Tag Archives: change management

“Agile just doesn’t work for us”

I bet I grabbed your attention with that title.  Before you proceed on, please be warned that this post is definitely more of a rant.  But, if you can’t occasionally rant on your own blog, then what’s it good for anyhow?

To those that say “Agile just doesn’t work for us”, I say bullshit!  For some reason, some people think their company / organization / product is so different from the rest of the world that a process like Agile will not work for them.  When it comes to work, we are all more alike than different.  Those same people tend to look for every opportunity to blame any issue on Agile.    The team didn’t get a user story done … “Agile just doesn’t work for us”.  A stakeholder made a late change … “Agile just doesn’t work for us”.  I can’t make it to the stand-up on time … “Agile just doesn’t work for us”.  We had a bad retrospective … “Agile just doesn’t work for us”.  We deployed a bug to production … “Agile just doesn’t work for us”.  It rained today … “Agile just isn’t working for us”.  You get the point, I’m sure.

Now, don’t get me wrong … I totally get statements like “This isn’t Agile” or “We aren’t being Agile”; that, I can deal with.  Just don’t make rash statements that insinuate that the process is to blame for what is a problem that would / may exist regardless of Agile.  In other words, don’t hate the process, hate the weaknesses in ourselves that the process exacerbates … whatever it may be, lack of discipline, poor collaboration, no accountability, bad leadership, etc.

Dig deeper beyond the rash statement and you will find that often it is not the process that doesn’t work for us, but rather we don’t work for the process.  When I hear “Agile just doesn’t work for us”, I like to probe further with questions like …

  • What specifically do you think is not working about Agile?
  • What have you done to try to solve the problem?
  • Would this / did this / could this problem exist under any other process?

So, to all those that are quick to say “Agile just doesn’t work for us”, don’t be a hater.  Look within your own locus of control (never thought I’d have the opportunity to use that phrase beyond college) before you jump to judgement about a process that has worked successfully for many diverse companies all over the world for many years.

Advertisements

The Power of the Backlog

The power of the backlog is incredible in a Scrum world.  If stories are the promise of a future conversation, then the mighty backlog can certainly start, end, or even influence a conversation.

The backlog can start a conversation … “Do you have it on your backlog?”

The backlog is a conversation starter when something new is identified as being a valuable enhancement to a given product.  Of course, value is generally subjective, but in this case, value is in the eye of the Product Owner with input from all the various stakeholders.  Maybe this sort of conversation is started from an executive, a stakeholder, the team, or even the true end user themselves.  Regardless, the backlog is that Scrum-sacred home where cool, hopefully valuable things go to wait until their story is planned into a sprint (and become part of the sprint backlog).  Even if the story never gets planned into a sprint, there is some satisfaction to the person that came up with the idea that it has been considered and is “on the backlog”.   As a ScrumMaster, I know that I feel satisfied when the Product Owner says, “Yep, I’ve got that on the  backlog already”.  If the idea is truly proven to be the next most valuable thing to work on, it should be planned into an upcoming sprint.  If not, it had it’s time on the backlog and maybe it falls off or is killed someday.  Call me sadistic, but I actually enjoy the killing of the occasional low-value backlog item.

The backlog can end a conversation just the same … “That’s not on our sprint backlog. Let’s backlog it for now.”

The backlog is a conversation end-er when something is brought up that isn’t on the current sprint backlog.  It’s amazing how much of an impediment (possible) future work can become if allowed to run wild.  In the old days of traditional waterfall project management, this was called scope creep and typically handled like a change request under whatever change management policy may have existed.  In most cases, meetings were called, the change was assessed, guess-timates were given, and friends or enemies were made as some change committee yeah-ed or nah-ed it.  All of that took time, time away from the team working on the approved scope of the project; more time in some cases than others depending on the degree of the change and the corporate bureaucracy in place.    Under Scrum, the power of the backlog makes clear what is in the current sprint backlog and what should be “backlogged” for a future sprint.  This means the team remains focused on the current sprint.

The backlog influences conversation … “We might want to add another developer to the team. I’ve got a 2 year backlog built up!”

The backlog influences conversations day in and day out throughout the life of the product.  One might even say, the backlog speaks.  The backlog says …

  • How much technical debt still exists for a product (especially if you religiously capture bugs and such in the backlog).
  • How much value remains to be implemented for the product.
  • Whether continued investment in a product or Scrum will continue for 1,2, 3 or however many months/years.
  • All that the team accomplished and the value delivered in past sprints.
  • And, so much more!

So, next time you overhear things like “it’s on the backlog”, “backlog it”, or “it’s not on our sprint backlog”, just remember that it’s all in the power of the backlog.