Wednesday, July 19, 2017

There is no such thing as a scrum team....

Yeah, I know that's a heck of a clickbait title, but it's also the thesis of this blog post.

According to the Scrum Guide (2016):

The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. Only members of the Development Team create the Increment.
Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness.
Development Teams have the following characteristics:
  • They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;
  • Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment;
  • Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;
  • Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis; there are no exceptions to this rule; and,
  • Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.

Five rules. Absolutes stated clearly. For two of them "there are no exceptions to this rule."

Just for fun, look through all five statements. Tell me how many scrum teams you know of personally for which all five of these are absolutely true.

Self-organizing: 

No one is allowed to tell the team to refactor or not to refactor, to test or not to test, whether they can mob or pair, whether they have individual assignments or not. Nobody can force them to pair or mob or TDD if they don't choose to. They control their own means and methods. Scrum doesn't tell them how (which has been a historic criticism of scrum, compared to XP which requires strong practices).

Most common failure modes:

  • Management, or the management tool, requires that work is assigned to individuals
  • PO or SM or "development lead" or "tech lead" (see 'no titles') often tell the team that they can't refactor, test, mob, pair
  • The HR system requires that work is tracked to individuals (else how can annual reviews be conducted? How do you separate overperformers from underperformers?)

Cross-functional:

Every skill needed to produce the code is on the team, and no work is done by people not on the team ("Only members of the Development Team create the Increment.")

Failure modes:
  • Separate test teams
  • Separate ops teams
  • Separate PO organization
  • Separate component teams
  • Separate UX team or specialist
  • Architects review work by all teams before it can be released
  • DBAs are not on the team, but have to be involved with all data changes

No Titles: NO EXCEPTIONS.

Other than scrum master and product owner, there are no titles other than developer.

Failure modes:
  • Sr/Junior separation (career path involves title and compensation)
  • Lead developers
  • Delivery Lead
  • Test Lead
  • Tester/Developer/UX/DB subteams have titles (see "no subteams").

No Sub Teams: NO EXCEPTIONS

There is one team, "regardless of particular domains that need to be addressed."

Failure modes:
  • See the teams called out in "cross-functional" above, especially component teams.
  • There is often a separate devops group for deploying and managing the application.
  • The requirements come from a separate subteam which is not incorporated into the team, but is an external entity (a separate team) who decides what should be built.

Teams Are Atomic:

"Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole."

In other words, work and accountability are pooled and the team is one atomic unit. The world outside the team does not deal with the team as individuals or ask the team to operate as a team of associated individuals. Instead "the team" is assigned work, and "the team" completes it, or "the team" is held responsible for it. The team does not throw members under the bus to avoid blame.

Failure Modes:
  • Assignment of work to individuals by manager, PO, or SM.
  • Disallowing pairing/mobbing (see first rule)
  • Requiring specific technical practices
  • Comparing individuals within the same team
  • Tracking work to individuals
  • Individuals reporting status at standup
  • Individuals "waiting on each other" reported to managers
  • Managers asking individuals how "their work" is going
  • External agents (managers usually) citing and rewarding individual contribution
  • Force-ranking team members

Does It Matter? 

There are 5 absolutely-worded qualities here, and "development teams have the following characteristics" so clearly if those five are missing, then by definition it's not a scrum team. 

Of course, the scrum guide (2016 and prior) says: 

Scrum is free and offered in this Guide. Scrum’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.

Either these are things that together cannot be done (in which case scrum is a sham) or else these things are not being done (in which case the organization responsible for teaching and transitioning is failing miserably).  

Is there a another option? 


  • Possibly scrum doesn't really mean it in which scrum really is a sham. 
  • Perhaps people don't know how,  in which case the scrum organization is a failure (despite the monies collected, the number of organizations "adopting,"  and the number of persons certified). In this case, I suggest the certification money is being wasted.
  • Perhaps some people can do these, but most corporations cannot. Okay, then, say that scrum can't work in corporations. Then why are we seeing corporate "adoptions" listed as successes, and so many organizations accepting the money to "install" (ew) or "transition" companies in which scrum cannot work? 

