Category Archives: Uncategorized

Finding Compassion – Lessons Learned From My Street

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

It may be a cliche to be talking about “Compassion” in the workplace, as it is a “concept” that has been addressed multiple times over many years.

Frankly, it is difficult to actually put into practice. And for me, it was something I explored, adopted, and then ignored, over the past number of decades as real-world priorities shifted.

But I want to share a very personal story that unfolded just today. Bear with me on this, as I will relate this personal situation to the workplace interactions we’ve all likely experienced.

My neighbour is a struggling single mother to whom I genuinely want to succeed, as she is a dedicated mother and a hard worker. However, she recently took a very base-level approach to an emotional situation that affects many people within my neighbourhood.

In short, her dog has behavioural issues which have lead to attacks and mock-attacks upon myself, my family, local contractors, and fellow neighbours. Latitude has been given to her in each instance as she has made earnest efforts to curb this behaviour, but for the most part, she has had marginal success. Most recently the dog actually attacked a local boy, who spent 3 days in hospital as a result.

Clearly, the issue with the “dog in the room” needed to be escalated and dealt with. The injured boy’s father rightly requested that a muzzle order be put in place: an order that has subsequently been appealed by the owner.

Think about this for a moment.

The position of the dog owner just changed, from “I am making earnest efforts” to “my dog is not the problem. You are the problem”.

Why?

Well, there’s been a trigger event and it’s because of a strong emotional connection to her dog. To justify this, she has created a “story” about all the people that are involved in this situation: the young boy in the hospital “provoked” the dog. The “dog doesn’t have the problem, everyone else does, and it’s all lies”. My personal situation in which I had to physically defend my family from the aggressiveness of this loose dog “never happened”. And of course the contractor who locked himself in a room until she came home……. well, you get the point.

It is very easy for me, as a professional who is accustomed to teams, and boardrooms, proper process, HR, and mature interactions that move business forward, to look at her position as an immature and flailing attempt to justify a deeper need. An  emotional need to protect the love she has for this dog and what the dog represents as part of her family.

Relating this to business, I’ve met people who have acted much like her in the workplace. The same story of innocence the dog owner positions, is often found in the boardroom! The questions are why, and secondly, do such people tend to remain in their position or do they get moved along?

They survive. While they may be unskilled and unready to address the actual deep personal issue driving their behaviour, they often position themselves in a very innocent light, and they tend to point out those “liars” around them.

The light went off for me when I found myself emotionally wrapped up in being called a liar by a person who was clearly to blame. How do you defend yourself with your “team skills” and “boardroom skills” against a person with “street skills”?

That is where I found Compassion.

As in situations with my co-workers, colleagues, clients and friends, I realized that this single mother is just trying to provide her son with a home, an education, a pet to call his own, and in between, cut the noise in her life, and find her own sense of happiness while shouldering 100% of the burden.

Moving this concept to the workplace, could it be that a percentage of your colleagues who sometimes leave you scratching your head, have some well-developed “street skills”?

After today I do believe it begins with you – not them – just as this personal revelation with the neighbour began with me.

In the end, the injured son’s father expertly resolved this emotional powder-keg: and I learned it’s not about defending against the accusations, it’s doing exactly what this father did.

He listened to all parties with genuine interest and curiosity. He asked neutral-based questions, keeping his emotions in check. He did not take the accusations personally. He sought answers and he sought consensus. He asked for timelines and process. He often asked for help, and sometimes he had to escalate (i.e. getting a muzzle order) where he needed. But he exercised Compassion at every step.

I learned that defending myself against accusations is not the name of the game: it’s about taking the father’s approach. His Compassion renewed Compassion in me.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

What Kanban Is (And Isn’t)

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

The Kanban Method is a management method for…

  • Directly improving service delivery
  • Catalyzing improvements
  • Evolving a business to be fit for purpose

The Kanban Method is not…

  • A project management method
  • A software development lifecycle process.

Your organization is an ecosystem of interdependent services—a complex, adaptive system. You introduce a Kanban system into it such that the complex system is stimulated improvement. – Alexei Zheglov

