Six Sure-Fire Ways to Make Scrum Fail

I joined a project which was trying to use Scrum.

After a quick read of Agile Software Development with SCRUM by Ken Schwaber and Mike Beedle, I was intrigued. What Schwaber and Beedle had to say passed the “gut check” and I wanted to see it in practice. Their basic arguments which warrant exploring are:

• Software development is unpredictable. You need a project management/process control system which adapts as you learn, and you should evaluate and apply what you are learning on a regular (monthly) basis.
• Developers must be held accountable for delivering what they promise. Developers can only be held accountable if they are empowered to solve problems.

I’d like to share our success story, but what I do have to share is lessons in how to make sure Scrum fails:

1. Interpret “Scrum” to mean there is absolutely no overall project planning or vision. After all, Scrum isn’t an empirical process control model; it’s a license to start development without an end goal in mind.
2. No software architecture! We’re agile; we don’t need no stinkin’ architecture!
3. That thing about removing impediments—it doesn’t apply if it means organizational change, it only applies to the project team. Empower development teams? Well, not if it’s hard.
4. Expect to get it exactly right in the first few sprints. If Scrum really worked, we’d get it right the first time, correct? A shift in team and organizational thinking shouldn’t take any effort.
5. The test team should refuse to play. Moving fast isn’t necessary, testing everything at the end of all the sprints is fine, correct?
6. Interpret the potential for refactoring code to mean that there is absolutely no reason to write good code to begin with, because you can always refactor it!

I joined the project at the beginning of its 3rd sprint, and Scrum was dropped in the 4th sprint. I still think Scrum has a lot of promise, and would like to give it a real try one day.

Related Reading:

Scrum Devleopment Process by Ken Schwaber.

7 Ways to Fail with Scrum by Jeff Sutherland

INCOSE 2008 - Can You Build an Airplane with an Agile Approach?

With all of the buzz about Agile, I have to mention that here at INCOSE 2008, I did not hear a single mention of it (except when I asked about it directly!). Actually, that’s not true, at one point I was excited to see a speaker’s slides which referenced applying agile processes as a step in a project. Then he spoke to the slide and I started to suspect he meant agile in the pure definition of the word, to move quickly. At the end, someone asked him the specific question as to whether he meant the agile software methodology and he clarified that he did not. So I left the conference wondering - with all the discussions about processes at a conference like this, why are they not ever speaking about agile?

Airplanes Are Not Software Requirements

My first guess - this probably relates to some of the core differences between systems and software engineering. I am going to over simplify this and just say that it is about scale. Systems projects are just a superset of software and hardware projects, integrating and deploying some combination of these. The teams of people deploying systems projects are quite large. And many of the projects discussed here are for government or regulated systems where specification and traceability is necessary. I could see how subsets of systems projects could in fact be developed using agile (pure software components), but I’m not convinced that an entire end-to-end project can. To put this in context, imagine you are building an airplane - a very commonly referenced type of systems engineering projects. Can you see this working using agile?

All skeptism aside, I do think that iterative development most certainly could work well on systems projects, and most people here would not argue that. In fact, I would love it if we could find examples of agile working on systems projects, because the number one feeling I get at systems engineering conferences is a craving for lighter processes.

I decided to do a little research outside the conference walls, and low-and-behold, I found a great article on this exact topic – “Toward Agile Systems Engineering Processes” by Dr. Richard Turner of the Systems and Software Consortium. The article is very well laid out, and I highly recommend reading it. He defines what agile is and what he believes the issue why most systems engineering projects are not agile. For example, he suggests that executives and program managers tend to believe that the teams involved have perfect knowledge about systems we are building, so we can plan them out in advance and work to a perfect execution against a perfect schedule.

Agile Can Work With Complex Systems

He talks to how to the agile concepts can work in systems projects. Here are a few examples summarized from his article:

• Learning based: The traditional V-model implies a one-time trip through, implying one time to re-learn. However, perhaps the model can be re-interpreted to allow multiple iterations through it to fulfill this.
• Customer focus: Typically systems engineering processes do not support multiple interactions with the customer throughout the project (just up front to gather requirements). That said, he references a study indicating the known issues with that on systems projects. Therefore, perhaps processes should be adapted to allow for this, particularly allowing for them to help prioritize requirements throughout projects.
• Short iterations: Iterations are largely unheard of because the V-model is a one-time pass through the development lifecycle. That said, iterations of prototyping through testing could be done in systems engineering in many cases. The issue is in delivering something complete at the end of each iteration. He suggests that this is not as important to the customer in large deployments as is reducing risk, validating requirements, etc. This is a great point to rememember the airplane example! Could we have even a working part of an airplane after 2 weeks? What about even the software to run a subsystem on the aircraft?
• Team ownership: Systems engineering is very process driven, so this one is tricky. Dr. Turner puts the idea out that perhaps allowing the systems engineers to drive it instead of the process to drive them, while more uncomfortable for management, might produce more effective results.

So while he does give some suggestions to adapt systems engineering processes to be more agile, I don’t think this will qualify as purely agile. And frankly if it we tried it, I think I'd be fearful to be in the airplane! But to quote Dr. Turner directly “…other hand, agility is much more a state of mind or philosophical approach than a set of rules that have to be followed regardless of appropriateness.” Using that idea, combined with what I saw at INCOSE 2008, I can see some definite opportunities for improvements for the field systems engineering.

Six Requirements Models For Agile Projects

When working on any agile project, most people will agree there is still a need to understand requirements. With the quick iterations of these projects, it’s more important than ever, to use visual models to capture the requirements. When done correctly, they are easier and quicker to create and understand than a list of written requirements. Selecting the appropriate models will vary by project; however, we can suggest a few common choices that work well.

High Level Models
At the beginning of the project, it is important to get a quick picture of the breadth of the project. This picture will help the team determine where to dive for depth. It is really important that these models are done as broad strokes, with just the bare minimum information. To get a sketch of that big picture, consider these models:

• Context diagram – This diagram simply sets the landscape of the project, clearly indicating the scope boundaries.

• Org chart – This is a model that often already exists in the organization. It can quickly help identify all the possible users or user groups that should be included in the project discussions.

• Data flow diagram – This is a quick sketch of the key pieces of data flowing through the system, including where it is created, changed and deleted. The data in this diagram should only be data that is important to the users of the system. They will help to identify the most important data and systems to work with.

• High-level process flow – Let’s start by saying this is nothing fancy or complex. The flow diagram should describe the major obvious steps. Again, the purpose is to sketch it simply, to give the big picture. In no way is it meant to be comprehensive or detailed.

Imagine one of your iterations requires bringing in new users to the team. These four models will give them an opportunity to quickly see the big picture of what this project is and where it is going, without having to read a 200 page spec (since there isn’t one!). You can also use them with your users to prioritize the most important pieces of the system for the iterations.

Models in the Iterations
Once you have prioritized the work for the first iteration, the two most popular models are likely to be:

• User stories – You can write these for the most important parts of the flow. They will be less detailed than the traditional use cases, supplying just enough depth to be developed.

• Wireframes – These will be connected to high-risk user stories, when sketching an interface might be a good aid to help the users explain what they need. These should be done in a quick modeling tool, or just by hand.

There will be other models. Sometimes you won’t even use these. The common theme in all of them is to create a visual representation of the requirements because it is faster to create and read. And with them all, only do the bare minimum necessary.

Four Ways To Improve Agile Requirements Management

One of the challenges of Agile projects is ensuring that the requirements remain “Agile”. While requirements are not necessarily neglected on Agile projects, an Agile project may erroneously take a waterfall approach to requirements.

Here are some simple techniques to adapt your requirements management effort to an agile project. The quotes at the beginning of each section are from the “Principles Behind the Agile Manifesto” at http://agilemanifesto.org .

1. Communicate Requirements Often And Effectively

“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

Two problems with email is that it is inefficient and easy to ignore. Email thread discussions can be long, tedious, and annoying. Despite the advances in emoticons over the past several years, it is also impossible to interpret non-verbal communication in email.

Resolutions to discussions around requirements, scope, and implementation will be resolved much quicker and to the satisfaction of more stakeholders through a meeting or hallway conversation.

If moderating a large number of email discussions is part of your current requirements process (for example, after the initial draft of the requirements doc is published), perhaps it’s time to schedule regular meetings at key points during the release cycle.

Established method: Email discussion

Suggested method: JAD, daily stand –ups

2. Use Collaboration Tools For Requirements Management

“Business people and developers must work together daily throughout the project.”

This is related to the other “C”—Communicate.

Communication on a project should be visible to all stakeholders in the project. Changes to requirements should be pushed out quickly and universally, without having to remember whether the developer who started last week is on the dev@mycompany.com mailing list.

Manage requirements in a central location where all stakeholders have immediate and easy access. An internal website for requirements and product management information is a much more efficient way of reaching your audience than emailing copies of documents to your stakeholders.

If possible, include collaborative tools like wikis and discussion boards as part of your website.

Established method: Word documents attached to emails

Suggested method: Wiki/Web page with automated change notification

3. Add Models And Wireframes To Your Requirements

“Continuous attention to technical excellence and good design enhances agility.”

If applicable, use wireframes or mockups with callouts as a supplement to your requirements.

This is especially useful on projects which call for enhancements to existing interfaces. A wireframe with brief text descriptions is easily consumable, and conveys a large amount of information very efficiently.

Include more detailed descriptions of wireframes and mockups in your user stories, and publish it on your internal product management website (see #2 above).

Established method: Design document/specification; Text-only documents.

Suggested method: Internally-hosted website with wireframes and bulleted descriptions

4. Keep User Stories Simple

“Simplicity--the art of maximizing the amount of work not done--is essential.”

Ensure your user stories describe one and only one feature, and only the functions necessary for that feature.

Looking through a large, monolithic document which describes multiple features to be implemented across several releases wastes time.

Breaking your user stories down into descriptions of the most basic functions required for a feature also helps maintain release discipline.

Resist the temptation to include requirements for “nice to have” or “future” functionality. This clutters the user story with unnecessary information.

Established method: Large document which describes many features

Suggested method: Wiki page/website with a single page devoted to a single feature. Include links to related features.