I like working in Agile teams. There's nothing better than spending the best part of your working day, with like-minded people, with the same goals, doing our best work. And in my line of work, projects or business-as-usual, it's quickly becoming a given. Talking to people who don't say they work with Agile methods, is like talking to people who aren't yet on social networks. "You aren't on Twitter/Facebook/Linkedin yet?"
Now of course some of those people have very good reasons not to be on any social networks, just the same as some organizations have very good reasons not to work Agile. It's not these organizations I speak about here. It's the organizations who say they are, when they are not - whether mistaken, misguided, misleading, take your pick. They pick up some of the buzzwords, spin it in a way they understand best, but rarely what organizations actually do in the end is in the spirit of Agile.
And I understand it's not easy to go from a traditional way of working to an Agile one. It's a sea change that requires and advocates changing the way people approach their work. And sometimes to make the change palpable, you make concessions, or you make an interpretation. These interpretations may be shaped in a way that does not fit Agile principles, but still works for your organization - which is fine... as long as you are not deluding yourself.
Principles are dangerous things. People live by them. People die by them. And they become even more dangerous when they are not fully understood.
1. All decisions are final. No BacksiesWith Agile hopefully there's a semblance of a belief that during the course of project various factors can affect it. Agile advocates iterations to institutionalize a regular evaluation process in a project - so you won't end up missing your mark somewhere down the line.
Agile does not advocate turning on a dime every single iteration. Iterations allow people the opportunity to reflect on what happened, to take stock in what's going on in the environment, and to take actions accordingly. If this means the backlog gets amended, so be it. If it means the work produced so far is worthless so be it.
But people still get stuck with notions similar to: "we made this decision months ago, we're not going to back out of it now"; "a deal's a deal". Which is kind of restrictive in its own right.
I've seen organizations introduce iterative working processes, with each phase of iterations bookended by toll booths, gates, decision points, go/no-go meetings etc. I'm alright with organizations calling these processes iterative. You do introduce specific moments where a project gets evaluated and if necessary redirected or even stopped. Indeed it roots out the situation where you work for a year and then end up with a piece of garbage, because no one evaluated it along the way. Indeed it allows projects that have no chance of succeeding to be killed off before a significant investment has been made.
There's big pressure to keep passing each toll gate, turning each iteration and each phase into a race to the finish line. Usually because budgets are released by passing one - and missing one means no money. It means that after passing one gate, a number of possible issues are no longer viable to break anymore. The money/investment is sunk. The instrument we're trying to utilize (the iteration), becomes a goal in itself.
I've seen some organizations having the gall to call this process Agile. Which is like saying your local beer league soccer team is playing like FC Barcelona. You're not, you don't have the players, you don't put in the training hours, and you certainly don't win the prizes.
2. Making decisions for youIn traditional settings the boss decides what to do, who does it, when and how. His commands move to his subordinates, who proceed to do the same to their subordinates.
In an Agile setting the decision making process is more distributed. Boss still decides the big picture, but the who, when and how becomes a more organic, more self-organizing process, or so it is hoped.
In practice, decisions do not magically move to the level where they make the most sense for the project as a whole to make. People have agendas, egos, capacities, ambitions, emotions and skills. People have roles and relationships. People have a view of themselves and only themselves, and have a tendency to believe they are more important in the grand scheme of things than they really are. All these factors affect when and how decisions are made, and by whom. Few of the factors completely match with the project as a whole, thus creating conflicts.
A boss' natural tendency is to mediate and rule (usually just rule), if he doesn't trust or empower the project members to resolve conflicts between themselves. Sometimes it becomes even necessary for a boss to do so. In doing so the decision making process becomes at the very least sub-optimal. People who have the responsibility to make certain decisions, can't or won't. The boss ends up spending his time making the decisions for them, forgoing his other responsibilities.
You shouldn't want a general to worry about a soldier's broken shoe laces. On the other hand a soldier should not be handing out orders to move an entire army to a new theater of war, despite what Hollywood shows us.
Should the boss just let things falter? No, but he should create the atmosphere where conflicts are worked out and project members keep in mind the overall project objectives. Conflicts are fact of life, but encouraging people to take the opportunity to deal with them for the good of the project, introducing the means to tackle and even anticipate conflicts, is where Agile shows its strengths.
3. Work break downWhen planning iterations, people tend to just list a bunch of requirements, estimate the work needed, and then divide the total by the number of iterations. Then they apply metrics to see if they are behind or ahead of schedule. That's a train wreck waiting to happen.
In general people are terrible at estimating. Some people may be lucky in guessing. Others might pick up on trends, tells, fakes and take informed risks. These people work the race track, the stock market or the poker table. These people do not in general work in a cubicle office, not unless they can help it. And they are more often wrong than right.
In general people are also terrible at communicating and defining exactly what they want; and even worse in understanding what others want. If people were able to, divorce rates would be far lower than they are now. You might be good with words. Great, you are in the minority of the world's population, let alone in the project. You might listen better to people who are charismatic, proficient in presenting themselves and their message. Unfortunately not everyone is Richard Branson.
Combine those deficiencies, and you end up with objectives that people can hardly describe in an accurate way, can hardly estimate with any authority, and which are chopped up in arbitrary chunks that may or may not end up being useful or of business value.
I am a firm believer in iterative working. Collectives of people (groups of project members) do not have the capacity to completely come up with a solution from start to finish with any degree of accuracy. Iterations help people manage big solutions, by breaking these down into smaller chunks that collectives
can manage.
The chunks should however be so defined that the collective can complete each individually in one iteration, and each should hold business value in itself (i.e. working code). So don't define your task for one iteration as a plastic water cup without a bottom. Rather admit that making a complete plastic cup doesn't fit in one iteration, and make arrangements to adjust the objective or change the capacity.
An Agile construct like complexity points are there for a reason, they force the product owner to think about the goals in terms of business value, rather than hours and dollar amounts which are arbitrary numbers that are attributed too much meaning. There's also a reason complexity points are estimated by the people who are going to do the job, and not the boss.
4. Money rules Plenty of clients who use money as an excuse to defer responsibilities. Plenty of contractors that let them.
The ancient creed that the Spiderman franchise is based on, applies here though:
with great power (money) comes great responsibility.
Now I know that successful clients have got many different things going on simultaneously, and they have to stretch, plan, prioritize their time accordingly. They have to plan where they are accordingly. None of these can be used as an excuse to not be involved with the people they've hired in the job they've hired them for.
The client has empowered them, good on 'em. But if they legitimately come back with a decision they cannot make, or a clarification they cannot make themselves, the client needs to be there.
A client needs to be involved in an Agile project, and should want to need to be involved. He should setup all the means to do so, from daily stand ups, to documentation, to delegating a representative etc.
In the spirit of thingsMost organizations still have a ways to go before actually working in a truly Agile way, if they need to at all really. I respect these organizations that realize this, and find ways to make it work in the meantime.
But if you do just a stand-up meeting, or just iterations or just a burndown chart, and say you are the Agile methods guru, I think you've cut some corners.
