In the last episode I introduced the Minimum Viable Product. I personally see Minimum Viable Products being related to Lean Principals. I'll give you an introduction to Lean in this podcast - and where appropriate, tie it back to the Minimum Viable Product.
Or listen at:
Published: Wed, 04 Sep 2019 16:04:29 GMT
Transcript
There are 4 terms I want to introduce over the coming weeks;
- Lean
- Agile
- Cloud
- And DevOps
There terms have become terribly overloaded by marketing hyperbole.
All have been terms that marketing folk have stuck on their products like stickers. So much so that these terms have started to lose their meaning.
If anything, they are almost becoming terms to dismiss because of their overuse and adulteration.
They are however, at their heart, very important concepts that allow business to operate better and to produce better Return on Investment from Software Development - especially in the digital age.
So over the course of the next few weeks I want to take you through how I interpret them in terms of getting better ROI from software development.
These podcasts will be far from definitive guides on the subjects. Each is a very deep subjects. But I hope to provide you enough to understand on how they fit in.
And I've chosen to start with Lean as it is possible the easiest to understand from a purely business perspective;
As a simple summary, Lean is a way of approaching work with the aim of reducing waste and focusing on value adding activities.
The current ideas of Lean are largely credited to manufacturing within Toyota.
From wikipedia;
"Lean manufacturing attempts to make obvious what adds value, through reducing everything else (because it is not adding value).
This management philosophy is derived mostly from the Toyota Production System (TPS) and identified as "lean" only in the 1990s.
TPS is renowned for its focus on reduction of the original Toyota seven wastes to improve overall customer value, but there are varying perspectives on how this is best achieved.
The steady growth of Toyota, from a small company to the world's largest automaker, has focused attention on how it has achieved this success."
As the quote mentions, the Toyota system used seven types of waste. Lean principals and supporting practices help an organisation highlight those wastes within their operation - with the aim of then reducing or eliminating them.
The principals have then been applied to software development in the book "Lean Software Development" by Mary & Tom Poppendieck in 2003.
Lean software development focuses on 7 principals:
- Eliminate Waste
- Amplify Learning
- Decide as late as possible
- Deliver as fast as possible
- Empower the team
- Build integrity in
- Optimize the whole
Let's start with Eliminating Waste;
The seven common types of waste defined by Lean manufacturing are:
- Transport - the moving of products that are not actually required to perform the processing. Imagine if a car has to repeatedly crisscross large distances during its manufacture. Even having to move a car across the same plant can be consider waste due to effort and risk of damage.
- Inventory - all components, work in process, and finished product not being processed. Imagine having an inventory of two years worth of car wheels. That would simply be excessive for any manufacturing needs. This will have tied up investment, which cannot be realised until a new car can be built (and sold). This will also be incurring storage costs. Plus it also runs the risk that those car wheels may become valueless through some change to regulations. Probably then incurring further costs for disposal.
- Motion - people or equipment moving more than is required to perform the processing. Imaging a badly designed workspace where an engineer would need to be constantly walking between multiple benches to get a task completed. Whereas having all the relevant components and tools close to hand to minimise that movement. Think about making a coffee. You wouldn't want the sink in one room, the kettle in another, the coffee in a third and then store your mugs half a mile down the road. You'd have them all in the one place for efficiency.
- Waiting - waiting for the next production step, or interruptions of production during shift change. This can be the opposite side of the coin to Inventory. If you've run out of those car wheels you can't complete your car and sell it.
- Over-production - production ahead of demand. For manufacturing; the producing of components before they are needed. Consider the wheels example from Inventory - they are very similar - the primary difference is that Over-production is making too much stuff. Inventory is having too much stuff. Over-production can definitely lead to Inventory.
- Over Processing - results from poor tool or product design creating activity. Consider work done that was due to things like poor communication, human error or not understanding the customers needs.
- Defects - the effort involved in fixing defects. Defects will result in cost to resolve and impact to the brand.
In their book, Mary & Tom Poppendieck identified similar wastes in software development;
- Partially done work - where work has started, but never gets to a point where it is providing value to the customer (generally, simply not finished). You are ultimately paying those developers to build things - investing in those things - never for them to see the light of day and establish any form of return. A Minimum Viable Product is an experiment and until you get it in front of the customer you are unable to prove or disprove the theory. MVP encourages us to get that smallest experiment in front of the customer.
- Extra Features - the adding of extra features not needed or asked for by the customer. Also commonly known as software bloat. I'd expect you've used Microsoft Word - part of their office suite. I was once given a stat that the average user uses less that 10% of the products features. Given the scope and feature richness of Microsoft Word, I'd expect that is a conservative estimate. To the average user, all of that 90% is over production. If Microsoft was starting again, I doubt they would invest heavily in that 90% - at least not early in their development. Investing in features not or rarely used is obviously a poor investment. The Minimum Viable Product encourages focusing on the smallest set of features to elicit feedback really does limit this expose. And if you are using the MVP to get the "what next" from the customer, you can have a huge level of confidence that you aren't over producing.
- Handoffs - similar to the motion waste within manufacturing. In our traditional software development we silo'ed our teams by their role - business analysis, designer, developer, tester, etc. Each role would generally work on their part of the project in isolation, then pass it on to the next stage when they had finished. This was generally in the form of documents being passed from one functional role to another. This resulted in a lot of lost time (writing documents) and understanding (misinterpretation of those documents). The Minimum Viable Product encourages us to get everyone you need for the experiment involved. Get them face-to-face. Get them focused on the experiment. Keep the hand offs to a minimum - ideally remove completely.
- Delays - anything that is delaying the progress of the experiment through the software development process and into the hands of the customer. Reviews and approvals are quite key ones. I've commonly worked on development teams where we've gone as far as we can without someone "approving" the work. That someone can take hours, days, weeks or even months to provide that approval. The Minimum Viable Product encourages us to focused on getting that experiment through and into the hands of the customer as quickly as possible. Any delay in that defers the potential return on our investment.
- Task Switching - where we assign an individual (or team) to multiple projects or tasks. This may seem counter productive; surely multitasking is a way of getting a lot of stuff done, right? As I've said before, at its heart, software development is problem solving. Imagine being asked to switch between various problem solving tasks rapidly throughout the day. Every time you switch, you have to take time reviewing the new problem - and you will be losing a portion of your thought process on the previous one. The common wisdom is that a software developer will lose around 15 minutes every time they do this switch. I've personally found that it can often be much higher if the problem at hand is complex. The best way to avoid? Keep the team focused on one thing at a time and really be careful to avoid interruptions. As an aside; think carefully about arranging meetings with your software development team. As a manager it is likely you will fill your calendar with meetings throughout the day. The best "flow" for you will be a meeting followed by some time to take any actions following that meeting, then repeat. For a software developer, they need time to think and to solve their problems. If there has to be a meeting, make sure it is at a standard common time that minimises "wait time". The Minimum Viable Product encourages us to focus on the next small experiment, helping us to avoid multitasking and thus that task switching.
- Defects - as with manufacturing, the effort (and costs) associated with resolving defects. There will be expense derived from the defect itself along with the expense to resolve. Both the direct affect and the expense to resolve is magnified by how long the defect goes undetected. It should be self evident that the direct affect of a defect will be smaller the quicker it is identified and resolved. What may not be so evident is the effort for the development team to resolve that defect. The longer you leave it, the higher (and more expensive) the effort to resolve. Part of this is mental recall - its a lot easier for someone that caused the defect to rationalise the likely fault if its an hour after they worked on it, rather than going back to it six months later. The other problem is that additional parts of system may have been build on top of this defect. Fixing the original defect may actually introduce further defects. The Minimum Viable Product helps by keeping the work small and getting it into active use quickly will generally highlight those defects quickly - allowing for cheaper resolution.
- Relearning - an effort to re-learn anything required to be effective. This could be because a software developer needs to re-learn the problem that they where switched off two days ago ... Or because they have to look at a defect from code they wrote 6 months ago ... Or because of knowledge loss during hand offs ... Or maybe there is just very poor understanding of what is being required. It has traditionally been very easy for the original intent to be lost through process & time. It certainly wasn't uncommon for the original requester to be presented with the final product only to comment "that's not what I asked for?" You may be forgiven at this stage to be thinking that you'd address this with more documentation, more sign off, more approvals, more meetings. We could spend 6 months writing a detailed requirements document (that can still be misinterpreted) or we can regularly meet face to face working in quick iterations. Minimum Viable Product can still result in the original requester commenting "that's not what I asked for?" - but isn't that a good thing if you've only invested hours or days on it? Much better to find out then and make a course correction than at the end of a 6 month project. Don't forget that Minimum Viable Product is expected to elicit feedback from the customer. Negative feedback can be just as valuable - if not more so - when it comes to ensuring our investment is getting the best return.
Moving on to Amplified Learning;
For me this goes back to the heart of why software development can be so complex (and thus difficult to get great return on your investment).
So much of software development is learning. Not just the tools and technical environment - but also the problem space.
As I've said before software development is problem solving. But before we even start to solve the problem, we need to make sure we know what the problem is.
Too often we assume we understand the problem we are solving and jump straight into building stuff. But this makes various assumptions on our correctness.
The Minimum Viable Product encourages to embrace that we aren't always going to be correct. In encourages iterative learning allowing for us to improve our understanding as we go.
The next principal is Decide as late as possible.
This is sometimes referred to as "deferred commitment". It is about keeping your options open as long as possible.
This is commonly misunderstood. Teams may feel this means they can choose not to plan and simply make it up as they go.
The reality is a lot more nuanced. The principal encourages the team not to make decisions months in advance of when they need to make them - but rather as they need them - but the decisions still needs thought.
Minimum Viable Product again encourages us to focus on the "what next" rather than spending time on planning for work 6 months down the line - which, if using MVP and customer feedback correctly, may prove to be entirely unnecessary.
The next principal is Deliver as fast as possible.
Again this is aligned with the Minimum Viable Product principal of getting feedback quickly from the customer.
If it takes 6 months to deliver something to the customer, then its going to take at least six months to get that feedback.
Modern business plan to release as quickly as possible. This allows them to test theories and react to market quickly.
Note that Delivering as fast as possible does not mean sacrificing quality.
Which brings us onto the next principal, Build integrity in.
You maybe forgiven for thinking that all the talk of fast and small would result in throwing poor quality software at the customer.
Traditional software development was based on a fixed list of functionality with fairly rigid dates and costs - this generally would result in quality suffering if either dates or costs looking to be overrunning.
It is recognised in Lean that the defect source of waste can be exceptionally expensive. As such the software developed needs to be a sufficient quality minimise that source of waste.
Now this may seem fairly self evident - but as I've said earlier, quality has traditionally been one of the first things to suffer when a project was in danger of missing a deadline or budget.
There are many software development practices that have been developed and improved over the years with the view helping maintain integrity and quality. I'll talk about many of these in future episodes.
There has however been push back on their use within more traditional software development. They are an activity and will involve some investment of time. Thus they come at a cost. Thus are often seen by project managers as unnecessary or gold plating - again back to being the first things to suffer if budgets or timelines are tight.
Personally I can understand that thought process - but it has always been a false economy.
Yes you may get a project delivered - but what mess are you passing to the rest of the business to handle failures? I've seen projects in the past that are "successful", even though its taken 2 years to resolves ongoing problems.
Minimum Viable Product allows us to put changes in front of the customer quickly which allows them to feedback on the quality and integrity. You will always have an internal view of what is "good enough" - and the customer will feedback if they don't agree. That helps you with the "what next" and avoiding the gold plating scenario.
The next principal is Empower the team.
This is a common theme I will come back to time and time again in these episodes.
The team should be capable and enabled to do the job being asked of them.
If they don't have the relevant skills or have to seek authority for every change, they will quickly generate waste.
This will generally involve a change in culture and how people are managed - something that I want to take a specific look at in an upcoming episode.
For now though, the key takeaway is that your team is a source of feedback. It is important that you are listening to them.
The final principal is Optimise the whole.
I've often considered software development a balancing act.
Rarely is there a 100% correct thing to do. As I talked about in episode 4, software development can involve a lot of trade offs and compromise.
And same is true in Lead Software Development, you have to consider all the principals and decide on the appropriate compromises.
For example, it is very easy to over focus on Delivering as fast as possible while neglecting integrity & quality.
Conversely, we can fall into the trap of "gold plating" and never releasing to the customer.
Neither of these extremes are desired.
So there has to be a blend - a compromise - of both.
And that's my introduction to Lean Software Development.
During this podcast I've linked Lean back to Minimum Viable Product and how I feel it fits in to helping you achieve better ROI from your software development.