Category Archives: Thought-out

Thought-out posts represent something serious I’d like to assert in the ongoing discussion about agile.

More on “The Curse of Allocation”

Recently, I re-discovered a post written by my friend Len Lagestee entitled “The Curse of Allocation.”

Len lays out five important problems that arise from allocating people to multiple teams or projects:

  • Wasted Time
  • Frustration
  • Lack of team bonding and connection
  • Lack of ownership and accountability
  • Perceived progress

Len’s post is a good one, and I encourage you to read it (and add his blog, Illustrated Agile to your regular reads!).

There is another problem with allocation people to multiple projects that I’d like to mention. It could also be seen as a symptom of the last two points Len raises, “lack of ownership and accountability” and “perceived progress.”

It’s very common for a worker who has two or more projects to work on to have to decide “what will I do today?” and to have several choices on each project they are working on. I believe (and have observed) that given a choice, an individual will choose the work that is either easiest or most easily defined (they’re often but not always the same). Which means that, given two sets of stories or tasks to choose from, an individual will choose what to do based not on the priorities and needs of either team, but rather will choose to do work that looks like something they can complete.

Of course, choosing to work on something you can complete is a great principle of agile: commit to doing things you can finish, or design your work such that there is a clear way of telling that it is done. No problem there.

The problem is that sometimes the most important work a team can take on is not easy to do or easy to define. Sometimes a team–or an individual–needs to be faced with no option but to take on a difficult challenge. A person on two teams, when faced with a difficult obstacle on team A, will choose to do the easier or clearer work on team B. And that is bad for both teamwork and team progress. It would be better that that individual have no option but to talk to their teammates, confess that they’re stuck, and get the team’s wisdom on determining how to move ahead.

As a thought-starter, I’ll offer a third alternative to Len’s tips — and let me note that Len’s tips are FAR superior to this idea:

Enforce the terms of allocation. If an individual is assigned to work “50%” of their time on project or team A, they should spend, literally, exactly that amount of their time on that project, even if it means they’re staring into space trying to think of the solution to a problem, or running around to the rest of the team asking for advice. That 50% should be regular (every iteration, pay period, reporting interval, whatever) and predictable (“each day from 8 am until noon” for instance).

Prioritize and Don’t Do It (Len’s post) are better pieces of advice, but if you must allocate, enforce the allocation so that you really understand its implications.


Why the Name “Scrum?”

It almost never fails to get a laugh: “scrum.”

But there are some real reasons for that name — it’s a term from rugby, and it’s used as a metaphor to reflect the degree of cooperation needed to succeed.

A rugby team scores when the ball is advanced across the goal line and touched to the ground. The way the ball moves is (primarily) by being carried and being handed off or passed laterally/backwards. If the ball carrier is tackled, he must release the ball, and play doesn’t stop.

Because holding the ball leaves you very vulnerable to being tackled by the big lads on the opposing team, it’s imperative to keep the ball moving between teammates. And this means that the whole team is needed to score. There are no Montana-Rice combos in rugby, no solo stars–at least not to the degree that there are in American football.

Work as a Team

There are a lot of applicable statements on this page about playing rugby: , but here’s one that might be the best:

Continually think of your alignment in relation to the ball carrier and any players in between. Work hard to be available when needed.

How about if I repeat that last sentence for effect: “Work hard to be available when needed.” If you are on an agile team, you should work hard to help your team succeed. Another one of those sure ways to make your team unhealthy is to look at the stories or tasks, shrug, and say “there’s nothing here for me to do.”

So . . . Scrum?

So what’s the term “scrum?” It’s the beginning of play (or the restart of play after an infraction): . If you are familiar with American football, you’ll see a scrum and think of a scrimmage. But in the scrum the ball is loose, and each team is scrambling (clawing, fighting, kicking) to gain control. Just as when the ball is being handled by the backs, teamwork is required. (I’m not advocating for violence in your retrospective meetings, just describing rugby, now.)

scrum, where forwards from both teams pack together using their bulk, strength and ability to work together to get the ball.

How do I know all this? Well, I admit I’m not an expert. I just googled to find the site I’m referencing, and what it says matches what I remember (Thanks, Peter Dawson!). Because when I was in college, I played rugby for about a week, damn near broke my ankle in a practice and never played again. I got a good tough shirt out of the deal, but my ankle still hurts sometimes.

Scrum Master != Answer Master

One thing I’ve seen in watching companies adopt agile principles, and specifically with some flavor of Scrum, is the tendency for newly-minted ScrumMasters to feel that they must have the answer for any question asked in a standup, demonstration, planning, grooming, or retrospective.

Now, it’s very typical for the existing Project Manager to assume the ScrumMaster role. It is the closest to what they were doing before.

And it’s natural for ex-Project Managers to hold on to many aspects of that role–we’re creatures of habit, after all. And in waterfall, the Project Manager was responsible–even accountable–for creating that lovely detailed work breakdown structure, and those spiffy cascading Gantt charts in MS Project. All the answers were at their fingertips: Are we On Schedule? Check with the Project Manager–they have a magical way of knowing if things are on track! What happens if we remove a feature? Subtract the tasks from the WBS, re-align any dependencies and voila, the Project Manager has calculated the answer!

Things aren’t so simple in life. Or in Scrum/agile.

If we’re building a healthy team, we should be seeing communication between team members, in a network, rather than in the hub and spoke fashion of a lot of Project Managers. ScrumMasters should encourage this networked mode of communication.

