Why Agile & Scrum Will Indeed Fix Your Products
In a recent post, Adam Pisoni, co-founder and former CTO of Yammer, claims that while the Agile software development methodology was indeed a positive step forward, it did not go nearly far enough. By declaring, ‘Agile will not fix your products,’ Pisoni is claiming that Agile is not the end all be all for development teams.
While he does support Agile, Pisoni feels that Agile implementations like Scrum are driven by a top-down approach and don’t give much freedom or autonomy to individual engineers. In turn, this creates a disconnect between engineers, management and customers. At the same time, Pisoni argues that engineers aren’t coming up with new ideas quickly enough using the Scrum methodology — instead, they’re stifled by management.
Pisoni goes on to suggest that in order to create an organization built for the 21st century, companies need to look beyond Agile to new methods that distribute authority, are self-organizing and allow customers, partners and employees to “own the process.”
He identifies a lot of Agile anti-patterns in his comments, yet completely misrepresents Scrum. Let’s take his arguments piece by piece and surface the nonsense:
While Agile did educate a generation of software developers on the importance of experimentation and customer feedback, it failed to change the old, centralized, command-and-control system of management, which remains a large part of the problem.
Let’s reiterate that Agile is not an implementation. It’s a set of values, and Scrum is a disciplined implementation of those values. When I created Scrum, I specifically made sure that there was no role for management in the process. And when Ken Schwaber joined me in formalizing Scrum, we made it crystal clear that management needs to get out of the way and has no role messing with engineering teams. That being said, there is a role for leadership to help teams remove items that are blocking them and making them unhappy.
Even with Agile, disempowered engineers working with too little context still end up taking too long to create products customers don’t even want, resulting in dissatisfied customers, disengaged engineers and frustrated managers.
Disempowered engineers were the reason Scrum was created. The goal was to empower the engineers and the first iteration of Scrum did that in spades. People were crying in my office when the Easel team was acquired and had to break up because they would be searching for the rest of their lives for the exhilaration of a great Scrum team. If the implementation is disempowering engineers, it is not Scrum. Industry data shows that 61% of so-called Agile teams are Agile in name only – they can’t deliver anything on time or on budget and their customers are unhappy. The author must be talking about these “Agile in Name Only” teams.
- Green: Agile – deliver what the customer wants
- Yellow: Agile in Name Only – not capable of delivering what the customer wants
- Red: Total failure – delivered nothing
Source: Standish Group. Chaos Report 2015
Scrum dramatically increased transparency and made it harder for managers to ask for more than could be accomplished. It also acknowledged the need to update plans iteratively.
This is true. Scrum is based on transparency, which enables inspection and adaptability, the fourth value in the Agile Manifesto. It is designed to prevent “Developer Abuse” or what Taiichi Ohno, the creator of the Toyota Production System, called “Absurdity” — in other words, waste generated by dysfunctional managers who pressure teams with excessive scope.
But, the increased transparency associated with Scrum actually gave engineers less autonomy than before. Engineers’ authority was reduced to determining how long something would take, and picking the next story from a queue determined largely by management.
Here, Pisoni completely misunderstands Scrum. Management has nothing to do with backlog prioritization, that is the role of Product Owners. No one assigns tasks in Scrum because that slows teams down. Scrum is at its best when developers pull from their backlogs, which are prioritized by Product Owners. This aspect is based on the Toyota New Product Development System, beautifully described in The New New Product Development Game.
While Scrum did manage to rein in impulsive managers, it ended up being used more to exert tighter control over engineers’ work. Most books on Scrum come at it from the perspective of top-down management, not self-organization.
Pisoni is internally inconsistent here. He says Scrum reined in impulsive managers, but it is based on top-down management, not self-organization.
You can argue that the problem isn’t Agile itself, but merely implementations like Scrum. That nuance would be lost on most people, as Scrum and Agile have nearly become synonymous.
This comment reveals a total misunderstanding of where “Agile” comes from. Agile was a set of values created during a debate primarily between the founders of Scrum and Extreme Programming (XP) with the help of 10 other thought-leaders, consultants and authors. Agile comes from Scrum and XP. It is not an implementation and is meaningless without one.
The world “Agile” comes from the book, Agile Competitors and Virtual Organizations: Strategies for Enriching the Customer, which covers 100 lean hardware companies that said involving the customer directly in Lean Product Development was “Agile.” When we gathered together to develop the Agile Manifesto we spent the first day of the meeting coming up with that word to describe what Scrum and XP were doing.
It’s not enough for management to be the voice of the customer. Engineers and designers themselves must understand and be able to empathize with the pains and goals of the people they are building for.
This is another huge misinterpretation. I created Scrum specifically to get the manager out of the way. By micro-managing developers, managers are ultimately interfering with what the customer wants. The Product Owner in Scrum is the voice of the customer and is not a manager. Management is notoriously unreliable in assessing customer needs.
As Scrum adoption has become increasingly widespread, the degree of misinterpretation around how it actually works has unfortunately spread with it. We only have to look at the industry data on “Agile in Name Only” to see what a monster we’ve created.
While Pisoni and I ultimately have different feelings around Scrum and its usefulness in the software development process, we do agree on the most important thing — organizations need to implement processes that distribute authority, are self-organizing, and allow customers, partners, and employees to “own the process.” This, of course is Scrum, not “Agile in Name Only.”
Usage-based pricing is a hot trend, but does it deliver? The answer—according to our recent study—appears to be yes.