Derek

Derek is a consultant, trainer, and learner in the software product development industry.

May 182017
 

My mother is going to laugh a lot at the fact that I’m writing this post, even if she’ll never admit it to me.  The idea that her son — who always used to get home late, sometimes knocking over the pots and pans that his father had set up against the door to announce his late arrival — is writing about time is a bit ironic.

But here we go. My good friend and excellent Agile Team Guide David A. Koontz (really, he’s an artist with teams; you should try to hire him) wrote an excellent article about Lead Time vs. Cycle Time, and the difference between how long we take to do a job vs. how long the customer waits for the results.

I’ve been working with Lean Kanban Inc. since last year, and I appreciate the sharp point they’ve put on terms around this issue. Here they are in a picture:

1. Customer Lead Time

The time from when we accept the customer’s request until deliver that request to the customer.

That’s it. Plain and simple. This is all the customer cares about!  The item could be “done” 5 minutes after the order is taken, but if it sits in a warehouse for a month before the customer gets it, the customer is still gonna be peeved.  Or as in David’s example, the item could sit around for a month and only take a few minutes to actually deliver. Either way the result is the same.

2. System Lead Time

The time from when we accept the customer’s request until the request reaches the first unbounded queue in the system.

This is a metric we care about when it comes to measuring and improving systems. Notice the Work In Process (WIP) limits in the picture above.  That last state, “Done” has no WIP limit. It’s potentially infinite. Even though we serviced the customer’s request at the end of Process C, it could sit around in a queue forever.

The reason we measure this only up to the point of the infinite queue is because we can only design and control systems that have WIP limits in them. Sometimes we can’t control what happens in that “Done” queue, so we can only work to improve everything up until that point. (At first. Once we get that under control, it’s time to have some conversations with the people in “Done.”)

This is why it’s important to have WIP limits on all work queues and buffers: if you don’t, then you don’t really have a pull system, and your ability to predict delivery is shot.

The actual LKI term for this metric is “Kanban System Lead Time.”  But if the first unbounded queue in your system is the Request buffer, guess what — you don’t have a kanban system. This, right here, is the most common pain I see when I’m asked to help with Agile delivery: a great Scrum engine with tightly-controlled WIP (from Sprint Planning), and a whole chain of unbounded queues upstream of it.

PRO TIP: your biggest predictability problem in this case is NOT your development process. :)

3. Time In Process (TIP)

The time that a particular request spends in a given process state.

This is what David called “cycle time,” and it’s a pretty common usage of the term. I prefer Time In Process because it’s clearer. “Lead Time” and “Cycle Time” can get confusing, so we just throw one term out. Yep, we don’t actually ever say “Cycle Time.” (Well, I try not to — old habits die hard.)

What about the time from Process A to Process C?  Easy, that’s just “the Time In Process for Process A, B, and C.” In our example above, TIP (Requests+A+B+C) for an item is the same as the System Lead Time for the item.

We use this in systems design to get a more fine-grained view of the system than System Lead Time.  And we use it day-to-day to meet our Service Level Expectations.  Do we expect most requests to spend 7 days TIP in Process B? Is this request here currently 6 days TIP? Then maybe we better get a move on and get it out of here — or think about renegotiating the customer request.

4. Working Time

Time spent on actually increasing the value of the item. Also called Touch Time.

In David’s example, this was also what he called “Cycle Time;” the time spent installing the basketball hoop. Often, the Working Time represents only a small fraction of the total Lead Time for the item. Which brings us to…

5. Waiting Time

Time where the item is not being actively worked on.

This is often a large portion of the total Lead Time (System, or Customer) for an item. This is where high WIP limits (or no WIP limits!) kills us. This is where multitasking kills us.  So much of the customer’s total wait time is just the request sitting around, or being shuttled back and forth from one person to another.  Which brings up…

6. Flow Efficiency

The ratio between total Working Time and total Waiting Time, expressed as a percentage of System Lead Time.

And here’s the second most common pain I see when asked to help with Agile delivery: poor flow efficiency.  In the example above, we take the customer’s order, and then it sits for a bit.  Then we start Process A and finish quickly… but it sits for a bit until it gets to Process B. Same thing happens with Process B. Process C is better; mostly we work on the request, with one brief interruption.

For systems with lousy flow efficiency, changing the system to reduce waiting times is going to be a huge bang for the buck — much more than improving the actual working processes. You’ll get faster delivery, and more focused, happier people who aren’t task-switching all the time.

One Last Distinction

In my recent AgileIndy talk, I made a call for 21st-century management to raise the game: we need to get better at managing systems, and leading people.

We sometimes use the terms above to refer to an individual request. “What’s the Time-in-Development for this FooBar Story? Is that going to affect our SLE?”  That’s valid. That’s the kind of question you’d hope to hear within the team, not from a manager.

If we are managing the systems, we use the terms I’ve outlined here to refer to requests in the aggregate — which really means referring to the system as a whole. “How can we get the System Lead Time down by 30% for all standard requests?” That’s also valid. And that’s the kind of question I really like to hear from management. 

Let the workers self-manage the work. Manage the systems. Lead the people.

Dec 152016
 

The rules of the post-WWII economy are becoming less relevant. Ben Thompson offers a view of what we could hope will replace it:

…instead of trying to recreate a 1950s fantasy of employment for life on an assembly line, the goal should be to create a far more dynamic labor market with a defined floor and significantly greater upside than the old system.

We are already seeing a hint of the opportunities offered in such a world with the rise of the “gig economy.” People sell crafts on Etsy, raise money for charities on Twitch, and drive for Uber.

But taking this to its extreme sounds pretty scary without some “floor” on income. You mean, I’m going to have to sell on Etsy and drive for Uber just to be able to afford food and medicine?

No. The idea is that, free of the need to struggle for basic subsistence, you can pursue different ceilings:

…a universal basic income alone offers some degree of financial security, but it does not offer dignity to the recipient, or any return for society beyond a reduction in guilt. What is most important, and what offers the highest return, is enabling more and better ways to work and ultimately create…

…who knows what sorts of products and services might result from an emboldened and secure middle class?

This reminded me a lot of the RSA Animate of Daniel Pink’s “Drive.” Specifically the findings about incentives for post-industrial work:

For work requiring rudimentary cognitive skill, people are motivated by Autonomy, Mastery, & Purpose — once you take security off the table.

Ben encourages those of us in the technological elite to focus less on using our tech to become (pardon the phrase) uber-rich and comfy, and more on helping bring about the world he describes:

To that end, technology executives and venture capitalists should lead the campaign for the type of reforms I have listed above. More importantly, they should match their rhetoric with actions: companies like Apple and Google should strive to be technology leaders, not tax avoidance ones…

He goes on to list a number of specific things that tech execs and VCs should support. Really, read the article.

I’m not hopeful, myself. In my own work, I’ve observed a strong temptation in tech leaders to apply old-world thinking to the new world of technology. “Well,” goes the (ir)rationale, “I went to school and worked hard, I deserve to make as much money as I can from it. It’s unfair for me to pay more in taxes.”

And baked into some of these conversations that I have is this undercurrent of “besides, it’s not like people can do without their Twitter/online banking/videogames. Anyone who blames technology is just a Luddite.”

Ben cautions

…people are not always rational, especially when they are desperate. It is absolutely in the industry’s best interests to not only participate in but lead the creation of a new system that works to the benefit of all…

The alternative is far worse: once automation arrives, guess who is going to be the scapegoat?

Ah, what does he know? It’s the 21st century. And we upper middle-class technologists have never had to fear a Reign of Terror.

But America is still young, as a nation goes.

There’s still time.

 Posted by at 4:04 pm
Sep 232016
 

No, even though 2016 marks the 50th anniversary of Star Trek, I’m not talking about James T. Kirk and the starship Enterprise.

zumwalt

DDG-1000, the USS Zumwalt (U.S. Navy)

I’m talking about Captain James A. Kirk and the USS Zumwalt, America’s “largest and most technologically sophisticated destroyer.” The Zumwalt grabbed my attention when it was commissioned earlier this month because not only is it larger, more powerful, and stealthier than current destroyers, it boasts a crew that is half the size of other ships in its class.

