Tag Archives: communication

The Scrum Master and Product Owner as leadership partners

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

After a recent large organizational change that resulted in a number of new teams formed, a product owner (PO) approached me looking for some help. He said, “I don’t think my new Scrum Master is doing their job and I’m now carrying the entire team, do we have a job description we can look at?”

I can already imagine how a version of me from a previous life would have responded, “yes of course let’s look at the job description and see where the SM is falling short of their roles and responsibilities”. But as I considered my response, my first thought was that focusing our attention on roles and job descriptions was a doomed route to failure. Pouring our energy there would likely just extend the pain the PO, and likely SM, were going through.

Sure we have an SM job description in our organization, and it clearly documents how the SM provides service to the organization, team and PO. But reviewing this with the seasoned SM didn’t really make sense to me; they were very well aware of the content of the job description and what was expected of them.

At the same time that this was happening, another newly paired Scrum Master asked for my help regarding their PO. From their perspective the PO was “suffocating” the team. The PO was directing the team in many aspects of the sprint that they felt was stepping beyond their role. “I don’t think the PO knows their role, maybe you can help me get them some training?” was the SMs concluding comment.

Over the course of the next few weeks this scenario played out again through more POs and SMs sharing similar challenges. Surely this was not a sudden epidemic of previously performing individuals who now needed to be reminded of what their job was?

Recognizing the impact of change

A common pattern was emerging from all of this, change was occurring and each individual was relying on, and to some degree expecting, old patterns to continue to work with their new situation. Their old way of working in Scrum seemed to work very well; so it was everyone else around them that was not meeting expectations.

The core issue however was that change was not being fully confronted: the product was different, the team competencies were different, the stakeholders were different, the expectations were different and finally the team dynamic was different all the way down to the relationship between the SM and PO.

Scrum as a form of Change Management

I looked for the solution from Scrum itself, at its heart a method for teams to use to adapt to and thrive with change. Was there enough transparency, inspection and adaptation going on between the SMs and POs in these situations? I would argue, not enough.

A pattern was becoming clear: nobody was fully disclosing their challenges to the other, they hadn’t fully confronted and understood their new situation and hadn’t come up with new approaches that would improve things. Said another way, they hadn’t inspected their new circumstances sufficiently and transparently enough so that they could adapt their role to fit the new need.

One thing that many successful SMs and POs recognize is that they are both leaders dependent on each other, and for their teams to be successful they need to figure out how they will work together in partnership. It doesn’t matter whether the terms of that partnership gets hashed out over a few chats over coffee or through a facilitated chartering workshop. What matters is clarity around how you agree to work together as partners meeting some shared goal.

As an SM or PO, here are some sample questions whose answers you may wish to understand and align on:

  • Do we both understand and support the team’s mission and goals?
  • What are the product goals?
  • How can we best help the team achieve those goals?
  • Are there any conflicts between the team and product goals?
  • When our goals or methods are in conflict, how will we resolve them?
  • In what ways will I be supporting your success as an SM/PO?
  • How will we keep each other informed and engaged?
  • Should we have a peer/subordinate/other relationship?

So if you are an SM or PO, and it’s unclear to you on the answers to some of these questions, you may just want to tap your leadership partner on the shoulder and say “let’s talk”.

[EDITOR’S NOTE: Martin Aziz is a first-time contributor to Agile Advice – please welcome him in the comments.  And let us know if you are interested in contributing.]

Please share!

Link: Meeting Check-Ins

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

Very nice article called Why I Always Start a Meeting with a Check-In.  From the article by Ted Lord, senior partner, The Giving Practice:

The greatest benefit of working in a group is our diversity of viewpoints and approaches; groups hobble themselves when they don’t continually give attention to creating a container of trust and shared identity that invites truth-telling, hard questions, and the outlier ideas that can lead to innovation

One antidote to over-designed collaboration is the check-in.

Please share!

Pitfall of Scrum: Focus on Scrum Tools

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

