Dr. Jacobson presented “Liberating the Essence from the Burden of the Whole: A Renaissance in Lean Thinking”. Ivar’s lively and engaging session clearly demonstrated to attendees the new reasoning around lean and that to stay lean you need to stay lean from the beginning of a project rather than trying to eliminate waste later.  By presenting three case studies representing business, software product and process method, Ivar demonstrated the concept of a “kernel” --representing the essence of something as a good starting point for most things you build.  You start lean and you stay lean throughout the life of what you build. 

Proven in many practical situations, the kernel concept provides the ability to scale up the use of agile approaches whilst maintaining control and visibility. Essentially, a kernel is composed of executable things, a blueprint, and principle and core values and these should be identified for anything we build.

The Kernel Further Explained by Dr. PanWei Ng

Following Ivar’s presentation, my fellow colleague Dr. Ng spoke about the kernel in more detail. He explained how one can use an agile approach with cards, which represent key elements originated from the kernel.  Panwei leveraged several case references to demonstrate to the audience that the kernel is not a concept; it is already widely in use at IJI consulting projects.

Use-Case 2.0

Following my two esteemed colleagues, I presented Use-Case 2.0. During my session, I attempted to provide a vivid example of how an existing practice can evolve to support a more agile way of working. A key feature of Use-Case 2.0 is “use-case slices”. These slices allow analysts, customers and developers to get what they need and the transformation from requirements to development becomes smoother.  Use-Case 2.o can support Scrum, Kanban seamlessly, and this facilitates the scaling of an agile approach possible. 

The event attracted more than 350 attendees and was held from 2:00 to 6:00 p.m.  The atmosphere of the conference was very warm. After the speeches, the audience showed much interest in the kernel, cards and Use-Case 2.0, and raised many questions. Due to the time limit, the host had to stop the questioning and announce the closure of the conference. The event will definitely increase the awareness of IJI in China, and let more people know about IJI’s role in agile development.

I look forward to the next TUP event.

Can it be turned around?

Implementing corporate change can be one of the toughest challenges for large organisations. Software development departments that want to scale their agile projects often run into this obstacle. The agile project that may have been extremely successful within a small team or department begins to crack and fall apart as the organisation attempts to scale Agile. 

At IJI, I work with large software development organisations helping them implement effective change across geographies and cultures.  One of the key ingredients for implementing successful change is the development of a strong coaching community. We’ve used this approach at numerous organisations. KPN is one example. At the moment we’re assisting a large multi-national insurer develop their coaching community in Europe and North America as part of their change program to move from a Waterfall development approach to Agile.

Developing a coaching community is critical. What’s the point in investing in a new way of working if key people in the organisation are not all in agreement on a better, smarter way of working? The goal is to create consistency across regions.

Define Your Coaching Community

One of the first steps is to define your coaching community, such as:

• What is a coach?
• What are the core characteristics that a coach must exemplify?
• How should coaches be distributed geographically?
• How many employees will each coach support?
• Will coaches be full-time coaches or will they coach as part of their job?

I believe that coaches must be practitioners. It’s also important that coaches are volunteers. Often coaches volunteer themselves by being interested in and offering help to their colleagues. They should not be assigned by management without their consent. An unwilling coach is a waste of time and can have a very negative effect on a change program. The energy and momentum that the coaches build in the transformation and adoption of improved ways of working needs to be protected and nurtured to allow for the success of the initiative.

Defining a coach is only one of the first steps in building a vibrant coaching community. In my next post, I’ll share with readers how to kick-start their coaching community.

It was an evening to share our experiences and update our guests on IJI’s recent activities and developments.

Ivar Jacobson, Svante Lidman, Graham Marsh and I presented IJI at the event and presented topics ranging from Scaling Agile to our new Use-Case 2.0 that our customers are currently using.

Svante Lidman presented an engaging and interesting presentation called “Learning’s from Large Scale Agile Transformation”. Svante discussed how a large client with thousands of developers and a large legacy system who was following a waterfall approach to software development is now making a successful transformation to becoming more agile.

