For More Agility Do the Waterfall !

Yes you read it right. If you want to be more Agile then my recommendation is to do Waterfall model . But do it in reverse direction.  

Here is my simple theory -  If the Waterfall model is opposite of Agile, then by doing Waterfall in opposite direction you get Agile!   If Waterfall has long product cycles then we make them super short.

Without further ado..

Fail Early, Fail Often, Fail Cheap

Agile Development has  one and only one reason for its existence - We need to respond to changing customer requirements in timely manner by better utilization of productive resources. 

Now that requires discovering customer requirements. In his book Lean Startup author Eric Ries talks about using Validated Learning - a process in which one learns by trying out an initial idea and then measuring it and validating the effect. Our goal then is to define and discover a minimal viable product (MVP) which is the "version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort" 

Turning back the Arrow Of Time

Let now do the Waterfall in opposite direction.

1. Announce your product's General Availability : Start with writing an internal press release of your finished product. The target audience is end user who is going to benefit from your solution. Describe how your product is better than your competition and how it exceeds customers expectations. Like a real  news story, include a narrative scenario of how one customer solved their most pressing problem using your product. 

At this point if there are not enough real benefits to make it a compelling value proposition then it is unlikely that product will succeed in the market place. Rework on your product idea. Don't rush this step. Get it right - are you appealing to right market segment ? Do they really have that problem that you are trying to solve? Remember Mr. Kano? Have you used right portfolio of exciting/cool features and must have functionality ? Have you covered all stages of Buyer Experience Cycle ?

Once you have this narrative scenario/ press release - use it as a light house to guide all your discussions and planning. This press release is what James D. Murphy, author of book Flawless Execution calls Future Picture - a high resolution description of the way we'd like things to be. The richness, the completeness is what makes it work by having sufficient content and clarity to provide guidance down the road.

2. Test with limited Beta Users

Invite your most friendly customers to test your product. At this point obviously what you don't have is the working code. But worry not , you can still conduct the usability testing by conducting what is called Paper Prototyping.  Instead of customers interacting with actual software they walk through the mockups and paper drawings.  http://interchangeproject.org/2013/11/02/paper-prototyping/

This is super useful because you get direct feedback about your product and discover missing and confusing features. It is super cheap and super easy - because all you require is paper and pencil. 

But make no mistake - this is NOT about UX design only. For every user interaction there must be an underlying API that must implement that functionality. Your services don't live in a vacuum - they are there to enable user scenarios - so first discover what those user stories are. This also uncovers  a underlying mental model that users, experts and developer use to think about the "stuff"  in your applications domain. In his book Domain Driven Design, author Eric Evans explains importance of discovering what he calls Ubiquitous Language. This model is input to your entity model. Using the ubiquitous language in conversations with domain experts and end users is an important part of testing it, and more importantly discovering the domain model. 

The most valuable outcome of this stage is domain model and set of user stories.

3. Deployment

Next you should write deployment scripts and figure out how you are going to deploy your software.  It helps resolve many issues early in the game

(a) how do you do branching ? Service release management? (b) How do you handle various deployment stages - (prod, pre-prod etc) (c) How do you package it - docker image? VM image? .jars ?  (d) How do you manage dependencies in your code ? (e) Do you have stateful services or stateless ? How many ? How many for each stage? How do you scale them up or down?  Where is the configuration stored (f) where do logs go ?  (h) what about test infrastructure ? How do you stress the product ? how do you measure performance ? (i) can you use open source ? do you have to open you code? (j) How do you configure CDN? (k) How do you charge the customer (l) What is your architecture ? 3 tier? 8 tiers ? how do micro-services discover each other ?....so on. 

All these decisions affect the way your team works.

In addition it is a pre-requisite for integration testing. The software does not need to be ready - yet. If your software is a command line utility, it just prints "hello world" . If it is a REST service it just returns 200 OK. If its a mobile app it just shows a logo. It is otherwise useless - does not do anything interesting. But most importantly - you can deploy it !!

4. Integration 

Next is integration. 

Define end to end Acceptance Tests: By this time you have broken down your news release scenario into manageable set of user stories.  You must now define acceptance criteria for each user story.

Assign clear responsibility to services/ components: You have an idea about how your architecture looks like and you have assigned capabilities to each micro-service/ component. It is time to define how they fit together. Are there missing components ? Is data lost in translation ? Do you need to transform data?  Walk through each scenario and user story to discover what functionality a service needs to implement, what data it needs to store and what data other services can provide.

Define perf and scalability goals: This is the time to define your performance/scalability goals for each scenario (and sometimes each user story). Having clearly defined  measurable targets helps drive implementation decisions.

Create Scenario Score Card : Create a score card to track how far are you from meeting all your goals - SLA, usability, capacity utilization.  

5. Unit Test 

Use Test Driven Development for each service/component. Ask your dev team to write test cases before writing any code.

This is a well established practice in many places. I need not elaborate...

6. Implementation

This is where you have reached the point in development process where there is lot less uncertainty and increased clarity about the intended functionality. 

Early in the cycle everything in the Scenario Score Card will be in red, but that motivates team to fix that and strive towards a green score card. Release criteria is simple - when everything is green you know you are ready to ship the product for real !

You are writing tons of quality code and completing feature after feature. You are  experiencing what the psychologists call - the Flow ! 

Flow, also known as the zone, is the mental state of operation in which a person performing an activity is fully immersed in a feeling of energized focus, full involvement, and enjoyment in the process of the activity. In essence, flow is characterized by complete absorption in what one does. 

7. Design 

You have shippable product.  You have well commented and well tested code. It is time to write one pager "Getting started .." design document, so that new hires know where to start looking for the executable design ! 

Conclusion

For More Agility Do the Waterfall !