Monday, December 11, 2017

Feeling Safe?

I finally got around to watching Frozen

I don't have any small children of my own and wasn't really interested in it for my own viewing pleasure, so it took a long time. I didn't know the songs, didn't know the characters, didn't know the storyline.

We were watching a friends' child last weekend, and the child really wanted to see Frozen, so we did.

Overall, it's cute and has nice jokes and beautiful animation. I can tell they spent a lot of money on the soundtrack. I probably won't watch it again, being well outside of the target audience.

There was one poignant moment that stood out to me, though.  Anna, the red-headed sister of magical-powered Elsa, came to retrieve her (very dangerous) sister and bring her back to their town. 

Elsa warned Anna that she was a danger to everyone. Anna said:
You don't have to protect me; I'm not afraid. 

Boom. That line.


Feeling v. Being


It dawned on me that Anna thinks that feeling unsafe is the thing; actually being unsafe doesn't occur to her.

She's focused on the feeling instead of the reality.

When we say "make safety a prerequisite", people think we mean "feeling safe and unthreatened" which is not what I mean. 


  • Fragile people can remain fragile in a confrontation-free space, but this doesn't make them safer.
  • Hiding problems can keep people from feeling afraid, but transparency gives them the ability to solve problems.
  • Brutish people can "feel safer" when they're allowed to run roughshod over others, but this does not make the group safer. 
There is more to this than feelings.

Likewise, when we say "make people awesome," some people think we mean "make people feel really great" instead of "give people the ability to do great things."  I mean the latter. If I meant "make people feel great" I would say "make people feel awesome" and would not bother with actually creating any enablement. Feelings matter, but there is more to this than feelings.

What Timing!


As I was pondering the Anna's "not needing protection" Elsa deals Anna a mortal blow which in time may well kill her.

Oh, so much for not needing protection.

Eventually, Anna is frozen solid, essentially dead. This being a Disney movie, she's restored to normal state and all is well at the end.

I wish it were the same for people who "feel safe" weaving through traffic on a motorcycle at 120mph with no helmet, or those who "feel safe" working with homemade explosives or modified firearms.

What Are We Really Doing?


The ideas of "make people awesome" and "make safety a prerequisite" are too important to me to have them confused and conflated with imparting (potentially deceptive) feelings of awesomeness and safety.

If we aren't enabling greater accomplishment and reducing potential damage, then what are we doing? Just playing with people's feelings? 

Monday, November 27, 2017

Taking Breaks in a Disciplined Way

I worked with a team where everyone was trying to do pair-programming, but it was too hard for them.

I asked what made it so hard, and they told me it was simply so exhausting. They were slumping in their seats by 10:30 in the morning, and by mid-afternoon, their productivity had plummeted.

I looked around the room to see if everyone had the same experience. They all nodded their heads. This was the big problem that was plaguing them.

I asked them how they were doing the pairing. They were forming up in pairs, and working all morning straight through without break. They went to lunch, and after lunch rejoined their partner and worked until quitting time.

They really were sticking with the pairing, and I had to admire their dedication. They were working so hard to try to build great software and working so hard at pairing that I was deeply touched.
But here is the problem, too.  They were working too hard at it to be able to do it well.

Biological Beings



We are biological beings. We're neither machines nor creatures of pure will and thought. We have human bodies housing human brains, and there are biological needs beyond mere nutrition, respiration, and elimination.

Thomas Davenport described "knowledge workers" as a people who "primarily rely on their brains rather than their bodies in [doing] their jobs."  Developers, testers, managers, service, support, finance, sales ... most people in the software trade are knowledge workers by this definition.

We, as a species, have uniquely large brains. It's said that 20% of our daily calories are burned in the brain, not in the muscles or other organs. That's one expensive organ.  Knowledge workers tax that organ more than most laborers.

That organ is biological, not mechanical. We can either try to work with the biology of that organ, or we can be subject to the weaknesses and frailty of the organ itself.

We have decades of people working hard to improve focus and extend the time that one can focus. We know that distractions are annoying and disrupt our train of thought. We are aware of the costs of multitasking, and especially of processing low-value interrupts (such as most notifications from social media and a lot of our low-business-value conversations). We have learned to hyper-focus on one topic for extended periods.

As reasonable as this sounds,  a number of recent studies have concluded (as Graham Wallas hypothesized in 1926) that a brain works better if it has some distracted time so that it may "incubate" ideas while doing other things.