Ivar updated attendees on Use-Case 2.0 (read Ivar’s previous posts for more info on this topic) and also presented Semat and Liberating the Essence from the Burden of the Whole: A Renaissance in Lean Thinking.

If you would like to be on our mailing list to be invited to one of our future events, drop me an email.

Quotation source: www.brainyquote.com.

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.

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.

Agile software development has made a huge impact and has been quite successful in the industry for the past decade. Building on the principles of agile, the presentation of “The future of agile development: a light weight software engineering kernel” given by Dr. Panwei Ng, the Principal Consultant and the Asia-Pacific CTO of Ivar Jacobson International, made the next wave in the agile world. Dr. Ng’s talk was part of an invited speech on New Agile Trends.

Dr. Ng introduced a new way of making agile systematic and scaleable, through the use of alpha state cards. He also demonstrated case studies representing small to large projects. Dr. Ng's speech was humorous and engaging. He started his talk by saying that he has lost 20 kilograms in 3 months, and has maintained the weight ever since. So he felt he is qualified to talk about lean and reducing waste. The room was packed by a curious audience who were eager to know the concept of “software engineering kernel”.
The concept of kernel is at the heart of Semat – Software Engineering Method and Theory, an initiative launched in December 2009 by Ivar Jacobson, Bertrand Meyer, and Richard Soley. (www.semat.org). 

Dr. Ng is a member of Semat China Executive Committee. He explained the concept of Kernel which is  “A common kernel of underlying concepts and principles applicable across all methods that may be used to define various practices.” To further elaborate the concept, the kernel includes the essence, pervasive concepts and qualities of software engineering – the common ground – Irrespective of code, software system, solution, methods, and organization. They are always prevalent in any software endeavors, for example, Work, Team, Requirements, Software System, Way of working, Stakeholders, and Opportunity.

Dr. Ng discussed how the kernel is presented in a lightweight manner in the form of cards and guidelines. It is simple to learn and yet very powerful and embodies the spirit of lean and agile development. Very vividly, he was like a magician when he showed how these tiny, yet succinct but extremely powerful cards help software development become systematic and scalable to large projects.

The concept is that state cards are building blocks to help teams become systematic, help teams scale, help teams collaborate better, and help teams mature in their practices. Alpha state cards compact the essence of software development into a small deck of cards that fit into your pocket. You use it to drive iterations, plan projects, assign work, design teams, and so on. It is a simple but extremely powerful tool for your development team and organization.

Examples of State Cards

Examples of the state cards with each card includes alpha name, alpha state name, and alpha state indicator, which are shown above.  Dr. Ng showed how to take concrete steps towards using them. He explained that this is achieved by overlaying further checkpoints, guidance and examples on top of state cards. The state cards being visible to the team on a daily basis bring the new practices to effect quickly.

Dr. Ng's presentation on the use of cards to demonstrate and apply the concepts of kernel, alpha, and state in real projects was an eye-opening experience for the audience and generated an overwhelming response after the talk. People rushed to the IIJ booth and asked for sample cards and how to get further information. Finding and apply the software engineering kernel has made the next wave in the agile world.

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

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).

Waterfall planning is founded on a complex system of interrelated beliefs:

• Products can be completely developed in one pass
• Requirements can be completed and frozen early
• All requirements are of equal importance
• Designs can be verified without building and testing something
• The entire project can be planned in detail with a high degree of precision at the start of the project
• Everything important can be known at the beginning of the project
• The project can “earn” value by only doing one discipline at a time
• Most importantly, if we follow the prescriptive steps of our process, then all the project risks will be addressed, and therefore one should measure teams on their ability to follow a plan and managers on their ability to create a plan

The focus of all waterfall methods is on optimizing the steps in the process to eliminate repetition and rework and to detect problems through detecting deviations from the plan. In short, the plan is usually regarded as perfect, and deviations from the plan are considered undesirable.

