Six Ways To Be An Agile Adolescent

Do you get along with everybody? Are you universally loved in your office?

Then you are a failure.

There are those that are born great and those that are told they are great guys. Especially working in an Agile environment, the requirements stakeholder has to be… well…

A screaming, pouting adolescent.

They don't call it a scrum for nothing: It's a battle. If you're not arguing, not giving voice to every seemingly petty impulse, you're not doing your job. But don't worry, I can help you tap into your inner child. Start with these techniques:

1. The Eye Roll: This classic we all mastered as teenagers-- stop a line of BS before it starts (you should know it when you see it, you're the adolescent, after all).

2. Belch if You're Bored: You should never be bored in a scrum. If you're bored you're not on task. If you're in a meeting [which should be a warning sign in and of itself] try a combo: belch, then eye roll, then moan "What are we doing here?" Sartre would approve.

3. The Pedantic Reductionist Humiliation (PRH): When you need to prove a point, paint the picture out in irreducible terms and make other people say it back to you, ESPECIALLY if they don't want to. Chase people down and pin them; the rhetorical equivalent of "quit hitting yourself".

4. Appropriation of the Winning Argument: This is a great technique. If you find yourself wrong, just switch sides immediately and congratulate yourself.

5. The Schizoid Handshake: When things get really heated, wax philosophic and say "I really appreciate the interaction here. This intellectual energy is critical to creating a good product." Feelings don't get hurt as easily if everybody thinks they're part of an exclusive group, like hanging with Dorothy Parker at the Gonk**.

6. Forget Everything by Monday: Remember everything that happened in the trailing 48 hours then forget about it (this includes grudges) unless it is a plotter printout posted on a wall in your immediate work area.

The only nice thing about the business of being a child is that, while perhaps unpleasant, your role is critical.

Without you, things stop moving.

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

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.