Tag Archives: agile

Learning the Value of Transparency Through Agile

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

 

Learning the Value of Transparency Through Agile

by Valerie Senyk

IMG_5461 (3)

I am intrigued by the principle of transparency which my employer, BERTEIG, models so beautifully.

When we have company (team) meetings, the owners practice complete transparency in regards to company finances, including profits and salaries. As we discuss various agenda items in our meetings, we are encouraged to be completely frank in order to make good team decisions. If personal issues are affecting a team member, he or she is respectfully listened to. If an employee needs time off, the need is not questioned. These are just some concrete examples of BERTEIG’s transparency.

Yet I don’t know how transparency is understood and practiced in other Agile environments or teams.

In the official Scrum website authored by Jeff Sutherland and Ken Schwaber (www.scrumguides.org), transparency is described as one of the three “pillars” of 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 build 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….The Scrum Team members have courage to do the right thing and work on tough problems….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.

From the above description, one understands that transparency exists along with other values such as commitment and courage, and that it is one of the necessary ingredients to building trust in a team.

Yet trust seems to be a deficient commodity in our times. There are so many reasons in everyday life to not trust, that trusting others becomes a challenge and perhaps even an obstacle.

The above site goes on to describe what is meant by transparency in a specific Scrum IT environment, which I believe is applicable in diverse organizations:

Significant aspects of the process must be visible to those responsible for the outcome. Transparency requires those aspects be defined by a common standard so observers share a common understanding of what is being seen.

For example:

  • Those performing the work and those accepting the work product must share a common definition of ‘Done’

Further in the same site there is a heading for “Artifact Transparency” which gets a little closer to the bone of understanding transparency’s importance:

Scrum relies on transparency. Decisions to optimize value and control risk are made based on the perceived state of the artifacts…To the extent that the artifacts are incompletely transparent, these decisions can be flawed, value may diminish and risk may increase.

The Scrum Master’s job is to work with the Scrum Team and the organization to increase the transparency of the artifacts. This work usually involves learning, convincing, and change. Transparency doesn’t occur overnight, but is a path.

 

What the above description does not include is corporate or personal transparency as practiced at BERTEIG. Transparency in an organization at the level the authors are talking about is impossible as long as a hierarchy exists whereby ascending the corporate ladder needs to be on the proven merits of things that a person has done instead of their attitude and willingness to walk a new path.

However, the above does make it clear that decisions will be sound, risk will be controlled, and value is optimized when transparency is practiced.

Overall, how do these ideas co-exist with the general Agile framework? From an article by Sameh Zeid on the Scrum Alliance website, he discusses six ways a product owner can increase transparency, then writes:

…without transparency we may not succeed in implementing Agile — and even if we can, the project can revert to command and control. Transparency implementation starts by leadership as represented by the product owner.

https://www.scrumalliance.org/community/articles/2013/june

There is a plethora of resources that one can access regarding Agile values and how to make it work. I believe transparency is a value that requires courage to begin with – courage which is facilitated by having an Agile culture.

BERTEIG is one company I know of that whole-heartedly practices transparency – – In fact, that element of “heart” may be exactly what’s needed in many organizations. It seems transparency can truly occur when there is caring between employer and employee.

How do you experience transparency, or lack of it, in your workplace? 

 


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

Announcement: BERTEIG is launching the first course of its kind in Canada!

Learn more about transforming people, process and culture with the Real Agility Program
The Certified Agile Leadership training is a new course. At the Orlando Scrum gathering the program was announced and shortly after, CSTs and CECs with strong leadership coaching background and formal education in this field were invited to apply to teach the class.
Michael Sahota - Profile Picture (2016)
Michael Sahota was one of these selected coaches.
The course is an acknowledgement that Agile transformation can only go so far if it is driven from the grassroots level, or without the full support of the leadership.
As a leader, they are driving a culture change in the organisation to get better results. This goes far beyond corporate mantras and motivational speeches. Participants can expext to learn the intracacies required of a leader to bring about lasting change.
The target audience is C-level executives, VPs and Senior Directors with decision making capability. The training is also for Change Agents who are catalysts in an organisation, who have the drive and willingness to make a difference.
Michael is known by the Scrum Alliance and since he has had taken formal non-Agile related Leadership training, his application was accepted making him the second global trainer to be approved after Pete Behrens (who is part of the creation committee of CAL) and another chap.
BERTEIG is honoured to be a part of this global launch of a brand new training and we look forward to the positive feedback from many more participants!
CAL1

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Four Awesome Agile Links

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

Agile_Axioms

What is agile exactly? How do we practice it? What does it look like to be an agile product owner? What is an agile team?

One of the qualities I’ve come to admire the most about agile teams and agile ambassadors is this continuous state of learning which everyone agrees to be in.

