Scope Creep. It’s What’s for Dinner.

Once upon a time there was a whiny Product Owner, two Team Leads, a Dev Director, an executive, and only 2 days to go in the sprint.

Enter the unplanned feature. The villainous Scope Creep we all know and hate.

But he pays our bills so we stay here late at night. And take it like a champ.

Can you guess what happens?

Watch more Prevent Agile Pandamonium videos like this

Posted in Agile Management, Agile Project Management, Agile Teams, Scrum Software | Leave a comment

Make It So… If Only Software Project Management Were That Simple

What if you could successfully execute your software projects like Captain Jean-Luc Picard of the Starship Enterprise just by commanding, “Make it so?”

What if you could successfully execute your software projects like Captain Jean-Luc Picard of the Starship Enterprise just by commanding, “Make it so?”

Sounds silly, doesn’t it? Yet many traditional command-and-control organizations think they can work this way.

Manager types go behind closed doors and through a series of many meetings come forth with “The Plan.”  The plan directs what is to be done, how it is to done, when it is to be done, and by whom it will be done.  The software developers who must implement the plan are informed of the plan and directed to “Make It So.

Almost immediately it seems a question will be raised with the realization of, “oops, that was not considered…  it is not in the plan.”

But, the Project Manager’s job is to create and then deliver based on “The Plan.”  They will be evaluated based on that ability.  Their performance and success is measured by variances to the plan and they report these variances every month to their superiors.  As is typical with human behavior, it does not take long for a savvy Project Manager to realize that, “hey, if I want to keep my job, or better yet, get a good raise or promotion, I better not have variances.”  Variances to a plan are bad.  So the project management function seeks to control and, thus, essentially prevent change.  Change becomes a threat to success of the plan.

So, you must follow “The Plan” and stay on schedule and on budget – deliver the hours and the planned activity and events. 

But, the Customer wants everything they asked for, so you must deliver all content as well.  No, they cannot add anything that will change the plan. 

If the developers cannot stay on task as defined, they simply must work harder and longer because “The Plan” must be good.  Then they must explain in detail why they could not accomplish what they were told to do within their budgeted hours.  Just Make It So.

Waterfall project management wants fixed schedule, budget, and content.  Actually what they really want is that big raise for demonstrating how great their plan was and how well they controlled the project through the plan.

If this project is actually well understood up front and what’s to be accomplished is pretty stable, then this approach may actually work.  Project managers are smart people too, and they can effectively apply experience and judgment to make good plans under the right conditions.  Some industry is very heavily regulated and only a very precise and specific requirement is acceptable.  This approach can work well and, if it does for you, then great…. Make It So

But, what if the software product must evolve to changing conditions and needs?  Today’s rapidly advancing technology means end-users are increasingly fickle about what they want.  Many agile software project management products now are being provided to model business processes and interactions, either for internal or external customers.  These processes are under pressure to constantly change and improve meaning that the supporting software must also change.  Companies cannot maintain a competitive edge unless they change and evolve rapidly.  Software projects must be prepared to do the same.  Does it really make sense to tell your customer they cannot have the thing they discovered they really need now because it was not in your plan you made months ago?

Like science fiction, plans rarely mirror actual reality.  Trying to fix schedule, budget, and content is a real challenge for a number of software projects in organizations today.  In reality, one of these parameters must be allowed to flex.  End-user software is very hard to define up front.  Users often do not know what they want, and even when they think they do, they quickly evolve to need something else.  Plans must be able to adapt and yet still provide the business with the insight that it needs to manage teams effectively.

This “Make It So” approach must evolve and, with it, the behaviors of project management and the measurements of project/plan success.  Even really good project managers cannot control the future.

Maybe it is time to “boldly go” and explore a new “agile software development” approach – one that provides immediate visibility into the health and status of the project real-time, and readily allows for a changing parameter (content, schedule or budget) to be understood immediately. 

What do you think?


Posted in Agile Adoption, Agile Benefits | 3 Comments

Self-Assessing How Agile You Are

A guest post from Ben Linders’ blog: Sharing My Experience. Ben is a Quality, Agile, Lean & Process Improvement expert, co-author of Getting Value out of Agile Retrospectives, and editor @InfoQ.

Do your teams want to know how agile they are? And what could be the possible next steps for them to become more agile and lean? In an open space session about Agile Self-Assessments organized by nlScrum we discussed why self-assessments matter and how teams can self-assess their agility to become better in what they do.

Becoming Agile over Doing Agile

