Why are we here? Coherence, Frameworks, Intents and Stories.

zelda_2_adventure_of_link_i_am_error_existentialism

The topic of using stories as a basis for developing coherence in business organizations is complicated in the software world by scrum “user story” terminology. I want to start by clarifying that when I refer to a “story” unless I specify otherwise I am referring to a narrative, not a scrum user story (e.g. “As a…I want…In order to…”) .

The lean principle of “Identify Value” is essential to gaining alignment across an organization. One way to identify value is to increase understanding. Does everyone in your organization know why they’re doing the work they’re doing? When we introduce frameworks like scrum to software development teams we increase the risk of that narrative being obscured by proxy-metrics such as velocity.

If you ask anybody in your organization what they’re working on would you hear a list of tasks to be accomplished by a date or a coherent story? Would they say “I’m currently working on laying down framework x so that I can plug in component y” or would they say “Currently I am helping our business delight it’s customers by making it easier for them to succeed at x?” The former is a description of work that is being done, the latter is a description of an intent. Intents can be “I’m helping us increase our revenue by making it easier for customers to buy our products in the following ways.” but the narrative is often more like: “I am delivering my 9 story points because I said I would at the sprint planning meeting.” I strongly believe there is great value in the former and very little value in the latter.

I believe that the initial concept of the “user story” was to bring some more coherence to work but in time it’s been diluted in practice to the point where it’s become a new more acceptable layer of abstraction from a clear definition of value.

When people understand why they’re doing the work they’re doing they’re empowered to make creative decisions about how that work is done. Ways in which that work can be improved or if the work doesn’t align with the actual purpose of the organization, eliminated. I believe transparent systems encourage innovation, continuous improvement and pride in work.

I recommend creating an environment where coherent purpose is the driving force at all levels. The sooner our organizations move away from productivity measures and toward coherent understanding the sooner we’ll be able to replace productivity with effectiveness, output with value-creation and ultimately work with joy.

 

Posted in Agile, ATDD, Lean, Scrum | Leave a comment

Why Visualize Work?

Image

The lack of transparency in business these days is astonishing. People are managed  by objectives and meaningless proxy metrics so aggressively that a big picture view of value delivery seems impossible. People’s jobs quickly become about pleasing their bosses and performing to expectations in order to receive a favorable performance review at the end of the year. This can lead to politics that are very destructive to the well being of employees and ultimately a business’ bottom line.

Of course there are many useful tools to help create an environment where people are effective and happily delivering on business and customer goals but without visibility there’s little impetus to seek them out. I’d like to share an hypothetical example of why visualizing work can be a powerful tool for continual improvement.

The current state of work:

Silos hide system interdependencies by delineating “clear” roles and responsibilities. People can find comfort by putting work into the following 2 buckets:

1. My job.

2. Someone else’s job.

By doing this people will often prioritize by throwing everything in column 2 out and then cherry picking out of column 1 those tasks that are most likely to make their boss think highly of them. Once we create clear roles and responsibilities and put people in boxes we create a zero sum system. Doing work that fits in box 2 might actually be the best use of my time but I’ll never know because it’s “not my job”.

This lack of visibility has more negative impacts than just misalignment with business goals. It also hides from us the costs of doing business. When somebody is working on things in bucket 1 that feed bottlenecks that are in bucket 2 they create queues. Queues on the critical path cause expensive delays and can have far-reaching negative implications to a business. This system which lacks visibility is usually akin to a tinderbox in dry brush. Eventually it sparks small fires that need to be put out. Expediting fires is not elective work and further disrupts the flow of value to the business and customers.

The people who put out those fires become heroes. Soon bucket 1 is full of firefighting work only and nothing useful is being created. Put out one fire and another one crops up elsewhere. The firefighters become the heroes of the business and get promoted to leadership positions where they mentor hire and train more future firefighters.

When you make the work visible and map that work to value delivery a lot of things change. People can now see the [previously] invisible pain points. Queues become obvious and feeding them seems silly. We can start to see how much actual value is being delivered and identify areas where fires are being set. The value of fire prevention becomes obvious. People can start asking questions like “What’s the most important thing for us as a business to deliver?”

