In Lean "Value to the Customer" actually trumps ... "Eliminate Waste"

A lot of people starting with lean think that the topmost goal is to eliminate waste.
Maybe it is just because the Poppendiecks started their first book on Lean Software Development with the principle "eliminate waste", or maybe it is because "Eliminate Waste" makes such an impressive battle cry.
The so called lean decision filter (described nicely by David J Anderson in an article on providing value with lean) makes it rather clear, that in most cases waste elimination is just a ‘minor’ priority, easily trumped by Value to the customer.

The whole chain of trumps in that decision filter is listed as

Value to the customer
    trumps
Flow
    trumps
Waste elimination

This list makes it way easier to decide what to work on next, as Yuval Yeret explained in an article at the leankit blog.

So, next time you ask yourself what to do next you might consider applying this filter instead of going by simple "always do x" rules.

till next time
  Michael Mahlberg

Breaking down the task-board

Have you ever experienced that dull task breakdown session, where you started with a couple of concepts (lets say street and phone and country) and ended up with a list of three or four tasks that somehow re-occured several times?

In this case perhaps:

• modify database schema to accommodate street
• modify ui to display street
• modify validators to validate street
• modify database schema to accommodate phone
• modify ui to display phone
• modify validators to validate phone
• modify database schema to accommodate country
• modify ui to display country
• modify validators to validate country

In these cases it might help to think differently about your work – perhaps those repeating categories are in faction stations that each of the concepts to be implemented have to go through.

Some people would model this as three different stations

• Database
• UI
• Validation

If you put them on the board as separate columns each item could be reduced to it's concepts core and just ‘flow’ through the system.

Database	UI	Validation	done
street
			phone
		country

So, perhaps it’s time to rethink task boards, put in some of the ideas from lean and kanban and add a couple of columns.

(of course not with the exact names from above ;-)

Disclaimer:
And no I don't recommend building db-, ui-, and logic-silos. But if you have them, be honest and acknowledge the fact. Change it afterwards. Start with what you do now as they say in Kanban.

till next time
  Michael Mahlberg

How to plan for iteration 35 in iteration 1

"But how can we make sure that we can incorporate all those things that we will only discover well into the future if we don't design the system with an architecture that takes all those things into account?"

Well....

You can't. But neither can you (or anybody else for that matter) look into the future with certainty.

We all learn only from things in the past. Even if we think about the future and ‘learn’ from those thought, the process of thinking is in the past, when we learn.

We just can not predict the future.

But we can learn from the past.

We can learn to build systems in such a way, that they are comparatively easy to adapt to new situations and requirements.

That’s what patterns are for

Software Design Patterns are proven approaches to common problems that have worked in the past. That is how the GoF-Book, which made the whole pattern movement available to a broader audience, states the idea of patterns. You've got a problem you want to solve? Perhaps there already is a proven approach. Look it up. Chances are that the approach encompasses sound design principles and makes later changes attainable.

That's what refactoring is for

Software is more easily changed and extended if it is well structured. Refactoring, as it has been defined originally, ensures that the system stays well structured and easily modifiable. Use it. Follow ‘red – green – refactor’ if you have the chance or at least ‘refactor mercilessly’

That's what SOLID is for

The SOLID design principles (SRP, OCP, LSP, ISP, DIP) provide guidance on how to build actually change-friendly and robust software.

That's what Clean Code is for

Robert C. Martin also inspired the whole clean code movement which is not only about writing good code, but also provides insights on how to keep your whole development ecosystem in such a way that change stays easy.

Conclusion

You don't need to think about the details of iteration 35 in iteration 1 – if you ‘just’ factor in a small portion of the effort that up-front planning for iteration 35 would have taken for refactoring and restructuring in each iteration and follow sound software design principles you should be fine. After all iteration 35 may turn out to be something completely different from what you think now that it will be.

till next time
  Michael Mahlberg