Richard Lawrence » Scrum

Building a Useful Task Board

Richard Lawrence — Mon, 21 Nov 2011 16:42:55 +0000

The task board is a simple, yet powerful, tool for Scrum teams. As a coach, I can tell a lot about a team just by looking at their task board in the middle of a sprint. If your Scrum team is in the same location, I can’t think of a good reason why you wouldn’t want to build and use a task board.

Here’s how to build a basic task board, various ways to enhance it to convey more information, and some analysis of the many things you can learn from this simple tool.

Supplies Required

A black or blue poster marker
A black fine tip marker
3 inch square Super Sticky Post-It notes in yellow (generic sticky notes tend not to stick for a whole sprint)
A large surface (e.g. whiteboard, foam core, smooth wall, etc.)

Optional Supplies

Blue and red fine tip markers
Two 1″ photos of each team member
Larger sticky notes in another color such as blue or green
Square or small sticky notes in orange or red
Removable, semi-transparent color dot stickers
Narrow electrical tape
Story Definition of Done printed as checklists
Post-It glue stick
Blue masking tape

Basic setup and use

Make sure you place your task board where the team will use it. Ideally, the team is in a team room together and the board is in the same room. At the very least, it should be in a place where the team will see it several times a day. It’s very valuable to use the board to focus the Daily Scrum, so there should be enough space for the whole team to stand around it.

On your task board surface, mark out the following columns with marker or tape: Story, Not Started, In Progress, Done.

Create a card (on a sticky note) for each story you committed to in the current sprint. If you have two colors of stickies or a larger sticky available, use that for the stories. Use the black fine marker to write a title for the story in large, clear print. If the story is in the typical “As a , I want so that ” format, you’ll want to shorten it to a 3-6 word title. You can write the full story on the card with a pen if you want. Write the story point estimate on the card, in a different color marker if you have one. The story titles on the cards should be readable from about 6 feet away. Arrange the story cards in priority order in the first column, leaving space between them. Each story thus defines a horizontal lane across the board. (I don’t recommend drawing or taping horizontal lines, though; different stories need different amounts of space at different times.)

Create a card for each task you’ve defined. Again, use the black fine marker and a short title to make them readable from 3-6 feet away. Arrange the tasks in the Not Started column with their corresponding story.

Some teams generate all or most of their tasks at sprint planning. Some generate tasks as they start a story or just-in-time. Still others don’t use tasks at all. If you generate tasks throughout the sprint, you can expand and contract the story lanes to make room for tasks as needed. If you don’t use tasks, you’ll want to eliminate the Story column and move the story cards through the other three columns.

Tasks will almost always be placed on the board in the Not Started column. As a team member assigns a task to himself, he’ll write his name or initials on the card and move the card into the In Progress column. When the task is done, he’ll move it into the Done column and likely choose another task to start.

The basic board should look something like this:

Enhancements and variations

If you have photos for each team member, attach them to small sticky notes or put Post-It glue on the back. Place the photo stickies on the edge of the board to indicate team members available for tasks. I suggest only making one sticky per person readily available. You can have a second sticky available for the rare times a task is blocked and they need to work on a second task. Instead of writing their names on tasks, team members will use their photo to indicate task assignments.

Make a half- or quarter-page checklist for your story definition of done. Print a stack of them. Place one on the board for each story and use it to make sure you generate the right tasks and actually reach done for the story.

If you regularly get work outside your sprint commitment that has to be addressed right away, such as production support, consider adding an “Expedite” lane above the first story. When something new appears in the Not Started column on the Expedite lane, the team focuses on that item rather than stories in order to get it done as soon as possible. (If the “urgent” item doesn’t trump the other stories, it probably should be added to the product backlog and wait until a future sprint, so this rule is a good way to distinguish between truly urgent work and someone just trying to change the team’s priorities mid-sprint.)

Use the red or orange stickies to represent impediments. Place them directly on the items they’re blocking. This avoids the disconnect between an impediment list and the task board and may explain otherwise strange indications on the board (e.g. a high-priority story in progress while low-priority stories get done).

Use different color cards or dots on cards to indicate themes, larger features, dependencies on other teams, etc.

Consider setting a WIP limit, a restriction on the number of stories you can have in progress at once. Post this number in the header of the In Progress column. Note: It’s helpful to write “limit 3 stories” rather than just “3″ because you’re limiting the number of stories in progress even though the column actually contains tasks.

