My friend Bill Scott once said at a conference, “Agile doesn’t have a brain.” What he meant by that is due to Agile’s software engineering roots many organizations that have adopted Scrum, XP and similar methodologies have done so through their engineering departments. This has led to the creation of amazing software development departments that are incentivized for the efficient and predictable delivery of high-quality code. These teams write great code. And, perhaps more importantly, they SHIP great code — regularly and predictably. For this they are rewarded and driven to become even more efficient with fewer defects.
The questions that rarely gets asked in these organizations however, are:
- WHICH features should we build?
- DID we build the right ones?
- DID we design them well?
- DID we optimize them to achieve maximum value for our customers and our business?
That’s what Bill was hinting at. As implemented by many organizations today, Agile — and its methodologies like Scrum — have no mechanism for determining if they’re building the right feature and whether that implementation is designed well and/or worth improving.
This is where Lean Startup and Design Thinking come in. With an experimental mindset rooted in market-based evidence and user-centric advocacy teams begin to question the validity of their feature choices. This humble approach ensures that the Scrum process churns out features that have the backing of the market (i.e., reality) and not just the gut instinct of an individual product leader or team.
The cadence of agile teams plays nicely into continuous experimentation and learning. Teams can build repeatable, routinized research tactics into their delivery streams. This builds a continuous flow of insight into the product development and delivery cycle as well as further upstream into the decision-making process. Effectively, this puts the “brain” on the agile process. And with a brain we make better decisions.
P.S. – The next post will discuss the discipline required to actually respond to the insight this learning process generates.
P.P.S. – If you’re interested in learning how to build this “brain” into your processes join me in one of the following cities for a fun, hands-on workshop: Stockholm, Phoenix, Minneapolis/St.Paul, Washington DC, and Bologna, Italy
[Jeff]
My experience is quite different. In all the agile teams I’ve worked with over the last 15 years, and the people I’ve met in the agile world, the questions you list above are very much at the heart of the process. If those questions aren’t being asked (and many more), its not agile.
That’s great to hear Channing. I’ve had mostly the opposite (i.e., described above) experience. I’d love to learn more about these orgs and more importantly, their leadership. What are the values they define as success for their teams? How do they reward and incentivize their teams to achieve those values? How do those values manifest in the product and ultimately in the company’s success?
Thanks!
Ah well, there you have hit the nail on the head. Without good leadership actively supporting teams to deliver value, you’re screwed.
Most of the organisations I’ve worked in have been in finance, and the most successful teams have been predominantly contractors. The incentive is usually simply giving people the space to do a good job – a really big motivator.
Having worked on a number of ‘rescue’-type projects, the value is often having high quality, working software that fulfils a business need, as well as enabling the business to offer more to clients. (Describing value is tricky.)
To be fair, I have also seen a number of projects defeated by ‘traditional methods’ being brought to bear on an otherwise successful team/project for political reasons. Sadly.
the value is often having high quality, working software that fulfils a business need
See? That’s exactly what I’m talking about. That’s NOT enough value. It has to actually be something desirable AND delightful to use. And that’s what’s missing — the process to get to that state — in many orgs.
desirability and delight is part of having high quality software, to me at least.
In XP, a member of the team is the actual customer who wants the features built, and her job is to get stuff that they need. That person/role is a user of the system and a purchasing agent, a job that is hard without a “brain.” When you say “Agile” do you mean XP? XP was represented well at the creation & signing of the manifesto.
Likewise, in scrum, there is supposed to be a “product owner” who does the same as the customer. They have the final say about content and priority. That person is supposed to know what is not to be done and what is — though the team might suffer from having “the wrong brain” in some cases.
I have seen scrum teams that run with a disconnected brain: the person playing “Product Owner” is not a customer, doesn’t talk to real customers, doesn’t actually ‘own’ the product from the point of view of making decisions.
A disconnected brain is tasked by local product managers (also not the real customer, but one layer closer) with producing features. Sadly, the disconnected head is not allowed to say “no”, to cut down the feature set, or to ship MVPs and validated incremental releases.
In other words, some scrum teams run as if they were waterfall teams with fixed content.
But I don’t think you can say “agile” here if the people in question are not actually doing what the agile methods describe.
Does that sound unfair?
I understand your point and agree that when executed well many of the issues I present get better. However, the reality is that most organizations are trying to bring scrum into practice but, as you put it, are working with static content. It’s an incentive management problem and it won’t get better until we get more user-centric thinking into the decision-making process.
Believe it or not, I’ve seen the same happen with Lean Startup.
No methodology is perfect. In fact, every instance of every methodology varies in the context it is implemented.
My point is that it’s not the methodology. Used in the “wrong” culture, every methodology will get bastardized to uselessness. And the more mainstream it becomes, the more it will happen.
A methodology followed through obligation and knowledge-avoidance can produce no positive change.
“Agile — and its methodologies like Scrum — have no mechanism for determining if they’re building the right feature and whether that implementation is designed well and/or worth improving”
Sure they do: put a new version of the system in front of actual users every few days or weeks and get their feedback. Have a Product Owner, or an onsite customer, or whatever you call them, to provide vision so that you aren’t just building “faster horses”, rinse and repeat. This is built in to Agile processes.