Requirements - Product Owner and Customer
December 13th, 2008
One very important thing that I have learnt from my consulting experience (dealing directly with Clients for building solutions) and in my experience of building exterprise products is:
When you are given a set of requirements, always understand the requirements in terms of what problem of the Customer (an actual client or the product owner) is this requirement trying to solve, instead of just treating the requirement as a feature or an enhancement request.
This may sound very simple, but it has far reaching implications in building great products/solutions. With a good understanding of the inner workings of the product or the architecture or technology or just out-of-the-box thinking, sometimes certain extremely simple alternative solutions might just do the trick with very little or almost no work/re-rework required..!
This was reinforced by one of the examples given by Mary Poppendieck in the Lean Management principles presentation I attended recently:
In the Military/Army, the communication given to the soldiers consists of just 2 things:
- End State
- Command Intent
So, the “Stories” or “Requirements” should specify the “what” and not the “how”.
Performance tuning vs. Lean/Agile
November 6th, 2008
I am currently working on performance tuning & refactoring a product. And, interestingly I found some Agile/Lean principles that apply for performance tuning and refactoring:
- Most Lean principles appear counter-intuitive at first
- Aim for system optimization instead of point optimization
- Build prototype and measure (run quick experiments), not just theorize
- Minimize the number and size of things-in-process
- The most predictable performance comes from maintaining options until you have the most information