What the task board can tell you

What have we committed to? The stories on the left of the board reflect the team’s commitment for the sprint. Because they’re readable at the 6′ distance, someone can see the overall commitment at a glance.

What’s done? Assuming you’ve created all the tasks for a story to get done, the presence of all a story’s task cards in the Done column indicates that the story is done.

What are we currently working on? The presence of task cards in In Progress indicates that the team is currently working on the corresponding story.

Are we working on the right things? Since stories on the task board are ordered according to their priority in the product backlog, the top stories should be getting to done first. If stories in the middle or at the bottom of the board are done while stories at the top are not started or in-progress, this can indicate a problem. For example, maybe there’s an impediment blocking a high-priority story but no one is talking about it.

Are we working together? The number of stories in progress and the distribution of names reveals whether the team is collaborating or whether each team member is working on her own story.

What’s blocked? If you use impediment stickies, you can see at a glance what’s blocked and make sure something is being done about the impediment.

How much urgent/unplanned work is being added? If you use the Expedite lane, you can see by the accumulation of cards how much work has been added after the start of the sprint. This may lead the team to discuss with the Product Owner dropping one or more stories from the bottom of the board.

What work should I do next? When you’re ready for a new task, the task board can tell you which stories are open so you can find a way to contribute to the highest priority open stories rather than opening a new story.

Next steps

Check out fellow CSC Xavier Quesada Allue’s excellent blog on visual management, which covers this topic in much more detail.

Share in the comments: How have you made the task board work better for your team? Which suggestions from above are you going to try?

Why Longer Sprints Probably Won’t Help

Richard Lawrence — Fri, 02 Sep 2011 17:55:43 +0000

As a coach, I’m frequently told, “Our sprint length is too short. We want to change it from X to Y weeks.”

The time box—the sprint in Scrum, the iteration in XP and other iterative methods—is one of the most powerful tools in agile software development for revealing problems in a team or organization. Notice I said reveal, not fix. I’ve seen a few cases where the sprint length really was too short. More often, though, the feeling that the sprint is too short is a sign of deeper problems. Lengthening the sprint might push these problems back under the surface, but it’s unlikely to actually solve them.

Before you increase your sprint length, ask “Why?” a few times to see if you have any of the following underlying issues, and try to deal with those first. Maybe your sprint really is too short. But don’t start there, lest you miss an opportunity to improve.

Underlying Problem #1—You’re trying to do “mini-waterfalls”

It’s very difficult to fit a mini-waterfall cycle into 1 or 2 weeks. If you regularly find that testing starts late in the sprint and gets less time than it deserves, experiment with something like ATDD to move testing earlier in the work and try working on fewer stories at a time.

Underlying Problem #2—You struggle to split stories

To maximize predictability without too much overhead, I recommend 6-10 stories in a sprint. Sometimes teams want to increase their sprint length because they struggle to get even one story small enough to fit into 2 weeks. Instead of increasing the sprint length, work on your story splitting skills for a while. Splitting stories is a skill that takes time and practice to develop.

Underlying Problem #3—Meetings take too long

Perhaps your Scrum meetings, especially Sprint Planning, are long and painful. It’s natural to want to do them less often. But consider this: Do you expect to do 50% more work in 3 weeks than you did in 2 weeks? Probably. Then you’ll have 50% more to talk about at Sprint Planning. The most effective hour of a meeting is usually the first hour. After that people, get tired and distracted and accomplish less. So, by increasing the content of your planning meeting by 50%, you’ll probably increase the total meeting time by more than 50%. True, it will happen less often. But it will be even more painful than today.

Instead, work on getting better at your meetings. One team I coached decreased their bi-weekly Sprint Planning meeting from 10 hours to 20 minutes by

doing regular backlog grooming every day or two for very short periods with just the necessary team members,
planning using story point velocity rather than task estimates,
creating tasks just-in-time during the sprint, and
doing Sprint Planning in multiple passes, a high-level initial discussion and commitment based on velocity and then more detailed discussion of each story as needed.

Could one or more of these techniques help you?

Underlying Problem #4—Deployment (or merging or integration or whatever) is too hard

Perhaps you try to deploy completed stories into some kind of staging or formal test environment at the end of each sprint. Maybe you even need to engage outside release managers to do it. It’s difficult and time-consuming to do, so naturally you want to do it less often.

