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

How Agile Does Your Team Need to be When You First Transition to Scrum?

Your First Transition to Scrum May Need to Evolve in Stages

Are you having trouble with your transition to scrum? Is it difficult to get everyone on board with the agile mindset? Sometimes it’s better to just dive in, do what you can and work out the kinks as you go along. We’re agile, right? Don’t overthink it. We can help our co-workers become more agile as we work through the process.

However, just because you don’t practice every aspect of scrum at start of your team’s transition, does not mean we advocate a hybrid approach. We recognize that ripping off the waterfall bandaid can be painful. So, sometimes you have to start without 100% understanding and buy in.

Don’t wait. Keep your eyes on the prize. The ultimate goal is to practice all aspects of scrum, but first recognize that scrum is a continuous learning method.

I recently worked on a project where the development team complained that the business kept changing their minds about requirements, even through final user acceptance testing. Sounds familiar, right? We all know that in the waterfall world change should be avoided this late in the game. The first phase of the project wound up delivered 6 months late. And guess what? The business still wanted more changes.

I suggested to the team that the second phase begged for an agile approach. So, for the next round of enhancements, which were significant, we went agile. Phase 2 was already underway when we made this decision, but we scrambled anyway to transition to scrum.

We set up Jira as the tool to manage the work. We planned for our first sprint by walking through the high-level requirements and defining the epics and potential stories. To be honest, it wasn’t pretty. The team kept trying to create stories out of tasks instead of deliverables. I spent a lot of time reiterating the concept of slices rather than layers (check out Chapter 3 of the GSD Handbook about story writing).

Our first sprint actually took us about 4 weeks to adjust to the new 2-week sprint format. We didn’t close any stories for the first 4 weeks. However, it was amazing how the daily standups served to bring the team together and smooth the work into an efficient rhythm. The product owner was engaged, the tester stayed involved with everything that was going on, and the development team began to flourish. A forum to ask questions and receive immediate answers to questions saved a ton of rework. In the end, implemented a significant number of large enhancements in almost half the time it took us with the original effort.

Now, as we begin to prepare for our next project together, we are formalizing our team contract and retrospectives. We now are ready to practice the scrum ceremonies as intended. Phase 2 was considered a success and the team is excited about scrum and agile.

Everyone agreed that jumping in (kicking and screaming) to become agile helped the team transition to scrum and adopt and agile mindset, which now everyone can see pays great dividends.

Have you had any experiences like this? I’d love to hear them!

Gerri Slama Grove

Gerri Slama Grove


Gerri Slama Grove


read more

Core Project Management Functions must Continue after Transition to Scrum

Who on your Scrum Team should Perform these Core Project Management Functions?

You’ve convinced your bosses to let you introduce Agile Scrum into your company and you’ve picked your pilot project. You gathered your team, trained them, you’ve enlisted an enthusiastic Product Owner, and now you are ready to rock.

As you get a couple of Sprints under your belt, you begin to realize some Project Management functions that were performed by a PM in the waterfall world may still be needed. What are they and who performs them now that you’re Agile?

  • Financial Reporting: How much will this feature set cost?
  • Risk Management: Who tracks risks and issues?
  • Documentation: Do we still need documentation and if so, who writes it?

Here at GSD Mindset, we have some practical ideas on how to approach this.

Financial Reporting

There are very few organizations that give you a pile of money and tell you to go have fun. Today, most companies want an accounting of how funds have been allocated. In the waterfall world, Project Managers report out the status of the monthly budget, using techniques like Earned Value to calculate where you are in relation to money spent.

Now that you’re Agile, good Project Management dictates that you still need to keep a financial accounting. In fact, many companies require careful accounting as a legal requirement. It’s not so hard to track and forecast expenses when you transition to Scrum.

After a few Sprints, you use Velocity to determine how many Story Points you can complete in a Sprint. If you know your monthly team budget, you can also calculate the average cost per Story Point. Multiply that cost to the estimated Story Points for the remaining Stories in your backlog for each Feature or Epic and now you have a rough idea of the amount of funding required to complete the remainder of the project.

Keeping on top of the financials will go a long way toward keeping management happy.

