Agile every day: a natural state

Last week, I took part in an internal Agile community discussion (via web-/tele-conference) in which I spoke on the topic of using Agile techniques in my daily life.  The given topic name was “How Agile are you?”  The idea being that we can draw parallels between using Agile in every day situation can inspire or motive the more effective use of Agile techniques in projects.

In preparing for the session, I focused on my own daily activities and approach, rather than how I try to shape the teams in which I participate or how things “work” in my family.  (As in, “Physician, heal thyself.”)  I found it interesting, mostly because rather than needing to search for elements of “agility”, they seemed to pop up every where I looked.  For example:

• Meetings get dynamically reprioritized, resulting in both schedule shifts, resizing, and delegations
• A task backlog has items added, recast, and undergoing shifting priorities, with some dropping due to “overcome by events”  
• Both meetings and tasks have generally evolving scope as more information emerges
• Large deliverables grow in size and scope, evolving to ‘done’ via a series of iterations
• Feedback (both provided and received) on evolving deliverables changes their direction, both gently and radically
• Frequent and effective communication (both oral and written) is part of the path to success 

I could go on.  And on.  And on.

What I couldn’t find was evidence of an approach that was dominantly plan-driven.  To be clear, there were plans, many of them, in various levels of detail that represented a certain prioritization.  But these plans were consistently subordinate to the reality of the day and were constantly reevaluated to reflect an evolving context with both long- and short-term priorities.

I thought more deeply about this and whether or not I could consider myself to be unusual.  To be fair, that could be an possibility.  I have a relatively senior role at work in an dynamic industry.  And so I looked around.  Every time I found someone who I thought might be operating in a plan driven way, perhaps due to a specificity of tasks or a regularity of schedule, I looked closer and when either zooming in or zooming out (in space or time), I found the need for adaptation and flexibility.

The particular type of adaptation and flexibility required varied greatly, due to circumstances.  Clearly, (so-called) knowledge workers experience the most need for agility.  However, among those in the service industry, some sort of agility is required for success.  (Ask anyone who has tried to deliver a service strictly according to an inflexible plan and you will receive stories of failure.)  And while manufacturing requires following strict plans in certain ways, the most successful manufacturers are those that can adapt their assembly lines and process rapidly to meet shifting market needs.

Thus, it’s my contention that being “agile every day” is easy because it’s our natural state.  Flexibility, adaptability, and communication are among the essential elements of humanity.  

The unnatural thing is attempting to over-plan the future, to fail to respond to change, and to value process adherence over human/contextual interactions.

Crossing your technical road

Dinesh and David are good friends and good programmers who live in Delhi and Dallas, respectively.  

For reasons that defy explanation to non-programmers, they were recently on Skype and having a (good-natured) argument about how to cross a busy road.  “I’m not sure what’s so hard,” said David, “Just get to the curb, look both ways, wait for a break in traffic, and then go."

“What do you mean about waiting for a break in traffic?” asked Dinesh.

“You know, wait for an opening in the traffic on the road when there’s no one coming."

“No… one… coming,” asked Dinesh in a confused manner.  “Like no one at all?"

“Right,” said David.

“And what wee hour of the morning are you crossing?” asked Dinesh.

“Not a wee hour,” said David, “Just any time.  OK, you might need to wait for the timing of the stoplights to hold all the traffic."

“Stoplights that hold all the traffic?” Dinesh’s face had taken on a look of full incomprehension, noticeable even in the small Skype window.

“Yes, depending on the synchronization and position of the stoplights,” said David.

Dinesh’s Incomprehension had given way to a glimmer of amusement.  David ignored the look from his friend and continued.

 

 “Yeah, you just wait for a break in traffic and then go.”  He paused a beat and added, almost as an afterthought, "Depending on traffic and the width of the road, you’ll probably need to run."

“Run?  Are you serious?” This was now too much for Dinesh, whose arms were extended in a gesture of exasperation.  “That’s way too dangerous.  Running will get you killed."

This earned a raised eyebrow from David who seemed to secretly enjoy riling up Dinesh.  “What would you suggest?,” he asked with a barely concealed smirk.  “Should I walk across the road?"

“Precisely,” said Dinesh in a profound and sincere manner..

“Do tell!” said David, whose face now held a full grin as he awaited his friend’s explanation of the seemingly inexplicable.