The story of this real-life, science-fact-not-science-fiction vessel and her crew is a great read, and not just because of the cool tech.  There are many lessons here for leaders of non-military “enterprises” such as software development, business, scientific research, and non-profit/NGOs.

In this series, I’ll point out just four.

Lesson 1. Technology & Automation Are Required

The Zumwalt doesn’t have gunners’ mates to operate her guns, a separate radio room for communications, or a helmsman to steer the ship. All these tasks can be performed by an officer standing watch in the Ops Center because these routine, manual tasks are handled by automated systems.

The technology of automation is quite a bit more capable now than it was a decade ago.

A good friend of mine used to work in “network operations security.” His team would spend their days in repetitive tasks that resembled manual labor. Inventorying hardware and software. Researching the latest threats online. Manually patching vulnerabilities wherever they could. It was a Sisyphusian and sometimes scary job, always trying to stay one step ahead of the hackers.

Zumwalt Ops Center (Raytheon)

Zumwalt Ops Center (Raytheon)

But today my friend’s team has software to automate the tasks they used to do. The tech hasn’t replaced the people, it’s raised their game. The software still needs to be told what to do in order to accomplish the why of the company’s risk management strategy. And it’s my friend’s team — now called “risk management” — who is responsible for accomplishing that “why.” The tech has enabled his team to deliver better, stronger services to their company.

Proper automation can enable humans to focus on tasks like synthesizing information, making good decisions, setting strategy, and employing their own technical know-how.  Skills that, you know, require a human.

Let the machines handle the repetitive mechanical tasks; they’re better at it. Don’t expect your systems to be able to handle too much variance and unpredictability; that’s what your people are for. Use the tech to raise the game of your peoples’ service delivery. Tech should allow your people to directly implement the overall goals and strategy of your organization.

If you employ technology this way, you can free up your smart, motivated people from the routine tasks of data-gathering and paper-pushing. You can unlock a pool of potential capability for your organization.

In the next article we’ll look at why automation and technology, while necessary, are not sufficient.

All articles in this series:

  1. “Raise the Game” — Automation is Required (this page)
  2. “Same Sheet, Different Data” — Tech is Not Enough
  3. Management Overhead — Reduce the Waste
  4. Team Skills Needed — Diversity, Communication, Mutual Support
Apr 242015
 

2013-03-04 20.13.41Googling, I discovered that the folks over at XCeleratePartners blogged about an Innovation Games for Product Development course I taught in Houston. That was gratifying.

But what was truly gratifying was their write-up about the course (and here’s part 2). Go check it out. You’ll see some excellent details on how the games are played, which one to use for what purpose. And there are nice pictures, too.

Every teacher wants to know that they have made a difference, that their learners “get it.” That’s the true test of training. Not Net Promoter Score. Not standardized tests. The measure of the teacher shows in the real-life performance of their students.

“Educate” comes from the Latin educare, meaning “to lead out that which lies within.” The best learning is centered in the learner — not on the teacher — allowing the student to connect new concepts and techniques to those understandings which they already possess.

ProdBoxThe depth of the XCelerate students’ understanding is demonstrated in their ability to write about the games in a clear and comprehensive way. As an organizational coach, I couldn’t be more glad for the existence of another Innovation Games practitioner.

As an educator, I couldn’t ask for a better compliment.

 Posted by at 5:46 pm
Feb 102012
 

I love this Google+ post from Dave Gray. He talks about the operation of an aircraft carrier, a complex system with high personnel turnover but no comprehensive operations manual. There is no manual because it would have to be as complex as the carrier itself. Instead, the “manual” for the carrier is the sum of ongoing expertise and learning that is occurring all the time:

When the situation is stable, predictable, and well-understood, traditional hierarchy prevails. But when decisions need to be made quickly, decisions will migrate to the edge, where people can sense and respond to situations in real time.

At the end of the post Dave invites us to use this story as a metaphor for other large complex systems. One such large complex system is the so-called “software development process.” A documented process presupposes a simplistic ecosystem, but the ecosystem of enterprise software development — like the ecosystem of an aircraft carrier — is enormously complex. Beyond one person, a small team, or even a team of teams, enterprise software development is of the same order of complexity as the enterprise itself.

And as such, as Dave says, “there ain’t no manual.”

