Even, if you don’t practice Scrum in your Team, probably you still follow the habit of having daily, short meetings during which all your team-members discuss together the plan of work for the next 24hrs. Daily Scrum have been adopted by many teams and is known as the most common way to help teams improve their communication, mitigate deliverables risks and accelerate the decision making process.
Ways of running Daily Scrum have changed over the time and vary between teams — some of them have their ‘daily’ in the morning, the others in the end of a day, many use…
During discussions about high-performing teams, we’re talking a lot of about coaching, mentoring, external trainings or facilitating workshops, but still forgetting about the other activity that can save companies a lot of time and money invested in building teams if it’s done right — RECRUITMENT.
“Acquiring the right talent is the most important key to growth. Hiring was-and still is- the most important thing we do.” — Marc Bennioff, CEO Salesforce.
Hiring the appropriate people to your organization, it’s one of the most important aspect of building effective teams and delivering successful products. Recruiting as the other skills can be…
Team’s Velocity is one the main metric used by Scrum Teams to plan their work and forecast potential future deliverables. Unfortunately, quite often the metric is being over-used and treated by stakeholders as the main method to manage business commitments and make long-term plans — such way of using Velocity is counter-productive, creates false assumption of control and support building working-environments focused more on output than on the outcome of work.
Almost each IT Project looks the same, we first organize planning sessions, build Gantts Charts and Project Plans, create Risks Log, analyse requirements, provide estimations, add time buffers for unexpected events, communicate the timeline to the stakeholders and then… after few weeks everything is starting to fail. Team gets irritated when asked once again if it’s finished yet, PMs get angry at developers that they don’t deliver things on time, your boss and customers are frustrated that you’re breaking made promises and… destroy their other plans.
After few additional status meetings, re-estimations calls with the team and months of delay…
Sometimes, things don’t go our way — product is getting bad reviews, our stakeholders are not satisfied with the financial results and people in the team are leaving. In this kind of moments, it’s may be worth to stop and go back to basics of product and team management.
Those generic truths could support us with getting through worse moments and help find ways to improve our current situation. When everything seems to be going wrong, remember that:
User Stories have become a standard way for software development teams to capture business requirements and build Product Backlogs. Unfortunately, quite often Product Managers treat User Stories as another way for storing already defined Business Specs, BRDs or requirements logs — such activities are counter-productive and don’t bring any real benefits from using User Stories.
User Stories were created to help Teams be more effective in delivering business value by building shared understanding between business and technical people, to quicker identify end-users and their problems and support building Products in an empirical way.
Software Products gives us the unique opportunity to see exactly how customers use our Product. By tracking thousands of metrics like Visits, Lead Time, Bounce Rate, Reading Time and other we’re able to gather almost a complete picture of the potential user of our system.
‘You can’t manage what you can’t measure’ — W. Edwards Deming
Unfortunately, quite often we’re getting lost in all of those data — the information overload is not helping us to focus on things that matter the most. …
If you’re new to the role of Product Owner, I’d strongly recommend to first read the below blog post, as it focuses on the basics of Product Ownership.
Your construction of the reality is subjective and prone to inaccurate judgment and illogical interpretations. The only way to limit the impact of it is to be aware of all cognitive biases (‘Thinking Fast and Slow’ is a great book to learn more about the topic) and make decisions based on data. Gather data for each of the new feature that your team is building. Get yourself immerse in already existing framework…
Having more than 1 team working on the one product means that you’re already working in Multi-Team Environment. The most common challenges related to working in Scale are associated with Cross-Team Dependencies, Shared Ownership and Goals Alignment. Those problems are directly caused by the increase of possible interactions between people and therefore the complexity of the whole system.
To reduce (it cannot be removed completely) the negative impact of working in Scale on the productivity and still apply empirical approach to product development, additional effort from each team would be needed to:
Sorry, there is nothing like perfect framework for delivering software, the ways of working depends solely on your current context — type of product, people, technical and soft skills, organizational culture. Sometimes the best approach would be to apply Kanban for product development, the other team would find Lean Rules and eXtreme Programming as the best fit for them.
To bring the most of value to you current company learn about various ways of working, software development practices, the psychology of teamwork and get experience by working in different type of products — Backend Application, Enterprise Systems, End-customer facing apps…