Changes to My Personal Kanban

I thought you might be interested in some improvements I made to my personal kanban wall this week. I know these aren't the best pictures, but below you'll see a before and after view.

FLOW
First, I reversed the board to flow right to left. This feels more like pull to me. I'm pulling work from the right rather than pushing work to the right. I think this will feel more like pull whenever the board is directly in front of me, or a little off to the right. If I could position the board out to the left of my desk, moving stickies left to right might feel like pull.

HEADERS
I prettied up the headers. The others were ugly. I was tired of looking at a sloppy wall. I don't mind the transient stuff to be sloppy, but I wanted the headers to be a little more neat. I could have done a decent job if I took my time, but I decided to ask my awesome wife, Laura, to make new headers for me.

As part of that, I cut the header stickies down to about a third of the size of the stickie. This, plus writing them with a sharpie, makes them look more like headers and also not take up so much space. This allowed me to feel free to move the header below the window muntin. When I first put the headers above the muntin I thought the muntin would feel like a heavy underline separating the header row from the other rows in a table. I think the muntin was too big for that to look right. Didn't achieve the desired effect.

Before

After

IMPORTANT/URGENT
I used to have "This Week" and "Today" columns. I really liked the "Today" column. I have been making a fair attempt to plan a day and a good attempt to do today's stuff today. But "Today" didn't always mean today. Sometimes it means "today or tomorrow but don't wait until the end of the week". Really, it meant something more like "Important and/or Urgent, don't let it slide".

Compared to how I planned and executed my days, I have been making a better attempt to plan a week but I didn't stick to the plan as much as I thought I would. For the most part, that's okay. I adapted as priorities shifted and as opportunities presented themselves. But I also let important stuff slide. "This Week" really meant something more like "Important and it might become Urgent if you let it slide".

Not sure how it will turn out, but I've now got Important, Urgent, and Important-and-Urgent columns. I can already see that I have lots of Important stuff. I couldn't really see that before. At least I'm not buried in Urgent stuff.

NOT READY
I also used to have lots of todos stuck over on the window stile. It was clear that I needed more room for my backlog. In addition to the stuff I had planned for Today and This-Week, I had all kinds of other stuff that I thought I should make a stickie for. There was stuff I wanted to do, but I just wasn't ready to do them. There was stuff that wasn't ripe; the timing wasn't right or there was another task to do first. All these things aren't exactly the same as Waiting. For me, Waiting is waiting for someone else. So I created the "Not Ready" column.

I had been putting recurring tasks above the header. That's stuff I wanted to do each week. I may still do that.

MAYBE
The new Maybe column is for stuff that is ready to pull but that isn't quite that Important yet. These tasks are things I can do if the mood strikes me. If I have the energy and focus to do a Maybe task but not the energy and focus to do something Important, then why not pull a Maybe task? This is a concept from Getting Things Done (GTD). There is a lot of overlap between GTD and personal kanban:

Get stuff out of your head and onto a system you can trust to free up your mind and then do the most important next-action that you have both the time and energy to do, taking advantage of opportunity and location.

I have an additional pile of Maybe next-actions in the front of my GTD card file on my desk. Here is a photo of that:

DONE
I've been stacking my Done stickies starting at the BOTTOM of the Done column, each one slightly higher than the one below it. This keeps the sticky part of the stickie on the glass so they don't fall off, but takes up less room on my kanban wall. This obscures the title of the done tasks underneath the top one, but that hasn't bothered me.

