Excerpts From Agile Coaching

Sharing some quotes from the book which I found interesting: Agile Coaching

• When a company is in the middle of a reorganization, then people are more focused on keeping their jobs rather than becoming Agile. We would advise against coaching while this is going on because the pressure on the team will be too distracting, and you will probably be wasting your time.
• To help Agile teams improve, you need to work with the individuals in the team. They’re the number-one experts on how they work and why. Tap into their expertise to reveal what’s holding them back. Listen to their concerns and ideas one-on-one to give you insights on how they can improve. Give them feedback to help them see where they can improve.
• When you are acting as a mediator, be clear that in this role you can’t take sides. Listen to the problem from each side, and demonstrate that you understand what is being said by restating the problem in your own words. Next, try to detach the problem from the individuals and frame this in the context of the team. It may be useful to create a diagram of effects to explore the forces involved.
• Make Change an Experiment: Once a team takes the plunge and tries a change as an experiment, team members get used to the new way of working. Now, making the change back to original way of working is the change that they hesitate over. You’ll also notice that each change they adopt reduces their resistance to the next change.
• Take care about using “why” questions, because they can shound like you’re criticizing when you don’t mean to do so. For example “Why did you do that?” sounds accusing, whereas “What were you trying to do?” sounds friendlier.
• There is no point asking about what got in the way if issues aren’t followed up. Avoid saying “Let’s take that offline” every time the conversation meanders or someone raises an issue, because this is ambiguous. Rather than scribbling notes about issues in your notebook, write each item that requires follow-up on a whiteboard that everyone can see to create a parking lot for issues. At the end of the meeting, revisit the parking lot to prioritize the items and work out who needs to be involved in any follow-up.
• A coach acts as the conscience of the team.
• The whole point of use stories is to ask questions to better understand what users need and to find ways of breaking requirements down.
• If the team is making one small changes to support live applications, rather than actively developing a product, there may be no benefit in getting the team together to create a longer-term plan. Instead, you might e better applying kanban, which focuses the team on improving the flow of work.
• The team’s productivity will not improve by wishful thinking and “trying harder.” At worst, it plummets under excessive pressure.
• Team velocity often slows down a little as the project grows and the software supports more user stories. Plans should be based on the new measured velocity rather than continuing to plan with the old velocity, hoping the magic will come back.
• When planning doesn’t make sense (lot of bugs to fix, on vacation members) create a prioritized queue of work on the team board. Consider moving to a kanban style of development which doesn’t depend on iteration timeboxes to limit work in progress.
• Agile teams need to learn how to work together to meet their goals. They are not kicking a ball; instead, they pass software between team members. Each person on the team plays a part in getting the work done.
• Don’t let them get away with adding a single task labeled “Testing” for each story – this is a cop-out! A few examples of testing tasks are writing automated tests, preparing test data, and setting up environments.
• The job of testers is to “prevent defects” rather than collect them .If a story is still on the team board, then any problems that must be fixed should be posted there too, where the whole team can see them. Recommend the team uses bug-tracking software only for bugs that are found after the iteration ends.
• Encourage the team to design for now and to keep their design as simple as they can for current needs.