My 12-minute recognition video for the nominees of the 2014 Brickell Key Awards — is available on YouTube. The nominees are recognized for outstanding leadership in #lean and modern #management methods, advancing the cutting edge of the #lean / #kanban community.
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?
I recently spent a day helping the leadership of an organization make the leap from “can we become Agile?” to “now we’re becoming Agile!” The problem was one of mindset: getting people to think less about barriers and more about what actions are possible. My solution involved hands-on experiential learning and structured group debriefing.
I’ve written about it below, but I’m a visual person so I’ve added a lot of captioned pictures if you want the gist, and the how-to “recipe” for doing this mindset-shift yourself is at the end.
At Agile Coach Camp I conducted a small session on balancing advocacy with inquiry when debriefing or trying to defuse tense situations. Olaf Lewitz gave a very kind write up of the session (with pictures!) in his blog post Test-Driven Conversations and explains the learning he took away from the session. Thanks, Olaf — and I love the title!
I did have a tweaks to the explanation, having to do with the example of Joe seeing Jim throw a plate on the floor, where Jim says “…if I was doing that I’d have been crazy.”
That’s an example of a judgmental statement couched in advocacy/enquiry language. The judgement there is “you are crazy” and the interaction is tending toward the implication that there is some fault on the part of Jim.
If Joe were truly approaching the situation with desire to find out Jim’s internal motivation and wished to balance advocacy with enquiry, Joe might have said something like:
“I saw you throw that plate on the floor (fact), and I was frightened because to me throwing things is a sign of anger (advocacy). Can you help me understand what was happening? (enquiry)“
Advocacy requires that you expose your own internal frame/motivation, which doesn’t necessarily mean keeping your emotions to yourself — it just means that you expose them directly by stating what they are, rather than indirectly through tone of voice, gesticulating, etc.
Of course, being able to do this requires that you know what’s going on inside your own head too… not always easy to be aware of when emotions are high. :)
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
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.”
And has been –
From the very start.
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.
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.
I’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!
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.
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)
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
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.
I had sent an “attaboy” email to one of the developers on my team for doing a great job in communicating and being visible to the rest of the team. (Don’t punish bad behavior, “catch” and encourage good behavior, right?) Not having previously received encouragement for anything less than heroics, the developer was perplexed upon receiving my email. Was I upset with him?
No, I explained, I just noticed he was being visible and wanted to encourage him to keep it up. “Consider that email a round of applause,” I said. Brian (another developer on the team) overheard this and then told us of his “Praises and Curses” email folder.
As it turns out, Brian collects emails from people when they thank him for doing a good job, or when they are upset and wish he had done something differently.
But he doesn’t just collect them — he reviews them. At least once a year prior to performance reviews. And sometimes more frequently.
Now, just to put this in context, Brian also uses the Pomodoro Technique in his daily work. So what we have here is an individual — a so-called “technical” person, no less – who:
- works in discrete intervals, identifying interruptions and tracking velocity
- inspects the feedback received as a result of his work
I gaped. What an incredibly good idea: building in the means for self-improvement that just sort of “happens.” No need to depend on the performance review as the only means of formal retrospection, simply collect the information as it comes in, and review at your leisure.
How many of us set up these kinds of mechanisms in our lives — feedback mechanisms which help provide awareness? What would life be like if more of us did this?
So, I’ll be participating in Scrum Beyond Software in Phoenix later this September.
I have a bubbling head full of ideas to share there, and as a collaboration junkie, I’m making them visible for comment. Suggestions? Criticisms? Want to join me in Phoenix and collaborate? Leave a comment!
Topic 1 — Science: A Framework to Aid Scientific Research Teams
Scrum is, at its heart, a simple empirical framework for learning and discovery. Often it’s used to “discover” the unbuilt-but-needed features of a software product, and so people confuse it with a product development methodology. But it’s more than that — Scrum is also useful for process improvement or organizational change. Scrum is even self-modifying: it can be used to “discover” the best way to shape the framework itself to help make the team using it more effective.
When you generalize Scrum this way, it seems pretty obvious to try to apply it to how teams “do science”:
- backlogs as analogs of hypotheses
- swarming as part of research
- team-synchronization via standups and lo-fi tools rather than long publishing processes
- scrum of scrums to synchronize multiple teams
- demos and retrospectives as analogs of findings and conclusions
These are fairly naive mappings; I hope to make richer ones in Phoenix.
Topic 2 — Healthcare: A Framework for Training Medical Teams
I first mentioned this in a Twitter post inspired by discussion at the 2010 Conference of the International Association of Medical Education.
It seems to me that much of the thought in medical education views education as a rather linear, deterministic process, using what Bob Marshall calls “analytical models,” as contrasted to empirical, stochastic or even chaordic models. Example: a “learning process” depends on:
- a set of initial “learning outcomes”
- guided “deliberate practice” where students work either on medical tasks, or simulated scenarios (as a team, no less!)
- “reflective learning” where students debrief and self-assess.
To a Scrummer like me, this just screams “backlog, whole-team execution/delivery, retrospection, REPEAT” and also embracing student/team learning as a chaordic rather than deterministic process. Unfortunately I see some of the literature and discussion in the medical education world take a rather “one-shot” approach to training: Students come in, execute, and now they are “trained.”
Some topics and questions I’d like to raise in Phoenix:
- How might we frame learning in the context of Scrum? By individual lesson (sprint), and as an entire curriculum (release)?
- Comments from people in the medical training/simulation field? How have you used something similar to Scrum?
- What are the problems with taking an approach driven by feedback loops rather than a stepwise process?
Topic 3 — Healthcare: Patient-Centered Treatment
Inspired by Compassion as a Golden Rule for Healthcare and Real Participatory Healthcare Starts With Assigning the Patient to Your Team (same author)
I need to give more thought on this — or ideally jam with another collaboration junkie — but the nebulous ideas here are:
- Linda Rising’s talk at Agile 2009 about how people who solve problems together, despite their backgrounds or knowledge, feel more empathy and understanding for each other
- How this effect brings diverse skillsets on an expert team together, despite egos and fears, and makes the team more effective at problem-solving
- Mapping the patient, and patient’s family into the role of “user”; mapping the medical staff into the role of “team”, and then:
- Using the Scrum framework as a structure in which to allow these roles to interact.
- How this is very different from the standard model of “lead physician interacts with patient/family, and specialists mostly interact with lead physician”
- Who should be the ScrumMaster and Product Owner?