In 2001 I was laid off from Lucent Corporation in Raleigh, NC. At the time, I was a software development director leading a group of developers and testers implementing optical networking devices. It was incredibly complex work and the teams were dedicated to doing great things.
This was just post the 9/11 attack and the Telecom bubble burst so to speak. So, all of the large Telecomm companies were impacted.
I was placed on the building close-out crew, so I had a long period of time “managing” the reduction. At that time, I began to write a book. I completed it in 2002 and it was finally published in December 2004. I remember at the time being incredibly impatient as the publisher, Dorset House, took its sweet time in the editorial and printing processes.
Fast forward to today, January 2017, and the book has been in existence for roughly 15 years. So, I thought I’d take a look back at some of the ideas from the book and see how they appear under my agile coaching lens from today.
Is there actually an “EndGame”?
One of the core premises of the endgame book was that software projects had a specific period of time called an endgame. I think I defined it at the time as:
The period of time when software is first exposed to external testing teams and testing till it is formally released into the customers’ hands.
This followed the Waterfall lifecycle where software passed through phases and gates. This being a primary gate from software development to testing. It was also the gate where most of the project time was “used up” so that the testers rarely had time to execute their original plans, which created a great deal of pressure in the endgame.
Today
Unfortunately, I still see endgames in the agile world of today. Now they are much shorter than their Waterfall cousins, usually occurring at the end of each sprint or iteration. But they are there nonetheless.
The term ScrummerFall was coined to represent the practice where software is delivered to the testers on an agile team around day 7-8-9 of a 10-day sprint. Clearly then the endgame is pressure-packed towards the testers.
While this isn’t the desired behavior in agile teams, it is still fairly common as the developers and testers fail to collaborate and rather hand-off deliverables between each other.
Endgame Metrics?
It’s almost embarrassing today to admit how much time I spent on endgame metrics in the book. Most of the focus was on measuring bugs cyclically through the various release cycles and trying to predict when find vs. fix rates would converge to a point when the software was ready for release.
I also spent time on defect characterization so that you would know what components they impacted. The focus here was on Pareto-based testing around where the defect clustering was occurring on each subsequent release. In other words, let the clustering drive your risk-based testing activity and focus.
Today
What’s interesting is that in endgames I made the mistake that many test organizations make. I focused on understanding and reacting to the bugs. While you can glean information from your bug flow, prevention and early detection are key today.
Pairing has become a popular way of developing software. It also serves as a lightweight training and inspection process that catches many defects at the point of entry. In the agile world, pairing isn’t just between developers. But all team members can and should pair as the stories meet the real world.
Quality vs. Testing?
It’s even more embarrassing to admit that the endgame book spent little to no time discussing how to build in quality. I think early on in the book I spoke to this as a focus. Meaning –
The context of the book is from within the endgame. Assuming we are part of a project team and have been handed the first QA-ready version of that software, our goal is to get it ready for release. We have to live with the quality proposition of the software – as delivered.
But just because I added that caveat, it doesn’t give me a pass for not focusing more on delivering quality products BEFORE you start to test.
And yes, there was some agile thinking
Now before you go off and get upset with me for the lack of agile thinking in the book, I must defend myself. At least a little.
I did talk about leveraging some of the dynamics from Scrum for “managing” the endgame. Daily stand-ups were a commonplace way to coordinate the endgame. I even shared an example of a project team of ~75 people where we had a daily standup for 2-3 months. And we did it in less than 30 minutes each day. Can you imagine?
And even more interesting, when we did the retrospective for the project, the agile parts were identified as THE critical factors for our success.
Things I wished I would have explored…
Upon reflection, I think I should have explored agile techniques more in the book. Yes, I did a bit of that, but I was overwhelmed by my Waterfall experience at the time. I’ll blame a large part of that on Lucent.
Another gap was a focus on the role of leadership. Again, I did explore it, but over time I feel that effective and balanced leadership is key to software projects. Leadership where you engage, listen to, protect, and empower your teams.
And one final regret. I set my context for the book at the HANDOFF from development to QA in the Waterfall process. That WAS the Endgame. And I spent little/no time looking at the project flow before that hand-off. While that was a solid premise for the book, it really wasn’t helpful from a project success perspective.
Early engagement should be a part of the Endgame planning!
Wrapping Up
I don’t recommend Endgames much anymore for people to read. The lifecycles and tempos have changed so much that I don’t think there’s sufficient value. From that point of view then, it hasn’t stood the test of time.
However, at the time, I feel it was a breakthrough book on a topic that virtually nobody was talking about. And an area where projects continuously struggled.
In the end, I’m quite proud of the book and the impact it has made. But, if you’ve been thinking – will there be a 2’nd Edition? The answer is no.
Stay agile my friends!
Bob.