Agility with Stability

I’ve recently been in a series of conversations with CTO’s and the topic of how to manage Agile development within large project teams keeps coming up.

The central issue seems to be that sprinting (an agile term for a one week planning cycle) doesn’t lead to longer term thinking.  This is exactly what the Agile community wants, since most long term thinking ends up being pointless as the domain isn’t well enough understood, and the market changes.  

Agile was initially designed by practitioners working on custom software development.  There really was one “client” and that client was highly invested in the outcome.  Thus, co-creation was entirely possible, and absolutely warranted.

Now that Agile has become an almost subconscious choice for much development, it is being applied well beyond that initial frame of custom development.  The struggles that I am hearing from CTOs center around:

  • Refactoring: We end up refactoring in a major way, a lot of the time, where we actually knew about the requirements when we initially did the development.
  • Burn out: Teams can only sprint for so long, before they start to wonder where they are sprinting to.
  • Strategic Planning: My teams are loath to commit to any longer term plan, as they trust only the Agile process, and don’t believe in roadmaps that go out more than a month.
  • Management Visibility: I can’t deliver to management what they really need - a framework to plan around - without undermining my team’s process.  I hate committing without bottom up estimates, yet I acknowledge the X factor that Agile handles well.

The litany above points to a central issue, that Agile doesn’t inherently address longer term planning and roadmapping, and often leads to a polarization between THE TEAM and THEM (management).  

I wanted to share a principle that we discovered turning around Visual C++:  

Milestones are about the “spirit” not the “letter”.

The letter of a milestone is the plan of record, usually a precise feature list and accompanying schedule estimates.  The spirit is the actual meaningful change in the user’s experience.

Teams that try to get the letter right end up in the trap of driving themselves crazy trying to live up to the foolish, uneducated promises of their former selves.  This means overwork, mistargetting, disappointments, and an increasingly incoherent product.  They also slip - a lot.

Teams that focus on the spirit are more successful.  By focusing on the desired impact, rather than the chosen features, the team takes every missed estimate or new issue as an opportunity to be creative about how to achieve the spirit, without slipping the milestone.  Features get scaled back, cut, or replaced, and the team constantly reconnects to the initial intent.

There’s a lot of subtlety to getting the spirit right, and communicating it to the team the right way.

For example, if we’re working on a todo list manager for mobile phones, we could state the first milestone as:

Item creation, management and deletion.  Sending reminders through email and/or social network of choice.  Registration, login, authentication.  Screens to support single list workflow on each native platform.

This is a “letter” definition.  It’s really a long inclusive feature list.  There’s no wiggle room once we realize that we haven’t factored in Facebook Connect and OpenID, or don’t have anyone who knows anything about Symbian.

Instead, we could define it as 

Get started, get reminded.

There is plenty to be inferred here, but there are many ways to achieve the spirit without getting hung up.  The exhaustive feature list still exists, but now we can use the spirit to define backlog priorities for the team to do an incrementally better job of getting started and getting reminded.

The biggest advantage is that consumers of the roadmap know what they will be able to do (get started, and get reminded) but not how (through email and/or social network of choice).  That means that when MySpace tanks halfway into our milestone, and we decide that Facebook is all that matters, we don’t have to backpedal with anyone.

The spirit enables the team to be righter every day, where the letter almost ensures that they are very wrong as the milestone date approaches

The disadvantage of the letter based approach is that the team ends up being either late, wrong, or both.  The spirit gives enough guidance on what will be achieved, but gives the team the ability to make the right calls and cuts to deliver on time, and on (more abstractly defined) target.  Management can plan.  Developers can deliver.  Product Management can relax.

Spinning this out, five milestones on the way to a todo list app might look like:


  1. Get started, get reminded
  2. Share tasks with friends and teammates
  3. Organize teamwork
  4. Integrate with calendars
  5. Mobile and in-sync


At each step of the way, I’ve got a full featured, working, complete feature set, which even the dumbest Director or CEO can understand (“can I assign tasks to others?” “Not till milestone 3”, “Does it work with my google calendar?” “Not till milestone 4”).

Even better, questions that shouldn’t be answered now (“Can I make lists of lists?”) aren’t (“As of milestone 3, you’ll be able to organize the work of a whole team, how exactly that manifests as features will be figure out as we get closer to that milestone”).  And when milestone 3 comes along, the PM can be reasonably sure that the team will actually deliver something better than what the dumb Director would have expected from “lists of lists”.















References (16)

References allow you to track sources for this article, as well as articles that were written in response to this article.
  • Response
    Response: Landin Henkel
    Hey, thanks for the article post. Really Cool.
  • Response
    Agility with Stability - The Art of Work - Blog - The Art of Work: Strategy and Teamwork for Tech Leaders
  • Response
    Response: Check This Out
    Great page, Preserve the fantastic job. Appreciate it.
  • Response
    Response: Source
    Nice Site, Stick to the wonderful work. Thanks a lot!
  • Response
    Response: carpet cleaning
    Agility with Stability - The Art of Work - Blog - The Art of Work: Strategy and Teamwork for Tech Leaders
  • Response
    Agility with Stability - The Art of Work - Blog - The Art of Work: Strategy and Teamwork for Tech Leaders
  • Response
    Agility with Stability - The Art of Work - Blog - The Art of Work: Strategy and Teamwork for Tech Leaders
  • Response
    Agility with Stability - The Art of Work - Blog - The Art of Work: Strategy and Teamwork for Tech Leaders
  • Response
    Response: 1
  • Response
    Response: moviebox for pc
  • Response
  • Response
    Response: Good flower
    thanks for it.
  • Response
    Response: custom writings
    The conversation is really have good knowledge for the visitor and this article is the best source of getting information about CTO’s and agile development. I think this practitioners designed on custom software. I am glad to read this content story that is all amazing for the visitor.
  • Response
    Response: shaggi-sexy-lady
  • Response
    Response: Credit Bureau
    Agility with
  • Response
    Response: Clevertech

Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>