An Overview of Lean Software Practices
An Overview of Lean Software Practices
Join the DZone community and get the full member experience.Join For Free
You've been hearing a lot about agile software development, get started with the eBook: Agile Product Development from 321 Gang.
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
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.
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.
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.
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.
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.
Opinions expressed by DZone contributors are their own.