Dinesh took a breath and began.  “Get to the curb, look in the direction of closest oncoming traffic, taking into account one-way streets, of course.  Then when there is a small break, or when traffic is stopped, step off the curb and work to cross the first line of traffic…"

“Lane, “ said David, a little too abruptly (he sometimes badgered Dinesh about his accent).

“No, line, I pronounced it correctly my drawling Texas friend.  Work to cross the first line of traffic.  You may have to catch the eye of the oncoming driver to make them slow down a bit to let you clear.  Or you can maybe just show them a hand"

“Um, Dinesh, you don’t mean to give them the finger, do you?” asked David cautiously, who thought his friend to be polite, but wasn’t too sure of his tactics at this point.

“Certainly not!”, exclaimed Dinesh, “I said to show them a hand; just a small low sort-of wave that we do to get their attention.  It is kind of like the gesture that a police officer would perform to say Stop, but this is made very low and close to the body, to as to be as humble as possible.  After all, I am just a pedestrian, the driver is controlling several thousand pounds of car."

“Ok, I think I get it,” said David, who still wasn’t quite sure of this approach, but was relieved that his friends tactics didn’t include obscene gestures.

“Anyway, as you are partway through clearing the first line of traffic, you start looking at the next line, keeping an eye out for motorbikes or scooters, which may be between lines.  You may need to adjust your angle of crossing, heading downstream a little bit, to let a motorbike pass so you can tuck in behind it.”  He continued, as David’s eyes widened.  “Then looking at the next line, just repeat the process again, recognizing the traffic may be changing speeds.  Or there may be an autorick, I mean tuk-tuk, or even a truck, both of which require special care."

“Special care?” wondered David.

“Yes, special care,” replied Dinish, “The little autoricks are quite unpredictable in both speed and direction, while the trucks are simply slow and frequently have poor brakes."

“Wow,” said David, who was having a hard time picturing this process, “are you across yet?"

“No, not at all, after 4 or 5 such encounters, I’m probably about halfway,” said Dinesh.

“Halfway!  Then what?” David wondered.

“Midway I’d stop and wait for a bit, whether there is a raised divide or not, the traffic will just flow around me,” said Dinesh.  “Then I’ll just start out again, handling traffic headed in the opposite direction."

“Wow,” that’s crazy, said David, shaking his head.  “The middle of the road is a dangerous place.  I can’t imagine stopping there."

“Not at all,” smiled Dinesh, "it’s quite safe, you just have to hold still"

“I guess we’re even, or something like that,” said David.  “You can’t run and I can’t walk"

“Correct,” said Dinesh, “And I need to stop in the middle while you can’t stop in the middle"

“You live in a strange world buddy,” said David.

“So do you, my Texas friend, so do you,” said Dinesh.

---

This entirely fictional story (cum parable) emerged from a set of recent discussion with different (Chennai-based) teams about the technical transition that each one faces.   Both teams have challenging transitions and need to carefully choose a transition approach.  And so like David and Dinesh, they need to not only plan carefully and execute well, but the plan needs to match with their context.

 

The first team is approaching particularly difficult UI architecture transition that a product needs to make. Their context included the following:

• No (apparent) backward or forward compatibility between architectures
• A large application with rich business functionality
• A wide variety of highly customized UI controls that had absorbed all varieties of specialized requirements over the years

The current estimates were coming in at levels that were both resource-heavy and for a long period (6-12 months).  The team was considering branching the code and having the work proceed on the branch for the duration of the transition.

Hmm.

But, I asked, wouldn’t this mean that the UI functionality would either be frozen for the migration period or there would be a backlog of changes to merge?  Yes, they agreed.  (Hmm.)

And, I asked, wouldn’t this mean that the even if the UI functionality was frozen, there would be some element of merging happening after we completed the migration effort.  Yes, they agreed again.

And here we stopped and I said that we needed to find a new way to go about the transition because the current migration approach is too slow and gradual and isn’t matched to the context.

In the second case, the particular team is working to find the best approach to allow customers to transition from one product to another.  This transition is made more crucial by the domain (healthcare) where there is very little appetite for operational risk and the system has deep integrations into many other systems.  Therefore, the transition is likely to require considerable testing and verification by the user community before a cutover is implemented to ensue that patient safety is maximized.

Here the team spent time explaining the formidable test plans they had assembled to complete pre-deployment testing.  They included a battery of testing (both automated and manual) for many scenarios. We talked about getting user data (anonymized for privacy concerns) into the test lab.  We discussed various kinds of test case reviews with the user community.  All of the information looked great.  And by most perspectives, the team’s cutover plan looked solid.

