I’ve recently taken to reading arguments against agility, to learn more about the common difficulties with implementing agility or more specifically scrum in organizations. These issues raised in this article interested me quite a bit and I felt like sharing them and responding to them in my usual ‘scrum-master-ly’ way… with questions.

Wonderful to be involved in such projects.

The problem I have with AGILE /SCRUM is that, like many methods, and indeed political doctrines such as communism (Das Kapital – Karl Marx), they look great on paper but fail to work in reality because they forget the human factor.

“When this person read this part of the agile manifesto(if they did):

Individuals and interactions over processes and tools

Off the ‘Paper”, what “Reality” ways did they implement that to ensure it stuck? Did they have a decisive customer on the team acting as the product owner? Did they have a daily scrum meeting to keep eachother accountable and visible? Did they have a sprint planning meeting lead by the customer to commit to things? Did they create a set of team rules with the customer to go over the scrum values

1.Commitment
2. Focus
3. Openness
4. Respect
5. Courage.?

By the way, nice job, compare it to communism, that'll get the right wingers against us. Just like those failed attempts at good ideas, people were the problem, but it's not a process that has to worry about people... it's the people implementing the proces. You try to blame the process... i'll say what about the people who tried and failed at implementing it, are they not the issue?”

 Any Paradigm, which has human interaction at its heart, will fail if human psychology is not understood and taken into account. The key aspects of human nature which IT development /project management methods have to take into account are no different to those at the heart of most modern economic theories:-

- People will always put their own interests ahead of the interests of the group.

Can you not align the business incentives with agile practices? Incent individuals into achieving team goals? Were you still incenting individuals to blame, lie, cheat and undermine eachother to get that next promotion because you gave them no alternatives to making money?

- People are self-interested

Can you not align the business incentives with agile practices? Incent individuals into achieving team goals? Were you still incenting individuals to blame, lie, cheat and undermine eachother to get that next promotion because you gave them no alternatives to making money?

- Commercial production decisions are based on rational expectations.

The rational expectations of who? Are you including the whole team when you say “rational”? Where in the agile manifesto (agile) or in scrum is it ever said that the product owner should be irrational?

- Karl Popper’s “First law of collective action”. You can never get more than 5 people to agree on anything.

AGILE /SCRUM has its own culture based on the best and worst of human nature, which often precedes its introduction into an organisation and often starts to imbed itself even before the implementation consultants have the caps off their marker pens. AGILE /SCRUM culture cuts across all of the points mentioned above and can from experience in the field turn often already sickly IT departments into meltdown.

Notes from my diary on the views of people working within 3 self-proclaimed AGILE /SCRUM organisations, describe the culture they experienced in the following terms:-

I should have stopped reading when you said “Self-proclaimed”, but I decided to continue any way. (whups that’s not a question). What makes you think these self-proclaimed agile teams were actually agile or actually using scrum? AND if they were in fact using adhering to agile values or using the scrum framework, then would they have found their organizational problems  if they weren’t? Was their inability to solve their organizational problems an agile/scrum issue? (Scrum’s job is to uncover problems, it’s the organization’s job to resolve them.)

• The Project Managers /SCRUM MASTERs turned themselves into Project Administrators. In each organisation this was characterised by a total lack of project plans, risk /issue management, quality management, change control, budgetary and status reporting. When questioned, all these managers felt they were responsible for the failure of their projects but had, under AGILE, no authority to direct or change anything. The team was responsible for delivery and they were responsible for taking the heat if it failed! They also felt they had to provide softly softly, and frankly patronising, Uncle Buck support for their project teams.

Were they using scrum? Did they have a product owner? The product owner steers the team in scrum, and without one the team very well may drive itself off a cliff. And when I ask if they had one… I mean did they have a product owner who was involved and committed to the team and doing what a good scrum product owner should do on a daily basis?

I was surprised to find in many cases that the Techncal staff conducted meetings with clients, leaving the Project Manager /SCRUM MASTER as a mute bystander, and totally ignoring risks, costs and commercial considerations. In all 3 organisations the managers, despite failure and chaos everywhere, were leaving for home on time and were mute concerning any questions concerning poor project delivery performance, instead choosing to hide behind the AGILE crucifix, with statements like “the team is responsible for this - go ask them they made the decisions. “Go talk to them! I am just following AGILE /SCRUM!”

Again, did any of these projects have a committed product owner assigned to the scrum teams to make these decisions? Or was the team just ‘doing scrum’ without a participating product owner?

Great we have a ship with no captain on deck being steered by the ships crew with any sinking / loss of life being the responsibility of the slumbering captain. No wonder they were in meltdown. CRAZY!

• The project teams had in almost all cases been taken over by strong personalities leading to mini dictatorships. These mini Hitler’s (senior technicians) kept all the most interesting development work for themselves and had often taken possession or laid claim to successfully delivered system deliverables leaving the rest of the mess to the other team members. These ‘dictators’ often seemed to accumulate more work than they could cope with and refused to hand it to others. This meant these projects slowly ground to a halt as all too frequently these tasks sat along the critical path.

Did the team get taught on conflict resolution and open-ness? Scrum only has one designation for a team member and that is “Software Developer”… did scrum give them the title of ‘senior technician’? Did scrum imply they had any more authority than other team members? Did they have a product owner?

• Knowledge Monopolies. The ‘dictators’ detailed in (b) also, in the absence of documentation, had absolute control of the code should the developed system ever be launched. They would be the only people in the organisation with the knowledge to maintain and enhance the code going forward, thus maintaining their job security, and guaranteeing pay rises above the market rate. I really noted some serious arm bending on pay by these guys - squeezing in one case the budgets to such extent that previously turned down outsourcing deals were back on the burner.

Did the team, when it was formed, set any ground rules? Did they define what “Done” meant? Was the documentation part of their definitnion of done? Was code documenting part of their definition of done? Did they have a collocated space for the team to work in? When this started happening did management do anything about it? (or the product owner?) Would you have known about it if you weren’t using scrum? Wouldn’t this happen in any methodology at that same company?

• Resource Management had vanished. With no proper project plans, except lists of team SPRINT deliverables at the most rudimentary level, no one knew how long a project would take and when resource would be needed, or could be released, between projects. The dictators appeared to want as many people in their teams as possible and were reluctant to let them go in order to maintain their status.

Did the team not do estimating at any level? With estimated backlog items you should be able to easily plan out releases in a way more granular level 2-4 iterations out than you’d ever be able to with anything else I’ve ever used. Sure the farther out you are the less you know, but you should at least be able to identify “WHO YOU NEED”. Again, did management do anything about this once they realized this was happening? Did the product owner realize this was happening? Was the product owner looking ahead to future backlog items and finding out who they would need?

• Having had a taste of freedom the dictators were a hateful and aggressive bunch when asked about their managers /SCRUM MASTERS. They felt they were in charge and knew best, and had been liberated from the incompetent direction of their old management. They were without exception, never going to be directed by anyone except perhaps the client!!. Many of these dictators seemed to start and leave work as they pleased as an ultimate expression of their importance. No one is an island or a law unto himself /herself!

That’s a pretty bold statement, you sound like many project managers I’ve talked to. Why shouldn’t the people doing the work have the most say in how the work is done? Do you know better than they do? Isn’t that arrogant? Were they wrong? Were their managers more competent to make decisions for them than they were? If so, why didn’t their managers give them training to become more competent? Wouldn’t it be feasible that any individual could be trained to be as competent as the manager? What’s wrong with that? You said above that people shouldn’t be hoarding knowledge or lording over their team members… does this not apply to “Managers”?

• Most of the talented young development staff were leaving because the dictators were hoarding work and only handing out uninteresting tasks to the new boys on the block.  This created a bunch of disaffected and unhappy people who had no idea what their future prospects were, or how to get promotion in such a CHAOTIC situation with so much posturing and territorial teeth showing between team members (like Gorilla packs in the forest) when they wanted to learn something or expand their remit.

Why didn’t the scrum master stop this from happening? They should be enforcing the scrum values and one of those is respect. This doesn’t sound very respectful. Remember people and interactions over processes and tools.

• Each of these organisations had differing development approaches and tools from project to project. One team would be using Java J2EE and another using .Net C# and another struts, all within the same IT department, so that maintainability and resource management was impossible. Each AGILE scrum appeared to make up their own minds as to which constructs /tools etc to use in order to deliver the project. On close investigation, the decisions seemed to be based on what might enhance the capital value of their CVs as against what might enhance the capital value of their employers. Not having interchangeable staff between projects and maintenance and support crews is a real constraint on an IT department’s productivity and ability to control costs. Cutting edge technology means the replacement developers /tech designers were also going to be expensive.

I can relate to this one,, we have this going on in our organization and we’re working to resolve it. Did any of these organizations recognize this problem and re-define “Done” to add certain toolsets in there? Did any of these organizations add constraints to their backlog on certain toolsets or products that would increase their CV? If the organization left it up to the team to decide and the team decided badly for the organization, then maybe the organization didn’t set clear enough expectations… after all it’s the Product Owner who determines the value of development, not the programmer… this should have been part of the product backlog or the definition of “Done”. This is a failure in implementing scrum properly and is fundamental.

• Clients feed up with never-ending, continuous involvement in IT projects. The clients could not afford to work so frequently with the IT project teams as envisaged under AGILE. In all cases client input was sporadic and inconsistent due to the duration of their required assistance right through the project life cycle. The clients could not afford the additional overhead cost. This is common with other development methods but with AGILE /SCRUM their involvement is more intensive, and for longer durations.

I am not knocking AGILE /SCRUM for the sake of it, more sharing my observations of organisations claiming to be AGILE shops struggling to make AGILE /SCRUM work in the REAL WORLD. If any method fails to survive front line implementation (large IT projects /programmes), you have to start asking questions.

All I can say is that when I have seen AGILE /SCRUM fail it is sad and painful for the professionals working in these places. If AGILE /SCRUM is to survive and have any chance of going forward, it has to be reworked so that it encourages the most valuable and productive aspects of human nature, whilst constraining the expression of some of its worst and most destructive aspects. This is the essence of people management.

This is a common “problem” with implementing scrum or using agility… your customer just doesn’t want to be involved. This is a bad customer… they will probably make your life hell, but sometimes you cannot choose who your customer is. What you really need to do then is identify a PROXY to the customer to act as your product owner, then THIS person can be involved on a daily basis and then go talk to the customer at their level of involvement. I’ve talked about this with MY product manager… they just aren’t willing to ‘play the scrum game’ every day, so we have business analysts and QA people  to have their best interests in mind. Again, what did these organizations do to try to fix the problem?