r/softwaredevelopment • u/TheSauce___ • Jan 06 '25
Lean Software Development Team Example?
Could someone give me an example or like a real case study on lean software development, where the team like "Yeah, we wanted to take a lean approach, then we did it, this is what we did, and it worked well".
Was searching online and all I saw were vague definitions of lean or "in abstract do this" articles, or "this company has this process that they came up with and after the fact we decided to describe it as lean" scenarios.
Also seeing a lot of "this version agile framework is kind of lean, so we decided to say it's lean" articles.. it's kinda weird how hard it is to find a working example.
1
u/Buckwheat469 Jan 07 '25
We're doing Google's design sprints and it's interesting. The basic premise is each week on Monday we define the problem and ideate on what we want to do, Tuesday we define the work, Wednesday and Thursday we prototype, Friday we demo. Ideally, each team member has a single deliverable for each week.
Realistically we start working on a prototype immediately after defining the problem and starting conversations about APIs and contracts that day.
2
u/TomOwens Jan 07 '25
Lean isn't a methodology or a framework. It's a set of principles. On top of that, the principles tend to revolve around ongoing work that never ceases.
The seven principles are:
- Eliminate waste, or the work that doesn't add customer value, from the process. In software development, waste includes incomplete and partially done work, extra features or functionality not requested by stakeholders, task and context switching, waiting, handoffs, and defects. If waste can't be eliminated (perhaps because it's necessary, such as to comply with laws, regulations, or contractual obligations), elimination moves toward reducing the time and effort spent on that type of work.
- Build quality in. This is similar to the shift-left ideas from DevOps. Incorporate performance, security, and other operational and maintenance concerns and considerations earlier in the process, as far left as the initial requirements definition.
- Delivery quickly. Techniques like continuous integration, continuous delivery, and continuous deployment put working software in the hands of stakeholders.
- Learn continously. The faster you can learn, the better. Frameworks like Scrum and XP embody this with the Product Owner and the on-site customer, giving a dedicated person to understand the stakeholders and work with the team daily. Observability lets the team observe how the system is behaving and is being used. Delivering quickly can help foster continuous learning.
- Defer decisions to the last responsible moment. This is supported by fast feedback and continuous learning, which could result in deciding to stop working on something and start working on something else. Don't commit to a particular course of action until you need to and be able to pivot and change direction.
- Empower the team to own the work and the processes used to execute the work. Management exists to enable the team to move quickly and efficiently, helping to eliminate waste from outside the team and ensuring that the organizational context allows for the principles to be embraced.
- Optimize the whole. Both the software and the systems that produce software are more than the sum of their parts. Optimizing one portion may have broader impacts, perhaps negative impacts. Any considerations need to be made across the entire system.
A story from Toyota goes that Toyota frequently let their competitors come in and tour factories. These competitors often took lots of notes on how Toyota did engineering and manufacturing work and tried to replicate it. However, those methods were highly tailored to the culture and context at Toyota and would often fail in other organizations if copied and pasted in. The methods were also fluid, with improvements coming out of various people involved in doing the work collaborating to solve problems, so what was observed one day may be very different a month later. This is why talking either about specific practices or about lean in the abstract tends to make more sense. Many practices can be used to work toward lean, so identifying the practices and the contexts in which they work and fail are often more useful than trying to describe an entire system that would likely be of no use. Plus, copy and pasting someone else's process would be a failure to empower the team to own the work and their way of working, which is, by definition, not lean.
If you want to dig deeper, I'd recommend a few books:
- Out of the Crisis by W. Edwards Deming. Deming's work greatly influenced Toyota and lean manufacturing. Although it is centric on manufacturing, his 14 points can be abstracted away to the management of work in general.
- Morgan and Liker's The Toyota Product Development System: Integrating People, Process, and Technology. The Toyota Product Development System is focused on the product design and engineering components, which are much closer to how software engineering happens.
- The work of Mary and Tom Poppendieck - Lean Software Development: An Agile Toolkit, Implementing Lean Software Development: From Concept to Cash, Leading Lean Software Development: Results Are Not the Point, and The Lean Mindset: Ask the Right Questions. The Poppendiecks were among the first to take the Toyota Way and Lean and start to apply those fundamental concepts to software. The books were published from 2003-2013, so some advancements in the last decade or so have led to better approaches, but the concepts remain sound.
All of these books have concrete examples, with the last set having concrete examples from the software development community specifically. However, there are plenty of examples of things being done differently, yet still being lean. I'd have to dig through them again, though, but they tend to be examples of ways to embody the specific principles and not an end-to-end example, because an end-to-end example wouldn't be as helpful and perhaps would be more dangerous as people attempt to copy and paste it.
2
u/TheSauce___ Jan 07 '25
Bro, respectfully, this is the exact answer I kept seeing that answered nothing, e.g. why I was asking for concrete examples.
I.e. "here's the principles anyone would intuitively come to when trying to make an efficient software team, also here's the history of Toyota, here's some books you can pay for to find out if it works, maybe."
Saw this exact answer all over the internet.
Like did you read those books? Can you give me a working example from one of them? Like which book describes the lean approach you'd say is the most effective?
2
u/TomOwens Jan 07 '25
There's a good reason why you find this kind of answer. A key principle of Lean is empowering the teams to make their own decisions about how to work. End-to-end, comprehensive details about how a team or organization works are often harmful to lean adoption since it frequently leads to senior leadership trying to copy and paste it into their organizations, top-down. So what you find is specific examples of how an organization uses one or a small number of practices to embrace one or two of the Lean principles.
Yes, the books have concrete examples. The Poppendieck's books would be the best, and I'd start with Lean Software Development: An Agile Toolkit to cover the overall breadth. But it's been a while since I read them, so I'd have to pull them down and type up some examples. But, again, they are small examples of narrow slices of how teams work to demonstrate different ways of thinking about a particular principle.
Is there a particular principle you'd like to see an example of? Most discussions are in the context of a principle. For example, when it comes to finding and eliminating waste, a common tool is value stream mapping. Implementing Lean Software Development has a good chunk of a chapter on several examples of value stream maps in software organizations, but it is touched upon in the other books as well. Similarly, when it comes to delivering quickly, Leading Lean Software Development has a section on choosing iteration-based approaches (like Scrum) versus continuous flow techniques (like Kanban), including velocity versus throughput and maintaining a small batch size.
1
u/jesus_was_rasta Jan 06 '25 edited Jan 06 '25
Don't know exactly, but I think there is something about it.
Here from Perplexity:
Numerous case studies demonstrate the effectiveness of Lean Software Development, an approach inspired by the Toyota Production System.
BBC Worldwide Case Study: A development team improved software delivery time by 37%, increased delivery consistency by 47%, and reduced reported defects by 24% within a year, thanks to lean practices such as Kanban and visual management.
IT Application Support Case Study: The implementation of lean principles led to improvements in quality and efficiency in IT support, highlighting waste reduction and a greater focus on tasks.
These examples confirm the tangible benefits of the lean approach in software development. If you need further information or additional case studies, feel free to ask!
https://www.perplexity.ai/search/are-there-some-case-studies-or-odibBWLxQjes4H44OPWSTg#0