But then, at the tail end of the discussion, I asked some questions which brought the room to a halt.   I inquired about:

• The impact of anonymized data
• The completeness of data scenarios
• The completeness of usage scenarios
• The ability to completely simulate upstream and downstream systems

These team responded that they had awareness of these and had worked to factor them into the testing plan.  But, they said, there were practical limits to their ability to address these.

And so, again as before, we stopped and I said that we needed to find a new way to go about the transition.  But this time, it was because the current transition because the current migration approach is too fast and abrupt and isn’t matched to the context due to patient safety concerns.

These two examples demonstrated the necessity of matching transition approach to operational context.  In the first scenario, the team was considering a long transition period, which would bottle up change and introduce risky merging.  In the second scenario, the team was considering a cut-over approach, which resulted in taking on a level of risk that was mismatch to the domain.  

One team needed to go faster; the second team needed to go slower.

So when planning your transitions, remember to step back and look at your context.  Without this consideration, even the best planned transition will be more difficult than it needs to be... and might not be successful.

Planning your product's release journey

When working in an agile environment (or an environment that aspires to be agile) defining a product roadmap through a series of iterations is crucial to the success of the effort and the team.  The iteration milestones largely determine the external and internal feedback points, along with which comes the ability of a project to adjust its approach to the product.  Therefore, the choice of iteration milestones, their position in time and in the problem space, and their separation and cadence can both enhance and detract from a project’s likelihood of success.

When discussing the process of forming a product roadmap, one often hears of the analogy of planning a long journey.  The overall plan for the trip represents the overall product roadmap.  Waypoints in major cities represent Iteration milestones.  And the first major city stopover represents the MVP (minimum viable product).

However, this analogy breaks down in several key ways.  First, when experiencing an actual trip, the traveler experiences and receives feedback while en route.  Whereas this feedback from the users/market is not provided in a product journey, unless explicitly solicited and acquired.  And even when the feedback is acquired, its validity is sometimes difficult to ascertain, unlike the validity of the feedback received by our traveler.

Second, on an actual trip that most travelers take, the type of feedback that we get rarely makes a material difference in the subsequent stops.  Whereas feedback from the users/market can (and should) have real impact on the product plan, both in the tactical sense (e.g. usability) and in the strategic sense (e.g. certain modules receiving outsized usage).  The type of feedback received on a product journey is much in common with to the information gathered on a travel-based mystery, when an investigator moves from place to place based on clues found along the way.

And lastly, given our familiarity with the physical world and its realities, the traveler never plans a trip without some contingency and margin for error.  Whether it be the amount of time that we allow for a connecting flight at Heathrow, the predictably difficult traffic in Noida, or delays on the local subway, we intuitively allow for a certain amount of friction and are very aware when we are operating with a reduced margin of error.

Therefore, when planning your release journey, consider the following:

• Gain user feedback absolutely as early as it is possible to gather it through real-world testing.  The critical qualifier here is “real-world”.  This means that surveys don’t fully qualify, nor does testing involving wireframes or click-through demos.  These mechanisms don’t test the real users in a real context.
• While qualitative feedback is interesting, quantitative feedback is actionable.  This is literally as simple as the difference between the objective and the subjective.  So identify measurements, instrument the system to capture them, and analyze accordingly.
• Getting to production quickly with a truly minimal MVP is perhaps the single biggest risk reducing gift you can give to a product.  Going live ensures that all sorts of non-functional considerations get attention and, most importantly, exercise the deployment mechanism, production infrastructure, and support processes.
• Sequential milestones do not necessarily need to focus on the same area.  That is, there may be benefit to alternating milestones between areas of functionality/scope.
• The more frequent the milestones, the more opportunities for feedback.  And more frequent milestones necessarily triggers a focus on smaller release sizes (all other factors being equal).
• Maintain high quality during release milestones.  In addition to accruing technical debt, allowing quality to slip generally invalidates feedback and will require another release to obtain that effective feedback.

While there are certainly other items to consider when crafting a release roadmap, these are some that have proven valuable in my experience.

Pronouns considered harmful

When I was a boy, my father used to tell a joke about a man who found himself in prison.  (To be sure, the peaceful sort of prisons in 1950’s-era black-and-white American films.)  A recent meeting brought it back to mind.  So… first the joke… and then the linkage to work.

