Overcome Resistance to Agile in Your Organization

A Simple Approach to Overcome Resistance to Agile

The biggest obstacle to successfully transition to agile is resistance to change. People resist change for many reasons, including fear of the unknown and job insecurity. If you are a proponent of agile development, then you need to overcome fear and uncertainty in order to get buy in.

If the desire to become agile begins at the highest levels of the organization, it’s the software development team that must become agile, so that team holds the key. If the desire to become agile begins with development team, management must agree to this new approach. Top to bottom, all levels of the organization must embrace the agile mindset.

How can you overcome fear and uncertainty? Make it easy for everyone to get on board.

  1. Explain how agile fits into the existing structure
  2. Start with 1 team
  3. Educate everyone involved
  4. Commit to working out the kinks
  5. Prove that agile works better

Before you suggest that even 1 team convert to agile, make you truly understand agile and the agile mindset. Get trained on agile scrum. Then test the water by asking your manager to pay for your training as part of your professional development. We recommend you read our post How to Get Your Boss to Pay for Scrum Training.  If your manager won’t pay for it, pay for it yourself. Show your commitment to the cause.

1. Explain How Agile Fits Into the Existing Structure

This seems like a no-brainer, but you’d be surprised to learn most companies that transition to agile do not even think about how agile fits into current business processes. If you want to alleviate fear and uncertainty, figure out:

  • How the new team’s roles and responsibilities map to existing roles and responsibilities.
  • How agile teams plan with and work with traditional teams.
  • How will status reporting occur? The agile teams must be able to report progress in much the same way traditional teams do.
  • How agile teams fit into the existing project management or product development structure.

Put together a proposal. Show that you are prepared and serious about taking action.

2. Start with 1 Team

Agile scrum is a software development method. Only the development team really needs to change. We suggest starting the transition with only one team. This lowers the risk to the organization, gives everyone a chance to get used to the idea, and also gives you a higher chance of success.

But, you must start with the right team. In addition to the Scrum Master, we believe you need a Product Owner, Business Analyst, Tech Lead or Architect, Developers and Quality Assurance.

You need a committed Product Owner, not an Executive Sponsor. Make sure that person is respected by the product team, understands the requirements and can prioritize the work. The Product Owner must be available to attend daily Standup, Story Writing and Grooming, Sprint Planning and Retrospective. That’s a much bigger commitment than that of Executive Sponsor, who periodically attends Steering Committee meetings.

The reason that you need a Business Analyst is because the Product Owner may not understand how to translate business requirements into stories and acceptance criteria. Business Analysts are well suited to team up with the new Product Owner and help out.

The transition to agile does not mean architectural design is no longer needed. Quite the opposite is true. Because the team is delivering functioning application code at a much faster rate, the role of Tech Lead or Architect is critical to team success. The team needs someone who understands the big picture, can build a development framework and ensure all the small pieces of functionality fit together at the end.

Choose the right developers. Yes, make sure you have all the skills to code all aspects of the application on the team. However, don’t pick developers who don’t want to switch. Just like with the Product Owner, pick developers excited to learn something new and who are willing to attend the required meetings: Story Grooming, Sprint Planning, Standup and Retrospective.  

Finally, scrum dictates that you cannot close a story until the acceptance criteria has been validated working as expected by Quality Assurance. Make sure that you have the right number and mix of testers.  

3. Educate Everyone Involved

Now that you have the right team, you need to train them. To minimize risk and to validate management commitment, get everyone on the team the proper training. The team must start with a good understanding of scrum and an agile mindset.

If you cannot get management to provide adequate training for your team, do not attempt the transition. Seriously, don’t even start. Agile scrum is way too different from traditional software development. You at least need enough management commitment to ensure everyone on the team starts with the tools needed to succeed.

To get even more buy in, ask management to attend the training. They more they know about scrum, the less uncertainty they feel about the transition.

If you can hire a coach, even better!

4. Commit to Working Out the Kinks