Sure, we need some abstractions (like UML) to help us quickly get our minds around general concepts. And we need some procedural checklists (like automated code-management tools). But mistaking these for “how to do software development” guides reminds me of Martin Fowler’s warning against mistaking software design docs for the software itself: “the code is the best source of comprehensive information, as the code is the easiest thing to keep in sync with the code.” Martin is reminding us that abstractions of complex systems are useful, but they are not the thing itself. Guidelines are useful, but manuals are useless.

So what do you do when your manual for the system will be as complex as the system itself? You don’t try to foster compliance — you foster learning.

And I have seen that scare the pee out of many people. They don’t want to learn. They don’t ever want to be the “new recruit” who has to learn how to best fit their own talents into that of the organization. They went to school, they have a degree, they have 10 years of experience, they want to prove to their organization that they “follow all the right processes and procedures.”

No wonder something like Scrum — three roles, three artifacts, three meetings, and 1 big rule: “adapt your work to best realize the needs of the product” — can be unsettling.

So, why are we learning to be afraid of learning?

 Posted by at 1:41 pm
Jul 172011
 

What is luxury?
Fine food, fine wine
Different lands, different people, different tongues
Water, sand, sun, sky:
Nature in all Her splendour.

Servants and service, our ev’ry whim
Fulfilled –
Singers, dancers, masseurs, chefs
A multitude of choices arrayed
To delight and dazzle us
Confounding our inner judge
Drowning out its strident
Admonitions: “You may not. You must not. There is not enough.”
“You just haven’t earned it yet.”

Freedom from want, freedom from duty
“Sit back, relax, and enjoy the flight.”
Freedom from normalcy, free refills
“You’ve been upgraded.”
Freedom from lack, freedom from fear
“You’ve earned it.”

But Nature is in the world, if you see Her
The songs are in your heart, if you hear them
The wine is from your soul, if you taste it
The food is with your friends, if you share it
The dance is in your work, if you dance it.
Stand up, relax, and enjoy the walk.
You need no upgrade.
“You may. You must. There is enough.”

It
Is yours
And has been —
From the very start.

20110717-043607.jpg

 Posted by at 3:36 pm
Oct 162010
 

Regina Holliday, a muralist and advocate for health care improvement, talks about her painting “Bridging the Great Divide” between L-mode and R-mode thought as applied to Healthcare 2.0.

The talk and painting depend a bit on the context of the conference where Regina is speaking, however I really liked this bit at at 3m50s about Gorilla Glass:

“Gorilla Glass… was sitting in a vault in Corningware since 1962, waiting for technology to catch up. And that’s what you guys are doing right now, you’re the catch-up. All these amazing things are out there that you need to embrace and teach us how to use correctly…

…Can you walk on glass? Can you take a step forward when you don’t know what’s supporting you? Do you have faith in the technology that you are speaking about, even if you cannot see it, nor prove it, nor say that its currently effective, can you convince others about how it’s going to change absolutely everything?”

I think there’s a message here for the #sgphx folks. I know I certainly am taking it to heart.

Amplify’d from www.thehealthcareblog.com

Click to see the video

Oct 022010
 

Oh, the farmer and the cowman should be friends.
One man likes to push a plough,
The other likes to chase a cow,
But that’s no reason why they cain’t be friends.

image from http://www.youtube.com/watch?v=XB90b8xXYIkI’ve noticed a disturbing trend at a few different clients now as far as how UX folk and Agile folk get along.  It put me in mind of a song from Rodgers & Hammerstein’s Oklahoma, barely-recalled from my high-school musical days.  Let me explain by way of example:

Steve is a User Experience (UX) expert on an Agile/Scrum team working on the new HipStartup.com website.  He’s excited because he recently returned from an Agile conference and got a lot of great ideas from Jeff Patton’s session about User-Centered Design.  John is the Product Owner (PO) for the site and is juggling multiple voices and requests, but knows that each day without a new site feature delivered is another day that Venture Capital money is burned with no return on investment.  Geri is the ScrumMaster (SM) for the team and she wants everyone to follow the Scrum process because she knows it’s the best way to deliver value incrementally.