This wikipedia entry provides a fairly accurate description of the Kanban Method:

https://en.wikipedia.org/wiki/Kanban_(development)

The Kanban Method has 3 Agendas:

  1. Survivability  (of the business, for business executives)
  2. Service-orientation (for all levels of management)
  3. Sustainability (for professional services knowledge workers)

The Kanban Method has 9 values:

  1. Customer focus
  2. Transparency
  3. Understanding
  4. Agreement
  5. Leadership
  6. Respect
  7. Collaboration
  8. Balance
  9. Flow

The Kanban Method has 6 principles; 3 change management principles and 3 service delivery principles.

Change Management Principles:

  1. Start with what you do now.
  2. Agree to pursue improvement through evolutionary change.
  3. Encourage acts of leadership at all levels.

Service Delivery Principles:

  1. Understand & focus on customer needs and expectations.
  2. Manage the work, let people self-organize around it.
  3. Policies govern service delivery.

The Kanban Method has 6 practices:

  1. Visualize
  2. Limit WIP
  3. Manage flow
  4. Make policies explicit
  5. Feedback loops
  6. Improve & evolve

LeanKanban Inc. is the authority on the Kanban Method. LeanKanban University is the accredited training organization of LeanKanban Inc.

David J. Anderson is the founder of the Kanban Method.

Travis Birch is an Accredited Kanban Trainer with LeanKanban University. You can sign up for his upcoming public Kanban courses in December 2017 at Berteig World Mindware.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

What if no one was forced to do Scrum?

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

I just commented on a LinkedIn thread about “Sprint Zero”. It occurred to me that Sprint Zero is often used as one of many coping mechanisms for people who are forced to do Scrum. It also occurred to me that in my 9 years or so working with a reliable sample size of Scrum teams, not one of those teams was populated entirely by people who were not coerced into doing Scrum.

Gut check: The percentage of people I know who are currently on Scrum teams and who would be doing Scrum if it wasn’t mandated by management could be lower than 50%. This begs the questions: What if Scrum was offered to teams as an optional way to manage their own work? Would there be less Scrum in the world?

With one exception, all of the Scrum teams I have worked with were mandated (forced) by management to implement Scrum. The exceptional team was exceptional in other ways. They were by far the happiest and most revolutionary (in terms of recognition for business success in their organization). Although one or two hesitant team members were roped in by their peers, the social climate of the team allowed the wary to adapt safely and gradually to their new reality.

For the overwhelming majority (in my experience), there is an irony, even a paradox at play. A lot has been said & written about how command and control management is antithetical to Scrum. Yet, many—if not most—Scrum adoptions are commanded by management with vanity metrics (i.e. velocity) installed to uphold the illusion of control.

What are some of the other coping mechanisms for people who are forced to do Scrum? What is driving this behaviour? How many of these behaviours have been labelled as “anti-patterns” and why?

Safety is an essential success factor for any organization. Is it safe for people to choose to not do Scrum, or express dissent about Scrum adoption in their organization? What does this tell us about Scrum itself? Does Scrum need to be reimagined or reframed in order to make Scrum adoption safer for more people? Is it safe to do so?


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Kanban: Real Scaled Agility for Your Enterprise

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

Your business is an ecosystem of interdependent services, a complex adaptive system.

A bunch of organizations I know started their journey of increasing their agility with Scrum. That didn’t solve all of their problems. Kanban enables organizations to evolve their service delivery systems towards mature business agility.

As addressed in How Kanban Saved Agile, pure Scrum is extremely rare. Scrumbut (the disparaging label that spawned from so many organizations reporting that they do Scrum, but…) on the other hand, is extremely common.

In order to not be Scrumbut, you need the following:
  • Cross-functional development team of 7 +/- 2 people—ALL skills needed to ship product is present on the team—there are no dependencies external to the team;
  • One source of demand with no capacity constraints—the Product Owner is the customer AND full-time member of the team;
  • Sprints are one month or less, begin with starting new demand from the Product Owner and end with the delivery of potentially shippable Product Increments, followed by a retrospective about how to do better next Sprint;
  • “Potentially Shippable” means that the decision about whether to actually ship is purely a business decision. All the technical work is done;
  • If all of the technical work required in order to ship isn’t done, then the Sprint is a failed Sprint;
  • The Scrum Master is a servant-leader and Scrum educator to the entire organization.