Srini Pillay said in May 2017's issue of Harvard Business Review that a brain can take only so much focus. Excessive focus, he says, exhausts the focus circuits in your brain, draining your energy, making you more impulsive and less helpful.  His article states that the brain operates best when it toggles between focus and unfocus (which I call "the prairie dog brain").


Prairie dogs poke their heads up out of their dens from time to time to check for predators or opportunities in their environment. They don't stay buried all day long.

My Prairie Dog Brain likes to (figuratively) pop its head up and sniff the air for interesting opportunities or threats in the environment. Rather than being hyperfocused all day, I need to seek the occasional distraction in order to do my best work.

In his book Tinker, Dabble, Doodle, Try, Pillay relates the story of one of his hospital supervisors telling him that "taking breaks to allow thought to congeal is one of the most important aspects of a true education."

The Water Analogy


Consider, as an analogy, hydration on a long-distance hike.

You will naturally lose water to breathing, perspiration, etc. You will run low on water if you don't replenish.

When you are dehydrated, your performance will suffer and your being may take damage. In severe cases, your body may fail entirely.

It is recommended that you drink water to avoid dehydration (and alternate with sports drinks to avoid hyponatremia) on your trip.

Some sources recommend a cup of water every 15 minutes if you're on an endurance walk.

That is considerably more than if you're sitting at home watching TV.

When you are working with your brain all day long, you are doing some "endurance thinking."

The brain has a "normal" attention span of about 20 minutes, and yet people struggle to keep it focused on the work at hand for hours.

Just as a hiker needs to drink water frequently, you will need to refresh your brain periodically.

Rather than taking breaks because we are tired, we take breaks so that we do not become tired.

If we allow ourselves to become tired, then we will need longer breaks to recover, and will work less well before and after the breaks.
Just as you might have to drink when not thirsty, you will need to take a break when not exhausted.

Disciplined Break Taking emerges



A past mentor of mine was famous for an interesting trick: when teaching a week-long event, he gave the class a ten-minute break every hour.  The team was able to work on their individual projects and assimilate new ideas much faster.

This worked nicely and had a good rhythm to it.

Around this time, I also read an article by John Richardson on "The Power of 48 Minutes" in which Don Crowther claimed that he could achieve and sustain a state of flow more quickly and predictably if he worked 48 minutes without distraction, and then took an (obscenely long) 12-minute break. Since then he has reduced his break to 10 minutes.

... 48 minutes is the magic number. Here’s how it works… Set a timer for 48 minutes. Close out all distractions and work continuously for 48 minutes. When the timer goes off, get up and stretch, get coffee, use the restroom, etc, in the following 12 minutes. Repeat as necessary.

Around the same time period, the Pomodoro Technique emerged and became popular. In the Pomodoro method, you work for 25 minutes and take a 5-minute break, which lands you at about 50 minutes of work per hour.

 
The Pomodoro technique is named for a tomato-shaped timer used by Francesco Cirillo when he formed the original concept.

The Pomodoro technique has been fine-tuned since the late 1980s and is a popular and widely respected way to maximize productivity.

This seems to be a pattern to the 50-minute hour.


The story continues (and concludes)



The team I spoke of at the top of the blog post were exhausted every day, for most of the day.

I didn't have Disciplined Breaks worked out then, but I knew about Pomodoros. I set up a timer, and we used 25/5 "standard" Pomodoros.

Success! The team completed the work planned for a full day before noon. Pretty impressive! We had 100% increase in productivity immediately.

By mid-morning one of the team members had mentioned that they weren't tired and didn't need a break. At that point, we reminded them that we don't take breaks because we are tired, we take breaks so that we are never tired.

The team member took the break, as we all did.

By mid-afternoon, the team had accomplished the following day's work.  They had completed two days' work in 75% of one day! I realized that exhaustion was the team's biggest problem (as they assured me it was in the morning coaching session).  I felt elated.

However, part-way through the next break, a manager addressed the team and said "are you all goofing off again? Already?"

The team's enthusiasm drained out of them. Their eyes went to the floor. They ducked their heads and mumbled, "I'm not going to take this break, I'll just work through it."

To the best of my knowledge, that team never again took a break during their workday. They may never have had a boost in productivity like that again.  I hope that they eventually negotiated a break-taking schedule with their managers. I just don't know.