There are many checklists and tools for agile self-assessments. Some of them focus on “hard” things agile practices, meetings and roles, while other cover the “soft” aspects like an agile mindset and values, culture, and the conditions for agile adoption in organizations to be successful.

We discussed about self-assessing the teams agility at the nlScrum open space. One conclusion was that most attendants had a strong preference for assessing based upon agile values and mindset to explore if and how their teams are becoming agile. This way of assessing distinct teams where professionals have really internalized what agile is and know why they should do it and how it helps them to deliver value to their customers and stakeholders from teams who are only doing agile or Scrum because they have been told to do so by their managers or organization.

Assessing values and mindset involves asking why certain agile practices and rituals are done. It empowers the agile team by developing a shared understanding of the weaknesses and strengths of their way of working and to decide which steps they will take to become better.

Effective agile teams understand the agile culture, mindset and values. That makes it possible for them to improve their development processes in an agile way. They can use the golden rules for agile process improvement to improve by continuously doing small but valuable improvement actions.

Can teams assess themselves?

As the name suggests, agile self-assessments are intended to be tools for agile teams. The result of an assessment helps a team to know how they are doing to help them improve themselves. Therefore the results of an assessment are intended to be used by the team alone. They should not be used by managers to evaluate the team’s performance or to compare and rate teams.

Question is if you can expect that a team can assess itself? It depends as usual :-). Teams who have just started with agile can find it difficult to take some distance and explore how they are doing.  They also might not have enough understanding of the why and how of agile to really assess how they are doing. In such cases an (external) facilitator can help teams to do their first assessments.

Agile retrospectives are another great way for teams to reflect and improve their way of working (read more on how to do them in our book Getting Value out of Agile Retrospectives). They help team to learn observing and analyzing their way of working and define their own improvement actions.  Many skills that team members develop doing retrospectives are also usable to do self-assessments, so investing in retrospectives makes sense.

Finally an agile coach can help a team to develop assessment skills, enabling them to do their own assessments in the future. Soft skills matter in IT and agile coaches can help people to learn and improve those skills. Which is also an effective way to help a team to become agile in an agile way.

Agile self-assessments

I like the Open Space Technology (OST) approach; it’s a great way to get people together and discuss those things that really matter to them. At the nlScrum Meetup about Scrum Maturity Models hosted by Xebia we did an open space session where we exchanged our experiences with agile self-assessments. This is what we came up during our stand-up meeting:

nlScrum 20130206 agile self assessments by Doralin

Photo taken by Doralin on February 6, 2014 at the nlScrum meetup hosted by Xebia

I already talked about assessing values over practices and why self-assessments are intended to be used only by the team and not by their managers. In our discussion in the open space and afterward on the meetup forum, several tools and checklists were brought up to do self-assessments and also several models and frameworks were mentioned that can be used to develop your own assessment. Some of them were already on my list of Agile Self-assessments tools and checklist, but there were also some new ones which I added (thanks guys!):

Self assessing your agility

Have you done agile self-assessments? Did they help you to improve and become more agile and lean? I’d like to hear from you!

Posted in Agile Adoption, Lean, Lean Software Development | Leave a comment

Retrospectives Might Be a Waste of Time If…

Retrospective:  looking back on or dealing with past events or situations.  

In projects, it is a meeting to discuss what was successful, what could be improved, and how to incorporate successes and improvements into future initiatives.  In Scrum, the purpose of a retrospective is to inspect and adapt with regards to people, relationships, process, and tools seeking to implement improvements to the way the Scrum Team does its work.

If you believe that you are the very top of your industry and your competition cannot ever touch you, this article will not help you.  Hope you are right….To everyone else, keep reading.

So you acknowledge that maybe you might need to improve and grow… but here are 7 signs that you’re not doing sprint retrospectives right. Retrospectives might still be a waste of time if:

  1. You think you are smarter than your employees or peers and thus believe they have nothing to offer you.
  2. You just like to be in control.  After all you worked hard to get to the position you are and they should just respect what you tell them to do.
  3. You think that people are the problem and you really just get tired of their complaints and whining.
  4. You think that if somebody has an issue with the way we do things around here, they are just a trouble-maker and should get with the program, or just move on.
  5. You think that if somebody thinks they can do something better, than they should just go do it themselves to prove their worth and stop asking for help all the time like they cannot cut it on their own.
  6. You promote continuous improvement, as long as nobody makes your area look bad, or expects you to have to do anything new or different.  After all we really just want to look good and promote what we are doing.
  7. You really are just too busy.

