Practical Agile over Ideological Agile

When is it OK for Practical Agile to Overrule The Scrum Guide?

In these fast-paced, often unpredictable times, should we change our approach to training and teach more practical agile methods, so our clients are better equipped to manage change? I’ve been reaching out to colleagues and competitors, discussing the state of agile training and consultation. Many of my colleagues still believe that certification in their favorite ideology is the best approach to training.

Certification Teaches Ideology

Certification trainers teach the rules and ideology of their method du jour, mainly The Scrum Guide, Disciplined Agile Toolkit, Scaled Agile Framework or favorite ICAgile topic. Each method has their own idea of what it means to practice agile. That implies there is no one right way to practice. I acknowledge that many students take certification classes to beef up their resume. With high unemployment rates, everyone wants their resume to stand out. 

Good certification trainers reach into their own on-the-job experience to explain how they’ve applied the principles to past projects. However, not all certification trainers have actually worked as scrum masters or product owners on an agile team. Their students learn enough ideology to pass an exam. The reality is that some students may return to work after passing their certification exam unprepared for the challenges ahead.

Practical Agile Increases Adoption of Agile Mindset

I love Scrum and the agile mindset. I am a practicing Certified Scrum Master (CSM) through the Scrum Alliance, I teach practical agile methods based on Scrum, and I spent the last year developing a program for individuals to apply practical agile methods to their personal lives. Our company, GSD Mindset, prides itself on teaching, coaching and practicing our practical agile approach called the GSD Scrum Method

World and business leaders must adopt an agile mindset or their organizations may not survive, given we live in a world with many unknowns. To increase adoption of the agile mindset and therefore increase our client’s chances to succeed, we should add a 13th Practical Agile Principle to the original 12 Agile Principles: Take a practical agile approach over our ideology as written.

Ways to Make Scrum Practical

Since we teach an extension of Scrum, I’ll use Scrum to illustrate my point. Many organizations adopt their own version of Scrum anyway. Sometimes those organizations see productivity and quality improvements, sometimes they don’t. Because we are agile influencers, it is our responsibility to guide the individuals who take our classes to apply a practical agile approach that actually works for their business.

For example, The Scrum Guide assumes you already have a prioritized Backlog. Many who practice Scrum don’t know how to organize and build one. Even though building your first Backlog is not in The Scrum Guide, our primary responsibility should be to provide our clients with tools to start focusing on the right things in a more productive way, and that starts with building a well-written Backlog:

  • How do you decide what to build?
  • How do you define the Minimum Viable Product?
  • How do you prioritize a Backlog? 

Even the authors of The Scrum Guide admit that Scrum is “Difficult to Master.” As coaches and trainers, after we train our clients how to build a Backlog, we need to help them correctly adapt the formal Events of Scrum to work in their unique situations:

  1. Plan without knowing all the answers.
  2. Meet Daily to keep focused on the right things.
  3. Review status and quality of work on a regular basis.
  4. Reflect on what’s working, brainstorm new ideas and learn how to recognize when to pivot. 

The key is to internalize the ideological principles and develop a practical agile approach that you can adapt to any situation.

Are you certified?
How have you changed your approach to agile?
Do share! 

Cynthia Kahn

Cynthia Kahn


Cynthia Kahn







Wanted – Guest Bloggers Passionate About Agile

read more

Help Your Team Overcome Past Scrum Failures

4 Ways to Overcome Past Scrum Failures

When it comes time to begin their Scrum journey, many teams come with baggage. I often hear, “We tried that, and it didn’t work.”  They may have “tried” Scrum before and “it didn’t work.” They may feel Scrum is yet another management fad.

Like unhappy families, team members may come from other teams that failed for different reasons. Here are some ideas a Scrum Master can use to help their new team overcome past Scrum failures. Through positive experience, help your team give Scrum another, successful try:

  1. Lead with empathy. Listen to your team. Learn what didn’t work before and what they most need now. Try to help them address the problem applying Scrum methods. You may have diagnosed different issues with a Scrum lens, but that can wait.
  2. Lean into exceptionalism. The things holding your team back aren’t unique, but who wants to be told that?  Accept and work into their excuses.  You can also build credibility by championing adjustments that use more common sense and are less rule focused.
  3. Celebrate transparency before results. High achieving individuals are accustomed to striving for the great report card.  Your job as Scrum Master is to decouple that dopamine hit from story points and attach it to the act of finding the baseline and ownership.
  4. Stick with basic principles. Scrum done well has any number of tools, and a Scrum Master should be aware of all of them.  With a new or resistant team, focus on the key few that suit your style.  For me, that is keeping Daily Standup short and effective, holding a regular Retrospective, and striving for predictable delivery.  Other things, even scrumly rituals like sizing, may fall away.  The team will discover them anew as they build trust.

I started working with one of my favorite Scrum teams six months ago. They were reluctant to try Scrum because it had been presented as an all or nothing scheme that would add overhead to existing business processes. Some had been burned by personal experience.

At our Director’s urging, they agreed to try Scrum but admonished me to keep it lightweight. Two weeks later, a reorganization placed them under new management, reducing higher level support for Scrum. The team was at a project phase with high scrutiny where work was driven by urgent issues.  The engineers were experts assigned to specific areas and rarely worked across those boundaries. It was an inauspicious time to demonstrate the value of Scrum. Luckily, the front-line manager decided to give it a try anyway.

