My first agile project began as a disaster, which is why we chose to try agile. Nothing else had worked, so we threw agile at it knowing the ship was starting to sink. Thus far, we were always 2 years from delivering. The beast was huge and we were doing more work descoping and handling change management than actually getting functioning code out the door. Oh, and we were under ISO and other audits (risk mitigation being more important on a life critical system.)
But, it ended up being one of the best teams and projects I've ever worked on. I still stay in touch with many of the people on that team and it was such a huge turn-around that many of us have been working with agile since then.
This morning I was reminded of this as I read Przemysław's blog post about "Half-dead projects". It reminded me how our project start was focused on a team of 5 clinicians pulling from their various experiences to create the "scope" and requirements needed to displace competitor products from the market. They spent over a year figuring out what it would take to perform a market take-over. The goal was to be a #3 product in the space within 3-5 years. Starting from nothing, that meant we had a long path to pursue. To make it worse, our product had to be a global product fulfilling all the needs of each culture and continent. There were always exceptions and special cases uncovered every day for a specific country or language. We were constantly descoping to pretend our deadline was obtainable. Our focus was on the day where we sold our product to 25-50 customers.
Then one day we realized we were close to being done. Unfortunately it was "dead done", not deployed done. We needed to survive. We had a contract in place with a beta customer... they also needed us to survive. So we threw the kitchen sink at it and we went agile.
On some level we threw out the entire MRS, PRS, SRS, and 50 other piles of documentation. In 3 days, we created a whole new backlog with stories and estimates. Then we stepped back and we realized this was still too much.
So we threw that out and started again. We went to the beta customer and asked... "What do you need to start using this?" What they "needed eventually" turned out to be much different than what they "needed to start". Turns out, a lot of time is spent setting systems up in the health care setting. Provide some screens to start configuring x, y, and z... it will be 2 months before that is ready to be used. Build this next... etc. We focused on one customer... right here, right now. Every 2 weeks (instead of every 3 months), we demonstrated what we had built and we asked what was next. Our product owner made sure that none of our steps were unique to the one customer and our work still fit the long term global strategy (you can't focus completely on right now), and we kept making little victories.
Six months later, that beta customer had software in their hands. Think about that... we went from 2 years to 6 months. It turned to be much more important to have one active customer than 15% of of our product built.
My favorite confirmation was when they told us how much better the process was. How they now understand why it was so hard and that by being involved, they could work with us as a team to make hard decisions and insure something of value was handed to them sooner.
That is one of the core impacts of going agile! You know it is working when you have proven success! I now believe that a market take-over is achieved by convincing EACH customer to buy your product or service. It is not done by defining up front what they all need. Every customer is slightly unique. Prove that you can make one customer happy, then five, then 20, then 100.
You can take over the world one customer at a time with proven successes. You can't do it any other way.
No comments:
Post a Comment