The Other Reason I Stopped Blogging

I blogged a fair amount (for me, and relative to many colleagues) before I went into consulting and continuing on into my time at Leading Agile -- right up until it became mandatory. The company had a desire to have more people write more content more often so it became expected that everyone be involved. The implementation was a well intentioned across the board writing calendar; a rotation for every consultant to write a blog post when his or her week came up.

That killed my writing motivation. 

I stopped writing. Corporate writing scheduler: "Write something!" Me: "Uh, well, no, and why don't you go pound sand." That's the lack-of-autonomy and lack-of-purpose (ref Pink's Drive) triggers for me. That was part of my writer's block.

Then I got over that (not wanting to comply) and began to think that I just couldn't write on schedule. I could write only when the inspiration hit me. Creativity can't be scheduled. There is some truth to that for me. Much of my writing was in response to either (a) a question someone asked me or (b) an answer someone gave me in response to a question I had. Even in the 1st case, the writing was a thinking tool. It helped me think though how to articulate a point or express a concept for the benefit of others.

It just now hit me that my writing also scratched the itch that Pink in Drive called mastery. As long as I was learning, I was writing. As long as I was learning how to better help others learn, I was writing. 

There came a time when my learning in some old areas slowed, and writing declined. And my learning shifted to a couple new spaces and before I figured out how to write about those things, I changed employers. 

I just discovered an important point about why I didn't start writing again in that new role. I discovered this while reading John Cutler's "TBM 9/52: Writing Culture Challenges". John wrote "A writing culture is a reading culture and a feedback-giving culture. A write-and-reading-and-feedback-giving culture requires time to think, process, and respond. Writing isn't the end goal: thinking and improving is the goal."

That's what happened when a writing schedule was put in place at Leading Agile -- writing was the goal; marketing was the goal. Well, the company's leadership might have known that writing was to develop thinking, but that's not how the expectation was expressed.

Then in the new role, the work-load set it. John says that you don't get a writing culture in "Conditions of high reactivity, cognitive load, and passivity. No one has time or energy to think, ask questions, and process. Too much energy goes into doing and reacting."

John goes on: "…you can't just 'switch' to writing culture. It has very little to do with the writing and everything to do with the preoccupation with busyness, optics, power, control, and tempo. ... Work-in-progess [sic], change-in-progress, and planning-in-progress is just too high to think." Yikes!

John gives some good suggestions, techniques in his article. Worth reading. But he doesn't tell you what to do with the high WIP, high change-in-progress problems in that article. I expect he has in some of his other articles that I haven't read. It's worth subscribing to his articles. 

What's DOING in Personal Kanban?

What do you do with Stories on your Personal Kanban that you are going to put aside for a day or three?

I'm committed to limiting my Work In Process (WIP) and to "stop starting / start finishing" but some stories/tasks just need to be put aside. I'm not talking about tasks that are blocked, waiting on someone else. Those I'll either flag or move to a Waiting/Blocked column. Rather, this post is about stuff that I need to stew on or need to come back to when my mind is ready. What do you do with those? Herein I'll tell you what I do, but I'm really interested in what you do. Please post your thoughts and ideas in the comments.

I don't have a HOLD column on my personal kanban wall. Hold seems to be a misnomer for me. It's a kind of lie. The work really still is in progress. It's WIP. I'm going to come back to it this week, maybe tomorrow, maybe even today. It ain't done.

I could split my task or story each time I feel the need to set one aside, putting part of it in DONE and part of it back in a ready column, but I kind of like my definition of what is a story, what is a task and what is a next-action (or sub-task). I don't want to monkey with that. Anyway, splitting stories is a kanban hazard.

PROJECTS, STORIES, TASKS, NEXT-ACTIONS & SUB-TASKS

For the following discussion you need to understand my context:

I have Projects (held in a folder) that get broken down into multiple Stories, each Story on its own stickie. Some Stories are stand-alone, not related to any Project.

I also have some Stories that have multiple "next-actions" (or tasks or sub-tasks, whatever you choose to call them). In the spirit of Getting Things Done (GTD), I note the next-action, or next several actions, on the Story stickie. Often, each one of these next-actions might take 5 minutes or less, so they don't seem to be a Story deserving of a stickie of their own.