As they say, “Rome wasn’t built in a day.” The same is true for the transition to scrum. It’s a big change. Before you begin, get assurance from management that you have at least 6 months to get the team fully functioning.

Let’s be clear: We do NOT advocate a slow or partial transition.

What you need to do: Rip off that bandaid and practice every aspect of scrum from Day 1.

Because you are switching cold turkey, you need time to get in the groove. We know. Planning, building a backlog and sprinting are new processes. The team may be a bit awkward in the beginning.

Keep up all scrum practices. Don’t skip a step.

Use Retrospective to improve the way you work together.

5. Prove that Agile Works Better

There is no better way to prove that scrum is better than when the team delivers higher quality products to your customers in a much faster timeframe than before the transition. Agile provides you the opportunity to show off your excellent work at the end of every sprint. So, demo often to your customers. If the customer wants or needs a change, pivot.

Practice scrum, meet your team commitments and deliver high-quality products to your customer.

Walk your talk.

That’s how you prove agile works better.

GSD Scrum Training

Do you need some help with your agile transition?
Then come to our next GSD Scrum Training or call us for a consultation.


Cynthia Kahn

Cynthia Kahn

Cynthia Kahn
CynthiaK@gsd.guru  503.799.5500

read more

Transition from Project Manager to Scrum Master

3 Steps to Become a Scrum Master

Agile and scrum are trending topics. Here you are, a successful project manager, and you want to learn more about scrum. You may even want to become a scrum master. The career transition from project manager to scrum master may seem simple, but it’s not as straightforward as you may think.

Scrum master has a very different role from that of project manager. The agile mindset is a paradigm shift from that of project manager too. To gain a better understanding of just how different, I recommend you read my earlier post: The Difference Between Scrum Master and Project Manager.

When readers contact me and ask me to advise them on how to best transition, I suggest the following:

  1. Learn about scrum from the Scrum Alliance
  2. Study and become a Certified Scrum Master (CSM)
  3. Get a job on an agile team

1. Learn about Scrum from the Scrum Alliance

Many of us organically became project managers through the course of our careers. We learned how to manage projects by working on projects and, eventually, we were promoted to leading projects ourselves. I personally never took a course on project management until the marketplace demanded that project managers have PMP certification.

However, scrum is a specific agile framework that is drastically different from the way you are used to managing traditional projects. If you want to be a scrum master, you need to read about it and study the concepts until they become an integral part of how you think about organizing projects.

The Scrum Alliance is a well-recognized authority on framework. Lucky for us, the Scrum Alliance has a wonderful website with lots of fabulous information.

Start here: https://www.scrumalliance.org/why-scrum

Reading about scrum is a great start, but I recommend you also learn about scrum from someone who already is a scrum master. If your company is transitioning to scrum, you may have the opportunity to learn from an agile coach. Take every advantage of that precious resource. If you are pursuing agile on your own, take a class. Ask for recommendations from friends and colleagues. Classroom learning combined with live exercises help reinforce the agile concepts you’ve been reading about.

2. Study and Become a Certified Scrum Master (CSM)

Just like with traditional project management where you need to become a certified PMP, if you want to be taken seriously, you need to become a CSM. Lucky for us, the CSM exam is straight-forward and much easier than the PMP exam. So, there is no reason not to get certified.

Start here: https://www.scrumalliance.org/certifications/practitioners/certified-scrummaster-csm

3. Get a Job on an Agile Team

If your company is not transitioning to agile, you will have to look outside your company for your first scrum master position. You may ask yourself: How can I get a job as a scrum master if I have no scrum master experience?

You may be able to land a scrum master gig based on your mad interview skills and CSM alone. Then again, you may not. If you are serious about becoming a scrum master, you may need to start as a different member of an agile team.

Depending on your background and what jobs you performed before you became a project manager, you may have a better chance at landing a Product Owner or Business Analyst or Tech Lead gig. Take a serious look at your career history and refactor several versions of your resume.

