I have met hundreds of organizations that are trying to improve their way-of-working. What I have found most interesting is that the vast majority of these organizations are looking for the solution outside of the company. They are either benchmarking with other similar organizations or running after the latest fashion in the industry. However the perceived benefits are not always there and the answer is usually much closer than they know.
Good industry standards are one thing, but many things that are good for a specific company are not necessarily transferable to another company with another background and culture.
In reality many solutions can be found inside the company. There are top-performers, top performing teams and projects in all companies and if we could repeat the good behavior from those individuals and teams, the organization could improve tremendously. However we need a structured way to capture that behavior so that it could be easily understood, distributed and reused; this is where using Practices makes perfect sense. Practices is a way to effectively describe the Essentials of Things to do, Things to Produce and the Competencies needed for a specific area of concern.
What good practices do you have in “your belly button”?
Last week, I attended a workshop of a new initiative in software engineering (SEMAT see www.semat.org). This was the first real f2f meeting we've had. 28 people attended the workshop and one session with around 12 people were working on developing more detailed objectives of the entire initiative.
In my last three blogs, I discussed how we can close the gap between the business and IT. I summed up the way forward with the advice to stop thinking about the business as the customer and IT as the provider. Instead, let them work together in teams (similar to members of a soccer team), responsible directly to management.
Many organizations have achieved a degree of process maturity (reliability, discipline, consistency) only by paying a very heavy price – they have become addicted to documents and document templates.
Software development processes have long advocated structuring a software solution around a domain model of the problem space being automated. A domain model shows how our business processes add value by progressing the states of our key business entities. These entities and their life histories tend to be much stable over time than the processes that surround them. Modeling the entities and their states enables us to experiment with different ways of achieving the same outcomes (state progressions) as we seek to rationalize and automate these processes.
I first learnt about the power of domain models more than 25 years ago when I first applied the Jackson System Development (JSD) process. This approach involves modeling the key conceptual entities in the problem domain and the business rules that define how value is delivered by advancing the value states of these key entities. Add a few key business attributes and you now have an executable model of your problem domain / business. You can then simulate the execution of your business merely by slapping some rough-and-ready user-interface screens onto these entities.
How many people know that approximately 40% of the cost of a truck are software costs or that it takes millions of lines of code to develop a mobile phone? The answer is unfortunately, very few. People do not view these things as software products! Software exists in so many things that we touch on a daily basis, but it is hidden under the shells of pacemakers, cars, etc., and the amount of software included in a “normal” product, grows every second.
To close the gap between business and IT we need to get them to play on the same team, as said in my two previous blogs. I compared this team with a soccer team in which the participants are not just specialists but also generalists – they can all kick the ball when called upon.
I was celebrating my birthday in Japan with a team I mentored. The manager was present and he asked me politely what my birthday wish was. I said I wanted to slim down without thinking much. It was something I wanted, but had not been succcessful. But through the weeks following that, by being conscious about calorie intake and output, spreading my food intake, reducing portions, adding some exercises, my weight reduced dramatically. I call it "dramatically" because I never lost that much. Within about a month, I lost 8 kilograms, and then another 6 the next month and another 6 on the third. I had to buy a new pair of pants twice. There were no dieting pills, no starving myself, no gym, but just some self-control, having daily stand-up meetings with my weighing scale and food calorie labels and of course some discipline and commitment with encouragement from weight logs. 
We in the software development industry face a seemingly intractable problem. We have learnt the lesson that prescriptive process is a bad thing. Process bureaucrats sitting in ivory method towers, telling highly-skilled professionals how to do their job and setting the process police on them if they don’t follow their instructions to the letter, can (unsurprisingly) be really quite damaging. It disempowers the development team and engrains apathetic attitudes along the lines of “When we inevitably under-deliver, it will not be our fault, but the fault of these ludicrous process hoops that we are forced to jump through, instead of being able to focus on writing great software”. The agile revolution was software engineering’s way of learning this lesson, and the agile manifesto pledge to value “people over process” and “software over documentation” has got to be right. But (… there was always a “but” coming …), we are already finding that the opposite extreme of little or no explicit process isn’t going to cut it either, because it leaves too many problems unsolved, such as: