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.

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

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. Read More