24 Being Agile with Practices and Methods

Agile development has seen significant growth since its beginnings when the agile manifesto was first declared in 2001. At that time, many organizations were focused on heavyweight processes and contract negotiations with less focus on the needs of development teams.  Since then, many teams have embarked on agile development. There are many agile practices, but the end of it all it is not about doing agile (which practice to apply), but being agile (with a learning and adaptive mind-set).

24.1 Agile Manifesto

In today’s fast changing Darwinian world, survival is about the ability to adapt quickly. The industry has deemed agile development as a major means to achieve adaptability. In 2001, a group of software engineering pragmatists came together to discuss how to overcome challenges faced by industry. At that time, most software development endeavors were using a so-called “waterfall approach”, which took years to complete, and were not really delivering what customers or users needed. These experts had been successful with their (at that time) new approaches and were constantly improvising and innovating. They summarized what they believed in as a manifesto. The agile manifesto: 

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.“

Perhaps the most agile statement in the manifesto is that “We are uncovering better ways of developing software by doing it and helping others do it”. It is this continuous striving to being better that spurs learning and advances in software development, not just in the industry, but in every team.

Every team has its own unique development context; they work on different kinds of development, their members have different levels of experience and backgrounds. They can be working on small or large-scale development. But in all these situations, a team can always collaborate and grow together to become better. It is this continual adaptation to the development context and continual learning that being agile with practices and methods is fundamentally about.

Since then, agile has gradually been adopted by the software industry, not just as a software engineering mindset, but even a business mindset because software is becoming an integral part of every business.

24.2 Agile Working with Methods

The authors of Essence Book (reference Original Essence Book) take the values and principles of the agile movement to another level by providing tools for teams to explicitly evolve their way of working.

In contrast to many previous method initiatives the focus of SEMAT is on those who know best what works and what doesn't work when building software systems.  That is, architects, analysts, designers, programmers, testers, and software managers. This takes a change in mind-set.  It requires a change in the way you think about methods, just as moving to agile development from traditional development (e.g. waterfall life cycle) requires a change in your mind-set on how to develop software. 

What are the mind-set changes you need to be aware of?  To some extent they differ from the Agile Manifesto[1], but they are inspired by it:

  1. The full team owns their method, rather than a select few
  2. Focus on method use rather than comprehensive method description
  3. Evolve your team’s method, rather than keeping your method fixed

We delve deeper into each of these mind-set changes in the following sections.

24.3 The Full Team Owns Their Method

Traditionally, there is a dichotomy between method engineers and method users (i.e. developers).

  1. Method engineers who define methods often do not use the methods themselves.
  2. Method users who acquire real experiences with methods, often are not asked, or do not have time to give feedback and refine the methods they use.

As a result, method users often find method discussions to be out of touch with their real experiences and therefore a waste of time.

The kernel approach seeks to bridge this divide by placing a proper balance on all stakeholder perspectives. It recognizes the value of every team member in determining what ways of working work best for their team.

The Essence kernel can assist this proper balancing through the use of the alphas, states, checklists and describing a team's own method through a composition of practices.  Examples include:

  1. Conducting retrospectives guided by the alphas and their states.
  2. Defining practices on top of alphas and their states.
  3. Using alphas and states to agree on team member involvement and team responsibilities.
  4. Using alphas and states to define lifecycles.

The alphas and their states and checklists provide a very simple but powerful tool, which team members can employ to take ownership of their own method.

24.4 Focus on Method Use

Traditionally, when most people talk about methods they are thinking in terms of method descriptions. Having a method description is a good thing in that it allows new team members or even existing team members to familiarize themselves with the team’s method.  Too often, however, these method descriptions fall short in communicating what team members really do in their day to day work.  Unfortunately, these method descriptions have often become too heavy-weight. This has only served to make the process description less, rather than more, useful. 

This dilemma is not best solved by more words, but rather by fewer words and more use.  How do teams and team members actually use methods to help them in their day to day jobs? Consider the following needs with respect to a team’s methods:

  1. Teams need a way to determine real development progress.
  2. Teams need to plan their endeavors, their sprints, and they need to discuss and agree upon what it means to be done.
  3. Teams need to organize their team members, agree on team member involvement and responsibilities.
  4. Teams need to do their work and adapt their way of working.
  5. Teams need to scale to varying size endeavors to handle varying challenges and complexity.

24.5 Evolve Your Team’s Method

There is no one-size-fits all when it comes to methods. This implies several things:

  1. You cannot simply take any method and follow it blindly. All methods must be adapted to fit your situation.
  2. Once adapted to your current situation, you are certain to learn more as your endeavor proceeds, requiring more adaptations. 

A team's method is never fixed.   Teams must constantly evolve their method as long as there is work to do on the product.  This implies two fundamentals:

  1. Always be ready to embrace new and better ways of working.
  2. Always consider your current development situation when considering a change.

Evolving a method is straightforward with the kernel approach. You start with the kernel, and evaluate the practices you already have. Practices that are inadequate are then refined or replaced with better ones.  This is best done gradually so continuous improvement becomes natural and not something you need to think about at great length.

Making continuous improvement a natural habit is easier said than done. It takes effort and proactive leadership and culture. So, on top of having a practice architecture, great organizations invest in creating a conducive environment to promote continuous improvement. Our approach of decomposing complex methods into much smaller practices help teams take ownership of their methods and the outcomes of using them.