Micro-LEAN: LEAN Without the Bullsh*t

Note: Yes I understand Agile isn’t a framework or methodology, yes I understand LEAN, Agile and Scrum are all completely different things. But that’s not the point of this article so I will refer to all of them interchangeably with little or no regard. Same goes for the difference between a framework and a methodology.

Agile and LEAN have directly and indirectly had a massive impact on how software is developed, allowing us to develop higher quality code, more quickly and at a greatly reduced code. A set of ideas developed by some of the greatest minds in the industry which have all worked wonders within the domain they were designed within and have helped take us to new heights.

The problem, however, is that unless you are employed by the FBI working on their Sentinel project and currently living in 2010, then you are probably not in the same domain that LEAN (software, not the Toyota Way LEAN) was developed for, that’s not to say you’re not in a similar domain, just that you are not in the EXACT same domain. And as for Agile, if you are lucky enough to be working directly in the same team as one of the original signatories of the Agile manifesto (or unlucky enough, based on the tweets of a certain Uncle) then you are probably not in that same domain either. Now that is not to say that none of the concepts carry over, several probably do, and in some situations all might, but that it to say that the chances of every concept in either of those frame being so perfectly applicable to your team that you need 350 pages of detailed instructions and explanations on how, when and why to apply it is SLIM (🤣).

So why do so many of these frameworks exist and how did they become so popular? And more importantly how did all these company develop around them who’s sole purpose is to tell you how to implement it exactly as it was supposedly intended? Well I have a theory which I discuss in the next section, feel free to skip it however as it’s irrelevant to the rest of the post.

THE CONSULTANT’S DILEMMA

Note: Feel free to skip this part, it’s mostly just a rant on some modern day tech consultants

Now here is where the problems begin, you see technology, just like any other industry that sees rapid innovation and knowledge creation, suffer from “The Consultant’s Dilemma”. The consultant’s dilemma is pretty simple, but will go to explain a lot, so bare with me, it also applies to book authors, handsome bloggers and anyone else trying to sell you knowledge. It goes like this:

• In any new industry or knowledge domain that proves to be successful, people and companies will look for consultants to help them implement it.
• To be a respected consultant, you need to be a recognised thought expert in your field and have in-depth knowledge and expertise that is not easily gained or taught
• To have that sort of in-depth knowledge and expertise, you need to have been doing it for a very long time.
• To have been doing it for a very long time, you can’t be within a new industry that has only just been proven itself to be successful and has a very shallow pool of pre-existing knowledge.

And that, is the consultant’s dilemma.

It’s not all doom and gloom however, and if you do decide to become a Silicon Valley tech consultant and ever plan to be able to afford a car with doors that open like this 👋 and not like this 👐, there is a very simple way of getting around it which is guaranteed to get results every time. Create a methodology, framework, or whatever you want to call it, and make it so precise, ridged and over complicated, with so many rules and procedures that it is impossible for anyone else to fully understand it, let alone implement it, and if on the off chance someone does manage to get through the 24 chapters of “insight” you pull out of your a$$ but which you expertly gained from building your start up or improving some company that ended up going bankrupt anyway (but for different reasons, also they didn’t listen enough you see), well then no matter what, they will definitely believe they can see the results of all the hard work you put them through in order to implement it within their own teams, because once someone is committed enough to an idea and has fought to get management buy in, they’ll believe it’s working no matter what, and that’s when you hit them with the $5,000 a day consulting contract! 💥 Welcome to the big leagues my friend.

MICRO-LEAN

No two teams are the same, nor are any two people. It goes without saying that a team consisting of four PhDs working on quantum cryptography might not function in a similar way to a team consisting of 3 senior developers, a hipster and an intern working on an app that helps make your Instagram feed more Instagrammy. Yet we are still being promised these overly complicated and precise tools and frameworks that are meant to somehow cater to everyone, while being given a solution to someone else’s problem.

As such, I believe in using a much simpler framework which I also believe is how LEAN was originally intended, and how it itself was developed. This framework should serve as a basic starting point which you build from organically to fit your own way of working.

The framework is a stripped down version of LEAN. As everything needs a name, I call it micro-LEAN, LEAN without all the handholding, consisting of just the core principles of these frameworks and learnings, and more similar to how we all naturally work, a cycle of Plan, Do, Check, Act. Or put more simply, literally what you’ve been doing your whole life in every area of your life, before being told you needed to formalise the process that limited your ability to change anything.

Before we move onto the framework however, I will first discuss the “principles” and state of mind you should be in before applying it.

Defining The Problem

Before implementing anything, you should first ask yourself what problem you are trying to solve. Implementing something for the sole purpose of implementing it, or thinking it will just magically fix all your problems, is a guaranteed way of reducing your own and your teams productivity. Luckily however, your team definitely has problems, and definitely has room for improvement. If even Toyota, the originator of modern day LEAN is still continuing to improve on a daily basis, then you can be pretty sure you can too, however, everything should still first go through a basic cost/benefit analysis before deciding just how much formality to put around this new effort.

Learn The Techniques and Not the Process

There is still a lot to learn and be taught by reading from other methodologies and points of view, however in most of the original books on the subject of LEAN, there is one key take away, learn from the techniques used to solve the problems, and not from the solution. It’s a point that comes up time and time again in books such as “The Toyota Way to Lean Leadership” by Gary Convis & Jeffrey Liker, two well regarded experts in the field, and in the core principles of the Toyota Production System.

