So that got me thinking, what about the things that Agile really does not value.
This may be going out on a limb, but as I read the Agile Manifesto and the Agile Principles, I see a lot here that I can imply the signatories don't value. I get that they wanted to focus on the goal. They want to stay positive. But as a team lead, a scrum master, and a team member, my experience has shown me that problems arise around trying to get companies, teams and people to not do some things. Agile leaves huge holes for troubles to pour in and I think they start with some of things Agile doesn't value.
Hey, maybe I'm making this up, but I'm writing it down so you can disagree.
Agile doesn't value political decision making
- Multiple masters kill a project especially if each of the masters are protecting turf and grabbing power. This happens so often that I consider it the norm and the notion that you're going to have an actual "product owner" to be very much like Big Foot. Hey, you might spot something that looked like it out of the corner of your eye once, but it was quick and fleeting, and in the end you're pretty sure they don't exist. At least not in your woods.
Agile doesn't value doing the work as fast as it can be done
- The principles are clear. Agile values the competitive advantage that comes from accepting changes even late in development. But most of the changes I've seen aren't competitive as the manifesto assumes. The fastest way to ship a product is to spend some time thinking it through (a few days), architect a solution, map out the work, identify the critical path, then do the work while optimizing along the critical path. This could be waterfall except I'm talking about doing all of this within hours or days - even on medium to large projects. The critical path is the shortest a project plan can be done but on an Agile project there is no critical path (well, there is one, you just don't know what it is). Agile does not value this. For good or bad, Agile values accepting changes and assume that it's a competitive advantage. Sometimes it is, sometimes it's waste.
Agile doesn't value shipping bug free software
- Agile encourages TDD and XP, but they are not required. I'll get a lot of flack on this if I go into too much detail so I'll make this simple. Neither the manifesto or the principles mention quality, bugs, testing, or defects. What the manifesto and principles mention is value. It could be implied that it's better to ship buggy software as long as your customer find it valuable. Please don't be angry at me, I'm just pointing this out. Think about it. Why don't they mention quality?
Agile doesn't value holding to a budget
- Costs are not mentioned in the manifesto or the principles, yet I've never seen a commercial project where the leaders weren't obsessed with the budget. The budget drove everything from the schedule, to the hiring and resourcing, to the services we could buy, to the equipment we could use - everything. But Agile doesn't value the single most important thing to most clients (with the arguable exception of the schedule). This causes many teams problems.
Agile doesn't value optimally resourcing the project
- Even though what I'm about to say is not at all controversial, it's likely to be considered controversial by my fellow Agilist. To optimally resource a project you need to know the size and shape and scope of the project. Duh! On Agile projects these things are rarely known. Therefore, I conclude that Agile does not value optimally resourcing a project.
Agile doesn't value the specialist
- While Agile values individuals, the signatories have been fairly clear that they value the generalist - the so called, "Cross Functional Team." From this, I'm going to assume that Agile doesn't value specialist. Almost all the teams I've worked on have had at least one specialist. And I see why Agile doesn't value them. They often end up as the bottleneck. Whether that's because there really is a bottleneck at the specialty or whether the team is being "held hostage" by the specialist depends; we can discuss that another time. There are risks with specialist and this problem was probably much worst in the past but it's clear that Agile has no place for specialist. My experience has been that the specialists are often the most effective people on the team - bottleneck or not. My friend Steve Bockman has an interesting take on this topic.
Agile doesn't value knowing what's best for the customer
- When doing Agile the client knows best - period. This may be a tad dramatic but I've witness many changes that didn't add value and members of the team knew they didn't. Even when it's obvious to a team member that a change is a waste, Agile has no place for this. Sure there is nothing that prevents you from arguing with the client but Agile is very clear: The Client Knows Best. I've had some great product owners and their vision has been very clear. They are a joy to work with. But I've also had projects where the product owner was a proxy product owner. In most corporate settings the product owner is often as far from ground level as anyone else on the team and they are often proxy product owners. Agile does not address this. Whomever gets assigned the role of product owner has most of power in Agile. Agile gambles the success of the project on the product owner and sometimes the product owner sucks.
Agile doesn't value building something of value to the users
- Agile's highest value includes satisfying the customer, not evaluating whether or not there was an actual competitive advantage gained by using the software. Whether we want to admit it or not, those two are often in conflict. Especially with proxy product owners. In many context this probably works out fine but all too often we end up producing software we know is stupid for a backslapping client who is surprised that it's not liked or used. Agile has nothing to say about this.
Good points there, especially the end about satisfying customer's immediate wants instead of building more slowly towards a bigger and possibly better value goal. But in a world where teams have to act fast for quick wins and impress shareholders, being agile is often the only course left. http://blog.twoodo.com/721/definition-of-teamwork/?track=blogcomment
ReplyDeleteThanks Andrea. I agree, but Agile says nothing about shareholders either - the notion of the stakeholder is a Scrum notion, so we can pull a wider audience from that if we want, but the values in the manifesto just say customer.
DeleteI don't believe we need to be making all these trade offs to deliver quickly. Many of the Agile projects I see don't deliver value faster, they deliver builds / releases faster. But a lot of software isn't valuable until a significant portion is done. A few years ago we tried to iteratively build some compliance software. The company could not use it until the very end because it needed the full software. The purpose of the software was to submit compliance reports to the Government. Building iteratively certainly helped us create the software the client desired, but the notion that they somehow got it sooner because of Agile is incorrect.
(sorry, hit save to quick)
DeleteI believe in the scenarios where you must deliver a completed project for it to be valuable then Agile actually slows you down. I'm not saying don't do the project iteratively, you should.
In those cases (which are many of the projects we work on) you should be building the project along the critical path to create it as well and as quickly as you can. Your milestones should be integration points and not features, you should release as you go to give people an early look, but the development should be prioritized along construction lines, not backlog priority.
This idea has fallen out of favor which is actually a vote of confidence. When most projects are failing, doing what everyone else is doing (on average) is the wrong thing.