If you are coaching or managing a team, then you probably should repeat my success and avoid my failure.

I've since had many successes with other teams. I have learned my lesson and work more closely with the team managers when possible.

Rules of Disciplined Break-Taking



Break taking is not a very complicated idea, but in order to fit it into a business context, we find that we need to surround it with some very special rules.

There is a perception problem with breaks. Managers can see people not working, fear for lost productivity, and demand that they return to work. From the information given so far in this blog post and your personal history, you can see that breaks will increase productivity if they are done correctly and the managers will allow it.

In order to make this a safe experiment for others to try, I added some rules and have tuned them for about a year. Disciplined Breaks is the best set of rules I've used personally and have shared with teams.

Work out the experiment with the team's boss if necessary. If not, then please freely take and use these rules. Expand them for your own context, or simply use the Pomodoro Technique.

Disciplined break-taking is, as I've defined it so far:




  1. Schedule it.
    If you don't schedule the break, you'll not notice it's time and you'll skip it.
    You'll end up tired and will need a longer break to recover. 
  2. Leave the area
    Don't stay seated in front of your computer. Get out of the cubicle, the room, the space you're working in. Move. If you stay, you won't really take a break.
  3. Attend to Biology
    Yes, this includes the obvious reason people often take breaks, but also consider getting a drink of water or a healthy snack. Keep your biology in a brain-supporting state. 
  4. Change Something
    Change your focal length (look out a window), change the atmosphere (go outside), change your state of mind (rest, meditate), change company (call home). Do something non-work like so that you can tolerate being away for 10 minutes.
  5. Return Promptly
    The major reason managers fear letting teams take breaks is that once you let people go, you don't know how soon you can get them back. Whether using Disciplined Breaks (this method) or Pomodoro, or any other method you will need to be trustworthy and not leave your work for "too long."
    I recommend setting a timer on your phone or smart watch for 8 minutes so it will remind you to come back on time.

There are immediate and significant gains possible through disciplined break taking.

Please give it a one-week or a one-sprint try. You will be surprised how well you can perform when you are working with biology, and not against it.

After all, we're not machines.



Tuesday, September 26, 2017

Why TDD?


Why do we care if people call what they're doing TDD or BDD or why do we care if they actually do it?

Saying It


When people mislabel what they’re doing and refer to it as “BDD” or “TDD” or “Scrum” or “Agile” when it isn't, it screws up all the conversations that follow until we manage to unravel that they’re really just doing automated testing, or iterations, or what-have-you.

Clarity in a conversation has the same value as clarity in code, and maybe more so.

Someone told me that they were doing TDD, and we were well into the conversation before I realized that everything I had said for several minutes had been totally misconstrued.

What they thought was TDD was “holding a testing sprint before release”

So, the value in crisp terminology is improved communication.

What is the value proposition for misusing terms?

I guess some people — even in the agile world — don’t know that TDD and BDD are processes, not artifacts or tools; and that neither is just another name for “automated testing.”

You’d think we all know better, but no.


Why does TDD beat just writing tests after using test-coverage tool?


It doesn't have to be TDD, you know. Cope says he can get equivalent results using DbC, and Cope isn’t given to making such statements lightly. So there are different ways to get similar results (it seems).

If you find other ways of achieving the same goals (or over-achieving by also solving other goals) then, by all means, teach me what you learn.

Of course, you can use test coverage tools with TDD, so really having the coverage tool is a wash. There is nothing about TDD that forbids having measurement.

Let's stick to TDD v. Test-After for a moment:

  • It brings testing across the RW/BS line. Test-after tends to live on the BS side, even though we like to think it doesn’t.
  • It begins with the developer as a user of a class/function and ends up with the developer as an implementer.
  • It keeps the code runnable at all times, since you can't have the code "up on blocks" for hours at a time and run the tests.
  • The feedback loops are hella fast. You know that everything was fine 10 seconds ago, and you’ve only written two lines of code and now it’s broken.


Typically, the code is written (as an implementor) so it has an inside-out API. You get the algorithm right, and then you expose the variables via some function calls and make sure that it does its job. This can be complicated in some cases, so the code that I'm typing at 14:30 may have been typed into code that was last run yesterday. Or the day before. If I'm writing it all in one go, I don't have to keep it runnable. After all, I only need it to work when it's done.

And then it’s done. Well, you know, other than tests.