This can be a scary question because often the answer is “we’re not sure,” or more often “It’s all important!” A visual workflow allows those questions to surface and other great questions such as:

-What is value?

-How do we know we’re investing in the right priorities as a business?

-How can we as a group help each other achieve these goals?

The first step to navigating difficult terrain is seeing it. Once we can see where we’re going we’re less likely to fall off a cliff. At least if we do leap off that cliff we’re more likely to have a parachute in hand.

Posted in Uncategorized | Tagged , , , | 2 Comments

Dialogue request: What is a project manager?

I recently hosted a lean coffee during which project management roles and responsibilities were discussed. The discussion helped me realize that this title held many different meanings for people.

The first line of Wikipedia’s entry on project management reads: “Project management is the discipline of planning, organizing, securing, managing, leading, and controlling resources to achieve specific goals. ”

The words in that description are quire provocative to me, but I’d rather hear what others believe.

I am keen to get some more understanding around this prevalent role. This blog post, more-so than others, is an explicit invitation to engage in a dialogue in the comments.

The questions I’d like to use to seed this discussion are:

What does a project manager do?

What problems would you hope to solve by hiring a project manager?

What’s the difference between a project manager and a program manager?

What are the most important traits of a good project manager?

How does a PMP certification make a project manager better?

Okay, so I’ll gladly add to this blog post and maybe even take what we learn from the comments in what I hope will be an educational, lively yet respectful discussion, and aggregate a subsequent post.

I’ll also add that I recognize there are not “best practices” I don’t believe there is a correct answer to be learned. What I hope is for us to learn from people in various contexts what the answers to these questions are for them.

Posted in Lean | 7 Comments

SFAgile2012 Experience Report: Five San Francisco Lean Coffees in Three Days

 

 

 

 

 

 

 

 

I just got back last week from SFAgile2012 conference where I talked with a group of smart people about eliminating silos in a “whole team” kanban and the power of lean coffee.

As is usually the case when I attend conferences that align with my values; it  felt as though I had been transported to the very best parts of my twitter stream. Putting faces to people once known to me only as @OlafLewitz, @MattBarcomb, @LisaCrispin, @JitterTed, @DavidJBland, @Zspencer and @hogfish during the conference and even got to meet @marlenac at the press club monday night and visit with my favorite tester @testobsessed.

I could write about the excellent keynotes:or the sessions where we played with legos to help us learn Cynefin or the fact that some exceptional people like Steve Rogalsky actually changed the content of his late conference sessions to incorporate things he’d learned during the conference.

But instead I’m going to write about why I present at conferences. The answer may come as a surprise but I present at conferences to learn. I’ve yet to discover a better way to learn a subject than to present it to others. There are many examples I could give of brilliant people attending presentations of mine and completely blowing my mind with their contributions. But before that happens I use anxiety to learn from my commitment to present. I have no fear of speaking in public. I have an intense fear of wasting people’s time by yammering about things I don’t understand in front of them. This fear is a big reason I am such a huge fan of open space conferences. Specifically the “rule of 2 feet” which states “If you’re not learning something or teaching something use your ‘two feet’ to leave the session and go elsewhere.” I think conferences, tutorials, open or closed space should have this rule clearly posted on every wall of every conference.

I do not make powerpoint slides and prepare a script to present, I just freak out that I need to make sure I’m as knowledgeable about the subject as I am make myself. I use sticky notes to help anchor my talk and ensure I don’t forget anything critical, but otherwise I’m generally on my own. This seems to work reasonably well when I know what I’m talking about. Consequently there is no better way for me to dive headfirst into a subject than to promise to teach it to a room full of people. My fear of wasting their time will keep me obsessively researching till the minute I walk into the room.

So what did my sessions at SFAgile2012 teach me?

In this case I feel like my talk about removing Silos needs more ideas and to lose the “kanban” label. I am eager to give that talk again about removing silos in organizations regardless of the methodology being used. This is an important subject that deserves attention and not to be obfuscated by attaching it to a given methodology. Silos are harmful to alignment and collaboration regardless of what system is being used to get the work done.