So, scrum is an evil money-making scheme with no goal other than lining the pockets of trainers and coaches? 


No. At least one more possibility exists that isn't mentioned in the Does It Matter section. 

Perhaps we are looking at transition, and seeing state. 

This sound reasonable to me. I don't think all scrum coaches and trainers are scam artists. I know a lot of them and they're pretty decent people trying to make a difference in a complicated and chaotic world.

There aren't many corporate scrum teams yet.  

The five qualities of a scrum team listed above are completely out of bounds for traditional organizations where the management teams work in a very industrial-age way, and the HR systems are more appropriate to mechanical workers than to knowledge workers. The system as described requires more permission, trust, and safety than they know how to give (so far). Their world has not yet climbed the Satir Change Curve, and so we're seeing them all in "chaos" and not in "new status quo."


It is hard -- potentially impossible --  to reach the described state of grace using scrum alone. 

I think that the thing missing, and necessary for corporate teams is that set of values known as Modern AgileThe organization must reorient to focus on safety, alignment with the success of others, continuous learning, and continuous delivery.

These are similar to the values we find in XP, and maybe one of the reasons that "hyper-productive scrum teams" are teams that actually use XP practices.

I think that this goes past practices, though. It goes to a mindset of permission, trust, and safety that most large organizations find comfortable.  

Without going to the Modern Agile values, I don't know that organizations will be able to ever have real scrum teams. 

By focusing on Modern Agile values, though, I think any organization can easily surpass the level to which expertly-led scrum can take them. We'll see. 


Wednesday, July 12, 2017

Agile Training Roller Coaster

A long time ago, I was in a company that (like my current company) was known for training and coaching agile teams.

Some of our customers were continually asking us if we could double the class size so more people could sit in. Others were asking us to deliver the same content in half the time. Some were asking for both. Some didn't stop at "double" or "half."

As we discussed more and more people getting less and less exposure to the deep ideas behind Agile methods (and XP technical practices in particular) my imagination got the best of me and I giggled.

I was imaging a line of people on some kind of a conveyance, being carried past inspirational posters with agile slogans and images on them. Maybe something colorful like this (one of my favorites) Modern Agile wheel:


Maybe something particularly clever and memorable from our Industrial Logic collection:




Maybe like this one from acm-software:



I initially thought of it as a moving sidewalk or an escalator.

But then I realized that it wouldn't be that much fun to be slowly carried past display posters, and we could get a lot more takers if it was a thrill ride.

So in my mind formed the idea of an agile training roller coaster.




Onto the side rails of the tracks, arms would be fitted carrying slogans like:

  • "The team has all the skills"
  • "Teams self-organize!"
  • "Code should always be runnable!"
  • "Red, Green, Refactor, Integrate!"
The idea is so ludicrous!
When I shared it my colleagues laughed with me (I think it was with me).

Now it's a decade or two later and still people want shallower contact with ideas for larger and larger groups of people.

So here we could put 40 people on a train. We run 3 trains so one is loading while two are running.  If it's a 2 minute track, probably a train a minute or so.

When they get off the train, they go to the photo booth to get the photo of them looking all freaked out on the big hill, along with a certificate of training, a discount coupon for a repeat ride, and a notice that they have to come back for recertification next year when we change out a couple of the posters.

I'm considering that this might be an improvement over the two-day scrum class. You wouldn't learn much less and it might be a lot more fun. Heck, you might ride it two or three times. 

It might be a simplification of Agile In A Flash, even.

Judging from what I hear from trainers, it would be a big hit.

Of course, if it is that hard to get people away from work for training, the alternative is to train while working, something along the lines of a coaching engagement or a real-work workshop.

But if someone wants to fund the coaster, we should talk.


Thursday, July 6, 2017

A Surprising Demotivator

I almost took the elevator up to my room today.

A year or two ago, my wife bought me one of those step-counting devices, you know the ones which tell you how many steps you've taken by counting your arm-swings (I think)?

If I remember correctly, I was pushing about 250 lbs body weight at the time. I might have been pushing over it a bit. Call me an over-achiever.

When I got my step counter, I started being more aware of my habits. I knew how sedentary I was. I knew my heart rate. I could see how badly I was sleeping. It is a great tool because it makes me aware of myself.

Along with that, I have had a few doctors, and so I have gotten some advice. I take as much as I know how and can stay mindful of, short of running or joining a gym. I'm just not a runner, and why should I join a gym when I'm never home to go there (or when I am, I have other things I need to do). Being a traveling consultant has its perks and struggles.

I walk more, I sometimes exercise, I try to be smarter with my food, all that.  I don't get my 10,000 steps in every day, but I get more of them than I used to. Some days I go well over, but most days I don't.

I've lost about 30 pounds of body weight. I need to lose about 10 more in the next couple of months. That's the background.

Today I glanced at the step-counter because it's also a watch. I was greeted by a message saying that my battery was dying. Since I use the fitness tool to measure my sleep cycles, I don't charge it overnight as I do with all my other electronics. I have to make an effort to charge it every 5 days or so. I forgot.

Then the step counter is dead.

I'm without a watch and have to use my cell phone or computer to tell time, but it's no big deal.

And here is the interesting bit: I get back from the office to the hotel, open the door and I have a choice of elevator or stairs. Normally, the non-answer is stairs. However, this time I automatically start toward the elevator instead.

Am I tired? No.

Am I carrying extra baggage so that I need to use the lift? No.

Are the stairs out of order? No.

Then why, oh why, would I move toward the elevator?


Because my fitbit is stopped.  The steps won't "count." 


Here we see the coercive nature of metrics. This isn't about bad management or numeric goals tied to pay or advancement.

This is a fact of the nature of having measurements.

When you are measured, you have an awareness that can be good for you. I lost weight and increased my activity and improved my sleep cycles.

But when you are measured, you do the things that score you points. I know that my goal is health and weight loss, but the measurements are surrogates for health, not health itself.

The measurement controls the behavior.  Do I need to stop losing weight just because the battery is drained? No, but since the steps and floors would not be counted to my benefit, I subliminally believed that the steps were not important.

We act for the benefit of the measurement alone.

This is the same risk we run with any kind of process metrics. When the metric becomes a target, it becomes a surrogate imperative.

There are few excuses more vacuous than "I can't take the stairs because my fitbit is dead."  It's dumb to me now. It was dumb when I first heard myself think it. It's ridiculous. No thinking person would fall into that trap!

And yet here we are.

Think about it. For good or ill, metrics will drive us to point-scoring and will discourage us from doing even beneficial things that "don't count."

It doesn't have to be a bad measurement to have that effect.

Will your improvements sustain beyond your focus on measuring them?

Will they really?


Thursday, June 22, 2017

The Genie Story

A clever man was crossing the ocean when his ship was capsized in a storm. He was the only survivor. Hungry, thirsty, and battered, he struggled to shore on a small island.

While searching for some form of sustenance, he instead comes across a bottle holding a genie. Thrilled by his fortune, he released the genie on the condition that the genie would grant him three wishes. The genie happily agreed.

"First," the clever man said, "I wish to have an infinite number of wishes!"

"Of course," replied the djinn, "you may wish anything you like from this day forth, at any time you like. That said, what other two wishes do you want me to grant you?"

The clever man frowned. Clearly the genie was as clever as himself. He would have to be careful indeed with his second wish.

"Well, then, I wish that you will grant me an infinite number of wishes!"

The genie frowned. "Sir, you have already asked for that and I have granted that you may have all the wishes you can wish. Now you have wasted this wish and have only one wish left."

The clever man realized that his phrasing was such that this was a reasonable interpretation and so he had in fact nearly outsmarted himself.

He exclaimed triumphantly "Then for my final wish, I wish that every time I make a wish, you will grant it for me."

