I don’t know completely. Yet.
For those who don’t know the book “The four disciplines of execution”, it defines a process consisting of the following elements:
1. Have 1 or at most 2 Wildly Important Goals (WIGs) – in a measurable way (Lag Measures: from X to Y by when) [focus]
2. Act on Lead Measures (stuff within your team’s circle of influence that’s connected to Lag Measures and can move you towards achieving the WIGs) [leverage]
3. Keep a compelling scoreboard (as you measure everything, you can have a large and simple display where everyone can see in a moment whether the team is winning or losing) [engagement]
4. Create a cadence of accountability (weekly meetings where the team makes sure things go in the right direction) [accountability]
I’ve read the book because I heard about a software company using this method. However, as none of the examples in the book are from the software industry or even anything close to it, I have big question marks in my head. I have this strange feeling because my strong belief has been so far (based on lots of experience) that you cannot reliably measure success of software engineering activities in quantitative ways due to the complexity and chaotic nature of this business. It’s too easy to do tricks. For example, if the KPI is to produce more features in a given period, you split the features to smaller pieces and you’re OK. If the goal is large unit test coverage, you create a big bunch of useless unit tests quickly and the KPI score is happy again.
Probably I haven’t tried hard enough. Although I still think that the notion of success in software engineering is a very complex combination of crisis management, customer diplomacy, internal politics and a lot more factors (including pure luck), I believe that agile processes and practices help a lot in making it manageable, and I want to believe that continuous improvement is possible, including measuring this improvement by numbers.
By the way, all the rest of the 4dx method is fantastic: accountability via regular meetings is already given in agile processes, while focus and leverage are concepts that I could learn a lot about from this book that I’m completely sure I’ll be able to use in my work.
Back to the measurement thing, I honestly wonder how this would work in software engineering context. I’ve just learned about a book titled “Software by Numbers” and it’s come close to top of my reading list.