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.

Last June at Innovate 2010 in Florida Kurt Bittner envisioned the new role and responsibilities of the next generation business analyst. If you were not able to attend, his presentation is available online so you can check it out: Transforming the role of the Business Analyst. The need for a different role and responsibilities is to provide solutions for ongoing problems a lot of companies are faced with. These are common problems like:

• Users expecting  functionality they did not initially ask for
• Users demanding functionality they will never use
• Contradictory of conflicting requirements

In order to be more successful, a number of changes are to be made and lessons are to be learned. One of them is that business analysts need to be more focused on desired outcomes rather than features. And another is that business analysts need to probe into root causes rather than being satisfied with just identifying the wants. Being focused on outcomes and unraveling root causes can be hard work and sometimes it is easy to mix them up or to get stuck. A smarter way it is to be more aware of the language that is used for questioning and context frames . Read More

Nowhere is the change in values of iterative development planning and measuring more important than in the management team. If the project is to iterate successfully, it must be managed iteratively.

The project manager must believe that an iterative approach is the best way to manage the project and must be prepared to set aside any inflexible, predictive, waterfall management practices that have been used before. This doesn’t mean that you should throw away all the good management practices and experiences you have built up over the years; good, disciplined project management is essential to the effective application of iterative development techniques. It is just that you must put aside some of the conventional wisdom about planning to give yourself the freedom to fully exploit the flexibility and power of the iterative approach.

The conventional approach to planning is prescriptive, based on the assumptions that the work which needs to be done can be predicted with great precision and that the unusual rarely occurs. This is true for many things—building a bridge over a highway or a standard family dwelling or a prefabricated commercial building, for example. These engineering efforts are technically predictable, and planning this kind of work is based on hundreds of years of experience. This experience has given rise to the generic project lifecycle in which the different types of project activities are aligned to the single phase that bears their name (i.e. Requirements, Analysis, Design, Code, Test and Deploy). Read More

Adopting an agile approach has a lot of benefits, not just when developing software and improving team working but for all aspects of our business. When it comes to measurement, I recommend that we all take an agile approach and keep things simple, open and adaptive to change. 

A simple, intuitive score-card is essential for any team or organization embarking on any form of agile adoption or transformation. The Better, Faster, Cheaper, Happier framework provides a great starting point for motivating and measuring your changes.

Agile: What’s the Point?

Let’s stop and think about why businesses get involved in agility.  What is the promise of agility that is so attractive to businesses?  What we at IJI have found when talking to business people is that agility is appealing because of the belief that better products will be built.  Not only will they be better software products but they will be built faster and cheaper than before. The promise is certainly there  and this is what people want to see as they make investments in agile adoption and, in particular, any kind of large scale agile transformation. 

The other significant result claimed for agile ways-of-working is that there will be an overall increase in everyone’s happiness - happier customers; happier users; happier sponsors; happier purchasers, and happier developers. Read More

Mijn collega Kurt Bittner heeft afgelopen juni  tijdens IBM Innovate 2010 (Florida) zijn visie gegeven op de nieuwe rol en verantwoordelijkheden van de nieuwe generatie informatieanalisten. Wanneer je geen kans hebt gezien om zijn presentatie bij te wonen, bekijk die dan via Slideshare: Transforming the role of the Business Analyst. Hieronder volgende enkele observaties of veel voorkomende problemen die hebben geleid tot zijn visie:

• Gebruikers verwachten andere  functionaliteit dan waar ze oorspronkelijk om hebben gevraagd.
• Gebruikers eisen functionaliteit die ze nooit zullen gebruiken
• Gebruikers geven tegenstrijdige of conflicterende requirements Read More

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

We are looking for Principal and Senior Consultants in North America and Sweden.  Interested? View the links below for more information on the position and to apply.

North America

Sweden