A Common Thread Among the Agile Methodologies

Agile is an interesting phenomenon. It is a practical “philosophy” that has become a movement with multiple denominations –

Scrum, XP, Kanban, Lean, as well as eclectic practitioners who do not ascribe to any denomination or brand of methodology.

Having multiple interpretations and implementations of the Agile approach to product development is fine, as long as we are aware that no one “brand” is the ultimate one; the one that will eliminate all the others.

A development methodology is the interpretation of a way to develop the product. There can be many valid interpretations. It is like choosing any important product, why reinvent when you can pick one and adapt it to your needs.

Methodology

We need methodologies. They provide a road map, principles, guidelines, forms and templates and promote discipline and precision. They help to make terminology and practices consistent across projects. Effective methodologies carry the essence of the philosophy and enable practitioners to achieve optimal performance.

While some practitioners can operate on their own without the structure provided by a methodology with its guidelines, forms, and steps, others are not comfortable creating a process on the fly.

Creating the process without considering past performance makes continuous improvement more difficult; we do not carry best practices forward. Methodologies work best when:

1. they can easily devolve into bureaucracies and
2. they are a starting point for an adaptive process – a process that can be adapted to meet the needs of changing circumstances – as opposed to laws that must be followed to the letter every time.

The Essence of Agile

Agile methodologies are influenced by a combination of agile and quality management principles. The underlying principles are expressed in the Agile Manifesto in which its authors value:

The basic principles of Agile:

1. Above all, satisfy the customer, delivering value quickly and continuously.
   a) Deliver working software frequently, within no more than a month of two
   b) Maintain a constant and sustainable development pace.
   c) Measure progress regarding delivered software.
2. Enable and accept changing requirements, even late in development.
3. Engage product owners and developers in a unified team.
   a) Create and empower effective teams.
   b) Recognize and promote the power of face to face collaboration.
   c) Self-organizing teams produce the best architectures, requirements, and designs.
4. Recognize that technical excellence and good design enhances agility.
5. Simplicity — only do what is necessary.
6. Continuously improve through regular and frequent process evaluation.
7. Take a both sides approach.

This last principle is implied in the Agile Manifesto’s statement “That is, while there is value in the items on the right, we value the items on the left more.” This principle is often overlooked by Agile zealots who devalue documentation and contracts for a seat-of-the-pants approach.

The Quality Management’s Influence

The quality management movement strongly influenced Agile. Lean and Kanban software development approaches are based on the methodologies used in manufacturing to minimize waste and promote highly effective results with control at the team level. The principles here are:

1. Visualize the workflow to make it clear and explicit to make control easier
2. Limit work in process to remove pressures to multitask and to promote timely delivery of product
3. Manage the flow of work to achieve 2.
4. Explicitly state process policies – have a defined process that everyone knows and follows
5. Improve continuously by collaboratively analyzing performance and changing the process.

These overlapping principles are the foundation for Agile methodologies. They boil down to:

• Collaborate
• Accept and enable change
• Deliver useful and quality product in a timely manner
• Manage the flow of work to performers
• Don’t waste time on unnecessary tasks.

Evaluate and Improve

Essential to any methodology is an attitude that the methodology is never finished. There must be an ongoing evaluation of the methodology, tools, and techniques in the context of your organization and its projects that lead to continuous improvement.

Evaluate your methodology regularly, as an integral part of project performance reviews, to make sure that the essence has not been lost to overzealous adherence to the letter of the law or to an unskillful interpretation of principles that leads to neglected documentation, formal agreements and project management.

Adaptability

In addition to including continuous improvement, the effective methodology must enable performers to adapt to situational needs. Every project is unique. Variations in scope, cost, significance to the organization and the availability and quality of resources require taking a creative approach to the way the methodology is applied.

In a project, the availability of knowledgeable users/product owners and developers will influence the degree to which a purely agile approach can be used. Agile requires a mindset change for development management. The involvement of the developers in work sessions that address user stories and requirements must be valued and planned for.

The mindset of product sponsors and business management, in general, must acknowledge the role of the “users” in the development process – it is not about defining a set of requirements, throwing them over the wall to the development and then getting the desired result. Instead, experience has shown that requirements and the product itself evolve. The choice is to enable that evolution during the product by engaging the product users and owners or to have the evolution take place in the operational environment after the product has been delivered.

In Agile, the evolution of the product is facilitated during the project itself. The product will continue to evolve once in production and operational use. However, Agile seeks a greater likelihood that the true requirements will be met in the initial delivery and that will minimize post-delivery changes.

Remember the Big Picture

Whatever Agile approach you use, keep in mind that Agile addresses the development stage of projects in which detailed requirements are defined and transformed into a product within a solution architecture to satisfy organizational needs.

A principle difference among Scrum, Extreme Programming (XP), Lean and Kanban is in the emphasis on particular goals; though the common goals are always the same – collaborate to deliver value frequently, expect and enable change and do no more work than is needed to produce a high-quality product. All of them offer useful and effective templates, guidelines and practices that make the work of the team more efficient and effective.

Scrum and XP are focused on software, often without ample consideration of the training, procurement, documentation and organizational change aspects of the product. Lean and Kanban more clearly address software development as one part of a larger project.

It is important for the developers to understand that an Agile approach does not eliminate the early stages of a waterfall methodology. Agile development is about development. There is still a need for the definition of high-level requirements to drive project approval and prioritization, set the stage for solution architecture and design and provide the source for the lists of user stories that the developers will deliver.

With Agile’s essential principles in mind choose your Agile approach carefully, as if you were selecting any important product, and be prepared to tweak it to suit your needs.