Tag Archives: scrum

Scrum vs. Kanban vs. ADKAR vs. Kotter: Change Management

Learn more about transforming people, process and culture with the Real Agility Program

The battle of the organizational change management approaches!

Check out the presentation I did last night at Agile Mississauga Meetup.

20170208 Agile Mississauga Meetup – Change Approach Characterization Model

I describe a model for understanding change management approaches and deciding which ones to use for your situation.  I also look briefly at Positive Deviance and Appreciative Inquiry.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

How Kanban Saved Agile

Learn more about transforming people, process and culture with the Real Agility Program

For my working definition of Kanban, please refer to my previous article 14 Things Every Agilist Should Know About Kanban (this contains links to the Kanban body of knowledge, including Essential Kanban Condensed by David J. Anderson and Andy Carmichael).

For my working definition of Agile, please refer to The Manifesto for Agile Software Development.

In reality, Kanban isn’t actually saving Agile nor is it intended to, nor is any thoughtful and responsible Kanban practitioner motivated by this agenda. What I’m really trying to convey is how human thinking about the business of professional services (including software development) has evolved since “Agile” as many of us know it was conceived around 20 or so years ago. The manifesto is the collective statement of a group of software development thought leaders that captured some of their ideas at the time about how the software industry needed to improve. Essentially, it was about the iterative and incremental delivery of high-quality software products. For 2001, this was pretty heady stuff. You could even say that it spawned a movement.

Since the publication of the manifesto in 2001, a lot of other people have had a lot of other good ideas about how the business of delivering professional services can improve. This has been well documented in well known sources too numerous to mention for the scope of this article.

Substantial contributions to the discourse have been generated by and through the LeanKanban community. The aim of Kanban is to foster environments in which knowledge workers can thrive and create innovative, valuable and viable solutions for improving the world. Kanban has three agendas: survivability (primarily but not exclusively for the business executives), service-orientation (primarily but not exclusively for managers) and sustainability (primarily but not exclusively for knowledge workers). Kanban provides pragmatic, actionable, evidence-based guidance for improving along these three agendas.

Evolutionary Theory is one of the key conceptual underpinnings of the Kanban Method, most notably the dynamic of punctuated equilibrium. Evolution is natural, perpetual and fundamental to life. Long periods of equilibrium are punctuated by relatively short periods of “transformation”—apparent total and irreversible change. An extinction event is a kind of punctuation, so too is the rapid explosion of new forms. Evolutionary theory is not only a scientifically proven body of knowledge for understanding the nature of life. It can be also applied to the way we think about ideas, methods and movements.

For example, science has more or less established that the extinction of the dinosaurs, triggered by a meteor impact and subsequent dramatic atmospheric and climate change, was in fact a key punctuation point in the evolution of birds. In other words, dinosaurs didn’t become extinct, rather they evolved into birds. That is, something along the lines of the small dinosaurs with large feathers hanging around after Armageddon learned to fly over generations in order to escape predators, find food and raise their young. Dinosaurs evolved into birds. Birds saved the dinosaurs.

There has been a lot of social media chatter and buzz lately about how Agile is dead. It is a movement that has run its course, or so the narrative goes. After all, 20 years is more or less the established pattern for the rise and fall of management fads. But too much emphasis on the rise and fall of fads can blind us to larger, broader (deeper) over-arching trends.

The agile movement historically has been about high-performing teams. More recently, market demand has lead to the profusion of “scaling” approaches and frameworks. Scaling emerged out of the reality of systemic interdependence in which most Agile teams find themselves. Most agile teams are responsible for aspects of workflows—stages of value creation—as contributors to the delivery of a service or multiple services. Agile teams capable of independently taking requests directly from and delivering directly to customers are extremely rare. For the rest, classical Agile or Scrum is not enough. The feathers just aren’t big enough. Agile teams attempting to function independently (pure Scrum) in an interdependent environment are vulnerable to the antibodies of the system, especially when such interdependencies are merely denounced as impediments to agility.

Some organizations find themselves in a state of evolutionary punctuation (the proverbial sky is falling) that can trigger rapid adaptations and the emergence of local conditions in which independent service delivery teams can thrive. Most large, established organizations seem to be more or less in a state of equilibrium. Whether real or imagined, this is what change agents have to work with. However, more often than not, the typical Agile change agent seems adamant that the sky is always falling and that everyone accepting that the sky is falling is the first step to real and meaningful change. This is not an attitude held by Agile change agents alone. This is a standard feature of traditional 20th Century change management methods, the key selling point for change management consulting.

Naturally, most self-identifying “Agilists” see themselves as change agents. Many of them find themselves in the position of change management consultants. But the motivation for change can quickly become misaligned: Change needs to happen in order for Agile to work. If you are passionate about Agile, you will seek to bring about the environmental changes that will allow for Agile to thrive. We don’t need to follow this path too far until Agile becomes an end in itself. It is understandable then that for some, Agile appears to be a dead end, or just dead.

But if there is a larger, over-arching historical process playing out, what might that be? Perhaps it has something to do with the evolution of human organization. Perhaps we are living in a period of punctuation.

 

 


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

A Group of Geographically Distributed Staff is NOT a Scrum Team

Learn more about transforming people, process and culture with the Real Agility Program

It’s my opinion, and I think the opinion of the authors of Scrum, that a Scrum team must be collocated. A collection of geographically distributed staff is NOT a Scrum team.

If you work in a “distributed team”, please consider the following question.

Do the members of this group have authority to decide (if they wanted to) to relocate and work in the same physical space?

  • If you answer “Yes” with regard to your coworkers: then I’d encourage you to advise your colleagues toward collocating, even if only as an experiment for a few Sprints, so they can decide for themselves whether to remain remote.
  • If you answer “No”, the members do not have authority to decide to relocate:
    • then clearly it is not a self-organizing team;
    • clearly there are others in the organization telling those members how to perform their work;
    • and clearly they have dependencies upon others who hold authority (probably budgets as well) which have imposed constraints upon communication between team members.
    • CLEARLY, THEREFORE, IT IS NOT A SCRUM TEAM.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

A Book Review: “The Great ScrumMaster”, by Zuzana Šochová

Learn more about transforming people, process and culture with the Real Agility Program

In Brief

Buy it! You won’t be disappointed!

In Depth

I read the book in 3 sittings.

The First Sitting

Zuzi gave her book to me in October. She was visiting Toronto at the time and we spent a few days together teaching Scrum – I was honoured that she would share a classroom with me and that I’d get a sneak peak at her new publication. Almost immediately after she gave me the book I found a few minutes to thumb through it and read the foreword and first chapters. I immediately liked what I saw.

The foreword is written by Linda Rising who frames the book nicely by reminding us of these simple principles: “successful change is built around small steps and learning”, and “the book offers a chance for reflection and evaluation”. Zuzi’s preface describes briefly her journey to become a great Scrum Master. Hers is a story about humility and studious peristence; the journey is unique and difficult for us all. I could relate! The best aspect of the early pages in the book are the photographs of Zuzi. The book exudes her character traits: a friendly and insightful expert, a colleague and advisor. Her photos, as well as her illustrations throughout the book, help the reader to understand her colourful character; her stance as a coach and mentor; and her voice as an author.

My time was limited so I didn’t get far in that first sitting though my first impressions of the book are memorable. It’s a big book – not thick, that’s not what I mean. I mean large, wide pages. Approximately 20 centimetres square. It’s the kind of book that lays open on a coffee table. This is important! I understand many people buy digital books but if you can find the book in physical format, buy it! The medium is the message, as Mcluhan said. The medium, in this case, is a lightweight book that rests easy, open-faced, on a desk or coffee table. As you pass by the table or sit for a while to enjoy a conversation, you’ll find the book open and waiting for you. You’re likely to thumb through it lazily, your mind wandering while on the phone or talking with a friend, then something will catch your eye. It’ll be a page you’ve looked at a dozen times but suddenly a sentence or illustration will stand out for you, draw your attention. Like, “…if you join a discussion with the core metaskill of curiosity it will be different than if you choose listening or teaching”. That sentence is on page 88 – that’s the one that jumped off the page for me today. I’ve read that page a few times already but this day, in this moment, that sentence resonates. Such a simple sentence on a page and sparse text and white space…but exactly the solace you will need.

The Second Sitting

I was riding a train with the book open on my lap. Through the window passed the Canadian landscape, and I’d glance at the book between sips of coffee to take in another paragraph, picture, page. (See how cool the format is??) What I’ve learned from the next chapters of the book is that I share Zuzi’s interpretation of Scrum and of the Scrum Master’s role.

Her perspective is a philosophical one, yet she effectively relates the material to practical examples. Zuzi describes a concept she calls the #ScrumMasterWay. This is an innovative model for understanding how a Scrum Master can adapt their mode of service depending on the conditions of the organization they serve. Perhaps at first, the organization they serve is ‘A Scrum Team’ – and in that mode of service a Scrum Master will facilitate Scrum and help the team to self-organize. Next, after all the easy fruit has been picked and the Scrum Team is capable of continuous and deep self-improvement, the Scrum Master’s mode of service is likely to change – the team no longer needs help with the rudiments so the Scrum Master may focus more intently upon relationships to and within the team. And finally, the 3rd level of #ScrumMasterWay is achieved when the Scrum Master is able to focus their effort toward the entire system, “bringing the Agile Mindset and Scrum values to the company level”.

