Conference Talk on Focus and the Pomodoro Technique

A colleague and I (thanks, Olivier!) presented the following talk on the Pomodoro Technique. Attendees were intrigued by the content, but the exercises needed some work. Olivier presented it again later in the month and it went much better... our experiments with small focus groups didn't scale out well to 10-15 people per team. The second time around, he increased pressure and scope creep by doing the following.

5-minute challenge: brainstorm as many tips as possible across all categories below. Make sure you get about the same number of words in each category. One person holds a dry-erase marker and notes ideas; no duplication allowed within lists.

• fire prevention
• road/driving safety
• professional hazards

5-minute debrief: count how many ideas were generated for each category. Ask how things went, and what was noteworthy.

5-minute challenge: same as challenge above, except we work one category at a time until there are about 20 ideas, then move to the next category.

• flu-prevention
• household child safety
• names of TV shows

5-minute debrief: was one strategy more effective than the other?

10-minutes: Introduction to the pomodoro technique.

15-minutes: how we tailor the technique to a team environment and meetings, Q&A

the cost of team-building

Part of what makes team-building so hard is its cost. There are personal costs, political costs, and organizational costs--plus the cost of time. Yet people who've been on a performing team often want to get back on one, and managers are often hoping to create them. I think that listing some of the costs may help us understand the resistance to team-building / gelling:

cost	benefit
loss of independence	we accomplish more than we'd do alone
increased visibility of mistakes	our team is there to help us when we fall
increased visibility of weaknesses	" " "
with more trust in teammates comes more vulnerability that they'll let you down	more connection and support
full presence requires more energy	we relish more in our success
decreased recognition from management for individual contributions	much more constructive feedback and learning opportunities from peers
organizations lose some control when a group has gelled--a self-organizing team does what it chooses, rather than always doing what the organization has requested	unprecedented levels of productivity and value

polyglot list serves

On the Agile Tour organizer's list this year we adopted a list serve culture I haven't seen elsewhere--members are invited to type in their native tongue, and liaisons (like me) translate the text to English. Everyone has decent reading comprehension of English, but may find it hard to write in it. This makes participation in the list easier for almost everyone... Have you participated in a list like this? What kinds of language- or process-related problems have you encountered?

fan-out release planning

What is Fan-out Release Planning?

Fan-out release planning integrates set-based design, weekly intermediate deliverables (and validated learning), sustainable pace, top-down budgeting, risk management, and deliberate prioritization to deliver a valuable product in sync with business, marketing, and sales plans. We do this from a Product Owner's perspective by selecting epics for the release, establishing a budget for each topic based on the business value, reality-checking the expectations with the development team (and trimming scope as necessary), and then scheduling the work strictly in order of priority, stopping development when we've run out of time.

The differences between fan-out planning and traditional XP planning are:

• an emphasis on exploration, especially during the beginning of an iteration/release
• top-down scheduling
• an explicit allowance for functional debt until the end of the release. (Functional debt, for example, is present in a new file editor that allows us to create and save documents, but not yet load them. We could address creating and saving first because the team identified these functions as the most risky, and identified a fail-safe plan of using a plain-text editor to display the files if we don't get a chance to work on loading/rendering issues. This gives us more time to focus on the core value provided by our editor, for example, auto-completion.)
• an emphasis on slack time, both creative and buffer slack

We use fan-out planning at an iteration level for cards that we can't readily estimate (because the solution or need is vague). Instead of doing pre-work on a card in an iteration before a story has been slated, we'll schedule it without an estimate, and let the team say what is feasible during the week. What does this do to a week's commitment? It makes it more fluid--people do the work that they can. The goal is to find the essence--the core value of a card--and do something that will yield feedback (validated learning). Normally an un-estimated card only produces a spike or more cards with estimates, but if the developers who took it find the work easy and relatively small (less than a day), they'll often move it to Done-Done. In any case, we have something to show for the work, that can be validated with a client, and we've left the production code in a healthy state (often by using options that hide new features).

Why Change the Planning Game?

Traditional XP release planning leaves little room for slack, and as a result, I think it doesn't get as creative. We also see cycle-time waste when we're doing analysis for story cards that aren't going to be picked for an iteration or more. So instead of nailing things down enough for estimation, we just 'take it offline' and talk when the card has been picked. This can be risky, because bottom-up scheduling and estimation protect a team's sustainable pace. We counter-balance this risk with adequate slack.

Another benefit of fan-out planning, counter-intuitive as it may be, is the increased predictability it gives us. It may be a bit premature to say it, but we've been doing fan-out planning for about 15 iterations, including one major release, and we find we are more capable of responding to changes in the market place, more capable of finishing strategic plans, and more predictable. By always focusing on the absolute minimal feature set, we gave ourselves enough slack to become predictable.

When we're beginning a new release, we need to provide some visibility to our marketing, sales, and support teams about what's coming with the next version of the product (we make internal releases each one-week iteration, and sometimes deploy those intermediate deliverables to a new client, but most existing clients only upgrade our product every 3-12 months). There's a lot of risk involved in promising a fixed scope with a fixed delivery date--so instead we commit to a delivery date and a vague set of release goals/epics/themes. By using fan-out planning, we attack several candidate solutions, show them to our stakeholders, and wait until later in the release plan to commit to a particular solution.

Does this sound familiar?

Fan-out release planning is, as far as I know, unique to my team (but inspired by XP, Scrum, and Lean ideas)--and I'd be happy to hear about other teams that are doing something similar, or about any resources/books that describe it, or of any concerns you might have about the process!

favorite lines from Slack by Tom DeMarco

DeMarco's book is not only about Slack--but if you want to read about it see:

Slack: We're not slacking off!

When to slack + what it gives us

Pressure

"People under time pressure don't think faster"--Tim Lister

DeMarco discusses at length the popular management idea that people under pressure work harder. Sorry--pressure only helps for physical labor. So what are managers supposed to do if they're not turning the screws? They're supposed to protect the focus in the work environment; to build relationships between individuals; to delegate and keep hands out of the "dirty work"; and to fight against aggressive schedules, overtime, a culture of fear, and litigation. Managers are avoid command-and-control behavior, and need to learn to lead by extending trust before it is earned: "you acquire trust by giving trust".

Change

There is no managing of change. No one knows what's going to happen. As Weinberg says, he goes in, shakes things up a little, and waits for concerned employees to come asking for his opinion. DeMarco adds: "in times of change, the reward has to come first". It's hard to change--it can be embarrassing for an expert to learn a new skill and be reduced to the same level as junior colleagues. Anyone who is learning, trying things out, taking risks, is likely to be afraid--but if they're not in a safe environment--they may get ridiculed--and that can kill their motivation to change. Furthermore, change has to be introduced when things are going smoothly! If things aren't going smoothly, and you still need to change--add a lot of slack.

Best Practices

DeMarco says that a focus on process comes from Taylorist thinking. From an observer's perspective, the physical process followed by stellar employees may be the same as the average employee--but that's because knowledge work depends on relationships or abstractions, not physical steps.

It's more important to be effective than efficient; that is, do the right things, before working on doing them the right way. As soon as we streamline our process, it becomes inflexible.

Managing

This couldn't be more simply put: "the skills [of management] are inherently difficult to master". Often managers are promoted from technical disciplines without proper training. This produces all kinds of common side effects... for example, the stereotypical weekly status meeting. These meetings may be nothing other than an opportunity for the 'boss' to demonstrate some sort of control over the project. What a manager needs to learn is to extend trust in a qualified context--and to give people the chance to fail. Ultimately this gives people the chance to learn and improve. Instead of second-guessing all the small decisions, the 'boss' can focus on the big picture with risk management. Appropriate risk management means we've planned for many failures along the way to ultimate success.

He Came to Bury Agile: Long Live Agile

It's Time for Agile 200x to Cede to the Smaller Conferences

Last year's keynote speech by Alistair Cockburn at the annual Agile Alliance conference was called "I Come to Bury Agile, Not to Praise It". I too am here to bury the Agile so many of us know, the Agile paid for by hollow certifications and expensive conferences and phony marketing. I'd argue that the term "Agile" itself was a phrase coined for marketing purposes--but that's another story(*). This story is about how we need to reach out in support of the whole community, rather than spending our attention/resources on a select few. What do I mean by a select few? Well, there are over 50k CSMs, and only around 2k attendees at the Agile Alliance conference every year. That's 4% of CSMs (and less if you count the rest of the Agile community). Less than 4% is a select few. Why don't more people go? I'm not sure--but for most of the colleagues I've worked with, it's simple--they can't afford to "pay to play". Me neither--if I pay early-bird rates, get super-cheap airline tickets, pay for my hotel and food, this sums to a month's-worth of my take-home pay (I'm working for European wages). A full month. What about corporate expense accounts? Not for this--all my colleagues and I have worked for small companies that can't afford it either. It's time to find an affordable way for the typical developer to participate in Agile conferences.... and that's through small, free/low-cost, local conferences, like the XP Day series, the Simple Design and Test Conference, Bar Camp, Agile Tour, etc.

Where I'm Coming From

Throughout my 10 years of agile software development, I've been getting more and more into the Agile community. I love this community because it is so open-minded, so willing to apply ideas from other arenas, and so ready to share knowledge without claiming intellectual property rights. We've built strong local user groups, e-mail lists, open space conferences, code camps, and have given legitimacy to the idea of sustainable pace--all without spending much money out-of-pocket. This is the Agile I know.

Yet, there's a part of the community I don't know, a part maybe I don't even want to know: the big, expensive conferences and training classes. It seems like all my role models are a part of this, so I figure it's worth trying, at least. Yet, how do I pay for it? This year I was happy to discover that the Agile Alliance offers speaker compensation packages that cover registration fees, hotel, and a stipend big enough to cover food and taxi from the airport, leaving only the international flight for me to cover myself. I thought this was a comparably affordable way for me to go to a conference. So I decide to prepare a submission. A couple years ago one of my role models, Yves Hanoulle, said he only goes to sessions that are prepared by a pair of presenters. OK, so I find a co-presenter. It's bound to make my submission better. So I begin the submission process, and find out right away that the speaker compensation policies for Agile 2010 and XP 2010 only reward the 'first speaker'. What? Aren't we, in Agile, supposed to believe in rewarding the team, not individuals? Well, I promised my co-presenter that I'd split the booty equally. Hmmm... now I'm down a couple hotel nights, stipend money, and worst of all, half of the conference registration fee. Well, I can fix that--I'll do two talks. I find another topic, another co-presenter, and away we go. Time goes on, a few people make good recommendations, we improve our proposals. I start reviewing other people's sessions, and see a lot of good ones. I'm not feeling all that confident, having never been to a big conference before, so I do one more submission. It's so much work to write a submission, I decide I may as well post it for several conferences... and soon get accepted for XP 2010 and Agile France. Woo-hoo! Maybe people do think I have something interesting to say....

With all my submissions made, I start appreciating the peer-review functionality of the Agile 2010 system. I start reading and commenting on other people's submissions--and find that this system is the best I've ever participated in. Here's the real Agile community I was looking for--people collaborating, seeking the best in others, and supporting one another. I ended up leaving comments on 130 proposals--hoping to give back what I had gotten so far from the process. I know stage producers had to do a lot more, but I think I can appreciate what they have done during the selection process. Ultimately, none of my talks were picked for this year at Agile 2010. Still, I noticed that the submissions from people that had established reputations in the field got 5 times as many comments as newcomers. I really wondered how people that hadn't participated much in the community would get mentored if they weren't getting equal support through the comment system. As a result, I think the review process needs to go double-blind.

The Revolution is Afoot

Maybe the rejection from Agile 2010 is clouding my judgement right now. Or maybe it's making it so I see more clearly. I did get in to other conferences, and all along I've been frustrated with the costs of doing a presentation. In any case, this big up-front selection process, in which a few volunteers meet to judge which talks are best suited for the conference, is simply not Agile. It's too cold, it's too Taylorist, it's too micro-optimized. It's not consistent with the relational vision of the Agile Community. There are already several disruptive changes in our midst that will outreach this top-down model of a conference. One, for example, is the Agile Tour, which had more conference attendees last year than the Agile 2009 event, and which cost an order of magnitude less. It gave a stage to practically anyone who wanted to talk, and attendees voted with their feet, during the day, to show what was most valuable to them. Another sea change is the growth of groups like the Agile Skills Project, which has reached over 800 members in less than a year, and the Diversity In Agile Project, which shows that we are recognizing the problems that come from undervaluing the full community.

The Agile 200x series of conferences has struggled for years with their selection process. Why not give up, and go with the Agile Tour model? Keep the peer reviews, keep collaborative improvement of session proposals, and get rid of the high-cost of flying everyone in the world to one city. Send invited keynote speakers on a short tour, and let everyone else in the door for free. Corporations can sponsor the venue and food, and the events could happen twice or more per year.

(*) Note the company names of the best-known consultants in the field--do they have 'agile' in the title? No! Because the word Agile is a marketing gimmick.

When To Slack + What it Gives Us

This is the second in a series of posts, beginning with Slack--we're Not Slacking Off!

We need slack in order to be creative, to maintain a sustainable pace, and to improve. So when should we slack? To answer this, we need to understand the costs and benefits of slack.

What is its cost?

Zero. Apparently, on Ilja Preuss' team, they schedule a full day of slack once per month, and they see no drop in velocity for that week. Our team aims for a full day per week of slack, and I'd say we get an increase in velocity for that. Based on this statistically insignificant sample size, I have to say that slack is free or value-producing. So last week in retrospective we decided to call slack our default activity and label card work a side-job. We said this was to emphasize the "research" part of our R&D group, to make sure everyone knows they're supposed to be coming up with innovative, even disruptive, ideas. I admit the idea of full-time slack is a bit extreme, so let's keep holding on to the one-day-per-week goal, 50% of the time.

What are the benefits of slack?

• Beck, in XP Explained 2nd ed, talks about slack as a way of making sure we meet our commitments--it is about transparency and building trust.
• Slack gives the Product Owners perspective on the health of the code and of innovation. If all developers do during slack time is refactor, we can ask if they're taking on too much work (and creating technical debt). If they're tweaking functionality they worked in the past, we may need to look at functional debt. If they're creating entirely new prototypes, then we only need to monitor the feedback cycle on these ideas to be sure the value is qualified before much is invested. Near the end of the iteration when I see people hovering around the story wall looking for something useful to do, I know they're not overworked--and when I see them starting prototypes, I know the iteration buffer is big enough.
• When the team reaches slack before the end of an iteration, they can share in success together--maybe they were lucky, or maybe they worked together well, but in either case, it's a success. The value is two-fold: the iteration work is Done-Done (and hopefully deployed and generating business value), and the team bonds are stronger.
• DeMarco says slack is a way to give employees control. Dan Pink talks about why control is important--motivation comes from autonomy, purpose, and mastery. So giving employees control is a way to keep them happy, motivated, and productive.
• Retaining our employees, as the Toyoda family and DeMarco have noted, is the most significant means of avoiding huge drops in productivity.
• DeMarco talks about being too busy, the myth of total efficiency, the impact that no slack has on change... we are not cogs in a machine, we can't be interchanged and we can't task switch without penalty. If we don't invest in slack, we will end up being overly bureaucratic, rigid, and conservative.

So when should we slack?

• Whenever there are no more cards to work on
• Towards the middle of the week (because people are tired Friday and Monday)
• When the whole team agrees there is no useful/effective/efficient way to divide up the remaining work any further. If some people are in slack while the rest of the team is pulling in the iteration, it can deteriorate team spirit.

One team I worked with ended iterations Tuesday night--it gave a beautiful cadence to an iteration... we finished Tuesday, slacked Wednesday + had a planning game Wed afternoon, started the iteration Thursday & Friday; by Monday we came in and asked "are we at least half way through? ", then hustled our way to the end of Tuesday again. It was nice to have a weekend break in the midst of an iteration--the distance from the work gave us new insights.

Slack: we’re not slacking off!

In a technical climbing technique known as lead climbing, a rock climber, the lead, takes a calculated risk by climbing above any anchors, in order to climb higher.  This kind of climbing requires precise coordination between the lead and the second, for without slack, the lead cannot advance at all; with too much slack, a fall is more dangerous; and with too little slack the lead can be thrown off balance and fall.  (Photo Credit)

Note that it is physically impossible to climb without slack. When it comes to software, however, I’ve too often become obsessed with productivity, moving cards, increasing velocity, process improvement, and delivering business value, to the point I optimized out all slack.  It’s not that I’m the only one to get lured by the “myth of total efficiency”—it is a common problem in agile and non-agile environments.  Slack is covered authoritatively in Tom DeMarco’s Slack, included in the core XP Practices in Beck’s Extreme Programming Explained, 2nd edition, institutionalized by the Pomodoro Technique, and championed by Deming and the lean school of thought using pull scheduling.  Yet on a recent discussion on the Extreme Programming yahoo list, I got the impression that my understanding of slack is a bit unique.

 

Buffer Slack and Creative Slack

Back to rock climbing—a good second will always give the lead at least some slack until the lead starts descending—triggered either by a fall or the lead calling “belay!”.  There are two kinds of slack on the cliff—the constant foot or so of buffer slack that allows the lead to move freely in the same spot.  The second kind of slack is the excess rope that the second liberates only when the lead is climbing higher.  This creative slack is given when the lead requests it explicitly, by yelling “slack!”.  This call signals that the second must stay vigilant, because it means the lead’s life now depends on correct belaying.

Just as in rock climbing, I see two kinds of slack for a software team.  The first is buffer slack—it is the down time between official work, be that work related to story cards, administration, or meetings.  It is work that happens when we’re waiting on someone else or we’re not yet ready to take on new work.  Buffer slack is what gives us time to reflect and to consider the larger context of what we’re working on.  We might fix a bug, or refactor some code that was out of scope of our last story, but that we just happened to notice.  It doesn’t require communication with the team because it won’t impact them or the goal of the iteration.

Creative slack is analogous to climbing higher on the rock face—it requires a bit of forethought, a consideration of the feasibility and impact of the next few moves.  Creative slack requires a significant investment and focus before one can start advancing. It allows us to improve our current technology, to build prototypes of potential new features, and to consider strategic moves for the product. I’m not giving license here for YAGNI or  BDUF.  It’s just that we can’t make significant gains without some forethought. Creative slack happens when the team explicitly schedules it; on my current team it’s the time between iterations, and it is typically 15% of our work week.

It’s funny that I didn’t discover the second kind of slack in the software realm until I came to France.  Buffer slack happens naturally, unless we over-optimize our process.  So when I intentionally left some room for it on my team in Philly, I thought I had slack—and I did—buffer slack.  Yet our retrospectives in Philly identified a problem—a lack of innovation—that we weren’t sure how to fix.  Our product owner insisted that any time he heard a good idea, he wrote it up on a card and scheduled work on it when he saw fit, so he denied that innovation was suffering.  What I didn’t realize is that we needed to schedule creative slack for the whole team.  When I joined my team in France, with the standard 7-weeks vacation, 35-hour work week, 2-hour long lunch breaks, there was a lot more natural buffer slack.  So when we started nailing iterations early, all the buffer activities were already done.  I noticed that the end-of-iteration slack was creative in ways that simply was not possible in buffer slack.  It was a new kind of slack: creative slack. I’m not the only one to have learned about Slack from the French culture of working to live instead of living to work.  Though he is a native Pennsylvanian, DeMarco studied here in France, at the University of Paris.  Maybe that’s why he knows so much about slack.

Note: Though important for recharging, non-work activity (returning a personal phone call, lunch break, evenings and weekends), is not slack in my opinion.  Slack is not the same as slacking off.

 

The Published Discourse on Slack

One of the main reasons I was attracted to Extreme Programming, when I first read about it in 1999, was the idea that we can do good work without overtime.  In Beck’s Extreme Programming Explained, 2nd ed., he explains that slack is about building trust—about keeping our iteration commitments.  This is obviously buffer slack.  James Shore builds upon the buffer concept by saying that it's the variability in problems that determine how much slack we need.  In the Pomodoro technique, we learn to pause every 25 minutes.  Why?  Partly to make sure we're doing what's important.  In my opinion, this is buffer slack too—it is still focused on the tasks at hand, rather than uncharted territory.

Though not specifically labeled creative slack, DeMarco’s work touches upon the idea, by identifying that if you don't have slack, you can't take risk, because there's no room for recovery from failure.  He also says that the more optimized you are, the less slack you have, and the less you're able to change.  Both risk-taking and change are likely to lead us into new territory, and is therefore, what I’d call, creative slack. 

 

Unanswered Questions

I have a lot of questions about what to do with creative slack.  Apparently Google requires that employees demonstrate a proof of concept before they are allowed to invest significant amounts of slack time in a project.  My team is not doing that—all our creative slack is purely free and unmanaged.  This doesn’t seem quite right to me because some of those projects have no value to me as a Product Owner—but I do not interfere because I think the energy these projects generate gives enough of a velocity boost that it’s justifiable.  I also don’t want to kill good ideas that I just don’t understand yet.

What do you think about the following?

• Can you manage slack (like Google does, without diminishing the energy generation of slack)?
• Can you suggest items for exploration (without impacting the restorative power of autonomy)?
• Should slack be unconditional?
• Should it be a reward?
• Does discussion forum/tech news/book reading/technical exploration count as buffer slack or creative slack?  Or is self-improvement slack a category that should be explained here?
• How do we balance individual needs for slack with team needs?
• Is creative slack part of your job?