I clean off my done column each week, record my velocity (which I haven't really done anything with yet), have a retrospective, recycle the old stickies, plan my next week, and plan my day. I didn't make any changes to that.

DID YOU GET ANY IDEAS?
I hope you got some good ideas from this post for improving your own GTD or Personal Kanban. Would love to hear about any changes you plan to make after having read this. Before you go away, please post your immediate thoughts in the comments.

Use Physical Story Cards

Sometimes you want to use an electronic Agile Application Life Cycle Management (ALM) tool for managing your user stories. There are benefits to using a tool. They have some really nice features, some of which can't be done in the physical realm. And sometimes you've just got to go electronic; you have no choice. But even if you've gone virtual, there are still benefits for having physical cards as well.

I like having my user stories on physical cards. Conversations are richer, and shorter, when you can point and ask "What's the difference between these two stories?" and the answer is "THIS story is about… but THAT story is for…".

Planning poker is great, but the Team Estimation approach is often better, especially if you have a dozen stories or more. I love it when someone can tell the team "I think THIS story is smaller than THAT one and larger than THIS one" and everyone immediately understand which stories he's talking about.

Relative prioritization is easier when you can slide around some physical cards, especially if you need to prioritize collaboratively. "I'm okay with what we've laid out here, but if you think THAT story is THAT high a priority, you are nuts!"

I recommend having a pre-planning meeting to help make iteration planning will go well. That first pre-planning before a team's first iteration planning meeting is particularly difficult. You don't know what your velocity is. You don't know how much you can get done. You may be unsure of dependencies. All this agile stuff is new. And you need to get several people to feel confident that the 1st sprint planning will go well. You have this large backlog of stories and you want to be sure everyone understands what we're sure we're putting in, what we're considering to put in, and what we're not putting in. So lay it out on the table. I love being able to slide cards around on a table and to be able to literally put something aside for now if it's giving us grief. It's not off the table, it's not out of sight, it doesn't look like it's still in the list, but it won't be forgotten. "Let's come back to THIS one later."

Story mapping just has to be physical until we get inexpensive wall-size touch-screen monitors and story mapping software.

I've worked with clients that were very happy with their ALM tool and large monitors. I was impressed with their dedication to making agile work, their open space, and these monitors for each team. But as big as the monitors were, it still just seemed easier to me to manipulate and read fat sharpie on index card. And I can write SPLIT on a card faster than I can tag it as too big in an ALM tool.

Sketches are interesting. A picture is worth a thousand words. Would be harder to do this on anything other than paper.

But using an ALM tool doesn't mean you can't have physical cards too. It's pretty easy to write the story title and estimate on an index card. You can write the story's ID number from the ALM tool on the card. You can also print story cards from some of the tools. VersionOne has always had a printing solution, but the version coming out in August 2012 will have the ability to print directly from the tool.

I've heard of other tools that make it easy to print, but I can't name them off hand. If you'd like to mention your tool in the comments, please do.

Lots could be written about keeping physical cards and an ALM tool in sync. I'm going to ignore keeping a Scrum card wall in sync in order to keep this post on the short-side, but I will add the following. If you are using physical cards for a prioritization or sizing exercise then just enter the updates back into the ALM tool and discard the cards -- or hang on to them for some other purpose if you want. The point is, the cards served their purpose, they are transient, update the tool and you are done. I could also approve of doing a story map at the start of a small release, then leave it on the wall as is as a historical vision document while the ALM tool becomes the plan of record. I also recommend sticking with physical cards through Iteration Zero and Iteration One. What's cool in I0 and I1 is using the same cards for socializing, estimating, prioritization, pre-planning, and finally planning and the daily standup, then seeing a gold star put on that sucker once it's done.

Bottom line: Keep using physical cards. I promise it will be worth it.

Consider Stories at Multiple Levels

I often work with teams adding new large features to existing applications. It is common for teams like this who are new to agile to go into too much detail too soon. It seems that those accustomed to waterfall believe you've only got one shot to discuss any requirement, so they must discuss it in detail.

In agile you get many looks at each user story (requirement), preferably from many different angles and ultimately getting progressively more detailed as you go. I like to explain it with these four levels.

VISUALIZE -- The Concept

We typically start with a project name or enhancement name, don't we? It's the handle by which we call this thing. From there we hope to have the vision, a short narrative for what we're after. Perhaps we have the name of a few super-epics. Refine that into some epics. Begin to understand the minimal marketable features (MMFs). Metaphorically, this may be an aerial view of the forest, or maybe the planet. Keep the vision in front of the team throughout the project.

PRIORITIZE, ORGANIZE and SOCIALIZE -- The Forest

By prioritize and organize, I mean use any approach to help the team see how the stories fit into the vision and understand the minimal marketable feature set. An example technique is Story Mapping. Understand your epics. Metaphorically, this is understanding what the forest full of trees looks like.

None of these are a one shot deal. Iteratively refine your prioritization. Tune the MMF and re-socialize stories as you learn and get feedback. You aren't done socializing just because sprint zero is over. For anything of size, you don't get done socializing in just one meeting. Nor does all the socializing happen in meetings.

SIZE -- The Trees

When sizing (with abstract relative points), look at your stories in a little more depth, but not to the level of detail described below. Look at it just enough to give an estimate relative to the other stories. You don't need as much detail for a relative estimate as you would for an hours/days/weeks estimate. You quickly get to a point of diminishing returns. Consider that we use a Fibonacci series or something similar -- we use a diminishing level of precision as the stories get larger. Once you are pretty confident that it's a 21 point story, you don't need to spend more time to make sure it isn't really a 13 pointer.

As with the above, you may look at a story for sizing multiple times. If you've sized a bunch of stories at the start of a release, you should re-size the remaining work after 3 to 5 iterations. By then you've learned more. You will have become more familiar with the project, subject matter and the affected code.

Sizing also shouldn't be expected to be static. How big a 3 point story is will shift over time, especially but not only because of changes in the team. Hopefully the individuals are getting better, smarter, and the code is getting cleaner. Also, the work that we're comparing stories to changes. Point-drift happens. Old estimates are like milk -- they don't get better with time.

PLAN -- The Details

In iteration planning we break stories down into tasks. We estimate tasks in hours or half-days or maybe in pomodoros. We think in terms of detailed design and code and test cases.


Understanding that we're going to see each story multiple times with progressive levels of detail helps overcome the desire to go too deep too soon.

What approaches have you used to help people think about stories at the appropriate level?

3 arguments against BLOCKED and a bonus on IMPEDIMENT

Why I don’t like "blocked" –

In some companies, people don’t want to say they are blocked.

(1) Being blocked gives you a sense of blaming others. Not wanting to offend coworkers...

Yes, I'm waiting on Joe, but he's not blocking me!

But we want honesty and need safety. I need a safe environment so that Joe and I can agree that Joe's blocking me. It's not Joe's fault. It just is. And it needs to be a safe environment especially if it is Joe's fault.

(2) Being blocked gives you lots of scrutiny.

No! I’m not blocked! Don’t help me!

But that’s exactly what we want – attention on the problem, but in a servant leadership collaborative way. Too often, blockers attract the wrong kind of attention.

(3) Being blocked sounds so absolute.

...and I'm not totally blocked anyway. There's some other stuff I can do.

Yeah, less important stuff. Probably stuff we shouldn't be doing anyway, unless it's taking advantage of slack to sharpen your saw.

(4) Having an impediment sounds like a medical problem.

No, unh-uh, no impediments here.

Impediment is such a funny word. Who introduced that into the agile vernacular anyway? Nobody uses that in normal speech. People new to agile likely don't even know what that means.


That's why I like to ask "what's slowing you down?"

"Oh, yeah, my PC's a few years old. I don't have very good test data. The A/C shuts off at 5:30p each day. I have to make two hops to remote into the test-lab because of security reasons. The build server builds once per day instead of on check-in. The unit tests are taking a few minutes to run; I think someone put something bad in there. We should find it and move the offender over to the regression suite or make it faster. Why can't we get some stickier stickies? I'm waiting for Joe to give me access to the production server. And I keep getting interrupted by customers bypassing the support desk… Sure. Lots of stuff is slowing me down."

Ah. Great. Now that I know, we can go work on that.

Constellations and Deep Democracy

Constellations can be used as effectively with just one or two statements as well as with dozen, making it an effective tool for Deep Democracy.

One of the tools I picked up from Lyssa Adkins' book, Coaching Agile Teams, is called Constellation. (It really should be plural, Lyssa.) Briefly, the purpose of Constellations is to gain a better understanding of your team and their individual preferences, values, interests, or opinions.

Mechanically Constellations works like this: Put something in the middle of a big open room. Have everyone stand in a big circle around this object. Explain that you are going to read some statements. (Such as: "I like Scrum." "I get value out of our retros." "We should TDD more." "I think Agile will work for us." Etc.) Instruct the team to orient themselves closer or further away from this object after each statement is read to represent the extent to which they agree with that statement. If they agree, move in. If not, move out. Tell them to not over think it. Tell them to stand where their heart and head tells them to stand, not where they think they should stand. Then have the team observe the Constellation of people and discuss what it means. There are some considerations for how that discussion is facilitated, but that's a topic for another post.

The way it's described in the book is that the facilitator might want to read numerous statements. This is a great way for a team to get to know each other. I've done this exercise with about a dozen different teams. Now, I'm no longer surprised by what I find. A common surprise to the team is when they discover that their Product Owner doesn't like to run the demo but that someone else one the team has been dying to do it. Another: There's often an ah-ha moment when the team begins to understand that the quiet person just needs time to think before he speaks.

Anyway, I've done this lots and lots and have used 20 to 40 statements each time. Some of the resulting Constellations aren't interesting. I move on quickly and don't have discussion for those. Some are very revealing. I have a short discussion on the spot for those. Even the teams that are well established have interesting revelations using this technique. The number of questions and amount of discussion is bounded only by the team's willingness to continue standing.

Building on Michael Spayd's talk on Deep Democracy at Agile 2009, during the Atlanta Scrum Gathering in 2012, Lyssa Adkins and Michael Spayd led a Constellations exercise and only asked 2 questions.

They used the technique for Deep Democracy (Arnold Mindell). They were working with a large random group of people from the conference; I usually work with a team that has at least a little work history, and often a long history with each other. They facilitated the discussion carefully, more carefully than I would with a known group. Lyssa started with the inner ring and encouraged all voices to be heard, one ring at a time, an important aspect of Deep Democracy. Lyssa was careful to give voice to each ring in the Constellation and to set the ground rules: don't state that someone else's opinion is wrong or challenge someone else, use "I think" or "I feel" or "my opinion is", all opinions are valid, I will step in if you violate these rules, etc.

What I learned directly from Lyssa that I didn't get out of the book is that the Constellations technique can be useful with just one or two questions. In particular, it's useful when you have a specific narrow topic, even a controversial one -- when Deep Democracy is needed. This can provide a safe environment in which to speak and allows the facilitator to manage diverse opinions in a logical progression. It's also useful to reduce the number of questions as the size of the team grows (since it takes more time to allow more people to voice their opinion).

I would love to hear about your experiences with Constellations and Deep Democracy, together or separately. Are there other variations on this theme? Other ways to use this technique?

For the Sake of a Productive Retrospective

Even good, competent, and valued people sometimes have an off day, make an ill-advised or selfish choice, or are just plain mindless.¹

Like many others, I'm not quite satisfied with the Retrospective Prime Directive as it's written. I understand and appreciate Dinwiddie's explanation of it, but as a useful tool, the directive doesn't strike any chords for me. What I think the directive is trying to say is:

Retrospectives are not about blame. They are about moving forward.

So why not just say that? I'm fond of Tobias' take on it (with another phrase² inserted):

We are emotional and vulnerable beings, subject to a continuous flow of influences from a myriad of sources. Sometimes we perform magnificently, other times we mess up. Mostly we are somewhere between these extremes. In this last period of work everyone did what they did, and likely had reasons for doing so.
     Bearing in mind that there are many factors of which I am unaware.²
Accept what is. And now, what can we learn from our past actions and thinking that will inform and guide our future ones?

Whenever I'm working with a team that is still struggling to create a safe environment, I also suggest "quietly considering" this:

I will ensure that we have a safe environment
in which we can each own up to our own mistakes own our own
and endeavor to not be defensive if someone else points out my mistakes.
If someone gets defensive, we'll assume that the environment is not safe
rather than assume a personality flaw.

1. Stone, Patton, Heen, Fisher, Difficult Conversations: How to Discuss What Matters Most, Penguin, 2010, page 287.

2. Wallace C. Ellerbroek, MD, “Language, Thought, & Disease”, The CoEvolution Quarterly, No. 17, Spring 1978, page 33.

Management at the Solstice

The winter solstice is upon us here in the Northern Hemisphere. The earth is tilted on its axis, making the days shorter as the earth goes about it's elliptical orbit around the sun, reaching the shortest day on the winter solstice. This doesn't coincide with the dead of winter, however, because of seasonal lag caused by us having lots of water around, giving off stored heat. (A little something to look forward to -- three more months of cold weather.) Speaking of colds, our solstice does, however, occur right after the start of cold and flu season. Lower relative humidity indoors and us being indoors more makes us more susceptible to viruses. The shortening days and more time spent indoors gives us the winter blues. Depression, more prevalence of illness, compounded by the dreaded annual performance review and holiday stress makes a nasty combination. All of this ultimately leads to poor productivity and unhappy people.

So what? What's that to do with me?

The manager's job is to create an environment in which people can be productive, even healthy. Help your team attack the winter blues and defeat viruses. Help them find their happy hat.

But how?

You've got to come up with your own ideas for your own environment, but here are some examples.

Improve lighting for a better mood. We might be saving energy, but we're killing productivity with those glare and headache inducing, flickering fluorescent lights. Indirect non-fluorescent lamps are easier on the eyes. Or set up a light therapy room in some meeting room or office. Why not?

And sunlight is great. Open the blinds and schedule some outdoor activities, maybe a team lunch that you can walk to or at least drive to. In other words, get out of the building during the middle of the day.

Stock the break rooms with fresh fruit, nuts, and disinfectant wipes. Oranges are great to have around, being good for overall health. The smell of a fresh orange around the office makes people smile inside, doesn't it? Apples are easy to wash and eat and some say provide a pick-me-up as good as coffee. But please, get a good eating apple like a Pink Lady. Shoot, do something unique -- buy and peel a pomegranate for each person in your group. Most folks have probably never seen a pomegranate. You'll be expanding their horizons.

As for nuts, we grow tired of peanuts and who likes cashews anyway? Try pecans, the healthy nut with the highest amount of anti-oxidants. Almonds and walnuts work too.

While you are passing out the hand sanitizer and disinfectant wipes, encourage hand washing.

Do this and you'll create a happy, healthy work environment. Happy people are productive people. For more bright ideas, check out last December's post.

Yet Another Agile Reading List

(Updated October 2018)

I'm often asked for an agile reading list and each time I wish that I had already blogged it. What's kept me from doing it so far is that I tend to write a somewhat new list each time depending on the requester's level of experience, unique situation, and context. Such a list is also likely to change over time, but that shouldn't stop me from posting it -- this post is my thoughts at this point in time. My thoughts are likely to change.

That said, and without further ado or proof reading, here is an agile reading list.

Getting Started
Just go read the Scrum Guide. If you've never read it, you really should. It's short. But you might need something beyond that to gain a better understanding of how and why agile works, so don't stop there...

I could make this easy for me and just say read Cohn's signature series plus the Beck signature series. That'd keep you busy for a while and cover the topic pretty well.

But I can put a little more effort into this. Don't let this long list scare you. Start with this 1st block, then supplement with some of the others. I'm writing this from the point of view of helping a total agile novice get started.

Most importantly, you need to understand the agile values: http://agilemanifesto.org/ and http://pmdoi.org/ and either http://www.extremeprogramming.org/values.html or http://www.softwarereality.com/lifecycle/xp/four_values.jsp or http://xp123.com/xplor/xp0209b/index.shtml.

Here are some links about agile in general and two specific agile processes, XP and Scrum, and one lean/agile approach called Kanban. Just read as little or as much of these as you desire to get the gist of what it's all about:
http://en.wikipedia.org/wiki/Agile_development
http://en.wikipedia.org/wiki/Extreme_Programming
http://en.wikipedia.org/wiki/Scrum_%28development%29
http://en.wikipedia.org/wiki/Kanban_%28development%29

You need a good understanding of the Scrum process since it's the market share leader right now. I really really like Kenny Rubin's way with words and his Essential Scrum book is excellent. This is good: Succeeding with Agile: Software Development Using Scrum by Mike Cohn. Subscribe to Mike's blog.

Here's a good short, quick, easy to read intro to Scrum: "The Elements of Scrum" by Sims and Johnson. It includes some extra stuff that you really should do if you are using Scrum. I liked that. Well written.

I think I'll throw in http://scrumpocketguide.com/# from my friend Peter Saddington. I haven't read it, but it sounds short. :-)

