Alice: Would you please tell me where to go from here?
Cat: That depends a good deal on where you want to get to
Alice: I don’t care much where—
Cat: Then it doesn’t really matter which way you go. — Alice in Wonderland, Lewis Carroll
A couple of notes/thoughts on this article:
(Source: The Wall Street Journal)
The retrospective has the power to be the most important element of a Scrum team. Many learning organizations use the retrospective or “after action review” to learn from mistakes, reflect on successes, and identify actions to improve things going forward. Typically, the three questions for a retrospective are:
I would propose a slight modification to those questions:
How is this different? Well, first, you are starting by reflecting on what exactly you had set out to do at the beginning of your sprint. You might remember the fact that you were never all that confident about your plan in the first place. You might think about the vision you had and where you had hoped you would be. Then you have a context to frame the good and the bad in. Based on our expectations, what went well? what didn’t go so well?
The focus now becomes bridging a more concrete gap that we’ve identified. Coming up with action items is one thing, finding volunteers to commit to them is another. This principle of self-organization is just as important in the retrospective as it is in the rest of the areas of scrum. If you don’t have a level of accountability in your retrospective, you probably will fall short in other areas as well.
I read a story this morning about an organization that uses retrospectives effectively. DTE Energy - the Detroit power company - had to respond to an emergency situation. The organization already had in place the discipline of “After Action Reviews” (AAR). During their crisis, many of the team members carried pads of paper with them with the headline “AAR Observations” at the top of them. While working to restore power, everyone on the team was aware that they would need to be able to help the organization learn how to improve going forward.
This leads me to my last point on improving retrospectives. If you are to be truly effective in your retrospective, the team needs to look at each sprint as an exciting opportunity to learn. When you go to a lecture or class excited to learn, you almost always take a pad of paper to jot down lessons learned and action items. Don’t let your retrospective be a time where you struggle to remember some of those lessons learned. It doesn’t matter what you use - a pad of paper, google docs, your favorite text editor - but if you see your sprints as exciting opportunities to learn, you will be taking notes along the way. When you get to your retrospective, you will already have great insights and action items that will help your team to improve.
How have you made retrospectives more effective on your team?
Every once in a while you read a book that literally has the ability to change your life. I can think of a few books that I’ve read that have had this affect on me. There are a couple things each book has in common. First, they are packed with timeless principles. Principles are true yesterday, today, and forever. They can be applied across a wide variety of situations and disciplines always with positive results. Second, they force you into action. Obviously, you must always choose to act, but these books are so packed with opportunities to act that you are continually pausing to consider actually putting down the book and applying the principles to a current problem or situation you are facing.
The subtitle of The Fifth Discipline is “The Art & Practice of the Learning Organization”. A learning organization is one that “makes key decisions based on shared understandings of interrelationships and patterns of change. Learning organizations have shared vision and collective ownership. Within a learning organization there is a great deal of trust and people feel that they can engage in dialogue and discussion about how things really are. When you are a part of such an organization, you are able to act with purpose directed toward a common vision without constantly reacting to the reality of your current environment.
The book teaches five disciplines:
I need some time to digest before writing another few posts on how I’m going to apply this to my career and life. Stay tuned for more!
We aspire to be a place where people can have uncluttered, meaningful connections. Communication is important. Like in the real world, context is important…. It’s never fun to be late to a market, but it does afford us the opportunity to talk to users to see what needs aren’t being met, what they like and don’t like, — Bradley Horowitz - Google+ Product Manager
I have always wanted to go to a Meetup and tonight I finally did. If you don’t know what a Meetup is, checkout the website, find something you’re interested in, and then just GO! It is a fantastic way to meet new people, learn about a topic of interest, and be able to contribute to a cool community.
The meetup was sponsored by a local consulting firm and they provided pizza, facilitation, structure, and a bit of instruction. The participants ranged in experience from those who were brand new to Scrum to those who have had years of experience.
The focus of the meeting tonight was on actual questions posted in Agile forums around the web. We talked in small groups about the actual answers to the questions as well as what about the questions “smelled” a little funny. Some of the questions were good questions while others reeked of Waterfall Evil!
Here’s a brief summary of what we discussed:
Q: The first question talked about requirements traceability. The person wanted to know: Why does Scrum so blatantly ignore traceability by allowing users to track requirements on a whiteboard with post-it notes?
A: We really had a lot of disagreement on this issue. Everyone thought that there were different levels of detail that needed to be tracked by teams through the developmentprocess (full SLDC). Eventually we came to the consensus that the questioned smells because the person is probably really concerned with being able to track things through a series of handoffs (as in traditional waterfall projects). We also discussed that tracking key information from sprints, documenting the results of sprints, and finding ways to gather data about your requirements so that you could improve in various ways were all good practices on a good Agile team. Being able to “track” things like velocity, estimates, and other historical data is good but making sure that continuous improvement is the goal is paramount. Agile teams should also make sure that they are using the lightest tool possible for the job. Don’t use a tool because it has a lot of cool features. Use a tool because it facilitates your highest possible efficiency. Agile Manifesto: we value comprehensive documentation we just value working software more.