The Last Sitting

Reading about Zuzi’s #ScrumMasterWay concept in the previous sitting led me to think nostalgically about my own journey. I know this book, had she written it a decade ago, may have saved me from some mistakes of my own. I’ve come to more deeply appreciate her telling of the Scrum Master role.

In the 2nd half of the book, she provides a glimpse into numerous related practices and concepts. A collection of references and teaching tools that most Scrum Masters will discover along their journey. For example, all Scrum Masters will find themselves in discussion with stakeholders about the nature of complex problems and, ta da!, like a stone tablet from a high mountain will appear Dave Snowden’s CYNEFIN framework! A simple diagram…it’s so obvious! All Scrum Masters will find themselves in a personal struggle between telling and listening: “should I coach as a teacher?” or “coach as a facilitator?” and, without fail, a fellow Scrum Master will recommend a training course with the Agile Coaching Institute to better understand the coaching stance(s).

Here’s the truth of it: if a young jazz musician wants to become a great jazz musician, there are some iconic recordings to which they must listen: Kind of Blue; anything by Duke Ellington and Louis Armstrong; Blue Train; Saxophone Colossus. No drummer is worth their salt without having spent a zillion hours listening to Max Roach and Jimmy Cobb. Likewise, every great Scrum Master has had to grapple with the iconic challenges of servant leadership – they’ve spent a zillion hours pondering the difference between the words “should” and “could” and they’ve praised the power of the question, “what if?”

So, to help Scrum Masters along their journey, Zuzi has compiled many of the community’s greatest hits in her book. Einstein is often quoted as saying, “If you can’t explain it simply, you don’t understand it well enough.” Perhaps then, one can examine how well a person understands a concept by how simply they can explain it… right? By that measure, it’s evident that Zuzi understands her material as she’s able to distill complex topics to just a colourful drawing and a few bullet points. “Root cause analysis” is described concisely with 3 paragraphs, 4 bullet points, and a beautiful drawing of a tree. Her purpose, keep in mind, isn’t to make the reader an expert in root cause analysis – her point is as if to say, “remember…problems often run deeeeeeep in the system. They’re organic. Find the seed.” I’m hearing in my mind a wise old music teacher, telling the aspring young jazz musician, “remember Herbie Hancock…go listen to Maiden Voyage…behold the deeeeeeep groove and floating melodies. It’s organic”.

The collection of materials which complete her book include highlights of Tuckman’s “Stages of Group Development”; Lencioni’s “Five Dysfunctions of a Team”; the martial artist’s progression through “Shu Ha Ri”; a shortlist of “Powerful Questions”; and a few others. In this last sitting, as I finished reading the book, I was struck by the similarity between Zuzi’s journey and interests and my own. I too have enjoyed Lencioni’s books, Tuckman’s model, the practice of co-active coaching. While I’ve lived and practiced all these years in Canada and Zuzi has lived and practiced in Prague, how is it we have been exposed to a similar body of knowledge and wisdom? I take some comfort in that, actually.

Conclusion

I face a difficult decision now. Zuzi signed this book for me and it’s in pristine condition. However, if I’m not careful, I am certain in the coming years this book will become littered with notes and comments, dog-eared pages and sticky-notes everywhere. Shall I allow myself to ruin this pristine book? Yes. Yes, I shall 🙂

See also:


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Lessons from a Scrum Webinar with Paul Goddard

Learn more about transforming people, process and culture with the Real Agility Program

“Improv-ing Your Scrum Team” was the title of the webinar given by Paul Goddard, a CST and Coach from the UK with a background in improvisational theatre. He has written and coached extensively on the use of improvisation to help Scrum teams develop. Because of my own experience in teaching and creating theatre, I was eager to see how Mr. Goddard used improv to improve Scrum teams.

For clarity’s sake, we can describe improvisation, in theatrical milieus, as the act of making things up as you go along. Improvisers are normally people who know their discipline very well, and are able to allow their creativity to take them into new places, new expressions, in their art.

Themes

The improv themes Goddard covered that can be used with Scrum teams were: creating safety, being spontaneous, telling stories, changing status and increasing sensitivity.

He likened these themes to the Agile Manifesto which proclaims: “Individuals and interactions over processes and tools,” and “Responding to change over following a plan.” He also related improv to Agile principles of “welcoming change,” “face to face is the best way to convey information,” and “the best designs emerge from self-organizing teams.”

Myths

In an interesting aside, he also compared myths of Agile to myths about Improv, for example, that Agile is only about creating software, and Improv is only about comedy. Another myth is that Agile and Improv are about unstructured chaos, whereas both prescribe being disciplined within a framework. Goddard described the Scrum framework as “a lightweight structure that uses constraints to unlock creativity;” improv also provides such a structure.