Many organizations try to find an electronic tool to help them manage the Scrum Process… before they even know how to do Scrum well! Use team rooms and manual and paper-based tracking for early Scrum use since it is easiest to get started. Finding a Scrum tool is usually just an obstacle to getting started.

The culture of most technology companies is to solve problems with technology. Sometimes this is good. However, it can go way overboard. Two large organizations have attempted to “go Agile” but at the same time have also attempted to “go remote”: to have everyone using electronic Scrum tools from home to work “together”. The problem with electronic Scrum tools is three-fold. They

  1. prevent the sharing of information and knowledge,
  2. reduce the fidelity of information and knowledge shared, and
  3. delay the transfer of information and knowledge.

Scrum Tools Prevent Information Sharing

Imagine you are sitting at your desk in a cubicle in an office. You have a question. It’s a simple question and you know who probably has the answer, but you also know that you can probably get away without knowing the answer. It’s non-critical. So, you think about searching the company directory for the person’s phone number and calling them up. Then you imagine having to leave a voice mail. And then you decide not to bother.

The tools have created a barrier to communicating. Information and knowledge are not shared.

Now imagine that the person who has the answer is sitting literally right next to you. You don’t have to bother with looking up their number nor actually using a phone to call. Instead, you simply speak up in a pretty normal tone of voice and ask your question. You might not even turn to look at them. And they answer.

Scrum tools are no different from these other examples of tools.  It takes much more energy and hassle to update an electronic tool with relevant, concise information… particularly if you aren’t good with writing text.  Even the very best Scrum tools should only be used for certain limited contexts.

As the Agile Manifesto says: “The most effective means of conveying information to and within a team is face-to-face communication.”

Scrum Tools Reduce Information Fidelity

How many times have you experienced this? You send an email and the recipient completely misunderstands you or takes it the wrong way. You are on a conference call and everyone leaves the call with a completely different concept of what the conversation was about. You read some documentation and discover that the documentation is out of date or downright incorrect. You are using video conferencing and its impossible to have an important side conversation with someone so you resort to trying to send text messages which don’t arrive on time to be relevant. You put a transcript of a phone call in your backlog tracking tool but you make a typo that changes the meaning.

The tools have reduced the fidelity of the communication. Information and knowledge are incorrect or limited.

Again, think about the difference between using all these tools and what the same scenarios would be like if you were sitting right beside the right people.  If you use Scrum tools such as Jira, Rally* or any of the others, you will have experienced this problem.  The information that gets forced into the tools is a sad shadow of the full information that could or should be shared.

As the Agile Manifesto says: “we have come to value: individuals and interactions over processes and tools.”

Scrum Tools Delay Information Transfer

Even if a person uses a tool and even if it is at the right level of fidelity for the information or knowledge to be communicated, it is still common that electronic tools delay the transfer of that information. This is obvious in the case of asynchronous tools such as email, text messages, voice mail, document repositories, content management systems, and version control. The delay in transfer is sometimes acceptable, but often it causes problems. Suppose you take the transcript of a conversation with a user and add it into your backlog tracking tool as a note. The Scrum Team works on the backlog item but fails to see the note until after they have gone in the wrong direction. You assumed they would see it (you put it in there), but they assumed that you would tell them more directly about anything important. Whoops. Now the team has to go back and change a bunch of stuff.

The Scrum tools have delayed the communication. Information and knowledge are being passed along, but not in a timely manner.

For the third time, think about how these delays would be avoided if everyone was in a room together having those direct, timely conversations.

As the Agile Manifesto says: “Business people and developers must work together daily throughout the project.”

Alternatives to Scrum Tools

Working in a team room with all the members of the Scrum Team present is the most effective means of improving communication. There are many photos available of good team rooms. To maximize communication, have everyone facing each other boardroom-style. Provide spacious walls and large whiteboards. Close the room off from other people in the organization. Provide natural light to keep people happy. And make sure that everyone in the room is working on the same thing! Using Scrum tools to replace a team room is a common Scrum pitfall.

