Category Archives: Scrum Master

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

David Sabine: What Real Agility Means To Me

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

Image

“Real Agility to me means being aware of and accepting of the present, in order to respond and chart new courses for the future,” David Sabine

My name is David Sabine. I’m a Real Agility Coach and have been thinking about what Real Agility means to me.

My introduction to Real Agility began in 2007 when the CTO of the college I was working at in Fort McMurray, Alberta brought in Mishkin Berteig as a third party consultant. Back then, I was a software developer and what I experienced then is still true today. The value of bringing in a third party to solve business challenges is immeasurable.

Time and time again, as I have been involved with companies, either in a training or a consulting capacity, I have found that a third party presence provides or creates a break-through. The purpose is not that I go to a company as a consultant and I bring my new ideas, as though I am the only one with new ideas.  What happens instead is that I visit a company and my presence, as a coach, opens the door for the internal staff to explore their own new thoughts, or concepts or possible solutions. So the ideas that are already in the company are just allowed to blossom a little bit in the presence of a third party,because this third party allows or creates a sense of permission, a sense of autonomy for those staff. They’ve been invited to explore concepts and they’ve been invited to think through their business problems from a different perspective and I am there just to reflect what they already have or what they already know.

That occurred when Mishkin Berteig visited the college in 2007, and that occurs every time I go and visit a company for training or consulting.

To really understand what Real Agility means to me, I’d like to tell you about how I came to software development in the first place beginning back in 1993 when I was starting university and was a freelance musician.

I had two passions at the time: the pursuit of music and the logic of programming. My computer tended to pay the bills, more so than being a freelance musician, so as a career path I guess I was drawn to software development and started to build my own products early on in 1996-1997. I was writing software for small business clients with the aim to eventually build a product on my own and release it for sale worldwide.

In 2000, I started to develop a product with a friend of mine. In 2001 we released it to other developers in the world. Our first sale of that product was in Belgium and for the next few years it sold worldwide. We had about 2000 websites that were using our product and it was translated into seven different languages by the community of users. It provided my friend and I with a reasonable income and a great opportunity. It was fun!

In 2006, I realized that my own growth as a computer scientist required working with others beyond this friend, to work in a team, in fact. I moved to Northern Alberta and worked in IT department for a college. As I mentioned, in 2007, the CTO, brought in Mishkin Berteig to provide us with a 3-day training course on Scrum. Quite immediately I loved it because I could see how it would provide us with a lot of opportunity to solve problems we were facing in an IT department and, secondly, it just seemed like a more human way to work. I was reflecting on all of these periods I had had as a musician, working with other musicians, and it just seemed like a better way to approach the creative endeavor than other project management methods that were in play at the time.

Since that time, I’ve been practicing them in a variety of settings and I’m more convinced now than ever that the Agile Manifesto provides us with a great solution space as we respond to business challenges. Recently I’ve decided not to be a developer or product owner but have decided to join Berteig full time and train and coach other teams.

So that’s the story of my personal evolution. My personal journey.

Looking back on that training I can see how I felt immediately that Real Agility was an alternative way of doing things.

I studied music since I was a child and music has always been a huge part of my life,and as a musician, one becomes aware of or familiar with continuous improvement. This is the same concept found in Real Agility. But with music it’s incremental, tiny, tiny increments of improvement over time. We respond to an audience. We respond in real time to our fellow musicians. We are always taking in input and that informs our performance of the music. As musicians, we spend a lot of personal time developing our craft. We spend significant time in performance so we can receive the audience feedback.

What I mean to say is that musicians are excellent examples of high performance teams and are excellent examples of creative excellence, who understand tactical excellence and what it means to get there.

When I joined Software development in a large, bureaucratic institution – the college – it was anything but natural for me. At that time, I was more than just a software developer. I was systems analyst, database admin and a variety of positions or roles. It just felt like an industrialized, mechanical environment where people were expected to behave as interchangeable units of skill. Work was expected to get done in the prescribed procedure. And decisions were expected only to be made by the smartest or the highest paid few and if you weren’t of that ilk, you were not expected to behave autonomously. You were expected to be just part of the machine and it felt very inhuman, as most people feel as a part of a large hierarchical bureaucracy.