I believe it’s healthier to accept that one individual will not have all the answers. Scary? Sure. But if your team is healthy, the answer to a question is not very far away, because there will be enough communication to retrieve any answer in short order (and enough information radiated by reports the ScrumMaster maintains to answer many simple status questions straightaway). Think about the idea that the knowledge of the team is “too big to know” and that the smartest person in the room is the room.

One way to be sure that your team doesn’t get healthy is to make sure that all communication is funneled through one single individual. (For instance, what does it do to your truck number if only one person has access to the folder where the team’s release plan is stored?)

On some–or maybe even many–projects, rather than being a special expert, the ScrumMaster could be an individual from within the team who steps up to handle the ScrumMaster role in addition to their other duties. The description of the ScrumMaster from the Scrum Alliance’s Scrum 101 page reads simply “ensures that the team is functional and productive.”

So, ScrumMasters, make sure your teams are protected from outside distractions. Radiate information like a single-pipe steam radiator with a wide-open air vent on a freezing cold day. Get the team to the demonstrations, the retrospectives, the grooming, the planning by making sure they know when and where they are. But once things get underway, get out of the way. To borrow a phrase, facilitate your meetings “as though you were cooking a small fish.”

(As a sidebar, and in the interest of thoroughness–not as an endorsement–I’ll link to the “ScrumMaster Manifesto.” I’ll say that I’m pretty sure that I disagree with their statement “WE BELIEVE THE SCRUMMASTER IS A FULL-TIME POSITION FOR ONE PERSON ON ONE SCRUM TEAM.” I think a lot about team size, challenge, maturity, and capability are being assumed by that statement.)

Punished by Ambition

One of the precepts that we–okay, I, for certain–take for granted in scrum is that teams should consider carefully how much work they can commit to in their sprints, use estimated size (i.e. in story points*) and past history as a guide, and only take on more work if they truly finish the work they’ve committed to. Intuitively, this makes sense. You want your teams to focus and finish work, not to start, or stub out, more than they can finish. Starting more than you can finish leads to making some progress with a lot of things, but being finished with few.

As I said, this makes sense intuitively. Recently, I came across a very nice empirical observation of the danger of over-commiting. I have to give props to one of my current clients** for providing this example, as well as providing the title of this blog post (although the phrase may have first been used by Sir Francis Bacon).

The team’s velocity, now established after more than 8 working timeboxes, is 60+ points per three-week sprint. This is shown on the graph as the 5-week moving average of points completed per sprint. But the team didn’t always know–or trust–that as a fact.

During their fourth sprint, even though they had never completed more than 81 points in a sprint, the team was pushed to accept 134 points as their committed work. They failed in a spectacular manner, completing less than a third that many. In fact, the number of points completed during that sprint was their second-lowest on record. (Their lowest-measuring sprint occurred early on when the team had almost no experience with agile techniques.)

So you can imagine what happened, right? The Product Owner, excited at seeing an upward trend over the previous couple of sprints, and perhaps agitated to release something soon, may have pushed the team to take on more work. Or the team itself, wanting to prove something, may have applied internal pressure. Whatever the exact reason, they took on more than they could handle. And the result was calamitous. Not only did the team not complete all the points they committed to, they in fact completed fewer points than they usually could.

In sprints 3.3 and 3.4, the team was more conservative, committing to 62 and 70 points respectively. And in both of those sprints, they were able to pull in work and complete more points than they committed to. (This pattern may suggest, of course, that their actual capacity is higher than 60.) But look out! Buoyed by those two successes, the team committed to 115 points in sprint 3.5, and again failed to meet their commitment. (To be fair, they did complete more than their average, so something is going right.)

The important point is that remaining focused, which in behavior translates to committing to fewer points/stories, allows the team to work more effectively and accomplish more than planned. And being aggressive in committing to work dilutes attention and results in worse than average performance.

* But for a good common sense opinion on NOT using story points for selecting work for sprints, see Mike Cohn “Why I Don’t Use Story Points for Sprint Planning.” I don’t think what he says negates the underlying message I’m trying to convey in my post.

** Not wishing to run afoul of any confidentiality agreements that may exist, I’m not going to identify the client by name in this blog posting.

Nothing’s Personal / It’s All Personal

One problem I have observed in Retrospectives, and one of the things that can keep a team (scrum/agile or otherwise) from really performing well, is the tendency to interrupt each other.

Sometimes, interruption is a sign of healthy enthusiasm. But sometimes it is not. It takes courage to let someone else finish their thoughts. You might be scared that they won’t let you finish yours. You might fear that your idea won’t be accepted if you don’t repeat it often enough. You might be afraid that someone else’s idea will be better than yours.

Stephen Covey’s fifth “habit” is “seek first to understand, then to be understood” and that definitely applies in Retrospective meetings.

But why did I title this post “Nothing’s Personal / It’s All Personal?”

Because it’s going to feel quite personal, to listen carefully to what someone says. Often things that are discussed in Retrospectives are coming from a place of feeling, of emotion, not simply burndown charts and story points.

But it’s also got to be treated like it’s NOT personal — just like the task cards we put on the table, once they’re out, they belong to the team to probe, question, build upon and even discard as the team sees fit. But still, the emotion-origin ideas at a Retrospective need to be treated as personal — one person said each of them, after all.

So it’s not personal, but it’s all personal. To put it another way, we need to balance thinking critically and objectively with being compassionate and appreciative. By listening carefully and personally, letting thoughts be finished–even if you’re jumping in to agree–you help make the transition from personal to not personal easier. And your team will grow stronger and more quickly.