Nimble Manifesto: Agility Without Agile

So what is the Nimble Manifesto?

The Nimble Manifesto is a call for sanity in software engineering. Agile paints a picture of an artificial fight between itself and Waterfall. This is a false dichotomy. The choice is not between just-in-time decision making and rigid up-front detailed plan.

What we want is a method that keeps up with changing plans and gives some degree of predictability too. As an added bonus, we can move faster without meetings eating up our teams’ calendars, we can keep our teams productive and effective without such frequent rewrites, and we can keep our developers from burning out sprinting all the time.

 

Nimble Values

Able to evolve OVER grind-to-a-halt technical debt

Absorbent to business evolution OVER constant reactive scrambling

Predictable cost and duration OVER the guess-and-check loop

Sustainable pace OVER perpetual sprinting

 

Bad for:

  • Precision Industries. Think NASA, autopilot systems, or medical devices. In these cases, we prefer exactness over flexibility. Space shuttles were not designed to be evolvable, they are designed to perform one role a particular way and to perfection. Time and Cost are less important but Quality is extremely important. Waterfall would work better.
  • Widget Factories. Predictably and similarly sized software tasks that don’t involve a high degree of creativity to build. Use “Capital-A” Agile.
  • Initial Prototypes. Particularly if they are prototypes of something small. Best to just do it- don’t be encumbered by process. When the prototype is proven or adopted, it’s often best to rebuild it from the ground up – you can significantly reduce Total Cost of Ownership.

 

Good for:

  • Most others. The VAST middle ground in between Waterfall and Agile.

 

But nothing is free. What is the caveat?

This is our tradeoff. In order to gain project efficiency, predictability, and maintainability, we choose to give up the fastest possible initial date of a feature. Working nimbly, we can complete the project quicker, know our costs up front, and mindfully choose the right balance of Time, Cost, and Risk for our needs.

 

My recommendation on how to use the Nimble Manifesto (on a 2-12 month project):

We have two goals to accomplish before starting the project: we need to put together system level requirements and get executive approval for the project, knowing the Time, Cost, and Risk.

System Level Requirements

  • Discover project requirements. These are the features.
  • Tease apart the system requirements- we’re working with capabilities here and not features.
  • Estimate these requirements. 1 person for each service or component (for backend) or each area (for frontend). We will use weeks, not hours to estimate. Why by week? We value accuracy over precision. When averaged together for the project, precision will be lost anyway. So course-grained estimation gives us accuracy.

 

Project Sign-Off

  • Build multiple potential plans that show various balances of Time, Cost, Risk.
  • Include staffing needs of each role- Architect, Product Manager, Project Manager, Developer, QA, Configuration Manager. The first 3 of these will be needed throughout the course of the project. The other roles will be introduced after the initial plan. Choose a realistic plan for staffing- not everyone can start on day 1, people can’t reasonably join and leave and join and leave the project. Mirror your plan to realities.
  • Present plans to the executive team for approval. Work together to explain the various balances of Time, Cost, Risk. Choose what makes sense for the business. Sometimes, it means building in-house, other times working with a consulting firm can expedite the project.

 

During the project:

  • Build software with engineering in mind. Use an architect to supervise the project.
  • When business changes come in, have a technical architect meet with a business architect to work together to measure impact and make decisions. The impact can be applied to the project plan and reassessed- get executive approval for anything major.
  • Don’t meet so much. It can encumber the team. Rather than be prescriptive, I will leave this one open ended. Are meetings adding the amount of value they are costing? Getting 5-10 people together in a room is expensive and distracting. The lightest possible process to keep things moving tends to make a big impact on added efficiency.
  • Features are integration points of our activities. We can demonstrate our capabilities coming together as progress. Progress will come more efficiently, but the features will not be here as quickly. At the end of the project, we will see the features come together.

 

Life’s a marathon, not a sprint. Let’s move adeptly, intelligently, and with a purpose.