AGILE /SCRUM Fails to get to grips with Human Psychology.
I promise in the next few weeks to concentrate on other subjects other than AGILE and its deficiencies, but my readership statistics show that AGILE is a popular subject. I also feel I have to keep up with my protagonists comments, which are appearing not just on my blog but all over the net.
At the moment, the net is buzzing with AGILE evangelist websites and Blogs making statements like “the AGILE manifesto is the equivalent to Newton 4th Law of Motion”. When someone takes a fanatical belief in anything without proper empirical evidence you have got to start thinking!!. Please see my post Storm in a Tea Cup. I really think these evangelists do not expect us to engage our brains. They think if they keep repeating the common look-up list of humorous slogans about AGILE’s invincibility, we will all be conditioned into turning a blind eye to the detail and asking for verifiable and independent evidence concerning this approach’s claimed scalability and prowess over other methods /approaches. At the moment the whole IT methods industry from Waterfall to RUP to AGILE and SCRUM is in need of consolidation based on some sound independent research. As we speak, large corporations take huge “flip flop” financial gambles adopting this method over another, largely based on the word of lightweight fee-earning consultants.
Most development /project management methods, which have come and gone over the last 20 years, are all variations of a theme. AGILE /SCRUM is nothing different and is a cobbling together of mostly small scale IT development methods which were drifting into obscurity until AGILE came along and gave them a new lease of life. AGILE has for some of these methods become the equivalent of being sent to your local A&E. For example, prior to AGILE DSDM had been removed from all of IBM’s front office websites.
I do think AGILE and SCRUM has its place. It is just that I believe this place is running projects under 5 people and delivery durations of less than 6 months. At that level, employing the right people with the right skills and motivation frequently guarantees that MAGIC will occur. The new media industry proves this everyday, irrespective of approach /method used. Good people always have the potential to overcome deficiencies with methods /approaches and poor management. I have seen it time and time again.
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. 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.
- People are self-interested
- Commercial production decisions are based on rational expectations.
- 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:-
• 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.
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!”
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.
• 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.
• 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.
• 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!
• 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.
• 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.
• 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 entry has been viewed 19557 times.
READER COMMENTS:
All contents copyright © 2006, Orbital Media Network. All rights reserved.
Interesting and informative observations. I’m beginning to see where some of your opinions about agile development came from. The organizations you describe sound fairly dysfunctional. Too bad the words “agile” and “scrum” were associated with them. Doesn’t sound like they really understood what to do.
I’ve mentioned before that agile methods have worked well at our company. The final two bullet points in your post pertain to our organization, however.
Initially, we used agile methods on small-scale projects to develop webapps. As you describe, each team chose its own tools. Some of us began to question how sustainable that would be, and predicted the approach would begin to break down in the production support area. Sure enough, that’s what happened. Since then, we’ve reined in the range of technology choices open to the agile delivery group so that we have a reasonable set of standards while still offering sufficient options to support the disparate needs of our projects. This is a factor any organization considering agile methods must take into consideration.
Some of our internal customers have balked at the amount of their time agile methods require. Some have adapted themselves to it, because they appreciate the relatively high business value they get from the approach. Others have been enthusiastic initially, but faded away from iteration to iteration because of other demands on their time. I think the key here is that an organization has to approach agile development with eyes open, and part of the reality of it is that it will demand more time on the part of customers. If that’s not feasible for a particular organization, they should consider alternatives such as lean development, or perhaps just tightening up the traditional process controls using a process improvement method such as Six Sigma.
At the risk of sounding like one of those zealots making excuses, the other bullet points in your list frankly sound as if the people mis-applied agile practices. In particular, the project managers who behaved as you describe really didn’t “get it.” Agile methods apply most directly during code development. They don’t substitute for all the other activities necessary for a project to be delivered successfully, such as planning and resource management and so forth. To be successful with agile, you have to integrate it with the rest of the activities in the organization. If you just sort of drop it on the floor and walk away, I have to wonder how anyone could expect anything useful to happen.
I’d like to make a final comment about your observation that agile methods only work on very small teams. With traditional methods, we scale up just by adding more people to the project team. Many people assume that’s the way to scale agile teams, too, but it doesn’t work. To scale an agile project, you decompose the work into sub-projects and coordinate them. Each of the sub-project is ideally staffed with no more than about 9 people. Obviously this adds management overhead to the process, but the net of it is still more cost-effective than traditional methods in most cases.
Posted by Dave Nicolette on Fri 18th August 2006 at 03:29 PM | #