Lean Software Development – Amplify learning

Of the Lean Software Development principles, learning excites me the most. As a software developer one must strive for continual feedback to improve your skills. The creation of software is after all, a continual learning process.

I like how Mary Poppendieck describes the difference between development and production¹. She likens development to the creation of a recipe, and production to following the recipe, with the principle differences outlined in the table below:

Development	Production
Quality is fitness for use	Quality is conformance to requirements
Variable results are good	Variable results are bad
Iteration generates value	Iteration generates waste

So with this in mind here are some of my thoughts on how you can Amplify Learning in Software Development.

Using an agile technique such as scrum is invaluable to assist in the learning around planning and how much work the team can be producing in a sprint. Use retrospectives to the  utmost to get the benefit of identifying what went right, firstly and then what went wrong. And choosing a small i.e. 3/4 number of items that did not go well to focus on in the next sprint. So the team as a whole is continually learning throughout the delivery cycle.

Eliminate big up front design. Do as little design as possible to convey appropriate understanding and then develop to test the ideas. You will most likely find the design is unpractical or there is a far simpler way of solving the problem. And in doing so you are actually proving a solution, not theorising about a problem.

Having the ability to get feedback on delivery as early as possible is critical. This means building on a library of unit tests that are run whenever code is changed. Unit tests are one of the best ways to institutionalise system knowledge, and when a scenario is missed add it to the suite of unit tests. Documentation and wikis become dated, and require effort to update, unit tests are guaranteed to always be up to date if they are running against your code base. And doing the necessary asserts of course.

Testers should be embedded in the team to improve the communication between developers and testers and as a result shorten the feedback cycle. Testers are quickly able to learn what a piece of code is doing, they can even look at the code, and developers get the feedback around defects early. I don’t understand how organisations can separate the testing function from the development function. They should be working hand in hand to improve quality and find ways to do it better. This is difficult to do when testers are in another building or the other side of the world for that matter.

Developers must be checking in early and often to get visibility of where there might be issues when multiple developers are working on the same areas of code. Continuos Integration that is running often is beneficial here to alert the team issues shortly after the code is checked in.

Define your constraints up front, this is what Mary Poppendieck calls Set Based Development¹. Whether it is time, resources, technology or environmental, rather define the parameters you will be working within than trying to provide multiple solutions that might or might not be solvable.

Lastly, deploy into production as often as possible. This is the ultimate in learning, the client is after all the user of your system. They might not even use the feature you are spending so much time on, or might hate your design. It is better to get this feedback as soon as possible, rather than spending a month or more developing features that aren’t liked by the client.

For other posts I have made on The Principles of Lean Software Development you can go here.

References

1. Amplify Learning – available at http://www.poppendieck.com/pdfs/AmplifyLearning.pdf

Advertisements