The term “Agile” gets bandied around a lot today, many organisations are “doing Agile” in their software development and it is rapidly spreading into the lexicon beyond IT and software into many other aspects of the business world.
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:
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:
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:
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.
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:
Characteristics of a flexible mindset are:
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:
Planning the project:
Delivering the project:
Monitoring the project:
Closing the project
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.
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/