It seems as though “being agile” gives us permission to sometimes know an answer and sometimes not to. It gives us permission to sometimes understand a situation and have a solution and sometimes not to. Agile methods have a built-in “Reality Check” which is so refreshing.

By openly communicating often in retrospectives and by making work and backlog visible the process is taken out of the abstract and into the concrete. Agile seems to put everyone on the same page ~ even if people are coming at agile from very different angles.

Recently I posted a question to the 2500+ members of the Facebook Scrum group, asking for good recommendations for meaningful resources.

Here are the TOP Four Responses:

  1. The Stacey Matrix

2. 9 Things Every Product Manager Should Know

3. How Agile Are You?

4. Think Purpose

I’m interested to read your comments about any of these four articles or sites. What do you agree with? What do you disagree with?

What has been your biggest challenge and greatest success with implementing agile methods in your work environment?


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Skills Matrix for Launching Teams – Presentation

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

Here is the set of slides from my presentation on the use of the Skills Matrix to help launch Agile teams.  This was first presented at AgileTO in March 2016.

20160316 Agile TO Meetup – Skills Matrix [pdf]

And the video on YouTube:

 


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

High-Performance Teams: Where Does Trust Fit In?

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

Mobbing TeamAt a recent Agile Coach Camp I attended in June, a fellow participant said it best when he commented that as a software developer who had not really had an interest in people or relationships before, agile changed everything for him. He said Agile methods gave him a way to communicate with others, to trust them, and to understand how to work together to deliver excellent products.

What this gentleman was referring to, perhaps unknowingly, is one of the stages of team development. When an individual moves through stages of not trusting to trusting they are participating in an evolutionary process with a positive end result.

Daniela Moinau writes about this process in her article entitled, “High-performance Teams: Understanding Team Cohesiveness.”

She writes, “Once the storming stage is overcome the team is ready to establish open communications, stable positions and norms – the norming phase. Trust is finally gained, and “when the trust account is high, communication is easy, instant, and effective.” These are the first steps towards cohesiveness. Once cohesiveness is achieved, teams will move from norming to performing and subsequently to highly performing. ”

So while it may appear somewhat obvious that teams would trust one another, its not obvious to everyone. Each person carries their own unique history and their life experiences are of value. These experiences shaped who they are and what they have become. These experiences, whether pleasant or traumatic, shape a person’s ability to trust.

Agile methods to challenge teams to trust on a more profound level because of the nature of the values and principles which insist on it.

When a person, such as the software developer I mentioned in the first paragraph, overcomes his own internal patterns and learns to trust in a new way it leads to cohesiveness for him and his team. And this cohesiveness leads to high-performance.

As it turns out, trust is essential.


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

Are Agile Teams Just More Comfortable Being Uncomfortable?

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

Stretch Goals - failure can be disasterous

Lately I’ve been appreciating the Top 100 Agile Websites compiled by Oikosofy.

Just out of curiosity, I thought I’d check out Number 100, just to see who was the lucky guy who wasn’t listed as number 101.

What I found was a delightfully surprising and pleasantly entertaining blog by a coach named Yves Hanoulle. One article which particularly caught my attention is called “Getting out of your comfort zone.”

8 key points for coaches creating safety for their teams
  1. Getting out of your comfort zone is important for personal improvement  
  2. When you do experiements as a coach to learn people about this, people might see things differently, because of their earlier experiences.  
  3. Give people a safe environment so they can learn to push their boundaries.  
  4. People need to feel safe to move out of their comfort zone.  
  5. The Safety Zone is bigger then Comfort Zone.
  6.  Stepping out of your Comfort zone increases the size of Safety Zone.
  7.  Staying to long in your Comfort Zone decreases your safe zone.
  8. Safety zone is perceived.

His reflections after a training seminar on the topic really made a lot of sense to me.

Basically, an agile team is striving to create a Safe Zone for themselves and their team-mates so people will take risks and move out of their comfort zone. In order to do this, they are or become really comfortable with that uneasy state of being uncomfortable.

It’s as though it is no longer uncomfortable to be uncomfortable.

When an agile team moves out of its Comfort Zone together and everyone feels safe and supported, the end result is the type of team described in the Agile Manifesto. It’s the type of team companies really get excited about. It’s the type of team people love to work with and in doing so they may find they love their work more than ever.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Do Agile Teams ‘Storm’ In Different Ways?

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

Team Discussion

Agile transformation coaches promise their clients the positive outcome of “high-performance teams.”

According to the well-cited Psychologist B.W Tuchman, teams go through four stages on their way to high-performance. The end result seems to be a self-organizing team which effectively delivers to clients or customers with increasing satisfaction and continuous development and growth.

However, agile teams are different than regular teams. Aren’t they?

What I mean is, right from the outset individuals in an agile culture expect to confront change with positive stride. They are expected to be able to adapt to quickly even in uncertain environments. Therefore, their experience of team development is different, right from the outset.

Consider what Debbie Madden has to say in her article The Increasing Fluidity of Agile Practices Across Teams. She writes that, “most companies either claim they are Agile, are trying to become Agile, or have tried Agile. In truth, what I see today is a lot of customized Agile. In fact, the term “Traditional Agile” has come to mean the pure, original implementation of Agile. And, most companies are not following “Traditional Agile”. Instead, teams are customizing Agile to fit their needs, making the fluidity of Agile more prominent now than ever before.”

What this says to me is that since “Traditional Agile” has been around long enough now, teams have internalized the principles and values enough to understand change is to be expected and they have strategies in place to adapt well.

It says to me that teams are now taking Agile to a whole new level. They are making it their own. Adapting. Shaping. Moulding. Sculpting. The fluid nature of Agile gives teams permission to do this.

If we take Tuchman’s four-stage model and insert some agile thinking what we might come out with is an awareness that agile teams do what Debbie said they do. They make things up as they go along and they get the job done.

In this way, what might have been called “storming” by the old standards and definitions of team development can really also be called “high-performance” when the team is agile.

Perhaps some agile teams can create their own team development model and one of the stages is “high-performing storming” and maybe that is not even the final outcome but maybe it is the starting point on Day One!

Wouldn’t that be something?


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Article Review: Thinking About the Agile Manifesto

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

Often times, as I’ve been researching about agile methods and how to apply these to create real and sustainable change in an organization, I come across reference to the Agile Manifesto. I list it here today for those who are new to the field or who are getting back to the roots after trying a few things with different-than-expected results. It is an instrumental document. The values and principles listed here truly do shape the way agilists think and operate and to some degree or another the results appear to be better than before this founding document was introduced. So here is my “hats off” to this remarkable item which plays a pivotal role in cultural transformation.

The four key values are:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Personally, I find the first one the most meaningful of all. When we value individuals and interactions over process and tools we are truly improving in leaps and bounds in creating collaborative environments which are continuously improving.


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

Breaks Between Sprints Indicate a Problem

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

This post is a follow-up to an earlier article: There Are No Breaks Between Sprints.

Breaks between Sprints indicate a problem. Usually such breaks are filled with planning activities including research, requirements gathering, design & preparation, negotiations & approvals and the problem is threefold:

  1. Such plans are based on conjecture (risky and not compatible with Scrum) rather than empiricism (less risky and compatible with Scrum). Those activities are most beneficial when diligently performed by skilled inspectors at the point of the work. The four formal events within each Sprint provide the team and stakeholders adequate opportunity for inspection and ensure that decisions are being made in light of the up-to-date product increment and with respect to current user needs and market conditions.
  2. Breaks between Sprints often include activities which do not add value to the product or are entirely unrelated.
  3. Breaks between Sprints defer the delivery of value because the work performed does not result in potentially-releasable increment of “Done” product.

To correct this problem it is important to identify whether any of the effort spent between Sprints is adding value to the product — that is, which activities effect the form, fit, or function of the actual product. If determined to not be value adding, stop the activity entirely — it is waste. If determined to be value adding then the work ought to be part of their Sprints and the Scrum Team may decide that either the activity should be represented and ordered in the Product Backlog, or should be represented in the team’s Definition of Done.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Succeeding with your Agile Coach

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

 

I recently said goodbye to one of my organization’s Agile Coaches and I felt that I needed to take a pause and reflect to consider my next move. The engagement had gone well, in fact one of the best we’ve had, but not without its share of successes and failures. But the successes had clearly outpaced any failures, and so there was a lot of good I wanted to build on.

The departing coach was part of a 3rd generation of Agile Coaches that I had worked with in the 3 years since we had begun our company’s transformation to Agile. And while he was a great coach, so were his predecessors and yet they had had fewer successes.

On reflection, what had really happened is that we had changed as a company; we had learned how to better execute our engagements with an Agile Coach.

Deciding to hire an Agile Coach.

Deciding to hire an Agile Coach can be a big step. A couple of things need to have happened, you’ve recognized that you need some help or at least another perspective. And given that Agile Coaches are typically not very cheap, you have decided to invest in your Agile transformation, however big or small. You’re clearly taking it seriously.

However, through my experiences I noticed that things can get a little tricky once that decision has been made. Many organizations can fall into a trap of externalizing transformation responsibilities to the Agile Coach.

In essence thinking along the lines of “as long as I hire a good coach, they should be able to make our teams Agile” can take you into an engagement model that is not very Agile in the first place.

Much like how Scrum and other Agile Practices connect customers with teams and establishes shared risk, an organization’s relationship with their Agile Coaches need to be a working partnership.

Figure1

Positive Patterns for Coaching Engagements

So it’s important for you to setup the right engagement approach to get value out of your Agile Coach and this goes beyond the hard costs of their services, but also the high cost of failure with not having the right coaching in the right areas.

