The Agile Manifesto In Plain Language
The definition of Agile is the ability to adapt to changing circumstances.
In February 2001, 17 software developers met at the Snowbird resort in Utah to discuss lightweight development methods. They published the Manifesto for Agile Software Development, in which they shared that through their combined experience of developing software and helping others to do it they had come to value:
– Individuals and interactions over processes and tools
– Working software over comprehensive documentation
– Customer collaboration over contract negotiation
– Responding to change over following a plan
Any person involved in projects in either large organizations or esp. Government organizations can see that these statements are more ore less opposites of each other.
Individuals and interactions over processes and tools
Having the experience and knowledge and being willing to share this with others versus applying a standardized process and using tools to accomplish a project.
There used to be a time when departments had dedicated business analysts working in the IT department. The business analyst had become a subject matter expert over time and whenever the business initialized a change request or project, the business analyst was able to communicate with the business and the IT people on the same level. He or she knew about the business processes and was a valued partner in the whole process. That all changed. Business Analysts became part of pools of analysts and the perception was that by just applying business analyst techniques a true understanding of the requirements was easy to get. Just ask some predefined questions in a workshop and write down the answers, put them in a large document and ask a group of managers to review it, make changes and when it all looks good get them to sign sign off. How hard can it be?
The Project Manager role has undergone a similar change. How many organizations and Government Agencies have permanent Project Managers dedicated to the business areas? Not many. The shift to engaging a high paid contractor from outside the organization to run a project is based on the same perception that by just applying a predefined process and tools can make a project successful. It doesn’t. Project Management Certification is based on the process and tools and because the certificate has a very high price tag attached to it, not many organizations were and are willing to spend it on a permanent employee. He or she might walk out of the door after the certification and look for greener pastures. It’s easier to just hire someone from outside the organization who has the certificate already. But this person doesn’t know your business, and it’s far more complicated than you think. Even if the Project Manager has worked on similar projects elsewhere, he or she has no understanding of your business. He or she has not worked with the people in your organization and people are the biggest risk factor for any project. The characters he or she has to work with. This is the most underestimated risk factor for any project.
This project manager is not an equal partner in the communications with the business areas and IT or any department in that regard. It takes a long time to establish trust and true knowledge. It’s hard to undo stupid, so if the project manager doesn’t give the impression from the start that he or she is an absolute expert in the business field and technical field, he or she is in for a rough ride. Apart from that, he or she has to know the political playing field as well to survive. Who should be pleased the most? The fact that he or she is on a high contract rate doesn’t do him or her any good. The more you earn, the more specific things you’re supposed to know. At least that’s what people think, why else pay that much money.
‘You’re here because you have a certificate in Project Management and by just applying the techniques you can run this project successfully. Don’t worry’
Good luck, it’s not going to happen. Everyone knows that. Few acknowledge it.
The other thing is that it is easy to make an outsider responsible. If it goes bad (and it will at some point) it’s better to blame the one person than to take the blame yourself. Being a PM On a high paid salary you should expect it and it will happen. The fact that there are so many Project Managers out there looking for a job is alarming. If they really were able to finish a project successfully, would the organization not keep them on for another project? I bet they would. So what happened? Maybe just applying the processes learned in the certification is not the way to a successful project. Maybe other things are as important or probably even more. Maybe the organization was very hostile and toxic and the PM left on his or her own account. Couldn’t handle it anymore, and left because health is more important than being on the wrong end of the stick of a few people who have total disregard for your well-being.
Working software over comprehensive documentation
‘Comprehensive documentation is not only time consuming, it is unnecessary.’
Good luck getting that statement out in large organizations and Government Agencies. The more documentation, the more words to describe simple processes, the more reviews and versions, the more reviewers and sign-offs the better. Every document has to pass the academic standards demanded by the reviewers. It has to be a novel. The reviewer needs to finish at least two red pens to the last drop of ink before it’s even near review completion. The author needs to be hammered a few times, a few fights have to break out, political power has to be displayed. It’s a perfect time to show everyone who is really running the show here! It’s entertainment for the ones in charge. They thrive on it and look forward to it when a new project starts. What else is there to do? Working software… who cares.
So taking this away is like taking away a baby’s pacifier or a kids favorite toy. They will put up a fight.
How to get away with a statement like ‘Working software over comprehensive documentation’?
By taking the comprehensive documentation away and consistently doing so. If they don’t get that document, then they can’t use it. Give them another document, name it differently and standardize the format from the start. And don’t give them a hybrid for review! Remember the two red pens…
Customer collaboration over contract negotiation
Who is the customer? In the traditional way of running IT projects, the customer is the business. IT is the one that delivers the service, and the customer is king… Why is that? Aren’t the business and IT in the same organization and therefor in it together? Do both parties not have the same responsibility to the organization as a whole when it comes to delivering a successful project? Yes they do. So why would we insist on a predefined scope, features and signed off document? The document is then a contract. We deliver what you asked for and if you change your mind on some things, we pull up the signed document from the dusty shelf and show you your signature. If you want changes, it will either cost you or you will get it later. Your choice.
‘But the business analyst (I hated that guy from the beginning because he didn’t know anything about the business) only asked the questions from the template and we were not aware that it would affect other areas as well. We were rushed as we needed to sign off the document because you guys said that the contract developers had already been hired and they had nothing to do because you were waiting to get the approval in the gate review to go ahead with the next stage.’
The moment that document is signed, it becomes a contract. Instead of delivering a product that is satisfying to the need, it becomes a matter of contract negotiation, which is much harder for both parties involved.
IT people take great pride in delivering a product that makes people happy. On the other hand, the business has to understand that the Waterfall method demands this way of working, so IT’s hands are tied as well. Waterfall enthusiasts deny this of course. They argue that change is possible at any stage of the project. Anyone who has tried it will say differently. It’s not as easy as they say. Most of the time changes will be addressed in a phase 2 or phase 3, or through change requests after the go-live date of the product. At that point the business is relying on the availability of IT resources, who have already moved on to the next project. When will the changes be implemented? Who knows. They will end up in a pile of change requests waiting to be completed and if there are many then a new project has to be initiated and who knows when funding will be available to start one.
‘In Agile you don’t get a Business Requirements document for sign-off, Joan.’ I said.
‘But we need a signed off Requirements Document!!!’ Joan said and looked at me over her black rimmed glasses, red pen waiting in her hand.
‘Not really.’ I said. She looked at me like I was from another planet.
‘What do you mean! We need that document! Without it I can’t do anything! I need to have something to review! I want to know what these people from operations have put in there and if I don’t like it, it won’t go in! I hate that Mary so whatever she put in there I’m going to oppose without even thinking. Who is she anyway? A grade 7. I’m a grade 10, what value does she have? I’m in charge here!’
‘Hold on Joan! Relax!’ I said, as I got the feeling that it wasn’t about the requirements anymore, but a power issue. I had to steer the conversation in another direction.
‘A requirements document is made out of a collection of requirements, right?’ I said. She agreed (well that was a good start).
‘So.. If you agree on these individually or in a small related group, that would be the same as putting them all together and then agree on them?’
‘Sure.’ She said.
‘Would that benefit you?’ I asked.
‘Yes it would. If I get them when they are ready individually or in small related groups as you say, it’s easier. I would feel more involved in the whole process. I can comment on them if I need to and I don’t have to go through this massive document at the end with someone breathing in my neck to sign it off because the whole organization is waiting for it. Some of these requirements have nothing to do with me. I wouldn’t have an idea what to comment on those. But I do feel the need to do it anyway, especially if it comes from that Mary!”
‘That Mary really ticks you off, doesn’t she?’ I asked.
‘Well I haven’t met her, but I don’t like Geoff, her boss, so for me they are one and the same really. And another thing I hate is that Functional Spec that I have to sign after the Business Requirements document! What is that thing all about? I’m not interested in how it’s done, as long as it’s done! When I go to a restaurant, I want to eat a nice steak, medium rare. I’m not interested in how the Chef is going to do it! What pan he uses… I want that steak.’
‘Good point Joan. You’re not going to get one of those documents either.’
‘Thanks!’ Joan said. Her pen was down by now. She looked at it… was that a tear I saw? … it had been her loyal friend for so long. It was time to let go…
Responding to change over following a plan
Agile is all about being able to respond to change. Certain things never change. If I want to make a coffee at home, I know that it will take a maximum of 10 minutes to do so, if I have all the ingredients that is. If I don’t and I have to get sugar from the shop then it will take me longer. How much longer? I don’t know. The shop can be busy, they might have run out of sugar and I have to go somewhere else. Traffic might be busy, a road might be closed and I have to take a detour. I might get lost even. But if I have everything available, it will take me 10 minutes. If I don’t, I really don’t know how long it will take me. So if I say it will take me 45 minutes just to make sure, then that is not correct either. Sometimes it will take me 10 minutes, so I’m 35 minutes off my plan and I finish early. Sometimes it will take me 90 minutes if I have to go to different shops.
So my plan is to make a coffee and I allocate the 10 minutes. That’s what it takes to make a coffee. I write that down in my plan. Regardless what happens, I have to be out of the door by 8 to get to work on time, and I have to have a coffee before I leave.
7.45… Time for coffee. No sugar… now what? I have to stick to the plan… what to do. My plan says that I can go to the shop, but that would not help me as I would be running late for work. Drink no coffee maybe? Not an option. I have to. Drink it without sugar? That would be an option, not nice though… only if I’m really desperate…
I’m stuck… 7.48… clock is ticking…
I hear Paul my neighbor in the backyard… I go outside… ‘Paul, can I have some sugar? I ran out’… ‘sure’
7.50… I start to make my coffee.
Now to avoid a situation like this, I could put in my plan that I start making coffee at 6.30 in the morning. If I have to go to the shops, I will estimate that it will take me 90 minutes, the maximum.
Paul was never in my plan when I wrote up the plan. I didn’t even think about it at the time.
Agile is not only about responding to changes but also about being able to be creative with coming up with an alternative solution when things don’t go as planned. Drinking the coffee and not running late was my main objective. Asking Paul for help wasn’t in the plan, but I did it anyway. Accomplishing the Goal is more important than following the path to get there. Now does that lead to anarchy? Will people do things without having to asking for permission? Yes, but it doesn’t have to be a big thing. The plan should not be a constraining factor. It’s a plan. It’s like a road map, but I should have the freedom to derive from that road when it congested or a tree has fallen on the road. It’s a decision I make on the spot to take another road without having to call 15 people for permission first. That’s Agile, self-organizing. Is that a bad thing? Depends how controlling the people are who would like to be called for permission… more on that in the ‘self organizing team’ section.