On a man's first night in prison, he is in his bunk after “lights out” when he hears “NUMBER 6!” called out loudly into the quiet cellblock.   Several hundred prisoners promptly erupt in laughter.

After quiet returns, another voice calls out “NUMBER 12!”.  And is answered by enthusiastic laughter.

“What’s going on?” asks the new prisoner.  “Well,” says his cellmate, “We’ve all been in here so long that we just tell the jokes by number, rather than telling the whole joke."

So the new prisoner asks if he can try it out.  “Be my guest,” says the cellmate with a smile.
When there is a gap, the new prisoner yells out, “NUMBER 13!”.  Dead silence.

“What happened?” he asks, “Wasn’t that joke funny?”

“Hmm…” said the cellmate, “Sometimes, it’s not the joke, it’s how you tell it."

This joke is a play on the shorthand enabled by familiarity and shared context.  Good friends do the same thing.  “Hey, we’ll both be in London this Friday, let’s meet at that pub in that passageway southeast of Trafalgar… the same one where we met after we signed that one big deal in 2013."  Without shared context, this is largely a nonsense statement.

Now let’s link this to work… 

I was recently in Hong Kong, where we’re working on a big software delivery.  Around a conference table, our technical experts were working with client business experts, driving toward shared understanding.  By my count, we had people from four countries, so clarity in communication was paramount.

At one point in the discussion, one of our technical experts was wrapping up a comprehensive discussion of the algorithm/process the system used to complete a particular business requirement.  Looking around the table, I could tell that everyone had almost followed him.

There was a pause as the client team absorbed what our experts had said and contemplated their next statement. 

And I shocked the room as I turned back to our expert and said:  “That was great… Now please do the explanation again… but with no pronouns."

Shock from the technical expert.  Confused looks all around the table… except for a wry grin from my Australian colleague.  And so I continued… smiling broadly so everyone could tell my intent, which was to drive clarity… with a dash of hilarity.

“Right… That was great… please do it again… but with no pronouns… don’t say the word ‘it’, ‘that’, ‘this’… just call a thing by its name when you refer to it.  This way, everyone knows what you have in your head."

Still… a lot of odd looks… and a little tension.  For this is clearly a very odd request to make.   Time to relax everyone.  So, I told a variant of the aforementioned London pub story.  (Which drew a bit of a laugh.)

And so our technical expert took a deep breath and restarted from the beginning.  There were a couple of false starts as he caught himself letting a pronoun slip in to his sentences  But then he gained momentum.  And the wave of understanding in the room was clear. 

Most interesting:  not only was his explanation better, but the questions that he received were better.  Proving that one really does need to know something to ask a good question.

So, the next time that you find yourself in the situation of needing to explain something complex, try the trick of banning pronouns from your explanation and see what happens.  And no, you don’t need to tell either of those two jokes as a warmup.

Motivation and focal point: BHAG vs 25 paces

Back in the early ’90’s my girlfriend (now wife) lived in Denver.  I visited (often) from Chicago and we hiked frequently and strenuously.  Being midwestern flatlanders, we took vigorously to bagging prominent peaks, with a focus on Fourteeners.  Even being in our twenties and very fit, these were difficult hikes, often over 15 miles round-trip, with plenty of elevation.  

We would attempt Fourteeners in the summertime, when the days were long, because one needs to summit before noon.  (In the afternoon, the thunderstorms roll in on the mountain tops, no matter how nice it is in the valleys).  So we set off before dawn, around 4:30am.  We would each carry a liter of extra water, find a bush about two or three hours up the trail, and stash/cache the liter so we wouldn’t have to carry it the whole day.  We carried plenty of food, because bonking is just not good when on a big hike.

Other than the outlandish effort, these hikes was straightforward, we had our goal,  resources,  skills, map, milestones, and deadline.  And, unlike the movies and unlike the projects that we face at work, things generally went as planned.  All we had to do was keep walking.

And walking

And walking.

And the combination of fatigue and boredom would be brutal.

At times on these hikes, the destination peak, the “BHAG”* was in view, but no matter how much we walked, it moved no closer.  And so, rather than have my motivation be soured by this optical tyranny of focal point, I would put my head down and look only at the trail 2 feet in front of me for (say) 25 paces.  And then I’d look up.

