The stuff we do, in more detail

Developers: frantic to free in 6 easy steps (part 5)

This is part of a series of posts chronicling my team’s adventure in making release day suck less.

Note: I would highly recommend giving each of these a shot in a way that fits your team. I would also recommend trying to implement each one at a time. If you spend time focused on each step, tweaking where there’s pain and adjusting to your team’s personality you’ll find everyone owning the end result. You’ll also show them you don’t know everything and need their help figuring some of these things out, which actually helps build a stronger team.

Here’s what we did, pretty much in the order in which we added them to our process:

5. Iterative requirements gathering

This one is a little hairy. Sometimes it’s hard to get buy-in on this from the higher ups (and in our case the Project Management Office), who tend to be accustomed to a more waterfall development approach. They like to know what it is exactly that we are building, and when it will be done. Oftentimes also exactly when it will be done.

However, if you can get over that hump there is sweet honey and the nectar of success on the other side. That may be a little strong, but it has been working well for my team. Anyway, you may be asking: "how do you get over that hump?" I thought you might… and unfortunately I don’t have a good answer. In my case we kinda went "black ops" and just did it for a while before everyone else noticed. The people and teams outside my own that I worked with were all in on it enough to allow me to try the process, but until we started seeing greater success we didn’t tell anyone. I wouldn’t recommend that as a general approach. I can only recommend you survey the landscape at your company and see what you think will work.

The most important thing you can do for people who need convincing is to provide evidence of the problems with trying to gather everything up front before you start. Given the failure stats of medium to large development projects that shouldn’t be too hard for an open-minded manager. Once you accept that the current way isn’t working, a different approach becomes more palatable. From there, it’s easy to show that iterative requirements gathering and iterative development allow you to fix the problem in one simple way: fail earlier.

You get enough requirements to slap some mockups together, to get the business folks thinking about the screen flow, and data requirements. If the business can’t agree, you’ve failed without development effort and lost very little time/money.

Mockups turn into a discussion about some additional requirements they forgot about, that they remember now that they see it on the screen. Again, if the business can’t agree, you’ve failed without development effort and lost very little time/money.

As you iron those requirements out, you turn the mockups into a proof of concept or maybe even iteration one in the real system. You’re now ready to demo and flush out even more forgotten or assumed requirements. If you’re off base you have time before setting the architecture in stone to adjust. If you’re WAY off base, you can always still bail.

You’ll notice I mention mockups in step one. I try to force myself to create as soon as I think I understand enough of the project to give the business owners something meaningful. By creating this early I focus my questions around their immediate needs, meeting their end-goals, and honestly revealing their mental picture of the screens already in their perception.

Now that we all have something tangible to point at, draw on, and cut apart we can have meaningful conversation around what the system does when you “click that button” or “enter such and such into that textbox”. It moves The System from abstract to concrete terms and removes the hand-flailing involved with describing chunks of functionality. In order to do that, you need to be able to get started early and risk missing the mark. You know you will miss the mark sometime, and missing it earlier allows you to correct before you’re so deeply locked into your metaphor/architecture/technology.

This concept goes hand in hand with my next post in this series in that what we develop, we release. Ship it as soon as it becomes a viable product or tool to be used. But that’s a post for another day…