When Mishkin facilitated the Certified Scrum Master training course in 2007, it just blew all those doors open. It reminded me that we can approach our work the way I had naturally approached it, as a creative individual who is capable of learning and wants to receive immediate feedback from audience or user, and who can make autonomous decisions about how to apply that feedback into the continuous development of software and systems and large infrastructure.

These business challenges are pretty common. They are delayed projects or projects that that blow the budget, or where a group of people are assigned to the project and they can’t possibly complete the scope of work in the time given. Or staff are demoralized, and how that expands through enterprises. There are many examples. The college where I was working suffered all of the most common issues and the one that hurt me the most or I felt the most was attrition. Dis-engaged staff. The reason for it was simple. The college had not presented with them a purpose or opportunity to be masterful. The extrinsic motivators, salaries and such, were just enough to keep people for a little while and then they would leave. And so the college at the time was experiencing attrition of 35-40% per year and that’s what I meant by inhuman.

“These Real Agility methods presented a change. In fact, people become centric to the purpose!”

When I read the Agile Manifesto I think that it provides us with solutions, and so if our current business problem or business circumstance is that we have disengaged staff who aren’t very productive and aren’t getting along well, then the Agile Manifesto reminds us that perhaps business people and developers can work daily throughout the project together. They can have continual interaction, and then individuals and their interactions become more valuable than the process and the organizational tools that have been put in their way. It reminds us that people should be allowed to work at a sustainable pace. We should build projects around motivated individuals. And that poses questions about how to do those things. What does it mean to be motivated, and how do we build projects around motivated people?

So Agile Manifesto presents us with some challenges, as a mental process, and then when we work through that we understand how it can inform good decisions about how to solve business problems.

Real Agility to me means being aware of and accepting of the present, in order to respond and chart new courses for the future.”

In other words, Agility means being nimble, the ability to adapt to current circumstance, but more than that, Real Agility means that we should approach our work with the intention that we stay light-weight so that when our circumstances change we can adapt without a lot of inertial resistance. So there’s two components there. One is being able to adapt quickly, and being aware of present circumstance but the other is that we don’t want to take on weight and institutional mass, because that’s inertia, the status quo.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Mishkin Berteig explains Real Agility

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

This video introduces some key features to the thinking behind real agility.

80 % = 90% of money and resources in an organization is going to waste and only 10% – 20% goes to productive, valuable work.

Real agility helps to solve this problem by creating a state where the amount of waste is reduced and the about of productivity is increased.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Agile Advice: Start Executing With Little Planning

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

Agile Planning

“Start executing and worry less about planning.” QA Consultant

This statement appeared on a recent feedback form after a BERTEIG learning event. It summarized a Quality Assurance Consultant’s learning from the CSM training they attended.

This statement so accurately summarizes one of the key principles of agile methodology which is to do minimal planning and review often. It doesn’t mean “No Planning” it just means different kinds of planning and the willingness to jump quickly into action.

Mishkin published an article on this topic in 2015  and it is re-posted here now because it is still so relevant today.

 

Agile Planning in a Nutshell

Mishkin Berteig 201504 white background - 640w

 

 

 

By Mishkin Berteig

Agile methods such as Scrum, Kanban and OpenAgile do not require long-term up-front plans.  However, many teams desire a long-term plan.  This can be thought of as a roadmap or schedule or a release plan.  Agile planning helps us build and maintain long-term plans.

Agile Planning Process

The steps to do this are actually very simple:

  1. Write down all the work to be done.  In Scrum these are called “Product Backlog Items”, in Kanban “Tasks” and in OpenAgile “Value Drivers”.
  2. Do some estimation of the work items.  Many Agile estimation techniques exist including Planning PokerThe Bucket SystemDot VotingT-Shirt Sizes.  These tools can be applied to many types of estimation.  There are three kinds of estimation that are important for Agile Planning:
    1. Estimating relative business value.  Usually done with the business people including customers and users.
    2. Estimating relative effort.  Usually done by the Agile team that will deliver the work.
    3. Estimating team capacity.  Also done by the Agile team (this is sometimes called “velocity”).
  3. Create the long-term plan.  Use the team capacity estimate and the sum of all the effort estimates to come up with an estimate of the overall time required to do the work.  (In Kanban, which doesn’t have an iterative approach, this is a bit more complicated.)  Use the business value and effort estimates to determine relative return on investment as a way to put work items in a logical sequence.