Who should track financials? Since calculating cost is similar to calculating Velocity, we believe this is a task best performed by the Scrum Master.

Risk Management

With Scrum, you should have less risk, because you deliver more frequently to customers, but that does not mean you can quit tracking and analyzing risk when you transition to Scrum. There are many ways to identify and track risks now that you are Agile. I find MindTools article on Risk Analysis and Risk Management helpful. 

Risk analysis and assessment should be a team effort. The Scrum Master should lead the discussion during Sprint Planning and conduct a quick checkup at Standup half-way through the Sprint.

Check out our blog post Reduce Risk on a Scrum Team for more ideas.


Most software folks are loathe to create documentation. This goes for writing User Guides and Specs all the way down to including Comments in lines of code. Documentation is an important tool to help future users understand what it’s all about. Documentation is a necessary Evil for those of us who remain in a world where our projects are audited. Even in Scrum, we follow a process and our implementation of that process may be audited.

The level of documentation should be decided at the beginning of the project. There are many tools to help you decide and document the minimal amount of documentation your project should require. Many companies today have Project Management Offices (PMOs), and they provide either written guidance or a tool for capturing this list. The final list of necessary documentation should be a part of your Definition of Done.

Once you’ve determined what needs to be written, you need to figure out who’s going to write it. Writing documentation is the responsibility of the entire team. The task to write or update documents should be included as part of the the Story. Because Stories are small changes to functionality, the level of documentation for each Story will be small compared to the size of documents completed at the end of large waterfall projects.

Hopefully, these ideas will help you figure out how best to tackle other traditional project management tasks that may be missing from your Scrum Team practices. Remember, it’s all about teamwork, team empowerment, and team accountability, so figure this out together as a team.

For more advice on how to transition more traditional project management roles, I recommend our blog post Agile Teams Still Need Traditional Support.



Gerri Slama Grove

Gerri Slama Grove


Gerri Slama Grove

read more

Don’t Hate Me Because I’m Agile

Why Do Traditional Project Managers Hate Agile?

I recently hired into a project management group of mostly traditional lifecycle project managers. The group has a directive to transition the team to become agile. That’s why I’m here.

I’m also here to apply agile to the Phase III of a problem project, where Phase I and Phase II were mismanaged and the application is unstable. So much for traditional project management methods.

In the first month since I started: I setup JIRA, formally kicked off the project with the Steering Committee (we can still be agile in a waterfall world), provided 2 half day workshops for my business product owner and business team members, planned feature deliverables for six Epics over the next three quarters, planned and executed my first sprint. We are not in “Exploring,” we are in “Doing.”

I attend all the project manager team meetings. I participate in discussion. I even offered to train or coach any project manager interested in becoming more agile.

Last week, my boss tells me that another project manager needs help with an agile project, and he asked me if I’d be open to coaching him. Of course! Next day, my boss sends out an email giving him the green light to reach out. Nothing. A few days later, my boss asks me if that project manager contacted me, and I had to admit that I had not heard from him.

This morning, I’m sitting at my desk and another project manager comes up to me and says, “Yesterday, I was sitting at my desk and I was surprised to hear you talk dirty.” I smiled and asked him to explain. His reply saddened me and inspired me to write this post: “You know, I heard words like agile and scrum in your conversation.”


I get it. Everyone’s a little scared of change. People ignore or belittle things they don’t understand.

I get it. Agile is not only a new method of application development, it’s a new way of thinking.

But, as technical professionals, we must learn new things all the time to remain relevant in our jobs.

What makes learning and adopting agile different from everything else?

I don’t have one best answer, but my observations lead me to believe that if you really want your team to become more agile:

  • The desire to change must come from upper management and it must be embraced throughout the organization.
  • Everyone must be trained. Get good training, even coaching. It’s worth the money.
  • Rip off the bandaid and do it right. If you want to practice scrum, practice scrum. Every aspect. Don’t hybrid a method unless you’ve mastered it.
  • Start small, with teams that want to transition first. Find the early adopters. Use them as poster children for how amazing agile can be.
  • Integrate change management principles into the transition. I attended a webinar on this topic the other day, and it opened my eyes to new ideas about how to implement agile (topic for another blog post).