So here's what I do for those tasks in that nebulous state of not done but not active either. I'd love for you to add your thoughts in the comments.

IT'S DOING

Some of my to-dos need time to stew, such as writing a blog post. I have lots of outlines and rough drafts. I create drafts quickly when the idea comes to me. Such activity never enters my personal kanban. In the spirit of GTD, if it takes less than a couple minutes to do, just do it. I very rarely create a Task or Story for such activity.

But when I select a draft blog post to finish, I put the blog-post Story on my personal kanban in DOING and leave it there until I'm done-done. But I won't finish it in one setting. I'll flesh it out and let it sit. I'll come back to it, pretty it up, put in some links and gather some photos, and let it sit. I'll proof read and polish it and paste it into blogger, and let it sit. I'll come back to it some morning to be sure it's ready to go, publish it, and tweet it. During all of that, I might add a next-action (sub-task) either into my draft blog post (such as "--insert photo here--") or onto the stickie (such as "trim the photos").

I'm pretty satisfied with how I do that.

IT'S DONE FOR TODAY AND A TODO FOR TOMORROW

Other times I'll have a to-do that I want to work on a little each day, such as practicing a coding kata or revising/rehearsing a short speech. Maybe I'll put a "next action" (sub-task) for each day of the week on the stickie and check them off as I go.

I don't usually leave those in DOING for the week. If I've done it for today, I don't like leaving it in the DOING column. I usually move them back to some ready column each day. But it's still in progress for the week.

I'm not completely satisfied with how I do that. Sometimes I've left such a story in DOING.

What do you think about this? Do me a favor and post your thoughts in the comments before you go.

Sketchnotes of Agile Immersion

Here are the sketchnotes from my November Agile Immersion workshop.

These sketchnotes were done by a business partner of mine, Jenny Trautman of evenview. Sketchnotes aren't the main thing evenview does -- sketchnotes are an artifact. What evenview does is help people bring innovative strategies into focus. They lead fun, high-energy meetings using interactive visuals that draw a team together. With their support, groups collaborate to develop a shared vision, create a plan for action, and implement their ideas. Use them for your next strategy meeting or kickoff.

By the way, this workshop is designed for everyone. No agile experience or programming skills required. All types of roles have found it benefical: product managers, marketers, managers, office managers, business development executives, developers, testers, CFOs, and etc. Check out this interesting blog post from a recent non-developer attendee.

Scrum Fundamental: Planning and Iterating

This is my last post, for now, in this series on common issues teams have with fundamental Scrum concepts. Here are a few tips, reminders actually, for planning and iterating.

Make story estimates visible to the Product Owner. Understanding the relative costs of features helps make better trade-offs.

Product Owners reprioritize work not started. Always work on the highest value story and risk reduction stories first.

Plan a second release from the start. This takes the pressure off. “We’ve just got to have feature X!” becomes “ok, we’ll put feature X in the second release and not worry about it now.” You may never do feature X, or release two, but it helps the first release move along unhindered.

If you need to know when you’ll be done, make a build up chart for the release. See Alistair Cockburn’s article on this topic.

Minimize the amount of work in process (WIP). Limit this in two ways: In each iteration, have the whole team work on just a few stories (like, three to six, depending on size). I put some rules of thumb on this in an earlier post. Don’t start work on something that cannot be completed in the iteration. With traditional project management using Gantt charts, you identify and care for the critical path. With agile projects, you limit WIP and increase cross-training, teamwork, team goals and collaboration to care for the critical path.

In addition to limiting the number of stories in the iteration, limit how many stories can be in progress at any one time. Limiting WIP to, say, one-third of the number of stories committed to the iteration might be about right. Then work towards limiting it to just one.

That’s it for now. But there is so much more that can be said. I welcome your own thoughts and lists and links to other relevant information in the comments below.

If It's Painful, Do It More Often

I've worked with a number of teams who couldn't deliver. They could write code all day long for months on end, and they'd do just that. But then they'd spend a month or three shaking bugs out and still not be able to get the product into production. In many of these cases, the programmers just want to program. They don't want to or know how to do the messy task of deployment. Install and upgrade is not their core competency.

It's instinctive to cram more features into the release when it is just so hard to deliver. If you get few chances to deliver improvement, you want to cram as much in the release as possible. But that just makes it harder. More beautiful garbage to push over the goal line. This raises the inventory of unfinished work, the amount of work in process, which further delays deployment and hides the real problem.

I'm reminded of the Israelites when Moses instructed them to not save the manna that God provided from one day to the next. Do not keep an inventory of the stuff. But some of them didn’t listen and kept some of it until morning. But by then it was full of maggots and had a terrible smell. Software development with too much WIP is exactly like that.

Anyway, Lean software development reduces work in process in order to surface problems and reduce costs.

I like this illustration from page 7 in Mary Poppendieck's book, Implementing Lean Software Development. When you first look at it, your reaction might be "No! RAISE the water because there are rocks!" But the rocks are still there. Some day you are going to hit those rocks. Better to hit the rocks and deal with it in a dingy than in a yacht. Better to deal with the inability to deploy using a small release than a big one. It's better to lower the inventory, surface the issues and work to resolve them. Don't leave them there, lingering.

In eXtreme Programming we say that if is something is painful, do it more often. What we mean is that we should not avoiding dealing with problems. Solve them right away.

It’s The Values That Matter. Or Maybe It’s The Culture.

Mechanical Agile^[1] is when one tries to follow the process with no understanding of the theory behind the practices, with no understanding of why it is designed as it is. Daryl Kulak wrote the most excellent post "Five Symptoms of Mechanical Agile". Any team exhibiting the conditions represented there, certainly need help. But truly, any team having those problems is pretty far along. They are trying to be agile but are misfiring on some point. Many teams don’t get that far because they just don’t get it.

As with XP, Scrum can be followed mechanically, without any understanding of why. Have some iterations, estimate in points, make a pretty burn down chart, do a demo, and maybe a retrospective every other sprint “because we just don’t see the value of doing it every sprint”.

And they totally miss the point of agile.

Ken Schwaber said that teams implementing Scrum need to "...recognize the even higher degree of control, risk management, and transparency required to use Scrum successfully. I estimate that 75% of those organizations using Scrum will not succeed in getting the benefits that they hope for from it." (Emphasis in original.)

I agree with Ken. More is needed than is evident to most teams. In the context of the quote, Ken is pointing out what is needed to supplement Scrum in lieu of "controls and safeguards of waterfall and predictive processes." And there is more needed beyond just that.

Same thing with Kanban: model the process, put some swim lanes on the wall, and maybe put some WIP limits in. Visualize the workflow and break a log-jam from time to time.

And totally miss the point of continuous improvement and the metrics that enable such.

In his article, Daryl wrote that if you fall into mechanical agile, "[only] addressing the attitude of thinking of people as machines will help you." Daryl touches briefly on the topic of culture in his article, suggesting that cultural issues can be a problem and the need to change the culture as a solution.

Jeff Patton says that "Agile development is more culture than process". That is, if you ain’t got the culture, your Scrum/Kanban team may not be agile. Pay close attention to agile values and mismatches between those and the organization’s values.

That’s the key ingredient: the agile values. Or maybe it’s the agile culture. Not sure if values drive the culture or whether it’s the culture that influences the values. Either way, they go together.

When I teach XP in a time-limited situation I’m always torn between focusing on the four core values versus the practices. The practices are easier for people to understand. They add some value by themselves. They are concrete and give the audience something they can grab on to. But picking up the practices don’t make one agile. It’s the XP or Scrum or agile values that give you a fighting chance of understanding what you are doing the practices for. But starting with the values leaves most people scratching their heads. They don’t resonate with the average software practitioner.

The best chance you have of changing a culture, then, is with successful agile projects, mechanical or otherwise, punctuated with judicious and timely explanations of the values.

1. Dr. Hong Li coined the term Mechanical Agile which was first used publically by his co-author in an upcoming book, Daryl Kulak.