Agile

Agile is a software development approach that is iterative, collaborative, and incremental, and incorporates stakeholder feedback

Agile is short for “Agile software development,” which is a set of values and principles shared publicly as a manifesto by seventeen software engineers in 2001. The Manifesto for Agile Software Development can be read at https://agilemanifesto.org/.

Agile principles were developed to create quality software that creates value for customers through autonomous, self-organized, cross-functional, and highly collaborative teams. Originally conceived specifically for software development organizations, Agile has evolved to include all types of products, as well as other aspects of business, including marketing, sales, and back office support functions.

Principle Shorthand	Comment
Customer satisfaction is highest priority	Complete the mission to the client's satisfaction
Open to change for the customer’s benefit	Circumstances change, so ability to change must be built into the process and requires checking in with clients
Continuously deliver working software	Demonstrating progress on outcomes is the best indication the team is tending toward success
Collaborate with business stakeholders	Those who "own" the project necessarily have input to the project, so there must be a collaborative relationship.
Give teams the freedom, resources, and environment needed to succeed	Part of a collaborative environment includes defiing the mission, the metrics to measure progress, the resources necessary
Communicate effectively	Preferably, face-to-face, periodically in person, effective communications between stakeholders, within teams, and with clients makes for successful projects
Measure progress via working software	Rather than focusing on measurement of task completion, instead measure progress toward desired oucomes
Work at a sustainable rate	A strong, regular cadence of focused work over periods of time, is better than unsustainable bursts of activity
Be good at what you do	Building depth of skills, and learning adjacent ones, as well as a mentality of continuous learning builds highly capable of teams.
Believe in simplicity	Focusing on work that delivers high value is the most efficient way to succeed.
Teams should organize themselves	Assuming teams are comprised of the skills necessary to accomplish their mission, it's best to leave them to determing the best way to do their work
Teams should always seek to improve their work	Teams and individuals should be self-aware, take time to be reflective, seek new information, and improve their abiity to deliver their work

WHAT THESE PRINCIPLES MEAN

Teams are autonomous in that they decide how to best approach solving a problem. They are self-organized, because the team members determine who does what by when. They are cross-functional in that members represent diverse backgrounds and expertise. They are purposefully highly collaborative through practices that seek input, represent good communication skills, and reflect on their work.

Generally, Agile is an iterative approach to solving problems. The principles and practices favor working in short phases (often referred to as “sprints”), which allow changes to the work, instead of following a rigid, detailed plan driven by the calendar. It is often contrasted with “Waterfall” development process and “phase-gate” or “stage-gate” methodologies.

Even more generally, small “a” agile means people should periodically lift up their heads and turn their attention to the world around them, to see if there’s new information that might affect the product and hence should change the work. Teams observe their progress relative to solving the needs they are addressing. They reflect on individual and team practices and improve upon them. They see and incorporate changes in social, economic, or environmental conditions that might affect the work and the desired outcomes.

In the end, the belief is that teams produce higher-quality products that better solve customer problems by incorporating “pause, reflect, and act” into the development and implementation process.

COMMON AGILE SPRINT PRACTICES

Sprint: Length of time for an increment of work. Sprints can be any duration, but in software development are commonly one to four weeks.

Backlog: A collection of all the tasks that need to be done for a particular project or project phase.

Sprint Planning: The Agile team collaboratively devices which items from the backlog will be included in the next sprint.

Retrospective: A periodic review of how the work is going and how well the team is functioning. The objective is to continuously improve the work, exercise good communication practices, raise and overcome obstacles, and keep team members engaged and motivated.

Demo: Short for demonstration, this activity is an opportunity for teams to share with each other the work they’ve been doing. It’s important for teams to communicate as a “team of teams”. (McChrystal)

Additionally, the “continuous feedback” principle ensures the work done over the sprint duration serves its purpose. Not only is the work tested to validate the product works as designed, but the customers interact with it as well, to validate its progress toward solving their needs.

The Manifesto for Agile Software Development does not dictate how the principles are applied, so naturally a myriad of frameworks has emerged to instruct their implementation. That sentence itself seems sort of anti-Agile. Nevertheless, SAFe®, Scrum, Extreme Programming, and several other frameworks have helped organizations implement and structure Agile practices.

