Wednesday, September 28, 2016

14 Challenges For Agile Adoption

I stumbled across a document describing the government's approach to agile software development.
I didn't read it really closely, because I was just looking for some of these bullet lists at the time. 
However, I think that they may have nailed it with the 14 Challenges.
GAO identified 14 challenges with adapting and applying Agile in the federal environment:
  • Teams had difficulty collaborating closely.
  • Procurement practices may not support Agile projects.
  • Teams had difficulty transitioning to self-directed work.
  • Customers did not trust iterative solutions.
  • Staff had difficulty committing to more timely and frequent input.
  • Teams had difficulty managing iterative requirements.
  • Agencies had trouble committing staff.
  • Compliance reviews were difficult to execute within an iteration time frame.
  • Timely adoption of new tools was difficult.
  • Federal reporting practices do not align with Agile.
  • Technical environments were difficult to establish and maintain.
  • Traditional artifact reviews do not align with Agile.
  • Agile guidance was not clear.
  • Traditional status tracking does not align with Agile.
The problem seems to be largely one of unlearning the way that software was done in the days before agile. People got used to working alone, being told what to do, being held individually accountable for work items, working with customers in a continuous way, not having big design up front.

Way down in the list were challenges with technical environments and new tools.  Two items out of 14.

The rest is cultural.

What lesson did you take from this?

Tuesday, August 23, 2016

The Curiosity Space

Sometimes we get what we expect.
The reactions to that?
Either satisfaction or no real reaction at all.

When I put my bread in the toaster and it toasts it according to the settings, I don't throw a party. After all, that's what the toaster is for.  The water tap dispenses water, just like always, and that's what I expected. I'm glad for toast and water, but it's not something that will occupy a lot of my thoughts.

If I put in bread and got back a waffle, that would be surprising. I would spend more of my day on that.   Likewise, if I put in bread and received a flood of fleeing insects, that would be surprising.

Which brings us to the point: sometimes what we get is different from what we expect.

We can feel that as delight sometimes, because our results were far better than we expected.

Other times we feel it as disappointment.

If we judge this space, we will feel it as frustration, failure, embarrassment. even disrespect and loss of control. We can react in very controlling, negative ways. We can escalate to intimidation, anger, even force.  We often refuse to take responsibility for the difference, and blame others or blame circumstance. This is unproductive.

We've heard "It's not my fault -- he made me mad" or "they just refused to cooperate so I had to get up in their grill" -- note the lack of ownership. The "I" in these stories had no choice, and had to act inappropriately and angrily because the others "made" them.

I know it's unproductive. I am the father of two boys. I spent a lot of years not appreciating the curiosity space and not exploring it, but merely escalating the control issues.  I try to be better these days, though I still get eye-rolls from my adult sons.