Alternatives or Slightly More Advanced Items
Subscribe to my blog and LeadingAgile's blog :-).

These next few are a bit old, but you need to have read something by "Uncle Bob" and Alistair. You could substitute some other book by them if you wish:
Agile Software Development, Principles, Patterns, and Practices by Robert C. Martin.
Agile Software Development by Alistair Cockburn.

These eXtreme Programming books are great and short and solidly apply to Scrum:
Planning XP by Beck.
XP Installed by Jeffries.
XP Explored by Wake.
Don't get the original white XP Explained book by Beck. It's talks about Load Factors and Ideal Engineering Days which I don't recommend.

If you want to broaden beyond Scrum and XP, read about Crystal Clear and the other Crystal methods by Alistair Cockburn.

Product Owner
Now we move beyond the basics into some specifics. First, let's take a look at the Product Owner related literature:

http://www.agilemodeling.com/artifacts/userStory.htm

Agile Estimating and Planning by Mike Cohn.

User Stories Applied: For Agile Software Development by Mike Cohn.

Here are some great posts from my colleague on The Product Owner:
http://www.leadingagile.com/2011/03/why-a-product-owner-team/
http://www.leadingagile.com/2011/03/product-owner-team-who-needs-to-play/
http://www.leadingagile.com/2011/03/one-real-life-product-owner-team/
http://www.leadingagile.com/2011/03/product-owner-team-design-considerations/

Scrum Product Ownership by Robert Galen. It's not an intro to agile. It's a good, thorough book on product ownership. It's full of good advice and tips and warnings against certain dysfunctional behaviors. The book contains some typos and passive voice that will annoy some people.

The Product Owner role in agile is a big job. And very important. Many say it can't be filled by just one person because no one has all the necessary skills. They say you often need a team of people with diverse skills and responsibilities to do the job well. I tend to agree. Here is some food for thought:
http://blog.xebia.com/2008/05/22/scrum-the-mythical-product-owner-role/

Scrum Master
Next, someone on your team needs to understand retrospectives in depth. If you don't get what you need to know out of the above books, this one is wonderful: Agile Retrospectives: Making Good Teams Great by Esther Derby. Subscribe to Esther's blog.

I highly recommend Scrum Mastery by Geoff Watts. This is an excellent book filled with very practical and though provoking advice.

Lyssa's book, Coaching Agile Teams, is very useful, but the novice should read the others first.

Technical
Here are some more assorted topics:

Agile Testing: A Practical Guide for Testers and Agile Teams by Lisa Crispin. And check out her sequel also: More Agile Testing.

Read Beck's TDD book, Fowler's Refactoring book, Evans' Domain Driven Design book, and Williams' Pair Programming book.

Specification By Example by Gojko Adzic should be in this list as should The Cucumber Book by Wynne and Hellesoy.

