A Matter of Trust

For a true agile transformation to take place in an organization, a variety of values and principles will need to align.  Among these, the one that I believe is the most necessary is “Trust”.


I once had the opportunity to serve as facilitator at a local PMI user group meeting on the subject of PMO’s.  I had worked with PMO’s in the past, both prior to the introduction of agility, and after agile had arrived and needed to be brought under the careful guidance of the Project Management Office.  I worked with a PMO every day in my engagement at that time, so I readily accepted the offer to guide this audience’s-inspired discussion.

Each attendee had been asked to provide at least one question they would like to see addressed by their fellow audience members.  Prior to the event, I had grouped the questions into some loose categories.  There was a collection of questions asking how big an organization needed to be before a PMO was warranted.  Others focused on how you measure the success of such an organization.  Yet another collection focused on recruiting PM’s from other groups to join the PMO.  There were a few questions that seemed intent on causing a disagreement.  I set those aside to use in case of emergency.

I decided a good place to start the evening would be to introduce the group to Simon Sinek’s golden circle (from his book: “It Starts With Why”, and his Ted Talk).  I asked the group to identify what PMO’s did, and I was immediately answered with a couple dozen one-word, or short phrase responses.  Words like “oversee”, “monitor”, “assure” and “coordinate” were offered.  I then began Simon’s infamous opening line, “Most people can tell you ‘What’ they do.  Some can tell you how they do it.  But very few can tell you why they do what they do.”  And so I challenged the group to explain why you needed a PMO.

Again, a barrage of short words.  Only these had a slightly more negative tone.  Words like “enforce”, “compliance”, and “control”.  In fact, it seemed like all of the words used were reactionary.  Reactions to things that had gone wrong in the past.

As discussions died out on one topic, I read another from the list.  When the answers came too quickly, or the audience appeared to lose interest, I’d pull out one of the provocative questions I had flagged from the list.  My favorite was something along the lines of, “Since our PMO formed, we’ve seen an increase in red tape, a decrease in PM quality, and a general drop in our ability to deliver.  Maybe PMO’s would work in other industries, but I think they don’t help in IT.  Your thoughts?”  As I finished the question, there was a sort of stunned silence in the room.  Some people smirked at the audacity of the question.  Some looked legitimately insulted.  I pushed a little, “…or to put that another way.  PMO’s suck.  Who’s with me!?”

That got the conversation going!

As more questions came and went, we circled back to the whiteboard repeatedly.  We talked about the conditions that caused the formation of most PMO’s.  A common path involved groups of developers got out of hand, so a PM was brought in to control the situation.  More teams formed, and more PM’s came in.  Eventually, the number of PM’s was large enough that the differences between their methods caused problems.  So a PMO was formed to bring the PM’s under control.  One helpful attendee then explained how in a large enough organization, you end up evolving multiple PMO’s, and those PMO’s in turn eventually do things differently enough that chaos returns.

We circled repeatedly back to “Why” each situation existed.  And time and again, it came down to one thing.  Lack of trust spawned strict rules, and necessitated enforcers, with the PMO in the role of the police.

Role of the PMO

Establish standards, and validate that they are followed.  To manage the Project Managers who manage the projects.  To ensure that costs are contained.

Role of the Project Manager in Agile

My approach to agility is very Pragmatic (as opposed to Dogmatic).  I’ve never liked rules-lawyers, so I don’t appreciate when people quote agile scripture as their only defense for why they make certain requests (demands) of the teams they train or coach.  If I’ve learned one thing in my years as an Agilist, it’s that people really need to understand ‘why’ a thing is needed to truly embrace the change that such a thing demands.  So, when I make a statement that Agile methods like Scrum provide no role for a Project Manager, I mean that as a simple statement of fact.

Scrum named only three roles: Development Team, Product Owner, and Scrum Master.  The responsibilities traditionally laid at the Project Manager’s feet in a traditional model have been redistributed to those three roles.  Things generally associated with the estimation and sequencing of work are allocated to the Development Team.  Things associated with the prioritization of work, or the containment of cost are allocated to the Product Owner.  And finally, things associated with governance, collecting/providing status, coordination with outside demands, or removal of blockers are assigned to the Scrum Master.  To put that another way, accountability and responsibility have shifted to the role that is best equipped to control that aspect of work.

So what’s a poor


Metric System

                                                                                                                                                                                                                                                                                                                                                                                                  “How we deal with death, is at least as important as how we deal with life, wouldn’t you say?” – Admiral Kirk

Have you ever been faced with a concept or idea that just refused to go away?  I think my least favorite one is “Service Level Agreement (SLA)”.  But right after that one is “Metrics”.

As an Agile Coach, I often encounter requests from clients to provide a list of Metrics.  I can hear the collective groans from a lot of you.  The funny part is that some of you groaned because you take the position that Metrics mean you can be held accountable (judged), and some of you groaned because you think I’m about to tell you that Metrics are evil.

You’re both right.  Kind of.

Let’s come together and agree that Metrics are a necessary evil that can allow us to gauge performance of a system.

BTW, there was a third set of groans.  Those groans came from the agile coach in an agile center of excellence who were tasked with creating a list of Metrics for the organization to adhere to.  With trepidation in your heart, you presented a simple, standard response… and things went sideways.

Metrics is not an easy subject to discuss in the agile world — partly because Metrics are so prevalent in the non-agile world.  It was difficult for agile methods to be adopted in organizations that prided themselves on their ability to measure things.  Meaningfully.  They demanded the same of the agile insurgency.  More’s the pity, because agile cut its teeth by opposing the inappropriate application of those metrics.

Metrics are a tool.  I recall a manager at one of my clients adamantly insist that Metrics are just measurements, and measurements are not evil. They are just numbers.


Metrics are tools, and as such are capable of helping us achieve great things. Tools are also capable of causing a lot of damage when that tool is used in the wrong way.

At the Chicago Coaching Summit 2018, held in Chicago this past October, I led an Open Space discussion on Metrics.  It was widely attended, and actually extended into a second session.  We started our discussion with the premise that the call for metrics was not going to go away, so let’s talk about the metrics we’ve used successfully, and also the ones that we tried to use that led to unexpected outcomes.  We decided that Metrics had attributes that we would discuss.  We chose:

  1. Metric Name
  2. Intended Use
  3. Unintended Consequence
  4. Appropriate Level
  5. Good or Bad?

There was a side conversation that centered around a model of Metrics-building called GQM (Goal, Question, Metric) which centers on the concept that you start with what you want to achieve, what question could you ask to find out if you are achieving it, and measure something that gives you an answer to the question.

The Metrics are summarized in the following link: https://drive.google.com/file/d/1qmyjH3hn8N1Tf0Dn9aTySiqlNXQFuJbI/view?usp=sharing


If I had a tractor…

Agile Estimation and Planning


With the advent of agile methods and their affinity for rapid delivery cycles, traditional estimation models are coming up wanting.  Agile estimation, while undoubtedly faster is also difficult for some to grasp.  Expressing work in terms of time has been burned into the software community’s psyche.  But it doesn’t have to be that way.  I coach agile teams in making the switch from traditional development models to agile.  In doing that, I help them learn new ways of estimating.  This series of articles will hopefully explain – through metaphor, why the old way of estimation was problematic, and how the new way addresses those shortcomings, is faster, is no less accurate, and can even be fun!

If I were to stand up in front of a room full of people, and select individuals at random to answer this question:  “How big is your lawn?”, I would get a variety of responses.  Many common answers are “1/4 acre, 1/2 acre, 10000 square feet, or maybe 900 square yards”.  The answer I would not expect to get is “45 minutes”.

Why is that?  For one thing, I asked for a size estimate, not a time estimate.  Yet, all over the globe, if I ask a software developer or project manager to estimate the size of a feature, they will generally answer in a number of hours, days, weeks, months, etc.

Time instead of Size.

This behavior has been ingrained in the development community for decades.  Agile methods have attempted to break that habit by requesting effort estimates as a measurement of relative size (often story points).

Indeed, I have been coaching and guiding teams long enough to have seen a variety of attempts to shift teams to “how big?” rather than “how long?”. Admittedly, it’s a really tough transition to make. And a very common way of approaching that transition is to offer a crutch – usually a conversion factor … you know, so the team members can wrap their heads around the concept more easily.  A common one I’ve seen is 1 Story Point = 1 Ideal Day.  SAFe offers the crutch that 1 Story Point is about 8 hours.  I’ve seen someone recently amend that to a range from 1 to 10 hours.

I’ve adopted a lot of truisms in my years of observation and continuous improvement. One that has stuck with me consistently though my agile career, is simply this:  “There is no direct relationship between Story Points and Time.”  If I want to leave some wiggle room, I might say “no reliable relationship” or “no consistent link”.  Of course then I’ll toss in that story points and time is not constant from team to team.  Any attempt to build that bridge will be fraught with drama, and lead to disappointment.

But nobody believes that.

And so, again and again, those who won’t acknowledge the past, repeat it over and over.

I’m hoping this series of articles on Agile Estimation and Planning will serve to save even a handful of you from following so many others in walking off that cliff.  If nothing else, it’s a chance for me to hone my explanation.

Feedback is welcome, please weigh in.

Part 1 – Size

Let’s go back to the lawn example, and start with a simple explanation as to why time is a terrible way to measure size…

I asked you how big your lawn is. I want you to think of your lawn. Think of the dimensions, think of how much of it is actually available for mowing.  Yes, that’s right. The grass.  Not the driveway.  Not the garden, nor the planting beds.  Not the patio or the stoop.  Got it?  First of all, notice that the size of your lawn is not the size of your lot.  The lot represents the dimensions of your property.  But not all of that is lawn.

Are we good so far?  I don’t want to lose you.

Now.  Picturing your lawn, and only your lawn:  How big is it?  Odds are, unless you’ve played this game before, you can’t give me an exact answer. You probably could if I gave you enough time and a tape measure.  You could probably get me a pretty exact measurement of the lawn part of your property.  But I have two problems with that.  First, it would take too long, and second, that wouldn’t be an estimate anymore, would it?  It would be an actual.  Traditional estimation models excel at doing this (pun intended), by giving you a really long time to lull yourself into a false sense of security in your ability to predict the future.  You may have noticed this activity is often followed later by a check of how accurate your estimate was — or more to the point, how wrong you were.  “We gave you months to predict the future! Why were you unable to give us a better estimate?”  That’s a hell of a way to start a conversation, isn’t it.  Let’s try to accentuate the positive a little, shall we?

In a moment we’ll get back to talking about the size of your lawn…by comparing it to something else!  Studies have shown that while humans are pretty bad at exact estimates, they are very good at comparing things.  This is a survival skill you learned as a small child – especially if you had siblings.  Remember family deserts?  Remember when there was one piece of cake left and both you and your pesky brother (or sister) wanted it? Remember how your mother, with the wisdom of Solomon, suggested you split the piece? The rules were simple: One of you sliced.  The other one chose – which gave you all sorts of incentive to slice well.  But no matter how carefully the slicing was carried out, one piece wound up slightly bigger than the other one and I’ll wager my half of the cake that you could tell exactly which half was bigger (the one you wanted), just by looking at it.  Or perhaps, they were actually close enough that there was no real distinction between them, and you both got to eat a piece of cake with satisfaction of knowing nobody got cheated.  We are going to leverage this skill in Agile Estimation.  The ability to look at two things, and declare whether one is bigger or smaller will prove valuable here!

Ready?  Do you need some cake first?  We don’t have time for cake.  Cake is for closers.  Are you a closer?  Let’s see what you’ve got.

Think about your neighbor’s lawn.  Let’s see if you can answer a simple relative sizing question.  Is your neighbor’s lawn, bigger, smaller, or about the same size as yours?  If you live in the suburbs this part will be really easy. Odds are pretty good that your neighbor not only has the same size lot as you, they probably also have a similar amount of grass in their yard.

So, what’s your answer? Is one lawn bigger than the other? Or perhaps, they’re close enough that you’re willing to call them even.  We’re talking now about degree of precision. When we ask for estimates, we should not be asking for perfection.  We just want to know within a margin of error.

To make this next part easier, I’m going to switch to talking about myself for a sec, partly because I’m having trouble seeing your lawn, but also because my neighborhood provides a particularly compelling example.

I can say with a fairly good degree of certainty that not only do I and my two adjacent neighbors have similar-sized lots, but the amount of open grass is pretty similar between the two — close enough at any rate.  That means, in terms of relative sizing, our three lawns are the same size.  How big is that?  Not sure yet, let’s think a bit farther.

