In Part 1, I talked about small stories/chunks of work, checking in all the time so you could build often and see progress. That assumes you know what done means. Project “done” means release criteria. Here are some stories about how I started using release criteria.
Back in the 70s, I worked in a small development group. We had 5 or 6 people, depending on the time of year. We worked alone on our parts of the system. We all integrated into one instrument, but we worked primarily alone. This is back in the days of microcomputers. I wrote assembler, Fortran, or microcode, depending on the part of the system. I still worked on small chunks, “checked in,” as in I made sure I saved my files. No, we had no real version control then.
We had a major release in about 1979 or something like that. I’d been there about 15 months by then. Our customers called the President of the company, complaining about the software. Yes, it was that bad.
Why was it that bad? We had thought we were working towards one goal. Our customers wanted a different goal. If I remember correctly, these were some of the problems (that was a long time ago. I might have forgotten some details.):
- We did not have a unified approach to how the system asked for information. There was no GUI, but the command line was not consistent.
- Parts of the system were quite buggy. The calculations were correct, but the information presentation was slow, in the wrong place, or didn’t make sense. Our customers had a difficult time using the system.
- Some parts of the system were quite slow. Not the instrument, but how the instrument showed the data.
- The parts didn’t fit together. No one had the responsibility of making sure that the system looked like one system. We all integrated our own parts. No one looked at the whole.
Oops. My boss told us we needed to fix it. I asked the question, “How will we know we are done?” He responded, “When the customers stop calling.” I said, “No, we’re not going to keep shipping more tape to people. What are all the things you want us to do?” He said, “You guys are the software people. You decide.”
I asked my colleagues if it was okay if I developed draft release criteria, so we would know that the release was done. They agreed. I developed them in the next half day, wrote a memo and asked people for a meeting to see if they agreed. (This is in the days before email.)
We met and we changed my strawman criteria to something we could all agree on. We now knew what we had to do. I showed the criteria to my boss. He agreed with them. We worked to the release criteria, sent out a new tape (before the days of disks or CDs!) to all our customers and that project finally finished.
I used the idea of release criteria on every single project since. For me, it’s a powerful idea, to know what done means for the project.
I wrote a release criteria article (see the release criteria search for my release criteria writing) and explained it more in Manage It! Your Guide to Modern, Pragmatic Project Management.
In the 80s, I used it for a project where we did custom machine vision implementations. If I hadn’t, the customer would have continued asking for more features. The customer did anyway, but we could ask for more money every time we changed the release criteria to add more features.
I use release criteria and milestone criteria for any projects and programs longer than three months in duration, so we could see our progress (or lack thereof) earlier, rather than later. To be honest, even if we think the project is only a couple of months, I always ask, “Do we know what done means for this project?” For small projects, I want to make sure we finish and don’t add more to the project. For programs, I want to make sure we all know where we are headed, so we get there.
Here’s how small chunks of work, checking in every day, and release criteria all work together:
- Release criteria tell you what done means for the project. Once you know, you can develop scenarios for checking on your “doneness” as often as you like. I like automated tests that we can run with each build. The tests tell us if we are getting closer or farther away from what we want out of our release.
- When you work in small chunks, check them in every day and build at least as often as every day, you can check on the build progress. You know if the build is good or not.
- If you add the idea of scenarios for testing as you proceed, release becomes a business decision, not a “hardening sprint” or some such.
Here’s a little list that might help you achieve friction-less releases:
- What do you need to do to make your stories small? If they are not one day, can you pair, swarm, or mob to finish one story in one day? What would you have to change to do so?
- If you have curlicue stories, what can you do to make your stories look like the straight line through the architecture?
- What can you do to check in all the time? Is it a personal thing you can do, or do you need to ask your entire team to check in all the time? I don’t know how to really succeed at agile without continuous integration. What prevents you from integrating all the time? (Hint, it might be your story size.)
- Do you know what done means for this release (interim and project)? Do you have deliverable-based planning to achieve those releases?
Solve these problems and you may find frictionless release possible.
When you make releasing externally a business decision—because you can release internally any time you want—you will find your project proceeds more smoothly, regardless of whether you are agile.
Reminder: If you want to learn how to make your stories smaller or solve some of the problems of non-frictionless releases, join my Practical Product Owner workshop, starting August 23, 2016. You’ll practice on your projects, so you can see maximum business value from the workshop.
| Reference: | Making Release Frictionless, a Business Decision, Part 2 from our JCG partner Johanna Rothman at the Managing Product Development blog. |
