Agile is not a noun

The very attractiveness of the term has resulted in an unfortunate proliferation of “Agile” for everything, often without understanding the context in which the ideas were formulated and the intent behind the approach.  This has resulted in a proliferation of “tragile” implementations which have harmed the reputation and perception of Agile development in the market.

The reality is that the Agile values and principles provide a solid foundation for maximizing the delivery of value and optimizing the outcomes for any knowledge intensive project which relies on human creativity to be successful. Agility in business is a necessity today as the pace of change and the rate of innovation increases.  What makes you successful today doesn’t guarantee that you will continue to be successful tomorrow, in fact you are almost guaranteed to fail tomorrow unless you are adapting constantly.

Agile for Software Development

Through the 1980s and ‘90s software was becoming a key part of most organisation’s ability to deliver value to their customers.  Software proliferated through most areas of the business world and into the personal lives of people in the developed world.  The growing pervasiveness of computing and the dependence on software brought into focus troubled projects and the challenges of building software systems.

As far back as 1968 “the software crisis” was identified, with organisations struggling to build the right products and lots of wasted money building the wrong thing.  Ideas from civil engineering were borrowed and rigorous approaches based on the construction model were applied, without much success.  Software development is not the same as building physical things and a predictive, sequential model of development does not work.

Alongside attempts to apply a predictive, sequential approach to software development, other approaches were being implemented, generally these were based on ideas of rapid feedback, learning and responding to evolving user/customer needs and technical excellence to make change easy to accommodate.  As far back as 1970 the EVO (Evolutionary Project Management) method was being applied to software development and these approaches were generally more successful than the plan-driven, predictive approaches being used elsewhere.

Through the 80’s and 90’s ideas and brands emerged which took a fundamentally different approach to building software.  Brands such as Scrum, eXtreme Programming, Adaptive Software Development, Feature Driven Development and models such as the Unified Process and RAD (Rapid Application Development) emerged.  Figure 1 shows a timeline of the various brands and ideas leading up to the Agile Manifesto and into the 21st century.

February 2001 was a watershed moment in the timeline – a group of practitioners got together at a ski resort in Snowbird, Utah, with the express intent of exploring areas of common ground in their practices.  They represented a variety of brands and approaches with both competing and complimentary ideas.  They didn’t have a specific intent in mind beyond exploring their ideas.  This informal gathering had a profound effect on the software development industry as it was over this weekend that the term “Agile” was coined as a unifying concept across the various approaches.

Figure 1: Timeline of Agile Development Methods and Brands

Over the conversations that weekend the participants were trying to find a term which they felt comfortable with using to describe the common aspects of their approach.  Lightweight was rejected because it didn’t convey the rigor and discipline that is so important in good software engineering and some of the participants were working on life and safety critical systems where lightweight was not an acceptable concept.  After much debate “Agile” was chosen as a term which conveyed both the discipline and addictiveness which was the intent of the authors.  Agile like an Olympic athlete is Agile – highly skilled, highly disciplined, able to change direction on a moment’s notice without breaking the flow of the activity.

The output of the meeting was a document – a simple manifesto for software development.

The Manifesto for Agile Software Development

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.

- Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland and Dave Thomas.

© 2001, the above authors, this declaration may be freely copied in any form, but only in its entirety through this notice - http://Agilemanifesto.org/

Principles behind the Agile Manifesto

We follow these principles:

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development.
• Agile processes harness change for the customer’s competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals.  Give them the environment and support they need, and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development.
• The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity—the art of maximising the amount of work not done—is essential.
• The best architectures, requirements, and designs emerge from self-organising teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

This simple document with four values and twelve principles has become a cornerstone for thinking about what Agile development actually means.

Agile or Tragile

There are a large range of practices and techniques which fall under the banner of agile development.  These practices come from a wide variety of sources and branded methods and are effective in their own context.  Unfortunately there is a tendency in organisations to see a practice being used elsewhere and equate the practice to the results the other organization is achieving without understanding the context the practice has been applied in.

Another trap which seems to be prevalent in the business world today is “silver bullet” thinking – if we just do X then we will get outcome Y, even if we don’t understand why and how X is supposed to work.  Perhaps because the language of Agile is so attractive and the perception of “doing things fast” there are lots of organisations and teams within organisations who have taken a cursory look at “Agile” and decided that they can adopt some of the practices without understanding the dependencies and context for the practices and somehow hope to get good outcomes.

Statements such as “we don’t need requirements – we’re Agile”, or “architecture doesn’t matter – we’re Agile” have left a sour taste in the mouths of many project managers, resulting in a level of distrust and skepticism in the community.

This is “tragile” – tragic agile and a cause of much pain and angst among the practitioners who are encouraging a measured and sensible adoption of agile approaches taking into account the context of the environment, the skills of the teams and the goals of the organization.  The goal should never be to “go agile”, there must be a broader organizational need which having an agile approach will help us to achieve.

Benefits and Outcomes – not Process and Practices

Adopting a new way of working should be based on a clear understanding of what the organization needs to achieve as a result of the change.  It’s not about “going Agile” rather identify the benefits which will flow from the new approaches.  Is time to market the challenge? If so then Agile practices focusing on rapid delivery and customer feedback (including short iterations, MoSCoW prioritization, MVP identification) could be useful.  If there a challenge in the maintainability and robustness of products, then some of the practices which aim to build quality in (such as TDD and pair programming) could be helpful.

Define the goals and outcomes then look at the combination of social and technical practices which will enable agility in mindset.

Doing Agile vs Being Agile

