Part 1: Sometimes Change is Really, Really Hard

Or Can This Client be Saved?

I know that I haven’t blogged for a while. My move from Portland, OR to Austin, TX was a big change for me and it took more energy than I anticipated. I’m finally settled and working on a new contract. My current client moved to scrum without training or fully understanding the agile method. Therefore, they transitioned themselves into a bigger problem than any I’ve had in my move half way across the country.

We like to think that businesses hire consultants at the beginning of their agile transition, to ensure everyone understands how to practice scrum and to reinforce the shift to an agile mindset. But, we know that many businesses just start practicing what they call agile or scrum, and they don’t hire consultants until some aspect of their process is so painful they must change or face even more declines in productivity.

I am usually up to the challenge. I’ve been practicing agile scrum for over 10 years now, and I’ve seen many forms of practice. However, in my new back yard, I find myself in the middle of the biggest mess that I’ve faced in my decade long career.

As change agents, we hope to be brought in at the highest levels of the organization, so we can lead with the support of upper management. However, in reality, we are brought in as scrum masters or coaches, working at the team level without access to upper management. Until now, this has not been much of an issue. Scrum is a team sport right?

Right…but…scrum is an application development method. I’ve written many times about how product management, project and program management, and even release management are Forces outside the team. Yet, these Forces impact the team’s ability to practice scrum in the manner necessary to predictably get stuff done and allow them to leave work by 5 pm and not work evenings and weekends.

The Force is not conspiring to ensure my teams can successfully practice scrum.

Here’s my challenge:

  • We don’t have the right team organization. In this case, the Product Owner is not at the right level of authority.
  • The Project Management Office (PMO) processes are at odds with agile methods: project sizing in Dev Days, story sizing in Story Points (maybe) and tracking task work in Hours.
  • Release Management is chaos. Releasing code to Production after acceptance is so time consuming that velocity is drastically impacted.

It’s easy to recognize the root cause of problems and offer suggestions. It’s not so easy to influence upward and convince senior management that the pain of change is less painful than their current situation where almost every project is yellow or red, with unpredictable delivery and disappointed customers.

Is the problem too big for me to solve from the lowly level of scrum master for 2 scrum teams in Austin while working for a major international company? Maybe. We’ll see.

I heard many times that we aren’t given challenges we can’t handle. So for now, I accept.

I continue to train and encourage my own scrum teams to correctly practice scrum in a way that allows them to be successful in this crazy environment. I am helping them learn how to write better stories, size in story points, use their voice to accept or not to accept a story for sizing or into the sprint backlog, and to time box. Our goal is determine a realistic sprint velocity.

I work with the local Engineering Manager and the PMO Director to outline symptoms, root cause and potential solutions to problems. This is the first step to influencing upward.

I have offered to train as many teams as possible in the GSD Scrum Method, our real world application of scrum. None of the teams have received formal training or coaching.

This is my first in a series of posts outlining my journey.

Hopefully, it’s not too late and I am truly up to the task.

I appreciate any and all suggestions.

Cynthia Kahn

Cynthia Kahn


Cynthia Kahn

read more