I wholeheartedly agree with the advice in Jez Humble and David Farley’s excellent book, Continuous Delivery: “If It Hurts, Do It More Frequently, and Bring the Pain Forward.” (p. 26) Instead of deferring the pain—and probably making it worse in the process—try to make it less painful so you can do it more often. If deploying every sprint is hard, figure out how to deploy nightly or on every commit. (Continuous Delivery is a great resource to start this journey.)

Underlying Problem #5—You can’t get anything done in 2 weeks

Sometimes teams tell me, “We simply can’t deliver anything valuable in 2 weeks, so we have to go to a longer sprint.” But changing your sprints from 2 to 4 weeks really hasn’t changed how much value you deliver in 2 weeks; it’s just given you half the visibility into progress. Instead of changing the sprint length, try these two things:

Use a concept like the Minimum Marketable Feature to group user stories into larger units of value. You’ll still work on stories, but you’ll have better visibility into how those stories contribute to releasable value.
Do some root cause analysis (e.g. the 5 whys or a similar tool) to find out why you deliver less value per week than you’d like. Maybe you have some technical debt you need to deal with. Maybe you have too much process overhead. Maybe a specialist is a bottleneck because skills are unevenly distributed on your team. Maybe you’re building on an out-of-date platform and could get more productivity with newer technology. There is a wide range of possible causes for low productivity. Whatever the cause, longer sprints are unlikely to be a fix.

Underlying Problem #6—It takes too long to get feedback

If the Product Owner takes a week to answer questions, it probably going to be very difficult to complete work in a 1 or 2 week sprint. But will a 3 week sprint be much better? Instead, find ways to shorten feedback cycles such as,

take other responsibilities away from the PO so she can focus on her role,
give the PO (or team) more authority to make decisions without having to ask hard-to-reach stakeholders, or
work to increase knowledge on the team to reduce the number of questions that need to go to the PO or outside experts (ATDD can be a great tool to accelerate this learning, especially if you use it to build a ubiquitous language).

Underlying Problem #7—Dependency on outside specialists

Related to #6, sometimes teams can’t complete a story without help from a specialist outside the team—a DBA, tech writer, expert on a particular technology, etc.—and this outside person is part-time on many teams. Before lengthening the sprint to work around this issue, try to reduce the dependency by

moving the specialist into the team,
reducing the specialist’s load so he can be more available to the team, or
growing the team’s own skills and/or authority in the speciality area.

Conclusion

If you’ve dealt with all the underlying problems you can find and your sprints still feel too short, then by all means, try a longer sprint length. Make your process for you. Just don’t start by lengthening your sprint and miss out on an opportunity to improve.

Another Story Splitting Pattern (Maybe)

Richard Lawrence — Wed, 04 May 2011 11:36:45 +0000

User stories are typically written using a template like, “As a , I want to so that .” My other story splitting patterns focus on complexity in the action part of the story. But sometimes the functional complexity in a user story is hidden in the role rather than the action. Consider: could you split the story by splitting the role and only satisfying a subset of potential users in the first story?

As the title suggests, I’m not sure this is actually a new pattern. Every example I can think of actually fits under another pattern. So, if you like, you can think of this as a thought experiment to identify simple/complex, business rule, data entry or other splits where splitting the role reveals a split somewhere else.

Share in the comments: Has discussing splitting the role for a story ever helped you find functional complexity to split the story? Can you provide an example? Is this a sufficiently distinct pattern to merit updating the original article?

Want Productivity? Focus on Predictability Instead

Richard Lawrence — Thu, 23 Sep 2010 16:07:54 +0000

Focus your team on predictability, and productivity will come. Focus on productivity, and you’ll get neither productivity nor predictability.

Focusing on predictability drives a team to:

Small user stories that can be completed in a day or two
Working on a small number of stories at once
A strong story definition of done with little or no gap between it and the release definition of done
Individuals crossing disciplines to get things done without unpredictable wait times
Making achievable commitments based on past results

On the other hand, focusing on productivity—usually leads to:

Individuals optimizing for their own productivity (i.e. lots of tasks getting done)
Over-committing
Starting stories without necessarily believing they’ll get done (“If we’re going to get all these stories done in this sprint, we’d better start them as soon as possible!”)
Sacrificing quality for speed (i.e. taking on technical debt—”Just get it done; we’ll clean it up later.”)
Communicating and collaborating less (“All that conversation slows me down. I need to focus on my work.”)

