#NoBigProcesses — 2 Key Activities

In the first post of my series on #NoBigProcesses, I mentioned that there are only two fundamental activities in all successful efforts to deliver software. The first is to actually deliver something in some way and the second is to reflect on how and what you did to achieve that. Of course, there are myriad techniques to perform those activities but the fundamentals remain constant.

Rather than simply enumerating these techniques, in this post we’ll explore why the activities are crucial and examine questions we might ask to light the way, so to speak.

Ship Something

The very first computer program I wrote for someone else was in early 1982 for my high school basketball coach. He wanted to track the stats from games in order to be able to see them in a more cohesive manner than simply reviewing copies of the game sheets. He also warned me not to lower the number of turnovers or boost the number of assists for anyone named “Dave Rooney”, but that was the extent of the “requirements” for the program.

Since I was a programming novice and didn’t know any better, I started by building a “skeleton” of the program with a menu containing some of the actions he might want to take. These included options like Enter Stats, Print Report, etc. This, of course, didn’t take very long, and I showed him this skeleton and how to navigate the rudimentary menu. He made some suggestions about menu item name that were more meaningful to him, but otherwise was pleased with what he saw despite it being only a tiny slice of what was to come. Indeed, it didn’t really provide any value yet at that point because no one could even enter stats let alone do anything else useful.

As time progressed, I began to build the functionality behind those first menu items. The first step was entering the stats and persisting them to disk. I remember that, from the programming perspective, it was an aspect of the Applesoft BASIC language that I hadn’t yet used. Not only was the functionality required new, but I was in new territory skills-wise for myself! However, I figured it out, probably asking other computer geeks at the school like me and the Computer Science teacher a number of annoying questions along the way. I showed the coach the stats entry process, he asked for some changes to make it easier, I made them, he approved. We continued this process until he had a working solution which met his initial needs. I continued the work further, adding features like searching and additional reports, providing more capabilities to the coach.

It never occurred to me that I was doing anything unusual, let alone radical, by working this way. Indeed, the conventional wisdom of the time suggested that my approach was all wrong because I didn’t determine all of the requirements, analyze what they meant, design the system, get approval for the design, build the whole damned thing, test it, and deliver in a big bang when it was all done. It wasn’t until a couple of years later when I was in university that I was told of the evil of my ways. Even then in the mid-80s something felt wrong about this all or nothing approach.

In the over 35 years since that stats program was built, I can point to dozens of occasions where I applied that “build a bit, let them use it, learn & adjust, build the next bit, rinse, repeat” approach. It was in those situations that I was most successful. I can also point to the times that delivering systems was quite challenging, and each of those followed the conventional wisdom of the waterfall approach.

To obtain that valuable, meaningful feedback, we must actually deliver some increment of software

So what can be gleaned from this? Well, obtaining feedback is one of the most important aspects of delivering software. That said, the most valuable feedback comes not from a document, but rather from the real system in the hands of people who will be using it.

Therefore, to obtain that valuable, meaningful feedback, we must actually deliver some increment of software. We must ship something! In order to minimize the risk of doing work that isn’t delivering value, we must make that increment as small as possible while still being representative of the solution as a whole.

Reflect

Shipping software is great! It gets value into the hands of the people who need it. It gives those of us who build software a sense of accomplishment! We solved the problem! We made someone’s life easier!

Or did we? How would we know? Did we really accomplish anything? Did we work ourselves to exhaustion to deliver the software?

These are the types of questions we want to ask as part of the second fundamental activity on successfully delivering software — reflection!

This is where we can ask powerful questions about the work we’re doing and how we’re doing it. For example (in no particular order),

• Is the work we’re doing meeting the most pressing business needs right now?
• How well did we meet those business needs?
• What could we have done better to achieve that?
• Did we introduce defects that need to be avoided in the future?
• How well did the team work together?
• Can we improve communication and collaboration?
• Was our customer happy with our work?
• Was our team happy?

It’s already relatively common within Agile processes to have a retrospective after each sprint. Even before Agile, it wasn’t unusual to have a “post-mortem” after a project was completed. These are both forms of reflection that are intended to produce learnings and actions to be applied to improve later efforts. Provided that what was learned is applied in practice and the actions are carried out, this is all good!

Feedback is critical to success, so we don’t want to defer obtaining it any longer than is necessary

But reflection can happen much, much more often in order to provide that value to groups. If a typical sprint is 2 weeks, why wait that long to reflect on a group’s work? As I mentioned above, feedback is critical to success, so we don’t want to defer obtaining it any longer than is necessary.

Consider defects for a moment. I’m a big advocate of applying a light version of Root Cause Analysis when we discover defects. For each one, we spend a few minutes asking the questions,

• What is the actual defect?
• What’s the nature or type of the defect?
• Could this same defect or type of defect exist anywhere else in our system?
• How do we make it impossible to have this type of defect?

This doesn’t have to take very long, and in my experience the conversations and actions it drives helps to radically improve quality. Root Cause Analysis is a form of reflection that can happen anytime, not just during a regularly scheduled retrospective.

This is just one example of the necessity of the second activity, Reflect.

While the notion of “Ship something and reflect” may sound simplistic for all but the most trivial of cases, it provides a solid foundation on which to build a process that works in your particular context. Agile approaches base themselves on the same foundation, though in the wild their implementations may tend towards approaches that would be more recognizable as waterfall. This is why I prefer to peel away all of the layers to get to the essence of successful software delivery:

• Ship something;
• Reflect on what and how you did in order to improve.

For every principle you follow and every practice you use, you should be able to trace it back to one of these two activities.

Next up in this series is, “#NoBigProcesses — It Needs a Little Something!”