Three weeks ago at the meeting with the VC folks, John heard that they would really love to see HipStartup.com do single-sign-on integration with Facebook, Twitter, NetFlix, and the FAA.gov websites — with a unified look and feel.  This morning during the sprint planning meeting, developer Brian cautiously raises the issue of design: does Steve have any wireframes or web composites done for Brian to use in his estimation of story size?  Steve replies that he’s still testing the wireframes with their user focus group and wants to make sure the design for the new single-sign-on will work for them before he releases them to the rest of the team.

John explodes. “What? It’s been three weeks! You’re telling me we still don’t have a thing to demo yet?”  Steve looks helplessly at Geri — surely she will understand the need for a good design?  “John has a point,” Geri says.  “All this user testing you keep talking about smells a lot like Big Up-Front Effort to me.  Can’t you get some wires to Brian ASAP, even if its just for a few stories?”  Steve is appalled.  Wires for just a portion of the site, when the VC folks clearly wanted a unified look and feel?  “Well, sure,” he huffs, “I can give you what I’ve got so far, and you can get right to work on it… if you don’t mind the users thinking it’s crap!

Let us let the curtain of imagination close over this scene for now.

I’d like to say a word fer the farmer
He come out west and made a lot of changes —
That’s right! He come out west and built a lot of fences,
And built ’em right across our cattle ranges!

Just like the farmer and the cowman, User Experience folk and Agilistas/ScrumMasters each provide value in ways that can inherently interfere with each other.  The UX person wants a good experience, and so needs to engage in some sort of holistic design.  This doesn’t have to mean Big Up-Front Effort, but it can look that way to the Agilista who has been fighting waterfall for much of her professional life.

They also each work in ways which tend to stir up the fears of the other.  The Agilista wants a continuous flow of bite-sized chunks of value, with frequent opportunities for inspection and adaptation.  This doesn’t have to mean a Frankenstein’s monster of cobbled-together parts, but to the UX person, even the possibility of creating such a monster is, pardon the phrase, horrifying.

I’d like to teach you all a little sayin’
And learn the words by heart the way you should
I don’t say I’m no better than anybody else,
But I’ll be damned if I ain’t jist as good!

So at the #womeninagile booth at Agile 2010, I had the great fortune to start a conversation with @carologic of Ask a User.  Carol is a UX expert and works through a variety of methods to incorporate actual user research and experience into the design of her client’s products.  While as an Agile coach and empiricism fanatic, I’m always espousing the “ready-fire-aim” and “fail fast” schools of adaptive outcome development.  Cage-match waiting to happen, right?

Wrong.  In 20 minutes of conversation at the booth, we were able to express our respective concerns with each others’ practices and how they are misapplied, and brainstorm at least three harmonious solutions integrating the best of Agile/Scrum and UX, in very specific ways.  Not to tease, but over the next few months, Carol and I will share those ideas with you in our respective blogs.  We will explore:

  • why we shouldn’t call the end-of-iteration demonstration of incremental functionality a “demo”
  • where to integrate user research into the Agile iteration cycle
  • the use of Boundary Objects as discussed in Israel Gat’s Agile 2010 talk

and more.  How did we come to this resolution so quickly?  Simple:  we both approached each others’ domains from a perspective of curiosity and interest — rather than from one of defensiveness.

And when this territory is a state
An’ joins the Union jus’ like all the others
The farmer, and cowman and the merchant
Mus’ all behave theirselves and act like brothers!

image from http://www.youtube.com/watch?v=jBf1Bkk8Gdk

I believe that diversity does not mean “tolerance of differences.”  Rather, diversity means “our differences make us collectively stronger.”  This isn’t compromise, this is learning from each other’s talents.  As Karl Weick said, “fight as if you are right and listen as if you are wrong.”

Let’s us UX and Agilista people listen to one another.  We’re not truly in competition, we both want the same things.  We just have different ideas of how to go about it.  And it’s in the union of the two that true value will be created.

As Oklahoma‘s Aunt Eller says, “ain’t nobody gonna slug out anything — this here’s a party.


 Posted by at 4:22 pm
Sep 222010
 

Rebecca Porterfield asks “can Agile work in a culture of single point accountability?”  The question stumped a panel discussion.  Too bad I wasn’t there, I’d have been able to give the usual pricey consultant answer:  “It depends.”