You are right then!  Retrospectives and continuous improvement initiatives are in fact a waste of time for your organization or team.  Your employees and peers will not contribute anything of substance anyway out of fear.  Sadly, I suspect there are elements of this thinking more often than we would like to admit.  But there is hope, and these attitudes can change.

To succeed, continuous improvement requires a supportive culture – one of safety and respect.  Establishing the culture can be very hard.  The vision and expectations for the culture must be explicitly clear and communicated effectively to all.  Those who are hindering the adoption of the culture must be refocused immediately.  More of this later….

In a culture of safety, ideas and opinions are respected and not criticized. Dissenting opinions are welcome and people are not punished and devalued for them.   It is understood that healthy debate of conflicting views often results in better solutions and sharing of new knowledge.  People are not viewed as the problem, and problems are viewed as opportunities.

It takes time to establish a healthy continuous improvement mentality.  I suspect that is why Scrum came to build it into the process framework – to ensure that new teams were focused on getting this culture established and healthy.  But this is very hard to do well and often gets abandoned too early.

Over time, high performing empowered teams and organizations just build it into how they work and it is not so much a “scheduled reoccurring event”, as just how we do things here.  It becomes the culture.  It occurs spontaneously all the time as part of the norm without requiring a focused activity to ensure that it gets done.

So, if you think a scheduled meeting called a retrospective is a waste of time or not needed because you have achieved a true culture of spontaneous improvement as a way of working, then I applaud you!!!  To everyone else, I suspect you still have some work to do.

Perhaps the first retrospective your business or team should conduct is to determine why they think they do not need an improvement program.

Leadership should immediately resolve impediments that are holding them back from realizing the benefits of the ideas that those closest to the work can offer.

Posted in Agile Teams, Scrum Development | 4 Comments

How Often Are You Wrong?

While we have made great strides in challenging late integration, lack of collaboration and the obvious need for automation, we still have a ways to go when it comes to ideation, and the dangerous amount of certainty we have when it comes to products and people.

Assume Delivery is a Constant

I once had a physics teacher who often said, “Assume acceleration is a constant,” just before he took us into the land of big thinking. Before we stepped too far into the land of complex learning, he tried to reduce the number of variables so we could focus on the more complex aspects ahead. I use this same idea when working with product teams by helping them to work towards delivery as the constant.

Of course delivery is never a constant, but it is tangible and often deterministic. Eco-systems where teams build and sustain adaptive eco-systems with well structured code, high levels of automation, rich collaboration and strong visualizations tend to do well with delivery, and often learn to deliver more than ever before. Thoughtful and aware teams (and programs) quickly realize that as product delivery becomes a constant, product discovery looms large on the horizon, and it is a land that’s messy, clumsy, non-linear and non-deterministic. Best practices rarely help.

Product Arrogance

So, for a minute, assume you’ve made delivery a constant. How sure are you that you are producing the right thing? How do you decide what is your next best investment, and how do you validate your choice? As a tool to help you, I offer of the idea of product arrogance. Inspired by Nassim Taleb‘s use of Epistemic Arrogance in The Black Swan, or “the difference between what you know and what you think you know,” Product Arrogance is simply defined as “The difference between what people really need and what you think they need.”

Now, while you are still assuming delivery is a constant (which is no small challenge on its own), ask yourself, “How wrong are you?” as it relates to the product ideas you are chasing. Or examine the flip side, “How sure are you that you are building the right thing?” What makes you sure, and what makes you unsure, are areas of thinking and learning that confront teams when they’ve worked hard to smooth out delivery. It does not matter if they are using Scrum, Kanabn or NonBan

The Myth of Certainty and the Measures of Realities

Many teams I coach talk about a “definition of done,” one of many emergent ideas from the agile community that has helped people learn to deliver. Work deemed done, in the form of working product in a meaningful environment, improves measures and learning, but sometimes induces a false sense of certainty and a dangerous level of confidence that success is near.

Unfortunately, products are only done when they are in use. Watching users in the wild often teaches teams that what they were certain about. “I am sure people will need to …” is not what people need. It may be that one person’s arrogance, or fear of “not being a good product owner,” is the issue. It could also be the simply fact that the product ideas were right and the market changed the game. When this happens, shedding arrogance and embracing evidence is your best tool for building less of the wrong thing (which allows you to learn fast and spend less).

Embracing Wrongness

Product development, which goes far beyond product delivery alone, is an act of being wrong often. Like science, ideas are tools for learning and need to be viewed with less certainty than an automated test. Where people are involved, as opposed to code, automation is more difficult. People are beautifully chaotic and take unexpected journeys into interesting and uncharted territories. Being ready to be wrong is one way to be ready to learn, and product learning something we all need to practice, and practice and practice.

If you have practical experiences to share, please chime in so we can collaboratively learn from being wrong collectively.

Posted in Kanban, Scrum Development | 2 Comments

Cure Your Agile Planning and Analysis Blues: Top 9 Pain Points

Guest post by Ellen Gottesdiener, Founder and President of EBG Consulting

If you’re on a team that’s transitioning to lean/agile, have you experienced troubling truths, baffling barriers, and veritable vexations around planning and analysis? We work with many lean/agile teams, and we’ve noted certain recurring planning and analysis pain points.

Mary Gorman and I shared our top observations in a recent webinar. Our hostess, Maureen McVey, IIBA’s Head of Learning and Development, prompted us to begin by sharing why we wrote the book Discover to Deliver: Agile Product Planning and Analysis and then explaining the essential practices you can learn by reading the book.

As we work with clients—product champions and delivery teams for both IT and commercial products—we strive to learn continually. And that learning is reflected in the book. It tells you how to take actions that will accelerate your delivery of valuable products and will increase your enjoyment in the work.

9 Pain Points to Prevent, Mitigate, or Resolve

Here’s what you need to know, in a nutshell — the 9 pain points we most often see in planning and analysis. (Note: when you read “team,” it means the product partnership: business, customer, and technology stakeholders.)

Inadequate Analysis: Teams start to deliver and then realize they don’t know what not to build. Some teams, making a pendulum swing to agile, abandon analysis, trying so hard to go lightweight that they go “no weight.”

Poor Planning: Teams waste a lot of time in planning and meeting without first having a shared understanding of the product vision and goals or the product needs for the next delivery cycle. Planning might be taking too long, or, on some teams, the product champion and delivery team mistakenly think they have sufficient information to plan and deliver.

blog frazzled product championFrazzled Product Champion: The product champion (what Scrum calls the Product Owner)—the person who makes decisions about what to deliver and when—is frayed, frustrated, overwhelmed, and overstressed. These people, the keepers of the vision and the holders of political responsibility for the value of the product, often struggle mightily to balance their strategic product-related responsibilities with their tactical ones.

Bulging Backlog: Teams accumulate monster, huge backlogs (baselines) of requirements, often in the form of user stories. Every possible story or option for building the product is weighing down the backlog and squeezing or obscuring the highest-value stories.

Role Silos: The team members are acting according to their formal roles, and not focused on the goal. For example, someone always writes the stories, someone else does the testing, and someone else develops. They don’t have a shared way to communicate or a shared understanding of the product needs.

Blocked Team: Teams. Just. Get. Stuck. Waiting. On hold. It even happens to teams using high-end agile project management tools, which are supposed to help them stay organized and efficient. Some of these teams are overwhelmed by the plethora of requirements (see “Bulging Backlog”). Or they have unclear decision rules or don’t know how to define, quickly analyze, and act on value-based decisions. We’ve also observed teams with too few “fresh,” well-defined requirements, ready to pull into delivery.

Erroneous Estimates: Estimates are way off (dare I remind you, most of us underestimate our work). We’ve observed teams that, even after three or four iterations, can’t stabilize their cycle time or speed. Often, they lack clarity about complex business rules and data details, or about the product’s quality attributes (such as usability or performance). That often contributes to our next observation.

blog traveling storiesTraveling Stories: Traveling stories (no, not traveling pants) are ones planned for a given iteration or release but end up being pushed to a later date. (As you may know, a story is a product need expressed as a user goal. Many agile teams use them, following the canonical format: “As a…I need to…so that…”) Occasionally stories travel due to unexpected technical issues. More often it’s because the stories are “too big” to be completed in a given release. Or at the last minute the team discovers they need an interface. Or they find expected business rules for an unexplored regulation. Or data dependencies pop up. Teams are not thin-slicing their stories based on value, and so they’re unable to finish.

Oops: Teams find unpleasant surprises during demonstrations and reviews, or weeks (or months) after delivery. Or worse, they aren’t delivering the right thing, the right value.

Context-Conversation-Collaboration: Pain Relief

You may have heard of card-conversation-confirmation, originated by Ron Jeffries and his coauthors. These “3Cs” explain the critical aspects of user stories, a part of the planning cycle.

Borrowing from Ron, we’ve found 3Cs of our own: agile product planning and analysis means attending to context, conversation, and collaboration. And these practices relieve the 9 pain points we’ve outlined.