Why Conventional Planning Wisdom is Wrong When Applied to Software

The short explanation is that almost every one of these assumptions is wrong when applied to software. Software development is an immature discipline, typically requiring extensive innovation and invention, rather than a mature discipline guided by generations of experience. Software projects are also typically unique in that we do not build the same things in the same way over and over again.

We are usually building something new or rebuilding something in a new way - software is typically a response to the needs of a changing business. In addition, innovation in software development technologies proceeds at such a blistering pace that in addition to changing business conditions, the implementation technologies are constantly shifting.

In opposition to the assumptions underlying the waterfall methods, we find that:

• Problems are discovered too late to do anything about them.
• Predictive plans do not provide the flexibility and adaptability required to handle extensive unknowns.
• Early commitment to detailed requirements is counter-productive.
• Undertaking only one activity at a time separates teams, reduces effectiveness, and creates adversarial team relationships.
• Only obtaining feedback from the next sequential activity delays the detection of errors and problems.
• The plan does not adapt to the risks facing the project.
• Integration and testing are always left until the end where, more often than not, they are cut back in an attempt to meet the original delivery date.
• Design feedback is obtained late, usually leading to late design breakage, when it is too late to fix problems in the architecture.
• Because the objective feedback provided by demonstration and testing is only obtained late in the project, risk resolution typically occurs too late to be effective.

The adoption of waterfall practices means that the problems are typically concentrated at the end of project, which is unfortunate because the majority of the budget has already been consumed and it is often too late to fix the problems.

The failure of the conventional wisdom about planning, especially for high-value, high-risk projects, has led to the evolution of a more progressive school of thought and the foundation of iterative development.

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.

Better, Faster, Cheaper, Happier - This is what “Agile” means to the business.  Things like Continuous Integration, Test-Driven Development, and Scrum are only useful if they help us get better software; faster time to market; cheaper products, and happier customers. To ignore these, and other, business demands is nonsense and one of the key factors in widening the gap between business and IT in many organizations. To be honest businesses don’t care about how “Agile” the IT organization is – unless it is noticeably contributing to their goals to be better, faster, cheaper and happier. Measurements of agility are, like measuring CMMI, at best secondary measures and only useful as evidence of how you succeeded once you have achieved your goals.

Imagine, if you can show the value and the results that IT is generating in a way that business can understand? If you can demonstrate that you are getting better, faster, and cheaper whilst taking on-board your customers’, users’ and other stakeholders’ concerns and making them happier with happier employees? If you do, you can really start to close the gap and bring the business and IT together.

What’s All This Nonsense about Happier?

I must admit some people get uncomfortable when the happier aspect of the scorecard is introduced but this is an essential aspect of successful software development that often gets forgotten.

You really need to think about how people feel because otherwise you can be hitting all your deadlines with the right quality levels and fulfilling all the requirements, and you can still have unhappy customers and unhappy users.  When people love things they give you lots of feedback. When they don’t love something, there is often silence. Don’t mistake silence for approval.  

I remember reading an article once where someone claimed that their software was developed so well that they did not need to have a change request system because no user had ever had a change request. They felt that their software was perfect.  I suspect the correct interpretation was that no one had a change request because no one was using their software. 

You need to get qualitative information; you need to ask everybody whether ‘they’ like the software; whether ‘they’ are using it; whether ‘they’ feel they are getting value for money.  Gather qualitative as well as the quantitative data and make sure that you have practical measures that focus on the real goals of the business:  the business as a whole and the business of the IT organisation.

Some people become so focused on financials or on secondary measures that they forget to think about the most important goals.  Do you have happy customers?  Do you have happy teams?  Don’t forget these very critical questions.

Measuring happiness is very important.  Are you really your business’s preferred supplier? Do your customers feel that they are getting value for money? Are you really a company where the newly trained and empowered agile developers want to work and continue their careers? These are all qualitative measure that you should look at and are very important in one of the key areas that IJI sees everyday: a growing distrust between business and IT.