Creating Safety

Improv starts with “creating safety.” Since it is impossible to improvise alone, we must learn to trust others. This involves a team behaving as a family who rescue each other if necessary. There are no mistakes in improv; team members work for each other. When we try too hard in improv to get it right, it becomes a struggle to feel safe. Ultimately, we should be able to feel safe whether we win or lose, and definitely we feel safe when we PLAY.

Being Spontaneous

The second theme is “being spontaneous.” Spontaneity is the ability to act on impulse as soon as an idea occurs. This is the bread and butter of creativity. We are less spontaneous when we filter or edit our ideas before trying them out. We usually do this filtering because we fear our ideas being deemed crazy, or obscene, or unoriginal. Good improvisers increase their spontaneity by giving and receiving offers from team members. Offers are the currency of improv: you go with an idea, build on it, and keep a scene going. Bad improvisers put up blocks, that is, they reject ideas, and a scene goes nowhere.

Telling stories

Goddard tells us that the power of storytelling lies in the fact that many parts of the brain get activated: empathy is increased, oxytocin hormone and cortisol is released when we feel empathy for a character, and so on. Conversely, the brain switches off ideas or stories that are cliches – things we’ve heard too many times before and are inured to. The beauty about stories is that they make dry data more human and therefore interesting.

Changing status

Status always exists, especially in business environments. Some jobs or roles imply having a higher status, i.e. Scrum Master. If physical power poses adjust the hormones in our bodies, as Goddard claims, then the opposite is also true. In improv, playing high or low status and then changing it becomes a dynamic and creative game. It assists in collaboration. Low status players in improv tend to accept offers from their fellows; high status tend to refuse offers, unless they can control them. Scrum teams can learn to play with status to collaborate more effectively.

Increased sensitivity

Great improvisers develop certain qualities: selflessness (they want to make others look good), listening, observation, recollection/ memory, and emotional awareness (ability to pick up on cues). They are able to be “fully in the moment.” Goddard describes this as “thinking inside the box,” i.e. with safety established, the ideas are already there.

Back to Scrum

Just as in an improv team, a Scrum team’s firmest foundation is trust. How can one introduce improv and its beneficial themes to a Scrum team? Start with the idea of a game. It’s not about performing. It’s simply about having fun together, getting to know each other, learning common values, shaking off the dust of work-related responsibilities and allowing time for play. If you’re working with introverted types, allow that person to opt out. Make sure no one is judged. It’s important to be able to joke and feel like a family. Even a non co-located team can play word games over the telephone.

I look forward to trying out some improv with my own team, and, hopefully, in the future with others.

For a more in-depth understanding of the use of improv see Paul Goddard’s book “IMPROV-ING AGILE TEAMS” available at www.amazon.ca.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

The Scrum Team Assessment – Official Launch

Learn more about transforming people, process and culture with the Real Agility Program

Hi Everyone,  I don’t do announcements on here too often, but I wanted to let everyone know about the official launch of our new product: the Scrum Team Assessment – an online tool for your team to get a report on how well they are using the Scrum framework… and most importantly, helpful recommendations on how to improve!  This is a fully automated Scrum maturity assessment tool!

The Scrum Team Assessment is based on the years that I and two other coaches (Paul Heidema and Travis Birch) have been working with Scrum and Agile teams to improve business and technical results.  The Scrum Team Assessment is a joint effort that has resulted in a fully automated virtual coach for your team.

The analysis is both statistical and expert-system based.  This means that the report has basic information about how the team is following Scrum, and, more importantly, clear how-to advice to get your team to make improvements.  There are “quick wins” which are easy but will have a significant impact as well as long-term recommendations that are often harder, but will drive your team to a high-performance state.

The Scrum Team Assessment includes a survey of about 100 questions that focus on seven broad categories:

  • The team’s environment
  • The basic Scrum process
  • The Product Backlog
  • Team Membership
  • ScrumMastering
  • Product Ownership
  • and Agile best practices

Every team member fills in the survey to help us generate a valid set of recommendations.

The Scrum Team Assessment is $496/team/use (that’s Canadian dollars).  If you have several teams or wish to obtain an enterprise license, please contact us at sales@berteigconsulting.com or +1-905-868-9995.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Quotable Quotes: Leadership is the key to driving change

Learn more about transforming people, process and culture with the Real Agility Program

Jerry Doucett 201601 white background - head - 275 square“Leadership is the key to driving change and progress.  Executives and managers of Scrum teams need to nurture the environment, let go of the “how”, allow the team to learn from mistakes, and encourage and coach the growth of the collective team knowledge and overall experience.

Understanding the dramatic impact leadership has on a transitioning team is also very critical, as a single word or direction from the executive level can single-handedly affect (either positively or negatively) the team’s future behaviours and resulting successes or failures.  And without a true environment of trust built by the leadership, team members will often shy away from taking a risk to try something new or unknown.” (By Senior Agile Coach Jerry Doucett)


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Quotable Quotes: Limit Work-In-Progress As Much As Possible!

Learn more about transforming people, process and culture with the Real Agility Program

Jerry Doucett 201601 white background - head - 275 squareScrum team members should be allocated to as few different initiatives as realistically possible.  The more projects you are allocated to, the more task switching you may have to perform, the longer it will take to complete any one item, the thinner you will be spread and the less effective you will be.  In other words, people (and teams) should limit their work in progress as much as possible and focus on completing those things that truly matter most.  This is true for any framework, but it is particularly emphasized with Agile ones.  Note there is a slight but fundamental difference between being allocatedto a team and being dedicated to a team – that is a topic for a future article.

(By Senior Agile Coach Jerry Doucett)

*******************************************************************

Jerry is leading a series of SAFe training classes in Toronto, Ontario from September through to December 2016. See here for more details.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Announcements, Links & Ponderables

Learn more about transforming people, process and culture with the Real Agility Program

For 10 years, Agile Advice has been providing useful information, Agile-related announcements & entertaining content for Agile ambassadors.

But Agile Advice is just one of the many portals to the BERTEIG online network.

For your easy reference here is a list of other 5 links which may bring you to the information you are looking for.

  1. Register for Training & Learning Events 
  2. Sign Up for BERTEIG’s Loyalty Program
  3. Find out More About BERTEIG’s Corporate Experience
  4. Join the 1000+ others in the LinkedIn Worldmindware Group
  5. Visit the BERTEIG-hosted Facebook Scrum Group with 2600+ members

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

A Safe Approach To Developing High Performance Teams

Learn more about transforming people, process and culture with the Real Agility Program
Jerry Doucett 201601 white background - head - 275 square
Improving Teams Means Changing Culture

By Jerry Doucet

Under the right conditions Scrum can be a tremendous success story, but it often requires hard work to get there.  For new Scrum teams it means learning to fundamentally work very differently than they are used to, such as relying on a lot more collaboration, making and delivering on shared commitments and building a high degree of trust.  For existing Scrum teams it means constantly renewing the team commitment to each other, the cause, and to the Scrum framework.  This includes the rather painful practice of revisiting the fundamentals and ensuring any deviations from accepted processes or practices were for the right reasons and had the right results.

To have a chance at achieving high performance a new-to-Scrum team will not only need to just change their processes, but fundamentally change the culture and behaviour of the team and all of the supporting roles (that includes their leadership).  Meanwhile, a mature or well-established team should never assume they are high performance; they should always be checking (and rechecking) that they are still living the Agile values.

********************************************************************

Jerry is offering a number of SAFe training opportunities in Toronto, Ontario from September through December 2016. More details here. 


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Link: Scrum Vs. Kanban

Learn more about transforming people, process and culture with the Real Agility Program

Vandana Roy writes a most succinct and clear description of Scrum and Kanban in this exceptional article.

Although I was first introduced to OpenAgile in 2013, Scrum and Kanban are relatively new to me this year. While not working in a tech-based department which uses these methods, I am interested in learning as much as possible about each system. I found her explanation and chart very helpful.

Here is a quote and chart she features in the article:

“Both Scrum and Kanban are unique and emphasize on more productivity with quality and efficiency for business. The table below shows advantages of both Scrum and Kanban and the commonality in both is  to keep delivering quality product.”

 

Advantages of Scrum

Advantages of Kanban

Transparency

Flexibility

Improved credibility with clients

Focus on Continuous Delivery

High Product Quality

Increased productivity and quality

Product Stability

Increased efficiency

Team members reach sustainable pace

Team members ability to focus

Allows client to change priorities and requirements quickly

Reduction of wasted work/wasted time


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

“Teams” Larger Than Eleven Are Not Scrum Teams

Learn more about transforming people, process and culture with the Real Agility Program

Mobbing Team

Scrum suggests the size of the Development Team (the Scrum Team members who perform the work of the Sprint Backlog) be between three (3) and nine (9) people. (The Scrum Master and Product Owner are not included in that count unless they are also executing the work of the Sprint Backlog.) To maximize cohesion and minimize complexity, it is important larger groups be split into smaller units or downsized.

