Committed to Forecasting: How Scrum & Kanban can play nicely together


Every Scrum Master worth their salt should be able to describe the momentous event that occurred back in 2011AD.... 

Scrum's "Immutable Rules" changed!


In 2011, the Sprint Backlog Items transitioned from a firm "Commitment" to a mere "Forecast."
"So what?" might be the response.

Well, here's the crucial thing: The Sprint Backlog never was that important - satisfying the Sprint Goal was the objective - with the change to Forecasting went the last vestige of excuse for followers of Kanban to decry the inflexibility of Scrum's Sprints.

Although, at the time, the intention was primarily to negate the perverse incentives created by Management pressure for completing all the Items in the Sprint Backlog. For Development Teams with such Managers, the only rational response was either to cut corners with the quality of the code (accruing Technical Debt during the Sprint), or to pair extreme pessimism with Parkinson's-Law and add a bit of a 'Safety Margin' (during Sprint Planning).

However, this simple change to the Rule Book - the move to forecasting - opened up the possibility of fusing Scrum seamlessly with Kanban. Let me give you an example with weather forecasting:

Now we could use a dedicated computer system, employing numerous sophisticated algorithms, churning through masses of data, trying to bring confidence and sense from the chaos...Or we could just stick our head out of the window.

Which is likely to be more accurate?

Well, if the range of the forecast is quite long, the odds are with the computer; however, for a short-range forecast, there probably isn't going to be a lot in it. (Particularly when the level of precision required isn't much more than, "Do I need to take an umbrella with me, or are my shorts & T-Shirt enough?")

"But isn't Kanban simpler than Scrum?"

Simpler, yes, in terms of what is mandated. But is simplicity the object of the administrative exercise? Or is it the effectiveness and efficiency of the whole Development process? Scrum events are famous for deleting extraneous meetings from the calendar; these events can also lend a natural cadence to Kanban which does it no harm, and often bring a lot of benefit.

Now I've worked in the past with Teams employing a 'pure' form of Kanban (the sequential, almost Waterfall- style of "New", "Ready for Dev", "In Dev", "Ready for Testing", "In Testing" and then "Done" etc.), and then with the Eric-Brechner form of Kanban (where the Backlog Item is pulled in and then broken down into Sub-Tasks, which can then be worked upon in parallel). We did both for 6 months and, as good as they were - without the Scrum events and regular feedback from Stakeholders - the approach began to feel relentless, like a 'Death March.'

"Oh, but we don't have the time to do Sprint Planning!" 

Really? So you don't have time to give the people who pay your salary any kind of expectation about what their money will buy? Just expect them to sign that blank cheque and leave you alone? (You don't think they'll hassle you for status updates, thereby taking time out of your day?)

Pro-Tip: If Sprint Planning is taking too long, try Refining your Product Backlog to a higher standard. (The unofficial Scrum artefact, the "Definition of Ready", may well help here.)

It literally takes no more than a few seconds to look at an ordered Product Backlog and hazard a guess as to which point you think you will reach by the end of an iteration.

"But we couldn't possibly plan what we're going to do today, let alone tomorrow, or the next fortnight!"

If your job is responding moment by moment to support calls and, at the start of any given day, you have no clue as to what you'll be working upon, then, yes, working from the top of a Product Backlog (rather from a Sprint Backlog) sounds like a sensible idea.

But for regular Software Development?

The inconvenience caused from frequently clashes between ad-hoc, impromptu work and the Sprint Backlog is just Scrum trying to tell you something.

Frequent interruptions from broken Production Code is indication of a problem with your Development Processes, your Deployment Process, and/or your Testing/Quality Assurance. Whilst shifting Business Priorities might suggestion an over-long iteration length, or a breakdown in communication between different parties in the Business, or of a simple lack of training.

Pro-Tip: Try improving the both parts of your Sprint Reviews
  • Part 1) Demonstrate the working increment of software to Stakeholders, Users, Clients and Customers - and take their feedback.
  • Part 2) Show the current Product Backlog and the work expected to be worked upon in the next Sprint. This publicly highlights any difference of opinion between the Business people and their Priorities for upcoming work BEFORE the work is started by the Development Team.

"Responding to Change over Following a Plan" is straight out of the Agile Manifesto. But it doesn't mean that you begin with no Plan at all!


Location: England, UK

Comments

Post a Comment

Popular posts from this blog

Little's shopping basket

Image
We've all been there. Waiting. Waiting. Looking at the queue ahead of us. Waiting. Glancing at our watches. Wondering when we're going to get our turn... In the 1960s, Dr. John Little famously provided the Mathematical proof for the following helpful formula (which later became known as Little's Law). L = ⅄W Where, in this instance: L is the average number of customers at the checkout. W is the average time the customer waits. ⅄   is the average rate of new arrivals. Now, crucially, in a stable system - where no customers are created or destroyed on their way through the checkout process(!) - the Departure rate will equal the Arrival rate. Therefore, in a stable system, we can happily equate these to queuing theory terms. Such that: L ≡ average W.I.P. (Work in Process) W ≡ average Cycle time ⅄ ≡ average Throughput E.g. if there are 5 of us queuing at the checkout, 4 people ahead of us, and the cashier is processing on average 1 person every 2 min...
Read more

CFDs – What does "Good" look like?

Image
Is the Cumulative Flow Diagram the most unloved and misunderstood tool in the Lean-Agile Toolbox? Despite its decorative colours and inherent simplicity, I think it might be. I too often see struggling Developers and Agile Coaches not even noticing that the shape of their CFD is visibly describing to them the effects of team and organisational dysfunction. I'm left to conclude that they don't have a mental model of what "Good" might look like. So let me take you on a little tour, a simplified '3-bin' (3-state) version of the ideal CFD, and help you see what I can see... NB: In these two examples, I shall assume it to be a Stable System ; that the Backlog Items are of equally small size; that the capacity and efficiency of the team remains constant; and that there is a steady, FIFO demand for work the team performs. Defining the 3 states: "New" – Items waiting in the Product Backlog. "Active" – Items being worked upon by th...
Read more

Inconvenient Metrics – Part 1 – The 5 Psychological Coping Mechanisms

Image
In a Lean-Agile environment, we're continuously trying to improve the product development and delivery processes, and, to that end, as William Edwards  Deming once famously quipped: "Without data, you're just another person with an opinion." So, one might imagine that most fair-minded people would be only too happy to inform their judgement by means of empirical evidence (especially since Lean-Agile provides us with so much of it!). But, in truth, when sub-par statistics, metrics or KPIs are presented to an uninitiated audience, the resulting levels of ' Cognitive Dissonance ' and ' Mental Gymnastics ' can sometimes be quite surprising! I n my experience - ignoring complete  'non-sequiturs' - t here is usually a retort which takes the form of 1 of  5 Psychological 'Coping Mechanisms': A claim of Inaccuracy A claim of Unrepresentativeness . A claim of External fault . A claim of Irrelevance . Or a claim of Sheer hopelessne...
Read more