Scrum Misconception – Speed to delivery versus ROI

I recently read a brilliant article on the myth that Scrum is faster and cheaper than traditional development. I highly recommend reading it, and no, I’m not affiliated with the writer or!

The article articulated something I feel is poorly understood. Following the ceremonies, roles and artifacts of Scrum is not a faster way of developing software. In fact, I am fairly certain that if you had two similar teams, gave them the same large specification and had one team develop to that specification using two week increments and the other using a waterfall approach, the second team would finish earlier. Why? (I’ll explain the underlining below) Continue reading

I have a GREAT idea!!!….

I was recently asked what to do when a stakeholder or client asks for a feature or user story that either doesn’t make sense or is based on flawed logic or on a lack of technology or domain knowledge. Sometimes stakeholders’ pet projects, wacky ideas and whims and fancies can be the nemesis of a product owner and her team. They waste valuable time and resources and in some cases they can affect team morale, as the team feels that they are on a fruitless errand.

I have two solutions to this problem: Nip it in the bud or meet them halfway.

Continue reading

A 5th statement in the Agile Manfesto?

I’m going to make a bit of a radical proposal here. I propose that we add the following to the Agile Manifesto:

We value interpersonal skills over technical knowledge

I’m not really proposing that we change the manifesto. I’m also not stating that technical knowledge is not extremely important. Remember that the Agile Manifesto states that we value the things on the left more than the right, but we still value the things on the right. I’m just making a point that I think a lot of organizations miss that affects their ability to really get the most out of Agile and Scrum.

Continue reading

Agile and the Analyst

I recently took the Scrum Master course and certification. If you work in software development in any capacity and you have the chance, I recommend you take this course, even if you aren’t a proponent of Scrum itself. Approach it with an open mind and you’ll come away thinking a little differently about managing people. I’m not saying you’ll be an Agile convert, but it will make you re-examine lot of the fundamental assumptions of traditional project management.

As a business requirement specialist, I was particularly interested to see how an experienced analyst might fit into Scrum. I had read a couple of books on Scrum, Kanban, and other Agile topics but I found them somewhat vague when it got to Continue reading

Honey, Vinegar, and Customer Participation

Recently I participated in a series of instructor-led online courses on Scrum/Agile. During the section on Sprint Planning, the instructor mentioned that shorter iterations provide more agility, and organizations should aim to achieve weekly sprints. This prompted one student to ask:

“The business people I need won’t attend my monthly meetings. How can I get them to attend a weekly planning meeting?”

This is one of the most common complaints or questions I receive, so it was no surprise that a student asked it here. However, what did surprise me was the instructor’s response:

“Tell them that if they don’t participate they can expect the software to be buggy and not meet their needs.”

I have witnessed this sort of approach before, but I was shocked at this answer from someone who claimed to be an expert in Agile. It contradicts the fundamental principals described in the Agile Manifesto: Continue reading