Kanban vs. Scrum: Kanban is NOT for Software Development, but Scrum is!

The Scrum Crazy Blog

Last week I was a panelist at the Agile Denver meeting, where the title of the panel was Kanban vs. Scrum! The Big Smackdown!

If you click through the link, you’ll notice that the title was misleading, on purpose, as is the title of this article(“Kanban vs. Scrum…”).  However, I want to catch the attention of those who think that this is even a valid question or consideration.  The title also speaks to a common problem in the industry that has been around for several years, and won’t seem to go away.

There are a number of software teams and organizations that think they should choose between Kanban and Scrum as their software development process.  This is a GIANT and RISKY mistake, in my professional opinion.

It’s not an either/or proposition.  Scrum is about software development.  Kanban is about change management.

There are several reasons why choosing Kanban as your…

View original post 1,293 more words


The Bitterness of Poor Quality



- Benjamin Franklin

– Benjamin Franklin

What’s In a Name? That which we call a developer…

I just saw some comments in a discussion thread about who should be contributing to story sizing when using Planning Poker. The question was about whether or not the Scrum Master should give a size estimate or should just the ‘core’ members give their estimates.

Surprisingly, several people responded and said only people who touch the code should be estimating. Those people are wrong.



Anybody who will do work in order to complete the story should be involved in estimating, whether you’re using Planning Poker, or any other method. Remember, when you’re sizing stories you’re trying to gauge the effort that will be required. Therefore, everybody’s effort should be taken into account.

I think the confusion comes from the fact that so many of us are used to thinking of a developer only as someone who writes code. But Scrum calls anybody who isn’t the Scrum Master or the Product Owner a ‘Developer’. That means testers, BSAs, and anybody else that will contribute to the story getting done is a Developer. But what we call them isn’t the important part. What matters is that the right people are in the room and they arrive at a size that is informed by all perspectives that matter.

11 Books Every Leader Should Read

Bob Sutton is Professor of Management Science at the Stanford Engineering School and a bestselling author of several books such as The No Asshole Rule: Building a Civilized Workplace and Surviving One That Isn’t. I saw Bob give the keynote presentation about Scaling Excellence at the Agile2012 conference in August of this year and really enjoyed it.

Bob has updated his list of recommended books for 2012. He knows a thing or two about leadership and people so if he likes these books, I think they’re worth a look.

Semantic Diffusion

Recently I was on a conference call with several Agile practitioners and the person who usually facilitates the meeting – let’s call him Peter – wasn’t able to be on the call that day. He asked another person to run the meeting for him. As the call got started, the person covering for Peter said, “Peter asked us to self-organize today so let’s get started”.

I winced just a tiny bit when I heard that. Was it necessarily wrong to use the term ‘self-organize’ in this context? Maybe not wrong, but it’s a good example of what Martin Fowler calls Semantic Diffusion. Martin says, “Semantic diffusion occurs when you have a word that is coined by a person or group, often with a pretty good definition, but then gets spread through the wider community in a way that weakens that definition. This weakening risks losing the definition entirely – and with it any usefulness to the term”.

I’m sure some of you might think, “Oh please, get over it. It’s just a word”. To that I say, it’s not just a word, it’s an important word, and an important concept as well. In fact, it’s so fundamental that it’s one of the 12 principles of the Agile Manifesto, “The best architectures, requirements, and designs emerge from self-organizing teams.” A self-organzing team, when faced with a new challenge, figures out how to organize themselves and their work to accomplish the goal. There was no challenge and we weren’t architecting or designing anything. We were just having a simple meeting.

So I encourage you to use words carefully, lest they lose their important meanings.


Requirements Traceability on an Agile project


Agile Transformation is hard. You need a big appetite.

Appetite for change.