Take your agile friends and colleagues to coffee. Ask them what companies look for in agile applicants, before you apply anywhere. Then, apply for all agile positions you qualify for. The more you interview, the better you get at answering questions.

Land that first agile gig, whatever it is, and learn how it’s done in the real world.

Then, after that first project is finished, change teams or change jobs. Agile is practiced differently in different organizations, self-organizing teams and all. So, to be the best scrum master you can be, get a broader perspective.

Never stop learning.

Expand your mind.

Change your life.

Cynthia Kahn

Cynthia Kahn

Cynthia Kahn
CynthiaK@gsd.guru  503.799.5500


Contact Us read more

5 Steps to Implement Agile

How to Plan for Successful Transition to Agile

We are constantly amazed at how many companies attempt to implement agile methods without adequately preparing for the transition. Just like with any major project or corporate restructuring, the transition to agile is pervasive. It’s a method and mindset change that affects the entire organization, not just the development team.

If your company has had trouble implementing agile, I’ll bet your company has not adequately planned and prepared for the transition.

We’ve identified 5 steps to a successful agile transition:

  1. Educate
  2. Budget
  3. Plan
  4. Start
  5. Revise

Step 1 – Educate

This first step seems obvious, but you’d be surprised at how many managers say they want to be agile when they have no idea what that means. Before you decide to go agile, educate yourself on the topic.

How can you budget and plan for something that you do not understand?

  • Read a book. Have someone you trust recommend one to you. If you want to transition to scrum, we offer a free GSD Scrum Handbook on our website. Ask us to send you a copy.
  • Take a class. There are many live and online courses available.
  • Interview professional agile coaches or consultants to get a feel for what the transition is going to be like. Talk to at least 3 consultants; approach and cost can vary widely.

Step 2 – Budget

As you learn more about agile, you start to form an idea about what your development organization would be like if you transitioned to agile, the benefits of agile, and how you can start the agile journey. Those benefits can then be assigned dollar amounts, and you can set meaningful goals and objectives for the transition project. Now you are ready to put together a meaningful proposal and ask for budget dollars.

The budget you receive for the transition heavily influences the rollout plan options available to you.

Step 3 – Plan

Most companies do not receive a budget large enough to convert the entire organization all at once. So, during the transition, some teams will be agile and some teams won’t.

Agile teams must be able to plan for and complete their development work without relying on another team, which may not have transitioned to agile or may not be on the same sprint cadence. Think about this concept of self-organizing and independence as you form your teams. Your current team structure may not currently be optimal for the transition to agile. You may need to reorganize around capabilities or software platforms before you develop your transition plan.

After you organize for success, you need to figure out:

What teams will be first movers in the first wave of the transition?
How will teams be organized?
Who will transition to what agile roles?
Timing of training and coaching?
How many waves?
How long between waves?
How long until everyone becomes agile?

Most importantly: How will your organization or PMO operate with some teams developing using agile and some teams still developing using traditional methods?

To achieve your goals and successfully transition your entire software development organization to agile, you have to visualize how this transition can be implemented for the greatest chance of success and adequately plan for it, given your budget constraints.

Step 4 – Start

When it’s time to transition first mover teams, we strongly advocate ripping off the bandaid and transitioning the selected teams to be 100% agile.

Let us be clear: We do not advocate scrummerfall or starting out by implementing any mix of agile and waterfall on any team or any part of the organization. You most likely will never become truly agile if you attempt to transition the organization in this way.  

The top reason why organizations don’t successfully implement agile is because the teams are not adequately trained. Step1 applies to every person on every team and every person who works with those agile teams.

Fear of the unknown and misunderstanding are the biggest contributors to failure on any project. Send everyone to classes that explain agile processes and concepts. Hire a good coach. Agile is a big paradigm shift from traditional methods. Give your teams the knowledge and confidence they need to succeed.

If you answered all the questions in Step 3, you identified the roles required for each team and you identified the right person to fill each role. Start out with complete teams. We cannot stress the importance of filling all the team roles and training the team members about their roles and responsibilities.

After training, immediately transition to agile. The team can no longer be allowed to operate in a traditional manner. This is why a coach is helpful, to reinforce the training and keep the team on track. Do not let the team flounder or get lost in analysis paralysis.

Step 5 – Revise

As you move through the first wave of transition, you become an educated and experienced agile manager. You recognize things you would do differently. So, change your approach and do the next wave differently.

The idea of Retrospective should permeate your organization. At the end of each wave, seek ways to improve and improve the performance of your entire project.

Learn agile.
Think agile.
Be agile.

Cynthia Kahn

Cynthia Kahn

Cynthia Kahn
CynthiaK@gsd.guru  503.799.5500

Contact Us


read more

No Management Buy In For Agile? Then Earn It!

Getting Leadership to Buy Into Agile

I’m sure you’ve heard people say, “We tried agile scrum and it didn’t work.” This is mostly from their first-hand experiences of trying agile and failing or hearing others share their horror stories and they are terrified to try it themselves. Whenever I hear these words, I think to myself, “I bet they didn’t implement scrum correctly.”

Why Scrum Fails

In my experience, the misuse of scrum methods leads to management’s resistance to agile scrum. It all boils down to the fact that scrum fails when the Development Team operates independent of any corporate objectives and strategic milestones.

When Development Teams operate without strategic direction, agile becomes the team’s excuse to work on whatever they feel like working on. I’m amazed when I asked why teams function this way and I hear, “We are agile, we will figure it out as we go.”

I have seen developers build whatever they want whenever they want without: a scrum team, prioritized backlog, and groomed stories and time boxed development cycles or sprints. This way of functioning is known as cowboy coding. With cowboy coding, the developers get to work on fun stuff, challenging stuff, easy stuff, whatever, without any consideration or coordination with the business. Remember, true agile works hand-in-hand with the business.

Even in cases where there are Development Teams using true scrum best practices, I have seen teams still not take into consideration corporate milestones. When key business areas have dependencies on deliverables beyond the time box of the sprint, say 3 months down the road, I have heard the Development Team respond with, “We do not plan that far ahead; we only plan 2 weeks in advance.”

No wonder leaders can be very cynical about agile scrum!

Steps to Leadership Buy In

If you plan to transition to agile and you do not plan to accomplish the 4 steps outlined below, your efforts can result in another horror story.

The 4 Steps to Scrum Success:

  1. Ensure management and the Development Team have proper agile scrum training
  2. Define project milestones for proper project tracking
  3. Develop as an agile team
  4. Status report progress on regular basis

Leadership must understand agile scrum teams are functioning in accordance with standard practices. For this to happen, we recommend management attend high-level agile scrum training, so they understand how they may have to change their management style and expectations. In addition, every member on the scrum team should go through formal training to ensure everyone is on the same page as to how to operate as a fully functional agile team.

Once the leadership and the agile scrum team are formally trained, a coach should be brought in not only to guide the team through training, but to support and build the right behavior through the execution of their first 3 sprints.

Remember that agile is more than a process. It’s a mindset shift. That’s why we believe training and coaching after training are so important.

Leadership needs to feel confident that the team can deliver to business objectives and corporate milestones. “Figuring it out as you go” and “It will be done when it’s done” are not agile. They are excuses for not wanting to be accountable.

We have a way to guide Development Teams through the process of breaking down high level requirements and creating a release plan that lines up with the strategic roadmap. In Chapter 2 of the GSD Scrum Handbook, we talk about The GSD Gold Approach to Project Planning in detail. This can help you demonstrate to your leadership how agile scrum can and does support corporate objectives.

Every Development Team has a Product Owner that works hand-in-hand with the business. The Product Owner represents the business, captures requirements in the form of stories (or product functionality), prioritizes those stories into the backlog and then guides the team on what to work on each sprint. It is the Product Owner’s responsibility to ensure backlog items are reflecting the organization’s strategic roadmap from a functionality and timing perspective.

