Viewing entries tagged
ambiguity

Pet Peeves: Getting Agile Requirements ‘Right’

Comment

Pet Peeves: Getting Agile Requirements ‘Right’

I’m sorry but I need to vent. I’ve been encountering these patterns a bit too often lately and I just need to get these thoughts off my chest.

The patterns are these:

  1. Organizations and teams consider it the Product Owners role/job to write every aspect (word) of every User Story. And, if the stories aren’t “complete enough” the team kicks it back to the Product Owner to do a better job.
  2. User Stories are too robust. I’m being kind here. The Product Owner / Analyst writing the story writes a complete requirement (pages, all information) before ever showing it to the team.

From my perspective, these are both agile requirement anti-patterns, you shouldn’t be doing it this way, and I’ll try to explain why. In both cases, I think it goes against some of the very core principles of the agile methods. It’s not changing your Waterfall views and while, you’re saying you’re agile on the outside, on the inside you’re still handling your requirements the same old way.

 

Comment

Comment

The Agile Project Manager—Fostering Controlled Chaos

As you may or may not know, I’m an active agile coach. I often get asked to enter new teams and jump-start them or assess their overall level of agile-ness. One of the ‘smells’ that I look for in a strong and healthy agile team is what I’ll call controlled chaos or perhaps a better phrase would be guided chaos.

You see, the atmosphere in these teams isn’t safe nor predicted too far in advance. The teams don’t have a false sense of security. They’re working on a short list of features in close collaboration with their Product Owner. They know that challenges will rise up to meet them. Risks will fire. Team members will get sick or get married or tend to ill parents. And the design approaches and code won’t always work as advertised.

Comment