Now think about your neighborhood, and the finite universe of houses and lawns that surround you.  Can you think of any lawns smaller than yours?  Can you think of any that are bigger?  If you can answer ‘yes’ to either of those questions, then the next question will be “How Much Bigger, or How Much Smaller”, and because we haven’t established a unit of measurement yet, let’s just use relative sizes.

Returning to my yard, the houses in the middle of the block all have the same lot size.  I also can’t think of any houses in the area with a smaller yard; but I can think of a few yards on the corners that are bigger… almost twice as big!  And then if I think about all the houses on the block, there is one house that due to the curve of the road, I’m pretty sure his lawn is closer to triple the size of mine.

I’m going to establish an arbitrary starting point now.  Based on my understanding so far, my yard and my neighbors’ are all 1 point yards, the corner houses have 2-point yards, and the odd-shaped yard a 3-point yard.  The chief advantage at this point, is this measurement was FAST.  Not a lot of time spent agonizing over it.  It was a quick 1,2, 3 and we’re ready to move on.

Figure 1.1

I now have three data points we can use to compare other work to.  If someone asks me over to their house and say, “could you estimate my lawn?”, I need only look at it, and compare it against the three data points in my head.  Is the new lawn bigger, smaller or about the same as one of those other lawns.  And if it is bigger or smaller, how much so?

The other advantage is that this estimate is PORTABLE – meaning it can be applied to the work of more than one team.  We’ll start to see why that’s important in the next section.

Part 2 – Scope

At this moment, all I have is a cursory understanding of how a few pieces of work relate to one another.  There are a myriad of activities that one could perform in support of a lawn.  We’re going to focus initially on mowing.

One weekend not so long ago, I looked at a long list of activities I needed to work on, and was trying to figure out how much I could do with the time I had.  One of the things that I have a pretty good handle on is mowing my lawn.  My definition of “Done” was pretty basic: gas up the mower, make sure it was set to “mulch”, and wander the property until all the grass was a nice, mostly uniform height. On most weekends, using my self-propelled lawnmower, I have been able to complete that job in about 45 minutes.

“Ah HA!”, I hear you cry, “Time!  Your one point lawn takes 45 minutes.  I’ve cracked the code!”

Well.  That’s nice.  Good for you!  But before you pat yourself on the back and start dividing my backlog into 45-minute increments, I’m going to wrinkle this up for you a bit.

Last summer, I hired someone to mow my lawn for me.  Don’t judge.  Work was demanding, and it was hot, and once you hire one of those guys, they keep coming back.  So my point is this:  Ed didn’t have a measly self-propelled walk-behind mower.  No.  He had one of those zero-turn-radius, stand/ride-behind monster machines that goes zero to sixty in about 2 seconds.  He fired that bad boy up, and viola! My lawn was freshly shorn in 10 minutes!

So, let me ask you this: Did my lawn change size?  If there is a universal constant between time and size, then Ed’s performance had reduced my 1 point story to something under a quarter point.

I submit to you that my lawn is in fact, the exact same postage stamp it has always been.  If it was 1 point before, it is 1 point now.  But something is clearly different.  Even I have to admit that 45 minutes vs. 10 is pretty compelling (or at least disheartening).

The difference has very little to do with the lawn itself.  The difference is that Ed, with his superior machine is capable of delivering the same work in less time than me.  How can I use this?  Well, if you take my 1-point lawn, and assume that every approximately 1-point lawn will take the same approximate amount of time (for me) then I can use that understanding to suggest how many 1-point lawns I believe I could fit into a weekend.  Given what I know, I think I could complete approximately 16 points worth of lawn .  But my friend with the impressive hardware can do many more!  The math whizzes out there have probably already concluded that Ed can do six 1-point lawns in an hour.  So given an eight hour workday and two days in a weekend, he’s going to be pounding out 96 points worth of lawns every weekend.  Those same math whizzes will point out that my sixteen-lawn estimate for myself is obviously under-represented.  I should be able to do four lawns every 3 hours, so in an 8 hour day, I should be able to do 21 points worth of lawns in a weekend, and if I just did a little overtime, I could pull off 22!

Isn’t math awesome?

and Terrible?