How many organizations do you know of with Scrum teams that meet all of the requirements above? I don’t know one.

So, what’s the solution? Give up on Scrum? Are we still getting benefits from Scrumbut? Alright, let’s stop it with the Scrumbut already. Let’s acknowledge what’s really going with real teams in the real world and call that Scrum. Let’s refer to the above  checklist as “Ideal Scrum”.

Agile scaling methods have become a popular risk hedging tactic for all the loose ends dangling around the real teams in the real world.

Here are some of the reasons for adding layers of scaling around Agile teams:

  • Teams are not fully cross-functional;
  • Teams have external and opaque depencies;
  • Many of these dependencies are shared services with multiple sources of demand and constrained capacity—often overburdened;
  • External dependencies can be other teams—demand from other teams shows up in their backlogs, prioritized by their own Product Owners;
  • Many dependencies don’t play by the same rules at all—some reside in a different part of the organization, with different structures and political forces;
  • The Product Owners are proxies for multiple stakeholders and customers and the Product Backlogs represent an array of multiple sources of demand, with different service level expectations, strategic origins, degrees of clarity, urgency and political forces pushing them into the deliver organization;
  • The Product Backlogs are made up primarily of solutions defined by stakeholders and translated by the pseudo-Product Owners as pseudo-user stories—how they get there is opaque, the “fuzzy front end”—and somewhere in here a fuzzy delivery commitment was already made;
  • The work of a Sprint includes all of the work that the non-cross-functional teams can get done—then whatever the teams get “done” is “delivered” (handed-off) to a subsequent set of teams or process steps (usually fairly well defined at an organizational level but outside of the teams’ influence);
  • Delivery decisions are made based on constraints imposed by legacy technology, systems and their gatekeepers (for historically good reasons);
  • The teams are “done” at the end of each Sprint, yet much work is still to be done before their “done” work is potentially shippable;
  • The Scrum Master’s are held collectively accountable for the collective deliverables of the teams and their ability to cross-team coordinate and integrate—accountability by committee translates into no one is actually responsible.
  • Middle managers are scrambling to pick up the pieces because they are actually accountable for delivered results.

Generally speaking, the aim of Agile scaling methods is to apply larger Agile wrappers around clusters of Agile teams in order to re-establish some kind of hierarchical structure needed to manage the interdependencies described above. Whether its a Release Train or a Nexus, or whatever else, the idea is that there is an “Agile Team of Teams” managing the interdependencies of multiple, smaller teams. As long as the total number of people doesn’t grow beyond the Dunbar number (~150), the Dunbar-sized group is dedicated and cross-functional, there is a team managing the interdependencies within the Dunbar, there are no dependencies outside of the Dunbar and there is some cadence (1-3 months) of integrated delivery—it’s still “Agile”. All of this scaling out as far as a Dunbar (and only that far) allows the enterprise to still “be Agile”—Scaled Agile.

This is all supposed to be somehow more realistic than Ideal Scrum (with perhaps am overlay of Scrum of Scrums and a Scrum of Scrum of Scrums). It’s not. How many organizations do you know of that can afford to have ~150 people 100% dedicated to a single product? Perhaps today there is enough cash lying around, but soon enough the  economic impact will be untenable, if not unsustainable.

How does Kanban address this problem? Your business is a complex adaptive system. You introduce a Kanban system into it such that it is likely that the complex adaptive system is stimulated to improve. The Systems Thinking Approach to Introducing Kanban—STATIK—is how you can make such a transition more successful (@az1):
  1. Understand the purpose of the system—explicitly identify the services you provide, to whom you provide them and why;
  2. Understand the things about the delivery of the service that people are not happy about today—both those whose needs are addressed by the service and those doing the work of delivering the service;
  3. Define the sources of demand—what your customers care about and why;
  4. Describe the capability of your system to satisfy these demands;
  5. Map the workflow of items of customer-recognizable value (@fer_cuenca), beginning with a known customer need and ending with the need being met through stages of primary knowledge discovery (Scrum teams somewhere in the middle, towards the end)—focus on activities, not looping value streams;
  6. Discover classes of service—there are patterns to how different kinds of work flow through your system (they are not arbitrarily decided by pseudo-Product Owners), what are they? Group them, they are classes of service and knowing them enables powerful risk management;
  7. With all of the above as an input, design the Kanban system for the service;
  8. Learn how to do steps 2-7 and start applying it directly to your own context in a Kanban System Design class;
  9. Socialize and rollout (learn how by participating in a Kanban Coaching Professional Masterclass);
  10. Implement feedback-loop Cadences for continuous evolution—learn the 7 Kanban Cadences and begin applying to your own context in a Kanban Management Professional class;
  11. Repeat with all of the interdependent services in your organization—every “dependency” is a service—Kanban all of them with STATIK and begin implementing the Cadences.

Don’t get hung up on teams, roles, your latest reorg, how people will
respond to another “change”, who’s in, who’s out, etc. These are all part of the service as it is now—your current capability. Initially, no changes are required at this level. The kanban system will operate at a higher level of scale. Through feedback-loop cadences, it will evolve to be fit for the purpose of your customers without a traumatic and expensive reorg.  Who is responsible for this? Identify this person. If you are the one thinking about this problem, there is a good chance that it’s you. Whoever it is, this is the manager of the service; take responsibility, do the work and make life better for everyone.

For more information about LeanKanban University Certified Kanban courses provided by Berteig, please go to www.worldmindware.com/kanban. Some spots are still available for our classes in Toronto, June 12-16.

For Agilists who have read this far and still don’t get it, start here:

14 Things Every Agilist Should Know About Kanban

The story below may be familiar to some:

Our IT group started with Scrum. Scores of people got trained. Most of our Project Managers became “Certified” Scrum Masters. Most of our Business Analysts became “Certified” Product Owners. We purged some people who we knew would never make the transition. We reorganized everyone else into cross-functional teams – mostly developers and testers. But now they are Scrum Developers. We tried to send them for “Certified” Scrum Developer training but hardly anyone of them signed up. So they are Just Scrum Developers. But we still call them developers and testers. Because that’s still how they mostly function—silos within “cross functional teams”, many tales of two cities rather than just one.

After the Scrum teams had been up and running for a while and we were able to establish some metrics to show the business how Agile we were (since they didn’t believe us based on business results), we had a really great dashboard showing us how many Scrum teams we had, how many Kanban teams, how many DevOps, how many people had been trained. We even knew the average story point velocity of each team.

The business didn’t get it. They were worried that Agile wasn’t going to solve their problem of making commitments to customers and looking bad because we still weren’t able to deliver “on time”.

As IT leadership, we were really in the hot seat. We started to talk about why the transformation wasn’t going as it should. We knew better than to bring the Agile coaches into the boardroom. They were part of the problem and needed to be kept at arms length from those of us who were making important decisions. Besides, their Zen talk about “why?” was really getting old fast. Some thought it was because we didn’t have the right technology. Others were convinced it was because we didn’t have the right people. After all, we didn’t go out and higher experienced (above-average) Scrum Masters and Product Owners, instead we just retrained our own people. Clearly that wasn’t working.

We started with improving the Scrum Masters. We went out and hired a few with impressive resumes. We developed some Scrum Master KPIs (HR jumped all over this one). Then one day we had a collective flash of brilliance—since the ScrumMasters are the servant leaders of teams, we will make them responsible for collecting and reporting team metrics and this will tell us how well the teams are doing and how they need to improve. This surely would be the key to improving the performance of IT and get us on a better footing with the business.

But we didn’t get the response we were hoping for. The ScrumMasters soon complained that the metrics of the teams were impacted by dependencies that they had no influence over. When we pushed harder and shamed them publicly for failing to produce meaningful metrics, they tried harder, but they weren’t able to do it. Some began disengage. “This is not the job I signed up for” became their new mantra. This was puzzling. We were empowering them and they were recoiling. Maybe we didn’t get the right Scrum Masters after all. Maybe we needed to go out and find people who could think and act effectively beyond the confines of their own teams. Or…


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

The Soft Skills Revolution: Why You May Want Team Development

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

If you go on line and type “soft skills” into your browser, you will come up with a plethora of sites. That’s because soft skills are being touted as the most important skill set for any individual in any career. Soft skills are becoming de rigeur in job applications and leadership training of every kind. One might say that there is, in fact, a soft skills revolution occurring in every sector of society.

What is motivating this revolution? Perhaps the more automated our world becomes, we see that our more human characteristics and relationships are needed to balance such a high degree of automation. Perhaps it’s become clear that human characteristics are what drive everything forward in either a positive or negative fashion.

Wikipedia describes soft skills in this way:

Soft skills are a combination of interpersonal people skills, social skills, communication skills, character traits, attitudes, career attributes, [1] social intelligence and emotional intelligence quotients among others that enable people to effectively navigate their environment, work well with others, perform well, and achieve their goals with complementing hard skills. [2]

By another definition, soft skills are those skills that are difficult to measure.

With the advent of the Agile Manifesto (www.agilemanifesto.com) and agile processes permeating business and organizational cultures more and more, people are abandoning the silo mentality and striving to create a more communal environment and team consciousness. Many organizations and businesses are learning that teams rather than individuals are more effective at accomplishing goals.

When a team of people have to work together, there is an expectation that they will all do their best to get a job done. On the other hand, it’s also normal for people on a team to encounter hiccups and even conflicts, whether it’s issues of personality, ego or disagreements of one kind or another. Then there are those team members who do not feel safe to offer their opinion, or those who harbor a prejudice against a certain type of person they may be required to work with.

By putting people together to work alongside each other day after day, we are creating a potent mix. Human beings are extremely complex and diverse after all. There are volumes written about both the need for and the difficulty of people working and achieving together.

From a recent Insight BTOES newsletter about hiring practices:

If they’re the best there is in their craft but would prefer to just do their job and be left alone, it isn’t likely they’ll engage in team improvement activities and become a contributing part of the new culture. It’s simply not worth taking on the resistance/non-engagement that you’ll have to deal with until your patience runs out and you’re right back where you started…”

http://insights.btoes.com/hard-skills-or-soft-skills-more-important-leadership-culture-transformation

Many corporations now claim that soft skills are the number one priority when hiring, Hard skills can be easily taught but soft skills make the difference whether a person is even teachable and flexible enough for a corporate environment.

This is just the tip of the iceberg, because soft skills have not been the focus of our education systems, and those who have them need continuous practice and improvement. But everyone has the potential to become more empathetic, cooperative, supportive, and respectful.

Whether it’s learning to communicate effectively, or to create a sense of cohesion in a team, there are many pieces that can be put in place to help any team (and its individual parts) be more powerful, effectual and happy.

One very basic ingredient that can make a world of difference to a team’s work is to feel safe. Safety comes with having clear and consistent goals. Team members feel safe to speak his or her mind without fear or judgement, even if their opinion is different from others. A team feels safe to experiment and to succeed or fail. Safety is built on the very essential idea of trust.

Psychologist, author and consultant Harvey Robbins has written extensively about the idea of trust as a key element of any team. He describes trust as follows:

· Trust means setting clear, consistent goals. If people don’t know exactly what they’re supposed to, they will feel set up to fail…

· Trust means being open, fair, and willing to listen. This requires more than making a thoughtful, considerate face. It means listening to the words other people are saying.

· Trust means being decisive… It’s a challenging thing to say, but sometimes it’s better to make any decision – good, bad, or indifferent – than it is to make no decision at all.

· Trust means supporting one another…Your team belong to you, and you belong to them.

· Trust means sharing credit with team members. You are there for them, not vice versa. If you are a glory hog, you are stealing from the team.

· Trust means being sensitive to team members’ needs. You should know what legitimate secondary agendas they may have, and be willing to help them achieve their personal goals.

· Trust means respecting the opinions of others. The worst thing a leader can do is denigrate or dismiss or ignore team members. If they’re no good, move them off the team. But even then you owe them your respect.

· Trust means empowering team members to act. It means trusting that they are up to the challenges that you trained them for…

· Finally, and ultimately, and most difficultly, trust means being willing to suffer… The ordinary leader exposes his people to all the risk. The trusted leader assumes risk himself.

Article Source: http://EzineArticles.com/716760

When a team has clearly articulated goals, it helps build a sense of cohesion, in that every member is aware of what they are working toward. When team members are allowed to work out an action plan toward achieving a goal, this gives everyone a stronger sense of purpose and ownership.

If you’re wondering whether a Team Development workshop would be of benefit to, or is necessary for your business or organization, here are some thoughts from MindTools that can help you decide:

  • Are there conflicts between certain people that are creating divisions within the team?
  • Do team members need to get to know one another?
  • Do some members focus on their own success, and harm the group as a result?
  • Does poor communication slow the group’s progress?
  • Do people need to learn how to work together, instead of individually?
  • Are some members resistant to change, and does this affect the group’s ability to move forward?
  • Do members of the group need a boost to their morale?”

https://www.mindtools.com/pages/article/newTMM_52.htm

Everyone has the potential to grow their soft skills. However, a company may not have the resources to help unlock this potential in its employees.

If team development is not part of a company’s culture there may be discomfort in dealing with friction arising from a lack of soft skills. In this case, an external facilitator or coach can be a very helpful resource to guide a work team, using thought-provoking activities and role-playing, to find greater connection and trust amongst themselves, and to address issues with a detached point of view.

Organizing such a workshop for your team does not mean they are not doing well or failing. It means you, the team lead/ manager/ CEO/ HR person, etc, care about your team’s best interests, highest achievements and happiness.

Valerie Senyk is a facilitator for Team Development with BERTEIG, and can be contacted by going to http://www.worldmindware.com/AgileTeamDevelopment


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Review of: Product Mastery – From Good to Great Product Ownership

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

Note: This review is based on an incomplete pdf copy of Product Mastery that was shared with the reviewer, which therefore limits discussion of the book.

Geoff Watts, author of Scrum Mastery, has now released Product Mastery: From Good to Great Product Ownership, published by Inspect & Adapt Ltd. The book contains two Forewards by Jeff Sutherland and Roman Pichler, both masters in the field of Scrum management.

The prose Watts uses is straightforward and provides an easy and intelligent read even for the layman, with graphs and illustrations that illuminate his ideas.

The book is built around the idea of DRIVEN, an acronym Watts uses to discuss the traits and characteristics of a great product owner. The book uses each letter as headings, i.e. D = Decisive, R = Ruthless, I = Informed, V = Versatile, E = Empowering, and N = Negotiable. Each heading offers pragmatic advice into the many responsibilities of being a product owner. I will give a few snippets of some insights that Watts shares.

In the first section, entitled “Decisive,” Watts creates stories and discussion that show how product owners need to have courage and trust themselves and others to make decisions, often with incomplete information. He gives strategies to make the decision-making process easier, such as reducing the number of options a product master is considering, and prioritizing. He cites Edison as once famously saying, “I have not failed. I’ve just found 10,000 ways that won’t work.”

Under “Ruthless” Watts shares a mantra used by product owners: “If the product is going to fail, then I would rather it fail in month 2 than month 22.” In other words, it is better to develop the wrong thing quickly and get feedback, than wait too long in an effort to make sure no mistakes are ever made.

The third section is called “Informed.” Watts includes a quote by Roman Pichler, author of Agile Product Management with Scrum, who told him: “Customer feedback is the basis for ideas. Customer data is the basis for decisions.” Watts then cites the experience of a company that creates mobile games. Rather than ask for ratings or feedback, the company monitors actual usage of their games.

In “Versatile” Watts advises product owners to “remain flexibly firm.”

Under the last heading, “Negotiable,” he outlines games to play when negotiating attributes of a product. In this section Watts makes it clear that product owners need to be careful to not fall into the trap of being a perfectionist. He writes: “The temptation to just add a little extra here or there is very strong; but those little bits here or there quickly add up and can easily lead to significant delays, not to mention an unnecessarily cumbersome product to support.”

