People need mastery and purpose, not bonuses

Pay people enough that they don't have to worry about money, and they'll perform well. Don't bother with monetary incentives beyond that. Want people to perform better? Establish an environment that encourages mastery and purpose.

That's the essence of this great video from the nice people at the RSA. Thanks to Jeff Sutherland for the pointer.


See Damon Poole at Agile Boston tomorrow

Damon Poole will be at Agile Boston tomorrow night.  Here is a preview of Damon's talk:
KANBAN and SCRUM, Like Chocolate and Peanut Butter
You may have heard that Scrum and Kanban are mutually exclusive or that Kanban isn't good for large software projects. In fact, much as Scrum and XP play well together, so do Scrum and Kanban.
This session will introduce Kanban from a Scrum perspective, show how the Lean practice of "One Piece Flow" is the key to both, and look at how to mix and match Scrum and Kanban to fine tune a process that fits your circumstances. This will include: decoupling once-per iteration activities from the iteration, work-in-progress limits, and the concept of "pull."
Register for the event, and I'll see you there!


Sprint length: it's all about batch size

What is the ideal sprint length?

I've been thinking about this a couple of ways. First, what is your definition of Done? For my teams, Done means, concisely, it can be deployed in production, and people can use it world-wide.

Then, think about your minimum batch size. How much work do you have to do to be able to add some business value and be Done at the end of a sprint? In addition to implementing new stories, what other things do you have to do each sprint to be Done, and how long does that overhead take?

For my teams, two weeks is the right sprint length. At one week, our maximum batch size is approximately 0--we add hardly any stories of business value for it to be worth our time, given the other sprint-Done activities that we do each sprint. With a two week sprint, we can add value and get the system totally stabilized and ready for production deployment. More than two weeks isn't worth talking about, because we can get stuff Done in two weeks.


If you're not Done, you're not Agile

Done is the crux of doing Agile well. You can do all the Agile activities--the iteration planning, the daily standup, the burndown--and still suck. But if you focus on getting things Done, two things happen. First, you start to actually get stuff done, and you can recognize your success. Second, when you don't get stuff done, you know it, and you recognize your failure. When you know you failed or are failing, suddenly all your activities have focus.

When you focus on Done, your daily work has focus: get stuff done! Your daily scrum has focus: point to tasks on the board that you got Done yesterday and that you will get Done today. What is preventing us from getting tasks Done? A ha! Now we have focus, the ability to identify impediments, and the ability to remove them, every day.

When you focus on Done, your sprint has focus: get your sprint commitment done. Your sprint retrospective has focus: either we got the sprint Done, or we didn't. If we got it Done, what did we do that made us successful? Let's repeat those things in the next sprint. If we failed, why? What impediments prevented us from getting done? A ha! Now we have focus, the ability to identify impediments, and the ability to remove them, every sprint.

Done is the crux of Agile because Done focuses you on getting done, and on removing impediments and making improvements. Removing impediments and making improvements is the crux of improving your velocity and becoming a high performance team. The ability to get stuff Done is what Agile is all about.

If you don't know what Done means, you can't get anything done. What is your definition of Done? Is it the same as your customers' and managers' definition of Done? How does your definition of Done help you get stuff done, and how does it help you remove impediments and increase your team's velocity?


Scrum and Agile lack credibility outside our community

At the Scrum Gathering in Orlando, we talked about company management as an impediment to the adoption of Agile and Scrum within organizations. Within the Scrum/Agile community, we are all believers and advocates. We network within our community. We publish data that support the adoption of Agile and Scrum, and we trust the data because they come from our community.

We thought that part of the problem might be that company management lies outside of our community. Our community's studies, reports, and supporting data don't show up in the things they read. We wondered what it would take to get more crosstalk between our communities, and how to get our stuff published in places that have credibility in the management community.

I recently read The Business Value of Agile Software Methods by Rico, Sayani, and Sone. The authors do a good job documenting various Agile practices and their return on investment. It is a businessy book, and we can use it when we present to the management community.

What else can we do to engage the individual managers and the management community as a whole? What magazines should we publish in? What conferences should we present at? What else can we do to make Agile and Scrum part of the management community's vernacular?

(Crossposted as a LinkedIn discussion)


Related Posts with Thumbnails