AGILE

“Momentum is the result of a series of completions, not beginnings. Energy grows when you get stuff done.”

– Dan Rockwell, Leadership Coach & Blogger

I first saw agile while working with one of the largest IT departments in the world on productivity improvements. The data was convincing that software development teams employing agile methodologies to manage projects were by far more productive, with higher quality code than those teams using the traditional waterfall methodology. I’ve used agile in most of my projects because agile simply works.

A quick history of Agile

A quick history lesson on waterfall and agile will shed a bit of light on why agile methods work so well. Many moons ago, waterfall project management methodologies originated from the civil engineering and construction industries. When you build a bridge, you need the sequential waterfall process of initiation, analysis, design, construct and test phases. If you haven’t done the analysis, then you can’t build the blueprints, if you don’t have the blueprints, you can’t purchase the materials and construct a good bridge, and so forth.

In the ‘70s and 80s, the emerging software development industry utilized the waterfall methodology since there were no other alternatives. During the same time, a growing community of developers and engineers became increasingly frustrated with the waterfall methodology.

Their frustration was rooted in the fact that designing and developing great software necessitates an opposite approach to problem solving. When constructing a bridge, you know it needs to be 456 feet long, able to bear a 450-ton load, last for 100 years, and withstand hurricane-force winds. When you start developing software, you typically don’t know what you are trying to build; you just know you are trying to solve a problem, such as improving the checkout of a website or developing a music recommendation app. And, while you can’t just start building a bridge from day 1, you can start improving the checkout of a website or developing the best music recommendation app from day 1.

This community of frustrated developers and engineers started experimenting with different types of methodologies, and in 2001, a group of these luminaries published the Agile Manifesto, which is the philosophical foundation for agile, as stated on AgileManesto.org:

• 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 by following a plan

• That is, while there is value in the items on the right, we value the items on the left more.

Agile methodologies flip the waterfall paradigm on its head, shaking out all of the inefficiencies and waste inherent in the waterfall paradigm. While agile grew within the realm of software development, agile methodologies apply to developing services, products, process improvement, engineering, and strategy projects. Once you really embrace agile methods, you won’t go back to the old-school waterfall methods.

What is agile?

The waterfall is a sequential development process, usually involving one team to design the product, then a handoff to a different team to develop the product, and then another handoff to yet a different team to test the product. For many types of products, all of these handoffs create a lot of waste and misinterpretation, and in the end, if there is an issue in testing the product, it necessitates looping all the way back to the design phase.

On the other hand, agile is an iterative development process, where only one team is responsible for designing, developing, and testing the end product. The team typically segments the end product into intermediate products or features, collaborates heavily with various stakeholders, and designs, develops, and tests intermediate products or features. These bursts of collaboration to get to intermediate products are called sprints. The goal at the end of each sprint is that there is tangible progress towards the end product, in the form of actual features, prototypes, or alpha or beta versions of the product.

The main characteristics of agile methodologies include self-managing teams, an iterative approach, focus on prioritized outputs, constant collaboration, flexibility, and sprints.

Self-Managing teams

Agile teams have the right people, norms, and empowerment to make their own decisions and manage their collective work. They are typically made up of a potential user of the end product, the designers, developers, and testers of the product, as well as other important stakeholders (e.g., team members from marketing and sales, operations, and customer service). The team consists of pretty much everyone you need to actually get the project completed.

Iterative approach

Realizing that there is often a lot of discovery and new ideas that happen in the development process, agile teams embrace an iterative approach, relying on a lot of prototyping, feedback, and iterations during development. And, often the test plans are created before the development of an end product to really pressure test the requirements and scope of the end product.

Focus on prioritized outputs

Agile teams continually drive towards the most critical end-state outputs. If a team is building software, this means they are continually prioritizing and developing features. If a team is developing a product, they are continually prioritizing requirements and driving towards working prototypes and usable products as fast as possible.

Constant collaboration

Agile teams depend on continuous collaboration with and feedback from potential customers and stakeholders. This collaboration ensures they are building an end-product that fits the needs of customers and stakeholders.

Flexibility

Agile teams rely on being flexible and always prioritizing potential changes to requirements and features.

Sprints

Agile teams sprint from deadline to deadline. They use deadlines to time box and focus their effort and outputs.

Agile vs. waterfall

Agile is an excellent methodology, especially for projects that are smaller, a bit ambiguous regarding the end product, and don’t have a lot of dependencies with other workstreams and teams. Agile can be applied to most strategy, software, digital, product, and service development projects. As you get into larger, more complex, and more structured projects, you can use the iterative waterfall methodology, which incorporates the sequential nature of waterfall, with iterative agile methodologies within the waterfall phases.

How do you implement agile?

There are many agile methodologies to choose from including SCRUM, feature-driven development, lean development, and others. Below are some agile implementation best practices.

Utilize mentors and coaches

Many agile practices go against peoples’ typical thought processes, such as developing test plans before designing the product, prioritizing daily tasks, self-managing teams, or constantly looking over a programmer’s shoulder to quality-check the code. Hire an agile coach, or have one or two people on the team with agile experience to mentor and teach the rest of the team members.

Embrace strong norms and governance

Self-managing teams can operate at a high level of efficiency and effectiveness, especially if there are strong team norms and governance. Have the team set the norms and governance, including the mission, team values, decision-making rules, and conflict resolution protocol. Agile relies on a series of kick-off meetings before a sprint, along with reflection and learning meetings after a sprint, to debate what worked and didn’t work and any potential changes in team norms or practices to improve the next sprint. Agile also relies on quick daily meetings to align and talk through the priorities of the team for the day and week.

Constantly organize priorities

Agile is about always working on the highest priority items. For a team to do this, their current and future priorities need to be well organized. Agile teams typically write discrete features on note cards and then order and reorder the note cards based on the next feature to build. Some agile teams use an Excel spreadsheet to prioritize actions, features, and requirements.

Co-Location and dedication

Effective teams, including agile teams, are co-located in the same area to maximize collaboration and minimize waste. Furthermore, it is important to keep the core team intact and working the same hours. Typically, the core team is 100% dedicated to the agile project, with other team members (e.g., marketing, sales, operations) devoting a certain amount of time to the agile project, based on input and collaboration needs.

NEXT SECTION: REQUIREMENTS & USE CASES

MCKINSEY PROBLEM SOLVING COURSE - LEARN MORE & ENROLL

Learn more about the best self-paced course on McKinsey Problem Solving

DOWNLOAD STRATEGY PRESENTATION TEMPLATES

THE $150 VALUE PACK - 600 SLIDES
168-PAGE COMPENDIUM OF STRATEGY FRAMEWORKS & TEMPLATES
186-PAGE HR & ORG STRATEGY PRESENTATION
100-PAGE SALES PLAN PRESENTATION
121-PAGE STRATEGIC PLAN & COMPANY OVERVIEW PRESENTATION
114-PAGE MARKET & COMPETITIVE ANALYSIS PRESENTATION
18-PAGE BUSINESS MODEL TEMPLATE

JOE NEWSUM COACHING

Learn more about Joe Newsum, the author of all this free content and a McKinsey Alum. I provide a suite of coaching and training services to realize the potential in you, your team, and your business. Learn more about me and my coaching philosophy.