Tracking change and innovation in the enterprise software development community
Free Book Offer
SOA Demystified
$40 Value
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Posted by Jacky Li , translated by Jacky Li on Jul 15, 2008
Lean software development, which we hear a lot about these days, may be still a bit of a mystery for people who come to Agile via Scrum or XP. Earlier this year, at an Open Party was sponsored by InfoQ China, Ning Lu of ThoughtWorks China offered an introduction to Lean thinking, and said the biggest obstacle to Lean thinking can be the manufacturing mindset.
VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.
well, it is true that it is impossible to foresee everything. in the beginning ever, the requirments are not clear, we can't say any work a wast unless , that work has not been passed through certail developement process. so i don't agree that wo should stop coding. infact our work is currently going through development process, not complete yet.
Regards.
Jacky, great article about Lean Thinking!
The way I see, before learning Scrum, XP or any flavor of Agile, people should understand about Lean Thinking and its principles.
It's all about the cultural change!
But... how?
Reading is good, but not enough.
We need to practice and learn. Improve, learn, adapt (remove waste), and try again.
About reading, one could start with a Mary Poppendieck's book, let's say "Lean Software Development - From Concept to Cash". Also reading something related to Toyota (i.e. Taiichi Ohno or Shigeo Shingo) is important.
Eh....actually, I didn't mean that we should stop coding.
I just want to say that If we take unfinished work as a form of waste, then we will be dedicated to turning the code into running software, and deploy it into a production environment a.s.a.p. Later we will get feedback and more detailed requirements from the customer, and we can find out whether the committed functionality is finished (or not). The more unfinished work we have, the bigger the risk will be.
The way I see, before learning Scrum, XP or any flavor of Agile, people should understand about Lean Thinking and its principles.
It's all about the cultural change!
Yep! Implementing Agile(or Lean) is a long turn process, and it would be even more difficult if one only try the practices without understanding the philosophy.
You took the WIN
Last sunday ,22 jun 2008,I read an about porche ,toyota and toyoda .How they introduced and implemented the lean management and what is really lean management is. I was thinking how can we put them in software engineering and can't find a clue to implement, you did a great job and make my thoughts clear and stream line.Thanks a lot.Good Job.
Regards
Noman Khan
Be careful when you try to copy/paste a manufacturing process into the software realm. For somebody who is familiar with LEAN in manufacturing, a whole bunch of things worried me when reading this article.
First of all, LEAN is a Just-In-Time process and the main principle of LEAN is that the production of any unit of work is triggered by actual demand. That is not the same as "push code into production asap and then get feedback" described in the article. You could even say - it's the opposite.
Another important issue with lean is quoted on Wikipedia: "A lean process requires reduced variability and uncertainty in the supply chain to reduce needs for raw materials and finished goods inventories." Manufacturing companies use rigorous forecasting to achieve reduced variability. In software engineering, as we all know, variability, ambiguous requirements and changing requirements are the fact of everyday life, so there is a big question whether LEAN is applicable to software engineering, just because it was successful in manufacturing.
Another interesting quote from Wikipedia: "LEAN has recently been introduced into Her Majesty's Revenue and Customs in an attempt to improve customer service within the government department[citation needed]. This however, has not been a success. Productivity in LEAN areas is down and staff morale has hit an all time low. This can be put down to a few factors, mainly mis management and the LEAN process not being fit for purpose in a UK office environment."
All that said, it's good to see that people are trying and looking for ways to further improve processes.
I'd also add to the be careful list...(applies to anything Agile too)
Find out what it means, not just use the word. Lean != Lightweight.
Like we're accustomed to in anything Agile, Lean at its core is about trimming out unneccessary/unproductive bits and minimizing overhead bits so you can focus on those things that provide value. I would say Lean mfg can teach us some things, but I'd also agree that it's not an easy map between the two. I think we should be looking at the principles, but not necessarily the actual approaches. At the end, I(at the risk of sounding ignorant of Lean) see very little difference between the driving principles of Lean in manufacturing and the Agile Manifesto that can't be explained by the differences in product.
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
7 comments
Watch Thread Reply