Watch the Video
Hear more about our observations of development teams, learn about the underlying principles that we’ve seen work in all kinds of teams, and see how Mary and I integrated them into Discover to Deliver. The link to the video is here. Let us know what you think.

Troubling Truths, Baffling Barriers, and Veritable Vexations. What are your pain points around agile planning and analysis? Share them with us in the comments section below.

Posted in Agile Management, Agile Metrics, Agile Project Management, Enterprise Agile, Lean, Scaling Agile | Leave a comment

Agile Metrics: Measuring Process Value

One of the things I emphasize in my executive engagements is the need to focus on measuring results rather than expectations, since expectations tend to focus more on operational adherence rather than value delivery.

Couched within this conversation is the idea that Agile is not just about efficiency, it’s also focused on effectiveness (value delivery). After all, what good is a process/method that helps you to do what you do faster/cheaper, but ultimately fails to deliver more value to your end users? Agile, therefore, offers the promise to both decrease costs and to increase revenue.

So, if your emphasis, and maybe your sole reason for choosing to go Agile, is to be more efficient, you will likely see the results you expected; your stuff is going out the door faster. But, if this excludes a focus on increasing revenue/value (i.e. product results), then ultimately you’re really just delaying the inevitable death of your organization. No amount of cost reduction can make up for a lack of revenue production. This idea may suggest that what we produce is more important than how we produce it, but I’ll leave that for another discussion.

Dave Gunther, a colleague at VersionOne, pointed out that process tools don’t really measure product results, and I’m not sure they should ever attempt to do this directly. However, if we view the “efficiency” or process/operational side of this equation as a product (something that attempts to solve a customer problem), then we may be able to find something of value in our process worth measuring.

Consider “pirate metrics”, which offer 5 key metrics to consider for a subscription based business model. Ultimately, these are focused on increasing revenue, which is the final metric. Here they are:

  • Acquisition
  • Activation
  • Retention
  • Referral
  • Revenue

Basically, each of these metrics build on the previous one, so, if you aren’t increasing your acquisitions, then there is no way you will increase your activations, therefore you won’t have increased retention, referrals and ultimately no increased revenue. Or, another way to look at it is that you may have received a referral, which is good, but if you aren’t actively tracking how you came to receive a referral, you don’t have very good chance at recreating that result.

Eric Ries, in his book The Lean Startup, posited that we make guesses on what will actually turn these metric “dials”, and so proposed that instead of investing a bunch of money to fully develop our “assumptions”, we would be better off implementing the scientific method to prove, or rather disprove, them. For example, if you were actively measuring acquisitions, then, hypothetically, every option you choose to implement to your product would affect that measurement. This being true, then we can compare the results of each option to each other to determine which options best get us to our goal of increasing revenue (i.e. value). Essentially, this process is an A/B testing model.

With this model as an example, if we apply it back to the operational/process side of Agile Transformation, what would we consider to be our metrics? Would the revenue equivalent be velocity (I know, don’t compare!)? Would acquisition be equivalent to number of people trained in a boot camp?

What do you think these measurements should be? How do you measure the value of your process options, or do you even measure them at all? Please leave your comments, I’d love to hear what you all think.

Posted in Agile Adoption, Agile Management, Agile Metrics, Agile Portfolio Management, Agile Project Management, Enterprise Agile, Lean | 5 Comments

The Agile Community to Join Forces in Detroit: @AgileAndBeyond

Agile and Beyond: the words paint an image of a dark, star-lit sky. The starship Agile floats through the air toward some distant, efficient, high-performing process improvement.

Excuse the attempt at a dreamy, poetic intro; I’ve got Valentine’s Day on the brain.

Good news; this thinking need not be conceptual dreaming. Agile and Beyond, coming to Detroit next week, brings a place and platform for healthy discussions and dialogue around agile software development’s past, its present, its future.

It’s Agile and Beyond time again, and VersionOne is proud to be a returning sponsor at the conference on Saturday, February 22nd in Dearborn, Michigan.

Stop by and visit us at Agile and Beyond to learn what you need to know about managing your company’s agile processes with an agile project management tool, or continue to evolve or adapt your understanding and execution of agile.  We are the first booth on the left when entering the sponsor area.

Agilists from across the Midwest will gather in Dearborn, Michigan for Agile and Beyond 2014.

Agilists from across the Midwest will gather in Dearborn, Michigan for Agile and Beyond 2014.

When you are not visiting our booth, check out the great slate of sessions available.

From reading the titles and abstracts, these are my favorites:

Stop Thinking and Start Doing: Action is everything, right? In this presentation, Daniel Davis will explore how we can use agile to put noble goals in place for you and your team. This will be personal development at its finest.

The Power of Promiscuous Pairing:  In this provocatively titled talk, Thomas Piggott and Carol Treat Morton will showcase how pairing can yield tremendous benefits even beyond development. Who wouldn’t want to attend a talk that helps your team eliminate ‘towers of knowledge?’

Removing the UX Roadblock: Anyone who has been on an agile team with UX talent knows the struggles. A developer’s work styles, patterns, and pacing may be completely different than a UX designer’s, yet the designer’s contributions and output are pivotal to producing software. Stop thinking of the UX team as a roadblock; instead visualize them as a high-performing team member capable of greatness.

We are just scratching the surface here with the number of awesome presentations and workshops on the schedule.

Thanks, Agile and Beyond for putting together another outstanding event. We look forward to meeting the agile software development community of the greater Detroit area.

BTW: If you have time after the conference, visit one of the great Middle Eastern restaurants that call Detroit home. You won’t be disappointed.

Dan Naden
Community Marketing Manager


Posted in Agile Software, Agile Tools, Scaling Agile | 1 Comment

Can a Team be Scrum without Retrospectives?

Sometimes Twitter is just a bunch of crap and noise.

Other times, stuff comes over that you just can’t ignore. After we published the State of Agile report, I had one of those moments.

It hit me after one dude tweeted something to the effect of: “How in the world can a team claim to be doing Scrum if they don’t practice retrospectives?” I couldn’t let this one go. I polled our staff of professional agile coaches. Within an hour, 6 of them had opinions on whether you can proudly call your team “Scrum” or even “Agile” without conducting regular continuous improvement procedures.


Here I’d like to share with you some of our coaches’ opinions and recommendations – then find out your take. (ADHD moment: If you are new to agile or wondering ‘what is a retrospective?’ here’s a good explanation).

Take this as FREE advice from our professional coaches. Normally you pay for this stuff so IF you enjoy it, you at least owe me a LinkedIn share or tweet @VersionOne.





“You can’t be ‘Scrum’ if you aren’t doing all of the practices of Scrum.” – Steve Ropa

True. But I give this statement a big “So what?” Isn’t the goal of agility to create great software? If some part of Scrum doesn’t work for your team, should you do it anyway just so you can be Scrum?  In the words of John Pinette, I give this a “nay nay.” I recommend doing all of the practices to start with – and only removing or modifying practices when you find them to be unnecessary or even detrimental. Ironically, teams usually come to that conclusion during the retrospective.

You can be agile without retrospectives, but it’s a very, very rare team who can. I have run into a few. They’ve usually been doing XP for a while, and are always co-located.  Some teams did the retrospective because they were supposed to, but never really came up with anything new.  What they were able to do was to inspect and adapt at the drop of a hat. These teams also found that daily standups had become redundant.

“It’s the wrong question to begin with.” – Lowell Lindstrom

The question of whether or not a team can be “Scrum” is a red herring for a few reasons.

First, due to the inherent inspect-and-adapt nature of Scrum, over time, no two teams will be identical and any given team may evolve in a way that makes one of the common or defined parts of the Scrum framework suboptimal. The classic example of this is task articulation and estimation in Sprint Planning, which many agile teams find is not necessary as they improve.

Second, there is no one person who can designate whether or not a team is Scrum, leaving any assessment to the discretion of the assessor. Across experts in the various Scrum communities there is a little consensus. This is due largely to the first point, i.e., the fact that each person’s opinions will be shaped by their experiences. And these are inevitably different.

It’s worth noting that the original definition of Scrum didn’t even include retrospectives. The patterns and papers from the mid-90s, and Ken Schwaber’s first book on Scrum (2001) make no mention of retros. The focus was on the product with the Sprint Review at the end of each Sprint, but no explicit reference to the team’s PDCA. Similarly, the original definition of Extreme Programming (XP) did not include retrospectives.

In 1999/2000 as XP was gaining in popularity, Norm Kerth was writing his book Project Retrospectives: A Handbook for Team Reviews.  Although focused on larger, longer projects and the difficulty of learning what really happened, the ideas resonated strongly with the XP community and we soon saw the practice added to the XP list. The Scrum community followed suit and in Ken’s next book on Scrum (2005), we see retrospectives become part of the framework as we know it today.