The genie knew that he was cornered, and considered his next words carefully.

"It is done, as you ask. But sir, considering that you are a limited human and not a Djinn, consider this: all humans are prone to rash decisions, errors, and unintended consequences. Do you really want every whim granted as soon as it is spoken?"

The clever man paled, considering the many stories he's read about men who accomplished their dreams only to lose their families, their hearts, and their souls. Indeed, had he followed his own youthful dreams he would not have the career and reputation he was able to build opportunistically by relying on his cleverness and wisdom.

"No, friend genie, I would not wish that at all!"

The genie laughed "VERY WELL! With that fourth wish, I am no longer obligated. You have wished yourself out of wishes."

The clever man lowered his head.

The genie looked at the clever man and felt pity.

"You know, sir, you could have wished for rescue, or that your ship had not sunk and killed your fellow passengers. You could have wished for sustenance and health and company on this island. You could have wished yourself home. All these I would gladly have given you in exchange for my freedom.

"Sadly, as a clever man who loves his own cleverness, your heart's only desire was to outsmart a djinn."

And with that, the genie vanished. 

Tuesday, May 16, 2017

Making people do what we want...

Amitai Schlier and Ryan Ripley conducted a session at Big Apple Scrum Day entitled "the care and feeding of T-shaped people" which was essentially a panel discussion taking questions from the audience.

I have trouble shutting up. If you know me, you know what a struggle it is. Sometimes I have to sit on my hands to keep from over-participating in a conversation (metaphorically).

Here are the questions:

  1. How do we get a developer to try something new?
  2. How do you know if you've stopped growing?
  3. How do you convince management to agree with you?
  4. Is there a stigma against T-shaped people when it comes to hiring?
  5. How do you choose a subject to go in-depth on?
  6. How do you optimize your paint-brushed-ness?
  7. How do you get team members to share knowledge?
  8. How deep do you go before it's just self-serving?
  9. How do you get a whole team to work on something that's new to all of them?
  10. How do you convince people wide is as important as deep?
  11. How do you persuade someone to be on a team when they're not bought in?
  12. Who decides what people will go deep on?
  13. Is there still a role for job titles?
  14. How do we incorporate learning into a project?
  15. What to do when people don't appreciate T-ness?
  16. How to market oneself with T-shaped skills?

Notice the volume of "how do you make people do X" questions here.  Review 1, 3, 7, 9, 10, 11, 12, 15. Exactly half of the questions involve mechanisms for getting one's own way.

As I left this session, I was impressed with how well Ryan and Amitai handled the questions and the sincerity and authenticity involved across the board. 

But I was also a tad dismayed by the questions which were phrased in ways that implied argument, manipulation, or coercion. Think about that for a while. How many times have you heard accusations that coaches and Scrum Masters are manipulators and scammers?  I wonder if our concern with getting our way (for "their own good", of course) has created a group of people with more psychological tricks and traps than they should be trusted with?

I want to address the questions and give some answers in coming weeks. 

Stay tuned.


Friday, May 12, 2017

Calibrate Your Dopplegangers

Haunted? 


I once knew a woman who confided that she lived with the disapproving, exhausting ghost of her long-dead mother. It was a disembodied voice in her head that wouldn't let her go to bed without the house in perfect order. All dishes, dusting, sweeping, tidying had to be done or this "spirit" would not let her rest. In fact, she confided that she didn't enjoy doing any of these things; it was a constant fear of disappointing her mother that drove her frantically through endless, joyless chores.

In a rather different vein, a friend of mine tells me that whenever he even considered any misbehavior he would hear the voice of his saintly grandmother, who he loved, reminding him that he knew better than to get involved with anything shady or "wrong." Rather than being tortured by this constant presence, he was comforted and aided by it. Occasionally, it was inconvenient, but honoring his grandmother was a pleasant and rewarding behavior he willingly engaged in.

In folklore, a doppelganger is a kind of ghost or spirit that takes the appearance of a living person: a kind of evil twin.

