The Agile Mindset is a Superpower

Why an Agile Mindset Helps Overcome Uncertainty

We all have favorite super heroes. We all hope to travel to brave new worlds, including outer space some day. But, in our wildest dreams, we never thought we’d be asked to “boldly go where no man has gone before” by staying home. 

I read and watch and listen to various authorities explain how my world is forever changed and my business must adapt or it may go bankrupt. Luckily, I have an agile mindset, so I know that I can meet these challenges and come out the other end with a successful agile business and brand. 

If you’re like me and you have an agile mindset, you have a distinct business advantage. Your brain is already wired to look for and take advantage of new opportunities. So, get up off that sofa, turn off the TV and take action!

Our agile mindset gives us laser focus, a desire for continuous learning and the ability to identify when we need to pivot to stay relevant and competitive. These three attributes form a superpower that helps us navigate through uncertainty and succeed.

Laser Focus

Every sprint is timeboxed, to ensure we remain focused on completing a specific set of accomplishments. In scrum, our sprints are usually two weeks. In times of uncertainty, we may only be able to plan for one week at a time. 

Our work and our business lives have now merged. We need to apply our laser focus holistically.

The key is to determine what needs to be accomplished now. No one really knows with any certainty what our lives will be like at the end of this quarter, let alone at the end of the year. Those quarterly and annual plans have become irrelevant. However, we all have work that needs to be completed by the end of this week. Apply that laser focus to your short-term goals. Take back control and move forward.

You cannot operate in a vacuum. Your customer’s businesses have changed. Talk to them. Make sure you are focusing on the right things. 

Continuous Learning

Continuous learning is the way we enhance the superpowers of our agile mindset. At the end of every sprint, even if your sprint is only 7 days, conduct a short retrospective. What worked? What didn’t? How can I improve the way I work in my business and with my family? 

By continuously monitoring what’s working and what’s not working, we learn from our interactions with others and we remain competitive. Keep in mind that what worked last week may not work in the upcoming week, so retrospective is more important now than ever before.

Ability to Pivot

Through retrospective and the art of continuous learning, we grow as human beings and business people. To fix what is not working, we may need to change our business model. For example, in-person training pivoted to online training. Restaurant dining pivoted to take out and delivery. What needs to change in your business?

Our customer’s problems are different now. In fact, they may be changing week by week, just like yours do. Listen closely to what your customers are telling you. What problems can you help them solve? Customer feedback may be telling you that you need to alter your product offering or your messaging or both. 

I’m even reaching out to potential customers who I don’t know, expanding my reach and understanding beyond my current customer base. More of us are working from home and feeling isolated. There’s never been a better time to reach out and connect.

If you haven’t already pivoted your product offering and messaging, you’re late to the game. Stop selling and start listening. Adapt and pivot and remain competitive.

Do you have any advice to share about how your business is coping? We’d love to hear from you.

Cynthia Kahn

Cynthia Kahn


Cynthia Kahn

read more

Part 2: Does Perfect Scrum Practice Make Perfect?

3 Reasons Why My Perfect Scrum Teams cannot Make Perfect

Wow! It’s been 9 months since I’ve written a blog post. A lot has happened since I wrote Part 1: Sometimes Change is Really, Really Hard. I’m still at the same client, finishing up a year of agile consulting. Let me fill you in on what’s been happening there.

Before I get started, I’m excited to tell you about what else has been happening since my last post. Last November, I gave a TEDx talk that explains how to Apply Agile Practices in your Life and be Happier. I share my backstory and describe how agile transformed not only my business life but my personal life too.

That TEDx talk was so well received that immediately afterwards, Gerri and I started to develop a 12-week guided workshop that can help anyone achieve their goals through applying agile principles. If you’re interested in learning more about our upcoming FREE goal setting workshop, contact us and we’ll put you on our brand new email list.

Now, back to my agile consulting client.

Part 1 Challenge Update

When I wrote Part 1, my biggest client challenges were:

  • Teams organized without a permanent Product Owner.
  • Project Management Office (PMO) tracking methods at odds with agile methods
  • Poor Release Management practices.

In the last 9 months, I’ve made good progress in these areas.

I was able to influence team organization through my relationship with the PMO. I helped management see the confusion caused by conflicting priorities when Product Owners are assigned to projects and not teams. I’m happy to say that now my scrum teams have a permanent Product Owner to prioritize project requests coming into the team from across the globe.

I locally fixed the tracking methods issue. The PMO still sizes and monitors progress in Dev Days, but now all the scrum teams at our local office have switched to relative story size techniques. After all the stories are sized, I roll up the story points and calculate Dev Days for the PMO. My teams receive the benefits of relative sizing and the PMO gets what it needs for management reports. Win-Win.

Release management is outside my local sphere of influence. Although I could not change the poor release management practices, I report time lost due to these issues in every sprint status report. This way, I quantify the impact to upper management every 2 weeks. Hopefully, someday upper management will see the light.

Perfect Scrum Practice Doesn’t Fix Everything?

Now, we practice scrum the best way possible. We plan Projects, we write Stories, we groom Stories, we plan Sprints, we Standup, we Demo and we reflect through Retrospective. Then why, why, why are my teams not perfect? Because at the end of the day, we’re building software, and we must follow best software development practices too.

Top 3 Reasons Why My Teams Are Still Not Perfect

The top 3 software development practices that prevent my teams from realizing all the gains from perfect scrum practice:

  1. Skip analysis and design as part of Definition of Done (DoD).
  2. Minimal or no unit testing by developers before passing story to testers for verification.
  3. Maintain unstable Develop and Test (Pre-Production) environments.

In traditional waterfall software development, the entire project goes through a systems development lifecycle (SDLC). One phase in the cycle must be completed for all the requirements before continuing to the next phase.