Considerations for re-organizing into multiple Scrum Teams:

  • People executing the work may be best suited to decide optimal team size and composition. Adjustments to team composition will be most effective if the team members are trusted (and supported) to re-organize around their own work.
  • Groups larger than eleven people often naturally subdivide into smaller, cross-functional sub-groups; therefore it may be possible to carefully observe which team members interact regularly while getting work done and simply acknowledge those informal arrangements.
  • In order to minimize dependencies between teams, Scrum Teams whose mandates are to own discreet Products or systems are preferable to groups whose mandates are to support “components” of larger systems.
  • Organizations which currently employ Project Management methods ought to consider changing budgeting & staffing practices to align around Product delivery rather than Project Management. Doing so will make value streams transparent and bring clarity to Product-centric team mandates.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Formula for Building a Successful Scrum Experience

Learn more about transforming people, process and culture with the Real Agility Program

Under the right conditions Scrum can be a tremendous success story, but it often requires hard work to get there.  For new Scrum teams it means learning to fundamentally work very differently than they are used to, such as relying on a lot more collaboration, making and delivering on shared commitments and building a high degree of trust.  For existing Scrum teams it means constantly renewing the team commitment to each other, the cause, and to the Scrum framework.  This includes the rather painful practice of revisiting the fundamentals and ensuring any deviations from accepted processes or practices were for the right reasons and had the right results.

To have a chance at achieving high performance a new-to-Scrum team will not only need to just change their processes, but fundamentally change the culture and behaviour of the team and all of the supporting roles (that includes their leadership).  Meanwhile, a mature or well-established team should never assume they are high performance; they should always be checking (and rechecking) that they are still living the Agile values.

Needless to say this can become an extremely complex challenge!  To be absolutely clear, I’m not proposing there is a single formula or recipe that works, but I do believe certain criteria can dramatically improve your Scrum team’s chances of success.  To that end here are 10 tips (plus a bonus) that may help you focus your efforts towards building a successful Scrum team and experience.

 

1. Right Number of Team Members

Currently the Scrum Guide recommends that Scrum teams will work best with three to nine people (not including the Scrum Master and Product Owner).  Too few people on the team and you risk not having enough technical expertise and coverage of critical skills.  Too many people on the team and you may become challenged to truly collaborate effectively.  Remember, this is just a guideline and you may be successful with different numbers, you just need to be aware of the impacts and make sure the gaps are covered.

2. Appropriate Balance of Skills

Scrum teams really should be balanced and cross-functional.  Having all of the necessary skills on the team for delivering a complete solution (not roles, but skills) will encourage and support end-to-end thinking all the way from design to implementation.  This approach will result in a better solution and a superior customer experience, but it relies on whole team collaboration.  Note this does not mean individual team members need to be fully cross-functional, but what is important is that all the critical skills are represented on the team and each team member contributes their domain expertise towards the collective strength.

3. Propensity for Engineering Technical Ability

For increased chances of success, a Scrum team should leverage technology and engineering practices whenever possible.  Techniques, skills and tools that facilitate Agile approaches such as Continuous Integration, Automated Testing and Test Driven Development all make technical excellence, continuous improvement and truly being “Done” every Sprint a possible reality for a Scrum team.

4. High Team Member Allocation

Scrum team members should be allocated to as few different initiatives as realistically possible.  The more projects you are allocated to, the more task switching you may have to perform, the longer it will take to complete any one item, the thinner you will be spread and the less effective you will be.  In other words, people (and teams) should limit their work in progress as much as possible and focus on completing those things that truly matter most.  This is true for any framework, but it is particularly emphasized with Agile ones.  Note there is a slight but fundamental difference between being allocated to a team and being dedicated to a team – that is a topic for a future article.

5. Empowered and Knowledgeable Product Owner

Your Product Owner needs to be informed, available, business-savvy, knowledgeable, collaborative, and empowered to make decisions about what to build and what order to do it in.  They also need to be a strong negotiator and very capable at conducting business driven trade-offs.  In the end, a Product Owner needs to effectively communicate, convey and deliver on a clear vision to the Team and Stakeholders to ensure a useful solution is created.  Without empowerment, knowledge, and vision in a Product Owner the team will struggle.

6. Equitable Scrum Master

Having a good process is only part of the equation.  A good Scrum Master will champion and enforce that process, protect the team, encourage collaboration, highlight (escalate when necessary) and encourage the removal of obstacles, facilitate discussions, provide fair and constructive feedback, cultivate a culture of continuous improvement and learning, and work to help the team live the Agile values.

Remember that the Scrum Master has authority over the process but not over the team.  As the process champion the Scrum Master may sometimes even find themselves in a conflict between maintaining the Scrum rules and guiding the team as they discover the need to adapt practices to better align with their own needs and ways of working.  In that regard a Scrum Master should understand and embrace the servant leader role.  In the end, a Scrum Master needs to be the person that helps the team make decisions, but not the person that makes decisions for them.

