It’s All About Flow

February 14, 2019

OK, please forgive me, but I’m going to geek out for bit here on some Thermodynamics of Emotion stuff. Furthermore, I’m going to try and draw an analogy between a law of thermodynamics and the business world. So, hold on to your hats, here we go… 

In the Design of Nature, Bejan states the Constructal Law as:

“For a finite-size flow system to persist in time (to live), its configuration must evolve in such a way that it provides easier access to the currents that flow through it.”

-Bejan, Adrian. Design in Nature

This is to say that for any living system there is a design or landscape that must change over time such that the flow through the system improves. The design can be anything as primitive as the branching of streams, the vascularity of the arteries and veins in your body, or perhaps the process that you use to do work at the office.

In business, process is the design that we use to structure the way work flows through our organizations. As such, the process is not arbitrary, but intentional. If it improves the flow of work, then it’s a useful process, if it degrades the flow of work, then it’s not. By improving the flow of work, we mean that it must configure the landscape or domain such that the work flows more easily (read with less resistance) through the system. That also implies that the access to that work is improved (it takes less energy to find it).

According to Constructal Law, processes that allow work to remain hidden interfere with flow. Processes that constrain work so that it’s flow can’t change or evolve also interfere with flow. Given these assumptions, old-school, plan-driven methods with rigidly defined processes are counter to healthy flow and are less likely to succeed than processes that are dynamic and enable transparency of work in the organization.

In fact, to carry this one step further. What we are currently witnessing in the last two to three decades is the evolution of processes in the business world. Rigid, plan driven processes are dying off, as the Constructal Law would predict, in the face of new dynamic processes like agile. Any process, even somewhat imperfect, that improves flow and transparency of work in the system is going to be more successful (more efficient conversion of energy to work) than a more rigid process. 

Of course, agile too will one day be replaced by a process that successfully enables better flow. What that next process is remains to be seen.


Building a Scaled Agile Framework for Dummies

February 10, 2019

Scaled Agile Frameworks like SAFe are all the rage these days. You can go out now and get training, certification and a shave from a bevy of consultants that for a mere two grand per head (not really sure about the shave part). That’s a perfectly legitimate approach. However here’s a dirty little secret: anyone can do it. Here’s an example of one that I made a few years ago.

I had taken a look at SAFe and there was a lot that I liked and there were some things that just didn’t seem to fit our context. With those qualifications in mind. I decided I could make my own version. I got out my notepad and my colored sharpies and I went to town. I knew that I liked the three layer model, but I found a lot of the SAFe Big Picture had too much complexity in it. So you can see that in the first level, I simplified things quite considerably. The second or program level was also quite simple. I mixed in some things like agile chartering which I felt would be beneficial and were not found in the SAFe diagram. What about the third (Portfolio) level? Well, at the time I really didn’t have a clear idea how that would look. It was at this level that I was looking to integrate the model with our existing PMO practices – which in hindsight was probably a mistake (hey, make your own model and you make your own mistakes). So then I started to iterate.

Now I was starting to think about how things related between the three layers. Those interactions between the team level, the program level, and the portfolio level seemed to be very important. I was also experimenting with different ways of visualizing the processes on each level (with what I must confess are varying degrees of success). My color repertoire had expanded too.

Finally I started to look at the processes as a series of prescriptive steps that I needed to be able to document and describe to people. You can see that I added numbers and then I took each of those interlocking blocks and documented them. I made poster sized copies and put them on the wall outside my office with a sharpie hanging next to them. The request was simple – please change it to fit your needs. After a few days, I had more feedback and iterated from there.

Building your own scaling model isn’t for everyone. However, it’s not rocket science either. If you have a modest understanding of your own business domain, AND you understand the basics of the agile frameworks, you have everything necessary to build your own scaling framework. I’m sure there will be folks who are appalled by the arrogance of doing something like this, but personally, I think we all should feel free to make our own Big Picture. When we can customize our processes in ways that work best for us, I think we win. We learn along the way and we don’t inherit a bunch of cruft from someone else’s framework.


Team Genetics

September 28, 2014

dna-163710_640

Today I was listing to “The Splendid Table”, a great cooking show on NPR. They were talking about variation in growing heirloom tomatoes. Somehow, that got me thinking about agile teams (probably time to see the therapist again). It occurred to me that ideas like Agile are memes.

Richard Dawkins defined a meme as “an idea, behavior, or style that spreads from person to person within a culture.” and Agile certainly fits that definition. Agile has spread from obscurity to worldwide acceptance within 20 years. In another 20 years I fully expect that waterfall, plan driven methods will be nothing but a footnote in the history books. Despite some early prognostications to the contrary, Agile has grown at a very healthy rate over the last several years.

“Richard Dawkins invented the term ‘memes’ to stand for items that are reproduced by imitation rather than reproduced genetically.”

While much of the credit belongs to the teams that actually do the hard work of making a new process work, there is also the business that has arisen around evangelizing and introducing Agile to companies that deserves a great deal of the credit. Agile training and consulting has done a remarkable job of spreading the meme throughout the software development world.

I think there are characteristics of Agile training that have made Agile “sticky” as a meme. Much of the Scrum certification is based on plenty of hands-on exercises. Training and certification has yielded a decent business. I’m not sure if anyone has the numbers, but I’d be surprised if it wasn’t a multi-million dollar enterprise worldwide. Strangely enough, much of that spreading has been through imitation. There is no shared agenda for the training, much of it is simply imitated from trainer to trainer.

When trainers and others spread the meme they are like Johnny Appleseed sowing Agile ideas across fertile corporate soil.

Genes change with each generation, and so do ideas. They go through a mixing and blending each time they are shared. Parts of the idea are forgotten, other new ideas are grafted on. Soon the original idea is unrecognizable. I think that’s kind of what has happened with XP. Extreme Programming originally contained a collection of ideas that were very potent. Things like pair programming, continuous integration and others all served as core ideas within XP. Over time, those ideas have been co-opted and found their main expression in Scrum. Today, almost no one trains teams in XP, Scrum is the dominant process that is trained and introduced to teams.

“Memes do this through the processes of variation, mutation, competition, and inheritance, each of which influence a meme’s reproductive success.”

So too does Agile. In recent years methods like Kanban and ideas like No Estimates have arisen and are becoming a meaningful part of the software development landscape. These are evolutions of the Agile meme. Agile is evolving, I wonder where it will go next…


Killing 7 Impediments in One Blow

September 18, 2014

Have you heard the story of the Brave Little Tailor? Here’s a refresher:

So one day this little guy kills 7 flies with one mighty blow. He crafts for himself a belt with “7 in One Blow” sewn into it. He then proceeds through various feats of cleverness to intimidate or subdue giants, soldiers, kings and princesses. Each one, in their own ignorance, misinterpreting what “7 in One Blow” actually refers to. It’s a classic for a number of reasons:

  1. It’s a story about mis-communication: Not one single adversary has the wit to ask just what he means by killing “7 in one blow”
  2. It’s also a story about using one’s cleverness to achieve great things. You have to love the ingenuity of the little guy as he makes his way adroitly past each obstacle.
  3. It’s a story about blowing things way out of proportion. Each of the tailor’s adversaries manages to magnify the capabilities of the tailor to extraordinary, even supernatural levels.

I’m thinking I might have to get a belt like that and wear it around the office. A nice pair of kahkis, a button down shirt, and a big belt with the words, “7 in One Blow”. Given how prone we all tend to be to each of the foibles above, I’m sure it would be a riot.
A QA guy might see my belt and say, “Wow! He killed 7 bugs in one blow!”
Maybe a project manager might see it and think, “This guy is so good he finished 7 projects all at once!” Or maybe the HR rep says, “Did he really fire 7 people in one day?” Or the Scrum Master who thinks, “That’s a lot of impediments to clear out at once!”
The point is that we make up these stories all the time. We have stories in our heads about our team mates, “Did you hear about Joe?” our managers, and their managers. Sometimes it seems as though we all have these distorted visions of each other. And perhaps we do. We need to get better at questioning those stories. We need to cultivate more of a sense of curiosity about the incomplete knowledge that we have of each other. That belt would be my reminder. I might have to buy one for each member of my team.
Of course the other thing that the belt can remind us of, is to use our own innate cleverness to help get what we need. When we are wrestling with the corporate challenges, we all too often tend to try and brute force our problems and obstacles. We need to be a bit more like the Little Tailor and manipulate the world around us with some cleverness. We all have it to one degree or another, and Lord knows we need all the cleverness we can get. Good work is full of challenges and you don’t want to take them all head on or you will end up like an NFL linebacker – brain damaged. Instead, we need to approach some things with subtlety. There is just as much value in not being in the path of a problem as there is in tackling things head on. Like the Tailor, we need to recruit others to achieve our objectives.
Finally, we really must stop blowing things out of proportion. Nobody cares about our methodology. You want to know what my favorite kind of pairing is? Lunch! We need to lighten up a bit. Working your way through the dark corporate forest, you can either play with what ever it brings and gracefully dodge the risks, or…you can get stepped on.


Starting Backwards

September 13, 2014

dangerous-fast-force-2438-466x350

If you were to draw a diagram of the entire product development process from start to finish, what would you start with? If you are like me, you’d probably start with the customer, or maybe sales. Then you’d probably pass the idea along to product management and onward to development. Last, but not least, the product would make its way to operations for deployment in production.

It’s pretty straightforward, front to back, end-to-end. Everybody knows how it works. And if we are going to try to improve this process, where do you think we typically start?

At the front? In sales? No.

At the back? With operations? No. Not there either.

Right smack dab in the middle? BINGO! Development always gets the love first.

Now what kind of lunacy is that? Now I’ve been part of a process improvement effort or two, so naturally I start to think I see patterns. Well, hallucinations of some kind anyway. Almost every time we start with the development teams. We do a good job, we get them up and sprinting, train a few scrum masters, console a few managers, and Bob’s your uncle: the dev teams are agile! Then what happens?

Downstream, the operations teams aren’t on board with the whole agile thing. They aren’t going to let you change their release processes just to satisfy some fad. Rapid change? Are you nuts? And what about the other end of the value stream, sales? They’re willing enough if it makes them money, but you’d better deliver (which isn’t happening with the operations guys, so you are screwed).

So lets take a step back and look at the value stream. Where do we typically see the most time spent? It’s not development – we’ve been squeezing development in one way or another for decades. However, you can find the most amazing queues in sales. With the rest of the organization moving so slowly, they naturally develop queues as they wait for the work to get done.

The question is, why don’t we start at the back? Why don’t we make the end of the value stream our focus first? We need to stop starting in the middle. Goldratt would have us chasing the bottlenecks. More power to him. If I speed up operations first, I may not see an immediate increase in productivity, but I have created the runway for success. I have them on board and bought in. Now, we move up the value stream to the Development teams. If we can get them performing, then we have already prepared the runway for them. No longer do we give them a fast car and ask them to drive it into the wall. Now they can deliver and they can do it with proper support from operations.

From there we can continue to move up to Sales and the front end of the value stream. They should be an easy sell at this point. So, the question is, why start in the middle?


Can a Project Be Beautiful?

September 7, 2014

What would make a project beautiful? What sort of aesthetic would we seek? Would would make a beautiful plan? What would make a beautiful backlog? What would make a beautiful team? What would make a beautiful delivery?

I imagine it might be different for everyone…

The Plan

For me, a beautiful plan would be something that covers a wall of a team or war room. It would have requirements, wireframes, architectures, acceptance criteria, impediments.

mess

 

 

 

 

 

It would tell a graphic story of the evolution of the project over time. It would be a graphic history in multiple dimensions, worthy of Edward Tufte. But it would not be perfect. It would reflect rough edges, rapid sketching, mistakes, blind alleys, rough annotations everywhere.

istock_000019366898small

 

 

 

 

 

 

 

 

It would also reflect the growth and improvement of the team. Items from retrospectives would be incorporated into the timeline. There would be different ways that the team measured their own performance. It would be a glorious mess!

OLYMPUS DIGITAL CAMERA

 

 

 

 

 

 

 

The Backlog

A beautiful backlog would be on it’s own wall. It would reflect dialog with the customer, questions from the team, user profiles and scenarios.

tumblr_ly5c4tDfnr1qfg8uu

 

 

 

 

 

 

 

 

 

It would be shaped like an inverted pyramid, with rich detail at the top, tapering down to sparse sets of one line ideas and proposals below. It would have color (LOTS of color) and use different shapes to indicate stories, epics, features, etc.

writing-on-wall

 

 

 

 

 

 

 

The Team

A beautiful team is tight. The team works physically closely together, eliminating all barriers, focusing on collaborative activity over solo activity. They work together, they eat together, they respect each other. They share roles and responsibilities promiscuously.

teamroom

 

 

 

 

 

 

 

 

 

They pair, they mob, they swarm!

8666.pp-Team-Room_4C3230AF

 

 

 

 

 

 

 

 

 

 The Delivery

A beautiful delivery is smooth and effortless: friction free. It happens on demand – with the ease of a thought. Work flows through to production almost inevitably. It’s a downhill slide, not a grind uphill.

Free-Mattress-Delivery-Farmington-Hills

 

 

 

 

 

 

 

 

 

 

 

What does a beautiful project look like to you?


Is Improvement really Continuous?

September 4, 2014

DT-09-final-infinity

 

 

 

 

 

 

I don’t want to get on a rant here, but…In the Agile community and perhaps in the IT community in general there is a tendency to use the term “Continuous Improvement” to describe some sort of mythical state where teams are constantly evolving toward some state of perfection. At least that’s what I think of when I hear the term. Now I don’t know about you, but I don’t think I’ve ever seen such a creature in the wild (or even anything close to it). Furthermore, I’m concerned that using such terminology sets an unrealistic expectation for performance with our customers and stakeholders.

As an example, I’ll use myself. Right now, despite a host of good intentions on my part, I am not continuously improving. I’m typing – my spelling and grammar are showing no discernible sign of improvement (as I’m quite sure you, dear reader, are all too painfully aware of). Honestly, I’m just not improving right now. In fact, I haven’t done anything to improve my blog writing since the last time I wrote one a week ago…a month ago…6 months ago…

“But Tom don’t be so hard on yourself!” You say, “Just by writing more you are improving your writing skill and the content of the blog.” To this my answer would be, “So just writing more code is improving too?” We all know the answer to that question. So no, the only thing writing does by itself, is make the number of words on the page grow.

In fact, I have a confession to make. Nothing I plan to do in the next 24 hours has anything with improvement. Not even:

  • Attending meetings (generally the opposite of improvement)
  • Writing status reports (ditto)
  • Cleaning the house (status quo – just fighting entropy is not improvement)
  • Commuting (status quo)
  • Watching TV (gently sliding toward entropic oblivion)
  • Sleeping (mandatory, but not improvement, at best it’s re-establishing the status quo)

You see, true improvement is really hard work, therefore I don’t do it very often. I certainly have never been able to do it “continuously”. Hah! What a ridiculous notion that is! Nobody can improve continuously. We all need to take a break. Taking a break is actually necessary in order to improve! So the very term “continuous improvement” is at best misleading and at worst an idiotic notion. It can’t be done! Combining the terms continuous and improvement is like the old joke about the term military intelligence – it just doesn’t exist!

Up to this point I’ve just been ranting about continuous improvement, but in the Agile community we use the “continuous” word everywhere. There’s continuous integration, continuous delivery, and I’m sure there are a few more I haven’t even thought of. Take any one of those continuous activities and look at it closely enough, and guess what? Not much is happening. I’m willing to bet that your continuous integration server isn’t constantly running builds all the time (at least I hope not). I’m sure the average integration server spends a lot of time just waiting for the next build request. I hope by now it is pretty apparent that very few things are really continuous. I think we need a better term to describe these processes. I would propose: Periodic, Frequent, Event-driven or my personal favorite – on demand.

I know, I really do get it – continuous sounds just better. Continuous has an aspirational sort of quality to it which you can’t help but admire. I think that it’s just a little disingenuous to use that term for things that may not even take place for an hour or even a day at a time. If improvement is really continuous in nature, I want to see evidence of improvement taking place as I’m watching, when my back is turned, on weekends, and perhaps even when visiting the bathroom. Is that too high a bar to set? I don’t think so. I make that demand of my lowly alarm clock. I’m not saying improvement doesn’t take place. It happens – for some of us it happens pretty frequently. For others, it happens on demand at the end of the sprint.

Improvement may be a never-ending quest, but it is rarely, if ever, continuous.