October 21, 2013
Eat your own dog-food (or ‘How we use Lean at ReQtest’)
We use Lean principles almost religiously, and although we are no Toyota, we find that there is no better way for us to maximize our productivity, communicate effectively and ship an excellent product in the most efficient of ways.
In fact, we’re all strong proponents of Lean principles, and we use a number of these principles all the time, every working day at ReQtest. This way we aren’t just advocating Lean, we’re actually using it. Eat your own dog-food has never rung truer.
Eliminate waste
The worst form of waste in system development is almost certainly redundant, unnecessary features. Early on in my career, I was involved in implementing an administrative system for an insurance company. The standard software contained a module where customer support could add a temporary address for customers to be used for a specific time period. For instance, when going on vacation, the customer could call and state an alternative address, for instance to their country house Our dev team spent a huge amount of project time investigating, gathering requirements, configuring and explaining how the feature worked. After several rounds of revising requirements, implementing, reviewing, and fixing, the module was finally completed.
Now to our disbelief, we discovered that the insurance company had no pressing need for adding temporary addresses. It turns out that very few customers have the urge to get insurance information during their vacation, so the module was never deployed in production. Guess what our next project was? You guessed it; it was yanking out everything deemed unnecessary in the system, which included the blessed temporary address function.
In this case, the “temporary address” function is a crystal clear example of “waste”. It was of very low value to the client, yet caused significant costs in terms of training, requirements definition, testing and correction. In hindsight, it was obvious to everyone that all that time should have been spent on something the client actually wanted instead.
Just in time commitment
We prefer to decide which requirements to include in the next sprint as late as possible, typically during sprint planning. Furthermore, requirements are not written and described in full until they are needed. According to the Lean principle of “Defer commitment,” we should make decisions which affect commitments as late as possible, which is why this approach is also called “Just In Time Commitment”.
By delaying the ‘freezing’ or ‘setting in stone’ of requirements until we have tested and evaluated different options, better decisions can be made, decisions based on the facts and experience which we have gathered, rather than decisions based solely on our imagination.
Deliver Fast
Another Lean concept that we use is that of “Deliver Fast”. We find that this approach not only forces us to think of how to plan our work more efficiently, it also cuts down on waste, both in terms of time wasted as well as wasted code and implementations. Technically, we can deploy new ReQtest releases after each sprint, that means every 2nd week. We have spent a lot of time to come to a smooth deployment process that makes it possible to deploy ReQtest with just a few clicks.
Even if there is no pressing need to deliver to the client so rapidly, the frequent internal deliveries help us to spot anomalies such as the redundant temp address feature mentioned above, and additionally, we can keep an eye on how well our progress is shaping up when compared to the product roadmap.
When urgent requirements arise we can rapidly react to the needs. We feel this makes a big difference in the product, so please, feel free to compare our delivery pace with the one of our competitors’.
Prototyping
In addition to the above, we also use a combination of prototypes and usability tests. According to the ‘Amplify Learning’ principle of Lean software development, “The process of user requirements gathering could be simplified by presenting screens to the end-users and getting their input” We take this credo a step forward and use prototypes to quickly produce tangible and visual solutions which work well as a basis for dialogue with our clients, users and fellow team members.
We also conduct usage tests , also known as “usability tests”, which we plan so as to give us validation from our end-users as early as possible.
In combination, these two techniques give us valuable, early and low cost feedback which we use to vastly improve the quality of our requirements which in turn results in a higher quality product!
Share article