A Lean journey in Software Development - Seeing problems when and where they occur
It's not the event that counts, it's your reaction to the event.
- Do nothing: accept them as "necessary inconveniences". If absolutely necessary, design a workaround to the problem, and resume immediately to "real, productive work".
- Make Problem Solving a daily activity for everyone, at every level, starting by detecting problems as early as possible in the process (when they make no or little harm, and the environment still provides contextual data for investigation).
When you are seeing and solving problems everyday, there are no crisis per se; there are just problems that are bigger and more demanding than others.
Seeing problems "where and when they occur" requires the habit of "Genshi Gembutsu" (go and see for yourself):
- interview end users and see them in action as often as you can, for knowing (not assuming) what are the problems you need to work on first, and fixing early your false assumptions,
- understand the actual working place, where value-adding activities take place, for grasping the working conditions and spotting (not imagining) the true obtacles to attaining your goals.
Look at this picture:
(...) detect abnormality in things that one cannot see by default (...) if they go wrong and the problem is not detected, they cause trouble. If they are seen as they start to go wrong, their effects may be mitigated quickly and the organisation may learn from their occurrence.
- Value Stream Map from initial idea to software in production
The outcome (value) of Software development consists in solutions to actual needs and problems, faced by the target users. With that definition in mind, we decided to map on the wall the flow of value from raw idea in the head of the client to features available and used in production:
- develop a shared, constant awareness of where we stand and where we go,
- avoid discrepancies between client wishes and actual developments,
- see immediately when an idea gets lost or poorly addressed,
- notice and address bottlenecks early, before they cause any harm,
- limit WIP and slowly develop a pull system
- Standardized daily meetings
|Standard Daily Meetings|
- Continuous Integration : Unit, Acceptance, Performance and Platform Tests
- Standardized Deployment process
Howebver, as long as deploying the application required more than 1 step, we used to print our best known procedure before each deployment, and log any anomaly as we were progressing through the operation:
|Tracking Anomalies after Production deployments|
- Pair Programming
Among other benefits, pair-programming helps detect and fix problems in the code as early as possible: the co-pilot reads and analyses the code as it is written, warns his mate about potential risks, raises questions and brings his perspective to produce a solid emerging design.
From my experience, this practice is much more effective at producing bug-free programs than a formal code review, executed days (or weeks) after the code has been checked in.
The examples provided above represent only a subset of what we have done in our context. Listing more would serve no purpose, as I believe every professional development project should customize its own system for detecting problems as they occur, for their specific value stream.
Good news: Problem Solving begins with Problem Awareness. Once your working environment triggers the attention of the right people on the right problems, the most trivial disappear by themselves, and the situation gets a little better.
I now think the next question should be: what is the thinking process of the best performing organisations for solving their problems? How can we apply it to our situation, in software development?
Waiting for the next article, I wish you a happy new year. See you in 2012!