7. Strong Executive Support

Leadership is the key to driving change and progress.  Executives and managers of Scrum teams need to nurture the environment, let go of the “how”, allow the team to learn from mistakes, and encourage and coach the growth of the collective team knowledge and overall experience.

Understanding the dramatic impact leadership has on a transitioning team is also very critical, as a single word or direction from the executive level can single-handedly affect (either positively or negatively) the team’s future behaviours and resulting successes or failures.  And without a true environment of trust built by the leadership, team members will often shy away from taking a risk to try something new or unknown.

8. Solid Partnership Commitment

There must be a consistent commitment and engagement from all parties in the organization towards adopting the Scrum framework, Agile methods, and thinking.  The initiative must be an open, collaborative experience and there must be complete understanding  and alignment by all parties in assuming the risks and rewards as well as sharing in the effort.  This includes not only business partners and their IT counterparts, but their leadership as well as all of the people and teams supporting an Agile initiative.

9. Reduced Team Dispersion

Co-located teams are more effective communicators and can sometimes experience increased productivity by up to 60% if situated together in the same room.  More simply stated, the greater the dispersion factor, the greater the challenge of collaboration.  Note that time zones are often considered the largest dispersion factor and can have a greater impact than geography.

Although it is strongly recommended that teams be co-located, it is not mandatory to success.  In fact, certain Agile practices have factors, tools and techniques inherent to them to help bridge some of the shortcomings of increased dispersion, such as a higher reliance on frequent collaboration and communication.  But to be clear, they do not replace the value of face-to-face conversation, they are merely a crutch to not having it.

10. Consistent Education and Coaching

To ensure consistency and a shared understanding, whole teams (including the business, IT, and their leadership of executives and managers) should receive a common skills development and education experience in proper Agile Thinking, the Scrum Framework, aligned practices and mindset training.  Coaching should then reinforce this new knowledge and encourage appropriate behaviours to turn these new practices into habits.  Indeed, learning should be a continuous cycle and endless journey towards excellence, and Scrum leverages this through frequent retrospection and continuous improvement.

11. The Right Attitude!

Mutual respect and caring are the cornerstone to the team’s success and it needs to be integral to their culture and beliefs.  Not just saying but living the belief there are no heroes or scapegoats.  Everyone, including the business, executives, team members and leadership must collaborate and share in celebrating the successes as well as accepting responsibility for setbacks and failures.

Everyone must have the right attitude and commit to not only DOING as needed by attending the ceremonies or following the process and practices but truly wanting to BE part of the solution by willingly changing the way they think, work and collaborate.

 

At the end of the day your goal should not be to become Agile or Scrum savvy.  Instead your real goals and outcomes should align with achieving the key benefits of Agility, and with what Scrum offers.  These should include (but are not limited to) increased customer satisfaction, faster delivery of value, improved feedback loops, adopting a continuous improvement mindset, improved employee morale and increased employee retention.  Scrum is just one of the many tools or approaches you may choose to get there, but it is certainly an important one to consider if these outcomes align with your goals.

For Scrum to be truly successful at your organization, you must dramatically transform your very culture and business approach.  To be clear, this is not easy to do but the rewards are well worth the effort.  By embracing such a transformation, the adopted change in behaviour, beliefs and practices should result in a more successful Scrum experience and a higher degree of satisfaction for both your customers and employees.

Can you think of other success factors that might help your Scrum team succeed?  There are lots, so feel free to reach out and share them below.

 

Thanks to Photographer: Chris Potter for this awesome photo.

Sourced from stockmonkeys.com | Flickr Portfolio


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

The New Scrum Guide: The 5 Scrum Values

Learn more about transforming people, process and culture with the Real Agility Program

Ken Schwaber and Jeff Sutherland have just announced the new version of the Scrum Guide!  The only change is the addition of two paragraphs about the five Scrum values:

When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and builds trust for everyone. The Scrum Team members learn and explore those values as they work with the Scrum events, roles and artifacts.

Successful use of Scrum depends on people becoming more proficient in living these five values. People personally commit to achieving the goals of the Scrum Team. The Scrum Team members have courage to do the right thing and work on tough problems. Everyone focuses on the work of the Sprint and the goals of the Scrum Team. The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work. Scrum Team members respect each other to be capable, independent people.

The Scrum Guide is the sole and official definition of Scrum.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

The Retro Game

Learn more about transforming people, process and culture with the Real Agility Program

The Hunt for Better Retrospectives

