Agile Zone is brought to you in partnership with:

Jared Richardson works at Logos Technologies As a recognized expert in the software industry, Jared has worked with both start-ups and software giants. He's been involved with various open source projects, with roles from contributor to founder. Jared co-authored the best selling book Ship It! and Career 2.0, and founded the Agile RTP user group as a local outlet for the agile community in North Carolina. His personal blog is Agile Artisans

Jared has posted 52 posts at DZone. You can read more from them at their website. View Full User Profile

An Overview of Lean Software Practices

05.24.2010
| 9451 views |
  • submit to reddit

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.

Published at DZone with permission of its author, Jared Richardson.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Daniel Lourenço replied on Thu, 2010/05/27 - 6:43am

Hi Jared,

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

I do agree. Customers have to see the feature working before they understand if it's what they really want. But I also agree that delivering very quickly makes it more likely to get the product to the customer while they remember what they asked for. :)

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

Perfectly stated! Thanks.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.