Having a Ball – Introduction

There is a simulation I build into my Agile training curriculum. It is based on a very old game that has been used for ages. I’m not the inventor of the game, but I am a very strong adapter of it. Here I examine the core game followed by variations I have used…

Continue reading “Having a Ball – Introduction”

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.

True.

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 – Introduction

Here the metaphor of lawn care serves as a gateway into a discussion of defining and estimating work in a manner similar to what new agile teams are first called upon to learn. We then build on those concepts to demonstrate the rationale for maintaining cross-functional teams. And finally how to budget for these activities.

Continue reading “If I Had a Tractor – Introduction”

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?”