It’s easy to teach someone a new practice or a set of practices, and with luck they will understand the rules and apply the practice faithfully.  The challenge with the agile practices is that just adopting a practice or set of practices will not achieve the desired outcomes.  Doing agile may result in some benefits, some of the practices when applied diligently will definitely change the result of some aspects of the development process.  However merely doing agile doesn’t bring about the true transformation that organisations need today.

In order to really get the benefits of agility people in the organization need to be Agile in their approach – embracing change for the customer’s competitive advantage, maximizing the amount of work not done, collaborating effectively in cross-functional, self-organising teams, honestly examining the nature of their work and changing their approach based on constant ongoing learning through retrospectives, listening and adapting to the evolving needs of the marketplace, taking pride in the technical excellence that is so crucial to product development today.

This needs a different mindset at all levels in the organization, a flexible, adaptable, Agile mindset.

Agility in Mindset

Generally we have two viewpoints about our ability, either as an individual or as part of a larger whole such as a department, division or organization.  The fixed mindset says that our capabilities are fixed and limited to a specific set or level, that potential is limited by the inherent capabilities we were born with and cannot change.

People and organisations with a fixed mindset exhibit some common characteristics:

• Desire to avoid failure and look smart in every situation and prove myself.
• Avoids challenges and obstacles because risk of failure.
• Stick to what they know and can do.
• Failure is an impression of lack of talent, therefore quick to blame and be defensive.
• Feedback and criticism is personal as it impacts self-image.
• They don’t change or improve so to this confirms that “they are as they are.”

The Agile mindset is focused on constantly learning, believes that there is always a better way to achieve an outcome and is never satisfied with the status quo. This can be an uncomfortable place to be for people who take a fixed view of the world.  Adopting an agile mindset allows us to learn from failure, adapt to the current situation, respond to customer needs and elicit honest feedback.

Business Agility

Adaptive, learning, Agile organisations are constantly looking for ways to improve, maximizing the value they deliver to customers and stakeholders, creating an environment of joy in work.

They share a number of common viewpoints and aims:

1. Optimise value and eliminate waste, organisational and team impediments: handoffs, partially done work, delays, unnecessary or overly complex features, waiting for approvals, others.
2. Inspire and empower the team: create autonomy, inspire confidence and belief, support mastery and set a clear purpose, hold team’s accountable for delivering results and regulate tension for innovation.
3. Deliver fast: MVP, limit context switching and WIP and enable flow.
4. Optimise the whole: focus on the entire value stream to deliver a minimum viable product: reinforcing that we all win together.
5. Build quality in: Detect and fix defects early, build a “mistake-proofing” culture that eliminates waste at the source (to re-invest time for innovation).
6. Defer decisions: Maintain options, decide at the “last responsible moment” and delegate decisions to those closest to the work.
7. Amplify learning: Get feedback early and often, learn through retrospectives and continuously experimenting, inspecting and adapting.

Characteristics of a flexible mindset are:

• Desire continuous learning. Confront uncertainties.
• Embracing challenges because will learn something new.
• Not afraid to fail – an opportunity to learn.
• Put lots of effort to learn and master something new.
• Feedback and criticism is not about them but about current capabilities.
• Elicit feedback since it is a source of new information and learning.

When enough people in the organization adopt a flexible mindset you have the potential to achieve true business agility.

Agility in Project Management

For projects to be successful in the changing environment, project management needs to adopt an Agile mindset, too.  We need to change some of the underlying assumptions of project management.  Aspects such as the iron triangle need to be rethought, yes the triple-constraint matters and we can’t ignore it but that is just one aspect of the value equation.

Figure 2: Revisiting the Iron Triangle

Project management changes in Agile environments.  We need to take a different perspective when looking at projects.

Initiating the project:

• We want to understand who our stakeholders are and how to engage with them.
• We get stakeholder feedback throughout the process to understand their actual needs at a specific point in time.
• We believe we need to facilitate the joint discovery of the outcomes / strategic goals and the constraints we need to operate within.

Planning the project:

• We plan the project using a map of progressively elaborated outcome level estimates
•  We bring the project to an appropriate team of experts to manage the nuances of a detailed solution, tasks and their durations and dependencies

Delivering the project:

• We manage dependencies and risks ahead of the delivery team.
• We ensure there is a list of valuable deliverables available for the delivery team to work on.
• We aim to make decisions as late as possible to ensure the best possible information for decision-making.

Monitoring the project:

• We monitor progress by delivering working increments.
• We gather continuous feedback to allow early identification of overruns.
• We use adaptive planning to mitigate overruns.
• We provide teams with context and guidance for good decision making.

Closing the project

• We use the feedback from continuous transitions to BAU to improve handover processes.
• We use the feedback from retrospectives to improve delivery processes.
• We use lessons from the previous iteration(s) to forecast. We use feedback to evolve the roadmap.

Conclusion

Agile is not a noun – you don’t do Agile, you take an Agile approach to doing something.

Agility is necessary in today’s business environment because of the pace of change and the flood of innovation happening around us.  Yesterday’s solutions don’t fix tomorrow’s problems.  We need to build adaptive, learning, evolving, joyful and productive workplaces using modern management thinking and project management practices suited to the creative knowledge-worker economy of today.

Being Agile in our thinking is necessary for long term success in today's marketplace.

Announcement:

EA Learning are excited to announce their move into the Agile training space. Register below to receive the latest information regarding this announcement.

Acknowledgement: The title and “Agile is not a noun” badges and image come from Joseph Flahiff –https://www.linkedin.com/in/josephflahiff

Article originally posted by Shane Hastie, via SoftEd https://www.softed.com/news/agile-is-not-a-noun/