The (ostensibly) productivity-focused behaviors may show a velocity increase in the short term. But you’ll pay for it later. More likely, you’ll see an erratic velocity, sometimes high, sometimes zero. And there is likely to be some nebulous chunk of work between the last story and the release.

Over and over again, I’ve seen the predictability-focused behaviors lead to a stable or, more often, a slowly increasing velocity. Small stories are easier to estimate and to get done right. Building quality in keeps the system easy to maintain and extend. And when done really means done, the Product Owner can make meaningful predictions and commitments around delivery. “Working software is the primary measure of progress,” after all.

Note: This assumes energized work. If your team doesn’t care about getting anything done, they could predictably deliver nothing, which isn’t particularly satisfying. With this team, focus on motivation, then predictability. As the Manifesto also says, “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” Motivation comes first.

Growing DONE—How to Make the Definition of Done Work for Your Team

Richard Lawrence — Mon, 21 Dec 2009 23:34:37 +0000

Effective agile teams get things done. They build software day after day that’s not just “code complete” but really shippable. And when their product owner says, “ship it,” they can get their shippable software into production at the drop of a hat.

The Definition of Done can be a powerful tool to make these things happen…If it’s used right.

Most agile teams I see have one of four relationships with a Definition of Done:

They don’t have one
They have one but don’t really use it
They have one but can never satisfy it
They have one, satisfy it for each story, but still have lots to do at the end of a release

I rarely come across teams who use the Definition of Done to good effect day after day, sprint after sprint.

The reason why, I think, is that if a team uses a Definition of Done at all, they try to use a single one before they’re ready. I’ve discovered that most teams really need two definitions of done. For a new agile team, there’s more to do to get software ready for production than can be accomplished a story at a time. Teams that fall into #3 above probably put everything on the Definition of Done. Teams in #4 probably put just those things they could do a story at a time on the Definition of Done and left everything else for later.

The answer is two Definitions of Done. The Story Definition of Done captures what the team can do today to make each story as shippable as possible in each sprint. The Release Definition of Done captures the gap between the Story Definition of Done and what’s actually required to ship. Together these tools provide a way to visualize what done means and to make it happen as early as possible.

Here’s how to build effective Story and Release Definitions of Done…

Building The Two Definitions of Done

1. Brainstorm the List

List all the things required to move a set of features in your product to production. Engage release management, operations, help desk, and other stakeholders at this point—it’s easier to build what they need into the software than to bolt it on at the end. This list typically includes things like:

user documentation
operations documentation
monitoring and logging
performance testing
regression tested in a clean QA environment

Now, list anything required to deliver software at a consistently fast pace from iteration to iteration. For example:

automated unit tests covering 80% of code
automated story tests covering 90% of acceptance criteria
adherence to coding standards
code reviewed by another developer
all production code developed by a pair

Finally, list non-functional requirements such as:

all pages load in under a second
all pages can support 300 simultaneous user sessions

Merge these lists into one, changing the language where necessary so that each bullet reads as a continuation of the sentence beginning: “In order for a set of features to be released to production…”

2. Challenge the List

For each item on the list, ask “why?” Keep asking “why?” until it’s clear that the item is the simplest, cheapest, most repeatable way to achieve some desired goal in the release. If it’s not, change it.

This is where you challenge the existing rules around releases. Maybe your release readiness guidelines today require a complete installation guide. Could you replace that with an automated installation script?

3. Build Release Readiness In

Now you have a list of the minimal set of things a group of features must have to be released—your Release Definition of Done. Bolting those things onto an otherwise complete set of features could impose a fixed cost of weeks to the end of any release. One of our goals in agile is to allow the product owner to be able to say at any point, “This is enough, I want to start making money off of this software now—ship it.” An expensive release gets in the way.

Look at each item on the list and ask, “Could we satisfy this as we build each story instead of all at once at the end of a release?” Yes? Then move it to your Story Definition of Done. No? Could you do part of it or do something that would reduce the time at the end? Yes? Then put that on your Story Definition of Done. No? Then leave it on the Release Definition of Done.