Agile planning allows a team to update estimates at any time.  Therefore, the techniques used above should not be thought of as a strict sequence.  Instead, as the team and the business people learn, the estimates and long-term plan can be easily updated.  Scrum refers to this ongoing process at “Product Backlog Refinement”.

Principles of Agile Planning

In order to use Agile planning effectively, people must be aware of and support the principles of Agile planning:

  1. Speed over accuracy.  We don’t want to waste time on planning!  Planning in and of itself does not deliver value.  Instead, get planning done fast and use the actual delivery of your Agile team to adjust plans as you go.
  2. Collaborative techniques.  We don’t want to be able to blame individuals if something goes wrong.  Instead, we create safe estimation and planning techniques.  Inevitably, when an estimate turns out to be wrong, it is impossible to blame a single individual for a “mistake”.
  3. Relative units.  We don’t try to estimate and plan based on “real” units such as dollars or hours.  Instead, we use ordering, relative estimation and other relative techniques to compare between options.  Humans are bad at estimating in absolute units.  We are much better at relative estimation and planning.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Quotable Quote: Scrum Master has authority over the process but not over the team

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

Jerry Doucett 201601 white background - head - 275 squareHaving 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. (By Senior Agile Coach Jerry Doucett)


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Link: How To Manage the “I’m the bestest” persons in Agile

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

therules

Can you believe there is an actual disorder which prevents people from seeing their own limits? It makes them over-cofindent to do things and yet under-skilled to achieve them. If you have a person with a disorder like this on your team, it can lead to disaster.

But you likely are not aware of what exactly is going on. Not until it’s too late.

You can read for yourself the nature of this condition and how a Scrum Master can help a person who perpetually under-estimates or over-estimates their capacities.

It’s called The Dunning-Kruger effect and here is the article entitled, “How to manage the “I’m the bestest” persons in Agile – The Dunning-Kruger effect.

What I like so much about this article is that despite the challenges of working with someone who is largely unaware of what they don’t know, is that the author offers encouragement to Scrum Masters.

Basically, a scrum team turns no one away. We are all capable of some degree of contributing. This article shows that the more a Scrum Master knows the individual team members and the collective capacity of the whole team, the better everyone can be!


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

Mishkin Berteig’s 13 Myths of Scrum

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

Mishkin Berteig dispels myths in some of the most challenging aspects of Scrum.

Have you been in a team where the ScrumMaster was also a Project Manager? Did you know that’s not really the role of a Scrum Master?

Or have you been participating in retrospectives which were public? Did you know they are not supposed to be?

The thirteen concepts addressed here bringing clarity and insight to Scrum Masters, Product Owners and team members.

These key principles of Scrum, when practiced regularly, improve the effectiveness of any team.

Learning a new way takes time but when the principles are clear it is easier to adopt them and implement them with focus and success.


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

Announcement: New Upgrades to The Scrum Team Assessment!

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

MeetScrum

For those who are not familiar, The Scrum Team Assessment is your virtual Scrum coach!  Using this simple assessment, you can find out how your team is doing and ways to improve.

Recently, new upgrades have been added to the Scrum Team Assessment and it is available for use free of charge for a limited time.

The features of the Scrum Team Assessment include:

  1. Scrum Scoring – How well your team is using Scrum;
    This includes measurement of the general process, the Product Backlog, the teamwork, and effectiveness of the ScrumMaster and Product Owner.
  2. Quick Wins – High impact ways to improve right now;
    The parts of Scrum you aren’t doing well that if you improve will give you the best return on your effort investment.  Specific, practical, applicable to your team right now!
  3. Long Term Recommendations – Sustaining high-performance;
    This is the harder stuff that involves the team’s environment, culture and processes and which can make a huge difference in the long term… but requires some up-front effort.  Practical suggestions to explore the creation of a high-performance Scrum team.
  4. Financial Benefits – The bottom line for the team;
    How much money is your organization wasting on poor performance, and how much can be saved by following the recommendations in the report.  Eye-opening, and the perfect motivation for management support of improvements.
  5. Industry Comparison – How your team is doing compares to others;
    Compare your team to other teams that have participated in the Scrum Team Assessment.  This comparison gets better and better as more teams use the Scrum Team Assessment.
  6. Recommended Resources – Tailored to your team.
    Books, articles, products, training and other services that will help your team rapidly improve.