Product Mastery is a book that is sure to attract a wide readership as it provides a balance

between vision, direction and execution. Wisely, Watts is not dogmatic in his style. He gives numerous approaches to the items under a product owner’s watch. He writes: “Great product owners know how to find the right middle ground, one with an appropriate balance of data and intuition – and a good measure of courage.”

I personally will be adding Product Mastery to BERTEIG’s book offerings for our Certified Scrum Product Owner attendees.

Product Mastery: From Good to Great Product Ownership (282 pp)

Table of Contents:

Foreward – Jeff Sutherland

Foreword by Roman Pichler

DECISIVE 26

RUTHLESS 64

INFORMED 102

VERSATILE 144

EMPOWERING 180

NEGOTIABLE 222

Be DRIVEN to Be Great 264

Available at https://www.amazon.ca/s/ref=nb_sb_noss_1?url=search-alias%3Daps&field-keywords=product+mastery

Product Mastery: From Good to Great Product Ownership Mar 1 2017

by Geoff Watts and Jeff Sutherland

Kindle EditionCDN$ 41.94

PaperbackCDN$ 42.18

 

 


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Using “Status” in Agile Coaching & Training

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

Recently after attending a Scrum Alliance webinar on “Best Practices in Coaching,” I was reminded of my experiences teaching Acting students at university, and how I used changing status to help them achieve their best.

Status refers to the position or rank of someone within a particular group or community. I believe it was Canadian Keith Johnstone who introduced the idea of “playing status” to theatre improv teams. It is used to create relationships between characters onstage, and to change those relationships to move a story forward.

Status can be indicated through position, posture, facial expression, voice and clothing. It is a fascinating tool for any trainer or coach to use.

At the beginning of a semester with new students, I would invite them to sit on the stage floor in a circle with me. I would welcome them, discuss my expectations of their learning, and tell them what they could expect from me. We’d go over the course syllabus and I’d answer questions. I purposefully put myself in an equal status to them, as a way of earning their trust, because the processes of acting* requires huge amounts of trust. I also wanted to establish a degree of respect in them for the stage by all of us being in a “humble” position on the stage floor.

However, when I would introduce a new exercise to them that required them to go beyond their comfort zones, I would deliver instructions from a standing position while they were seated. By elevating my status, I conveyed the importance of the exercise, and it was a signal that it was not something they could opt out of. In this way, I could help them to exercise their creativity to a greater extent.

Another way I encouraged my students to take risks was to take risks myself. Sometimes I would illustrate an acting exercise by doing it myself first. For those few minutes I became a colleague with my students, one of them, equal in status. If I could “make a fool of myself” (which is how it may look to an outsider), then they could too.

I had one student who had great potential, but who took on the role of class clown and would not give it up. He fought against going deeper and getting real. One day in an exercise where they had to “own” a line of dialogue, I had him in a chair onstage, while I and the rest of the students were seated. He had to repeat the line of text until it resonated with him and became real. After some minutes, nothing was changing in him. In desperation had him turn his chair around so his back was to us. I then indicated to the other students to quietly leave the room. He could hear something happening but was confused about it. He was not able to turn around and look.

When I allowed him to turn around it was only him and me left in the theatre. I had him go through the repetition exercise again. Without an audience, and with me still seated, he finally broke through the wall he had erected and connected with the line of text from his inner self. It was a wonderful moment of truth and vulnerability. I then allowed the other students back in, and had him find that connection again with the students there. He was able to do it.

He is grateful to me to this day for helping him get beyond his comfortable role as clown to become a serious actor.

When training or coaching, it seems to me there can be huge value in playing with status. Sometimes taking a lower status, an equal status, or a higher status, can move a team or upper management into discovering whatever may have been blocking the process. Again, there are many ways to indicate status and even a status change to effect progress.

