“You don’t have to see the whole staircase. Just take the first step.”
Martin Luther King
The third in a three-part series; I’ve given the context to Lean through lean manufacturing, I’ve condensed the Lean principles to give you a flavour of lean thinking, so now it’s time to introduce some practical, thinking tools for us to consider and help us apply Lean to what we do.
I sometimes get told that Agile is good (glad to hear it) but it’s not practical or it’s not realistic to where we are, so I hope to address that in part with this blog. We need to remember that principles look to guide us, not tell us what to do. Practices are what you do to carry out principles and need to be translated so that they fit the environment, Eagle Eye in our case.
Below are ten practical areas where I believe lean thinking could make a difference at Eagle Eye. Like most things, the power of many trumps the power of one so hopefully this is just a starting point for us. There will be as many questions as answers in this blog. I’m not prescribing how to do something, nor should I. I want to draw some awareness to things we could try if we wanted to explore Lean further.
I shall exert some literary licence and consider that the leadership team are on board for the lean journey. Because that is exactly where we should start …
Lean Principles: Optimise the whole, amplify learning, build integrity in
Audience: The executive team
The first and the most important thing to establish would be whether we, as an organisation are ready for Lean? Do we have the openness and transparency across departments and from the top down to support lean thinking and lean initiatives? Many organisations aren’t ready for Lean and that is neither good nor bad, it just is. When push comes to shove, the company is content operating as they are. Maybe it’s not the right time, we can’t see how Lean could help us clearly enough or there’s too many other initiatives underway.
Some things to consider here in making the decision
Because a lot of Lean centres on organisational change, making it work will be easier if we have the support from our executive team. If we don’t, we can still apply some lean thinking and practices however the impact will be reduced, and the effort involved will be greater. It’s the difference between making an engine performant and leaving the rest of the car as it is with the result that the car won’t go as fast as it could.
Lean Principles: Optimise the whole, eliminate waste, build integrity in
Audience: Everyone
My journey with Lean started with waste, and that’s a good place to start. Whatever you’re doing, there’s likely something with the seven / eight types of waste that will resonate with you. So, there’s a blog on waste you could look at, or I’ll happily run a session with anyone or any team who wants to know more about waste or Lean. Because lots of us are working in Agile ways which consider lean thinking, we should want to learn more.
If we know more about the types of waste, maybe we start to have better quality conversations around waste in our world. Maybe we devote more focused time in our Agile events to talk about the specific types of waste. We already do this to a degree, but explicitly mentioning task switching or waiting for example and looking to measure its impact on you and your teams can be a valuable thing to do. Identify a type of waste which slows us down, a plan to tackle it and measure how you get on. Then tell us about it.
I often have to wait on things. I am an impatient person, so it frustrates me seeing examples of the waiting waste in action, and how that slows us down. I could have got these blogs out weeks before if I didn’t have to wait so long. And so in the end I pushed it because I think it’s important to do so and the timing feels right.
Lean Principles: Optimise the whole, eliminate waste, build integrity in
Audience: The exec initially because of the representation across the business
Now we know more about waste, we can do a value stream mapping exercise so that we can better see waste in our world. Map out the time from a customer’s request to completion of the work, and then consider the amount of time that is value added activity. It should take an hour of your time as a collective, and I can facilitate the session. It would be my first value stream mapping exercise.
Source: a photograph from Lean Software Development
Once we’ve done the exercise, we should be able to see our waste more clearly. Would all our projects have a similar map? There are two questions this exercise will help us to address
Hopefully, we start by identifying our biggest source of waste and look to cut it in half.
In the book Lean Software Development, they look at a traditional project, that same project under Agile practices and consider that we could cut 75% of the waste out of a project. So that's delivering that 2 year project in 6 months. Hope that got your attention.
Lean Principles: Amplify learning, empower the team, build integrity in
Audience: Everyone
What are we doing to support, coach and grow the teams and individuals? That’s a question for our executive team and beyond. I think our executive team know that the expectations from an executive has changed. Execs need to steer, direct and lead but they also need to support, coach and grow the teams. And I think our exec understand that and are working towards the same.
A Gemba walk is a walk around the office (remember that place) usually by the exec and managers to get a better view and feel of how we’re doing at the ground level. What are people doing, what motivates them, what hinders them and what can you / we do to help?
Beyond shared consciousness, listening and camaraderie this can also be a useful way of gathering new information, getting a temperature of how people are feeling and identifying common problems. This creates a sense of community, a sense of oneness, a sense of belonging. So, when we can again, let’s see more of our managers and our exec and maybe even our Agile Coach walking around the office. An alternative could be dipping into more meetings from time to time, in case the office is now a distant memory.
In the book Trillion Dollar Coach, the authors explain how Bill Campbell, then coach to several executives at Silicon Valley took the time to get to know his mentees, their families and some of the things he did to build loyalty and trust with them.
When one of his mentee’s partner had a serious accident, he got them on a plane to be with them. He organised big socials including Superbowl weekends each year which he continued to subsidise from beyond the grave. Meetings would start with the personal touch first, rather than jump straight in. Maybe something to consider there. We spend a lot of time with each other, maybe we should get to know one another better, and we’ll be better of for it.
Beyond a walk around the office, a walk can be good for all of us. A walk to clear the head, to think or to switch off for a while, to breathe and take a breath.
Lean Principles: Amplify learning, deliver as fast as possible, empower the team
Audience: Teams
Bastardising Richard Ashcroft’s “Music is Power”, in the software space information is power, or more accurately the generation of new information is power. What can we do to generate new information and knowledge in the quickest amount of time?
Maybe that’s Operation Speedboat, looking to deliver a feature as quickly as possible to generate information as quickly as possible and then refine the feature with the new information gathered. Maybe that’s a hackathon to prove that conceptually something could work. Or tackle the highest risk areas first. Or address the big questions first through a prototype.
When we generate new information early on, we become more informed, more in control, more knowledgeable and better able to predict the future. We can delay decisions and manage risk better. When we are more informed, we are more in control and can make better and more autonomous decisions, which has a motivating effect on people and teams. Maybe that’s worth thinking on the next time we get that requirement / problem to solve.
And the flip side of this statement is if there’s stuff we do that doesn’t give us new information, then it’s a candidate to get rid of as a form of waste. If we run some tests that pass every time, and it’s been that way for the past year, what insight or information is that providing us?
Lean Principles: Amplify learning, decide as late as possible, deliver as fast as possible, empower the team, build integrity in
Audience: Everyone
When writing this blog, I first thought of segmenting it by organisational, teams and across team practices. I then thought about listing the principles and the practices relating to them. In the end I mixed my options up and I think it is better for it. That’s the benefit of keeping your options open, hopefully you make better decisions and deliver a better outcome as a result.
Do a trial whereby on the next feature or request that comes into the team, you look to keep your options open for as long as possible. Don’t make irreversible decisions by making no decision at all. Now, we aren’t talking about procrastination, we are talking about taking a different approach to tackling a problem, one which may reduce risk down the line, result in a better solution and make future work easier. I think that’s smart.
Extend this idea out to problem solving as a team and rather than limiting your options early, come up with three options and explore each of them at the same time. Converge at some point and pull the best parts from each option or go with the best option. Would this have been the option you’d have chosen from the offset? Is there value to be gained from a breadth first approach to problem solving whereby you keep your options open? Is the solution which evolved better working in this way?
Take advantage of the power of many, and if you identify yourself as someone who goes down a path too quickly, look to pair with someone who exhibits a breadth approach to their work. Consider this with new members of the team or those with less experience as they will be more inclined to jump in.
Lean Principles: Eliminate waste, amplify learning, deliver as fast as possible, build integrity in
Audience: Everyone
Feedback is good, however timely and quick feedback is better! We want feedback opportunities; it helps us to learn and improve. Agile bakes in feedback moments as it knows its importance. Learn that feedback is best done during, not at the end of something. And that it should involve the people who participated. If you’re not having reviews, then consider what you’re missing by not having them. And remember that this extends beyond those working with Agile, project reviews can and should be taking place and why wait to the end of the project to do so … that’s too late!
It’s a fallacy in my opinion to think that we don’t have time to do reviews … do we have the time not to do them?
Lean Principles: Optimise the whole, empower the team, build integrity in
Audience: Everyone
Oh no, not this one again. But it matters, so why not keep beating the drum. At an organisational level this is a goal which everyone gets and buys into and one that they can easily recite and connect to … we can see how our daily work influences the goal. At a team level this may be hitting service level agreements (SLA’s) or completing your mission for the quarter. At an individual level, it may be developing and growing as you had intended.
I think there’s work here to make sure that these various purposes are more rounded, grounded and founded (sorry, I couldn’t resist the rhyming) so that they all pull in the same direction. Maybe we need some early exposure and a few iterations of the company goal before it gets nailed down next time.
There’s probably a more subtle thing we can do here; work on our standards and look to define a common language amongst the organisation; and at the risk of upsetting a wide majority of my audience that language should be our customers' language.
Lean Principles: Optimise the whole, empower the team, build integrity in
Audience: Everyone
We all want what is fair, we all want what is best for the company, we all want to be heard and listened to. But are we all playing on the same playing field? Are things balanced correctly for continuous growth, fast delivery, empowerment for example. I spend most of my time with engineers, and I probably don’t spend enough time with them as well, but I mention that here as there may be some bias in the below. If I spent more time with Delivery or Finance maybe I’d have a different slant, but I don’t. Maybe I should, I’d like to.
There are some things we’ve been looking at recently, such as tech debt and some longer running initiatives which have stalled. We keep churning out more and more new features for our clients. And we should, however we are making it harder to do so by not addressing the things that could improve our lives or building on top of something that we did in a rush. There’s a vicious cycle here we should address, and it’s to our advantage to do so.
I read that looking at tech debt should be roughly 20-30% of your time. We give it 10% as stands, and the reality is it’s not likely even that. So, we’ll try and set that straight, look to address the balance if we can. Why does this matter? Because you can’t go fast with tech debt, you go slower as the debt mounts. And because we have the tools to make our lives easier, we need to spend the time getting them in place and taking advantage of them. Continued investment in refactoring and automation and smarter ways to do things pays.
Lean Principles: Optimise the whole, eliminate waste, deliver as fast as possible, build integrity in
Audience: Everyone
There is a lot to be said of thinking of the organisation as a system. It stops us from being blinkered and concentrated too much on our own worlds. Let’s just consider this for a moment. An objective for sales and an objective for engineering may not align. Worse, they may clash. And that could mean that we are ultimately prioritising the wrong things or pulling in different directions.
In Managing the Design Factory, Donald Reinertsen encourages us to think of the organisation as a system, with inputs and outputs and a black box in between. The output is profit as a rule in most organisations. The inputs in our world would be requirements, schedules, resources, costs etc. But the black box, what and how we deal with the inputs should be for the company and the teams to decide. The book went as far as suggesting a finance person on each team and budgets for teams as a means of empowering the teams. Now that may a step too far, however it’s an interesting concept.
Are our contracts with clients putting us into a partnership with the customer? Where we collaborate and coordinate with our customers. Are we selling Agile to our customers, given that that is how we deliver? And are we synchronised with our customers? If we have pulled out all the stops to get a piece of development work done, why does it sometimes sit there for a time before we receive any feedback? What effect do you think that has on people who have worked so hard to hit a milestone, hit it and our efficiency picking it up again after the delay? These are honest questions we need to start asking ourselves more regularly if we want to improve.
Systems thinking can help us in more subtle ways. It can help us to think clearer and consider the whole more often. I also think it can remove emotion from some difficult discussions, meaning we have better conversations. There is a difference in pushing work on people and people pulling work when it is needed. If you maximise capacity at 100% you will get queues, so don’t and factor in some contingency. Consider smaller batch sizes of work, be that smaller items of work (smaller tickets) or less work in the quarter. If you need a project tracking system that is a symptom of too much work being in the system.
If we have created a system which says this is a Priority 1 issue, stop what you’re doing and work on this instead – guess what, that’s directly introducing context switching, a form of waste and we’ll waste time, so maybe we need to reconsider that part of our system. And if we have a system that requires permission to deploy something, consider how that sits alongside the principles of empower the team or deliver as fast as possible.
It probably pays to look at the whole system more regularly and often, whether it is working for us, why not and what changes we can make so that it serves us all better. Use our learning cycles from sprint and knowledge gained of the system to improve it continuously. And remember here, because I think it’s important, we are not thinking of a sub system here, we are thinking of the whole or the organisation system as that is where we'll likely make the biggest gains.
Lean, and indeed any form of Agile needs organisation buy-in and commitment, especially support from the people with the cash and means to make real change happen. There’s so much good stuff in Lean, relevant to where we are currently operating and with practical advice to the problems that we face that I hope we give this some serious thought.
That is the crux of what this series of blogs has been about. I hope to get an invite to some sessions soon, I hope that my P45 is not in the post, I hope I have stirred something in you all, I hope you have enjoyed the series as much as I have gained from writing them and I hope you are all eager to learn more, or inspired to try out some lean practices yourselves.
The above are some practical steps we can take, if we choose to, if we decide we want to and which we ideally take as an organisation to make a difference, decide, change, try something, see how it works, get curious, answer the big questions and so on as we seek change to improve our lives and the health of the organisation.
But no one is going to serve you Agile or Lean on a platter, we need to take the first or the next step or steps, and it will be better if we take that step together as an organisation.
Lean Software Development: An Agile Toolkit, Mary and Tom Poppendieck, 2003
Managing the Design Factory: A Product Developers Tool kit, Donald G. Reinertsen, 1997
Trillion Dollar Coach, Eric Schmidt, Donald Rosenberg, Alan Eagle, 2019
https://www.infoworld.com/article/3309258/5-best-practices-to-measure-and-manage-technical-debt.html
https://enterprisersproject.com/article/2020/7/technical-debt-how-measure
Stairs image sourced from https://toppng.com/wallpaper/stairs-steps-backlight-dark-blue-purple/449453
6 min read
Craig Rogers on Mar 5, 2021 10:25:00 AM
source: https://www.deviantart.com/mindgem/art/Graffiti-piece-Waste-91909811 Elimination of these seven kinds of waste can help companies reduce...
7 min read
Craig Sefton on Aug 10, 2020 12:10:00 PM
Anyone who has spent any time programming knows the truth in how difficult it is to name things. There’s a classic quote from Phil Karlton that most...
5 min read
John Durrant on Dec 15, 2020 3:37:00 PM
I am excited to announce that the Engineering and Technical teams at Eagle Eye will be publishing some of our non-proprietary software components and...