Lean
At some point, you might need to know what people mean by Lean as it applies to software. Poppendieck wrote the books on it:

Implementing Lean Software Development: From Concept to Cash by Mary Poppendieck

Leading Lean Software Development: Results Are not the Point by Mary Poppendieck.

To really understand lean, really and truly, read Toyota Kata by Mike Rother. This is about getting everyone in the org to make process improvement part of their daily job, to be very intentional about understanding the current and target condition, and to be very intentional about mentoring everyone about everything I just mentioned. This text will help you have a proper understanding about everything else you read about lean, all the techniques, all the metrics, all the approaches. 

Then read The Goal: A Process of Ongoing Improvement by Eliyahu M. Goldratt, a delightful book. We also have his Theory of Constraints (ToC) text. Goldratt is becoming a very important person to have read, at least for lean/agile consultants.

However, if you read Goldratt, you must also read The Principles of Product Development Flow by Reinertsen. Reinertsen takes exception with the over simplified or at least naïve implementations of ToC (et. al.).

ToC brings us to the kanban process which is gaining popularity. Kanban by David J Anderson is a wonderful book,but lacks specifics on how to do the metrics when the rubber meets the road. Subscribe to the kanbandev yahoo group. Anderson's Agile Management I would say is more advanced and should be read by serious agile managers or coaches. It's a good cross section of lean, pre-kanban, ToC, etc.

