- Where you are now (current location)
- Where you want to go (destination)
Knowing where you are now and where you want to know provides us with a rough framework for navigation. If this were an ocean voyage, we could take prevailing winds into account, then head straight for our target location. Unfortunately, for most of us, this is more like an orienteering course. It's cross country with many, many obstacles.
So these first two essential questions provide us with a few implied questions.
- What are the anticipated road blocks or problems we could encounter?
- What methodologies or ideas will govern our travel paths?
I find the second question the most important, especially for a software shop. For this article, we're going to focus on that part of the question. (The other areas are important too, but that'll be for a future article, if anyone wants it.)
If you know me or are familiar with my work, you know I'm a huge fan of the Agile software movement. However, like many religious denominations, Agile sometimes presents a unified front, but it's generally a festering pile of jealousy and back biting. (And I mean that in the most loving and caring way! And this by no means is limited to Agile, but any group that grows to any appreciable size.) There are several schools of thought on how to do most tasks in an Agile way, so even if you're shop is dedicated to the pursuit of Agile ideals, you'll still find plenty of room for debate.
That's why I specifically like to spell out the different schools of thoughts I'm invoking for the goals I want a shop to you follow. I usually break it up into four different categories.
1) The Agile Manifesto
2) Development Practices
3) Project Management Practices
4) Custom Practices
Our first influence is the Agile Manifesto itself. It's a great document with four areas of focus.
- Individuals and Interactions Over Processes and Tools
- Working Software Over Comprehensive Documentation
- Customer Collaboration Over Contract Negotiation
- Respsonding to Change Over Following a Plan
The manifesto is a set of principles, and that's why it's so hard to pin down exact practices... as to why we need exact practices, revisit the Dryfus Model of Skills Acquisition and Why Beginners Need Steps. I like to start with the manifesto because anything that comes after needs to fit into one of these four categories. If it's not driving one of these core areas, then be very, very careful about including the practice in your roadmap. The manifesto isn't gospel, but it's a pretty solid document.
Next, we want to tackle Development Practices. This usually translates roughly into the eXtreme Programming (XP) practices. The early XP adherents were a bit, ahem, strident in their insistence that you could pick and choose any of the XP practices you liked.... as long as you used them all. As a result, many of the practices have gotten a bad reputation. Don't discredit the ideas though. This is a baby and bathwater situation. XP is still around because it works and there's gold in it. Reference the XP practices to drive your development or engineering practices. Here are a few examples.
- Two Sets of Eyes XP would get this via pair programming. I also like light-weight peer code reviews. But always require two people to understand the code before it's checked in
- Test Relentlessly You should eventually move to Test Driven Development, but starting teams there is difficult. I find Defect Driven Testing an easier starting place, but don't ever make the assumption that DDT is a stopping place. It's a beginning, not an end.
- Story Cards for All Work Story cards drive small units of work and they keep your work visible. (See more in my related article 3x5 Cards. What a Waste!
You get the idea... use the practices from XP to decide what your shop will pursue in that arena. Now onto project management practices.
Scrum is the predominant source of Agile project management today. It's various certifications have become how many people get their first introduction to Agile. It introduces ideas that are used to manage a team, or a team of teams, in a way that can be understood by management, while still fostering Agile practices.
Some of the roadmap items you can take from Scrum include:
- Scrum Master The scrum master runs meetings, keeps an eye on the team, and generally keeps everything moving forward smoothly. In many shops that I coach I make the Scrum Master role a rotating one at first. This gives everyone a feel, and a great amount of sympathy, for the few that take on the role full time later. It also provides a readymade set of experienced scrum masters when your company experiences rapid growth and needs more teams.
- Product Owners Jeff Sutherland (one of Scrum's co-creators) says that the product owner's job is to groom the backlog and feed the team. They interface with the multiple customers every development team has (sales, marketing, executives, customers, support engineers, etc) and gather the work to be done. They prioritize the backlog of work based on their view of what needs to come next, and then present it to the team in a sane way. They break down the work as far as they can, then the team helps them break it down further.
Again, you get the idea. Take the ideas in scrum and see where your weaknesses, and your aspirations, are.
Finally, I like to mix in a number of custom practices. These are the ones that don't always fit into the previous categories, but contain work that enable the previous ideas to be tackled effectively.
- Database scripting You'll need to be able to script your database schema creation, backups, as well as data loads and backups. Please note that opening a GUI isn't scripting. Be sure to use the right tool here.
- Solid deployment scripts If you're deploying your product by hand, it'll be impossible to do any type of continuous deployment.
- Acceptance Tests These tests are usually integration tests and always require a bit of development time. You have pick the right tools, sometimes change your product to enable the testing, be able to deploy a small, representative database (for a known data set to test against), script the deploy, then find out where your assumptions were wrong causing the deployments or tests to fail. Then you start picking your QA staff's brains about what to automate.
- Big Visible Charts Chart anything that can provide good information to the team. Burn down charts, burn up charts, disruption indexes (your planned work versus the work that was actually done), and so on.
Again, this list could go on for a while. Once you've decided what you want to tackle, do some self assessments. Decide where you think you're at today. Then, get another set of eyes, just like on that code. Find an experienced Agilist within your organization, or bring in a coach, but see if they see what you're seeing. Far too often, we've all bought rose colored glasses, or become acclimated to the pain, and it's difficult or impossible for us to see those problems ourselves. Fresh eyes are invaluable.
Now chart your standing today. For this type of work I find spider (or radar) charts work well, but use a format that makes sense to you.
Decide where you want to be with your goals in three, six, and twelve months. At each milestone, revisit your charts and see how far you've come. I like to use the spider charts with the interior colored in, and with each milestone using a different color, as seen in this MS template. I think it makes it easier to see your progress.
All this work tells us where we want to go, and some of how to get there. Take your three month goals, and see what can be done this month. Then this week. And finally, today.
If you don't start today, then tomorrow will also be too busy. And so will next week. Eventually you'll stumble across an old spreadsheet on your hard drive from years ago.
If you're going to create a road map, put in on the wall where everyone can see it. Then take your first step.