Allow me to toss a little water on those flames of victory you’re dancing around.  Unless you are going to work things out so those 21 lawns are placed end-to-end next to each other and set up my mower to be perpetually full of gasoline, I can’t possibly attain the number you’ve so carefully assigned to me.  I have to move the mower from one location to another.  I have to refuel at every job.  I have to stop to take a drink of water, or eat lunch, or answer a call.  Your assumption of my velocity seems to be missing a few things.  Your assumption of Ed’s velocity is just as wrong, by the way.  In order to move that behemoth of his, he needs to drive it up onto a trailer in order to move it to the next job site.  Where would we account for loading and unloading time?  Where do we lump the travel time between locations?  What about bathroom breaks?

The capability of a team is made up of a lot more than just the sum of the hours of work they perform.

Part 3 – Definition of Done

Something else happened when I hired Ed to mow my lawn.  He brought friends.  Not only was Ed mowing my lawn, but he had another guy with a gas-powered trimmer and yet another guy with a leaf-blower helping him.   So when he was “Done” with my lawn, not only had he completed the mowing job in less time, but he had DONE MORE than I ever did in my 45 minutes.  Trimming!  Edging!  Cleanup!  And once my wife realized those were on the table, those all became desirable additions to my lawn mowing regimen as well!  It was no longer sufficient for me to just gas up my mulching mower and try to get as close as I could to the flower beds.  I needed to pull out my electric trimmer, and follow myself around the yard, then edge the sidewalk, and then make sure I swept the sidewalk and driveway.  Guess what!  My 45-minute job wasn’t 45 minutes anymore!  Ed has a team of three people.  My team still only has me on it.  All that additional work added another hour to the time it takes me to complete a typical 1-point lawn (thanks a lot, Ed).

I ask again.  Think carefully.  Has the lawn change size, now?

No, the lawn is still the same lawn it always was.  But the definition of what constitutes a completed, quality job has certainly changed!  And because I now need to do more things to complete the same sized lawn, rate of delivery will suffer for it by decreasing.

Understanding this distinction is absolutely key!  The job didn’t change size, the level of expectation changed, and my team failed to adapt to that change.  The result was a measurable impact on my ability to deliver value (completed lawns).

Why would I insist on looking at it this way?  Consider this:  Recall, earlier I had estimated that I could deliver 16 points of lawns in a weekend — sixteen lawns just like mine.  In order to compete with Ed’s lawn service, I can no longer get away with a mow-only task list.  I need to perform the same quality tasks that Ed provides!  If I equated size to time, I would now have to re-estimate all of the lawns in my list!  Instead of 45 minutes, they’re taking 45+60=105 minutes.  By that magic conversion factor of 1 point = 45 minutes, those 1 point lawns in my neighborhood are now 2.33 points each (because math).  The corner lots are now 4.66 and the weird lot is a whopping 6.99.

Also, since you already had the calculator out, the project manager/mathematicians went even further: “By my calculations, in the same 16 hour work weekend, you can now to do (16 hours x 60 minutes per hour ) / 105 (minutes per lawn) = 9 lawns. 

See how easy this is?  You changed the scale and did math again, trying to get me to commit to something like (2.33 x 9 = 20.97 — aw heck, let’s say 21 points).  When a 1-point lawn was 45 minutes, you demanded 21 points.  Now that a 1-point lawn is 105 minutes, you still want 21 points.  Except that before, that 21 points would have delivered 21 pieces of customer value, and now that same 21 points is only delivering 9 pieces.  My team appears to have maintained velocity (that’s good, right?), but we’re not advancing anywhere near that rate!  Only 9 customers are satisfied by the same 21 points.

Also keep in mind, that I’m still not accepting your math.  I was only willing to commit to 16 points per weekend.  And I’m not going to re-estimate everything on my backlog, either.  THE LAWNS DIDN’T CHANGE SIZE!

With the impact the new Definition of Done is bringing to the table, unless I do something to correct my team makeup, you’re going to see my velocity drop like a stone to 7 points – seven lawns instead of sixteen.  And that very rightly should set off a red flag somewhere.

Part 4 – Velocity

When we talk of delivering value to our customers, we need to be very careful that we only count things that we’ve actually completed. The Definition of Done says I must mow, trim, edge and clean to meet my customer’s expectations. If I fail to deliver on any single aspect of that definition, the customer could reject my work, and refuse to pay me.

Think about that.  Even if I spent every minute of my weekend pushing the lawnmower around, and managed to cut the grass on twenty lawns — if I never touched the trimmer or broom, then despite the fact that I was BUSY the whole time, I didn’t actually COMPLETE any of the work.  What do I do now?  What do my customers do?  Do I just come back next weekend and do the trimming, edging and sweeping then?  Nice theory, but the grass will all have grown back by then, so now I’ll spend all weekend finishing he jobs from last weekend, but the customer will look out and still see incomplete work, and they’d be well within their rights to withhold payment again.

This is why the Agile world is OUTCOME-DRIVEN. It doesn’t matter that we are keeping our people active and working (busy) if they aren’t finishing everything in the Definition of Done.  When you get right down to it, time estimates are not helpful.  We don’t deliver time.  Our customers don’t consume hours.  They really don’t care how busy we were.  They care about results.  So we need a measurement of our ability to deliver VALUE.  In Agile, we call this Velocity.

Velocity is a measurement of the number of points of value that a team is able to complete in an iteration.  Only work that meets the Definition of Done is counted toward Velocity.  Partially completed work may as well not exist.

Velocity is a very useful metric, but it is not a universal constant.  It is a value that is unique to every team, based on their skills, tools, team structure, etc.

No matter what, Ed’s team is going to have a higher velocity than me.  First, their equipment is better -I can’t compete with that monster mower. And second, his cross-functional team can do tasks simultaneously.  In terms of clock time, from the moment they pull the equipment off the trailer until the time they roll it back up, something like 15 minutes goes by… (this includes Ed coming to the door for his payment).

Despite the fact that I’m telling you not to estimate in time, the concept of time keeps working its way into the conversation.  For instance, if I say Ed’s takes 15 minutes from wheels down, to wheels back up on the trailer.  That’s time, isn’t it?  You’re right, I did talk about duration of the job.  But I didn’t ESTIMATE in time.  Do you understand why?

The reason we want to stay away from time estimation is because time estimation is not portable!  It cannot translate from one team to another. When Ed takes 15 minutes, or I take 105 minutes, this causes a problem when it comes to translating our work.

My hours are not your hours.  The way I work, and the experiences I’ve had will ultimately affect the amount of time it takes for me to deliver.  What if Jeremy, the kid across the street grabs his dad’s lawn-mower and decides to get into this lawn-cutting game for some extra pocket money.   As it turns out, Jeremy’s mower is exactly the same as mine because his father and I both bought them when the local big-box store had a killer overstock sale.  Jeremy and I have the same equipment at our disposal.  Does that mean he is going to take the same amount of time that I will to mow my lawn?  I will bet you the answer is NO.  Whether Jeremy and I have different levels of strength, speed, attention span, or even experience, I can virtually guarantee that we will perform the same amount of work at different speeds.

Furthermore, if Jeremy or I walk up to a house on the next block, intent on giving our estimate, and instead are informed that Ed was already there, and told them it’s a 15-minute job.  Does that mean I’m required to accept that estimate?  How many times in your professional career have you found yourself being held to an estimate made by someone else?  It happens all the time – even more disturbing when that estimate isn’t even made by someone who does that work.

Part 5 – Cross-Functional Teams

Let’s assume you’re someone who’s going to fund the mowing of lawns.  Maybe you’re the head of the homeowners association, and you’re in the process of subcontracting the upkeep of lawns in the subdivision.  My team originally pledged 16 points, and my competition pledged 6o points.  But after you saw the additional services they were providing, you requested that we have a uniform Definition of Done across both teams.  This threatens to tank my performance!

How could we reconcile this?  “What,” you may ask, “do I need to do, to maintain the higher committed velocity?”

I suppose I could throw caution to the wind, and try running behind the mower!  I might be able to bring the time it takes to mow down a bit, but I’m probably going to miss some spots.  I don’t think that will ultimately solve the problem.

I could work overtime, mowing long into the evening hours.  That has potential, but now I’m going to get way more tired, and likely make mistakes.  The quality of my work will certainly suffer, and I now incur the risk of the customer rejecting the work. What would you do?

How about adding people to my team to handle these other tasks in the Definition of Done.  Ed has a cross-functional team (mower, trimmer, sweeper), where I had only a single generalist on my team).  If I got someone to run the weed whacker while I mowed, and whichever one of us finished their job first, then swept the sidewalk, I might be able to bring my clock time down to under an hour.  The math would support us saying we could reach 8 points per day then, but I’d still feel a lot better calling it 6 or maybe 7.  Either way my Velocity for the weekend could increase from a around 7 if I go it alone, to a real possibility of 12-14.  Not quite 16, but let’s face it: when I was just mowing the lawn, there was still long grass growing against the fence and the planting beds that the mower just couldn’t reach.  There was still grass clippings on the sidewalk, and let’s not even talk about the edging! In short, my quality was low, and the other team revealed that fact to the stakeholder.  I had to adapt or risk losing the gig.  So I expanded my team.