Rother's book Learning To See is about value stream mapping from a manufacturing perspective. I enjoyed working through it, but i'm weird that way. Most people in software development organizations won't need this.

Scale
There are books on scaling agile: Practices for Scaling Lean & Agile Development by Larman and Vodde. And Scaling Software Agility, Leffingwell.

Manage
Management 3.0 by Jurgen Appelo is the most important book for anyone leading or managing IT knowledge workers.

Dan Pink's Drive: understand autonomy, mastery and purpose.

Not sure whether to put DeMarco's Slack, Getting Past Burnout, Busywork and the Myth of Total Efficiency here or up under Lean. I have a blog post on slack.

Fin
Sadly, I cannot recommend this book, even thought I have a chapter in it: XP 2003 Proceedings.

Finally, find a local agile/lean/scrum user group to attend and make connections. I can tell you all about the ones in Atlanta and can connect you to people who know all about the ones in Ohio and Chicago and RTP, NC.

There are probably a thousand other folks with their own agile reading list. I wouldn't mind it at all if you were to post your list here or link from here to your site.

Slack and the Manager's Role in Scrum

photo credit: flikr dcwriterdawn

In his book Slack, Tom DeMarco makes the point is that you can't be creative when you are overworked or overburdened. Stress kills innovation as does busyness. To be creative, your mind needs to feel free and unallocated, uncluttered even.

