Showing the way
Why Agile goes awry and how to fix it
In the spirit of becoming more adaptive, organizations have rushed to implement Agile software development. But many have done so in a way that actually makes them less agile. These companies have become agile in name only, as the process they’ve put in place often ends up hurting engineering motivation and productivity.
When Agile software development was born in 2001, it articulated a set of four critical principles to elevate the craft of software development and improve engineering and product manager motivation.
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Agile processes go awry, because as companies strive for high performance, they either become too tactical (focusing too much on process and micromanagement) or too adaptive (avoiding long-term goals, timelines, or cross-functional collaboration).
The key is balancing both tactical and adaptive performance. Whether you’re an engineer or product manager, here are a few changes to consider to find this balance, so you can improve your engineering (or any) team’s motivation and performance.
1. Software development should be a no-handoff, collaborative process.
First the team, including executives, should articulate the team’s strategic “challenges.” Challenges take the form of a question, always focused on improving some kind of customer outcome or impact. Think of them as a team’s detailed mission in question-form to trigger expansive thinking. The challenges themselves are developed and iterated by the whole team, including its executive sponsors (and customers). Every single person on the team (or any team for that matter) is asked to contribute ideas to each challenge whenever they want.
2. The team’s unit of delivery should be minimally viable experiments.
Teams often find they waste time by adapting too much. To avoid this, not only should ideas be formed for a strategic challenge, but they should also be executed with fast experiments aimed at learning just enough to know what works for customers. In other words, they should be maximizing their “speed to truth.”
3. The team’s approach should be customer-centric.
The process of building software (even internal-use software) should be squarely customer-centric.
At the simplest, these principles should hold:
- “Challenges” are always framed around customer impact.
- Problem solving meetings always start with a customer update, and representatives from the frontline are included frequently in these discussions.
- Every experiment is built around a customer-centric hypothesis. That way, the team can hold themselves accountable to the outcome predicted by the experiment.
However, even more important is that engineers see with their own eyes how customers use their products. This requires the frontline and the engineers working together to see if the product is creating customer impact.
4. Use timeboxes to focus experimentation and avoid waste.
You want to be clear on how far an engineer should go before they check to see if the direction is still correct. The greater the uncertainty on a team’s hypothesis, and the greater the risk, the shorter that runway should be. With that in mind, the timebox isn’t a deadline. It is a constraint that should guide the level of depth and quality for an experiment before a real test. In this way, timeboxes can increase total motivation.
5. The team should be organized to emphasize collaboration.
To make sure you end up with a no-handoff process, the various stakeholders involved should function as a single cross-functional team, also known as a pod. The goal of the pod is to drive collaboration. Each pod should contain the full set of experts needed to deliver a great product. This may include senior executives. In one organization, for example product pods include a product manager, front-end engineer, back-end engineer, designer, a quality engineer, and part-time representation from customer service, and a senior executive from a control function.
6. The team should constantly question their process.
Rather than building “Agile” as a religion that cannot be questioned, engineering teams should be in the habit of constantly diagnosing and iterating their own team’s operating model. In the best examples we’ve seen, on a monthly basis, teams diagnose their operating model and decide if it needs changing to produce a better product.
The ability to attract, inspire, and retain digital product talent is becoming mission critical for organizations. Most organizations have fallen prey to a simple message — implement Agile as a series of ceremonies and everything gets better. Unfortunately, this is often not the case when the human-side of the equation is lost. By getting back to the basics of motivation and adaptive performance, you can build an organization that is truly agile.
Read the full article, here.