Whole Agile Team Collaboration and Self-Organization
Agile team members are empowered to negotiate between themselves. Projects are planned, developed, and maintained by the entire team, not individuals. Team members have direct access to those who need the solution. There’s no such thing as a team if there’s no identified customer.
A group where every member has the skills, confidence, and empowerment to take the initiative, make decisions, and lead others. When people see problems, they think, let me take the lead in solving this issue. Communicate project status to stakeholders. Manage and call out risks. Team members should ensure the quality and reliability of shipped products.
Help the team ship and delegate (both to the team and upwards). Motivate the team on the way. Set up a framework for collaboration. Break down the project into milestones & provide estimates on these. There should not be a global entity managing the work of the team members. Individual team members are not a good metric to assess the complexity of work.
The practice was renamed Whole Team to clarify that a development team was not a customer/programmer dyad. Questions can be asked and answered within seconds. The experts who know the answers are always near. The whole team attends the IPM. The entire team includes the stakeholders, the programmers, the testers, and the project manager.
The goal of each iteration is to produce data by getting stories done. An iteration should contain about the same number of stories as there are developers on the team. The stakeholders will have read the estimated stories and sorted them in the order of business value.
The team should focus on stories rather than tasks within stories. Stories are chosen by and belong to individual programmers. Managers and leads will be tempted to assign stories to programmers. This should be avoided. Let the programmers negotiate amongst themselves to promote collaboration is far better. After all, agile teams should be self-organizing teams.
Don’t Underestimate. Estimates should be as accurate as possible but only as precise as necessary to keep the estimation cost low. Even if you’ve worked on the same task in the past, nuances are always involved in each study. Separating large tasks into smaller ones improves the accuracy of estimates. Decompose estimates into tasks requiring at most two days of effort. Estimate in ranges: worst case, most likely case, best case for a task. Document and communicate the assumptions embedded in your assessment. The best estimation techniques for small projects tend to be “bottom-up” based on estimates created by people who will do the work. Next time someone asks for an estimate, grab a Post-it and take note of your answer. When you are ready to begin the task, start a clock and see how long it takes to complete. Once the task is done, note how many hours it took to finish. Repeat the same thing for the next task.
Minor releases aim to increase delivering value by increasing the number of deploys. Measuring cycle time is the first step to moving towards more minor releases. If you release every six months, try every three months, every month, and every week. Keep shortening the release cycle in an asymptotic approach to zero. The term “release” means the software is ready to deploy. The decision to deploy becomes a business decision.
— -
[¹]: Robert Martin(2019): (Clean Agile: Back to Basics (Robert C. Martin Series))