So, were teams doing Scrum from 1993-2005 not considered ‘Scrum teams’ because they didn’t do retrospectives? Of course they were; it’s a silly question. What we can say is that the Scrum community and its leaders have found that the most hyper-performing teams reflect on their practices with a tenacious attitude toward improving the way they develop. Most do this through the construct of the retrospective. However, doing retrospectives well is difficult and depends on a culture that values learning. So, if my retrospectives suck and yield no improvement, then am I really any closer to being Scrum than if I do not do them at all?  I would argue: No.  Is a team who uses most of the Scrum framework but not retrospectives, integrating PDCA into their daily work as the Kanban community advocates, still a Scrum team?  I would argue: Yes.

Any discussion centered on “being” Scrum or “doing” Scrum should explore whether a practice improves a team’s performance, the different scenarios and conditions required for a practice to thrive, and the substitutes that might make a practice replaceable.

“Retro is a key ceremony. You cannot be ‘true’ Scrum unless you follow the framework as it was designed.” — Jo Hollen

You can, however, be “ScrumBut”… and realize some value from your partial Scrum efforts.

Going back to agile and Lean principles, the notion of continuous improvement is very foundational. Without retrospectives, I would be concerned about how the culture is addressing the principle of continuous improvement. Do such organizations have other methods through which they can incorporate team feedback and address improvement? Maybe the more interesting examination is why do they NOT want to do a “retrospective” – or not think they need to?  I’ve seen where they were done as part of the process, but often I felt they were not very effective in many teams.

First, it must feel totally safe to bring up something that is not going well.  Many cultures still want to immediately find a person to blame for the “problem.” If anyone feels unsafe, the retrospective will be superficial. Nothing useful will come from it, and the team will quickly find the retro a waste of time.

Even if a team gets to the point of bringing up real issues, there must be a spirit of appreciation for the input – then real results and follow-through.  If nothing ever comes of the feedback, it will quickly stop. Besides, if results are not implemented, then there is no improvement anyway (thus, another waste of time).

Or maybe the team feels that everything is fine. REALLY??? Nothing can be improved? (Maybe you should hire them for coaches then). Even the highest-performing teams will find things that can be improved. But, maybe every two weeks feels too often? Maybe they should do a health-check/status and a deep-dive examination every few sprints. Agile requires some form of engagement and commitment to continuous improvement.

“You can’t be ‘Scrum’ without the ‘Scrum’ ceremonies.” – John Krewson

You can be agile without the ceremonies so long as you’re adhering to the principles, but “Scrum” asserts certain ceremonies as part of the framework. Those ceremonies, retrospectives included, are intended to uphold the theory of empirical process control upon which Scrum was built. I refer to retrospectives as the “missing agile value” and have a blog post coming out soon to address this.

“Learning always precedes agile maturity.”  — Brian Irwin

As you’ll see in John’s blog post, from an organizational perspective, learning always precedes agile maturity. I’m also planning a blog post specifically about expanding retrospectives past the team level and embracing them at all levels in the organization, including (or especially) at the upper-management level.

To me, one of the most critical aspects of agility is learning; i.e., at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Maximizing learning is also a key Lean concept.

I think people tend to get so hung up on processes and how to do things that they forget why they’re doing them in the first place.  But to answer the question directly, if you’re not doing retrospectives not only are you not doing Scrum—you’re not really agile if you aren’t making time for learning. Teams typically stop doing retrospectives because they’re difficult. Once you’ve addressed the low-hanging fruit, it gets complex to address the real hard stuff (people issues, organizational dysfunction, etc.).

“Not doing retrospectives suggests the plan must be perfect.” — Michael Moore

I would say that this is not specific to Scrum so much as it’s one of the principles of agile to inspect and then adjust/tune.  This principle goes beyond agile even; I’m not sure I’ve seen any good improvement method that doesn’t include some sort of periodic reflection and adjustment, whether it be self-improvement or organizational.

Not doing retrospectives suggests that there is no need for adjustment, which means that the team and plan must be perfect.  If they aren’t, however, this activity is essential to maximizing effectiveness.

Of all the principles, this is the first that should be implemented, regardless of the method. From this principle, all other principles and practices are discoverable.


Can a team be Scrum or Agile without retrospectives? Join the debate by leaving a comment below. Better yet, subscribe to this blog; several articles addressing this topic are on deck from our coaches in the upcoming Agile Chronicles. We’d like to hear from you!




Posted in Agile Adoption, Agile Methodologies, Scrum Development, Scrum Methodology | 7 Comments

Education Led Transformation