Very few items can’t be satisfied a story at a time. The most common ones I see are performance testing in a production-like environment shared with other products and beta testing with a set of real users. But you can get a head start on even these. Maybe your test environment isn’t exactly like production, but can you make the performance constraints similar enough to at least profile for likely performance issues? Maybe you can’t beta test on a large scale, but could you get a small set of users to volunteer to use stories as they’re built and provide early feedback to make the beta test shorter and more predictable? Think hard about anything you’re tempted to leave on the Release Definition of Done.

4. Use Your Definitions of Done

You now have two definitions of done, one for every story you build and one for a collection of stories you want to release. The Story Definition of Done will inform your acceptance criteria for every story. If page load time matters, a story isn’t done until all the related pages load fast enough. Test for this. Automate these tests and run them on every build if you can.

You won’t satisfy the items on your Release Definition of Done until the end of a release. But this doesn’t mean you can forget about them until then. Keep the Release Definition of Done visible, and look for ways to test early for release readiness.

5. Grow Your Story Definition of Done

The Definitions of Done are a starting place, a statement of what your team can accomplish today. Over time, your Release Definition of Done should get smaller and your Story Definition of Done should grow. If you have 3 weeks of manual regression testing at the end of each release, come up with a plan to grow automated regression tests as you build new stories. Maybe you can reduce those 3 weeks of testing to one. If you have a tech writer spend a month writing documentation at the end of a release today, find ways to integrate her into the team to grow the documentation as you grow the software. Maybe you can reduce that month of writing to 3 days of editing and polishing.

The Bottom Line

Use two definitions of done. In every retrospective, look for ways to grow your Story Definition of Done so you can consistently build and release software quickly. If you get to a point where you can throw away the Release Definition of Done, congratulations! But don’t start there.

How to Give a Great Sprint Demo

Richard Lawrence — Sat, 25 Apr 2009 02:03:10 +0000

Exciting. Entertaining. Do these words describe your sprint demo meetings? Or are boring and unfocused more accurate?

I can’t believe how many times I’ve come in to coach a team and they’ve been surprised when I actually expected to see a software demo in the sprint demo meeting. As the agile principle says, “Working software is the primary measure of progress.” Let’s see some software!

Why are so many agile teams so hesitant to do demos? Why are demos so lifeless? Sometimes, the team’s not actually done. That makes a demo awkward. Other times, they can’t communicate what they did to the Product Owner; they don’t speak “business.” But most often, they simply don’t know how to give a good demo.

So, how do you give a good demo?

Here are a few tips:

Focus on acceptance criteria. You’ve defined what done means for the story (right?), so focus your demo around proving that you’re actually done.
Start with the demo in mind. Don’t wait to think about the demo until you’re done with the story. You might be able to write tests that double as demo scripts. And it’s best to plan your demo for a story while it’s fresh in your mind, before you move to the next story.
Prepare. Don’t ad lib. Think through an interesting scenario to prove that you’ve satisfied the core acceptance criteria. Create any necessary test data. Use tools like Watir if necessary to get your app into a state where you can start an interesting demo.
Practice. Run through the demo at least once. When you’re getting started, you might want to grab a trial version of Camtasia and record yourself giving the practice demo. Painful, huh? That just means you need to work on it.
Tell a story. Center your demo around a realistic user solving a real problem. The point is not just to show that the software works, but to show that it’s valuable.
Keep it short. If you work on your stories one at a time and get them accepted when they’re ready, you don’t need to exhaustively cover all your acceptance criteria in your demo. Instead, focus your demo on what’s interesting and what’s valuable about each feature.

The sprint demo should be the most exciting part of Scrum. It’s when the team gets to show everyone all the value they’re delivering. That’s worth investing a little time to do well. You may find that previously disinterested stakeholders start coming just for the show.

What has worked well for you in sprint demos? What hasn’t worked? Share in the comments.

Continuous Deployment

Richard Lawrence — Fri, 13 Feb 2009 15:05:23 +0000

I’ve written before about the amazing financial impact of releasing more often. And I know from personal experience the positive impact that frequent releases have on learning and on product quality and value. So, I enjoyed this post on one company’s experience with continuous releases. Yes, you read that right; they release, on average, 50 times per day.

We call this process continuous deployment because it seemed to us like a natural extension of the continuous integration we were already doing. Our eventual conclusion was that there was no reason to have code that had passed the integration step but was not yet deployed.

Read the whole thing and consider what it would take in your organization to get to continuous deployment. How fast could you go? And what impediments would have to be resolved to make it happen?