What all these books should provide you with however, is an arsenal of tools you have at your disposal to apply to problem areas that might benefit from them, tools such as the TPS’s 5-whys , retrospectives to formalise problem finding and solving, or using sprints and Kanban boards to arrange your tasks. Again, it’s important to note that the usage of any of these techniques should be evaluated for the problem it is intended to solve, and even if it is found beneficial, it should still regularly be re-evaluated for it’s continued usefulness.

Now for the framework. Micro-LEAN is all about concentrating on the core Plan, Do, Check, Act cycle. It is about concentrating entirely on the continuous improvement cycle, and not letting anything distract from that. As long as you are improving, you are doing better than you were yesterday, and as long as you continue to improve, you will continue to get better. It’s not about a quick fix, it’s not about formalising what works well and what doesn’t, it is about building a team that work well together, and building a process that fits to their individual requirements, talents and strengths, and not about moulding people to fit into your framework.

The first step of Micro-LEAN ironically is, putting in place a formal method of ensuring you are making a continued effort to improve. And Micro-LEAN still consists of 3 main rituals, Improvement Cycles, Retros and Refinements, though in a slightly different context.

The Improvement Cycle

Micro-LEAN consists of cycles very similar to sprints and which can also be aligned with sprints. Rather than a traditional sprint however, there is no limitation on the number of cycles that could be happening simultaneously. An individual can have their own personal daily cycle where they look to improve their own productivity, or 2 team members who work in close proximity to each other could also have a private one, there can also be any number of team wide improvement cycles each designed to tackle a particular problem.

What does matter is that it is held at a pre-determined interval, and that it happens. And that when it does happen there is an action on how the way work is done around subject area of the cycle can be improved. Once such outcomes can no longer be produced, the cycle should stop. There should however always be at least one single team wide cycle.

🗝 A key point of the cycle is that it is held to tackle a problem area. That area might be overall productivity or it might be on how to de-escalate the turf war between the UX Designers and Paddles the poodle, it should however suit the requirements of your team. Different teams have different needs, and will perform best at varying numbers of simultaneous cycles, but most likely, you’ll only need one and it will only be for overall productivity.

The Retro — Starting at the End

In Micro-LEAN, the most important decisions are made at the end of the cycle in a similar way to a traditional retrospective in SCRUM. This is a time when issues are still fresh on everyone’s mind, while also ensuring that it doesn’t interrupt the flow of work. From this, the group should come up with a single issue they wish to tackle and how they wish to go about solving it. There are many techniques and tools for doing this, a good one is the 5-whys, but it is up to every team to decide what works best for them, there is also a wide range of possible solutions you might find in one of the many books on software development methodologies. This is the ideal time to reflect back on them (it is also probably the only time you really should).

Again, it is important to keep in mind the way the the retro sessions is held should be flexible and based around your individual requirements, for some people maybe a slack message is enough, for individuals you might just need a time during the day to reflect back at what when wrong, or you might need to book a meeting room for an hour and bring the entire team in, all that matters is it can efficiently be used to find problems and come up with a candidate solutions. One the retro session becomes inefficient, you should be holding a future retro around that.

Once a problem is selected, and a solution is agreed upon, it is then up to all the team members to be mindful of this solution and implement it during their next sprint.

🗝 A key point of the retro is that, any topic that is in any way impacting the teams productivity, including whether or not the cycle is even required, should be up for discussion and a candidate for improvement. Have too many improvement cycles? Then the outcome of a retro should solve that, potentially by getting ride of a few. The cost/benefit analysis on absolutely everything should be done and the sole goal of the retro is to find ways to improve productivity. If you are a software development company, then productivity is defined as your ability to produce software and not your ability to hold meetings and improve software development processes.

Solution Refinement

The probability of the first solution you come up with for solving a problem being the perfect one is quite low, but it does take you down the correct path of experimenting, which is why the next step is refining and improving your previously implemented solutions.

The solution refinement is like a retro on a solution. It is the Inception of Micro-LEAN. During the refinement session the team should all give their input on the most recently selected candidate solution that was meant to help improve productivity, and whether or not it served it’s intended purpose. During this session the members of the team should agree on doiing one of 3 things, either scrapping the solution entirely and agreeing it is the wrong path to be going down, making tweaks to improve the solution, or agreeing the solution serves it’s intended purpose and there is no benefit in attempting to developing it any further, at which point is becomes formalised as a part of your own Micro-LEAN implementation.

A good time for this to happen is immediately before the retro session, though it’s important to set clear boundaries between the two. The refinement session should only be about improving the solutions that were implemented over the last retro sessions and which have not yet been abandoned or formalised.

🗝 A key point about the solution refinement session is that it is only solutions that were recently proposed and not formalised should be discussed. Any previously formalised solutions that are starting to be an impediment to productivity should be discussed during the retro.

Key Takeaway

And that is the entire process, 3 basic sessions that form a part of a Plan, Do, Check, Act cycle, helping you develop your own iteration of LEAN, SCRUM, Agile or hybrid of all the above. It is a constantly evolving process of continuous improvement that organically shifts and moulds itself to the requirements of your team, adding formalities where they are helpful and removing them where they are not. It is what LEAN is once you remove all the bullshit and consultants, it is how the Toyota Production System itself was developed, it requires very little commitment, and has so few components that any team can pick it up and implement it in a day, yet will continue to see improvements from for the teams lifetime.

Originally published at https://blog.moodio.co.uk on June 28, 2019.