Read more about the Scrum Team Assessment and try it for your team!


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

ScrumMaster or Armchair Psychologist? – Notes from a Webinar by Angela Johnson

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

Valerie Senyk

March 9, 2016, I took advantage of a free webinar offered by the Scrum Alliance, with the above title. We were told 5,000 people were attending! Angela Johnson’s presentation was based on information from both the Scrum and psychology communities.

First, she reiterated many ideas that are commonly understood about the role of a ScrumMaster (SM): an internal coach, a servant leader, an active facilitator. The SM makes sure that the rules of Scrum are followed by a team, but focuses on interactions and outcomes. As in football, the SM is truly a coach.

She described how new SM’s often latch onto the mechanics of Scrum, but most important are the personal interactions of a team. When difficulties arise, it is important to ask: “Do we have a Scrum problem, or is it a people problem?”

Ms. Johnson cited two resources available to SM’s to understand people interactions and problems better. One is the previous publication by Dale Carnegie called “How to Win Friends and Influence People.” The other is a newer resource by Michael James available online as scrummasterchecklist.org. In it James covers ideas like “How is my team doing?…How is the product owner doing?…etc”

She also cited a fascinating book by Harvey Robbins and Michael Finley called “’The New’ Why Teams Don’t Work.” She spoke about the importance of goals and objectives for a team. Bad Teams have vague goals and objectives. Good Teams may have clearer goals and engage in barrier identification. But the Best Teams have clear, short-term goals with continuous high-priority goals and objectives in segments of 30 days or less; they also identify barriers to people and processes. Best Teams ultimately value differences among team members, and develop something she called “versatility plans in interpersonal relationships.” (I wanted to learn more about this idea and posed a question in the webinar which unfortunately went unanswered.)

She then turned to psychology to discuss behavioral style differences in people. Four distinct personality types were explored: the Analytical (asks how?), the Driver (asks what?), the Amiable (asks who?) and the Expressive (asks why?). She believes a SM might help team members identify which personality quadrant they belong in so as to better understand each other. As well, in knowing the type of people who are in his/her team, a SM could adjust his/her communication and behavior to better reach each type.

I think it would be an interesting exercise for a team to go through personality types at least once. The exercise itself, besides creating deeper understanding, could also lead to some “aha” moments and laughter.

Johnson went through a checklist of Harvey Robbins’ rules for building trust in a team or group of people, and I will list them here:

  • have clear, consistent goals

  • be open, fair, and willing to listen

  • be decisive (meet the definition of Done)

  • support all other team members

  • give credit to team members when due

  • be sensitive to the needs of members

  • respect others’ opinions

  • empower team members to act

  • adopt a “we” mentality

  • take responsibility for team actions

She then added tips about supporting versatility: a)  you can only create an environment that encourages self-motivation rather than motivate others directly; b) assist people  to interpret what you say, i.e. “What I’m about to say is to help…etc;” c)  don’t overlook a variety of orientations, whether they are cultural, or gender-based. She advised that we need to be aware that orientation is very important to consider as the teams we work with have a greater number of people whose first language is not English.

She spoke about Scrum teams working within larger organizations. If the goal of Scrum is to produce greater value more quickly, then a SM should never have his/her attention split between more than one team. The SM has to be a teacher inside of an organization, to help management understand best practices – the SM is really the coach for a team, the Product Owner and the organization. Old habits die hard, so educating takes time.

Don’t allow language to get in the way of this process. Don’t say: “That’s not Agile! That’s not Scrum! You’re doing it wrong!” Instead say, “When you say Agile, what do you mean?” or, “What is the problem we’re trying to solve?” A SM can always point out that we have a choice to work in the old way, or to try something new. We have an opportunity to improve the way we work.

Agile and Scrum, she emphasized, are not destinations – they are about continuous improvement.

This summarizes just some of the valuable ideas Angela Johnson presented.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail