“Agile Coaching” Reading Accomplished
Finished reading the book “Agile Coaching” by Rachel Davies and Liz Sedley, it’s just as described :
“This book provides you with deeper knowledge of how agile practices work and how to inspire your team to improve. Discover how to coach your team through the agile lifecycle, from planning to writing software. Learn the secrets of running effective agile meetings and how to get your team following a consistent approach to creating software.”
The book was written like a story, from the beginning to the end of coaching organization. Since I experienced this procedure several times, even I knew almost all those, it’s still very useful to reflect again, especially it’s “Agile” coaching, instead of “Scrum” coaching or sort of “Scrum + XP” coaching. This book is actually a must read for anyone who is in Agile, only if you want to be focused on business areas (e.g. Telecom system) or technical areas (e.g. programming in Java).
* Part I Coaching Basics
First you should be clear about your role “Agile Coach”, and be prepared to start, its full checklist as below :
- Practice explaining Agile to others. You can do this with anyone willing to listen. Agile user groups are a good place to refine your Agile pitch.
- Do some groundwork, and work out the best way to be introduced to the team.
- Find ways to show that you apply Agile principles yourself. For example, you can work iteratively and have face-to-face conversations rather than asking questions by email.
- Apply the PrOpER cycle to your coaching interventions. Start with the problem, consider at least three different opinions that you can take, pick one and try that as an experiment, and then review the outcome.
- Pause to reflect and learn from your mistakes. Leave room for the team to learn from mistakes too.
- Look for opportunities to learn from other Agile coaches, both inside and outside your company.
- If you work with one organization for a long time, you can get pickled. When the team is running an effective Agile processes. It’s probably time to move on.
When you start there are many things to be aware, working with people is not just as easy as sitting together and start typing keyboards. You have to practice how to listen carefully in order to understand the problems, ask questions to clarify if you don’t get somebody’s idea. While providing feedbacks back to them, separate the observations which is neutral and your personal interpretations or even judgments.
Trying to introduce change is always hard, people are suspicious about changes normally. Share your passion for Agile, without being too fanatical. Talk with each individuals, care their opinions and concerns, clarify them, tell them what would they benefit from this change. Working on promoting the learning culture, encouraging people to read books by sharing your own, share blogs you read, point people to podcasts, etc. And it’s 100% that you’ll face resistance, don’t be upset or put it into personal, start with understanding where it comes from, check the reasons from yourself first, this is actually a good attitude for Agile teams — don’t complain others, change yourself first.
The 4th chapter of this part is “Building an Agile team”, Rachel and Liz shared a checklist :
- Create opportunities for the team to get to know each other, which helps the team jell. Regularly spend informal time together, such as lunch or drinks.
- Create a shared workspace to help the team work together well. Try to get the whole team sitting together.
- Make role responsibilities clear. Get the customer the support the need to work within the team.
- Ensure the team has a reachable but challenging goal. make sure the work is neither too easy nor too hard.
- Arrange food or drink to celebrate a release. Ask customers and management to thank them.
* Part II Planning as a Team
This part mainly talk about how to get the framework in place, covered topics like “how you do the daily standup”, “understand the requirements”, “planning and prioritizing”, “make progress and problems visible”.
Having a successful daily standup meeting is not as easy as defining the time, place and send out invitation. You may face tons of problems, people may arrive late for the meeting, people complain the meeting lasts too long, or the daily meeting is hijacked by someone, even you may have somebody who can not standup… The authors’ tips are :
- Find a space that the team can run their daily standup around their team board. If they don’t have room in their workspace, then use a portable team board.
- Make the time that the daily standup runs a team decision. You can run it more than once a day, if not everyone works the same hours.
- Encourage the team to keep their replies short and sweet. The three-question formula can help the team get started, but don’t let this become a straightjacket for daily standup conversation.
- keep the daily standup flowing; a speaking token puts this in control of the team.
- Ask the customer along to the daily standup to give her progress and updates.
- Gather issues that come up on a whiteboard where everyone can see them. Prioritize it with the team, and follow up afterward.
- Review the effectiveness of the daily standup in the retrospective, and experiment with the format.
According to my own experience, there is always a problem with understanding requirements, more or less. The user story practice from Agile is very good for this, it promotes 3C (Card, Conversation, Confirmation), to help team clarify the real user requirement, and establish common understanding, with the analyzed tests for acceptance. One thing would be important to mention is, the User Story card or any format of written-down is not requirement documentation, tell them the INVEST principle of a good user story.
At the beginning of each iteration, there is the planning meeting, help team preparing for it, and teach them how to estimate and prioritize. During the iteration, encourage them to have a team board, and make it the information radiator, plus big visible charts. Avoid burying information into electronic information fridges, it’s easy to ignore and don’t update them nor use them.
* Part III Caring About Quality
In this part, authors talked about the Definition of Done, how to drive development with tests, and about writing clean code. “Done” is a practice used as agreement on quality, which “means the customer is happy with what has been developed, and all the story tests pass.” from the book. Check the picture on the right for example. Don’t forget testing, make sure that testing is considered in the iteration planning so testing tasks are understood by the whole team. Share the bugs at the same place as story tasks, otherwise there will be a hidden backlog in those bug tracker systems. At the end of iteration, if the team doesn’t get all the stories done, talk about it in retrospective, figure out ways to improve.
Test first is one of the XP principles, which forces you to think deeply about the reason for your implementation or design. Why I need this piece of code? Why I need this execution step of test scripts? Why I need to verify this functional behavior? Doing this in the best way requires a whole bunch of Agile practices, e.g. Test-Driven Development, Acceptance-TDD, Test Automation, Continuous Integration, Refactoring, etc. However, get people trained, and tried on those practices, reserve time for the transition to those practices. For Continuous Integration, focus on the attitude change than tool setup.
Keeping your house tidy and clean is obviously important; otherwise, over time it becomes impossible to live in. In the same way, if the team doesn’t take time to keep their code clean, it becomes messy and fragile, which slows them down. As their coach, you’re there to support them in learning how to keep code clean, tested, and integrated all the time. The checklist as below :
- Help the team strike a balance between spending time on software design vs.. time implementing code. The team needs to focus on designing for the user stories they know about rather than second guessing the customer.
- Remind the team during the planning process to allow time for incremental design. Get into the habit of using a whiteboard in the team workspace for design discussions.
- Encourage the team to improve software design gradually by refactoring before every check-in rather than building up technical debt. Refactoring tools lower the barrier to making design improvements. Make sure the team knows how to use them.
- Bring the whole team together to agree on a common coding style. If the team doesn’t adopt pair programming, recommend they incorporate peer code reviews into their definition of “done.”
- Help the team formulate a plan to renovate any areas of the code where design has decayed. Fixing broken windows helps the team keep the standard of design up.
- Use pair programming to get two heads on difficult problems and spread knowledge within the team. Set the team workspace up so that pair programming is comfortable, for example, two monitors displaying the same desktop.
- Introduce ping-pong programming to encourage pairs to swap between the roles of driver and navigator. Watch that pairs take enough breaks and swap partners rather than forming pair cliques.
* Part IV Listening to Feedback
For the team, after started the iteration, it’s time for review the user stories, whether they are Done or not. And the team should take time to retrospect themselves too. In my opinion, retrospective is the most important for the team compare with other ceremonies, because it’s the point for Inspect and Adapt of the team. Normally you could facilitate it like in the sample agenda :
- Review the goal of meeting, and remind the team of the ground rules.
- Create a timeline.
- Mine the timeline for insights.
- Select the topics to focus on.
- Review the progress on previous actions.
- Generate ideas for improvements.
- Action planning.
Been aware of those hurdles, they ruins the effectiveness of retrospective : Same action comes up again and again, cut them into smaller ones, or simply use the SMART principle for your action; Some team members are very quiet, and be clear that it’s ok to say “pass”; Team is always moaning, then try to get the team back into learning mode by asking, “if this situation happens again, how should we react to it?”; If you want to share your own impressions too, you need to be careful not to be seen as “taking sides”, “playing favorites”, stay neutral, or find another facilitator to help you, so you can be released to join as part of the team.
The final chapter is actually the most close important for yourself :-) “Growing You”, how you can grow as a person and keep your ideas fresh, you also need to take care of yourself in order to cope with the day-to-day demands of being an Agile Coach. Check Rachel and Liz’s checklist first :
- Make time to learn. Create a plan of what you want to learn this month and for how you will do so.
- Make time to reflect. The most powerful lessons don’t come from books but from learning from our own mistakes—small or large.
- Take time out to distress. Work can seem very important, and it is easy to let it swallow you up. Keep things in perspective by making time for yourself every day.
- Meet other people who care about the same things as you. Local interest groups and conferences are great places to meet people who will help you keep your passion for Agile alive.
- Be kind to yourself. Forgive your mistakes. Learn from them, make amends, and move on.
- Be kind to others. Don’t attribute bad intentions to people. Instead, find out why they are acting that way. Differences in opinion and style in a team are good.
- Don’t let your job grow stale. Keep pushing yourself at work; otherwise, it will no longer be fun.
Generally, it’s pretty much the same how you advice the team. First, look at what you’re good at or experienced, start from them, broader your knowledge areas, You could commit to read one technical book per moth, or listen to a podcast on your way to work; enhance your experience, by starting blogging, which requires you to think critically and be systematic and logical with your words. Second, you could create your own personal development plan, like a product backlog, what are the highest priority parts you want to improve, of course, remember the SMART objective. Third, build your network, join conferences and user groups, grow together, and learn from others. Finally, be kind to yourself, we’re human, we make mistakes, we are not perfect, so you are.
* My Conclusion
It’s a good book, read it.