Scrum Tools - Labelled Team Room Photo

The most common approach to helping a team track and report its work is to use a physical “Kanban” board. This is usually done on a wall in which space is divided into columns representing (at least) the steps of “to do”, “in progress” and “done”. On the board, all the work is represented as note cards each with a separate piece of work. The note cards are moved by the people who do the work. The board therefore represents the current state of all the work in an easy-to-interpret visual way. Using a tool to replace a task board is another variant of this common Scrum pitfall.

This article is a follow-up article to the 24 Common Scrum Pitfalls written back in 2011.

* Disclaimer: BERTEIG is a partner with a tool vendor: Version One.

Please share!

What’s in a Voice? Communicating Who You Are [Updated with edits]

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

In our professional lives and in doing business, we commonly follow the advice to “dress for success.” We make certain to wear that business suit, or a particular pair of snazzy heels, or a certain color of tie. For better or for worse, we can be judged in the first few seconds of contact with a potential employer or customer by our attire, our hairstyle, our facial expression, our nose ring…

A more subtle way we evaluate a person is through the sound of his or her voice. The voice is a very personal instrument, and it can communicate so much about who you are, your abilities and your intentions.

The voice can tell you whether someone is nervous or at ease. Whether they’re authentic or stringing you a line. Whether they care if they communicate with you or not. When I was a kid, I thought I could detect when someone was lying to me by a certain glitch in the voice, or a tell-tale tone. Often, our brain makes intuitive judgements about what’s being said to us, and is sensitive to vocal rhythm, clarity, tones, and the use of language.

One may think it’s not fair to judge someone by their voice. Let’s face it, a voice – like being short, or having a large nose – is usually unchangeable. But it’s how the voice is used that matters. We all have an inherently full, expressive voice, but things happen to us in life that can negatively influence and/ or harm that voice.

Think of the person who speaks so quietly it’s almost a whisper – you must lean closer to catch what she says. This person may have had some trauma in her life, like being constantly told as a child to ‘be quiet’, to de-voice her. I know people whose greatest fear is public speaking, who quake inwardly and outwardly, even if they have something important to share with others.

Personality is also expressed through the voice. Imagine the annoyingly loud talker sitting nearby in a restaurant. This is certainly someone who wants too much attention and tries to get it by being overbearing. Or the fast-talker, who doesn’t want any other opinions but his own to be expressed, and doesn’t give the listener an opportunity to think or to respond, lest they disagree with him.

Anyone can be trained to use their voice for positive communication. A voice is an instrument that can become effective and optimal with practice.

Here’s a few things to think about in how you use your voice:

  • Are you clearly enunciating your words so as not to be mis-heard?

  • Are you directing your voice to the person or people you want to communicate with?

  • Are you speaking in a rhythm that’s neither too fast nor too slow?

  • Are you allowing your true feelings or intentions to come through?

  • Are you being honest?

The voice is just one of the important tools we use to communicate. If your work requires relating to other people in any way, for example, making presentations, or promoting a product, consider how you use your voice and what it may communicate about you!

Please share!

A Conference Call in Real Life (youtube)

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

I’ve started to show this video in my public CSM classes (see sidebar for scheduled courses) as part of the discussion about why co-location for Agile teams is so important.  The video is a humorous look at what conference calls are like.  Probably the most notable part of it is the fact that on a conference call you can’t see people’s body language and facial language which are important cues for efficient communication:

Please share!

The Rules of Scrum: Your Product Owner is allowed to communicate directly with any stakeholder of the team

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

The Product Owner needs to be in contact with all those that are invested in the work of the team (aka stakeholders). These stakeholders have information on the marketplace, the users’ needs, and the business needs. The Product Owner must be able to communicate with each of these individuals whenever the need arises. If this is possible, the entire Scrum Team will have the most up to date information that will aid them in their execution of the product. If not, the team will have to wait for information and/or guess which will cause confusion, blame, distrust, and unhappy customers.

To learn more about Product Owners, visit the Scrum Team Assessment.