This notion of a cross-functional team is very powerful.  It allows us to build teams with all the skills needed to achieve our Definition of Done in one iteration, without relying on outside help.

Part 6 – Multi-Tasking and Work in Process

How good are you at multi-tasking?

Part 7 – Stable Funding

…or more importantly, our value.  What if I want to find out when I can expect delivery on the 16 points of lawns Figure 1.1?  It’s a valid question.  It happens all the time in business.



Are We There Yet?

A friend of mine was once put in charge of the Innovation group at the company where we worked.  Whenever we would talk about the state of Innovation, he always seemed preoccupied with creating an “innovation organization”.  But the conversation never seemed to get far beyond that point.
Continue reading “Are We There Yet?”

When things get hard…

“We practice when things are easy so we can use it when they get hard.”

The phone in the dining room rang, the caller id showed my parent’s number.  My wife looked at the phone, then up at the clock, then at me.  Somehow, we instinctively knew what was coming.  I pushed the speakerphone button, and I heard my mother’s voice, quiet and wracked with grief. “I’m all alone.” Continue reading “When things get hard…”

Instilling a Sense of Urgency

The team just isn’t demonstrating a sense of urgency.

The manager looked earnestly at me across the table.

I took a deep breath.  “If I may clarify.  Is your wish that the team understands the urgency of the situation, or that they demonstrate a sense of … panic?” Continue reading “Instilling a Sense of Urgency”

Orchestrating Beautiful Music

Can you imagine if you invite the best musicians in the world to perform in an orchestra without having any coordination between them?

Although not the intention of the author, the quote above served as a bit of inspiration for me this afternoon.  Agility is often maligned by its detractors as being ultimately untenable because it relies on self-organized teams to build a successful, complex structure.  I often encounter individuals who attempt to disprove the viability of agile in their organization by stating how impossible it would be to create a large system without first engaging in a big up-front design.  As I said, it wasn’t the author’s intention, but he indirectly mimicked a conversation I had a week previous, where an architect waved off agile because it allowed development to begin before all the kinks were worked out of the system.

The architect had mentioned music as well.  So the premise we will work from, is that agile can be disproven because you cannot put a group of random musicians in a room together, and expect them to play music.

Since my daughter was present as I read the comment, I thought it was a great opportunity to see her thoughts on the topic.  My daughter has played viola since the fifth grade.  She has participated in several orchestras, both in and out of school.  She has been a soloist in a jazz ensemble, first chair among the other violas, as well as a member of a chamber orchestra.

“What would happen if you took a bunch of orchestra musicians, put them in a room together, and told them to play?”

She pondered for a moment, then asked, “Soloists or regular orchestra?”

I immediately saw her point.  “Describe both,” I said.

Team of Soloists

“Well, a bunch of soloists would probably fight until they figured out what they should do to make it work,” she began, “But they would figure it out because that would be the only way for the outcome not to suck — and more than anything they hate to suck.”

I smiled as she related the tale.  Images of highly experienced, lone-wolf programmers thrust into a team situation, and asked to work together.  First a battle of egos, as each tried to proclaim themselves leader, and ultimately an attempt to carve out their own special expert silo so they wouldn’t have to work with anyone else.  It reminded me of the experienced developer who declared in a recent retrospective how happy he was to be able to work at his desk away from everyone else, so he could be more efficient, while everyone else complained that they had no idea where he was in the development of the features he had signed up for.  How they could help.  If he even needed help.  Whether he was on track to finish.  It usually takes a few sprints before the team forms around the concept of cooperation — almost always as a result of a lone wolf failing to deliver.

Orchestral Regulars

She then continued: “Regular orchestra players would form into groups by instrument. Orchestras already have an organization structure built in. Each section follows the lead of their first chair. All the first chairs confer together. Then they would play.”

