Agile Development - Mitch Lacey

I was teaching a Certified ScrumMaster course recently and the discussion of “done” came up. I love this topic, it is one that I am very passionate about.

The analogy I use when I think of what done means to me is around wrapping gifts. For this example, we’ll consider Christmas gifts, where done equals a wrapped present under the tree, with a nametag on it, making it potentially shippable – I can add the bow and ribbon later – the additional features required to really wow my customers. The story goes like this.

Burndown charts are a great tool. They show, at a glance, both how much work has been accomplished in a sprint and how much work remains. What they don’t show, however, is how much time teams are spending on activities, such as meetings and reviews, that go on behind the scenes. This ambiguity leads to questions like, “What’s the team really working on?”  “Is the team really maxed out?” and “Can the team take on more work?”In reality, the team probably is maxed out, working at their capacity. The question is, on what? Are they spending the right time on the right things? That’s the real issue here.

Until they know how the team is spending their time, product owners, project managers or anyone else who is not a core team member likely will ask the team to produce more, to increase their velocity. The team will perceive this constant badgering by “people that don’t understand” as ignorance, and they will react negatively or lash out at their product owner. The perception that this reaction will create is that the team is defensive, not willing to take on more work; maybe the team is not working hard enough.

What is missing is transparency. Once upon a time, the solution for providing that transparency was to use burndowns. And that was a pretty good answer—for a while. It turns out, though, that if you really want to measure value and keep a team working on value, you need more than that. By providing transparency and visibility into the work types the team is addressing, product owners and business can optimize for value.

Read the PDF

Please send me / post comments and feedback on this chapter!

"Are you done yet?" The answer to this question may sink your career, your team and your project. If you respond with a "yes," you may be forced to take on additional work. If you say "no," you may be branded as someone who can't get things done.

This innocent question is asked countless times on almost every software project. The way we answer, however, is anything but innocuous. If team members’ answers vary, it can degrade stakeholders’ trust in the project team.

Establishing an upfront, common understanding of "done" can save teams and businesses countless hours of refactoring, process-thrash, unclear communication and hidden work.

In this chapter, you will learn what a done list is, how it adds value, and the value it communicates to stakeholders. Then, I’ll present an exercise that will help you build your own done list and manage it over time.

Read the PDF

Please send me / post comments and feedback on this chapter!

Why do some teams succeed widely while others merely get by? Why do some teams eat change, stress and drama for lunch while others stay away from it like the plague? The answer may lie in the ability of the team leader, sometimes known in agile teams as the ScrumMaster. A good team leader has the uncanny ability to detect the non-verbal warning signs that show a team is in danger.

Reading the signs correctly can help prevent one of the most dangerous things that can happen to a team—burnout.

 Read the PDF

Hello!

I have just added a new section titled Resources. Here you can find my published papers and decks, Scrum tools that I use on my projects and a reading list. I will continue to add to this list over time as it grows!

Enjoy!

I have received permission from the publisher to begin posting the draft chapters.  Please find the working table of contents below.  It is in flux and some items I expect to fall off when new ones get added.

Enjoy!