With scrum and other agile frameworks, every story (or small set of requirements) should go through the same SDLC as an entire waterfall project. Agile does not equate to lack of design. In fact, design is even more important with agile projects, which are built story by story. Without a solid design, the team runs the risk of incrementally developing software that does not fit together correctly at the end. Poor design or lack of design also increases risk of technical debt.

When developers don’t take unit testing seriously, the quality of code passed to the testers for verification is low. The initial builds do not produce code that works the first time. Stories go back-and-forth between develop and test. Stories take longer to close. Maybe the team just likes the drama?

Shared test boxes are wholly maintained by the developers and testers instead of Operations. This causes a litany of issues for version control, upgrades and releases. Issues multiply when multiple changes deploy from multiple teams working on multiple projects in multiple countries. Environments break. Many hours, even days, are lost.

Introduce Changes in Software Practice at Retrospective

At every Retrospective, I recommend appropriate changes when problems are discussed that I believe stem from the lack of best software development practices. Every time. Even if crucial practices are not adopted, I continue to teach until my team is ready to learn.

Environment issues cannot directly be be fixed through internal team process improvements, However, Retrospective provides an excellent opportunity to discuss different ways to approach and work with management. Teams can have powerful influence when they manage up.

As consultants, we always hope we can bring our clients from darkness into the light.
I guess that’s not always possible, even with the best intentions. However, continue to make constructive suggestions and find ways to track then report the impact. Telling a consistent story ensures that when teams are ready, they will hear you and take action.

If you have any techniques that you’ve applied in your own practice that could help, please share,

Cynthia Kahn

Cynthia Kahn


Cynthia Kahn

read more

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

Why Your Team is Not Agile

Maybe Your Team is not Agile because They Don’t Know How to Be Agile

Many Scrum Masters feel frustrated when their team is not agile enough or they don’t practice scrum the “right way.” Probably every Scrum Master feels this way at some time in their career.

So, why is this happening?

We could list an infinite number of reasons for this, but if you look past the symptoms, we can group the team’s lack of commitment or poor performance to 3 root causes: 1) Inadequate training, 2) No consequences and 3) We forget that we are servant leaders.

Inadequate Training

Maybe the team doesn’t know how to be agile.

It never ceases to amaze me how many companies transition to agile without training everyone involved: management, the engineering staff and (oh yes) the business team members too. Agile methods are more than ceremony. To be agile, you must change the way you think. To truly transition, everyone involved must understand not only how to practice, but also the theory behind why the practice works.

Companies that train their staff may only train the Scrum Masters and maybe the engineering staff. I’ve never understood why management feels exempt from training too. If their entire staff is transitioning to a new approach to application development, won’t their approach to managing their staff need to change too? How can anyone manage and support what they do not truly understand?

One of the major benefits of scrum is Product Owner membership on the team. This precious customer representative influences timing and impacts quality. Their vision has direct impact on customer satisfaction. If the Product Owner is an integral part of the team’s ability to deliver, then why is it that the Product Owner rarely receives training before joining the team? How can we expect someone to write stories when they do not understand the concept and they haven’t been trained how to plan or how to write story requirements and acceptance criteria?

If your team does not know how to be agile, as the Scrum Master, remove this blocker by requesting training for those who need it.

No Consequences

What happens when the team misses their commitment?

Many scrum teams operate without a team contract. Agile is about self-managing teams. Self-management is an awesome responsibility. As the first step, the team needs to define how they want to work together. If the team skips this step, then there is no commitment to practice scrum and it’s no surprise that anarchy ensues.

The team contract should acknowledge mandatory attendance at ceremonies like Daily Standup, Story Grooming, Sprint Planning and Retrospective. The contract should also include expectations when a team member cannot attend. The team contract should be prominently displayed on wiki or SharePoint pages. Consistent disregard for aspects of the contract should be escalated to management by the Scrum Master in the same manner as any blocker to team success. For more information about team contracts, check out Chapter 1 of the GSD Scrum Handbook.

Many teams cannot seem to time box their sprints or meet their story commitments. This common problem has roots in many different aspects of practice. As Scrum Master, do not let these problems languish. Discuss them at Retrospective. Let the team identify the root cause and then let them decide how to change their behavior. At the beginning of every Retrospective, review practice changes from prior Retrospectives to see if the team has actually changed. Holding the team accountable for walking their talk is an important aspect that is often overlooked.

We Forget that We are Servant Leaders

Servant leaders are not task masters.

In the age of agile, many project managers have transitioned to Scrum Masters. In our past waterfall world, the project manager works with the team to create a work breakdown structure and then creates a plan with tasks that must be completed to complete the project.

In scrum, the Scrum Master must know scrum, but the Product Owner decides what the team works on and when the work is complete. The Development Team decides what they can commit to. Everyone decides how they want to work together. Then, the Scrum Master clears the path and removes roadblocks.

For many Scrum Masters, it’s hard to give up control. When your team is not agile enough, first look inward. Are you part of the problem? Scrum Theory prescribes 4 events: Sprint Planning, Daily Scrum (Standup), Sprint Review (and Demos) and Sprint Retrospective. If your team practices these events, they practice scrum.

Coach your team and arm them with knowledge about best practices, yet give them freedom to practice scrum in the way that works for them. If it’s not working, review at Retrospective and let them decide how to change.

Providing team training, allowing the team to define their own rules and consequences, and ensuring the team has freedom to practice within the boundaries of scrum are the recipe for self-managing teams that are most likely to meet their commitments.

Do you have any experiences that you’d like to share?

Cynthia Kahn

Cynthia Kahn


Cynthia Kahn 503.799.5500

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