Again, I imagined a cross-functional development team, each member holding a vital piece of the puzzle to create the end product.  Sometimes we allow teams to form organically.  Often someone tries to construct a magical combination of personalities and skills.  Even more often we throw whoever we have into the mix and hope for the best.  In agile methods such as scrum, we don’t provide a leader.  We provide to guide, and we provide an enabler.  The guide sets the limits of the performance – declaring the desired outcome.  The enabler looks for ways to help the team perform more efficiently.  One possible way to look at the conference of first-chairs is to think of it as a scrum of scrums.  A collection of independent teams of instruments, agreeing to where they would meet in the performance, then going back to their individual groups and explaining the pace and tempo.  Have you ever noticed how all of the bows in an orchestra move in unison?  That isn’t a requirement.  The instrument will produce music whether the bow is being drawn upwards or downwards across the strings.  It is something the musicians do by choice, because it looks better.  This struck me as being particularly interesting, because it speaks to development standards that most teams employ.

The Chamber

I then asked about chamber orchestra players.  She brightened up immediately.  “Oh, chamber musicians would have no problem at all.  They already know how to self organize and direct themselves.”

A chamber orchestra is probably the best analogy for a high-performing agile team.  If you’ve never seen one play, the chamber has no director.  They choose a leader among themselves, who begins the performance – almost always by raising their bow, and making eye-contact with the other members around them.  They begin the movement, and the rest of the chamber falls into step, each performing their unique role in the performance.

Who is in charge?

I deliberately left the conductor/director out of most of the discussion.  Some would say that the director is the scrum master.  I think they are probably more of a product owner.  They select the music.  They set a cadence, and they point at specific performers at key moments to make sure they maintain alignment.  But they don’t make the performance happen.

So where would a scrum master fit into this orchestral analogy?  They are probably walking around backstage keeping other people from trying to influence what the individual performers are doing on stage.

When I coach an agile team, I do so with the intention of teaching them to be able to function without me watching over them.  The scrum master finds themselves in a similar situation.  We often say that the role of the scrum master is to put themselves out of a job.  Ironically, unless your organization has embraced agility at all levels and actually respects the necessity of self-organization, you will need to have that protector role present — even though they are not directly involved in the creation of the deliverable.

What is the Deliverable?

Where the orchestral metaphor first appears to fall flat may be in the music sheets themselves.  One might think that the music sheets are the deliverable … that our mythical orchestra is just reproducing something that has already been clearly defined.  I disagree.  The music sheets are not the deliverable.  The PERFORMANCE is the deliverable.

The performance is the thing that is created though the unique application of the musician’s craft.  Each performance is unique.  So if not the deliverable, what then does the sheet music represent?  Is it the method that is being followed?  Is it the requirements list?  Perhaps it is the definition of done that the orchestra is trying to achieve.  There are certainly plenty of music ensembles that manage to play together just fine without sheet music.  Anyone who has ever witnessed a jam session in progress–with only a few words of collaboration, almost any group of experienced musicians can find a way to play together.

But it always takes collaboration.  A few words.  A nod.  A steady tap of a foot.

Then as they work together, they learn each others strengths.  They learn how their various parts combine and the whole becomes greater than the sum of the parts.



Best Laid Plans…

I am one of the co-organizers of a local Agile Meetup group (APLN-Chicago).  Our monthly meetings are generally attended by folks in one of two camps:  The first, I’ll call the Agile Seekers — people who would not consider themselves experts, but are there to learn the what/why/how of Agile.  The second group I’ll call the Agile Explorers — people with practical experience in Agile, who are looking to test the edges of Agile and finding/sharing new ways of plying their craft.  On most nights, we manage to strike a pretty good balance between the different camps, finding ways to leverage the experience to feed the learning, and everyone walks away with something positive.  I wish I could say it always works that way, but last night it kind of got away from me. Continue reading “Best Laid Plans…”

Accentuate the Negative?

The instant message app chimed on my desktop. “How confident are you that we won’t find any more defects in testing?”, the department head asked. I glanced over at the task board, at the lone sticky note sitting in the “In Progress” section: “Architecture Review”, it read. I popped open the chat window, and responded, “100% sure. We are done with testing.” I watched the window for a moment as the message app informed me they were typing their reply. “Okay. Because I’m about to go report that to the senior managers.” “No problem,” I typed back. “See you at the demo, tomorrow.” Continue reading “Accentuate the Negative?”