Agile Animal Inc.

 I like getting paid.

I am not saying that I go to work for a paycheck - I love what I do - but a person has to eat and to eat they need to get paid.

For this reason I suspect you like getting paid too.

This is not a bad thing. It simply creates the reality that someone is going to have to pay for all the work that you do in a day. We call that person the customer. Whether the customer is a larger company or 100,000 teenagers they are going to have to pay for each line of code that you develop.

The truth is that this actually creates a simple answer to a complex problem. Often when developing software it is hard to know where to draw the line when it comes to features, documentation, etc. People often debate this for hours. It is actually pretty simple:

Make sure the customer is willing to pay for everything that you do.

It turns out that this actually can be broken down into two categories of user stories:

• Stories that have value so the customer is will to pay for them. (this might be that new feature you are working on.)
• Stories that have no value but are required to get paid. (this might be the documentation needed to use the new feature.)

Think of this as working and filling out a time sheet: you need to work to get paid and you need to fill out your time sheet to get paid. Valuable stories and required stories. Pretty simple.

In Scrum this simple concept forms the basis for a product backlog. The Product Owner (a representative of the customer) and the ScrumMaster make a list of stories and then assign a value to them. The team then estimates how hard a task will be to complete - lets call this the effort. Sort the list by dividing the value by the effort. Again, simple.

Priority = Value / Effort

Things only get a little tricky when we talk about required stories (the ones without value that are still needed to get paid). These should be kept up to date with the progress of the project. For example, a required manual should be updated once a feature is demo’d. This way the product can be released as needed with little notice.

As you work through the list you will eventually realize that at some point the value returned by a stories does not pay for your development costs to produce it. This is when you wrap the project up and deliver it. Again, simple.

So to recap here is the way to prioritize your work:

• Only work on stories that get you paid:
  • this can mean stories with value or
  • this can mean stories that have no value but are required.
• Don’t work on anything that is not required to get paid.
• Priority = Value / Effort
• Sort your list by priority.
• Even thought the priority of a required story is essentially zero, keep required stories up to date with your current progress so that you can deliver the product as requested by the customer.
• The project is done when the customer is happy with the current features or when it will cost more to develop a story than it is worth to the customer.

Follow these rules and you will get paid.

And you will be happy.

And your customer will be too.

Start small. Think BIG.

I read a book by Seth Godin a while back called "The Dip." (Well, by read I mean I listened to it after buying it from Audible.) The book gets a bit repetitive but the message is relevant. It is a book about quitting as a technique for success.

I am going to repeat that for those of you skimming this post: "The Dip" is a book about quitting as a technique for success.

Initially this should seem strange. For some reason society seems to think "winners never quit." Society is wrong. Winners quit. They quit so quickly that you might not even notice they tried at all. That is the whole point.

In my post on Prioritizing Work I talk about how we need to work from a backlog that orders stories by value. Most often you will find that the high value items are usually difficult. A difficult item with low business value is something that likely will never be done - why would you waste time working on a problem that has no value. At times you will find that a projects success hinges on completing some difficult items. They may be so difficult that , for many reasons, they are impossible and the software project is doomed to fail. That is why we need to build these features first.

If a software project fails after one week, great! This is the best possible way to fail: very little time and effort invested. Chances are there is disappointment but everyone survives.

Software projects that take years to fail bring down companies. I have personally seen it happen.

The only thing better than failing quickly is succeeding quickly. What better success to start a project with: tackling the hardest problem!

In XP they would call this a spike solution. In Scrum this is the way we organize our backlog. Either way the concept is simple: don’t invest time and effort into a project that you cannot finish. 

Failing early is the key to success.

I realized that this really answers a simple question and then presents a much harder one. Namely, you need to know if the problem you are working on is hard or if it is impossible.

I don’t have the answer for this one. There is no sure-fire way to measure your talent or that of your team and know if you will succeed. Analyze the problem. Be realistic about the availability of the resources need to complete it. Think about what is needed to succeed. Is success possible. Weigh the risks and rewards.

It is hard to predict success and failure. That is not what this is about. It is about honestly evaluating if success is an option and if failure is inevitable.

If you can’t succeed, fail quickly. 

Start small. Think BIG.

Ever ask someone how they were doing and then got the reply, "Fine" - what does fine actually mean?

As far as I can tell fine used to mean a little closer to good then bad but now I am convinced that it actually the equivalent of someone saying either "You don’t really care how I am feeling and I don’t really care to tell you!" or it means "I am feeling so bad right now that if I actually tell you I am going to burst into tears and it is going to ruin your day."

I think that software teams have the same problem with the word "Done"  - what does done actually mean?

Done can mean a lot of things including:

• Delivered
• Documented
• Tested on Production
• Pushed to Production
• Staged
• Tagged in the Repository
• Acceptance Tested
• Ready to Demo
• Committed to the Repository
• Unit Tested
• Peer Reviewed
• Ready to Test
• Barely Working

What does done mean for your team?

An exercise that like to do is to have everyone write down their definition of done and then read out the definitions to the team (obviously without naming who wrote the definition). Then as a group come up with a universal definition of done. Once you all agree hang it up on the wall in a nice frame. Have the creators sign it. The visibility of the definition will keep people honest.

It is important to note that the definition will need to be different for every team. You probably do not have access to the production environment. Maybe you work for a large company that has policies requiring someone else stage or acceptance test your code. Work with what is realistic.

When it comes to the definition of done the most important thing you can do is just talk about and agree upon the definition. The definition is less important.

Once things are getting done then work on expanding your definition.

When you are starting out it is sometimes a tall order to go from a concept to code that is working on production in a week. There needs to be a lot of tools in place to allow this to happen. As the team gets better include more in the definition. If you are working on a large project going from a Story to Done in a week or two might be a tall order without the right processes and the right tools.

Here are some practices and tools that will help expand your definition of done:

• Behavior Driven Development: rSpec, nBehave, NSpecify, JBehave, NSpec
• TDD and Unit Testing: xUnit (Yeah, there is a unit test framework for your platform. You need to fine it though.)
• Continuous Integration: CruiseControl, CruiseControl.NET, Cruise, TeamCity
• Virtualization: VMWare, Cirtrix Xen
• Scrum, XP: Mingle

When we started out our definition of done was demo-able. Now it means delivered.

Start small. Think BIG.

 

I have decided to write a series of posts that I am now going to call my Agile To Do List. If you are planning on using some form of Agile software development like Scrum these are things that you are going to need to do.

This list is not going to be in order of priority for you. You need to evaluate your own situation an determine where improvements are needed most. However, I am quite convinced that if you are able to tackle this list with your team you will succeed.

I am going to add to the list here as I write the articles so that you will be able to grab them from one central place.

Okay, without further ado here is the Agile To Do List:

• Define Done (and make sure this includes testing).
• Create a Prioritized List (Backlog) to work from.
• Ensure Quality
• Fail (or Succeed) Quickly
• Have a Scheduled Weekly Demo (that ends with a reflection).
• Have a Scheduled Weekly Reflection (that begins with a demo).
• …

Like I said, as I complete the articles I will post the links here.

 

Agile software development makes sense. Reduce waste, improve productivity, it sounds great. Maybe you buy into Scrum, maybe Crystal Clear. There is a lot of information on the web discussing Agile project management.

The biggest challenge is not the planning, it is actually getting things done. Writing the code.

When it comes to writing code there are some practices that can help developers succeed: test driven development, continuous integration, automated testing.

We know what we need to do. We know why. But, how?

How is the real trick. How do you take a team of developers, any team of developers, and make them agile. Agile in their practices and agile in their thinking. 

How is the question I intend to answer.