The code could conceivably be shipped, and the author has checked and double-checked it on the fly. We've had the debugger out to fix some problems so we know it works.

Still, the Powers That Be say there have to be automated tests. So there is an immediate emotional foot-dragging and obligatory feel to the work, but we’re professionals so we push through…

 … and then we see that to test some variation, we would have to change the code. That’s one thing when it’s being written, but dammit the code is done and I don’t want to change it just to make the tests pass; how much do I need this test? This is another source of emotional foot-dragging and obligation. Maybe we push through that and change the code or write a complicated test.

… and writing the test we see that it’s a pain to pass all these parameters. It’s a little ticklish because there are 3 integers in the parameter list in a row so it’s easy to get the wrong value in the wrong place. OTOH, the code is done and changing the interface will mean changing the finished code and all the tests. Emotional foot-dragging kicks in. Can we just leave it the way it is? Note that in TDD we would be faced with this decision repeatedly, increasing the likelihood that we would revise the interface for safety's sake.

There are other points of friction. While there should logically be NO DIFFERENCE in doing test-after instead of test-before, it somehow just never turns out that way.

The only thing that test-after ensures is that there are tests; one of the less interesting side-effects of TDD. TDD isn’t about writing tests; it’s about driving the development of code in a special way with the side-effect that there is pretty good test coverage at the end.

Don't take my word for it.


Anyone is welcome to try an experiment.

If you are not sure that TDD makes any sense, or that it's effective, then try doing TDD for two weeks and then doing test-after for two weeks and evaluate the quality of the code and the quality of the tests and the quality of the experience.

  • Is the non-TDD way as safe? 
  • Is the code as frequently runnable and integrated?
  • Is the feedback as fast? 
  • Does it result in as good a code interface? 
  • Does it feel like the testing is a natural part of the work flow? 
  • Does it lend to refactoring as easily? 
  • Is the code just as good (accurate, simple, clear)?
  • What other benefits do you get from the non-TDD method? 

And don't just limit that to test-after. There are probably better ways than TDD, and we'll find them by going forward. Likely the answer is not "just don't do it" but in doing something even more simple, valuable, and profound in its place.

FIND THAT BETTER WAY!

And then come here and post a link to what you've learned. I'm all ears!

Monday, September 18, 2017

The 5 Ts

When I'm talking to Agile teams, we often talk about the role of management: whether it exists, and if so what it is.

I always fall back to the principles of the agile manifesto:

Business people and developers must work
together daily throughout the project.
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.


Of course, there is more to it than that in an organization. If we were, as some suggest, to get rid of the managers someone would have to assume the duties that managers actually fill in organizations. It's possible via holocracy and sociocracy to do such a thing, but what would it mean?

I like managers.  I love leaders, I have some issue sometimes with bosses, but I like managers. I like having them. I have enjoyed being one. I even like administrators.

In my mind, managers are people who are trusted to care for, spend, and attend to certain aspects of the work which I call the 5 Ts.
  • Time
  • Talent
  • Target
  • Treasury
  • Trust
Let's take them in turn:

Time


Organizations tend to have schedules. Some of these are full of events (trade shows for example), promised events, holidays, vacations, etc. 

A manager will help a team by keeping track of the schedule and helping the team ensure that they deliver the best value they can prior to the event, even if that means getting their code & tests reviewed and checked in and their expense reports filed before going on vacation.

If one intends to change a delivery date, it is likely going to require a manager who knows how to navigate the organization and its many dependent interrelationships in order to make a successful change. 

In small or informal organizations, and especially those practicing Continuous Delivery, a lot of hassle goes out of the schedule, but it is good to have a way of keeping the team free of hassles with regards to the organization's calendar. 

Sometimes keeping track of time and preparing for near-future events is more than we can do while we're in the midst of development work, interpersonal crises, learning, and the like. Having at least one person whose focus on the corporate calendar isn't compromised by hyperfocus can be valuable.


Talent



Are teams are made of people; our work is made of thinking; our dependencies are on other people.

Working with great people is a considerable benefit.

Managers are traditionally in charge of the headcount and composition of a team, the work of hiring and firing, and the budget for training and acquiring thought leadership. Other than recommending outside people for job interviews most team members have little influence over the who they work with.

It is not impossible for a team to take care of such things. There are systems where the teams seem to do this well.

However, there are tricky areas of dealing with accidental bias and legalities and such. Sometimes we need people to be trained in the procedures of hiring and releasing team members so that these things can either be avoided or done correctly. It's complicated.