7 Tips for a More Effective Daily Scrum

Richard Lawrence — Sat, 07 Feb 2009 17:40:26 +0000

The main purpose of the Daily Scrum is for team members to make and follow-up on commitments to one another that work towards the team’s shared sprint commitment. If your Daily Scrum has become unfocused, too long, or otherwise ineffective, here are seven ways to get it back on track.

1. Do it around the task board. Have team members point at stories and tasks on the task board as they talk about their work. This keeps the focus on work for the sprint and makes it obvious when the talk becomes unrelated to the sprint.

2. Change the questions. In “One Word Can Change Your Daily Scrum” I described a way I like to change the three Daily Scrum questions to focus the team on getting things done.

3. Don’t show up. If your Daily Scrum has turned into a status report to the ScrumMaster, try taking a few days off. Let the team report to each other instead of you. Aaron Sanders has more here. Less dramatic ways to have the same effect are avoiding eye contact or stepping outside the circle. But sometimes dramatic is necessary to shake things up.

4. Don’t talk. If you’re not taking sprint tasks, you don’t need to answer the three questions. Emphasize that by not talking at all during the Daily Scrum. Use non-verbal communication when necessary, but keep your mouth shut.

5. Use a parking lot. There are legitimate things for a team to talk about in the morning that don’t fit the tightly-defined purpose of the Daily Scrum. Use a parking lot (i.e. a flip chart or section of a whiteboard) to capture those topics. Address them right after the Daily Scrum is over. You can even let team members add items to the parking lot outside of the meeting to be addressed in the next “parking lot time.” That way, they’re not trying to remember their parking lot topic when they should be paying attention to the Daily Scrum.

6. Actually stand. It shouldn’t be necessary for us to stand to have a short, high-energy meeting, but it really seems to help. If your team has started sitting for the Daily Scrum and it’s running longer than 15 minutes, it might be time to try standing again. Set an example by standing for the whole meeting, and maybe ask one or two influential team members to do the same. Combining this with #1 makes it feel less awkward.

7. Pass a token. Jason Yip describes how introducing randomness and play into the Daily Scrum by tossing a ball to the next person to speak can add energy to the meeting.

What else have you done to keep your Daily Scrum effective? Share in the comments.

Agile Product Management Boot Camp

Richard Lawrence — Thu, 22 Jan 2009 03:52:29 +0000

Bob Hartman and I are offering an Agile Product Management Boot Camp course March 9-10 in Denver. If you’re a product manager, product owner, business analyst or in any other product facing role in an agile (or soon-to-be agile) environment, this intense, hands-on course is a great opportunity for you to ensure that you’re helping your team maximize the value it delivers.

Topics include…

Understanding Agile: Process and Driving Principles
Ensuring the Right Things Gets Built: Testing and Acceptance
Specifying What to Build: User Stories
Deciding What to Build First: Prioritization
Defining Customer Value: Minimum Marketable/Releasable Features
Project Acceptance: Building a Product Vision and Business Case
Product Management 101: Useful Tips, Tricks and Techniques
Pulling it All Together: Project Simulation

You will leave the course knowing how to:

Deal with the team outside of just planning meetings, demonstrations and retrospectives.
Break down requirements into usable stories – even when the team is unable to help.
Deliver value in stages rather than all at once.
Write acceptance criteria to ensure the right features are being developed.
Create a project business case and vision.
Perform basic product management functions in an agile way.
Effectively interact with customers, community, stakeholders, managers, and the team.
Make a convincing business case for using agile for more projects.
Continuously improve.

The course registration fee is $1,200, but readers of this blog can take advantage of a special 2-for-1 offer. Simply register with discount code RLB2FOR1, and we’ll send you another code you can give to a colleague to register for free. Seats are limited, so get your registration in today.

Short Answers #2: What to Focus on in 2009

Richard Lawrence — Sat, 03 Jan 2009 23:48:33 +0000

It’s officially a series now. In this Short Answers video, I answer the question, “If my Scrum team could work on one thing in 2009, what should it be?”

Of course, adopting agile engineering practices and getting better at product management are often easier said than done. If you’d like help getting started with some of the practices I mentioned in the video, I’m running a New Year’s training and coaching special with 7 ways to get 2009 started right for less than $2,000.

Books I mentioned in the video:
The Goal by Eli Goldratt
It’s Not Luck by Eli Goldratt