Please share!

The Rules of Scrum: Your ScrumMaster is allowed to communicate directly with any stakeholder of the team

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

It is the ScrumMaster’s job to remove the Scrum Team’s obstacles that occur through all levels of the organization. To do this properly the ScrumMaster must be able to connect directly with all stakeholders of the team including those outside the organization. This direct communication aids in addressing identified obstacles with the appropriate individual or group. Without the ScrumMaster being allowed this direct communication, he will have to deal with a third party which may distort the information and/or be unable to convey the importance of removing an obstacle or addressing a need. The ScrumMaster is like a catalyst that should be able to set ablaze those individuals that are interacting or connecting with the team either directly or indirectly.

To learn more about ScrumMasters, visit the Scrum Team Assessment.

Please share!

The Rules of Scrum: I attend every Sprint Planning meeting in person

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

This rule of Scrum aligns with the Agile Manifesto principle “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”  In-person attendance of all Scrum Team members allows for the plan to unfold with minimal communication overhead and for the team to keep the meeting within the short time-box.  In-person attendance also allows the team to effectively collaborate in the work of creating the plan. The efficiency and effectiveness of the Product Owner’s presentation of the Product Backlog is optimized as well as the Development Team’s ability to collaboratively assess and select what it can and will accomplish in the Sprint. It also allows for everyone to be clear about the Sprint Goal and why the Development Team is building the increment. In-person attendance also allows the Development team to efficiently and effectively come to a decision as to how it will build the increment of functionality. In-person participation of all team members also increases the likelihood that the team will create the right design for the increment.  If even one team member attempts to attend this meeting by any other means, either by phone or even video conferencing, efficiency and effectiveness of the planning becomes compromised. Compromised collaborative planning yields compromised collective ownership. The successful delivery of the Sprint Goal requires full commitment on the part of the whole team. Lack of in-person participation increases the likelihood that the team will fail to deliver on its Goal because the planning will lack effectiveness. People are prone to estrangement from hazy goals reached through ineffective planning. In-person planning, therefore, is paramount to succeeding with Scrum.

Please share!

Communication at XKCD

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

The comic strip at XKCD today is brilliant.  It takes a bit of effort to follow it, but the punchline is brilliant.  Communication is tough.  How does this apply to agile teams?  You be the judge! (PS.  XKCD is a great comic for geeks, but sometimes nsfw.)

Please share!

Five Tips for Distributed Agile Teams

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

Actually, this is six tips because my first tip is really about deciding to use distributed teams…

Some in-house studies that I have been privy to have shown 2-1 or 3-1 productivity difference between good co-located teams and “good” virtual teams. Creating a true, high-performance virtual team is incredibly hard emotionally, incredibly time-consuming, and costs a lot in terms of tools and travel. If this is being done for convenience of the team members or for cost savings, it’s a bad idea. The only good reason to have distributed teams is if there is a compelling strategic reason that trumps the hit you will take financially and morale-wise. (That was tip “zero”.)

That said, it is worth trying is to create an environment as close as possible to what you would get with a co-located team. To do this, here are some things to try:

1. Set core hours (at least 3 contiguous) every day when everyone on the team, regardless of time zone, will be at work simultaneously. If you have a globally distributed team, this will mean that some team members will have to make an ongoing personal sacrifice to be available. This sacrifice should be compensated financially. Avoid rotating the core hours in the mis-guided idea that it is better that everyone is uncomfortable some of the time vs. some being uncomfortable all of the time. It is much easier for a team member to get used to a consistent schedule and although initially there will be discomfort for some team members, they will (relatively speaking) get used to the new schedule.

2. During core hours, use a good video conferencing tool (e.g. Office Communicator), in an always-on state for all team members – be in the same space at the same time. Cameras should be set up so that it is possible to see an individual’s facial expressions, yet also to allow that person to move around and still be in-view. The video conferencing tool should have good full-duplex audio so that no one ever gets cut off because someone else is louder.

