Know what to build
Being a great leader is all about enabling a great team. That starts with helping the team know what to build. What does your customer want? What does he really want? Why? Your team needs a deep understanding of your customer’s needs. They need more than a formal list of requirements–they need to understand the rationale and intent behind the requirements. If your team doesn’t know what to build, they simply can’t build it, and your customers and managers will be disappointed. If the team doesn’t understand what to build, they will build something technically great, but that isn’t what the customer wants. They will hyperfocus on some requirement that’s not important to the customer. They will build something that is interesting to them, but not to the customer. They will build exactly what is listed in the formal requirements document, and nothing else, missing the customer’s target because they didn’t understand the customer’s goals.
Scrum and Agile make it easy to know what to build. Instead of a big formal requirements document, use a product backlog. Fill the backlog with user stories. Each user story communicates both the What and the Why–what the customer wants, and the intent behind it, so even if the What statements are incomplete, the team understands the intent and can fill in the blanks. Prioritize the backlog by your customer’s business value. Always honor your customer’s prioritization; always build the most important stuff next, build the less important stuff later, and postpone the least important stuff, maybe forever. Add good acceptance criteria to each story, so your customer can better articulate his desires, and so the team better understands what to build. Estimate the complexity of each story as a team, so everyone understands the What and the Why, and so the team can preview upcoming stories and put some context around the current sprint’s stories. During the sprint planning meeting, decompose stories into tasks and estimate the effort for each task, so the team gets an even deeper understanding of the What and the Why.
Build it, and deliver
Now that the team knows what to build and why, they have to build it. More importantly, they have to deliver it–building it doesn’t count if they can’t deliver. Software is intangible, and building it is an intellectual exercise. But delivering it makes it a tangible, demonstrable thing: you either delivered it to your customer, or you didn’t, and your customer either accepts the delivery, or he doesn’t. Your customer doesn’t care how hard you worked or what hurdles you encountered along the way–he just wants you to solve his problems. When you deliver something, your customer feels less anxious and less stressed–you have proven that you made progress, instead of just making a claim of progress. For your team, build-and-deliver needs to be the norm, not the exception. If you plan to deliver exactly one time at the end of a long project, without having had any practice at production deployment, then you are planning to fail. So instead of building it and delivering once, your team needs to make delivery a regular activity, repeated every two weeks.
Scrum and Agile help here, as well. Make sure your user stories are small enough that the team can get any story done within half a sprint. At the sprint planning meeting, the team makes a commitment to itself, to you, and to your customer, to build and deliver some stuff. When there is a problem that impedes getting the stuff done and delivered, the daily scrum and the sprint burndown chart alert you to the impediments early, so you can fix the problems early, before they torpedo the sprint. Break the user stories down into small tasks, each no more than eight man-hours of effort, so you can gauge daily progress–if you started a story yesterday, but it’s not done today, there’s probably something wrong. Display your impediments on an impediments tracking board so you don’t lose sight of them and so there’s pressure on you and the team to remove them. The sprint demo focuses the team on getting stuff done–when you demo i in front of an audience, the stuff better work! But don’t just demonstrate what you got done–deliver it in production. Focus the team on Really Really getting things Done Done: if it can’t be deployed as a production service at the end of the sprint, then it’s not Really Really Done Done. Guide the team’s definition of done to include “it was deployed in production.” With the sprint rhythm, the team gets into the habit of delivering to the customer every two weeks. Build-and-deliver becomes a normal behavior, not an exception.
Improve
So you built and delivered some stuff. Did you meet your commitment? Were you Really Really Done Done? How much stuff did you get done? Do your customers and managers expect more out of the team? They are paying a lot of money, and they expect more stuff done, faster, at a higher quality level. Can you do that?
Once again, Scrum and Agile make this easy. Help your team know its velocity by estimating user stories in story points. Use a product burndown chart, and gauge the team’s likely, best, and worst velocity. Inspire the team to increase its velocity, and help remove the impediments on their velocity. Keep in mind that velocity is a vector–not just a magnitude, but also a direction–and that you can’t just get more stuff done, you have to get more stuff done toward your customer’s goal. Keep using the daily scrum and the impediments board to achieve sprint commitments, and use the sprint retrospective to find and fix larger impediments. Don’t just react to the impediments you know today, because you’re already too late; instead, anticipate upcoming impediments, and eliminate them before they slow down the team. Do third party dependencies slow you down? Crappy tools and hardware? Lack of XP practices, such as continuous build or automated testing? Help the team identify its problems, help the team get them out of its way, and they’ll help your customer and management team kick ass.