In a waterfall shop, slack abounds. There's the project fuzzy front end where some are idle. There's the test and fix or stabilization cycle at the end of the project where some folks are slammed, and others are trying to not look as idle as they are. And there are times in the middle where this person or that one doesn't have enough work to do. Or maybe they are blocked. If you can put that slack time to good use improving the product, the work environment, your skills, or your process, then good for you.

The problem with Scrum and eXtreme Programming in particular and with iterative development in general is that they wring all the slack out of an organization. There is no unaccounted for time on a Scrum team. You must deliver value in every story. Every sprint must deliver valuable working software. You must help your teammates finish their work for the sprint if they get in a bind. Or add another small story to the sprint if possible. "If ya ain't working on the sprint backlog, ya ain't getting paid!" Little slack leads to little time to look around leads to little improvement.

Thankfully, we have a solution.

We have more than one, in fact. Let me first tell you about the solution that this article is not about. You can introduce slack into your organization with regular slack time. There are numerous well known examples of companies that do things like Fed-Ex days, time set aside for self-directed work, not allocated to Prioritized Product Backlog Items. Dan Pink recently endorsed this approach. As an aside, I like what Dan has to say about what motivates knowledge workers.

But there's another solution to the lack of slack that we should entertain first. In fact, you are less likely to do the FedEx day if you aren't first doing the following. But to introduce this I must first point out something that Scrum says about managers. Scrum doesn't say a whole lot about managers, but it does say at least this: mangers must stop assigning tasks. Too bad that many managers get their power and sense of self-worth from this activity. Deciding how to get the work done in Scrum is left up to the self-organizing cross-functional team. The people who can best decide how the work should be done are those closest to the work.

Just to be clear, managers in Scrum and eXtreme Programming should not:

• make assignments
• hand out work
• direct people or tell them what to do
• make the hiring decision solo
• SW architecture (in my opinion - debatable)
• do work
• be an individual contributor
• be a hero

Well, gosh, then shat should a manager do? Well, I'll tell ya! You could manage more people. You can still step in when the team needs help (but not too quickly). You are still an agent of the company, handling legal stuff, signing off on expenditures, etc. You can still manage risks, especially if you are a skilled Project Manager.

But you could also do something else.





Be the Slack.

Move up to a higher level of value to the organization. Be the slack that has been wrung out of the team. Here are some specific suggestions:

• Keep an eye on the system, looking for improvements
• Ensure cross-training is happening (not by making assignments, but making the team handle it)
• Understand the dynamics of the organization
• Understand how value is created
• Protect the team from interference
• Make the organization effective; learn to look at it as a system
• Support the team
• Clear roadblocks
• Provide good facilities -- fight the facilities police (better: teach facilities how value is created and how better facilities helps you guys create value)
• Ditto with more powerful computers, sufficient build machines and test machines (the people on the team are far more expensive than a PC)
• Use Derby's 13 essential questions for managers or the book on this topic she is working on
• Read Deming
• Watch interpersonal interaction -- watch when one team member pulls back, withdraws in a brainstorm (for example)
• Help the team learn TDD by making room for them to learn (time - remove the schedule pressure while they learn)
• Understand the capacity of the team (also a team and scrummaster job)
• Think through policies, procedures and reward/review systems and improve them (what messages do they send?)
• Understand what motivates knowledge workers (see the previous reference to Pink) and let creating that kind of environment be an imperative

