This article uses a department’s entertainment budget as a simple way to explain how the principle of decentralised decision-making should be applied at the team level. What’s more, you can expect teams to communicate and function better when it’s applied correctly.
My very simple definition of the difference between output and outcome is:
Output is delivering volume
Outcome is delivering value
Theoretically, they could be the same but in practice this is seldom the case.
I can create a lot of ‘stuff’ (i.e. output) but realise very little, or even negative, value for all the time and effort spent producing said ‘stuff’. This article provides two practical examples of what normally happens (we focus only the output), why this is a terrible practice and the problems associated with ignoring the outcomes. Continue reading “Outcomes: The Forgotten Test Case”
Ron Kohavi was the Technical Fellow and VP of the Analysis & Experimentation team at Microsoft. He had a team of brilliant engineers, data scientists and program managers working under him. Kohavi’s team built Microsoft’s “Experimentation Platform.” Before the Experimentation Platform was in use, Microsoft teams were delivering well-thought out features, some small, others larger multi-month projects. Output was great – and Microsoft products like Bing, Edge, Exchange, Office, Skype, Windows, and Xbox were benefitting from the exceptional work produced.
I was asked to submit a “Running Mann-style” presentation for the Business Agility Africa conference. The accepted topic was, “What the Comrades Marathon tells you about Agile Transformations” and ended up being the final of 21 presentations from speakers representing 6 countries.
Before the presentation, several of the 170 delegates asked, “How the hell do you relate Comrades to agile transformations?” After the presentation, they were left in no doubt! The presentation combines stats and stories from the great ultra running event on the planet – and I even managed to work in “The Agile Running Mannifesto!” Continue reading “What the Comrades Marathon tells you about Agile Transformations”
Where We Were: 12 Months to Deliver a Small Feature
The graphic below is an example of a feature that previously took 12 months to deliver when we were working waterfall. This was the typical cycle-time for a small feature. Larger features would usually take over two years to flow through the system. With agile, we would now expect this same feature to be complete in a two week sprint. This article provides the six main reasons for the massive cycle-time reduction.
Instead of making up-front decisions based on assumptions and imperfect knowledge we create hypotheses and run a series of experiments to determine whether each hypothesis is true or false. The results determine what we should stop doing, start doing and continue doing. Based on complexity, uncertainty and rapidly changing environments, most software development projects are “research and development” exercises ideally suited to this hypothesis-based approach. Continue reading “Using Hypothesis Statements for Features in Software Development”