I don't believe that the spirits of the departed walk the earth and torment (or augment) the living.  I use the concept of haunting as a metaphor only.

I have noticed that the memories we have of interactions with others (living or dead) tend to form a kind of simulated model of that person in our memory.

I use the term "doppelganger" to refer to our mental model of other humans.

Protective models


I have read that one of the features of intelligence is the kind of imagination that allows you to simulate real-world interactions and operations. I don't recall the source, but I think it was in the context of animals using tools and solving problems and the apparently wrong opinion we once had that this use of imagination was the unique capability of human beings (what "separates us from the animals"). We've since found that animals may also have the same ability.

As a child, you probably had a mental model of a parent or guardian. This model was constructed of your memories of prior interactions and conversations. When you considered asking for permission to do a thing, you ran it past your mental model first. If your mental model refused, then you may not have made the request of your actual parent.

Have you ever rehearsed an argument? Most people have had long simulated imaginary arguments with a friend or loved one. If your imaginary argument with the doppelganger was successful, you were emboldened to have a real argument with the real loved one.

These doppelgangers are generally more harsh, disapproving, and difficult than the real people they simulate. I suspect that this is because the doppelganger is a protective model.

The doppelganger predicts other people's responses (based on our understanding of those people). This keeps us from crossing boundaries or interacting in a way that will be uncomfortable for ourselves and others.

Ideally, the doppelganger in our head is a social crash-test-dummy.

Once I became aware of the phenomenon, I discussed it with some of my friends and peers to see if they experienced the whole doppelganger experience in a similar way. This discussion opened up stories that none of us had told the others before.

At this time, I have little but observation (and possibly observational comedy) to go from. I would appreciate any links to articles, papers, or official psychological studies of the phenomenon.


The phone call


I recall one time when a boss of mine called me on the phone.

My inner boss-doppelganger was calling to give me a hard time, to relentlessly press me to do additional work or to be busier. I would have to give an account of everything I've been doing and explain why I was overwrought with my current level of effort and how little I understand of some of the things I'm asked to do. I would be called to account for everything not finished. I would be disrespected for my lack of knowledge/skill in some areas.

It would almost certainly be a negative experience I was not ready to have. I found myself considering what excuses I might offer later for not answering the phone now.

I realized that this was no way for an employee to behave. Hiding is not only a poor relational tactic, it is a kind of cowardice.

It was also unfair and unkind. If our positions were reversed and I was the boss, I would not want my people to avoid me.

I picked up the phone.

It was that employer telling me of a wonderful opportunity that has arisen which his internal doppelganger-tim told him I would enjoy.

His doppelganger-tim was a higher fidelity model than my doppelganger-boss.

The doppelganger I was listening to was not protecting me. It was robbing me of the joy of interacting wholeheartedly with the real person.

It was like an evil spirit haunting a crucial relationship in my life.

I recalled the woman I mentioned in the first paragraph above. I still wonder how supportive, accepting, and loving her real mother was compared to the doppelganger-mother she dreads so much.

Maybe we all have some doppelgangers to recalibrate.

Nicer in Real Life


I met some online acquaintances in real life (IRL). I remember hanging out for an hour or so when one of them told me that I seem surly and disapproving online but in person, I was (surprisingly) "charming and positive."

I later took a look through my past postings/tweets with an eye to understanding what social hints were built into my online persona. I saw how people who did not know me personally could easily have constructed an unpleasant Doppelganger Tim.

How fascinating!

Later on, I was having a voice-only conference call when one of my peers suggested a course of action and immediately warned us that he could see his "inner Tim" shaking his head and tsk-tsking.

This surprised me because I was enthusiastic about the suggestion.

This was a new revelation to me. Not only do we sometimes have miscalibrated doppelgangers, sometimes we unintentionally construct disapproving doppelgangers in the minds of the people around us.

A few other interactions, including a meaningful one with Christopher Avery in email, confirmed this revelation.

I can take responsibility for the image others have of me. Their doppelganger is built from memories of my interactions with them.