Frequently, I’d notice a small change in the view of the destination peak.  Maybe the path curved, or dipped, or a tree was in the way.  Or maybe not.  But regardless of the view of the destination peak, in 25 paces, the path itself typically changed in some interesting way.  And I noticed progress.  And by noticing progress, I got a little motivation.  And a little motivation gave me a little  energy.  And so I’d put my head down for another 25 paces.  And repeat the cycle… which gave me a little more progress… etc.

And you can see where this leads.  Straight to achieving the BHAG.  The top of that Fourteener.

The message here is that we need the motivation symbolized by both distances of focal point: the long-range of out toward the peak and the short-range of looking down over 25 paces of trail.  Lacking long-range motivation, our short-range effort will be frittered away in an uncoordinated manner.  Lacking short-range energy, our long-range aspiration will lack the kinetic power to be achieved.

As you plan your 2015, I hope you consider how to manipulate focal point and motivation to your advantage.  (And if you have the chance, I do recommend both of Collins and Porras’ books: Good to Great and Build to Last)

* BHAG := Big Hairy Audacious Goal  a clear and compelling goal with a clear finish line, from the book “Built to Last"

Turning Toward 2015

Snappy post tonight... because this is the new year.  And any new year is about getting things done... not about long-winded reminiscing about doing stuff.  So, let's get to it.

Like many of you, I used the holidays to do some catching up… here are some technology-related catching-up things that I did over the holiday break.  Maybe they will give you some ideas/inspiration:

• Helped one child set up two-factor authentication on their Dropbox account
• Worked out the kinks in the Arduino code for another child’s cool motion-controlled lamp
• Initiated a second (home-based) Time Machine disk for my work Macbook to protect from theft/loss of the Time Machine disk that I carry
• Ordered some additional SmartThings moisture sensors (since apparently I need one next to each toilet)
• Configured some additional SmartThings home automation with some motion sensors I had (and threw out all of my old X-10 hardware… yippee!)
• Dug out about a dozen old paper manuals like this one, found them on the web, saved them to Evernote, and recycled the paper… yippee!)
• Set up a newly arrived Doxie Go Wi-Fi scanner, a super-handy, high-quality way to get paper into Evernote via Mac/iPhone/iPad
• Did some digital shredding of old data... the hard way
• Upgraded the last of the Macs in the house to Yosemite (much to the excitement of the family)
• Learned how to Snapchat (much to the disappointment of the rest of the family ;-)

There you have it.  Hope that inspires you to go do your thing!

Statics, Dynamics, and Relativity

I have a regular meeting with some of the senior technologists on my team.  It’s a small, varied and global group.  They have little in common except their deep technical experience, a readiness to debate, and a strong tendency toward sarcasm (things that seem to transcend national and cultural boundaries among technologists).

During many of these meetings we discuss the barriers to change that Others (it’s always Others ;-) are erecting as we seek to change cause change in our environment.  Sometimes it’s change to help things go Faster.  Sometimes it’s to help improve Quality.  And other times, it’s to lower Cost.

The example last week was around our development process and how the Others were hindering the improvement of Scrum.  (In this case, it happened to be the need to have better quality and depth of product backlog.)  The team had plenty of commentary about what needed to be done and how Others needed to not be resisting the change.

From there, the discussion pivoted toward some work that other team members were doing on an automation platform.  In this case, a team had been working extensively with Puppet to accomplish cross-platform installation and configuration automation.  And (seemingly) “out of nowhere” another team started talking about the importance of Ansible.

The team had been used to hearing about the Puppet vs Chef debate, which seemed to break largely along sysadmin vs programmer lines.  However, they said, Ansible seemed to be swaying previous Puppet advocates due to its agentless architecture…  They added that there doesn’t yet seem to be a clear-cut winner in this debate.

From there, the discussion started to go meta as the participants began to observe that “this automation stuff seems unsettled.”  And then began to wonder “when is it going to get figured out."

Listening to the conversation, I could feel that there were tendencies, lurking just beneath the surface, to “wait and see” before taking on certain automation projects.  There it was... resistance to change.  Just which the team didn't want to see in Others.

And it was then that I realized (or perhaps was reminded) that for all of us, our perception of change is relative.  In the former case, the team felt the environment was too static and change wasn’t happening fast enough… in the latter case, the team felt the environment was too dynamic and change was happening too fast.

So in a time of change, remember that regardless of what side of the times we find ourselves, understanding the Other’s worldview will help to smooth the transition.