3. During core hours, all team members agree to forego the use of headphones or anything else that would prevent them from instantly being aware of something happening with any of the other team members. Again, for some people this might be quite a sacrifice. The idea is that communication is paramount for agile teams and anything that isolates one team member from another will hinder communication.

4. Have a live update task tracking tool that all team members use. (Most agile team management tools that I am aware of do not work because you have to refresh to see updates. Cardmeeting.com is a decent virtual wall that has live updates.) Any task-switching should be visible on this tool either through a color change, an audible cue, or a movement. So if I complete a task and start on a new one, everyone else should notice this immediately even if I do not actually say anything. The team members should get in the habit of using this tool even outside core hours.

5. Have a second (or third) monitor for every team member that is dedicated to the always-on communication tools (video conferencing, task tracking). These always-on tools should _never_ be covered by anything else. All the real-time communication tools are useless if they are not constantly visible. If your team members currently have two monitors, then get them a third for these tools. There should never be any excuse for a team member to hide these tools.

Basically, these suggestions are designed to maximize the quality, bandwidth and minimize the latency of communication among the team members. If you have a distributed team, and you try these things, please let me know how it works for you!

Please share!

The Seven Core Practices of Agile Work

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

Agile Work consists of seven core practices. These practices form a solid starting point for any person, team or community that wishes to follow the Middle Way to Excellence.

Self-Organizing Team

Any group of people that wish to be an Agile Team need to take the initiative to determine for themselves how they are going to work (process) and how they are going to do the work (product). The term “team” really applies quite broadly to any size group of people that are working together towards a common goal.

Teams go through stages of development as they perform their work. The most important result of team development is the team itself, and not the specific skills and abilities that the individuals learn.

If the team is part of a broader organization, that organization must give the team the authority, space and safety to learn to be self-organizing. The organization’s leadership is responsible for determining the “why?”, some constraints on “how?”, and then letting the team respond to the need as best as it can.

Also Known As: Whole Team (Extreme Programming), Cross-Functional Team (business management).

Deliver Frequently

Agile Work uses short fixed periods of time to frame the process of delivering something of value. Each of these iterations or timeboxes is structured so that the team or group actually finishes a piece of work and delivers it to stakeholders. Then, the team builds on what has previously been delivered to do it again in the same short amount of time.

The sooner that valuable results can be delivered, the more value can be obtained from those results. This extra value is derived from opportunities such as earlier sales, competitive advantage, early feedback, and risk reduction.

There is an explicit tradeoff: the shorter the time to delivery, the smaller the piece of value will be. But, like investing in one’s retirement account, the earlier you start, even with small amounts of money, the better off you are in the long run.

Also Known As: Sprint (Scrum), Iteration (Extreme Programming), Timeboxing (generic), Time Value of Money (accounting).

Plan to Learn

Every type of work is governed by a Horizon of Predictability. Any plan that extends beyond this horizon of predictability is bound to fail. Agile work uses an explicit learning cycle tied in with the planning of work to accomodate this inevitable change.

First, a goal is required. This goal can be long-term. Teams using Agile Work then create a queue of work items to be done in order to reach this goal. Each iteration, some of these items are selected, finished and then the queue is adjusted. The changes in the work queue are based on external factors, and learning that the team does as it goes.

One of the most effective methods for the team to learn about how it is doing its work is the retrospective. After each delivery of results, the team holds a retrospective to examine how it can improve.

Also Known As: Inspect and Adapt (Scrum), Kaizen (Lean), Adaptive Planning (generic).

Communicate Powerfully

A team needs to have effective means of communicating, both amongst team members and also to stakeholders. To Communicate Powerfully, a team needs to prefer in-person communication over distributed communication. Synchronous over asynchronous communication. High-bandwidth over low-bandwidth communication. Multi-mode communication over single-mode communication.

The results of failing to communicate powerfully include wasted time for waiting, misunderstandings leading to defects or re-work, slower development of trust, slower team-building, and ultimately a failure to align perceptions of reality.