Many people working "in the trenches" don't want to deal with the interpersonal strain involved with personnel changes, nor the work of planning scheduling training. They prefer leaving those jobs to people who are more comfortable with the tasks of scheduling and planning.

Target



Who decides what will be done and what will absolutely not be done in an organization? 

It is typically managers and the process usually involves determining priorities, setting up budgets, and pre-determining appropriate times for review and assessment.

While teams are formed to do the work on projects and products, the choice of products and projects usually falls to a management team. Often the overall direction for the organization is set by an executive team along with advisors. This is a process that is (sometimes overly) complicated and time-consuming. If it were possible to not do it, many organizations would gladly skip it.

Again, it is not impossible for a team to take on more of this work, but when it is time to ramp up a promising project or shut down one that heartbreakingly did not find a market, it tends to be the work of managers to justify the cases, plan the transition, and eventually declare the thing done.

Treasury


Most of us have been at the point in a project where the thing the team most needed was another computer, or another virtual machine in the cloud, or a license for a tool.  Standing desks? Extra monitors? A more reliable network? A change of version control system? 

It's possible that the team needed some training, possibly a visit from a consultant or specialist. 

It didn't have to be something large and expensive. Maybe it was index cards, adhesive flipchart pads, and sharpie markers. Maybe donuts & coffee to compensate for some early meeting would have been handy.

Typically, the ability to spend money is granted to managers, and only through delegation to non-management types. While it is obvious of large expenses, this hierarchical function is true of money in surprisingly small amounts. Some organizations require sign-off on all expenses over USD$25.00.

Whether it's trivial or considerable, the access to the treasury (and the skill to make a case for the expenditure) often falls on someone in a management position. 

Trust


The other Ts are important. Sometimes they're crucial. However, this one is key. 

A team is given a goal, and some discretionary space (volition, control, etc) to get a job done.  That discretionary space consists of trust, permission, support, and time. 

Within the space, the team can do the work in the way that seems appropriate to them, within known constraints. They can self-teach, peer-teach, and can develop automation and tooling that will increase their speed and accuracy. They can develop their skills and their work system, and improve their working relationships as well. They will experiment with technique and technology.

The more space they are given, the more abuse potential exists. What if they do the wrong things? What if they aren't improving the code in the way we want them to? What if they don't get it done? What if they end up working against the company's goals?

The fear of workers abuse of their time, especially where schedules and budgets are tight, is such a powerful force that many managers give their development teams almost no discretionary space at all. They "clamp down" and monitor the busyness of the team, and hold their "feet to the fire" and their "noses to the grindstone" so that nothing can be done that wasn't approved and assigned. 

As a result, an under-trusted team does not communicate well, does not share work, does not engage in peer-teaching or peer-improving activities, does not automate wasteful processes, and does not improve either their speed of delivery or their quality. They become resentful. They become obstinate. They lose touch with the "true-north values" of the organization.

All the best things happen IFF trust is given, but giving trust appropriately is a skill.

There is a very careful, incremental, crucial dance here; creating alignment and then following up by giving the right degree of trust in the right area, and supporting it so that teams can be increasingly engaged and effective.

Can teams work effectively and in a trustworthy way without managers supporting, aligning, and facilitating the process? Maybe. Probably. Sometimes. "It Depends."

Are Managers Strictly Necessary?

There are other models in the world of Sociocracy,  Participation Age, Dynamic Governance, Hierarchy-less, we find that the title of manager may be unnecessary (strictly speaking), but somehow these 5 Ts are crucial. Whether one is at Morning Star, Zappos, Valve, 37Signals, WL Gore or any of the dozens of other managerless operations, it is still important that these 5T management concerns are handled in some way.

Most of the organizations I come in contact (not all!) tend to concentrate these functions in the hierarchy (or web) of people who are professional managers and who are formally or informally trained to handle these responsibilities.

Most of the time, workers in the company are happy to have these tasks concentrated in managers. It saves them effort and distraction.

What Do I Do With The 5Ts?


Workers are slow to engage their managers even on issues that involve the 5Ts.

If we can make people more aware of the 5Ts, then we can help them to engage their managers on the topics for which their managers have the most influence and discretion. It's my hope that we can learn to classify our work into either "a management problem" or "a technical problem" and thereby become more efficient and more effective in how we engage with our managers.



