What to do when Scrum/XP isn’t working in your shop?

By this time, probably at least a few shops have given a try to Agile and Scrum.  For some, things have probably been going fine. For others, perhaps not so fine.  What to do when Agile/Scrum isn’t working for your shop?

Many would recommend posting to Agile/XP news groups, or hiring a Scrum coach to help out. But I’m going to suggest something different.

First, I think one should keep in mind a few things.

1) The notion that Scrum/XP will help your project is simply a theory, not a proven fact.

Although these methodologies are often presented in a fait accompli way, that of course, if you take the magic pills, you will lose weight, the facts are often different.

The reality is that Scrum/XP are simply THEORIES about how to conduct a software development effort, they are not proven in any widely accepted way.

2) Your “Agility” may be harming your project

 The Scrum/XP process, when followed in the orthodox manner, is a fairly ad hoc and chaotic process.  It simply may be the case that a more organized approach would better suit your organization; e.g., having 3×5 cards pasted to a wall may be too low tech and difficult to transmit to other team members compared to more traditional documentation.

 User stories do not capture the cross functional (UI versus back end) nature of tasks which can lead to a variety of timeline issues.

 The “onsite customer” may have ideas different than “other customers” and this may lead to extensive rewrites

3) Lack of Up Front Design leads to frequent refactorings and wasted effort

 This cannot be emphasized enough; the  YAGNI (“do it later”), literally lazy approach and general disdain for “design” in Agile projects can have severe implications down the road.  In fact, often the entire code base must be thrown out (aka “refactored”) when it becomes known how non-performant the system is under a real load.

 To me, throwing out 6 months of effort because noone chose to do the requisite up front design or analysis is not “Agile” as most people would think of the word.

 Not understanding the problem domain fully often leads to a variety of issues, rewrites, and refactorings. If you feel that you are refactoring too much, perhaps not enough time is being spent in Design and Architecture.

4) Your issues may not lie in the Software Development process at all, and may be higher up in nature

 If software requirements are constantly changing, the best course of action simply is to nail down the requirements as much as possible before beginning coding.

 If the requirements keep changing, perhaps management has not done a good enough job of enumerating the requirements through discussions with customers, ROI planning, etc.

 It may also be the case that upper management’s internal communication process could be improved to reduce the number of changes in the Spec.

5) Scrum as a management process may be too simplistic for your project

 I could go on forever about this, but Scrum is the most simplistic and minimal form of management possible. It is possible this form of management is in fact too primitive for your organization.

 6) Too many cooks working on the same pie

 The Agile/Scrum approach that everyone’s hands can and should be in everything creates more entropy than is needed.  In a project of 7 or so developers on a web project, it makes more sense for some of them to specialize on the database, some on front end/html/javascript, some on graphics etc.

 Avoiding specialization increases the communication overhead, number of refactorings, and level of bugs in the system. 

7) Scrum and Agile/XP Focus on the Immediate term at the expense of the Long and Medium term

 Scrum, XP and Agile focus on tactical, short term goals, practically by definition, versus considering the medium and long term (strategic) implications.

 The Scrum “Master” asks — What did you do today? What will you do tomorrow?  When does s/he consider what will happen next week or next month?

 The inability to grasp a time scale beyond the immediate now is pretty much how the animal kingdom works; when did this become the preferred method of anything, let alone software development?

 While it may be useful to be tactical at times, it certainly is no strategy, and the fallout from this lack of strategic planning can be dramatic.

 These are just a few things to consider when Agile/Scrum is not working in your shop.

 In many cases the solution is not to become “More Agile” but to become “More Organized”.

 If your organization needs assistance in this area, feel free to Get In Touch.



About postagilist

Architect, Manager, Developer, Musician, Post-Agile thought leader
This entry was posted in agile, software architecture and tagged , , , , , , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s