Another week, another event! This time it was the turn of the Agile Business Conference in London. It was encouraging to see an excellent turn out for this 3 day event, and an overwhelmingly positive attitude from delegates, speakers & sponsors. The thing that most struck me about the whole experience was that agile software development really is breaking out and growing up. This was a conference not just for people wanting to know what it’s all about and how to get started, but for people that want to improve and grow, and use agile in ever more complex and challenging environments. But in the words of the famous american baseball player, Casey Stengel: “The trick is growing up without growing old”....let's hope the agile movement is not just another fad in the development of the software engineering profession.

Quotation source: www.brainyquote.com.

It was great to see Ivar Jacobson present the award last week to Christine Henly of Allianz. Christine was one of a group of five Business Analysts from Allianz, Barclays, Lloyds and The Post Office that were shortlisted for the award – so well done Christine!

Ivar presented the award just after his (typically amusing) key note speech in which he introduced Use Case 2.0 – an elegant bringing together of the popular and powerful use case approach with user stories, which is currently much in vogue with the agile community. Use Case 2.0 provides an agile requirements approach that scales for large and complex systems development.

In this photograph, Christine is flanked by Ivar Jacobson (left) and AssistKD director Paul Turner (right). Picture Source: AssistKD

Learn more about the conference and the award program by visiting the IIBA event website.

The 6th annual Agile China was held in Beijing from September 1 – 3, 2011. Agile China is a summit of agile world enthusiasts gathering in China. For the past five years, it’s attracted world-class agile experts, such as Martin Fowler, Kent Beck, Dave Thomas, James Grenning, and Mary Poppendieck et al, and tens of  thousands of attendees across China and overseas. It represents the highest level of development and adoption of agile development in China.

This year’s conference proved to be another successful event. The three-day event was packed by some 700 attendees. The conference was opened by Mr. Wang Jun, General Secretary of China System and Software Process Improvement Association, the host of the conference, and keynote by Linda Rising, the authour of “Fearless Change”, followed by parallel sessions on agile training camp, agile new trend, and agile testing and quality control. People gathered to share their experience and to explore new ideas and  trends. The conference atmosphere was full of energy and excitement. Particularly, I truly enjoyed the free style of discussions and presentations – in a real agile spirit. Read More

Understanding the potential barriers to change will help you make the right choices of timing, project, and approach. Some of the more important questions to ask include in the following:

• How supportive is senior management of the change? The measurements and milestones
  they establish can easily derail an iterative approach, as is the case when they ask even seemingly
  innocent questions such as “When will the design be completed?” or “When will requirements be
  signed-off?”
• What is the scope of your authority to make changes? How much of the development lifecycle
  are you responsible for? For example, the requirements might have already been specified in a
  format and to a level of detail that would make it more difficult to adopt an iterative approach.
• What are the team’s feelings about the changes? How enthusiastic is the team about iterating?
  To achieve the transition to iterative development, you will need the support of the team,
  especially the other members of the leadership team.
• What else does the team have to do? How many other projects and initiatives is the team involved
  in? If the team is not focused on and dedicated to the project, the transition to iterative
  practices will probably be slower and take more time and energy to complete.
• What capability do you need to improve? It is important to understand the capability of the
  team and how well the current capability supports the proposed iterative approach. For example,
  is there any testing capability in the team? Testing will be needed from the first iteration, which is
  often a problem in companies organized around the phases of a waterfall approach. Read More

The progressive, adaptive, iterative approach is founded on the following principles:

• Proceed in small steps, continuing steadily by increments.
• The plans must adapt to the project’s changing circumstances.
• The characteristics that distinguish the product or service must be progressively elaborated.
• They should be broadly defined early in the project and made more explicit and detailed as a better understanding of the project emerges.
• Large projects must be broken up into smaller projects.
• Requirements errors can be 100 times more costly to fix after deployment than at requirements time.
• Initial estimates have a large margin of error—most waterfall projects cost two to three times what was initially predicted.
• The first one never works; always develop things at least twice.
• Initial designs will be flawed.
• Requirements must evolve alongside demonstrable versions of the product.
• Teams need to own and be accountable for their achievements and plans.
• You should believe the project results, not the project plan.
• Detailed planning should be limited to the next milestone.
• Projects should adopt an active and aggressive approach to addressing project risk.

Progressive, iterative processes were developed in response to the problems inherent in the waterfall approach. Instead of developing the whole system in one go, an increment is selected and developed, then another increment, and so on. The selection of the contents of the first increment is based on risk, addressing the highest-priority risks first. To address the selected risk(s), select a subset of the requirements to be implemented and tested. Develop the minimal set of functionality that enables objective verification (through a set of executable tests) that the risks have been successfully addressed. Then select the next highest risks to be addressed in the next iteration, and so on.
One of the great ironies of modern software development is that in the paper that led to the popularity of the waterfall approach to software development, Winston Royce argued that projects should always go through at least two development cycles because the first version never works. He was actually arguing that projects should take a more incremental approach, not that they should adopt a prescriptive waterfall development approach. Progressive, iterative approaches take this principle one step further by splitting the lifecycle up into many smaller increments, each explicitly addressing the project’s major risks.

As discussed in an earlier blog post, you need to measure the desired results.  If Agility and Agile Transformation is going to make you better, then look at the things it is going to make better and set some targets.  If it is going to make you faster, then look at the things it is going to make faster and again set some targets and track against them.  If it is going to make you cheaper and happier, then focus on those things.  This approach begins to make your measurement framework much more inspirational.

Historically, many organisations struggle with their Organisational Measurement getting any traction.  I have seen many organisations where every year they introduce some key performance indicators and by the end of they year, they have abandoned them.  I have seen many organisations with large dashboards with graphs no one understands and no one looks at but a lot of money is spent on them.

You need to change this whole approach.  Measurement needs to change at the organisational level to become more agile – valuing people over processes – collaboration over contracts etc. All the great things from the Agile Manifesto should be visible within your measurement program as well. 

A balanced scorecard organized around the four goals of better, faster, cheaper and happier is a great place to start.  Recently, we worked with KPN and implemented a organizational measurement program using the better, faster cheaper, happier framework. It was an excellent framework for their organisation. It allowed them to look at what is important in terms of getting better – Were they becoming more predictable and were they delivering a higher level of quality?, faster – cheaper - , and happier -    The framework allowed them to look at the problem areas and phrase questions that business and IT could understand. It was so successful that everyone in the whole organization, including the business, embraced the measures with both enthusiasm and commitment. See the case study / webinar for more details.

A better, faster, cheaper, happier balanced scorecard provides a way to communicate the effectiveness of IT in a way that everybody in the organisation can embrace and understand. It also allows you to measure success in a way that is independent of the processes used by the projects and teams being measured – essential if you want to demonstrate that an agile approach is better than more traditional approaches or build a platform to enable you to continually improve and adapt your agile way-of-working.

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.