Here are 5 positive patterns for coaching engagements that I’ve observed:

1. Identify the Customer

Usually it is management who will hire a coach, and they may do so to help one or more teams with their Agile adoption needs. So in this scenario who is the customer? Is it the person that hired the coach or the teams (the coachees) who will be receiving the services? In some cases, the coachees aren’t clear why the coach is there, they haven’t asked for their services and in some cases may even feel threatened by their presence.

For this reason, if management is hiring coaches you need to recognize that there is a 3-pronged relationship that needs to be clearly established and maintained.

Figure2

With the customer in this case being someone in management, i.e. the person who hired the coach in the first place. The customer’s responsibility will be to not only identify the coachee but then work with the coach to establish and support that relationship.

2. Set the Mandate

Agile Coaches typically tend to be more effective when they have one or two specific mandates tied to an organization’s goals. Not only is the mandate important to establish why the coach is there, too many goals can significantly dilute the coach’s effectiveness. Put another way, Agile Coaches are not immune to exceeding their own Work in Progress limits.

The mandate establishes why the coach is there, and should be tied to some sort of organizational need. A good way of developing this is to articulate what is currently happening and the desired future state you want the coach to help with.

For example:

The teams on our new program are great at consistently delivering their features at the end of each sprint. However, we still experience significant delays merging and testing between teams in order for the program to ship a new release. We’d like to reduce that time significantly, hopefully by at least half.

Once the engagement is well underway you may find that the coach, through serendipity alone, is exposed to and gets involved with a wide variety of other areas. This is fine, but it’s best to just consider this to be a side show and not the main event. If other activities start to take on a life of their own, it’s probably a good time to go back to inspect and potentially adjust the mandate.

If you’re not sure how to establish or identify your Agile goals, this could be the first goal of any Agile coach you hire. In this scenario, the customer is also the coachee and the mandate is to get help establishing a mandate.

3. Hire the Coach that fits the need

Agile coaches are not a homogeneous group, with many degrees of specialty, perspective and experiences. Resist the desire to find a jack-of-all-trades, you’re as likely to find them as a unicorn.

Your now established mandate will be your biggest guide to what kind of coach you should be looking for. Is the need tied to technical practices, process engineering, team collaboration, executive buy-in, transforming your culture, etc?

The other part is connected with the identified coachee. Are the coachees team members, middle management or someone with a “C” in at the start of their title? Will mentoring be required or are you just here to teach something specific?

Using something like ACI’s Agile Coaching Competency Framework, would be a good model to match the competencies required of the perspective coach.

In my example earlier, in order for your team to get help with their merging & testing needs, you may have to look for a coach with the right skills within the Technical Mastery competence. And if you have technical leaders who are championing the change, potentially the ability to Mentor.

Figure3

4. Establish Feedback Loops

With the coach, customer and mandate clearly identified, you now need to be ready to devote your time to regularly connect and work with the coach. Formalizing some sort of cadence is necessary, if you leave it to ad hoc meetings you will typically not meet regularly enough and usually after some sort of failure has occurred.

The objective of these feedback loops is to tie together the communication lines between the 3 prongs established: the customer, the coach and the coachees. They should be framed in terms of reviewing progress against the goals established with the mandate. If the coachees ran any experiments or made any changes that were intended to get closer to the goals, this would be the time to reflect on them. If the coachees need something from the customer, this would be a good forum to review that need.

Figure4

Along with maintaining a cadence of communication, feedback loops if done regularly and consistently, could be used to replace deadlines, which in many cases are set simply a pressure mechanism to maintain urgency. So statements like “Merge & test time is to be reduced by half by Q2” now become “We need to reduce merge and test time by half and we will review our progress and adjust every 2 weeks.”

5. It doesn’t need to be Full Time

Resist the temptation to set the coach’s hours as a full-time embedded part of the organization or team. While you may want to have the coach spend a significant amount of time with you and your coachees when the engagement is starting, after this period you will likely get a lot more value from regular check-ins.

This could look like establishing some sort of rhythm with a coachee: reviewing challenges, then agreeing on changes and then coming back to review the results after sufficient time has passed.

This approach is more likely to keep the coach as a coach, and prevents the coach from becoming entangled in the delivery chain of the organization. The coach is there to help the coachees solve the problems, and not to become an active participant in their delivery.

Time to get to work

Bringing in an Agile Coach is an excellent and likely necessary part of unlocking your Agile transformation. However, a successful engagement with a coach will have you more connected and active with your transformation, not less. So consider these 5 positive coaching engagement patterns as I consider them moving into my 4th generation of Agile coaches. I expect it will be a lot of work, along with a steady stream of great results.

Martin aziz

Martin Aziz
Blog
@martinaziz
LoyaltyOne

 

 


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail