Monthly Archives: October 2012

Process Patterns: Design Patterns for Process Nerds

Ever hear of ITIL? It’s a great way of looking at an entire IT department. How about SPICE? It’s a way to assess software development practices? CMM? A Maturity model for software development? CMMI? An extension of that model to integrated platforms.

How about PSP? A way to manage your personal work habits to develop software. ADKAR? A way to talk about organizational change. The MAT? A way to measure software process risk. (I invented that one). SIPOC? An older way to describe processes. BPM? A way to visually describe how the business works.

I could go on at length. Once you get through learning a few programming languages, then how systems go together, there’s a whole other world of patterns of how people organize and create value when working on technology projects.

When you start learning Object-Oriented Programming practices, you eventually will hear about Design Patterns. They’re little blocks of reusable solutions to common problems. The idea is that when you come across a common pattern, don’t re-invent the wheel. Instead pull one of these pre-canned ideas from the book and kablam! Presto Chango! You have solved a problem.

What really happens, though, is a little different. Once design patterns are learned, folks start seeing them everywhere. I’ll never forget looking at the data model for a retail store back around 2000. It had over 900 tables in there! Just to sell stuff to people. When I started looking for reasons why, I noticed that the architects had taken every problem they ran into and applied a data modeling design pattern. So there wasn’t a customer. There was a party-person pattern. Everything in the problem domain splayed out into 5 or 6 tables.

Instead of thinking about the problem we’re solving, patterns can encourage us to jump to over-reaching (and many times very constraining) premature solutions.

It’s the same way with process patterns. Process patterns encourage us not to think about the exact situation we have, weighing pros and cons of various options. Instead they promise to provide us with pre-optimized solutions.

Just like design patterns, once you start learning process patterns you have a tendency to shoot yourself in the foot.

How to prevent this? At all times focus on the rate your team is providing value back to the organization. That value can be defined various ways, but it’s critical to identify and track it. Personally I find user stories work the best here.

No matter how you structure your work, if you over-rely on patterns you are setting yourself up for big trouble.

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Why your programming skills suck at project management

I was working with an Agile program doing planning last week, and we were all busy creating our release plans and beginning to scope out our product backlog. Every team was using big visible indicators of work, usually post-it notes and blotter paper.

Except one. As we started socializing our work, talking about dependencies and identifying opportunities to refactor, one team came up and presented their backlog on the projector using a spreadsheet. Everybody stopped while one person went down each line, item-by-item, for 100 items.

This kind of meeting, where somebody grabs a projector and folks stare at a wall for hours, is one of my pet peeves. But these guys were new and I saw it as an opportunity to coach them later on. I timeboxed their presentation to limit the damage, then we all managed to complete.

At the end of the day, when we were getting feedback, I got quite a surprise! The group who didn’t physically work with their backlog thought that all this post-it and physical stuff was so much rework. Why not everybody just complete their work ahead of time and we could all show it on a projector? Ten teams, all with hundreds of items on spreadsheets to go down line by line, all day long.


They also thought the 3 hours we spent doing the same work took too long! Go figure.

I had to come up with a respectful way to tell them that this is a bad idea.

“You know, the way you think about backlogs, a big hunk of data to be created and managed, is not actually the way they work. The wonderful skills you have as a programmer or analyst are actually not applicable here. The goal here is not to work with the data, it’s to work with what is between your ears. Your brain. We are optimizing the transfer of information using humans, not computers. That means that there’s a whole new set of rules to deal with.”

I don’t think they got it, but most of the other teams knew what was going on and had my back. So it worked out.

But there is a teachable moment here. As technologists we are used to moving data around on machines. This is a completely different universe from optimizing the behavior of people to understand and attack a problem. People are not computers.

There are a lot of little consequences from this. For instance, people can only compare so many items at a time, so we usually limit comparisons to 2 or 3 items. People can only remember so many items in a meeting, so we limit our lists to 20 or 30 items. People read more by body language than by words, so we put them physically together while planning. People are more likely to make good tough decisions early in the day, before they reach “decision fatigue”, so we front-load the work. And so on.

Some of this stuff, of course, is unproven pscyho-babble. Some is not. What the Agile community has been doing is empirically testing these various theories to see which ones work well and which ones do not. As practitioners we have a big list of “games” and principles the games are built on. We add some in, see how the team reacts, then adapt. That’s why Agile is different from other methodologies. Agile is a marketing term around best practices for iterative and incremental development. That vagueness is its strength, but it can also drive newbies nuts. It is entirely different from the kind of yes-no, off-on boolean logic most of us deal with in our jobs everyday.

Or to paraphrase a famous presidential campaign, it’s the people, stupid.

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Trusting the System

I remember when I first learned and really grokeed Object-Oriented Analysis and Design. I had read a bunch of books. I had even designed and coded some systems. Some had went well, but some, well, were a bit more complex than they needed to be. See “Architecture Astronaut

Then one day I picked up use cases. Not the god-awful templated 30-page nightmare that most companies make out of use-cases; the real deal. trigger-actor-goal-context process analysis. The kind you can do on a napkin. Maybe sketch something on the back of it if you’re having problems. Specifically, how process analysis fits into Object-Oriented Analysis. Process analysis tells you what needs to happen. OOA tells you what are the logical pieces to make it happen. Semi-structured, all from plain English.

I realized at that point that both OOA and process analysis helped me do one very important thing: I no longer had to keep the entire problem in my head at one time. I had a system that I could use to pick up any problem and drive it towards some kind of resolution. It might be an ugly resolution, but I could get there. I didn’t have to be a genius to solve tough business problems. I just had to follow the system.

I had a similar experience with Agile. As a young PM, I had a desire to plan out everything my team was doing. After all, the more I planned, the less risk there was, right? How could you do anything truly complex and important without having a detailed plan of how you were going to attack it?

At the time, I hated making developers suffer, so I held back. I would secretly plan a bit out ahead in order to make myself feel better, but unless we needed it, I let the team do their work. This wasn’t out of any feelings of comfort. Heck, I spent most of my time as a PM worried about the 17 thousand ways things could go wrong. It was the mid 90s, and we were charging tons of money to solve complex problems. Lots could go wrong.

But what I found out over time, as I adopted more and more “Agile” practices without even knowing it (“Agile” didn’t exist at the time), was that all of my planning was really just a Stupid Human Trick. I felt that by treating people like computers, by programming out everything that was going to happen, that somehow I was reducing risk. But what really happened was that people would always find the problems I missed, and if I left them alone, would go fix them. Turns out people were pretty good at identifying and structuring their own work as they went along. Much better than I was by myself, doing it for them.

Eventually I learned there was a system. There was a minimum amount of structure that I could (had) to provide for teams to succeed. As long as I did that, they would always rock and roll. My job as a PM (and later SM) was to get obstacles out of the way, provided the most minimum amount of structure necessary, and watch the magic happen.

I didn’t have to be a genius to solve tough technology development problems. I just had to follow the system.

As a coach, when I explain these and other concepts like them to folks, many times I get the “crazy uncle” smile. Yes, Daniel, they say, of course it’s all that. (Meanwhile wondering how much I am billing and how did we get stuck with this nice, but misguided guy who thinks the world works on magic)

I think it’s one of those things you have to see to believe. Once you tackle a super-complex business problem using simple tools, you realize you can do this over and over again. Just trust the system. Once you see a team solve a ton of development problems while delivering a product the customer wants, you realize you can do this over and over again. Just trust the system.

Yes, we take this too far. Sometimes people don’t really understand that there is a balance between structure and chaos. Sometimes they want to say silly things like “It’s emergent” to describe conversations and processes they don’t understand. When you see the magician do a few tricks, you might start thinking he can do anything. He cannot.

But most people have the opposite problem. They come from school, where you had to understand the complete problem and solution to get a grade. They want to do well where they are, so they want to be able to describe just how each piece of the process works to create a solution. It is completely counter-intuitive to think that by doing simple things in a system, you can achieve enormously complex goals. But for many of the really cool things in life, that’s how it works.

Trust the system.

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.