Guest post from Alex Adamopoulos, founder/CEO of Emergn Limited

In the 1960s the Center for Creative Leadership (CCL) developed the 70/20/10 model, a model that demonstrated how people learn best when it comes to doing their jobs. The study showed that lessons learned from successful and effective managers were:

70% from tough jobs, experience / 20% from people (managers, bosses) / 10% from courses and reading (classroom instruction)

In 1996, two of the original members of the CCL study on the 70/20/10 model wrote the book “The Career Architect Development Planner.” With more empirical data and evidence, they were confident in stating:

“Development generally begins with a realization of current or future need and the motivation to do something about it. This might come from feedback, a mistake, watching other people’s reactions, failing or not being up to a task – in other words, from experience. The odds are that development will be about 70% from on-the-job experiences, working on tasks and problems; about 20% from feedback and working around good and bad examples of the need, and 10% from courses and reading.”  (Lombardo and Eichinger expressed the rationale behind the 70/20/10 model this way in The Career Architect Development Planner).

In the last five years we’ve seen the exponential demand for new thinking in organizations. When I say “new thinking,” I mean new ways of doing our old jobs. This exponential demand is largely credited to adoption of both agile and lean practices. The early years of Scrum and XP have demonstrated that developing and delivering software can be drastically improved but also that many agile practices can now be applied successfully in other core areas of an IT and business organization. The early years of lean showed us that Lean Six Sigma was a good initial foray into compressing DMAIC and taking the idea of lean from the manufacturing floor to the corporate world. We’ve now learned that lean, on its own, is more than adequate without other process models attached to its hip. Lean Startup is a testimony to this.

In all of it, however, companies still spend enormous amounts of money on sending people to training classes in order to learn these new skills; plus they bring in external consultants to coach and mentor. There is value and need in both of these investments, but if we are truly interested in transformation, then we need to look further and outside the traditional methods. This goes back to the 70/20/10 model and why it’s more relevant now than ever.

Part of the answer when we discuss transformation lies in two important questions: ”What do we mean by transformation?” and “What are we transforming?” History tells us that traditional two-day Scrum training has had little effect on helping organizations change how they work. We see a similar challenge with the dependence on tools. Just as some believe that tools will inherently solve problems, two days of training on anything simply cannot product lasting results. Only motivation, perhaps, and some formation of good ideas can help. This is the 10% component of the model: learning from courses and reading (classroom instruction). To emphasize, this is still important, but it’s not the whole picture, nor does it serve the real need: how we help people change the way they do their work and how to make that change stick.

The 70% component of the model: learning from tough jobs and experience is where the real learning sticks. This requires the consistent and repeated application of practices and principles on real work — something in which you are engaged at your company where you can begin to see immediate results and understand why change matters. This approach, often referred to as work-based or action learning, is new to the agile and lean market; yet, it is quickly becoming the new normal. Think of it in the form of these statements:

  • You want to introduce agile and lean thinking to improve your customer experience and overall business performance
  • You want to invest in what’s most valuable to your organization: your people
  • You want to retain your best people and provide a learning journey for others so that they become your best people
  • You want to improve, even change, the way you deliver your services and products to gain market share and increase brand equity
  • You want to leverage “just enough” external expertise and not be heavily dependent on someone else
  • You want to do all this in the shortest timeframe possible with the maximum results and most reasonable cost
  • All this is what you mean by transformation

I expect there are more statements you’d add, but to achieve these we need to bring it back to how people learn. A systemic learning approach will always provide greater value and lasting benefits. Incremental and disparate training that is purely content- or classroom-driven simply cannot product the same, compelling results.

Education Led Transformation is a phrase that has come to mean many things for me in the last year; mainly it has been a re-awakening that organizations improve only when people do. Oh my, this is so obvious that it even seems trivial to say, but haven’t we all fallen into the trap that processes and tools are so much more important? Isn’t this the reason the Agile Manifesto was so key in saying, “individuals and interactions over processes and tools?” Isn’t it still, and won’t it always be about people?

Therefore, we conclude that learning AND development are so much more important and so much more than just training. They bring a lifestyle of learning and applying; this is why leading with a systemic, work-based learning approach is so fundamental to the cause. Yes, I’m a bit biased to the work-based (action) learning topic, but indeed I’ve now seen too many examples of how impactful it truly is.

“I hear and I forget;
I see and I remember;
I do and I understand.”


Posted in Agile Adoption, Agile Coaching, Agile Teams, Agile Training, Lean, Scrum Development | 1 Comment