I can hear you thinking: That’s all fine and good, Cynthia, but what am I supposed to do? I’m just an individual contributor, the Scrum Master / Product Owner / Member of the Development Team.

I say: Walk your talk. Seek to understand. Lead by example.

  • Meet individually with those who resist and ask them how they feel about agile. Elicit honest feedback. Listen. Don’t judge or try to change their minds at this meeting. Afterwards, use that valuable feedback to figure out how to address concerns.
  • Ask those who are struggling if they’d like to observe you work with your scrum team.
  • Offer to coach those who have trouble shifting their mindset, writing stories, grooming stories and sprinting.
  • Help your team meet their sprint commitments, even if it means working outside your job description.
  • Deliver quality product to the customer more quickly than before, even if it means helping with testing.

Agile is a journey.

Retrospective ensures continuous improvement.
We can always make it better if we work together as a team.

Is that so different from anything else we do?

Don’t let negative experiences like the ones I describe sidetrack you.

Smile big and be the change you want to see in others.

I wrote this post to spark a discussion.
What are some techniques you employ to reduce resistance to adopting agile?

Cynthia Kahn

Cynthia Kahn  503.799.5500

read more

Agile Teams Still Need Traditional Support

Scrum is an Agile Development Method Not a Product Management Framework

When I talk about agile for business, I’m talking about the need for businesses to apply agile concepts, so they can better meet the needs of an ever-changing worldwide landscape. As you know, I dedicated an entire post to how Business Must Become Agile or Be Left Behind.

When I talk about an agile team, I’m talking about how development teams apply scrum in product or software development departments within a business. The biggest misconception about scrum is that when you convert to scrum, you no longer need traditional program or product management.

The role of program manager, product manager, project manager and scrum master are all very different. All four roles are important, but you don’t necessarily need four people to fulfill them. How many people you need to manage the development organization depends on the size of your business, the number of projects and/or products, and the skill set of the resources assigned.

The Need for Program and Product Management are still Required

That’s right folks:

  • Someone still needs to develop and manage the product and/or program roadmap
  • Someone still needs to decide what new products, product enhancements and/or projects the development team works on
  • Someone still needs to decide what milestones to track
  • Someone still needs to organize the workload and ensure the team delivers to committed milestones
  • Someone still needs to report status against milestones to upper management

This sounds a lot like traditional product and program management, you say? Well, that’s because scrum is a development methodology, not a program or product management methodology.

Don’t Mess with the Development Team

The practice of scrum and applying the agile mindset to software development is radically different from traditional software development. As part of transition planning, decide how the development team will work with and report to the rest of the organization. Then, once the team commits to scrum, rip off that bandaid and allow the team to truly become agile.

Program and Product Managers Guide the Development Team

Think of program and product managers as wrappers around scrum development teams. These managers guide the team’s high-level priorities and ensure they deliver according to the business roadmap.

I suggest splitting the project manager role between the program manager and the scrum master.  Program and product managers set the roadmap and report to upper management or the PMO. Scrum masters work with the development team to determine if delivering to the roadmap is possible, work with the Product Owner to ensure the right stories are brought into each sprint and work with the program manager to reports status against roadmap milestones. Most importantly, the scrum master helps the team remain agile and efficiently practice scrum.

Release Management Must Deliver More Often to the Customer

Scrum ensures a quality working product is demoed at the end of every sprint. Whether or not the updated product moves to production or releases to the customer is another process that is outside the boundaries of scrum. Remember that even if your team practices continuous integration with automated tests during sprint development, it does not mean regression testing, automated manual testing and user acceptance testing can be bypassed as part of the release cycle.

Because an updated product is available at the end of the sprint, we hope that management makes the commitment to release more often. Don’t wait. Big band delivery is the old way of thinking. Successful businesses consistently provide value to the customer, those folks that buy your products and provide the income that goes toward your paycheck.

Want to better understand how to successfully practice scrum in the real world?
Then you should read our GSD Scrum Handbook.

Want personalized instruction?
Then come to our next GSD Scrum Training or call us for a consultation.


Cynthia Kahn

Cynthia Kahn

Cynthia Kahn  503.799.5500

read more