I also am a software development trainer, coach, consultant. I often find that what works in one context has no impact (or the wrong impact) in another context. I've watched some other consultants throw angry fits and yell at people and demand dismissal of the employees who disagreed or didn't go along (I've never done this personally).

It's sad.  It's unnecessary.

I like to call the difference between expectations and results "the curiosity space."

We can't always explore the difference between what we want and what we get. There isn't time, given the number of surprises we see every day.   But when it's important, or upsetting, or delightful, then I think we have to put aside judgement and start asking "why" and "how did that happen" and "does that always happen".

I've written a lot about giving up recreational anger, and one of the most powerful things it has done for me lately is opening up my curiosity.

Now I see so many things I need to learn, and can take the opportunity to ask questions and look at alternatives and gather wisdom from other people.  I learned that if we enter the curiosity space as honestly curious people, we engage others. We can learn so much more. We open ourselves up to alternative explanations and theories and possibilities.

That space between expectations and actuals isn't a "problem" to be controlled.

It's a story to be unfolded.

Tuesday, August 2, 2016

The Relevance Ratio

As another bit of speculative, observational humor let me introduce you to the Relevance Ratio.

What it is:

Consider where you are sitting right now, and the last task you tried to do there.

Now, consider/remember the information around you on all sides. The posters, conversations, sounds, words, materials.

Pretend you measured this information content and assigned it a number like maybe 100 (just to make the math simple).

Next, look at all that information content and determine how much of it is not relevant to the work you are doing. Do you have posters? Clutter? Radio? A television playing? Reminders of other work to do? Clocks (not pomodoro)? Dilbert posters? Are there things you have to reach around or past in order to do your work? Consider it all. Do you have a coffee cup? That's information too -- because it urges you to make a beverage decision. Candy dish or lunch box? Food decisions.Say it's a 60.  About 60% of the information in your view has nothing to do with completing the work you're doing.

60 out of 100 percent of your information is irrelevant? Then we assume that the other 40% is related to your work today. 40% relevance ratio.

Yes, it's just another way to say signal-to-noise ratio. It's just applied to your environment.

Why would you do this?

I have been talking to people about their environment. Usually it goes to the seating arrangement.

Some people claim that they are only productive in a closed office by themselves. 

Others are best when sitting in an open floor plan (bullpens or pods) with their coworkers.


Now here is where the observational comedy comes in: I really don't know.  Not a clue. No study has been done that I know of, and all I have is anecdotes and personal experience. 

So this is an idea. A hypothesis.

To wit:

Solo workers tend to want to be alone, and teamworkers tend to want to be with their teammates.

Nobody wants to be seated closely (in cubicles or open floorplan) among people who have nothing to do with their work.

For solo workers, the relevance ratio in a team space is amazing low. While isolation removes distraction, it also ensures that they are starved of relevant signal as well.  Excessive isolation means that other people are not aware of the quality or quantity or importance of the work being done and can easily be suspicious and check on the solo relentlessly, which lowers the relevance ratio by stopping the work for status reporting.

Solos often resort to chat and email to try to reconnect with people whose work is relevant, but who are not in the immediate area (boosting the relevance ratio).  

When a collaborative team worker (sharing tasks, goals, results with teammates) is isolated, the lack of signal is a real problem. It's better in pods or bullpens, provided that they are seated near people who are sharing the work -- so that the relevance is high.  Of course, they are highly visible and can be seen collaborating and often serendipitously joining conversations where they can be of aid to their colleagues. 

So What?

The interesting idea here is that maybe we can get more done if we tap into the kind of work (solo or collaborative) afforded by our environment, or (better, and perhaps more radically) change our environment to support the kind of work we need to do. 

I am sitting in a space with moderately high signal. I have three screens, and cheat sheets, and writing utensils and such. Also, I have a window into a wooded yard and am in view of my water bottle and coffee supplies. Sadly, I'm also nested in with clutter and noise that distracts me. A bit more relevance in my surroundings I have learned will help me focus -- or I can concentrate until I don't notice those things.

That concentration is wasted willpower and wasted mental energy which I could use for making better decisions and doing better work. It's an annoyance. 

So, I'm thinking of how to increase the relevance ratio in my space, and I will be embarking on a quick clean-up to make that happen.

Is irrelevance bad, though?

Will you be only 40% effective? Nah. Focus is not everything. You need to be reminded to drink water, stop for a snack, remember the next meeting, see your family's smiling faces. That refreshes you and reminds you of your purpose and place and physical being. We don't want you to be a machine, but a whole person.

A cartoon or two may remind you of your values and your view of the world, and to keep good humor about yourself.

Certainly a fan creates some noise, but that is white noise which masks quieter distractions while keeping the room at a comfortable temperature so that you're not distracted by thinking about how hot it's getting.

Is the person in the next office/cubicle/seat chewing potato chips/crisps with their mouth open while clipping their nails? That's distraction. Some amount of the irrelevant information is unwanted. Likewise, are your neighbors talking about a project that you have nothing to do with? A sport you don't follow? God forbid, politics? Probably not useful.

This idea is interesting, because it has some explanatory power and some predictive power and it seems that paying attention to it is helping.

But there are no guarantees. It's just an idea.

I'd love to hear both supporting and dissenting views -- have you tried manipulating or monitoring your relevance ratio?

Monday, August 1, 2016

The Intimidation Cycle

I look at how hard people try to combat fear with fear --
  • X is afraid of Y, so 
  • X tries to make Y afraid of them in return, and 
  • X escalates to make sure Y is the more afraid, so 
  • Y cranks up the intimidation even more, because
  • Y can't let X win.
  • Y says "X needs to fear US!", so 
  • (repeat paragraph)...
I wonder, how long will we keep doing this?

And I'm told: as long as the other guys are winning.

Breaking the cycle is possible, but you can bet that when it ends, it won't be because one side won.

Thursday, July 7, 2016

Curiosity over Judgment: getting past defensiveness.

Say someone wants some aspect of my behavior to change: dress, schedule, food, drink, speech, whatever.

I initially get a little upset, defensive. But that's not productive. That's just anger and ego protection.

Is there a more excellent way?

I'm told that the secret to success is to replace judgment ('that's none of your business", "you are trying to control me", "screw off, I do what I want", "that's not fair") with curiosity.

"replace judgment with curiosity"

Curiosity. Hmmm. Let's try that. I wonder where that will lead.

I'll have to suspend my anger and judgment and blame and quit assigning motives to others if I'm going to process this with curiosity.

So much is possible now, and there are so many questions:

So, why is it so important to you that I change how I behave?
  • Is it for a purpose? 
  • Does it serve you in some way? 
  • Is it because you care about me and think it will help me? 
  • Is it so that we'll conform to the same standard? 
  • Is it because without the change I am missing opportunities? 
  • Is it for our mutual good? Only mine? Neither? 
And then -- since I got defensive -- there are other questions for me to answer first:
  • Why is keeping this behavior so important to me? 
  • Why should I cling to this behavior?
  • Is this behavior symbolic to me? Of what? 
  • Is this behavior central to my purpose and place in the world?
  • Has my current behavior limited me or expanded my opportunities and enjoyment of life? 
  • Is it really "just something I do"?
  • Is the new behavior really detrimental to me? 
And then... what is best?

If I take the position that I should want what is best for me, what builds the future and the person and family that I value so much:
"what do I really want?"

Now I can make a decision with clarity, intention, values, and purpose.
I'm free.
I have power over my life.
I can choose.

I don't even have to make a permanent decision for life, I can choose for now and revisit later when I know more about how this change affects me, you, and us.

"what does this mean to you?"

But of course, to get past judgment and to an end, both people are probably going to have to have this conversation -- in curiosity and not in blame or judgment.

I wish the world worked this way more often.

Friday, July 1, 2016

What is "Agile"?

Most of agile is about delivering sooner and a lot more often, so that you can incorporate the client's desires and feedback into your daily work. 

The rest is about how to make that sustainable for development teams.

Monday, April 4, 2016

Naming is still hard.

Ideally, we would have excellent and obvious names for all variables, classes, packages, methods, etc. But it's hard to be excellent all the time. People building the java libraries struggled with names, I can tell, and though I don't always appreciate their choices I recognize that this is a multifaceted problem.

Maybe a moment of agonizing over a bad name might help share a mental model, and some patterns or smells for naming methods.

Let's give it a shot.

A Tiny Example

Here is a tiny, dull, dumb snippet:
 Date now = new Date();
 DateFormat df = DateFormat.getDateInstance(LONG, Locale.FRENCH);

Java has a method called getDateInstance().

Does it return an instance of a date? No, it does not.

If it lived in a package called Date then it would be a terribly wrong name, but it doesn't live there.

It returns an instance of a date formatter, whose class is called DateFormat.

DateFormat doesn't seem like such a good name, because it is an object with methods format. A DateFormat with a format method seems odd and redundant. Is it one, or does it make one, or what?But let's not worry about that for a minute.

It lives in DateFormat, so technically its name is DateFormat.getDateInstance.  That's better, but it's possibly both misleading (not a date instance) and also redundant ('Date' appearing both in package and method name).  Would DateFormat.getInstance() be a better name?

Well, that depends on how you import it. If you import DateFormat, then DateFormat.getInstance() seems harmless enough, but you might import DateFormat.getInstance() and then the use of the method appears without needed context:

      Console.out.println(getInstance(LONG, Locale.US).format(now)); 

Instance of a LONG? Instance of an US? Should the name be getInstanceOfClassDateFormat? Ew. GetInstanceOfFormatter?

Well, the call to format seems to help give context so we know more about it, and we can hover over the getInstance() call in an IDE to help us see where it comes from. It is harmless and survivable.

But it doesn't seem excellent.

Identifying a Noise Word

Trying to finesse or expand the word Instance is not productive here.

The problem with Instance is that it is a noise word.  It is like Data, Manager, Information, and so many other space-consuming bits of non-meaning we often assign to variables and classes.

So maybe the question that helps with naming is to ask again why this function exists.

It seems to me that it exists to provide the date formatter that the user requested from among the many date formats that may exist in different locales.

That suggests that the name should probably be something like getLocaleSpecificDateFormatter, but that's a real handful to type and most of the interesting words are near the end. Eww.

Perhaps getLocaleFormatter() is sufficient, since it's in the DateFormat package to begin with.

I prefer that, but I'm not crazy about it. I don't even like starting with 'get', which leads me to ...

Working with the Audience

I don't care for the getter/setter standard in Java. I would prefer to see something like DateFormat.for(LONG, Locale.FRENCH).  However, I have to balance that preference with the idioms and habits of the Java community.

A programmer working in an IDE will type the word get, and then ask the IDE for completion. That's a powerfully useful habit in Java IDEs, and it behooves us to comply.  Therefore 'get' is mandatory.

Now the next-most important thing is the word following get, because the programmer needs to quickly select the method they want from the completion list.

The next important word seems to be Locale. Let's make that word #2.

Now we see DateFormat.getLocale -- and that's still misleading. We don't really want a locale object/package/class here, but rather an object that will format a date for us. Drats.

Do we drop "Locale" from the name elaborate further?

It seems that Locale is important, so we don't want to move it later in the name or drop it entirely, so we'll elaborate a little further to see where it takes us.

So if we're not getting a locale, but a formatter, let's append the word formatter.

We suck up the redundancy issue. DateFormat.getLocaleFormatter() seems like the best we can do without agonizing over this for weeks.

Looking at the example of usage (in a test, of course) I see something like this:
DateFormatter df = getLocaleFormatter(LONG, Locale.FRENCH);
String formattedDate = df.format(now);
This seems to reveal intent so much better than getInstance().

Of course, the java libraries are in wide use and people have already formed habits and programs that would break if we renamed the library method now. So, we don't do anything about it, and go back to calling getInstance() while gritting our teeth.

Oh, look. The variable df has a horribly bad name. I bet I could fix that...

What do we learn from this exercise?

In this (perhaps silly) example, we examined a name that we cannot change, but along the way  you and I have examined:

  • the direct honesty of a name (and found it wanting)
  • the context of the name (the package and usage)
  • the existence of noise words in the name
  • the way in which other programmers use names
  • the idioms of the programming language
  • using a compound name to progressively reveal the intent of the method
  • the difficulty of changing APIs whose users are unknown to us
  • the fact that naming is an ongoing battle (see remark about df, above)

I welcome your comments and criticisms.