The single most effective means to communicate powerfully, is to put all the team in a room together where they can do their work, every day for the majority of the work time.

Some types of work do not lend themselves to this approach (e.g. creating a documentary video), but every effort should be made to improve communication.

Also Known As: Visibility (Scrum), Whole Team and Team Room (Extreme Programming), War Room (business management).

Test Everything

Defects are one of the most critical types of waste to eliminate from a work process. By testing everything, by driving all the work of a team by creating test cases to check the work, a team can reach extremely high quality levels. This ability to prevent defects is so important that only an executive level decision should be considered sufficient to allow defects into a work process. Quality is not negotiable.

In Agile Work, removing a defect is the only type of work that takes priority over any new features/functionality/production. If the end result desired is to maximize value, then removing defects is an important means to that end.

A team has an ethical duty to discover new ways to effectively test their work. This can be through the use of tools, various feedback mechanisms, automation, and good old problem-solving abilities.

Also Known As: Canary in the Coal Mine (Scrum), Test-Driven Development (Extreme Programming), Defects per Opportunities (Six-Sigma).

Measure Value

Since Reality is Perceived, it is important for an agile team and organization to have a clear method of describing and perceiving what is important for the organization. Measuring value is a critical method for describing and perceiving what is important.

A single metric can be used to drive all the measurement and goal-setting and rewards in an organization. All other measurements are secondary and must be treated as such: limited in use and temporary.

There are many things which are easier to measure than value. It is often easy to measure cost, or hours worked, or defects found, or estimate vs. actual… etc. However, all of these other measurements either implicitly or explicitly drive sub-optimal behavior.

Also Known As: Measuring Results (Scrum), ROI (business management), Economic Driver (Good to Great), Running Tested Features (Extreme Programming).

Clear the Path

Everyone in an organization using Agile Work takes responsibility for clearing the path, removing the obstacles that prevent work from being done effectively. Clearing the Path doesn’t just mean expedient, quick fixes to problems, but rather taking the time to look at an obstacle and do the best possible to remove it permanently so that it never blocks the path again.

In the Agile Work method, the Process Facilitator is the person who is responsible for tracking obstacles and ensuring that the path is cleared. To do this, the Process Facilitator maintains a Record of Obstacles.

Clearing the Path is sometimes painful work that exposes things we would rather not deal with. As a result, it is critical that people build their capacity for truthfulness and work to develop trust amongst each other. Building a capacity for truthfulness is not something that can be done by using an explicit process.

Also Known As: Removing Obstacles (Scrum), Stopping the Line (Lean).

Remember also, that these practices must always be viewed and implemented in the context of the Agile Axioms. These axioms provide a check to ensure that the practices are not being applied blindly, but rather applied appropriately to the given situation.

Please share!

Collocate the Team

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

Collocation of the team is used to improve communication efficiency and to allow the team to learn to be more collaborative. Perfect collocation would have all stakeholders and work performers in the same work space (e.g. a large room) during all working hours. This level of collocation is not usually possible, so adjustments are made.

Collocation reduces wastes associated with waiting, movement, and inefficient communication. Collocation increases learning and feedback and assists with team empowerment.

Collocation can present challenges to people used to working on their own. For these people, a careful consideration of how to accommodate their working style is important, but more important is helping them to understand the need for and benefits from collocation. As this understanding grows and as the team starts to produce noticeable results, most people start to enjoy the close working environment.

When perfect collocation is not possible, consider part-time collocation, video conferencing, having a decision-making proxy represent the stakeholders, getting rid of closed offices, moving into open or shared work spaces or collocating part of the team.

I typically hear a great deal of positive feedback from teams that were previously not collocated after they come together in a common space. For example: “I don’t have to spend hours dealing with email anymore – it takes a few seconds to lean over and ask a question and get a response.” “Meetings that used to take half an hour to organize on people’s calendars now happen spontaneously.” “I can work much more efficiently because the people who I need to collaborate with are right there. No more emails, phone calls, scheduling, and pestering.”

Please share!