A man asked me “do you like scrum?” – meaning the Scrum agile software development process.  I get questions like this a lot. In my opinion, agile processes are good, but ANY agile process will give you approximately the same results. Scrum is fine. So is the alternative. If everyone on the team happens to have been trained for Scrum, use the rituals of Scrum. Otherwise, I have some simple suggestions.

Any agile process is based on a few principles:

• You build to user “scenarios”, “stories”, or “storyboards”, hopefully based on a real user, rather than abstract requirements.
• You release frequently to users, using “milestones”, “sprints”, or “iterations”.
• You fix the release date, not the features. You cut features so that you can release on the expected date (or time, if you are really moving quickly).

Building to user stories prevents you from wasting time on things that might turn out to be irrelevant. Releasing frequently makes you improve quickly. Releasing on the appointed date keeps you from getting stuck in the common trap of never releasing. As long as you follow these basic principles, you will have an agile process. You may even get good software.

You can wrap some extra conditions and terms around these principles to create an agile process with a new name, a lot of new words, and a new set of seminars. That makes people feel good because they can talk in a shared language with other people who have been to the same seminars. Best of all, it makes money for people who sell seminars.

I suggest the following simple approach to Agile:

1) Set up Milestones in your ticketing system. Put a date on the first (or next) milestone. There must be at least three milestones: The next release, a following release (where you move requests that don’t make it into the next release), and a far-off vision milestone that can hold and preserve all of the requests and ideas that aren’t scheduled for immediate implementation.

2) Make user stories (also called use cases or scenarios) and storyboards for any big features. A storyboard is a drawing, like a flowchart, of the screens that a user will encounter while using the feature to do a particular task. You start by thinking of a user, and an intended task. Ideally, the user is a real user that you know. This source of authority and detail makes it a lot easier to answer questions that come up about your story. Then you start at the beginning and draw screens and lines (links between screens) until you reach your goal. You can get nice drawing software for this. Personally, I write on a piece of paper or a whiteboard, take a digital photo, and attach it to the related tickets.

3) Write tickets with feature and task requests, assigned to the appropriate milestones.

4) A developer or designer should select one ticket at a time from the list of tickets for the next milestone, put his/her name on it, and commit the related changes as quickly as possible.

5) Do a daily build to a staging machine. This is very important if you have a distributed team, because the daily build is the thing that unifies the team and ensures they are all working on the same thing. The daily build also helps testers. A project goes a lot faster if you test every day, instead of every week.  And, improves your build process so that it is more likely to work smoothly when you do a production build. You should invest in staging systems and build scripts at the very beginning of the project.

6) Test, close, and write tickets at least once per day. If you have a big group that includes users, testers, and project managers, you may need to specify some rules about who gets to post tickets (everyone), who gets to assign a ticket to the next milestone (the manager, this is the main control point), and who gets to close tickets (you have to decide whether developers should close their own tickets, or whether someone else should test their work).

7) When release time comes, fix as many tickets as you can, and move the rest to the following milestone.

8) Do the release.  Ideally, there is no decision about whether to do the release.  You always release on the appointed day.  Releases are the fuel for the development process, and need to do them for the benefit of the development team, if not for the benefit of the users.  You can control quality with a different decision - deciding whom to release to.  Take pressure off by creating an option to do a limited or beta release.

Remember the daily build. If you have a distributed team, you want everyone working on the same thing.