Many project leaders have questions about agile, particularly when it comes to implementing agile values and principles. Questions come in all shapes and sizes – from those starting out and questioning whether agile is right for them to seasoned teams looking to move to the next level.
This is the first of a series of posts on agile meant to help answer some of these questions. The three parts in this series include:
- Agile Overview
- Agile in Practice
- Agile Insights
For this initial post, let’s first start by defining terms, answering some of the questions encountered most often.
What is Agile?
Agile is not in and of itself a methodology. It is based on the Agile Manifesto, which is a set of values and principles that were identified by a group of high performing software development professionals. They had been working in differing types of iterative, non-sequential development environments for several years, and were striving to encapsulate the values and principles that were making their projects highly successful. Therefore, agile is ultimately a way of thinking about solving problems and getting work done, a different mindset.
At its core, agile is about delivering the right business value at the right time, while improving the overall quality of the product. Given those precepts, we are actually seeing an increasing amount of agile practices being applied outside the software development space.
What Are Some Agile Misconceptions?
Agile is not a prescriptive approach to anything, especially software development. However, there are a number of “frameworks” that would be considered agile, as compared to the Agile Manifesto. Scrum, Extreme Programming (XP), and Kanban are examples of these “frameworks.” Because its core values express constant inspection and adaptation, any agile approach would need to be less prescriptive in nature.
Agile is not a cure-all. If you have an existing team, process or leadership issue, they will likely only be made even more visible when moving to an agile approach. However, if you are ready to actively work with those involved to address these issues, the resulting improvements will be just as visible, which is a good thing!
Agile is not easy to implement. Agile encourages people to work together at very high levels of interaction, across multiple disciplines, as well as across the business and IT. For organizations that have traditionally been very siloed, this is a change that can be jarring and needs to be managed and supported accordingly. Failing to see and address this need is a common cause of failure for many organizations when attempting to implement an agile approach.
Why does it work?
Software development is by nature generally complex. By complex, we mean that the problems we solve by the development process don’t usually have predictable solutions. We typically have to try some different solutions before arriving at a suitable one. However, the next time we need to solve a similar problem, the same solution may no longer apply (technologies change, people change, business priorities change). See Dave Snowden’s Cynefin Framework to understand how problem-solving should be approached in different domains. An agile approach leverages very small feedback loops, with an inspect-adapt cycle (probe-sense-respond in Cynefin model). If the underlying assumption is that our problems are complex (complicated at minimum), then the inspect-adapt cycles will minimize the risk associated with complex work.
For additional information on this topic, read “A Leader’s Framework for Decision Making,” which was published in an older, but still highly relevant, Harvard Business Review publication (you will need to purchase the article or subscribe to view the entire article).
Why do I care?
Clearly, there need to be benefits in making any significant change to how work is completed within an organization. Agile methods, when executed well, can provide many advantages.
Most important features are delivered first. Because of the focus on working software, agile approaches generally build a “backlog” of features and deliver those, in short, 2–3 week iterations. This allows the business to prioritize these features frequently, ensuring that the most important work is done first. And, since the result is “working software,” the features can actually be deployed into production where they can start providing value.
Progress is visible and transparent. Few things are more frustrating to a leader than not having a clear picture of the progress being made against a substantial investment (i.e. large software development project/program). There are few better ways to see the progress of a software project than to witness functioning software being delivered in 2 to 3 week iterations. In addition, practices such as Big Visible Charts (BVCs) provide real-time views into the work the teams are working on at that moment in time. That is powerful stuff!
Agile gives the ability to adapt to change. We know that change is a reality in most software development efforts. Instead of treating change punitively (i.e. expensive and painful change requests), agile approaches have built-in mechanisms to allow for change.
Although this has been a very high-level overview of agile software development, the hope is that this has helped pique your interest and address initial questions. In Part 2, we will look at what some successful agile implementations look like in practice, where you can get a glimpse into the culture, practices, processes, and tools of a successful agile implementation. In Part 3, insights the team has gained over years of agile journeys will be shared.
About the Author
Matt Anderson has worked many years in the insurance and financial services industries. This experience includes 11 years in leadership roles for many different mission-critical enterprise applications. These applications spanned technologies and platforms, from mainframe to client-server to intranet/internet. Matt is a Professional Scrum Master, Project Management Professional with the Project Management Institute and is certified in ITIL v3 Foundations.