An Overview of Lean Software Practices
Tim Wingfield gave a talk last weekend about the seven pillars of lean software development. I was lucky enough to get a preview of the talk last week. Here's a recap of the presentation
Eliminate Waste
Tim talked about how estimating was a waste of time because it added
nothing to the end value of the product. That's different than sizing
the work though.
The goal was to drive cost down and profitability up. If the work you're
doing doesn't fit into one of those two categories, then eliminate it.
Also beware the QS and hand offs. Anytime you hand off work or pass
along information there's a chance for details to be lost and it takes
valuable time to impart details.
Build Quality In
The goal is to build quality in, not test it in afterwards. It's
impossible to test quality into a badly written product.
Quality assurance is not quality construction. One is the inspector
coming along afterwards to force the contractor to fix all the problems
they can find with the house. Quality construction is building it right
the first time. It appears cheaper to build to junky homes... until you
start considering how much it costs to fix problems later. The
maintenance costs will overwhelm you.
Some of the ways you can buid the quality in up front include test
driven design, pair programming, and peer code reviews.
Suggested reading on this topic includes Clean Code by Bob Martin and
The Pragmatic Programmer by Andy Hunt and Dave Thomas.
Create Knowledge
Avoid Big Up Front Design (BDUF)... what does it add? Avoid fixed bid
contracts. Deliver incrementally to the client and stop when they have
what they need. This helpls you avoid delivering features they though
they neded but later decided they didn't. Writing those features would
have been a waste of time.
Focus on development evolution. Practices and features evolve if given
room to grow and fail.
Give your teams room to mature. This includes setting a low bar for
failing. Let them fail so they can learn.
Continuous improvement... learn, do, learn, do... repeat.
Embed your testers on the team with your developers. Don't separte these
teams... it leads to testing in afterwards if the teams are separated.
Defer Committements
Hold off on decisions until the last responsible moment. Choosing
features and technologies long before you need them removes your ability
to change. You can't make better decisions later if you've already
locked yourself in early.
When you do make decisions, strive to make them reversible ones. Martin
Fowler calls architecture anything you can't change later. Try to avoid
adding too much architecture into your product early.
Don't take this as an excuse to do nothing thought. Gather information
and create your plan. This isn't procrastination, it's flexibility.
Deliver Fast
Frequent delivers helps you finish features before the customer changes
their mind.
However fast speed isn't just hacking out junk code. You still need
disciplined coding to deliver a quality product.
Know your team's capacity and work to it. Don't overload, and then burn
out, your team. Overloaded teams make mistakes that cost a lot of time,
and therefore money, to fix later.
Focus on the team's cycle (or iteration), not the utilization. At the
end of the day, the only thing that matters are solid, working features,
not whether the team worked at 110%.
Automate everything. Relentlessly. Automate your builds, testing,
deployment, database staging, and anything else you can think to add.
Respect People
Process and tools are useful, but you win with people. But not heroes.
Heroes go so far above and beyond that do so at the expense of the team.
It's always better to build a solid team than to have one "heroe" who
works all night. There's a usually a reason this one person has to work
all night... they're fixing the problems they created!
Give smart people the right information and trust them to make good
decisions. There are 100 ways to do something right.
Involve everyone and encourage passionate involvement. Encourage
ownership whenver possible.
Optimize the Whole
Focus on the entire value stream. Have developers go to lunch with sales
reps. Share knowledge.
Always deliver a complete product.
Be a team. Complete products come from complete teams.
Don't hoard knowledge. Don't be a bottle neck.
---------------------------------------
This looked like a
great talk and he's a great presenter. Try to get a chance to see Tim
give it in person if he's
in your area.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)




Comments
Daniel Lourenço replied on Thu, 2010/05/27 - 6:43am
This is in deed an interesting view over some practices in lean software development. I would say that one key factor that I would expect to see mentioned is the involvement of the end-user and the stakeholders in the development cycles - this way we have a two way alignment "the team gets aligned with the business needs" and the "business understands the delivery team".
I just don't agree with the "Frequent delivers helps you finish features before the customer changes their mind.". The truth is that the customers always changes his mind, so the important thing is to have intense communication and small cycles so that the customer can change his mind while it is still possible to fix it without having to refactor your whole project and change your timelines.
Don't you agree?
Jared Richardson replied on Sat, 2010/05/29 - 11:50am
The two ideas don't seem mutually exclusive to me. Rather, they're both good ideas to embrace.
Daniel Lourenço replied on Mon, 2010/05/31 - 11:55am
in response to:
Jared Richardson
OK Jared, I now understand. A delivery process with large development development cycles has three dangers:
1. The business needs change during the project (or simply disappear) - when the software is available, it is no longer needed or appropriate;
2. The development team did not understand the "business requirements" and implements a piece of software that is not what business expects.
3. The customer "forgets" the context that motivated the requirement (indeed this can happen for more than simple amnesia - for example, the customer stakeholder can change). This can cause severe disruption in the software delivery process (I am imagining a project where, after months of implementation, hundreds of requirements are not clearly understood by the customer nor the delivery team).
Thanks! :)
Jared Richardson replied on Mon, 2010/05/31 - 9:11pm
in response to:
Daniel Lourenço