Friday, August 18, 2017

Can We Process Our Hurts Without Going To Categories?

It Begins As A Reaction


People who are hurt and angry sometimes give in to two unproductive natural urges:
  1. Hurt the other back so they'll think twice next time
  2. Disconnect oneself from the other to build distance emotionally 

Maybe it's these two urges together that drive people to go to categories instead of keeping the context of an interpersonal struggle between two people.
It leads to using pejoratives related to the other's race, gender, age, sexuality, religion, etc, probably because these are known sore points, probably because they are shocking (and so speak to pain), and probably because they also leave the other categorized as 'less than'. It satisfies both urges.
We don't have to give in to those twin urges. 
Most of us have given in at some point in our past. 
When I look back far enough into my past I can dredge up an example or two. I would like to make excuses, but I know it was ignorance and willfulness and that I knew it was wrong at the time.  No "get out of jail free" card for my past. 

It All Looks The Same From The Outside

It is deucedly hard to tell an angry retort from a real, deeply-held "ism" like those we see playing out in the world this year.
Does the epithet reveal one as a bigot/chauvinist/racist or does it only show that they the person knows how badly bigotry, chauvinism, and racism hurt?
When one does go to categories, to the person receiving the epithet and to everyone else listening, it looks like act of true, chronic, systemic, heartfelt bias.
This breaks off relationships with people who don't share that bias.
Worse, it draws people who do.
To someone who truly carries the "ism," hearing it spoken is an encouragement. It builds their sense that "we're all thinking it" and that other people simply "lack the courage to say it out loud."  It tells them that they are among kindred spirits. It emboldens them.
It is likely that the one speaking neither truly intended to cause permanent damage, nor intended to incite others to violence, nor intended to reinforce systematic suppression or dehumanization of others.
And yet, the consequences and appearances are the same.

We Can Do Better


We need to find new ways to process hurts.
We truly need to relate to other humans as individuals, even and especially when we are hurt. 
This is necessary if we want to see a decline in the normalization of racism and hatred.
Maybe we can redirect others from categories to a human connection and a human context when it happens, maybe others can redirect us if (God forbid) it happens with us. 
It doesn't mean that we give in to others who are hurtful, but that we don't go to war with them in a way that damages us in the eyes of others, calls up deep hurts in others that we can't really appreciate, and encourages the worst biases and behaviors in our fellow humans.
It means that we keep our personal business and our personal upset on a level where we can either resolve it, fight about it, or leave it where it is, rather than escalating to battles of categories where it is (seemingly) unsolvable.
Going to categories is trouble. 

A small start

I have a small and simple idea. You can memorize it. I can probably fit it on a sticker. It's a promise to myself and to my friends and to strangers. It's not much, but if we start here, maybe the idea can go much further and deeper into the world. I don't pretend it will fix deep schisms, but after all peace begins inside us so the first "fix" has to be in our own hearts and minds. 

Here is my pledge:

Expect respect from me.
If you don't see it, then help me. 
We can do better.

Tuesday, August 15, 2017

A VERY brief note on certification..

I'm well-known for my distaste of certifications for software developers, trainers, and coaches.

What seems to be less-well-known is the reasoning behind that.

GETTING certifications is not the big problem.
  • I do not seek or accept certifications, but it's not because owning them is evil. 
  • Yes, a certification is a proxy for a reputation. 
  • Yes, I value reputation greatly and certification almost not at all.
  • No, it's not because the certifications are too easy to acquire. 
  • No, having a body I trust more doing the certification would not help.
  • No, I don't want to certify people or back a certification.
  • No, I am absolutely not against education in any way, shape, or form. 

Vendor Distraction

My problem is that once you become a certifying body then certifying more people becomes an important part of the revenue stream. You want to do so profitably so certifying more trainers to sell more certificates becomes important. I believe that within 5 years serving the certification industry tends to become more important than serving the software industry.

The distraction is dangerous.

What makes the certifier successful is not what makes the industry successful. Brand X selling 10% more certifications doesn't make the customers who are actually using Brand X processes 1% more successful in their business.

We are supposed to be helping people solve their problems via software. Selling certificates won't necessarily help in that direction.

Ossification

Certification can't operate without standardization.

In a period of rapid transformation and growth, how reasonable is it to standardize?

If we're changing every year, should we standardize and therefore slow the rate of change, or should we wait and standardize once a single clear way of working is truly dominant and widely accepted?