The rumours had started to spread, retrospectives at our organization were flat, stale and stuck in a rut. The prevailing thought was that this was stalling the pace of continuous improvement across our teams. In truth, I wasn’t sure if this was at all true, it’s a complex problem that has many possible contributing factors. Here are just some possible alternative or co-contributing causes: how the teams are organized, the level of safety, mechanisms to deal with impediments across the organization, cultural issues, levels of autonomy and engagement, competence & ability and so on…

Despite this, it didn’t hurt to have a look for some inspiration on good retrospectives. I really liked Gitte Klitgaard’s talk called Retrospectives are Boring and Useless – Or are They? In particular the parts around preparing and establishing safety.

On the theme of safety, I thought we could try to go as far as having fun; we’d already had lots of success with the getKanban game (oh Carlos you devil!). Where it all tied together for me, was being inspired by the great question-based approach from cultureqs.com that I’d had a chance to preview at Spark.

If I could create a game with the right prepared questions, we could establish safety, the right dialogue and maybe even have some fun.

The Retro Game

This is a question-based game that I created that you could use to conduct your next retro for teams of up to 10 people. The rules of the game are fairly simple and you could play through a round or two in about 1 to 2 hours depending on team size and sprint duration. Prep time for the facilitator is about 2-4 hours.

theretrogame

Prepping to play the game

You, as facilitator, will need to prepare for 3 types of questions that are thought of ahead of time and printed (or written) on the back of card-stock paper cards.

One question per card. Each question type has its unique colour card. About 8 questions per category is more than enough to play this game.

The 3 types of questions are:

In the Moment – These are questions that are currently on the mind of the team. These could be generated by simply connecting with each team member ahead of time and asking, “if you could only talk about one or two things this retro, what would it be?” If for example they responded “I want to talk about keeping our momentum”, you could create a question like “what would it take to keep our momentum going?”

Pulse Check – These are questions that are focused on people and engagement. Sometimes you would see similar questions on employee satisfaction surveys. An example question in this category could be “What tools and resources do we need to continue to be successful?”

Dreams and Worries – This is a longer-term view of the goals of the team. If the team has had any type of Lift Off or chartering exercise in the past, these would be questions connected to any goals and potential risks that have been previously identified. For example if one of a team’s goal is to ship product updates every 2 weeks, a question could be “What should we do next to get closer to shipping every 2 weeks?”

On the face-up side of the card it should indicate the question type as well as have room to write down any insights and actions.

You will also need:

  • To print out the game board
  • To print out the rule card
  • Bring a 6-sided dice

Playing the Game

Players sit on the floor or at a table around the game board. The cards are in 3 piles, grouped by type, with the questions face down.

therules

  • The person with the furthest birthday goes first.
  • It is their turn and they get to roll the dice.
  • They then choose a card from the pile based on the dice roll. A roll of 1 through 3 is an “In the Moment” card, 4 is a “Pulse Check” and 5 to 6 “Dreams & Worries”
  • They then read the card question on the card out loud and then pass the card to the person on the right.
    • The person on your right is the scribe, they will capture notes in the Insight and Actions boxes of the card for this round.
  • Once they have read the question, they have a chance to think and then answer the question out loud to the group. Nobody else gets to talk.
  • Once they’ve answered the question, others can provide their thoughts on the subject.
  • After 3 minutes, you may wish to move on to the next round.
  • At the end of each round the person whose turn it was chooses the person who listened and contributed to the discussion best. That person is given the card to keep.
  • The person to the left is given the dice and goes next.

Winning the Game

  • The game ends at 10 minutes prior to the end of the meeting.
  • At the end of the game, the person with the most cards wins!
  • The winner gets the bragging rights (and certificate) indicating they are the retrospective champion!
  • You should spend the last 10 minutes reflecting on the experience and organizing on the action items identified.

Concepts at Play

players-playing

Context & Reflection – Preparation is key, particularly for the “In the Moment” section. The topics will be relevant and connect with what the team wants to talk about. Also when presented in the form of a question they will likely trigger reflection for all those present.

Sharing the Voice – Everyone gets a chance to speak and be heard without interruptions. The game element also incentivises quality participation.

Coverage of topic areas – The 3 question categories spread the coverage across multiple areas, not just the items in the moment. The probabilities are not however equal, for example there is a 50% chance of “In the Moment” being chosen in each turn.

Fun & Safety – The game element encourages play and friendlier exchanges. You are likely to have dialogue over debate.

Want to play the game?

I’d love to hear how this game worked out for you. I’ve included everything you need here to setup your own game. Let me know how it went and how it could be improved!

Resources:
Retro Game – Game Board
Retro Game – Rules
Retro Game – Card Template
Retro Game – Champion Certificate

Martin aziz

Martin Aziz
Blog
@martinaziz
LoyaltyOne

 

Business vector designed by Freepik

 


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail