Agile development is all about delivering the greatest value in the shortest time possible, using the least amount of effort. This does not equate to being simplistic; it’s about using the most direct approach to accomplish what is needed. For those who are considering adopting agile (and for those who need to persuade others), here are some points to consider.
Agile development is customer-focused and value-oriented. Aligning IT and the business has been a long-standing concern, and agile development is one way to get closer to the customer and focus on what the customer truly values.
One change with agile development is that agile wants and needs customer involvement throughout the development cycle. This is because agile product development teams are focused on continually delivering what the business values.
The customer (or a proxy such as a Product Owner) need to prioritize work based on business value, be available to answer questions as the team implements features, review the work produced by the team at the end of each short delivery cycle (typically a couple of weeks or so), and accept or reject the results along with requesting any desired changes. And if changes are requested they must be prioritized relative to the remaining work. Doing all of this allows us to maximize the value delivered.
Agile development also values the people performing the work. Agile values people and their interactions, leveraging face-to-face communication wherever possible as the most effective means of communication. Agile development also values people by:
- Using a sustainable pace, essential for long-term productivity.
- Placing control of the work in the hands of those performing the work (autonomy).
Notice that these activities are deferred, not eliminated. With agile development, we elaborate the requirements, plan, and deliver them in small batches, using iterations or Sprints (with Scrum) that are very short in duration (a few weeks, give or take). We elaborate and plan throughout the development cycle, using the most up-to-date information possible gleaned from prior deliveries and interactions with the customer.
When it comes to making mid-stream adjustments, many will claim (and rightly so) that their existing, non-agile process adapts to change. But with agile development we’re talking about increasing the speed at which change requests can be made (every few weeks, based on regular reviews of working software), how quickly decisions are made and how quickly and easily we can incorporate those changes into future deliveries along with understanding impacts and trade-offs of those decisions relative to future work.
You also benefit from agile because agile adapts and responds to change quickly while keeping the cost of change low. The cost of change is kept low because we avoid building up an excessive inventory of fully developed requirements in advance (just as any lean manufacturer avoids building up excess inventory) because those requirements are subject to change in their content and/or priority over time.
We also keep the cost low by sizing the work contained in the Product Backlog instead of estimating in hours, deferring on detailed tasking and estimating until we actually plan to implement a requirement. With a little practice, teams find that relative sizing is far faster and easier than estimating in hours, and no less accurate when forecasting delivery dates.
Agile development also keeps the cost of change low while being rapid by placing decision-making as close to the team as possible. The Product Owner (or customer) works with the team directly, answering questions and making decisions on the spot, without having delays of sending requests “up the chain” and waiting for responses/approvals.
Risk is managed by delivering and reviewing working software in short periods of time. With agile development, we no longer have to rely on percent complete figures on a project plan (that sooner or later fail us) and milestone reviews that may be months apart. We can see working software delivered every couple of weeks or so. The team’s velocity (a measure of how much work the team is accomplishing each iteration or Sprint) and the forecasted delivery date are very clear and visible. Any changes and their impact to forecasted delivery are likewise immediately clear and visible.
Risk is also reduced – particularly as teams become more experienced – by defining increasingly small, independent units of work (e.g., a User Story). Smaller units of work are more predictable than larger pieces of work, increasing schedule predictability.
There is a balance of people, process, product, and technical disciplines. Agile development is a disciplined blend of just the right amount of process (typically less than non-agile organizations rely on today) coupled with product and technical excellence and greater collaboration and interaction (increasing in these dimensions) that combine to generate value early while allowing teams to continue to deliver value on a regular cadence indefinitely.
Agile development supports continuous improvement. Using a framework like Scrum (the most popular agile framework in use today), we have two mechanisms for improvement built in: The Sprint Review and the Sprint Retrospective. Customers and stakeholders participate in the Sprint Review and make suggestions to improve the product. The product development team gets together in the Sprint Retrospective to reflect and discuss how to become more effective as a team at delivering, choosing an improvement activity for the very next Sprint.
The development of people also goes hand-in-hand with continuous improvement, whether it is to enhance their technical knowledge, knowledge of agile and lean concepts, business knowledge or anything else related to improving themselves so that they can perform and interact better.
Yes, agile is change. Getting all of this correct requires time and attention on everyone’s’ part, and it doesn’t come easy. Agile is significant change because the benefits are realized from working differently, and this naturally takes some time and a little effort to understand what is different and why. But the rewards are definitely worth it!
The beauty is that you can start small, gain some experience and be better informed about how agile will affect you and your organization as you move forward.
So I ask again, is there anything holding you back about adopting agile?