Freigeben über

Motley says: "Milestones are useless for agile development"

  • Artikel

Summary

 

Motley: Milestones are useless for agile development. Our feature team can ship at the end of every iteration, so milestones have no value for us.

 

Maven: Milestones provide a synchronization point across a set of features, helping to ensure the overall product is of high quality. Every milestone has a set of exit criteria that the integrated product must satisfy before moving on.

______________________________

 

[Context: Motley is analyzing his team's upcoming deliverables and is questioning some of the Cynthesis Software development process]

 

Motley: Overhead, overhead, overhead. Why is the project manager making our team go through all the hassle of hitting a milestone when we are doing iterative development anyway? We have mini-milestones every time we finish an iteration. We produce a shippable piece of functionality that is ready to go. Milestones are useless for us.

 

Maven: Actually, milestones have use even in an agile world. You are not the only team contributing functionality to the release, right? There are other teams building features?

 

Motley: Yeah, so? Some of the other teams are doing agile as well so they likely have the same questions as we do. For the others not doing agile, well, they need to wise up and get with the program.

 

Maven: It's not so easy to change a company, as we discussed in previous conversations on change management. At some point you need to bring all the feature teams together and make sure everyone is synchronized. That's one of the primary purposes of a milestone. It is a checkpoint that all teams have in common with a set of exit criteria. A milestone brings everyone together to ensure all teams can integrate their features and come together to create a product. Milestones may not be technically necessary if there is one small team developing a release. You can ship at the end of every iteration, at least in theory. However, when many teams are involved in creating a large product, you  need to periodically bring everyone together.

 

Motley: Milestones just seem too process-heavy. Why not just sync-up on an as-needed basis?

 

Maven: Don't forget - milestones also have use to people outside the company.

 

Motley: Why should anyone outside our development group care about our internal milestones? Perhaps your girlfriend needs to know so she can expect you to work some overtime around the end of a milestone, but other than that, I can't think of any reason.

 

Maven: With any significantly-sized product, Cynthesis typically ships technical previews, does integrated product demos for customers, and ships beta releases. Typically these interim releases prior to ship align with milestones to ensure product quality is high. Because each small feature team may have their own iteration schedule with their sprints, the milestones provide that date where sprints can align.

 

Motley: Fine. I can accept all that. It still seems process heavy though. You mentioned the phrase "exit criteria". That phrase has "formal process" stamped all over it. Pepto Bismol is my exit criteria after eating bad seafood.

 

Maven: Ah, dude, that really wasn't necessary.

 

Motley: I know, but potty humor is always fun anyway <laugh>.

 

Maven: Back to business. Yes, "exit criteria" is one of the more formal-sounding software engineering phrases, but it does have use. At the end of any given milestone there is typically a checklist of quality criteria that each team and the overall product has to satisfy before the milestone is considered done. Think of it as a team-wide definition of that ever-so-important definition of "done".

 

Motley: Ah, so it's a fancy phrase meaning that once we put all the pieces together that they all work well together. That would include overall performance, end-to-end integrated scenario testing, stress testing over time, lack of cross-product memory leaks, general usability and consistency across features, consistency of documentation, how it works with the rest of the system, and other general product health issues.

 

Maven: Exactly! We put all the pieces of the puzzle together and hopefully it produces a beautiful picture. Without that checkpoint you could ship a product with puzzle pieces that don't match creating a jumbled mess.

 

Motley: I see. Makes sense. One thing that I would encourage the project managers to do, however, is not make those exit criteria too strict and that we focus on the right things.

 

Maven: That's a very astute observation, Mot. I worked in one company where the exit criteria list was pages and pages long. After about the first third in priority order, the rest just created needless overhead and diminishing returns. It felt like the project managers were micromanaging the feature teams. Instead of speeding up the development process, it slowed everybody down, in my opinion.

 

Motley: Ouch. I guess we should consider ourselves lucky here at Cynthesis. I can put up with a reasonable list of exit criteria, but you don't want to know what I do when someone tries to micromanage me.

 

Maven: Imagine nag nails for every little thing like high priority bugs you haven't updated in the bug database for a few hours, or nag mails because the project manager thinks you haven't triaged your bugs but your process is different than other teams, or people screaming at you because bugs are not assigned to a specific individual person and are instead on a bug backlog. I'll stop ranting now, but just know that these things can be a reality even in great software companies.

 

Motley: Enough! Enough already! You are going to make me start pulling my hair out just thinking about it, and I really don't have that much hair to begin with.

 

I understand the need for milestones. From my perspective of being on an agile team, we keep going as usual, make sure we integrate on a regular basis, be strict about our meaning of "done" for tasks, fold the exit criteria for milestones into our everyday development and guess what? Our team won't struggle through trying to meet exit criteria in the high pressure closing of a milestone. Smooth sailing.

 

Maven: That's the spirit. Your team is going to rock.

______________________________

 

Maven's Pointer:  Learn the intricate details of the milestones in your company. At Microsoft, practically every team has a "code complete" milestone. Most developers take that milestone for granted. However, the definition of "code complete" is different on every team. Do all features need to be done? Are to-do's allowed in the code? Do you need to run static analysis prior to code complete? Is some measure of API documentation required by the milestone exit? Learn what "code complete" and the other milestones mean on your team and address the exit criteria early.

 

Maven's Double Pointer Indirection:  Avoid cheating on the exit criteria when the end of a milestone draws near and the project manager does not want to change the date. You are only cheating yourself. Do your best to meet the exit criteria and maintain high product quality even in early milestones. Revisit the exit criteria for future milestones if the exit definition is too strict.

 

Maven's Resources: 

  • None this time

Comments