Merriam Webster defines the term “agile” as “marked by the ready ability to move with quick easy grace.” The term “agile” was popularized in business by the “Agile Manifesto for Software Development” issued in 2001. Since then, the agile movement has exploded as companies rush to “agile” as the cure for a wide range of business challenges and IT teams garner significant investments promising that agile is the answer to IT’s inability to deliver at the speed the business demands. But are these efforts yielding the promised results?

I’ve seen agile succeed in small IT organizations and large ones but I’ve also seen an equal number that have faltered or failed. Some of the reasons these programs struggle is not setting them up properly to begin with. Here are some tips for getting it right:

1. Invest in change management:  Most established IT organizations have ingrained methodologies for delivery. By nature, people fall back on what they know. Agile is as much a mindset change as it is a methodology and changing mindsets and behavior is hard. Agile requires strong commitment and leadership from the top, and a plan for tackling the significant organizational change that adopting an agile mindset requires.
2. Emphasize delivery over speed:  The term “agile” itself is a bit of a misnomer as the word itself focuses on “speed.” However, the emphasis in agile should not be on speed but on delivery or shipping feature or products. I’ve seen teams spend days planning 2-3 week sprints and fail to ship any tangible deliverables or work in the planned sprint. The point with agile is to deliver small measurable incremental chunks of work – failing to organize the work into bite size chunks that can be delivered and measured is an important factor in agile’s success.
3. Invest in people, process and technology:  Implementing agile requires setting up the people, process and technology for success. Here are the most common misconceptions I’ve seen around agile that lead to underinvestment:

Misconception #1: Agile teams can manage themselves

Leaders often have an expectation that agile team members will actively engage with the process by both contributing to and volunteering for tasks on their own. In reality, this works if you have a strong agile lead or coach and a mature and high-functioning team. Most IT teams are used to a more directive culture and will not naturally sign up for tasks or contribute. This behavior must be taught, encouraged, modeled and rewarded – it doesn’t happen naturally.

Misconception #2: Agile doesn’t require planning

Technologists love agile because of the misconception that it requires less planning. When done right, agile actually requires more granular, daily planning, task estimation, communication and measures of accountability. Without the right mindset, lead or coach and the ability to track and monitor task estimates and measure productivity, agile will fail to deliver.

Misconception #3: Implementing an agile “tool” will enable the process

Another misconception is that agile software tools are the cure-all for fixing the people and process issues. Many of software tools used to support agile are time-consuming and cumbersome to use and are perceived as a burden rather than an enabler of work. A good tool built on a lightweight simple process will enable agile teams to easily triage, communicate and facilitate work.  This will also insure that the tool is used throughout the day to manage work. This requires setting up the tools with a smart lightweight process that all team members can get behind.

• Define measures of success:  Agile requires fine grained estimation on the “incremental parts” that are being delivered in a sprint and it requires evaluating the estimator’s accuracy. Gathering data on the accuracy of estimation to actuals allows for the refinement of planning going forward which facilitates greater predictability of delivery.
• Include the business in all aspects of agile delivery: Agile requires the involvement of the business in all aspects of delivery. Many IT organizations think agile is “an IT thing” and have the misconception that agile can work without the inclusion of the business or users. In reality, the close partnership between end users and developers means there is constant feedback and “iterations” and there won’t be any last-minute surprises.

Finally, agile is no magic bullet. It’s a methodology and a process for delivery that takes time, focus, dedication, and most importantly flexibility (agility!) in tweaking the process over time until it works.