Tracking change and innovation in the enterprise software development community
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Free Book Offer
SOA Demystified
$40 Value
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
Posted by Geoffrey Wiseman on Jul 25, 2007
Lean methods employ Kaizen, or continuous improvement, to reduce waste and improve results on a regular, even daily, basis. On the leanagilescrum group, Alan asked:
[A]re there known techniques for facilitating kaizen activities within Lean/Agile software development?
Martin suggested:
To me, software Kaizen is more than looking for waste, it's looking for ways you can improve things all across the board.
I'm a hands-on developer, so I'm pretty code-quality focused. If you have a horrible untested/untestable legacy codebase, it's pretty easy to measure the improvements you can make by refactoring to testability/design patterns. I guess you can look at that as reducing the wasted time people scratch their heads and say "how's that supposed to work?"
I like to look things like number of classes under test, percentage of code coverage (although this is tricky by itself).
I strongly believe that if you don't have high quality code, you'll only be able to go so far with other Kaizen approaches.
Finally, Phillip responds with a detailed review of steps to follow before, after and during a Kaizen event, closing with:
The above described process should happen in less than a week. The spirit of Kaizen is to identify waste and eliminate it through process improvement, do so quickly involving the people actually doing the work, implement the change, support and monitor the change, then start all over again.
In a related blog post, Bruno Câmara analyzes the intersection between Scrum and Kaizen, suggesting that incremental improvements are made in the sprint retrospective, and that collecting and analyzing data is done daily with the burndown chart and project backlog. Broadening the scope somewhat, he suggests that that agile processes avoid waste through excess documentation, and that agile's small self-managed skilled teams push decision-making to the developers, as Kaizen intends.
For more information on Lean, Kaizen, Retrospectives and Continuous Improvement, read on at InfoQ.
Learning to be a Good Product Owner: Foundation Skills
Regaining control of the data centre
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.
I'm inspired by the theory of constraint: en.wikipedia.org/wiki/Theory_of_constraints
And throughput accounting: en.wikipedia.org/wiki/Throughput_accounting
For me in software development you have to pull result out. Typically, if you don't test some aspect of an application you can't be sure if it works as expected. Hence you have to pull results out of the development process by testing.
Kaizen is about micro improvements. Sprint Retrospective Cycles are too long to remember all the micro problems und potential micro improvements.
Creating an impediments backlog at the daily standups may help since the cycle is much shorter.
jeffsutherland.com/scrum/2006/06/why-three-ques...
If you read Phillip's steps and you are in software development field you will notice it is hugely similar to the app profiling activity:
- observe and measure the app
- try out different approaches
- keep an eye on it
So, imo in this case Kaizen sounds like a development process profiling.
./alex
--
.w( the_mindstorm )p.
________________________
Alexandru Popescu
Senior Software Eng.
InfoQ TechLead&CoFounder
Robert Hoekman has written the Kaizen Manifesto (www.kaizenmanifesto.org/) in which he suggests the principles of the kaizen manifesto are:
1. Make continuous improvements in every aspect of the business.
2. Actively pursue a superior, complete customer experience.
3. Continually improve designs, code, and processes.
4. Strive to increase agility (binshou) while reducing costs.
5. Use the Deming Cycle to minimize disruption from change.
6. Prevent errors (poka-yoke), in software and in business.
7. Respect people, leverage expertise, and trust staff.
8. Reward suggestions, improvements, and progress.
9. Always move forward.
Although I'm not sure I buy into his critique vis-a-vis agile and Kaizen (see derivadow.com/2007/03/07/maintaining-agility-an...)
Robert Hoekman has written the Kaizen Manifesto
Aren't these just normal rules that any sane company is supposed to use?
bests,
./alex
--
.w( the_mindstorm )p.
________________________
Alexandru Popescu
Senior Software Eng.
InfoQ TechLead&CoFounder
Alex wrote:
"Aren't these just normal rules that any sane company is supposed to use?"
lol - yes, one would hope, however we(organizations of people) can get so bogged down with process that we forget that what we do is really about delivering value and supporting our front line workers to deliver on that value. We get so busy with "stuff" we forget to focus on analyzing and improving our "value stream"
bests,
./alex
--
.w( the_mindstorm )p.
________________________
Alexandru Popescu
Senior Software Eng.
InfoQ TechLead&CoFounder
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.
6 comments
Watch Thread Reply