How a Product Team is improving value delivery rate with Kanban

Here are my slides from #lkuk14. Full video available soon from Lean Kanban UK.

Care about business strategy? - Tune to this channel...

If you think the principles and values of agile extend beyond the narrow boundaries of software development teams to organisations and corporate cultures, I think, like me, you'll be inspired by a couple of presentations from the recent Agile On The Beach conference, They are great bedtime viewing (for when you've finally had enough of Bakeoff!).

Firstly a video from Tom Sedge: TDD for Business Strategies – Developing Business Strategies Test-First.

Tom Sedge provides very practical advice on how to define mission (why we're here - our purpose and driving cause), vision (where we're heading - how the world will be different), goals (what we want - destinations or desired outcomes), and strategies (how we will get there - potential routes to the destination). His examples of good (Tesla, SpaceX) and bad (Kodak) missions/visions are particularly helpful. How could the inventor of the digital camera go bust, just as digital photography exploded on scene, particularly as their founder George Eastman expressed his vision in the 1880's as "a world where the camera is as convenient as the pencil". These days I quite often wish I had a pencil on me, yet I always have a camera! His vision makes a sad contrast with Kodak's mission and vision statement from the early 2000's - a paragraph of unmemorable platitudes about customer focus and shareholder value, that no one outside the company would care a fig about!

The second one is from Bjarte Bogsnes, Vice President of Performance Management Development at the major international oil company, Statoil. It's on Beyond Budgeting – an agile management model for new business and people realities. If you give it a listen you'll understand why (even though I think budgets are essential) I'm not that keen on investing much time in annual budgeting. In his words, the approach "... is about rethinking how we manage organisations in a post-industrial world, where innovative management models represent the only sustainable competitive advantage ... releasing people from the burdens of stifling bureaucracy and suffocating control systems, trusting them with information and giving them time to think, reflect, share, learn and improve."

Remember he's talking about a massive oil company - not the easiest place to introduce agile thinking! Gives hope to the rest of us.

x-Banning a process

I've just proposed an experience paper for LKUK14 - "x-Ban the process! (or how a product team is improving value delivery rate with Kanban)". Feel free to vote for it by the way here!

Scrumban, Xanpan (XP-ban) - even Prince-ban and DSDM-ban - have all been used as portmanteau words to explain the journeys from a particular named process or framework to a continually evolving and improving process, guided by the principles and practices of Kanban. If you are trying to apply a named process but frustrated by a patchy track-record of improvement, consider the alternative: x-Ban it!

When I was asked in early 2013 if I would work with Clearvision's product development team, they had just adopted Scrum (a matter of weeks before). Their process, like most I've reviewed from teams claiming to use Scrum, was not compliant with a large number of Scrum rules. It was pragmatic, constrained, variably applied and ripe for improvement... but it certainly wasn't Scrum. We had two choices - apply Scrum rules as soon as possible (defining the backlog of necessary changes and a timetable to apply them), or “x-Ban” it (use Kanban to attain evolutionary changes that we kept only if we were confident they resulted in improvements). We did the latter.

There are many lessons I've learned from this experience: some things that worked - and some that didn’t. They're lessons and general principles that others can apply on a similar journey. It has taken much longer to adopt some practices than I expected, the current process is quite different than I expected when I started 18 months ago (it’s more Scrum-like now than when I arrived for example!), but it is a route I would recommend to others.

Start x-Banning your process now!

Improving Software Development at Scale: Promise and Pitfalls

Here's my talk from the London Lean Kanban Day 2014. Enjoy!

Not all work "flows"

I've written elsewhere that it's key to focus attention on "Work that Flows" (see Clearvision's blog). That is, work that has a beginning, middle and end (delivery) and some tangible value as the outcome. The thing is not all work does flow. A lot of our time is dedicated to tasks that are simply "overhead". They might be waste - they add no value and serve no useful purpose - but equally they might be necessary activity within the context of how you deliver your work, yet not actually attached to delivery. Project management for example will need to be done for as long as the project lasts - it is not something can be completed independently from the delivery tasks. Sometimes overhead tasks can be removed if the process is changed, but  more often they are a pretty-much immovable feature of the way we work.

I just want to make one point about this - you should know the difference between work that flows and work that doesn't - i.e. overhead work. Don't put overhead tasks on your Scrum or Kanban boards for example. Focus on the work that flows. Whenever you can, eliminate (or minimise) the overhead tasks!