During the three days of SFAgile2012 I hosted a lean coffee every morning at the Blu Cafe at 7AM. On day one we had 10 attendees and as always seems to be the case the level of discussion was first rate. Steve Rogalsky introduced the topic of selling lean to CFOs, Jabe Bloom shared his upcoming talk for GLASSCON and bounced some ideas around how to address 200 government employees about introducing experimentation and lean to their organizations. Jim Benson talked about “Agile in a can” and respect for people. On day 2 we had almost 20 people and day three lots of folks showed up. As is usually the case I wish I had recorded or taken notes to share with those 3 lean coffees.

On Wednesday I presented the power of lean coffee as a session for the conference. I realized too late that while I had prepared an extensive discussion about facilitation patterns, cynefin, and some pitfalls inherent in the process I had missed the most critical aspect of the presentation. I realized that nobody had to teach me how to do lean coffee. The best way to learn lean coffee is to do lean coffee. I decided at that moment that if we had time after the talk we’d break into groups and have lean coffee.

I conversed for nearly 45 minutes about lean coffee wth the group before we split into two lean coffees. During those 2 lean coffees I was reminded of some antipatterns and things I should’ve included in the talk. Ultimately I think the lean coffees were the best part of my session. I bounced between the two lean coffee tables and found it incredibly difficult to observe all the passionate discussion while not diving in myself. My talk was just before the lunch break and each table stayed at their lean coffees well past the end of the session. A sure testament to the power of lean coffee to engage people.

I’ll never again give a 45 minute talk about the things I’ve learned facilitating lean coffee. I’ll present a 15 minute introduction to the process mechanics before breaking into lean coffee groups. After an hour of lean coffee I’ll bring it all back together to discuss facilitation patterns with an audience that has greater understanding and get feedback on those people’s observations of running their own first lean coffee.

During SFAgile2012 I taught myself that silos are a problem many people are interested in solving and that I need to give more thought and research on eliminating them. I also learned what I believe to be the very best way to teach an advanced lean coffee facilitation course. Lean Coffee teaches itself, and once folks have learned from Lean Coffee they’ll benefit greatly from additional facilitation patterns and stories of past challenges.

I learned a ton from the sessions I attended and look forward to writing about them in future posts. I would also like to thank the organizers of SFAgile2012 for the invitation and hope they enjoyed my contribution.

I would also be grateful for any feedback people wanted to give me so I can do a better job on this blog or in future conference sessions.

http://sayat.me/widget/adamyuret

Posted in Uncategorized | Leave a comment

Lean Coffee is Some Powerful #$%^ (Anonymous CTO) SFAgile 2012 preview

Every Wednesday morning I drive down to Kakao Coffee in the South Lake Union neighborhood of Seattle and learn from a panel of esteemed “professors” for free at Lean Coffee.

The experience is nearly always amazing, when it’s not amazing it’s merely great. The mechanics of this meeting are deceptively simple: write ideas on stickies and then talk about them.

The facilitation tools are cheap sticky notes and sharpies. The “professors” take time out of their busy days as practicing coaches, consultants, project managers, testers, programmers, authors, university professors, and entrepreneurs from diverse fields ranging from software development to health care.

We almost always walk away with powerful new insights into very serious and complex life challenges. Topics vary from how to identify and overcome our own cognitive biases to how to facilitate enterprise lean organizational transformation. No one person has the answers but as a collaborative group we’re far greater than the sum of our parts.

Jim Benson and Jeremy Lightsmith founded this powerful convergence in 2009 and due to busy travel schedules attend rarely. Another testament to the power of this thing is the fact that it quickly became a self-sustaining community of practice. It happens every week regardless of the attendance of it’s founders. It’s a living entity that cannot be stopped.

I look forward not only to presenting the power of this system to attendees of SFAgile 2012 but to sharing my experiences as an attendee and facilitator. Additionally I’m going to host a lean coffee in the very early morning hours prior to each conference day 1 block from the venue at Blu Cafe 747 Market St. . I am counting on our east coast and european jet laggards to be bright eyed and bushy tailed for a 7AM lean coffee. :-)