In his book, “Improv-ing Agile Teams,” Paul Goddard makes some important observations about using status. He writes: “Even though status is far less obvious than what is portrayed on stage, individuals still can take small steps to encourage status changes within their own team. For example, asking a team member who exhibits lower status behaviours to take ownership of a meeting or oversee a process not only boosts that person’s confidence but also increases status among peers…these subtle actions can help make lower-status team members feel more comfortable when expressing new ideas or exposing hidden problems.”

A colleague reminded me of a 1975 publication called “Power: How to Get It, How to Use It,” in which author Michael Korda gives advice about facial expression, stance, clothing and innumerable ways to express “power.” The idea of using status in the context I’m writing about is not about gaining power, but about finding ways through one’s own status changes to help unlock the capacity and potential of others.

How can a coach use status to help someone in management who is blocking change? Is someone on a team not accepting what others have to offer because s/he is keeping his/her status high? Is a Scrum Master necessarily a high-status team member, or rather a servant to the team (low status)?

I am curious if any coaches or trainers out there have used status in a way that created growth and change.

*Good acting is a matter of the actor finding the truth in oneself as it relates to the character he or she is playing. It requires vulnerability and courage to step out of one’s known persona and take on another as truthfully as possible. Inherent truthfulness also applies to work in any other endeavour.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Dejirafication: Free Your Process

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

Alexey Krivitsky recently posted a presentation on his blog, agiletrainings.eu, addressing the issue of so-called-agile tools, specifically Jira.

Here is a link to his presentation.

The movie images he chose gave me a chuckle and his points really hit home.

He offers 4 points to what he calls a “Jira Rehab Program” and I found the points interesting.

Take a look. See what you think.

Share your comments on your experience with agile tools here.

Have you had success with Jira or would you rather see it disposed of?

And check out Mishkin’s recent article on the ideal electronic Agile tool.

 

 


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Link: Strong Teams Start With Trust

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

One of the positive outcomes of an agile team succeeding in its transformation is the establishment of a high-functioning team.

A high-functioning team works more effectively, efficiently and can innovate more appropriately for the corporate advantage of the business.

Ryan Yeoman has a lot to say on the topic. Although he doesn’t mention agile specifically, he’s right on in his approach.

In his article, “Strong Teams Start With Trust: 5 Ways To Build Trust in Your Teams,” he writes that:

All of them point to trust as a critical and fundamental piece to success – in business and in life.

Piggy-backing all these thoughts and making it personal to myself, trust enables me to be more.  It enables me to:

  • Accomplish more and do better work by getting feedback and synergizing
  • Grow and learn more by allowing myself to be “open” and receive information
  • Teach more and serve by letting me focus my attention on others
  • Care more and empathize because I’m not constantly worried about protecting myself
  • Be more human

Trust helps you accept deepening relationships and removes politics and silos from the work place, creating an organization within which people feel safe. At its simplest, trust is a catalyst for your organization to be more: more nimble, more efficient, more effective.  It’s like oxygen for a successful team – one simply can’t exist without it.

I found his comments insightful and his links appropriate.

This is an excellent article for those team members who are striving for excellence and learning to trust one another, and themselves, in the process.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Video: Managers Develop Delivery Teams

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

Real Agility managers help their delivery teams to progress through the stages of team development to reach a sustainable high-performance state. Real Agility is the merging of Agile, Lean, and Community Development. Find out how managers’ roles change in this short video by Mishkin Berteig.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Quotable Quote: Transform Culture & Business Approach

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

Jerry Doucett 201601 white background - head - 275 squareAt 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.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Announcement: 4 New Steams of SAFe courses offered

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

Jerry Doucett 201601 white background - large square

Jerry Doucett is now offering consulting in implementing SAFe 4.0,  as well as teaching the following courses and workshops:

1) “Leading SAFe 4.0” course for the SAFe Agilist (SA certification)

2) “SAFe Product Manager – Product Owner” workshop (SPMPO certification)

3) “SAFe 4.0 for Teams” course for the  SAFe Practitioner (SP certification).

Please reach out to Jerry by email or on LinkedIn if you have any questions about SAFe or about scaling Agility.

The next SAFe class is “Leading SAFe 4.0” on September 08 and 09.  Please see WorldMindware.com for more information including registration.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail