Marcato

We spent yesterday afternoon and evening dodging thunderstorms and tornadoes at the TCF Bank Stadium; while normally this would be entertainment enough, the real reason we were there was to watch the Drum Corps International competition.  If you are unfamiliar with this form of competition, check out this trailer:  http://link.brightcove.com/services/player/bcpid62043804001?bctid=95733275001.  A friend of ours competes throughout the summer in the Minnesota Brass – a remarkable assemblage of talented people that actually PAY for the privilege of spending their summer practicing complex routines in often (especially last night) less than ideal conditions.

This was our second competition we had attended, and this time we sprung for better seats – oddly enough, for sport of this nature, the better seats are actually higher up, and I was amazed at the difference.  Closer to the field you can see the details, but as the old saying goes, “you can’t see the forest through the trees”.  From this perspective, individuals are lost but the design and execution of the whole becomes clear.  The flash of a single cymbal move is lost, but the synchrony of the squad becomes clear.  Excellence in execution is required because errors break the pattern and distract the observer, but execution alone does not make you world class.  Instead, it now becomes a competition of choreography and concept where the constantly shifting patterns communicate a story and accomplish a purpose.

There are lots of elements in the performance to appreciate as there is so much going on – the music itself, the color guard with flags and twirling guns, the visual flash of color and  - but my mind kept observing a simple yet compelling part of how each routine is choreographed.  It seems that the architect of the routine knows that what what will have the most impact is to present a relatively small number of big moments where everything resolves into a sharp image for that “wow” moment – sometimes it is as simple as a single straight line slowly moving forward with all instruments holding a note in unison that sends a shiver down your spine, other times it is a design representative of the theme of the performance and part of telling the story.

But most of the time during the performance itself is actually spent moving between these moments, and during these times, individual execution matters even more.  The patterns dissolve into an almost chaotic scramble as different lines shift and merge; each person performs their work to get from here to there but in a way that cooperates with the others in their immediate vicinity.  This motion has a beauty of its own, but for the most part it is a building phase that we know must be tolerated as we set up the next impressive moment.  I’m sure this is intentional, but often during these transitions the performers are all turned away from you and the music is muted.  It’s messy and in some ways unsatisfying, yet usually worth the wait when the image suddenly comes into sharp focus and all the instruments turn towards you to appeal for your applause.

Now I know that I have a tendency to see everything in life as analogous to software, but there is an important parallel between what I saw on the field last night and what we do when we are using Agile to build software.  It’s very easy to get lost in the details of the execution of each sprint, and when you are down there on the field in the team, it takes everything you have just to get from point A to point B.  In fact, there is a REALLY important difference between what we do when we make software and what we see on the field – we don’t get to practice the same transitions over and over again until they approach perfection.  Instead, we get to do them once and to the best of our abilities, and then we move on to the next one.  Given this important difference, it’s nothing short of miraculous when we do have those sprints where everything comes together well and we have a great sprint review.  This is also why I think it is important to tolerate with grace those times when it doesn’t quite work.  As a coach, what I look for is an honest intent within the team to do better in the future and a honest and healthy spirit of learning from your mistakes.

One final note – in the end, great execution and choreography combine to please the audience, and this is the reason I see so many passionate converts to Agile on the business side.  Once they have experienced this level of involvement in the process and they see the product emerge as a progression of steps that are themselves pleasing to witness, they never want to do it any other way.  In that sense, perhaps with Agile we nerds and geeks have finally found a way to accomplish what we always wanted – to turn what we do into a form of performance art.

We are happy to welcome a new voice to the blog!  Riley Horan is an experienced IT project manager that specializes in Agile and appreciates its focus on the team as the central building block.  Riley and others of similar mindset have been writing about building better teams at http://buildbetterteams.blogspot.com.

Reprinted from:  http://buildbetterteams.blogspot.com/2009/08/where-is-butter.html

——————-

My daughters love butter. They can’t get enough of it. When we have pancakes they love it even more. The problem is though, if they can’t see it they don’t believe it is there.