In the best case, the frameworks are flexible enough to incorporate corporate culture and business needs into the implementation. In other cases, Agile becomes merely a varied version of Waterfall. If you do not incorporate the actual principles and values outlined in the manifesto, then you may or may not have implemented a more efficient way to produce the product, but either way it’s not Agile.

The reason why this distinction is important is because of uncertainty. As discussed elsewhere (and quite a bit in The Lean Entrepreneur), the world we live and do business in is more complex than ever and has a high degree of uncertainty. Agile is in direct response to that phenomenon.

The Industrial Age was defined by assembly lines and dominated for decades by large companies producing a limited number of products. From a market perspective, there was less uncertainty. (In the things we can control and respond to. I am not talking about wars, famine, and acts of God.) The prevailing trend over the last decades is increased market complexity—more products, more product versions—e.g., from the Model T to the hundreds of models available today.

The digital age, plus globalization, means consumers actually have a multitude of choices and are overwhelmed by the amount of information clogging up mental channels. Fundamentally, this situation means producing products people want or need is more difficult, even while the technology revolution means producing the products is generally easier and less expensive.

Agile works best in uncertainty. The more the volatility in markets, the more you need to incorporate external information. If everything about a customer and product is well known, a more Waterfall approach may be reasonable. The length of an Agile sprint should be based on two factors:

The time it takes to perform the average unit of work
How often a team should incorporate external information

If a team works on an extremely complex product and the shortest unit of work is one month, it’s highly unlikely a sprint shorter than one month would make sense. If the team is building a jet engine and know exactly what needs to be done, sprints might be scheduled at a cadence based upon quality assurance testing, development issues, need for team retrospective, and so on. But if a team is writing a new feature a day, a shorter sprint might be reasonable.

The flexibility of Agile is also important when considering its implementation in other parts of the company, i.e., in non-development groups. While the processes described above are effective anywhere in the business and the idea of using sprints to organize and visualize work can benefit any team, most don’t need or want a super rigid or high-bandwidth implementation—not that development groups need or want that, either.

An idealized, highly functional Agile team looks like this:

Company or division has a need. There is a problem that needs solving. It could be to build the first version of a new product, or to launch a marketing campaign to acquire customers, or to go learn a new market using the principles outlined in this book.

Team size is a diverse group of no more than seven or eight members. Their abilities generally match what is needed, but all members mustn’t be experts. You manage with the cards you’re dealt. The team is diverse in terms of background, life experience, and level of maturity; members bring different skills to the table. You evaluate the team more than parse the individuals.

The project has a time objective and a specific, quantifiable desired outcome. The team has access to stakeholders to understand the needs, constraints, and outcomes, as well as report progress and test solutions. Stakeholders might include users and customers, but also internal product “owners,” executives, and so on.

Stakeholders own the outcome. But they don’t own the path to the outcome. Generally, the Agile team is responsible for creating the best path to the result. The team is formed with the experience and expertise in mind toward providing the best solution.

The team is self-organized. Generally, the team owns internal roles, responsibilities, skill development, and relationship management. Its members decide who does what by when. There is no formal leadership. Roles such as timekeeper, scribe, and facilitator are used on a regular basis and responsibility is shared.

The team manages what needs to be accomplished, the time estimates, and what goes into each sprint. It holds stand-ups and retrospectives on a regular cadence.

The team reports progress to and shares the actual work with stakeholders on a set schedule.

Leadership inspires, empowers, and holds teams accountable. Leaders are responsible for setting overall objectives and context. They regularly update teams on changes to context. Changes might be due to internal or external factors, such as economy, crises, company performance, finance, personnel issues, and so on.

Leaders organize communications between teams to ensure larger contextual issues and needs are addressed. Teams are responsible for sharing updates, work product, and issues and obstacles that may affect other teams, or other teams might help with.

Leaders take responsibility for helping teams overcome internal or external obstacles, providing time, space, human, and financial resources; opening doors; and addressing issues teams do not have authority or skills to address themselves.

Like all of these frameworks, Agile is a mindset. I strongly believe Agile will become a standard way of organizing work inside of corporations and by work, I mean all work.