schapendonk.org

Scrum empowers The Team to do everything it needs to do to get the job done. In the process, it should self organize for best results. According to Tuckman’s model, every self organizing team goes through four phases:

• Forming - everybody is really polite and gets to know each other;
• Storming - while trying to cooperate, team members are confronted with different ideas, values, beliefs and assumptions they all might have;
• Norming - the ideas and beliefs converge to a shared vision;
• Performing - the team reaches a hyperperforming stage in which team members trust and depend on each other to get the job done.

To go through these phases takes a couple of Sprints, depending on the team members, sprint length, etc… etc… In summary, you need to invest to get a hyperperforming Scrum team.

Some teams include (or even exist entirely of) people who are hired specifically for the project at hand. Is it feasible to introduce Scrum in such a team? Is there a tradeoff between the team forming effort and project length?

Why would I pay the cost of introducing Scrum for short projects (less than, say, 3 sprints)? However attractive this shortcut may seem, I think it’s a pitfall you shouldn’t step into. Remember the environment that Scrum supports best: complex projects, with considerable uncertain technology and requirements. The best solution for complex problems comes from solving them together. To solve a problem together, you need to be a team. And each team goes through Tuckman’s phases. There are no shortcuts.

A team specifically assembled for a short project may never reach hyperproductivity. That’s a pity. But the solution delivered will still be better than it would have been in a command and control environment.

Technorati: scrum, tuckman, team, contractor

Tags: Scrum // Add Comment »

User stories are the de facto standard to handle requirements in an agile software development environment. They can be anything from small index cards to a few pages of text in organizations that appreciate a bit more ceremony.

Years ago, Bill Wake coined the acronym INVEST to verify if you have the right kind of user stories. He said that user stories should be

• Independent
• Negotiable
• Valuable
• Estimatable
• Small
• Testable

I just read something about the new INVEST model, which changes the meaning of Small to Sized appropriately. Mike Cohn appears to use this new definition and I saw a few references on other blogs as well.

I’m not sure I agree. A product backlog is like an iceberg: user stories on the top should be ready for inclusion in a sprint, and user stories further down the road can become Big Ugly Epics. What is so INVEST about an epic? Nothing, IMHO. You can’t negotiate an epic. You can’t estimate an epic (sure, 100 points, XXXXL or a question mark will always do). You can’t test an epic. It might be independent and the product owner can probably put some business value on it. But that’s about it.

Instead, we should relate the definition of INVEST to the ranking of the user story in the backlog. For all stories that are ready for sprint inclusion, each story should conform to INVEST. No excuses. For stories further down the backlog, INVEST can be more loosely applied. As stories rise the backlog, they should become more and more INVEST until they are ready for a sprint.

I think that this distinction is better than watering down the definition of INVEST.

Technorati: INVEST, Scrum, user stories, product backlog

Tags: Scrum // Add Comment »

Kees just wrote something about project management, change management and the involvement of the information security officer in projects.

He argues that the information security officer should be involved in almost any project and he’s probably right about that.

More generally speaking, the information security officer is ‘just another stakeholder’ for any project. And for a project to be successful, it should pay attention to the needs of its stakeholders.

But… while there are many stakeholders, there is usually only one sponsor of the project. Does he consider ‘information security’ important to ‘his’ project? Who would have to convince him that he should reserve some resources to achieve an acceptable level of information security?

Seems like a perfect role for the information security officer. Even better if that officer is backed by a proper information security policy (I guess it isn’t a coincidence that Kees has an opinion about that too ;-)).

Doesn’t it all come down to the fact that we tend to overlook the Ilities in projects?

Tags: Management // Comments Off