Saturday, April 28, 2012

How My Team Decomposed Agile

Below is my submission to NY SPIN Process Nightmare Session in April 2012. This submission was selected, and I had a chance to present to the audience of software professionals. It was a great experience both having a chance to present and to listed to my fellow presenters about their experience. My favorite question from the audience was "If you did it all over again, what would you do differently"? Guess what I answered?

Anyway, below is the submission.

An “Agile Hammer”
(How my team decomposed agile)

Summary. Have you ever heard of a hammer analogy when people talk about scrum adoption? Imagine you need to put a nail down and decide to use a hammer, but you do not see the value or just don’t know how to use the hammer. So you decide to decompose it into two parts. Now you can use a handle or the metal part to put the nail down, and either part is more effective than a bare fist. But only when you use the hammer as a whole the way it’s intended to be used, you will be able to achieve true efficiency. This is what my story is about: how my team adopted agile by decomposing it, and as we were progressing with our implementation, we realized the value of all the missing ceremonies and ended up with an efficient “agile hammer”.        

How did it happen?
In 2005, when Agile adoption rates according to Forrester research were about 15%, I was a project manager on a team of 13 (6 developers, 3QA, 2 BAs, dev manager, and I) responsible for development and support of an enterprise level proprietary application. We were a waterfall shop and I quite enjoyed my role of a PM – my 10-page Gantt charts gave me a sense of accomplishment and I felt I was in control as long as my MS Project Plan was updated on a daily basis. The only downsize was normally towards the end of the project when I was able to accurately assess progress and it would become obvious that after 6 months of hard work and one week into QA testing we are completely off track and something needs to be urgently done. Then, I would alert my business stakeholders, risk and issue logs would start growing exponentially, and for another 3 months my team would lose any sleep trying to catch up. 4 QA cycles later, after descoping or phasing out nearly 50% of functionality, we would deliver working software, then struggle to fix post-production defects for another two or three weeks, and after celebrating the fact that the nightmare of that release is behind, we would start new projects slowly, giving a chance to developers to relax a little bit during requirements gathering. Despite the team working crazy hours, the business was never appreciative citing long time to market, low quality, and lack of visibility into the project progress.

And then one day dev manager called a meeting and said: We are going Agile. I thought he meant: We are going crazy – because at that time we were into the “meet-the deadline-or-die” phase of the project when the business informed us that because of a competitive product which was just release, the work we were doing for 6+ months was useless and we had to start requirements gathering cycle all over again. So I asked what he meant by Agile, and he said that this is a new framework which will help us adapt to the changing business needs and we would be able to produce working software within two weeks. We all laughed. Our application was a multi-tier multi-technology enterprise level platform with a distributed team in 3 countries working on it – how was that possible? Quite possible, he said, and here are the rules: you meet every day for 15 minutes, have a business stakeholder dedicated to the team and available every day, you stop doing hourly estimations and assign abstract point to your requirements, which are not requirements any more – they are called stories, and when you are done, you invite the stakeholders and show them the work. We said that it is insane to move from 9 and 12-month projects to two weeks, and besides, how do we know if it works? Retros, he said, it’s like lessons learned, we will inspect and adapt, and this way we will continuously improve our practices.

We decided to give it a try. The first few months were a nightmare. Our daily “sit down” meetings were one hour long, we were constantly stepping on each other toes. Our product owner was telling the team to switch to a different project mid-sprint. Acceptance criteria were not available. Product backlog was not prioritized. We decided not even to try estimation – this was too complex to grasp. We were not meeting our commitments. Our retros were more about complaining how painful this experience is and how we miss waterfall with uneven load and unhappy business stakeholders. We started moving towards agile more: implemented story point estimation, started to stand during daily meetings which miraculously became shorter, started parking discussions and answering only three standard questions, our retro became focused with action items which we were tracking. The business gave us a stellar feedback, and after sprint 5, we were stunned when someone on the team noticed that we stopped having post-production defects. However, we still had our mini-waterfall within each sprint: requirements gathering, development, QA, and UAT. We even split the team into two, so that their cycle overlap and eliminate productivity loss. We thought we were doing as well as it is possible until a during sprint 12, someone from QA said that she wanted to do some development and was successfully trained. One sprint later, we need additional QA resources and one of the developers volunteered to help. We merged back into one cross-functional team and abandoned mini-waterfall.  At that point, we thought we cannot become any more productive, but our productivity tripled, and other business units decided to try agile because our stakeholders were as satisfied as never before. It was not perfect and commitments were still occasionally missed, but we as a team – no longer divided into business and technology – were confident of our ability as a team to deliver high quality work while growing professionally and enjoying what we were doing.

This team-level transformation took us over a year, and now looking back, I realize that we made a natural move from agile piecemeal to a standard scrum implementation. While being able to realize some benefits right away, we were step by step implementing standard practices – stand up meetings, story point estimation, retrospectives – and moving towards Agile. Each step made us more successful, but only when we connected all the dots, we were able to see exponential growth of productivity. This reminds me of an analogy I came across in one of the blogs. Imagine you need to put a nail down. Take a hammer. Let’s say you do not see the value or just don’t know how to use the hammer. So you decide to decompose it into two parts. Now you can use a handle or the metal part to put the nail down, and either part is more effective than a bare fist. But only when you use the hammer as a whole the way it’s intended to be used, you will be able to achieve true efficiency.

Since this first experience, I worked as a scrum master on many teams, and finally moved to another employer and became part of team that is responsible for company-wide transition to agile. In my role of an agile coach, the first thing that I tell our teams is: Agile requires discipline, do not try to pick and choose until you master it well. Only then, you will be able to determine what sprint duration, what estimation technique, and team composition is optimal for your team. Follow Agile framework that you chose step-by-step, otherwise you will learn the value of Agile as a whole the way my first team did, through painful trial and error, through a “hammer” approach.


  1. Hey, nice site you have here! Keep up the excellent work!

    Function Point Estimation Training

  2. Thanks for sharing, I will bookmark and be back again
    Agile Coaching

  3. Please come back, Kiruthika. Also, please tell me if there is a topic of an interest to you, and let's have a dialogue about your experience and mine related to this. My current set of thoughts is about showing appreciate to your team members - whether they need it, and if they do, how you do it. I hope to be able to share my experience on that soon - once I pilot a few ideas with my teams.