Ivar Jacobson International » Pan-Wei Ng | Ivar Jacobson International

Light Weight Software Development Process #2

Pan-Wei Ng — Wed, 01 Dec 2010 14:00:38 +0000

The Software Development Process Challenge

*The first post in this series can be read here

Before I describe the deck of cards, I’d like to set the stage for using the cards. We can view software development from three time-scales (see Figure 1). Successful software development process is in essence, being able to coordinate the three time-scales effectively.

The broadest time scale covers from the beginning to the end of a software development cycle which is marked by several key business decision making milestones. This is of great interest to stakeholders and decision makers on whether development can proceed or whether the software is suitable for release.
The next time scale breaks the lifecycle into time-periods – months, or weeks, or what is known as an iteration. It is a fixed time-box where a number of target objectives are to be met by a development team. If there are multiple teams, then each team would be assigned their specific set of objectives. This is where team leaders operate.
The lowest time scale is what a team member does. The work done here can be in terms of hours or days depending on the complexity of the work.

Figure 1:The Three Perspectives to Software Development.

A major problem I see in many development organizations is the serious disconnect between the three levels. The objectives set at the higher level do not easily translate to work at lower levels. Lower levels are unable to see their contribution to higher level objectives. There is a miscommunication between the levels, and poor coordination within the same level, which leads to blockages which should not even happen. We need to solve this.

Light Weight Software Development Process using State Cards

Pan-Wei Ng — Tue, 16 Nov 2010 01:38:57 +0000

It is a well known fact that all software is different; all software development teams are also different. So, why should we expect software development processes be fixed? There is no such thing as “one size fits all.” Yet, it is also common sense that there must be something in common, as otherwise there is absolutely no way to learn from experience and mistakes. The challenge is then, to find a middle ground that is easy to communicate to the development team and stakeholders. In the next few blog postings, I will present a pragmatic approach using a deck of A8 (5 1/4" x 7 7/8") sized state-cards that is small enough to fit into your pocket. I will demonstrate how you can use the state-cards to understand the state of software development, how to define your lifecycle model and how you can use it to define your value streams. It is important to get your team to define and own their software development process and state-cards provides the building blocks to do this.

The posts to follow on this topic include:

1. The Software Development Process Challenge

2. A Solution through a Deck of Cards

3. Dynamic Software Development Lifecycle with State-Cards

4. Lean Iterative Management with State-Cards

5. Organizing Design of Lean and Agile Teams

6. Effective Work Assignment Using State Cards

7. Applying State-cards to Manage Software Development

Detox, Slim Down and Shape Up – Becoming Lean and Agile

Pan-Wei Ng — Tue, 02 Feb 2010 15:47:25 +0000

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.

In the midst of this, I was invited to give a talk on agile development in Singapore. Naturally, I decided to use my weight losing experience as an analogy to introduce lean to the audience. The talk has a similar title as the title of this blog. During the talk, I asked the audience of about a 100 if they wanted to lose weight. 30% raised their hands. I said that they would learn how to lose weight as individuals, and become lean as development teams, which certainly resulted in a number of smiles.

The analogy between the weight management industry and the software development are surprisingly similar. Everyone wants to be slim, trim, sexy and healthy. Every software team wants to do things faster, cheaper, and better. Today, we replace the faster, cheaper and better with another adjective -"agile". Of course, we want to be agile. The weight management industry has so many dieting programmes, also called fad diets -Atkins Diet, Stillman Diet, Cambridge Diet, Mayo Diet, and many more. One of these diet (Stillman Diet), was what Karen Carpenter used before she died on 3 Feb 1983. In the software development industry, we have no shortage of methodologies - XP, SCRUM, use case driven development, feature driven development, test driven development, component based development, etc. There have been successes, and likewise failures. The overweight individual is frequently at a loss what to do. The software team is also frequently at a loss which method to apply.

The parallel does not stop there. The reasons why individuals gain weight and why software teams lose their edge are remarkably similar. The reasons why individuals fail at losing weight and the reasons why software teams fail in adopting agile are also very similar. The only difference with weight management and software teams is that weight loss is for the indiviudal, and software development is a multitude of individuals, which add to the complexity. Nevertheless, the parallels offer something which we can learn.