Tom and Geri Scrum

Modern Control Systems – The Secret to Understanding Agile
We make a simple promise to you, read and understand this overview of modern control theory and you will understand how agile software development works, in a profound way. You will understand it better than many people who lecture on Agile techniques at conferences.

Open Loop Systems
We begin with a simple description of open loop systems. An open loop system is a modern control system without feedback. “What is that?” you ask. Fortunately, it is easy to understand, it is as easy as making toast.

A modern control systems can be described in three simple parts:

 Part 1: Desired Output

You begin  with an idea of a specific output you desire to create. If you are creating a piece of toast then you being with an image of what a perfect piece of toast may look like to you.

Having the idea of the desired output is the first part in modern control theory. You need some idea of what you want so you can discover a way to create it. That leads us to:

Part 2: Process

After you have a desired output you create a process to give you that desired output. If we want to make a process to give us the perfect piece of toast it will likely contain the following steps:

1. Acquire bread, remove from package.
2. Put bread into toaster.
3. Set desired darkness.
4. Press down control lever lowering toast into toaster and engaging heating elements.
5. Wait until toast pops up.
6. Remove toast.

You implement this process to create your desired output, having the desired output in mind helped us describe this process.

[Desired Output] →[Process]

Simple, even a child can do it. In fact, making toast is one of those childhood delights.

That leads us to:

Part 3: Desired Output 

At the end of the toasting cycle we removed the perfect piece of toast and enjoy. Our entire process looks like the following:

[Desired Output] →[Process]→[Actual Output]

In modern control systems we call this an “Open Loop” control. It is perhaps better described as a “No Loop” control. No loops because there is no feedback in this system. You set the controls, wait, and whatever you get is whatever you get. Hopefully, the actual output is close to the desired output and you have the perfect piece of toast.

Burnt Toast

Sometimes, however, the actual output looks more like this:

What happens if you accidentally create a piece of toast that looks like this?

Well, you can try to do additional processing and scrape the burnt part off in the sink. But that doesn’t create a very compelling piece of toast. The typical solution is to toss the toast into the trash and start the whole process all over again, setting the darkness knob on the toaster to a slightly lighter level.

The process we outlined for making toast contains no feedback (no loops). Step 1, led to step 2, led to step 3,… and so on.

1. Acquire bread, remove from package
2. Put bread into toaster
3. Set desired darkness control
4. Press down control lever lowering toast into toaster and engaging heating elements
5. Wait until toast pops up
6. Remove toast

Closes Loop Systems

Nowhere in the previous system do we use information while the toast is toasting to understand how well our process is working. What might it look like if we try to gather information while our toast is toasting?

“Why do I care?”  Andy asked, interrupting about 45 seconds into my Toast presentation.

“What?”

“Why do I care?” Andy asked again. “You haven’t told me why I should care enough to listen to this presentation.”

Andy is one of our Agile coaches.A maverick entrepreneur who has made, lost, and made again several small fortunes. He is used to being boss, and is usually about as tactful as a she bear whose cubs are being tortured.

Still, he was right. I hadn’t stated why someone should care. I hadn’t provided a hook, a reason to listen, a promise of an interesting story or a guarantee of a result. I hadn’t given my students a reason to actually listen closely, and for this presentation I really needed them to listen.

I added a new slide at the beginning of the Toast deck.  A picture of a giant set of keys.

The slide appears and I say, “In the next 20 minutes I’ll explain why and how agile works so clearly that you will understand it better than most people who speak at agile conferences. Listen for 20 minutes, and you will understand exactly how agile works and exactly how it differs from agile–guaranteed.”

A powerful promise. But we deliver. An nobody has ever tried to collect the guarantee, which is good, since I can’t really give them their 20 minutes back.

Still, I tell people clearly why they should care.

Today, we showed Andy a poster.

“Why do I care?” Andy said, reading the poster.

Sigh.

Dang-it, I had no idea.

When are you ever going to get this right?” He asked.

An alternative loopian dicationary.

loop: A completed feedback cycle.
loops: Plural of Loop. The name of the process.
looped: Past tense of Loop. The process of having feedback provided to you.

loopm : Someone providing manual feedback loops (loop em).
loopa: An automated process/daemon providing automated feedback (loop uhh).

Prefixes:

• s- loops that operate on a second by second basis.
• m- loops that operate on a minute by minute basis
• h- loops that operate on an hour by hour basis
• d- loops that operate on a day by day basis

Putting these definitions together we could get:

s-loopm:  Someone providing feedback on a second by second basis, usually through pairing.

s-loopa: Something providing feedback on a second by second basis.

Here, rewritten, are the loops listed in a previous post:

1. As a loopm,I want my design ideas sloopm so I do not get stuck and waste time.
2. As a loopm, I want my variable names sloopm for clarity so the code is easier to maintain the very first time it is checked in.
3. As a loopm, I want my class/function names sloopm for clarity so the code is easier to maintain the very first time it is checked in.
4. As a loopm, I want my each line of code sloopm for clarity so the code is easier to maintain the very first time it is checked in.
5. As a loopm, I want each line of code sloopm for logic errors to reduce errors in the code the very first time it is checked in.

Writing a few more loops this way:

1. As a loopm, I want my token of code sloopa as I  type for syntax errors so no syntax errors are introduced as I type.
2. As a loopm, I want each function of code I am editing sloopa as I type for unit correctness so I do not have to wait to run all the unit tests to see that this code is accurate. **
3. As a loopm, I want all units dependent on the code I am editing mloopa for unit correctness so I know if I am breaking code in dependent systems before I check the code into production.

There are hundreds and hundreds of control loops to document in agile if we really want to understand how agile works. I thought  I would re-document my feedback loops posted previously in a more loopian vocabulary. This will either be interesting, or incomprehensible, or perhaps both.

Loop: A completed feedback cycle.
Loops: Plural of Loop. The name of the process.
Looped: Past tense of Loop. The process of having feedback provided to you.
S-Looped: A loop where the feedback may be provided on a second by second basis.
M-Looped: A loop where the feedback may be provided on a minute by minute basis.
H-Looped: A loop where the feedback may be provided on a hour by hour basis.
D-Looped: A loop where the feedback may be provided on a day by day basis.
Loopy: Someone working in Loops.
Aloopy: An automated process/daemon running in Loops to provide automated feedback.

Putting these definitions together we could get:

loopy s-looped:  Someone providing feedback on a second by second basis, usually through pairing.

aloopy s-looped: Something providing feedback on a second by second basis.

Here, rewritten, are the loops listed in a previous post:

1. As a loopy, I want my design ideas loopy s-looped so I do not get stuck and waste time.
2. As a loopy, I want my variable names loopy s-looped for clarity so the code is easier to maintain the very first time it is checked in.
3. As a loopy, I want my class/function names loopy s-looped for clarity so the code is easier to maintain the very first time it is checked in.
4. As a loopy, I want my each line of code loopy s-looped for clarity so the code is easier to maintain the very first time it is checked in.
5. As a loopy, I want each line of code loopy s-looped for logic errors to reduce errors in the code the very first time it is checked in.

Writing a few more loops this way:

1. As a loopy, I want my token of code aloopy s-looped as I  type for syntax errors so no syntax errors are introduced as I type.
2. As a loopy, I want each function of code I am editing aloopy s-looped as I type for unit correctness so I do not have to wait to run all the unit tests to see that this code is accurate. **
3. As a loopy, I want all units dependent on the code I am editing aloopy m-looped for unit correctness so I know if I am breaking code in dependent systems before I check the code into production.

-Tom

Geri and I pair for every important task we do for our clients. Not necessarily sitting at the same keyboard, but jointly producing all major deliverables as a collaborative effort.

I will toot our own horn here for a moment because, quite simply, I find the results stunning and I think you should take note.

When we collaborate on a project, be it creating a presentation, a coaching plan, or an entire Scrum curriculum, I believe the end result is not simply twice as good when we pair, I believe it is ten times better.

It is so much better it is scary.

I believe our clients get ten times the value when we collaborate. And, if you can find a partner who complements you well, then you can find that type of productivity improvement too.

Two is, quite simply, way better than one.

Pairing more than doubles our productivity, it puts it in turbo mode. Pairing more than doubles our quality, it takes our deliverables to an entirely new plane of existence.

I have observed this effect for more than a decade. If you want higher quality, better productivity, and faster results, then pair your staff. Not just your programmers, pair everybody! Or at least everybody doing knowledge work.

The results will blow you away.

Guaranteed.

People have been asking about Feedback Loops for the new “Toast” methodology, or should it be the “Loops” methodology. Here are some more Feedback Loops that happen on the second by second basis if you pair program:

1. As a Loops Team Member I want to have my code reviewed by my partner on a second by second basis so I greatly reduce the errors I check in.

2. As a Loops Team Member I want to have my partner watch me type in code on a second by second basis so that he or she helps me move faster when I get stuck finding a solution.

3. As a Loops Team Member I want to have my partner tell me if they cannot understand the purpose of the variable I just named so that I can write variable names that are more clear and easier to maintain.

4. As a Loops Team Member I want to have my partner tell me if they cannot understand the purpose of the class I just named so that I can write class names that are more clear and easier to maintain.

5. As a Loops Team Member I want to have my partner tell me if they cannot understand the purpose of the line of code I just wrote so that I can write lines of code that are more clear and easier to maintain.

There is a reason why there are hundreds and hundreds of feedback loops in agile development, and why pair programming is so productive. Now I have to figure out how to document these on a table in this site.

-Tom

“If they don’t have an amazing Taco for less than two dollars,” Kyle exclaimed enthusiastically,  “It is not an authentic Taqueria.”

We’re continuing a tradition we started five years ago at Blue Cross. Every Wednesday evening any contractors who want to attend are invited to a group dinner. In theory, Greg is supposed to be brewing beer at this dinner too, but for some reason we remain dry. Geri & I started the tradition again in March, just the two of us at first. Now we are joined by Greg, Mike, Andy, Raje, Kyle & Dee and their very cute family. This week Kyle chose the restaurant.

“If you are in Southwest Texas,” Kyle continued, “there are really only two types of high-quality food you should expect to find, Mexican and Barbecue, and the best Mexican is frequently found in the humble Taqueria.”

“This is the best Mexican I could find within a reasonable distance of work.” he added. “There are better tacos I have found in San Antonio, but you have to eat them out of a truck.”

Kyle never sleeps. Instead he spends nights crawling the web reading obscure blogs and searching for well-reviewed, highly-quality, low-profile dining experiences. His favorite way to order, I have come to appreciate, is to ask his server to bring him what he or she likes most.

“Mind you,” Kyle instructed us all, “I don’t think anyone here actually speaks English.” He pauses to ensure we all heard him, “So I suggest you just point to something that looks good on the menu, nod, and smile.”

I find something called #17, point at it, nod, smile, and say “Gratzi.”  I think I just ordered, and in the process, accidentally spoke Italian.

I am sitting across from Geri, away from the office and stress, so what do I do? I pull a notebook with feedback loops in it and immediate start talking shop. Geri and I almost always talk shop: agile, Scrum, marketing, design, architecture, business analysis, grammars, or whatever. It is almost impossible to stop. Wednesday evenings with the coaches is usually about 50% shop talk.

“Look at these,” I exclaim, passing the notebook to Geri. “I’ve itemized 3 feedback loops around why people should stand up in stand up meetings. I’ve listed over 50 more other loops. I think this may be a really good way to talk about Agile.”

Geri looked down at the cryptic notes I had written on the page and said “I have no idea what these notes mean.”

Kyle peered over Geri’s sholder. “Why don’t you write them as stories?” he suggested. “We teach everyone to write stories, so write the loops as stories.”

I peer at him over the top of my reading glasses. My immediate desire is to say “Just read the damn loops as I wrote them.” However, an inner bunny (more about bunnies later) keeps me quite. I grab the notebook back and start writing.

As a Scrum Team Member I want to stand when the Scrum is about to begin to make it clear to other team members I am waiting, so they realize I am waiting and quickly stand and join the meeting in order to not waste my time.

I look at it, read it a few times. Not bad for a first draft and a lot clearer than the loop I had scrawled earlier. I write another:

As a Scrum Team we want to stand during the Scrum so it is clear to anyone walking near us we are doing a formal ceremony and they should not interrupt us and decrease the effectiveness of our meeting.

I pass the notebook over to Kyle, “Better” he says, matter-of-factly. He smiles, not rubbing it in too badly that he was clearly right again, and he passes it over to Geri.

“I can understand this,” Geri says delightfully. She passes it on to the other coaches telling them about the idea of writing loops as user stories.

I realize I have totally forgotten what I ordered, again. But it is Mexican, so I figure it doesn’t really matter.

“I brought back my husband’s book on Modern Control Loops,” Geri said with a smile, dropping it on her kitchen table. “It is electrical engineering, but I thought the first chapter might be useful.”

Geri was back from another trip home, a mere 1,000 miles away. I always like it when she comes back and brings me presents. Renee (my wife) and I were over for some of Geri’s famous soup and sourdough bread, made with starter that had traveled half-way round the world.

“Look at this,” she added, flipping open the book. “It does a great introduction to control theory using simple examples like water towers, toasters, and toilets. We just need the first chapter, but Jason wouldn’t let me rip it out.”

“Toilets?” I said, suddenly finding the topic more interesting, as I consider the idea of displaying a slide with just a picture of a giant toilet on it something that, quite simply, I must someday do.

“Say away from the toilet metaphors Tom,” Geri quickly added.

“O.K.,” I mumbled, “but then it has to be toast.”  I actually consider toast to be a food group.

“Toast,” she replied. “Right here on page 7.”

I picked it up and started reading. I loved it. Feedback theory explained with toasters, toilets, and water towers. This could be really useful.

Kyle had recently dropped a feedback loop presentation on my desk. It contained his idea of feedback loops as the core agile value, and showed feedback loops nested inside of other feedback loops, nested inside of other feedback loops. I was trying to make it into a presentation for some executives, but it didn’t connect to me emotionally. I wasn’t moved. Or, how I usually describe work product I do not like, it was crap.

But toast. Toast has legs. The word is fun to say. Makes you smile, and we can all relate to making and burning toast.

“Here is the soup,” Geri interruped my ponderings, “one with cream and one without.” Cream, what is it with the fascination with cream by the agile coaches? Kyle was now even drinking cream for lunch, or rather as lunch. “I’ll have without please.”

Renee had hers with cream.

“Toast,” I proclaimed to Geri, spreading butter on the still warm bread, “could be used as an example of both an open and closed loop feedback system.”

“I know,” Geri added, “and people might actually get it if we talk about making toast.”

“What are you talking about?” Renee asked, as if to test the point.

“Open loops,” Geri explained, “is when you put the bread in the toaster, set the darkness, push the lever down and walk away, hoping for the best. It is an open loop because there is no Feedback.”

“Open loop toasting is careful planning, if the controls are carefully set you get a great piece of toast,” I added.

“One small mistake, however,” Geri continued, “and you are setting off smoke alarms.”

“Closed loop toasting,” I added, “is more interesting to us agile folks. Closed loop toasting is when you peer into the top of the toaster watching it toast because you just burned the last two pieces of bread. Put the bread in and watch it very closely, using observations to adjust the controls and pop out the perfect piece of toast. Closed loop toasting is toasting using feedback.”

“They pay you for this work?” Renee, asked incredulously. “To tell them how to make toast?”

“Indeed.” I replied, “In fact,  I think I’ll start on a new presentation tomorrow. Mark my words, in a few days I will have everyone talking about Toast.”

I, of course, wasn’t quite so sure it would work. But in marketing and sales, always lead with confidence. As I watched Renee and Geri eat their cream soup I wondered, ‘Would this connect to people? Talking about toast? and What is the deal with cream?’

I built the concepts a slide at a time over several days. Open loop toasting was waterfall. Plan carefully, set the levers, put the toast in, and hope for the best. Closed loop toasting was Agile. Use feedback to make great toast.

“What are you doing?” Geri asked, four days later watching me still working on just one of eight presentations we had to deliver within a month.

“I’m trying to make this toaster slide build better,” I replied.

“You do know we have a major presentation soon to a whole team of executives? You can’t spend all your time tuning just one presentation.”

“Ahh,” I replied, “but this is the presentation. The one presentation we do before every other presentation. The one presentation to rule them all and in the feedback bind them.”

She rolled her eyes.

“Besides,” I added, “you’re working on the other seven.”

Truth was, it was impossible to stop toasting. Kyle had already given the toast presentation about a dozen times in various forms and was on a roll, presenting it to anyone he could corner. “Have you seen toast yet?” he would say to anyone walking too close to his desk.

It was a challenge. Could I change a slide on the presentation before he gave it again,  preferably between the time he last looked at the presentation and when he next gave it.

There are only three people I’ve ever worked with where I could ever do this type of curriculum development (most people won’t tolerate it). James at Menlo Innovations was the first, Geri the second, and now Kyle… and I had Geri and Kyle together in one place. This was too good of an opportunity to miss.

I would change a slide, Kyle or Geri would have to talk to it on the fly, and later they would tell me how it worked. I should point out, these slides did not have a lot of text. In fact, many of  the slides were simply a single picture, such as one whole slide that contained only the Wright brother’s first airplane, and another a picture of a toaster and a piece of burnt toast. You had to think fast on your feet to give the toast presentation.

Last time I checked it Toast was on revision 12, but to be honest, I didn’t make revision changes the first few weeks it was developed, so it is probably really version 25. It has settled down lately, only changing once or twice a week.

Toast works.

People get it. And I believe people who see it only once just might understand agile philosophically better than people who have actually been doing agile for years. Feedback is that fundamental.

It is now the first presentation we give to everyone on agile, regardless of what we are teaching. It grounds people. It is impossible to see this presentation and not understand in a profound way how agile is different from waterfall.

Do you want to learn to be agile? It all begins with a perfect slice of toast.

A lot of companies like to measure productivity.  What these measurements come down to is how much can we produce in an hour or a day or a week? Then they use that number to look for trends, such as “We are getting more productive over time”.

This sounds good. But as a primary indicator, it falls flat. Why does it matter that we produce more with the same people?  It implies that our production costs are going down, but that is not necessarily a good thing. (If your production is up, cost is down, but the product is full of errors, then as a customer I am not happy. If production is up because of a lot of unreported overtime, then as your employee I am not happy.)  It could also imply that we are doing more faster, which is also not necessarily a good thing. (More stuff that no one wants is not good. Getting there faster when the destination is wrong is not good.)

Consider these scenarios:

Leonard Cohen took more than 2 years to write the song “Hallelujah” http://1heckofaguy.com/2010/05/10/bob-dylan-covers-leonard-cohens-hallelujah/, one of the most popular and successful songs of our time.

Bob Dylan (in the same article) claims to have written some of his songs in as little as 15 minutes.

So obviously Bob Dylan is way more productive than Leonard Cohen. Does it matter?

Piers Anthony has published more than 150 books since 1969 (43 years), or about 3.5 books a year. http://www.hipiers.com/bibliography.html

Stephen King has published 69 books since 1974 (38 years) or not quite 2  books a year. http://en.wikipedia.org/wiki/Stephen_King_bibliography

By that measure, Piers Anthony is much more productive than Stephen King. Does it matter?

Productivity only becomes interesting after we have answered far more important questions: Did we get the right product to market at the right time?  And we ask: Was the cost of producing the product worth it compared to the value we as a company received from the sales of that product?

If the answers to those questions are yes, then productivity becomes a more interesting measure. But only after we have asked and answered the more important questions. Once we know we are doing the right thing, then is the time to do it more efficiently, and productivity measures become interesting.

Tom and Geri