Share This Post

It’s fun to ask a company or a team if they are using agile development methodologies. You might get a “no”, but you rarely get a “yes” that isn’t followed up with a “but…”. The “but” can be simple little things like the team doesn’t self-organize, or be something a lot more serious. I’ve never come across a Scrum team that does everything the theory says they ought to, and I think that is the way it SHOULD be – you adapt agile concepts to your particular people and circumstances. That said, there are a few fundamentals – the agile manifesto, to be exact – that you need to jealously guard.

Let me cite an example. There was a group that had been “doing agile” for better than six months. When I asked who the product owner was, I was told it was a director. This puzzled me a bit, so I asked if he was the one that managed the product backlog. The answer was no – that was being done by project management. There were Product Managers, but they weren’t involved in the Scrum activities. A closer look at the product backlog (which had been front loaded with requirements gathered and expressed in waterfall fashion) showed it didn’t look an awful lot like a product backlog. Stories weren’t actually getting completed in the sprints, and grooming was mostly just saying what would be in the next sprint that would be starting “next week”. The engineering team wasn’t involved in reviewing or accepting the stories that were in the sprint, and there weren’t really reviews going on at the end. They WERE doing daily standups, having a Planning Day (sort of) and a Review Day (kind of).

I don’t want to give the impression that this group was unmotivated, or sloppy, or in any way trying to break the system. They just hadn’t caught on to a few of the basics. To their credit, they were eager to get things righted and charge after the goal.

The first thing to do was to get a person to be the real Product Owner, and then to get them to order the top of the backlog. Luckily, the engineers received Scrum training about that time as well, so they were up to speed on things like estimating effort and such. The Product Owner got going on getting the stories shaped up, and then with the engineers started doing the grooming to get the acceptance criteria in good condition. It was almost magical to watch the team slowly evolve from the “doing” (or pretending) agile mindset, to actually *being* agile.

Whenever I am coaching a Scrum team and they trip over some aspect of agile delivery, I try to go back to the basics – the agile manifesto – to couch the recommendation or answer to their problem. If they get the why of agile, then the what make sense.

More To Explore

Visuals in Requirements Mapping

In Praise of Requirements Mapping

Learn how to tie software requirements together with visual models and other artifacts created during the analysis process.

It’s a Matter of Trust

The combination of pandemic and moving to a rural community has increased the amount of shopping I do online, but even before those events I found myself depending more and