Archives for Oct,2014

You are browsing the site archives by date.

A Plan to Discuss is Not a Plan

Many companies have been trying to reduce the overhead of meetings, to no avail. Here is one idea that may help. Never set up or attend a meeting where the subject line reads:

“Discuss [topic]”

…with no agenda. Here’s some examples of meeting invites I’ve had over the years:

  • Discuss technology direction
  • Discuss production outage
  • Discuss deployment plan
  • Discuss new design

Of course these meetings never have agendas. What value do these meetings provide? None! A friend of mine compared these kinds of meetings to bar conversations. You know those; lots of fun dreaming about “what ifs” and coming up with a plan on how to “make it big”. And what happens after those conversations? Nothing. It’s as if they never happened.

Let’s rewrite those meeting invites to be a bit more productive (don’t forget to include an agenda!)

  • Decide whether to build the application using .NET or Java
  • Create an action plan that minimizes production outages
  • Decide whether to use Ruby on Rails or CakePHP
  • Define the test cases for User Story XYZ

Notice that the verbs imply finality, while “discuss” does not. To “Decide”, “create”, or “define” means that you will leave the meeting with something finalized. You now have a definition of “Done” for the meeting.

You will never know when you are “Done” if the goal is to discuss.

Talk to Us Today

Why I Would Never Go “Enterprise Scrum”

I’ve had some recent debates regarding whether we should start an “enterprise Scrum” initiative, i.e. WE WILL BE A SCRUM SHOP.  I would have completely supported this several years ago.  Now, I am completely against it.

In an organization of any significant size or age, there typically have been methodologies that have been introduced, pushed, then they fade away into the far recesses of everyone’s memories.  One characteristic of these methodologies is that they have very specific rules.  You can’t add to, change, or remove any of the rules.  Why?  Well, because you wouldn’t be “doing” X methodology!!!

People have a habit of dogmatically following whatever methodology management makes them follow.  Now let’s say we are doing “Enterprise Scrum”.

This means that you are performing the following ceremonies:

  • Release Planning
  • Sprint Planning (every sprint)
  • Daily Scrum (every day)
  • Sprint Review (every sprint)
  • Sprint Retrospective (every sprint)

And, you have the following roles:

  • (1) Scrum Master
  • (1) Product Owner
  • Team (self-organizing)

And you will have the following artifacts:

  • Product Backlog
  • Sprint Backlog
  • Burndown/Burnup charts (some say Scrum requires these, I don’t think it does as it’s not clearly articulated and varies by source)

So we’ve gone enterprise Scrum.  We’ve introduced this “by the book” Scrum.  However, we’ve also preached “inspect and adapt”.  But, in Scrum, the above items are non-negotiable…you can inspect and adapt all you want, but you can’t change the ceremonies, artifacts, and roles.  Can you add to them?  Sure, but you can’t “change” them.  And, in reality, making “inspect and adapt” a cultural “habit” is spectacularly difficult and rarely truly attained.

What if we have a Scrum team that wants to do a retrospective every other sprint instead of every sprint?  Blasphemy!!!  <finger-pointing> YOU are doing SCRUM-BUT!!! </finger-pointing>.  Really?  What if the team, Scrum Master, and Product Owner are all cool with it?  Now we have a bunch of stress, spinning, and politics because we want to make a change to our enterprise standard Scrum.  In reality, this is perfectly okay.  However, since we’ve pushed “Enterprise Scrum”, we have totally boxed ourselves in.  There will even be people who will not want to add techniques because “Scrum doesn’t say so”. Do those people truly understand the essence of Scrum?  No.  But they will cause disruption and waste

What if you don’t want to do iterations?  What if you want to deliver continuously instead of iteratively?  No Iterations?!?!  Blasphemy!!!!  <finger-pointing> YOU are doing SCRUM-BUT!!! </finger-pointing>.

You know all of this could have been avoided?  By NOT saying we are going “Enterprise Scrum”.  I believe the best way to roll this out is by pushing Agile and Lean and what makes sense on a project by project basis.  Along with this there should be some foundational elements that are standard regardless of the methodology/toolset that is used. In addition, there needs to be a COE that can ensure that consistency is maintained without bureaucracy, and that knowledge gained is effectively utilized to continuously improve.

Please don’t misunderstand my intention here.  I am not bashing Scrum.  I LOVE Scrum.  I always use Scrum when I execute projects.  However, I’ve had rare cases within the same company where Scrum was NOT optimal, but Kanban was. I was very thankful that Scrum was not the required standard.

Talk to Us Today

Experiencing the Agile Transition

There’s a benefit to working on a team as it transforms to Agile as opposed to jumping ship and moving from a company without Agile to one that practices Agile.

Don’t get me wrong – moving to a new company and experiencing Agile is a cool thing. But seeing a team of people you’re familiar with as it transforms is powerful. Watching familiar frustrations fade and seeing timelines shrink – with the same people on the project – is exhilarating.

The first time Agile was introduced to me, it was proposed that we adopt Scrum. My team was barely meeting our deadlines and we were working twelve hour days. We always managed to deliver, but it was because we were killing ourselves to do so. Often we’d be on conference calls at night from home, trying to finish up pieces of our product before a release date. We operated under a sense of constant panic and rush.

When we were asked by our project manager to read sections of Agile Estimating and Planning and User Stories Applied (both by Mike Cohn), we couldn’t believe he was making us invest time in something like a new methodology while we were all struggling to just keep our heads above water. But he insisted, and we all grumbled our way through our first few weeks of Scrum, waiting for it to fail and for our PM to allow us to go back to what we were doing before.

I clearly remember thinking that this would be the thing that pushed us into failure. We didn’t have time to mess around with some new methodology. I hoped that our PM would realize that before it was too late, but I had no option other to go along with him and indulge his new hair-brained idea.

Somewhere into our second week, we began to understand the process and embrace the tools. Somewhere into our fourth week, it became something that we would all insist on continuing even if it was no longer required of us.

Days of frustrated moans and frantic hallway conversations morphed into coordinated efforts and understanding.

Nights of working from home vanished as our estimates and efforts became more effective.

Rather than packing up at the end of the day and rushing home to complete something that we just found out we had to do, we were packing up and heading out for drinks because we knew that we were on schedule.

Relationships began to solidify, and our team felt a bit like soldiers returning triumphant from battle. (I know that sounds dramatic, but it really was a battle for us before Scrum. We all have mental scars from the days of fighting toward deadlines. From giving our all and realizing that our all was barely enough to pass muster.)

Other teams saw what our team was doing, and began to implement Agile, as well. Scrum terms became a part of daily communication, and the entire office changed dramatically.

Before Scrum, it was a stressful environment full of high achievers who constantly felt as though they were tugging against some invisible force in order to complete the bare minimum.

After Scrum, those same high achievers were allowed to sail forward together. The entire culture of our office changed within six months of Scrum making its way onto our team. (Remember – same people, same products, same office, same leadership. The only thing that changed was the fact that we became Agile.)

If I hadn’t been there for the transformation and experienced it firsthand, I don’t think I would have understood the significant difference that Agile can have on not only project completion, but on the people involved, as well.

Talk to Us Today