A staged approach to agility enhancement

The one and only immediate benefit of moving to agile methods from the traditional waterfall models is the ability to fail fast, than on the last day. This provides more time for recovery. If the organization is willing to nurture their agile initiative for a while, then they can expect the real benefits of transparency and productivity improvement.Without this realistic expectation, any organization embracing agile as a silver bullet solution to all their issues can get disappointed very fast and abandon their agile journey.

A focused, time boxed realistic road map for the agile implementation, will provide the real strategic business advantage to the organization. Based on my experience with agile teams , I have coined the agile implementation model for implementing agile within organizations. The only objective of this staged approach is to set the right expectations out of agile and to provide a road map for organizations to nurture their agility.

Level – 0

An aspiring organization, which is very new to agile project management practices. Most of the work happens in an ad hoc manner, or are based on waterfall, CMM, ISO etc.

Level-1 (Agile project management partial)

General awareness on the right agile management methodology is imparted to some teams, and they have started implementing tailored agile in their respective teams. Mindset still remains waterfall. Definition of done is ready for testing. Testing teams still work in the independent testing mode. Work allocation and tracking happens as in the traditional project management teams. Still they get some benefits.

Level-2 (Agile project management fully implemented)

At this stage, all the key agile project management practices given below are implemented.
• Product backlog
• User stories and estimation using story points
• Estimation using poker
• Acceptance test cases are written and documented before the sprint
• Sprint planning
• Work volunteering
• Daily stand up meetings
• Tracking Sprint board and burn down charts
• Sprint review meetings
• Lessons learned exercises
• Velocity calculations
• Role clarities scrum master, product owner, team members
• Tool usage for multi-location collaboration

Level-3 (Agile engineering practices implemented, Scaled)

At this stage the core engineering practices given below are adopted;
• Adherence to coding standards
• Create the unit test first
• Pair programming
• Integrate code at a time
• Integrate often
• Acceptance test automation

Level -4 (Agile HR practice implemented)

• Alignment of the HR practices to the agile values like commitment, focus, openness, respect and courage.


Agile case studies

Case #1  Large multinational product company with distributed development,involved in developing medical software product

The organization grew through acquisitions and plagued by informal groups with diverse cultures within the same organization. The organization has decided to adopt agile (scrum) as a strategy to bring in a common culture. There was a global scrum roll out champion located at Germany and they had consultants for every geography. I was their India consultant. Our strategy was to transition a hundred member team to agile and show case the results.

Success rating on a 1 to 5 scale where 5 > 1   #4

Case#2  Large multinational product company with distributed development involved in systems software development 

In this organization a particular product group comprising of 100+ engineers worked on a product for a couple of years and then the product got scrapped resulting in huge loss to the company. They wanted to adopt a framework which will allow them to fail fast, and not in the last minute. This ability to fail fast would have helped them to save lot of money. All the engineers were trained on scrum and then supported them during their implementation phase.

Success rating on a 1 to 5 scale where 5 > 1   #4

Case#3  A large multinational bank 

Because their competitors were more agile, their turnaround time for new features was much shorter than my client’s cycle time. They wanted to speed up their feature turnaround time, and scrum was the recommendation. I was one of their coaches.

Success rating on a 1 to 5 scale where 5 > 1   #3

Case#4  A start up company with distributed teams with a payment processing product

They got a very big order from a major client, and their product could not scale. For this reason they wanted to bring in more transparency and predictability into their process and scrum was the way. Midway through the assignment, they got entangled in more product related issues. Even though scrum was highlighting the organizational deficiencies, organization was not willing to listen.

Success rating on a 1 to 5 scale where 5 > 1   #1

Case#5  A start up involved in web application development who wanted to formalize their project management processes

A 100+ member organization where everything was happening adhoc wanted to formalize their processes. I recommended scrum. Implemented well. Perfect scrum happened for a while and then became customized scrum. Because of the transparency and the predictability provided by scrum, their customer satisfaction improved, resulting in repeat orders.

Success rating on a 1 to 5 scale where 5 > 1   #4

Case#6  A company who was outsourcing part of their product development work to India wanting to improve their cycle time and quality. 

Started by training the team, and then worked along with them for implementation

Success rating on a 1 to 5 scale where 5 > 1   #3

Case #7  A start up product company who has several orders for their product and struggling with product quality and predictability. Currently I am working on this assignment. Adopting a multi-pronged strategy comprising of;

  • Awareness building through training
  • Value stream mapping of features along with business analysts to improve user experience and faster ROI
  • Agile tool implementation
  • Working with technology teams to embrace frameworks which are conducive for agile way of working

Seeking the sales pitch first vs last

What is our sales pitch?

What is the value to the business of the customer?  (ROI).

Why should they buy this? 

Recently I heard these questions coming out of the sponsor of the product, just a couple of days prior to the product presentation to one of the  customers. Seeking the sales patch at the fag end of the development process is wasting a myriad of opportunities which we could have leveraged by asking the same questions very early in the development process.

Product’s Inspirational Quotient (PQ)

Have you ever deleted an application and re-installed it later?. Have you ever deserted a familiar brand temporarily and then came back to it afterwards?. This happened with me with Nokia’s user interface for android phones. I used it for a while, deleted it and then re-installed. it happened with facebook too. Jira is another case. Sometimes I wonder why I am taking extra pains to recommend some products to my clients, trying to convince them to go for it. Because I feel that it is designed o provide value to the users.

Have you ever wondered  about the teams who conceived the product idea, designed it, developed it, tested it, supported it, marketed it. These are the teams who experienced great project experiences, by delivering great products with tremendous user experiences. They will be able to honestly say that they took pride in what they were doing. They were building great products, not just coding and testing. They were building cathedrals not carrying stones.  Project experience and product experience are intertwined. Everything starts with the product’s inspirational quotient (PQ). If it has the potential to get the stakeholders inspired, half of the job is done. If it is low, it is too risky to continue with the product idea. ‘Fast failures’ are always better than ‘late failures’.

Product’s inspirational quotient (PQ) is linked to the value the product offers to the users of the product and the tangible business benefits to their organizations. Identifying the user’s of the product and classifying them based on the  quadrants of;

  • High power. high interest groups
  • High power low interest groups
  • Low power high interest groups
  • Low power low interest groups

during the very early stages of the development process, helps us to focus on the value to these users. This helps to engineer ‘user delights’ into the product while capturing, grouping and prioritizing user stories. Here starts the compelling sales pitch of the product, which the buyers cannot ignore.

About the blogger 

Abrachan Pudussery is an highly experienced and independent agile culture consultant working with teams in helping them to improve their project and product experiences. Click here to contact  him