I learned that I can interact intentionally in such a way as to build a more true-to-life model for others. It helped me to express myself more authentically.

It's a journey, but early results are good.

Awareness, Curiosity, Appreciation, Responsibility


We could go to judgment and chide others for having fake mental models or being too hard on each other, but there's not much value in that.

It is clear that many (perhaps all) of us have protective mental models of people we know. Trying to not have those models is difficult.

It is equally clear that others have mental models of us, which may also be miscalibrated.

Where does that leave us, and how can we improve our experience?

I can intentionally recalibrate my doppelgangers by having more probing interactions with real people. By allowing myself to be curious about their motivations instead of assuming certain personality traits, I can allow the real people to speak for themselves. What I learn from the real interaction calibrates the doppelganger.

I can also try to inform other people's inner doppelganger-Tim so that they know what to really expect of me, especially to be sure they know what brings me great joy.

And it might be freeing to know that the troublesome spirits who haunt and torture our days are not entirely real, but a product of our own memory and imagination.

How we respond to our doppelgangers is as much a choice as how we respond to other people.  We can take responsibility.



Sunday, March 12, 2017

Make People Awesome? Give Them Superpowers!





We need to explain our primary statement of benevolence, expressed as "make people awesome." This is intended to express that have an explicit goal of benefitting specific others with all of our work.

I have had so many apologetic conversations about the term, and it's been described in several articles (some well, some rather poorly).

The message is singularly hard to express, at least in a form that fits on the sticker.

Admittedly, it's 2017. Everyone is on high alert, and words trigger people in dozens of interesting ways.

To date, the primary triggers are:
  1. "make people" - which tends to be heard as "coerce, demand, or force"
  2. "awesome" - which tends to be heard as "valley girl talk", indicating the speaker is bubble-headed or shallow.  

In any longer discussion, we eventually get around to Kathy Sierra's book.  "Badass: Making Users Awesome"  which was one of Josh's inspirations.  There were a few tailorings going on, but the idea was here.

We don't say "badass" because that, by itself, is sometimes used to describe someone who is forceful and violent.  I'd be surprised if Kathy S. has not had many clarifying discussions over that misinterpretation.

We also don't say "users" in our little slogan. We believe in an overarching benevolence.  We want to make users "awesome" of course, but we also want that benevolence to extend to our teammates, managers, support people, DevOps, QA, sales. We want it to extend to our customers' customers.

Some people take "make people awesome" to be a demand that managers of development teams behave a certain way toward their teams. We're not excluding that message, but suggestions that we change it to something like "get out of your team's way" restricts the message to micromanagers only, and not benevolence to all our community.

Sadly, some people take the whole statement to mean "demand that other people behave in a way that you see as awesome" -- very far from what we intend. We would have said "demand awesomeness from others" if we meant that.

Likewise "be kind" doesn't cover it.  We are not trying to "just be nice" but rather to give the people we deal with an extra measure of capability, awareness, competence, and power. We want them to be, properly "awe-inspiring" to the people they work and live around.

And now I've tripped over "awesome" at least twice.

Let me explain.  I found an old article I wrote describing software as super-powers.

The idea is that there are systems that help doctors avoid drug interactions while they are in the act of prescribing drugs. This has had a huge impact on the world. Patients have fewer complications, doctors have fewer lawsuits, hospitals have less workload due to drug interactions. Compared to pre-software-assist, doctors are impressively aware of interactions and up-to-date with new alerts because of software. That software is "making them awesome" in some regards.

The idea of making people awesome is just that - always be looking for ways to multiply other people's ability to be successful in their endeavors.

It doesn't matter if they're coding, testing, managing, performing medical services, nursing, hosting parties, supporting software systems, installing cable TV, cooking dinner, or editing podcasts. We can always be looking to "make people awesome" at the things they do for others.

I don't know that we'll always hold to the current phrasing. I would be okay with finding another way to say this that also fits on stickers and is easily memorable. In most ways, the current phrasing is fine, if only there weren't so many triggers to trip.