(cue laugh track)

image from The Village Voice, http://blogs.villagevoice.com/forkintheroad/archives/2009/12/locavorism_gone.php

In all seriousness, it depends on what you mean by “work.”  I personally have very high standards for “working” Agile.  Agile isn’t a way of doing, it’s a way of being.  So do I believe Agile can work in the spirit of its greatest potential, as a means to enable the shift from an deterministic organization to a learning organization (a la Senge), in a culture of single point accountability?

Can a possum stop a car?

Accountability When Agile is a Process

Sure, Agile can work as a process for incrementally creating quality software product when we insist on maintaining single-point accountability, exactly as Rebecca successfully implemented in her project.  You can “wrap” the Delivery Team in Agile and use the Product Owner and ScrumMaster as the “interfaces” for the team.  You can even promote individual accountability in such a scenario:

  • Product Owner (PO) — on the hook for the health of the (software) product
  • Team Coach/ScrumMaster (SM) — on the hook for the health of the Team and their adoption/adaptation of the process
  • Delivery Team — on the hook for demonstrating a working product increment at the end of each iteration

“Hey Derek, not too fast! That last one is team accountability!  So there isn’t individual accountability at the team level!”

Uh, no.  There certainly is.  In the context of the entire Agile Team (e.g. a Scrum Team consisting of a SM, PO, and Folks Who Make the Software Product Exist) the Delivery Team is accountable only so far as they collectively build working product.  Individually, however:

  • Delivery Team Member — on the hook to the rest of their Team for whatever commitments they make each day at standup; for asking for help when needed; and for swarming and providing help as needed.

See ?  If we are talking about a culture of accountability, then accountability depends in what context you view it.  Each person both has individual accountability and also is part of a Team that has team accountability.  In the context of the Delivery Team, Brian the Developer is accountable for the tasks he signs up for and tells his team “by tomorrow I will complete…”  In the context of accountability to the rest of the organization, however, there is no individual accountability at the Team level lest we promote siloed work and blame-shifting and all the other joys of WaterGile.  But in the same context of the rest of the organization, Geri the PO is the single-point of accountability for the “health of the (software) product (that the team delivers every increment).”

But can Geri truly be single-point accountable for the R-O-I of the product?  Because she is also part of the larger team of Product Management, which is team-accountable for making that R-O-I manifest and be something the organization can use.  In the context of the total utility of the software product, one must also consider the teams of marketing, sales, support, training, etc. to extract and deliver full value on the potential of the software product.

So it’s both.  In a single-point accountability culture, the successful Agilist who wishes to use Agile as a process for creating potentially useful software products needs to promote team accountability and individual accountability as appropriate for the context.  Asking which is more important is like asking whether “3” or “blind mice” is more important.

Lowest Common Denominator

Image from http://seoblackhat.com/2008/05/19/to-make-a-fortune-cookie/ and http://www.isaacsunyer.com/dont-be-evil/

Now, this will work for churning out product at a reasonable rate, and Fred Winslow Taylor and members of his Fan Club can clap and sing that Agile will work in a culture of single-point responsibility.  Assuming that your organization has little commitment to the change necessary to achieve the hyper-productivity promises of Agile, assuming you don’t mind flat or near-flat velocity gains, flat team morale, and assuming you are okay with the criminal waste of human potential of churning out product with no real Awesomeness in it — please, be my guest.  Don’t look back, some other companies might be gaining on you.

But if this doesn’t seem to align with your organization’s values, if you actually want people to work better together, to develop their full potential as a team, to realize the power of their diversity and make some truly creative and useful things… you may wish to be cautious with single-point accountability and Agile.

Because you’re robbing people of responsibility.

Responsibility — being a source or cause for results — depends on having the opportunity to be the source for those results.  When you make one person (e.g. the PO, or the SM) on the hook for delivery of the product, people who don’t have the ability to deliver that product, you steal that opportunity away from the Delivery Team.  And that’s the greatest paradox of how I so often see Agile being implemented.

Trying to realize these kinds of gains while preserving single-point accountability for delivery will be about as successful as the possum trying to stop the car.

 Posted by at 8:11 pm