When you put butter on a hot pancake it melts to the point that you can’t see it. If I bring the pancake to them, without viewable butter, they say “Where is the butter?”. I tell them it is there, but they don’t believe me. So I need to go back and put more butter on it to satisfy their need to “see it to believe it”.

The same thing is true when you are working with someone who doesn’t necessarily behave in a way you would expect or want.

Twice in the last few years I’ve come across circumstances where people I’ve worked with have been steady and even keeled and not subject to excitement or panic. But a perception has been that this person is not driving their team. Not building excitement and momentum.

When this is brought to my attention and I’m told they are not a driver, I ask “why”? What are you seeing or hearing that is making you think that? Because it seems like they are working well and getting their projects done. The response has been that this person is not a driver because they are not pushing their teams.

Ah…..”Where is the butter?”

It took me a while to figure this out when I was working with one person a few years back. We changed one thing. When he was talking in front of people who like action I told him to use stronger words and stronger tone. Result? First time he did this he received a voice mail from someone who thanked him how he was driving on the project and moving things forward.

Did he change any of his other behaviors? No. We did talk about using a slightly stronger choice of words and tone in certain circumstances, but overall his behaviors were the same.

Don’t get confused if at first you don’t see the butter. It may really may be there, you just can’t see it. If you are making a pancake, sometimes you just need to give people what they want to hear or see, and that will keep them satisfied.

Yesterday afternoon I was talking to a friend and client about our efforts over the last six months to build and ship a new product platform and to use that effort to inspire new customers to use our products and services and new investors to help fund us through to profitability.  The result of those efforts recently shipped to our production data center and are now in use by our current customers.  As he has been talking to investors, he is now using this proof point to demonstrate to them that we have an effective team in place that is capable of delivering on the overall vision we have for the product.  More importantly, he has been telling them that we set out six months ago to build this platform and now, after six months, we have shipped it on time.  The problem?  Nobody believes him.  You can see it in their eyes and in the questions they ask – “Nobody ships software on time.  You cheated.”

I:  ”So you say that after six months of development, you have shipped the product that you wanted on schedule.”

A:  ”Yes…well, not exactly.”

I:  ”Oh?”

A:  ”Well, to be more precise – we shipped the product that our customers need on schedule.”

I:  ”And it’s done?”

A:  ”Of course not – we just started.  Show me a software product that is done, and I’ll show you a product that was just turned off by it’s last customer.”

I:  ”OK – fair enough.  As long as you can fund the ongoing effort from your revenue stream and be profitable, I guess I get what I want.  But let me ask the question a different way.  You said it doesn’t have everything you want but what your customers need – does that mean you had to leave out features?”

A:  ”Yes.  There are things we said we wanted to accomplish when we started that were left out.  But we always left the product owner in control of those priorities, and to the degree that they were able to effectively represent our customers, we were always working on what our customers would say was most important.”

I:  ”Aha!  But that’s cheating – you didn’t actually do everything you said you would the way you said you would at the beginning!”

A:  ”No, we didn’t cheat, but yes, we compromised along the way.  To be fair, the business’ understanding of it’s product, position in the marketplace, customer needs, and financial position changed a lot along the way, too.  Staffing and priorities related to other product lines were in flux, and when we started we had not even chosen the two strategic partners we would have to integrate with to provide a significant part of the feature set.”

I:  ”So, it’s somebody else’s fault that you did not get everything done that you said would get done?  I’ve heard that story many times before.”

A:  ”I think you are looking at it wrong.  If your assumption is that everyone starts with a perfect understanding of what is needed and how to do it and all that is needed is to execute on that plan, then I suppose you could say that it is cheating.  But, if you instead assume that everyone involved is simply making the best decisions they can at the time based on the knowledge they have, then the actual path you take to get to the goal isn’t the result of cheating – it simple acknowledges that we are all always acting on imperfect information.”

I:  ”I suppose that’s true – but how can a business make good financial decisions in a situation like that?  If we don’t know what we are going to get, when we will get it, or what it will cost, then we can’t determine if the investment will be profitable.”

A:  ”Well, you can set some constraints on all of those factors so that you know roughly what the business can expect, but are you saying that even if we could somehow tell you all of those things, then you would be able to tell us exactly how much of that product you will be able to sell?”

I:  ”Hmm – not really, at least not exactly.  After all, we’re in a speculative business venture trying to do something that has not been done before, so while we can try to model how the market will behave and how the business will perform, we can’t really be sure until we do it.”

A:  ”So, what you are saying is that while you can’t list the names and dollar amounts of the people that will buy the product, you can make macro level estimates based on related products and industries and overall estimates of the market potential and then correct that model as needed based on what actually happens when you start to sell the product?”

I:  ”Yes – that we can do.”

A:  ”But that’s cheating by your own definition!  Or would you agree that as long as you get the sales you need when you need them, then the model holds together and you get the results you expect without having to try to predict or control the details?”

I:  ”I see what you are doing; don’t try to twist this around!  OK, I’ll concede that point, but you are engineers; you’re supposed to be smart and detail oriented.  Salespeople have to have some latitude for finding creative ways to make their quote – it’s the only way to retain the best.  I don’t want to micro-manage what they do – it’s just the result I care about.  Anyway, let’s switch to the other side of the coin.  You said you got it done on time – so that means everything went to plan?”

A:  ”Nope – there were lots of things that went wrong along the way, and we missed our goals by a couple of months.”

I:  ”There you go – cheating again!  How can you say you shipped on time when you told me you missed your goals?  You can’t have it both ways.”

A:  ”But you can.  There was always two plans – the public plan that we told our current and future customers and investors, and our internal plan.  Our internal goals were much more aggressive because we knew that there would be some unexpected changes along the way.  What matters was that we committed to incremental steps along the way and corrected our plan each time we discovered that it needed to change.”

I:  ”So, let me see if I have this straight.  You intentionally created an internal plan to ship in April so that you could meet your external plan of shipping in June.  The way I see it, you sandbagged by 50% and came nowhere close to meeting your goals.”

A:  ”Or, another way of looking at it is that we intentionally created urgency within the team to make sure we stayed focused only on the most critical features.  Look at it this way – let’s say you have an interview for a job you really want at noon on the other side of town.  You get a map on the Internet and it says you will need 24 minutes to get there.  Do you leave at 11:36?”

I:  ”Of course not.  You might hit traffic, and the map doesn’t account for the construction on Hwy. 36 where they have it down to one lane, plus it always takes and extra 10 minutes or so to find parking near the actual building when you can find that.  I’d probably leave around 11 just to be sure.”

A:  ”Seems reasonable, but you have to admit that you might get there early and have to wait for it to start.”

I:  ”True, but the consequences of being late are more traumatic.  Besides, if I get there early I can always get other work done while I wait.”

A:  ”The same thing applies to our software release.  What if I told you that some of the team finished early and have already started working on features for the next release?  Would you still say we were sandbagging?”

I:  ”It does help, but it still seems like you could just do whatever you want for the first couple of months and then use the last 4 months to actually build what we asked.”

A:  ”It probably seems that way, but what if I also told you that every two weeks we showed the team actual working software?  It seems hard to hide that way.  And what if I told you that every two weeks you get to decide what we will do next based on your current understanding of what is important to our customers and to the business?”

I:  ”Trust, but verify.  I guess I like that I at least get to know how my money is being spent.  I don’t want to have to watch over every little detail along the way, but I need to know I’m getting value for my money.”

A:  ”I wouldn’t want it any other way.  I know there are situations where the technical teams take advantage of the business, but that’s really hard to do with Agile.  In fact, if there is any risk, it is that the business so dominates the agenda that you do not make important but not urgent investments in upgrading technologies or staying true to your overall architectural plan.  You have to make sure you have leadership that understands how to deliver those things along the way while explaining to the business why they are important enough to invest in.”

I:  ”I feel like we’ve been talking in circles, but I at least feel like I understand what happened.  You didn’t ship what you wanted when you wanted, but you did ship what your business and your customers needed when you needed and the business had good visibility into and control over what was happening along the way.  I guess that’s not cheating – it’s just a practical approach given the situation, especially for an early stage company without a proven product or market.”

A:  ”Exactly.”