I contend that we should focus on continuous improvement of process, of people’s skills and knowledge, with a strong focus on empowerment and self-organization. And work on open, honest feedback. You’ll have better results if you do all that and just completely scrap the individual annual review.* I love quoting Drucker here: "“the average person takes 6 months recovering from a performance review.”

I'm really straying off the point of the article there. Let me bring it back together by saying you can't do a good job with this other higher value stuff if you are down in the weeds assigning tasks to people. Delegate more. In fact, delegate everything, freeing yourself up to be the ultimate in valuable slack.


----------------------------------------------------------------
* Not sure if that sentence is in my words or whether I've co-opted someone else's way of saying that. I think I've read a similar sentiment in either Management 3.0 or in Coaching Agile Teams. I don't think I've plagiarized there, but will gladly give due credit if I have.

How to Engage an Agile Coach

I'm often asked by companies how they can engage me as an Agile Coach. What would you do? For how long would you be there? How long would it take? My response is always tailored given their specific context. Each situation is different. However, here's an attempt to give a very general response to that question.

In short, you can pretty much design your own ideal engagement with an Agile Coach. I'm sure there is a coach out there that will be willing work with you toward your goals or activities, whatever they are. Although some coaches only do deals of a certain size or of a certain type of work, there is generally lots of flexibility to be found.

For example, depending on what you are after and on your budget, the number of days and the frequency of involvement can vary.

• Very limited: A day or a small number of days
• Regular or periodic: A day or three each iteration
• Full time but temporary: like 1 to 6 months
• Full time permanent: unbounded

A single small team that just wants some outside eyes once, or once in a while, can get help with a small budget. Involving the coach with more teams and more people typically means more days are needed to accomplish your improvement or transformation goals. An organization looking for coaching for many large non-collocated teams is a much larger deal.

The engagement can be just as simple as "hey, I think we're doing pretty good, but we'd like to have a fresh set of eyes to point out what we're overlooking." That could lead to any number of recommendations that the team is free to tackle on their own. Or that could lead to an additional engagement designed to address some specific issues. Or an engagement can be as broad as be here every day and work with us for three months.

As for the type of work that a coach may do for you, the work of the coach may be in the form of training and workshops, mentoring, coaching, consulting/advising, or getting his hands dirty.

Here are some examples of what you might engage a coach to help you with. This is not an exhaustive list.

• Limiting WIP and setting limits
• Using Kanban and Lean metrics
• Eliminating delay, prioritizing work via cost of delay, and improving flow
• A3 problem solving
• Demonstrate many retrospective techniques, lead retrospectives, mentor others as they use these techniques
• Spotting and removing impediments and managing risks
• Creating and sizing / estimating the release backlog, using velocity
• Identifying the MMF set
• Story mapping
• Project chartering, vision casting
• Planning and preplanning
• Communicating
• Using BVCs and information radiators, addressing why they are stale and not being used
• Space and facilities
• Pair programming, SOLID design, emergent architecture, TDD, CI, continuous deployment, etc.
• Defining Done
• Coding katas
• Design patterns, refactoring, etc., for example through lunch-n-learns
• Designing and tasking-out of stories; design review; shared task list and working as a team on each story
• A myriad of dysfunctions
• Issues with interpersonal relationships, working agreements, appreciation, active listening and working as a genuine team instead of as a simple working group, team accountability
• Team goals, rewards, recognition, MBOs and other HR/management policies
• The management role, including management influence and interference, people management
• Scrum of scrums, multi-layer scrum and kanban
• Working effectively with remote workers
• Project portfolio management
• Documentation
• Q&A - Address the team's concerns and questions such as:
  
  • "How should we handle defects and minor changes in our specific context? Plan them and estimate them? Treat them as high priority and don't plan/estimate?"
  • "What should we do if we don't finish a story in the iteration?"
  • "On what day of the week should we have planning?"
  • "We're considering changing the way we do xxxxxx, what do you think?"
  • "We have work left over at the end of each iteration. What do we do?"
    

This list could go on and on and on. Each coach has their specialties and strengths and would come up with a somewhat different list.

Give me a call and we'll set up a time to craft an engagement of your own, suitable for your needs and your context.