I charged in with the religious zeal of a Certified Scrum Master confident of winning more converts. After three months, the team remained highly siloed. The Accept/Commit Ratio hovered around 50%. Overall velocity was stubbornly flat. I expected to see the experiment called off.

However, the team understood what they were up against.  They helped me coach them.  I learned about their challenges with deadlines and validation requirements, and about the mix of skills in the team (empathy). Their company-mandated ticket system was poorly adapted to Scrum. Rather than do data entry in another system, they found a way to make it work, and I built a manual dashboard (exceptionalism).  We focused on seeing and improving the trend in our improvised Scrum board through anecdotes of improved focus and collaboration (transparency).  I kept my promise to keep it lightweight and they readily bought into having regular Daily Standups and Retrospectives (basic principles).

Over time, they developed improvements in tracking on their homemade system and in Backlog Grooming. They found ways to share work fairly across projects.  They engaged their validation team and internal customers as a part of the Scrum process.

After more than a dozen Sprints, the team has hit a groove.  Their Accept/Commit Ratio approaches 90%, and they are developing a discipline to baseline and address their interrupt rate.  What’s more, they have maintained their Scrum practice while rapidly adjusting to working virtually in a coronavirus world.  They are now a team that says, “It works for us.”

Emily Hackett

Emily Hackett

Emily Hackett

Emily is a Technical Program Manager working with the Performance Architecture and Analysis team at Intel.  She has been a Scrum Master since 2016 and has also worked as a Release Train Engineer (RTE) in a Scaled Agile Framework (SAFe) organization and as a functional manager for a highly effective Scrum team. Opinions presented are her own.



Wanted – Guest Bloggers Passionate About Agile



read more

Don’t Let Setbacks Derail Your Agile Project

Take Advantage of these 3 Techniques to Get Your Agile Project Back on Track

We’re all learning new ways to live and work in a virtual world. Many have published articles and delivered webinars explaining how to use available web tools so everything functions more smoothly. These tools may make facilitating meetings and classroom training easier, but without changing your practices, they may not be enough to keep your agile on project schedule.

When my agile project needs some love and attention, I have successfully used these 3 techniques to get back on track:

  1. Add optional 15 minute meeting after Daily Standup
  2. Take advantage of Retrospective 
  3. Rethink Velocity

Add Optional 15 Minute Meeting After Daily Standup

I’ve always tried to stick to the 10 minute max Daily Standup rule. In fact, I often tell my teams that “Daily Standup is the best 10 minutes of your day.” Why? Because that’s the only time each day when everyone is together in 1 place. 

Daily Standup is the best time for the Product Owner and Scrum Master to ensure everyone is focusing on the right stuff. It’s also the best time for the Development Team to gain clarification and resolution to open issues and burning questions.

If the team has issues that cannot be resolved in the 10 minute time box, Scrum implies that plans should be made to continue the discussion at some other point in the day. With virtual teams, it’s easier to get distracted. So, at the next Daily Standup, we often hear that those involved did not meet and the affected Stories have not progressed. As this happens with more and more Stories in the Sprint Backlog, the Sprint (and therefore project schedule) may get derailed.

We all have a tendency to work on the easy stuff and ignore the tough stuff when we’re isolated at home. When I work with virtual teams, I often add an optional 15 minute meeting after Daily Standup, so the Scrum Master and Product Owner can ensure the necessary conversations take place with the Development Team. 

By creating a separate meeting, you don’t disrespect the intent of Daily Standup. By making the meeting optional, you limit attendance to only required team members. 

The caveat: Just because you schedule the meeting doesn’t mean you must use the time every day. Only take advantage of the time box when the team really has an issue to discuss. The additional meeting is NOT an excuse to extend standup to 25 minutes.

Take Advantage of Retrospective

Relationships change when teams become virtual, because we communicate differently. Conversations happen less frequently, and most of those conversations are messages rather than video or phone calls. It’s easier to ignore each other when uncomfortable issues arise. 

Retrospective is the best time to talk about what’s working, what’s not working and to brainstorm better ways to work together. At the end of every Sprint, use Retrospective time to openly and honestly reflect on what’s affecting team productivity. 

If your team does not conduct Retrospective at the end of every Sprint, reinstate the practice now. Address small issues before they become big ones and further derail your agile project.

Rethink Velocity

New virtual teams must overcome many obstacles. In addition to the issues I’ve already discussed, your team may be faced with network issues, VPN issues, access issues, environment issues and problems with new tools. It’s naive to think that Velocity won’t be affected.

It’s been a few Sprints since we all became virtual, so you probably can see a new normal Velocity emerging. If this new Velocity is significantly lower than before, you need to reset expectations with your management and other stakeholders.

Recalculate estimated time to completion and project status. Help your organization understand exactly where your project stands in relation to where you’re supposed to be. That way, you can negotiate more realistic timelines. Maybe reducing scope or redefining the MVP could be the answer, so your customers can still get what they need.

The Key is Communication

To remain a productive team, open and honest and constructive communication between members is required. Address important issues as soon as possible. Extend Daily Standup for those who need additional help with requirements and technology. Take advantage of Retrospective and find creative ways to work together. If Velocity is affected, reset expectations and scope right away.

What agile techniques is your team using to remain happy and productive?

Cynthia Kahn

Cynthia Kahn


Cynthia Kahn

read more

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