Here is a mind-map I made of the talk/process. I’d love feedback any time.

Posted in Uncategorized | 1 Comment

“Avoiding Silos in Your Whole Team Kanban” SFAgile2012 preview…

Monday June 3rd I’ll be hosting a discussion about “Avoiding Silos in Your Whole Team Kanban” at SFAgile.

The source of this concept comes from my experience with teams transitioning to scrum/kanban/scrumban systems as a tester. In my experience even when WIP limits are applied they are only applied to the development swim lane. Which means as work gets finished it avalanches down into the testing team. The concept that development is a more complex endeavor than testing is a potential driving force behind this fallacy. The belief being that testing is easier than development so you can heap loads of stories onto the testers and they’ll knock it out in a similar amount of time to how long it took to develop.

There are loads of issues with these assumptions. Rigorous, skilled testing can be considerably more time/effort intensive that coding the story. When testing is left until the end as a separate activity the only result of that testing is rework and therefore cards are send backwards along the kanban.

Beyond the testing example, we have different business units interested in the process. How can we have a “whole team approach” if we put walls between engineering and management, or sales and engineering? How do we engage these teams in collaboration?

I have some ideas about ways to attempt to resolve these questions. I have no answers but I look forward to having an active discussion about this important topic. I hope we’re able through this dialog to come up with some ideas to explore further, and ideally we’ll even commit to actionable goals that we can individually strive to achieve.

Here’s a mind-map of the structure of the discussion as I see it, feel free to offer feedback prior to the conference and remember it’s not too late to register and come spend some time with brilliant doers & thinkers in the space.

Posted in Uncategorized | 1 Comment

“Working software” isn’t enough… (Agile Principle #7)

Yesterday, after Lean Coffee, I had a conversation about agile software methodologies with Joe Justice, somebody I greatly respect. I expressed my feeling that the term “agile” has become a loaded one, with many conflicting meanings, and use of it can incite unintended reactions from the community. At the time I didn’t realize that I shouldn’t have said “the community” , as I now believe that it was too narrow in scope and might’ve derailed our conversation a bit. By “community” I meant the software industry as a whole (See: Agile ruined my life and halfarsedagilemanifesto).

We discussed how certain methodologies emphasize the technical team as the boundary for the new way of thinking…emphasizing divisive principles, like protecting the engineers from “the business” so that they can do their best work without interruption. These methodologies overlooks that “the business” consists of people who are also trying to do their best work toward the same goal. I strongly believe that organizational alignment is vital to work satisfaction, and being happy is vital to doing our best work.

I am certain I made some tired arguments about local optimizations that de-optimize the whole, when Joe put us back on track by explaining what “agile” means to him. His guiding agile principle (see:Principles behind the agile manifesto) is the 7th: “Working software is the primary measure of progress.”

I got to thinking about this and it started to dawn on me that this is a very easily misinterpreted principle. The definition of “Working software” can be very broad indeed. If software compiles without build errors does that mean it “works” or if it runs successfully through the happy path?

Let’s say for the sake of argument that the software is bug free; meaning it works exactly as specified and no defects exist. What if the customer doesn’t want it? Or there is no market for this mythical flawless feature? What if that feature was very expensive to produce? We’ve made working software, but was it an effective primary measure of progress? What if the engineering team worked so tirelessly on producing this software that they all hate their jobs? Eric Ries calls the aforementioned “Achieving Failure”: Delivering on time, and on budget a low defect, high-quality product that nobody wants.

I think working software as a goal is a good one, but when we silo the engineering team and “protect” them from “the business” we create an adversarial environment between groups that have the same goal. To enrich the lives of their users by producing an experience so great as to compel the customer to clamor for it and tell their friends.

Maybe a better wording for that principle could be “Delivering amazing experiences to customers at a sustainable pace is the primary measure of success.”

I could go on about the many ways one could misinterpret those words too, but I’ll leave that to the commenters. :-)

Posted in Uncategorized | 4 Comments