There are many definitions for Lean, we have found that a focus on Flow to be the simplest and more effective way of introducing Lean principles into teams. With visualisation, the flow of work can be easily seen and when you can see how work flows through a team and even better, the organisation, you can start to remove waits and obstacles and really get that value to flow.
We use Kanban, Agile and Feature teams. Not all our teams are in the new Agile and Feature team space, which is where using Kanban concepts and questions that focus the team on how their work moves, what they need to get their work done and who they wait for, can be a powerful tool.
What do the teams understand by Flow ? How do they fit into the overall flow of value in the organisation ? How could they visualise flow ?
Blog Posts on Flow
So here we sit, the team and I – with a lovely Kanban board with queues and flow and everything we need to stop starting and start finishing – only it doesn’t seem to be working smoothly. So I turn up my listening and there, hidden beneath the words is something really interesting – we keep on coming back to change!
We can’t start testing because there are changes still coming. What changes ? Where are they ? Are they important ? Who are they important to ? Where are they coming from ?
Turns out, we don’t really know! Which means we don’t really know when to stop working on this set of use cases and start to work on new one’s because the way we have always worked is to go round and round, perfecting the use case, adding changes no matter where they come from, no matter how valueless they might be.
I can see how this is created – if you can’t see what is next up why would you finish what you have right now ? If you can’t see how much is left to be done and what absolutely has to be done, why stop working on what you have right now ? We have created a culture where teams need to be busy, they need to be billable.
After 10 months of analysis the team and the business still don’t really know what they want. After 20 years in software development I am not really surprised, because invariably you find out what is needed when you build it and start to use it – which is a problem in waterfall, because that is when you are out of time and money.
So what now ? Well now we create a mechanism where we can get clarity on what is needed and what is valuable. We get to explore grooming of the backlog and risk profiles (thanks David Anderson) and I can’t wait to see what happens.
I am already imagining a team where delivery happens on stable, clear features that have been selected in the last week or two by the business, where everyone can see why these have been selected and can see what needs to still be done to build a product that now only delights customers, but Wows them and allows us to steal customers. A space where change is embraced and welcomed and we are delivering value to customers frequently.
What techniques are you using to get that infinite, ever changing backlog under control ? How are your teams choosing between features and replenishing their delivery flows ?
One of the interesting observations coming out in a new engagement is how teams define done, in particular how a waterfall team defines DONE and how an Agile/ Kanban system defines done!
Within waterfall we are done when we get to the end of the project. Testing gives us a list of things that aren’t working, we then fix those and keep going until we either remove all the bugs or we finish the official testing period. During this time change requests probably come in from the front of the flow through analysis with the end result that the team is never really done. There is a hidden expectation for the team that they never stop working on something, so when asked, what is in the next iteration, the answer can be, updating what we have already done!
This has some interesting consequences when a team decides to shift into sprints/ Kanban continuous flow because the goal here is to FINISH work before starting something else and for me, that implies that not all issues uncovered in testing will be taken as new work, some of it may go into backlog.
This seems to be a rather uncomfortable reality for teams who have been embedded in what I am calling waterfall thinking.
Can you get flow if you don’t stop working on something ?
Isn’t that the definition of flow, that we start something and finish it and then start something else ?
How have you managed this in your world ?
Yes, I am reading again (or is it still 🙂 ), this time Gemba Walks by Jim Womack. We were having a debate the other day about what Lean is – with one strong voice leading with “Lean is the elimination of waste” (not my definition btw, I prefer using “Lean creates flow of value through the company and permanently removes obstacles and blockers from the system”).
But back to waste, if you do subscribe to the view that Lean and waste removal are synonymous then this might interest you, an essay from Jim Womack entitled Mura (Waste/ non-value add activity) , Muri (uneven demand) or Muda (overburden) (click here to read it).
One of the first questions I ask when I am standing at a new visualisation is, “What or who are you waiting for ? ” Because I often can’t tell, especially where teams have adopted a generic Kanban that shows ‘To Do’, ‘Busy’ and ‘Done’. The teams often fall into the trap of relaxing as they are ‘doing Kanban’, only they aren’t showing where they are in the ‘Done’ and that is part of the point – to be able to see where and why flow is sluggish and or blocked.
I am coming to the conclusion that perhaps not! When I think about visualisation, I think about turning data into something that can be translated (without thought) into meaning! I think about thermometers and colour and images that convey meaning. I see my cars petrol gauge, rather than a digital number.
When I engage with individuals and teams what we end up talking about is numbers and words – all of which require the brain to ‘think’ about the information and interpret it. The problem here is that numbers mean different things to different people. I have 20l left in my petrol tank – is that good or is that bad ? How far can I get ?
As our company shifts out of the formalized process era into a more Agile, Kanban, Lean space I have started to notice a reliance on process itself. The change we are generating is a process one as well as a cultural one and relies on a shift from unilateral control leadership (command and control, hierarchical, the land of the hero developer and the problem solving manager who save the day) to facilitative leadership, where teams have autonomy and permission to make decisions. The problem is, the process! Where is it ?
Time and time again as a coach I get either asked what does Agile say (which is impossible to answer as Agile is conceptual and not a process, however Scrum is a process ) and if I answer along the lines of, “What would work for you ?” Or even better, “Does that make sense ? ” Or wait, the scary one, “How come you are doing that, where is the value ? ” People panic! They want a process, they want surety and safety, they want the process to make decisions for them…..which are all symptoms of unilateral command leadership.
I have started to wonder if Process isn’t just another form of command and control? An insidious one as we don’t even see it as taking away our freedom, whereas we quickly spot a tyrannical leader. I noticed this diving, especially when I started to do more unusual dives, where the ‘process’ didn’t really fit, but as it was the way we did things, that is how people judged competence. The problem is, to dive a new site or in my case, to a depth never dived before by a woman and only a handful of times by men, you can’t use the process that gets you to 30m and back. You can barely use the process that got you to 186m and back because deep underwater, process sticks you into a sequence of reactions that may not be at all suitable for what is actually happening and because you are following the process, you don’t think, you just follow. In a deep dive, if you can’t work from principle and in the moment you can’t adapt and so you die.
We may not see the world of business or indeed banking as a world of explorers but what if they were more similar than not ? We live in a world that changes, fast, to the point where the process we used last month to solve a problem or achieve results probably won’t now. The more I think about it the more I can’t but help see Process is a trap. It is command and control as it takes away a team’s ability to think for themselves and make decisions for th selves and even worse than when this unilateral control is sitting with a person, it places it into the hands of no person! There is no one to argue with or debate with and no easy way to get the process changed, mostly because no one really knows why the process exists so they don’t how how to change it safely. So you are stuck, following the process, not thinking, adapting or learning, waiting for the process to somehow evolve, blameless of course.
Yes process has its place, without it divers wouldn’t now be able to successfully repeat 100m dives….but that is just it. Process allows you to repeat and follow, it doesn’t easily allow for new. So for now I will be following ‘no process’ and seeing what happens when people learn how to see their world and so build the process they need now….and then throw it away when they see things change and build a brand new one, custom fitted for where they are now.
Have you noticed how most initiatives in flow and agility focus exclusively on new processes and skills ? Have you also noticed how the people use these ? In the same way they used the last lot of processes and so we get so,e change, but mostly we are now just wrapping the old process in new paper.
People create flow! Yes, processes help! A bad process will hinder flow and stall it, but there is always that handful of ‘go to’ people who somehow get it to work. Note I said people, not a go to process.
Shifting from a traditions, resource optimization culture to a capacity driven one is a big deal. It means stopping answering the question, “How long will it take ?” Yes! Stopping answering! Because every time you answer you keep yourself locked into a viscous spiral that seldom (if ever?) has a positive outcome. Only you have to answer right ? Because the person asking is meaner and more powerful and a whole host of nasty things will happen if you change your answer to, ‘well, it looks like the effort is around 8 story points which is quite high and we are currently able to manage 12 story points a sprint. Do you want to prioritize this for the next sprint ?”, which for the person asking isn’t an answer at all!
Whenever I suggest this as an option the room goes quiet and the discomfort and anxiety levels shoot up. I mean, how dare I be so, well rude and brazen ? How dare you not be ? Your job is to deliver reliably and predictably, yes ? You like delivering and being competent! You like being proud of who you are and your work, yes ? Well then, how can you not change how you answer ?
If you look back over your last year, how often where you able to accurately get that number right ? How often where you able to predict the work that was unknown or the hidden dependencies or the new work that would arrive ? More likely, over the last year you haven’t managed to hit that number once and into the deadly spiral you have dropped… being beaten with the delivery stick until you and everyone else knows how useless you are!
So what if you starting answering that question differently? Instead of spending hours and anxiety minutes on finding an accurate number, start answering in terms of capacity and shift the onus on prioritizing to the business – it is after all their primary responsibility!
What if YOU are the culture!? Which would mean you make a doffer nice – you are either reinforcing the culture or changing it.
And … what if all it takes is changing how you are showing up?
We think that for things to change management needs to change, but what if all it took was something as small as refusing to answer the question, “how long will it take?”
Elements of Flow
When showing flow, show the handovers – these are the places where time and work get lost…waiting for Joe in Testing or Annie in Requirements to come back to me…and we wait!
The simplest way to show flow is to show it Kanban style. Kanban has some key elements, restricting the Work in Progress is one, the other is to show the queues and so allow the team to pull as they are ready. The power of this is that you can see where the work is piling up and you stop having to hand out work on a daily basis, it is all there.