Another point of contention with leadership is visibility into how their Development Teams are tracking to completing their committed work. Throughout the sprint, Story Boards and Burndown charts provide visibility and traceability throughout the sprint cycles. Both of these tools should be available to all members of an organization at all times either in a tool or on a whiteboard. We talk about this in Chapter 6 of the GSD Scrum Handbook.

The agile Development Team must also be able to report project progress beyond the limits of the sprint. In Chapter 10 of the GSD Scrum Handbook, we explain how to accomplish this.

Once leadership has visibility through regular status reports and sprint transparency, they will begin to have confidence the Development Teams can deliver against their strategic roadmaps. Delivery to corporate objectives proves scrum works efficiently and effectively.

If you have any suggestions or comments from your own personal experiences, please post them below.

Want more details about how scrum can work for your organization?
We recommend you get your own copy of the GSD Scrum Handbook.

DSC_4880 (500x483)

April Shepherd

April Shepherd
AprilS@gsd.guru  503.307.9072

Contact Us read more

Transition Your Team from Waterfall to Agile Scrum

My First Agile Scrum Project

The first question traditional waterfall development managers ask when they are looking to transition to agile scrum is, “How do I make this happen?” I’m going to share my first transition from waterfall to agile scrum five years ago and, hopefully, this will help you with yours.


I was a traditional waterfall project manager at a Fortune 500 international company. My team consisted of 2 developers, 2 quality engineers and 1 tech lead. The overall scope of the project was to procure and build the infrastructure from the ground up then to develop the following functionality: Email, Push, In-App and SMS.

Waterfall is OK for Architecture Buildout

We managed the procurement and buildout of the supporting architecture using the traditional waterfall approach, because there were simply too many dependencies on technologies and non-dedicated team members needing to do work outside of what would be an agile scrum team. We referred to this buildout period as Sprint Zero.

Begin the Transition from Waterfall to Agile

Sprint Zero

I obtained my Certified Scrum Master (CSM) certification and our team engaged an onsite scrum coach (similar to the services we offer at GSD) to train our entire team. Everyone on the team attended the training, including our new Product Owner.

Topics we learned included:

  • Defining Epics
  • Defining Sprint cycle
  • Story Writing
  • Backlog grooming
  • Estimating and assigning story points
  • Sprint Planning     
  • Daily Standups
  • Product Demos
  • Retrospectives
  • Reporting sprint velocity
  • Setting up and configuring tracking tool (JIRA)

Training sessions were spread over a few weeks to minimize disruption to the team and to allow them to complete their infrastructure buildout tasks. As a new scrum master, I worked closely with the team to ensure we were all aligned on how to implement agile scrum and how to be successful.  

Sprints 1 to 3

We decided to start with 2 week sprints as our coach advised this is optimum for most development teams. We have found 2 weeks to be the magic number with all our agile scrum teams. We also found this was a good amount  to analyze, develop, test, and document potentially deployable packages of code.

To ease the transition, our scrum coach attended all of our Story Writing, Backlog Grooming, Sprint Planning, Product Demo and Retrospective sessions during our first 3 sprints. Our scrum coach would be a silent observer in these sessions, but would interject if the team went off track or had questions about scrum.

This support gave our team, including our new Product Owner, confidence that we could fully function and deliver as a new agile scrum team. We wanted to demonstrate that we could quickly develop deployable code and show tangible work progress in a short amount of time. This was great because the team realized quick wins by demonstrating functional pieces of code. The Product Owner and stakeholders were getting continual feedback on the team’s progress. It was a win for everyone!

Operating Agile

I found the experience so amazing I knew I wanted to be an Agile coach. If we didn’t have ours, I don’t think we could have done it alone. The coach was crucial not only to training, but providing support to ensure we were embracing our new agile mindset and not falling back into waterfall processes. It also gave our stakeholders confidence we were working with an expert who could guide our team to success.

Let me know if you have any questions or need help with your transition to agile scrum.

DSC_4880 (500x483)

April Shepherd

April Shepherd
AprilS@gsd.guru  503.307.9072

Contact Us read more