Over the course of the last couple of months, I’ve been working with a client who is interested in changing their approach on how to handle what they term as “Big Rocks” in IT for planning, execution, and delivery. We had our first demo and retrospective yesterday, and I felt a tear of joy in my eye. So, I thought I’d share a little progress report from the field with you on some agile success.
We started with a business requirements document that took about 2 people years to develop. Some of the items in this long document were items that haunted the organization for up to 4 years. The normal next steps would be to take the requirements and submit them to the various silos of development for specifications, come up with project plans, manage the dependencies between the development silos, engage QA, and hopefully integrate everything together at the end and release the new and improved system.
My coaching and mentoring strategy was centered around the normal set of Agile and Lean values, principles, and practices that I employ to get organizations thinking in an Agile mindset. I did add a new visualization to the mix, the “Agile Fluency” concepts that started with James Shore and Diana Larsen, which are being popularized by Martin Fowler.
We would start with the business leaders and decision makers on making a shift into business value focus at the organizational level for teams to be newly formed and sustained, with each team able to deliver independently on the software side of the value proposition considered.
From the start, I made it clear that whatever new process we came up with, I wouldn’t just try to make for better planning of dependencies between the software layers and better tracking of actuals versus estimates. To start, I wanted the organization to take a fresh look at what made sense to do from an economic perspective, and then use Lean principles of waste elimination to guide us on how to execute the plan. Core to all thinking was the concept of a feedback loop, so we could constantly exploit variability as the landscape changed.
The results were both surprising and expected. After looking at appropriate lightweight monetization of benefits and cost, the first and most beneficial epic emerged – which was to be expected. However, what was surprising was how the business started to see that a point of diminishing returns would be reached only 6 months or so into the backlog created from the initial business requirements document that would easily be expected to take at least 18 months to complete. This started raising eyebrows and opened people’s eyes about how to better spend those development dollars for other items on the organization’s portfolio of work to consider. Rolling budgetary planning would occur monthly (which I think is a bit too rapid, but we needed to try and learn from it). The organization decided to stop forming teams around projects, limit their WIP for projects under development, and bring the work to the teams as part of their Scrum product backlogs. There were some vocal skeptics about how this could never work, but the client’s senior leadership team gave the go-ahead for a limited trial of the new way of approaching work. For me, I couldn’t have been happier!
As we started up the first team to execute on the newly value focussed single stack ranked backlog of work, we faced a really tough decision. The organization was used to silo development with project-planned dependencies resolving the (infrequent) points of integration with a UAT blessing at the end saying that the right stuff was built, followed by a QA stamp of approval that everything in the applications all still work. The application architecture was rather complicated, with web, middleware, and backend layers of components. The deployment process is manual, hard to coordinate, and fraught with peril.
My suggestion for Scrum team formation was to bring all the development layers together with the Product Owner into one project room and begin to develop the skills to consistently deliver on the value. Additionally, I really wanted some of the Agile Engineering practices of Continuous Integration, Automated Regression Testing for both white and black box testing, and Automated Deployments to be started and gain some traction. I felt that without reducing the entire concept to cash cycle time, these new organizational cultural shifts would be tossed aside quickly as hard and expensive, and a reversion to the status quo would quickly occur once I left. We got support from all the development silos with the exception of QA, who pledged to add a person to the team, but would not commit to enabling them to develop automated tests as we developed the code.
Our initial iteration planning went as well as could be expected for a team that was unaccustomed to working with one another in such a close and collaborative fashion. Our Definition of Done for stories included using Ant build scripts that invoke JUnit, SoapUI, and Selenium webdriver/PageObject tests run on a Continuous Integration server (which was to be built in this first iteration). It was a pretty tall technical order with huge uncertainties for a team that needed to get comfortable with a new way of how *they* approached work.
I was honored to see this team get its work done. Was it perfect? Nope. We had to do some backlog grooming a few days into the iteration, because we hadn’t had a chance to get completely through the backlog, and wanted some idea about what the general shape of the release would look like. To our horror, when we started digging into the workflows and UIs that support them, we saw that a story that we had completely worked through make it impossible to implement something that we now were trying to wrap our arms around. Right after we discovered this, the Product Owner had to go to the full Delivery Team and say, “Gang, I know that this is what I said we needed during our iteration planning. But don’t do that. I just figured out that I need something else!” Conversations were had, and the team felt comfortable once again. At the end of the iteration, during the demo, the Product Owner recounted the story, and then explained to everyone, “if we had done this in our previous process, we could have had to wait 3 months to even see that we had a problem!”
The demo was also super cool when the developer that put together the CI server wanted to show what the tool looked like and what it did. Just that day, the developer was asked about a small change that needed to be researched from an architectural perspective for the next iteration. Going out on a limb, the developer made a code change in that direction during his demo, and committed his work. The CI server kicked in, and allowed him to show the product owner what that new feature might look like. In real time! Before, that level of system integration would have taken days to deploy, just to show what something would look like. In the past, decisions would be made based on documentation, but that’s not as valuable as seeing the actual new feature running!
Anyway, it was one of those all too rare victory moments for teams at this client. Senior leadership team members were thanking the team and saying how they were amazed on the amount of progress that could be demonstrated in just two weeks. We have a long journey ahead, but we’ve gotten started on the right foot.
Anyhow, I was so impressed with this team’s progress that I decided to send this card and share their success with you. It’s beautiful. Wish you were here!
Want actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.