I will argue that todays best practices may well be the antiquated flotsam of the past VERY soon. Perhaps in months, but certainly in years. Values may be settled, but this is the world of the web and of changing programming languages and market segments, Lean Startup, Devops, and CD. What made sense a year ago still needs to be revisited and revised.

I say this even though I observe XP technical practices have aged very gracefully indeed. Of course, there is no certification for those.

Bad Metrics

Having too difficult a certification becomes a problem because markets love success stories. How many millions have we certified? How many more people have been certified this year than last year? Are we having a banner growth year in our certification business?

People see the growth or decline of the training business as the indication of a growing or declining topic area. When we have a banner year, doesn't that mean our brand is having a banner year?  When we have a slowdown, doesn't that indicate our brand is dying off? For instance: Doesn't fewer Brand X certifications mean Brand X is dying? 

I think this is Goodhart's Law (and maybe Campbell's Law) at its worst.

Aging Materials

If certification can't freeze the march of time and change, then the materials are aging ungracefully and quietly in the background. There are financial reasons for certification-rot.

Certification isn't the most profitable business in the world. So, how much time and money should a certifying body invest in updating our materials every single year? Every quarter? Every month?

If a certifying body updates the materials, won't it require retraining or even (gasp) recertification of trainers? Won't it damage the value of certifications issued in the past?

Imagine that "You paid $2000.00 for a certificate last month. We regret to tell you that your certification will be deprecated as of the 12th of next month when the new training materials roll out. Thanks for doing business."

Is the reasonable approach, then, to not update the materials or to not deprecate obsolete certificates?

Which is more valuable to the certifier?
Which to the certified?
Which to the people who hire certified individuals?

Uncertain Recency

Staying with the theme of ossification and rapid change along with aging materials, let's assume an agile method called SACRUFE (invented here). Let's say that the method has several of years of use on it, and that there is a document that describes it's current state. Further let's assume that the document describing SACRUFE is updated periodically to keep it up-to-date.

Now, the problem is that you don't know if your materials are current or not. Even if they are, you probably don't know and have not asked.

On your certificate, does it say which version of the SACRUFE MANUAL was used in your training?

Were you certified in 2017 to be competent in the quintuply-replaced 2011 SACRUFE style?

What if your friends were certified in 2013 SACRUFE and you were certified in 2015.4 SACRUFE method? Aren't they carrying the same certification as you are? Would you be held to the older standard because the majority know it?


Uncertain Authority

Is the trainer who taught your SACRUFE certified in 2017.b version of the SACRUFE METHOD MANUAL?

  • Do they actually know the current material? 
  • Have they ever participated as material contributors in a SACRUFE project? 
  • Did the people who trained them enter this field as a trainer/coach, or have they materially contributed on at least one SACRUFE project? 
  • Is what you were taught really SACRUFE at all, or just a few of the principles and practices thereof? 
  • Did you learn the trainer's personally-modified version of SACRUFE, or was it actually the official version with some personal notes added? 
  • Do you and your trainers really subscribe to the techniques, values, and process of SACRUFE at all, or is this "just a job" so you adopt the brand and skip the mindset, techniques, and process? 



So...

I don't mind that you have a certificate.

I'm not even mad that you've issued some.

I am worried about the business model of certification and the effects it has on the certifying bodies. Certifiers are the ones courting a deep problem.

The phenomenon of certification as a way that one body can confer a proxy reputation on someone who has not done the work (and thereby earned a real reputation) is upsetting.

The ability of a certification body to choose which practitioners' reputations and experience are valid is more upsetting yet.

I'm willing to grant that the creators of a method (and their selected body of like-minded people) have the right to define the method and decide who is using it or not. There's nothing wrong with saying "what you are doing is not SACRUFE, but is interesting and seems to have good results."

And the phenomenon of a body bestowing a reputation proxy for pay, in effect limiting the field to those who can afford to pay for the proxy, upsets me most deeply.

It's probably not you. It's a bigger issue. But let's talk about that.

Wednesday, July 19, 2017

There is no such thing as a scrum development 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 extremely uncomfortable.

Some even suggest that those values cannot work in a large company, or that the people who propose the values don't really mean it.  With regard to scrum, they assume the parts that involve human relationship are entirely optional and replaceable with "known good" command and control techniques. This is false. The values are crucial and irreplaceable. 

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.