Sticky Note Power

Ah, the power of the sticky note. That little piece of genius has freed me from brainlock once again.

Sometimes when your faced with a problem that is just too big to wrap your head around it is tough knowing where to start. I am the type of person that likes to see the big picture before I dive into the details, so figuring out that big picture from a big pile of details can leave me stuck in analysis paralysis.

I've been dealing with a problem at work about how to best start an effort moving that has been stalled out for a very long time. Everyone agrees that the end game is a good idea, and everyone wants to do the work, but nobody has been able to figure out how to get started. And I have to admit that I beat my head against that same wall myself for over a month. Then, I decided I had to change my perspective.

When Sherlock Holmes would get stuck on a particular problem, sometimes he'd climb up on a piece of furniture to look at a room in a new way. The theory was that if you can radically change your perspective new things can emerge from the new way of looking at your problem. That same theory is at the heart of my sticky note technique.

The technique is basically an effort to break apart logically grouped tasks, ideas, and issues and to recombine them in new ways until a new picture jumps out at you. So, in this circumstance, I started pouring through my inherited lists of requirements, budgets, issues docs, use cases, anything I could get my hands on. And every time I came across a new piece of information I wrote it on a sticky note and stuck it on my wall. I didn't care if the information was an outstanding task, a risk, a needed capability, or whatever. If it represented potential work, it went on a sticky note.

You'll find that as you write and stick your notes on the wall logical groupings will emerge. Often that first set of groupings will be how you stick the notes on the wall. But soon, you'll see that lots of notes don't fit nicely into the groups you had in your mind. Those things are the things that are preventing you from moving forward. They're good. Keep writing them down. Try to create new groups in which to put those notes.

Eventually, you'll start moving notes. Ones you thought were in one grouping really belonged with a bunch of stuff you didn't have in any group at all. Don't be afraid to abandon your old groupings. Those old groups are what has gotten you into this problem in the first place. Reorder and regroup your sticky notes over and over until their groupings just feel right and every note has a home.

Then, it's time to cull the weak notes. Start combining and eliminating notes. Try to get your notes to the same level of granularity. Chances are some of the things you thought you needed to do aren't really that important after all when you see your new groupings. Set them aside or chuck them in the trash.

Once you feel you have good groupings, then lay out a basic timeline on a big wall and start slotting each of those notes into the timelines you'd like to hit. Use horizontal rows to show basic dependency.

Presto! You now have a new plan of attack and can build out your more detailed execution plan.

Meaningful Metrics

Where is the line that separates process for the sake of process and process that adds value for most of the people most of the time?

How does one develop technology metrics that are meaningful to the majority of efforts without misrepresenting those that don't fit the measure?

I've run software development projects in a wide variety of environments and with a wide variety of methodologies. I've been a scrum master and I've guided traditional waterfall teams. And I've become increasingly convinced over the years that the only really meaningful metrics for teams are customer satisfaction-based. Metrics like agile velocity and traditional on time/scope/budget metrics can be useful as a guide as you progress through your efforts, but at the end of each project those metrics were not nearly as meaningful as how happy my customer was with the end product.

As you start any development effort take some time to identify how you know whether or not you succeeded. Then, choose the methodology that best supports that end game. Sometimes, speed is everything and other times predictability is everything. You can set yourself up best to succeed if you understand what is most important to each of the stakeholders you impact, and that includes your development team.

Then, you have to develop three sets of metrics.

The first set of metrics is in support of your chosen methodology. Are you measuring velocity accurately in an agile world and are you controlling scope and timelines in a traditional model? How are you controlling for quality? It matters little what methodology you chose as long as you ensure that you control for and measure the things about that effort that matter to your stakeholders and introduce risk to your efforts. Use this set of metrics to drive your effort to completion and success.

The second set of metrics is in support of measuring a project's success. Assuming that on scope, on time, and on budget is the definition of success for every project is just as bad as assuming waterfall or Scrum is the right software development methodology for every project. If your stakeholders indicate that revenue increases are the definition of success, then that had better be your success metric. And you had better find a way to measure that metric, even if it means more development work. There is always a way to isolate and measure those success factors if you build specifically to support those metrics. Let's use our increased revenue example as a test. How could you isolate revenue increases due to a web site change when there are a million other factors that could also impact revenue? Split A/B deployment and measurement is a potential solution that jumps to mind. But if you don't build specifically to support the measurement of that goal, then you'll never be able to quantify your effort.

Finally, the last set of metrics you need are ones that give you visibility across efforts. I recommend you develop a satisfaction scale that is independent of any specific success factor. Then, for each effort you undertake, map the project's success factors to degrees of satisfaction. Then include a subjective component to the satisfaction measure for an aggregate metric system that can measure different types of projects similarly independent of their methodology or definitions of success.

The bottom line is that measurement of your efforts is critical to your success. Just don't confuse metrics that facilitate the successful development of your software with the set of metrics that measure its success. They often are very different sets of things to measure. Give them both the attention they deserve and you set yourself up for success.