AgileIQ Blog

The ScrumMaster's Discretionary Budget

  

 Email Article  

Tweet  

  

by Joe Justice

During the daily standup meeting, the ScrumMaster records the blocking issues team members raise by writing them down as tasks on their impediment backlog (or placing them as impediments on the team backlog). That helps keep the standup on track by avoiding discussing the block until after standup is completed, and then letting team members opt in to that conversation.

What are the ScrumMaster's resources for bulldozing those road blocks so they can report back to the team during their standup the next day?

The ScrumMaster makes the waste generated by the block visible. If it is in their power to unblock it, they do -- typically they have a petty cash budget to buy tools (a WiFi router, a coffee maker, a set of screwdrivers) or small items when the team needs them. This is totally different than the operating budget, which the product owner wields. Tasks they do not have the resources to unblock, they make visible to those who can -- like the product owner, or stakeholders, or any organization above that. By showing the waste created by the block, the person with the resources to solve it can take that task into their backlog and prioritize it against the rest of their work.

Being a ScrumMaster for a Scrumban Team

  

 Email Article  

Tweet  

  

by Venkatram Vatti

What follows is a brief outline of the features and challenges of using Scrumban, a technique that combines Scrum and Kanban, two of the most successful Agile concepts. With some outside references and personal experiences combined, I have attempted to project my idea of implementing and practicing Scrumban.

Kanban and WIP limits help the team to stay
focused and continuously deliver.

Scrumban features:

• Combines Scrum and Kanban to get the most out of both.
• Visualizes the flow of Product Backlog Items or Stories, rather than Tasks. Tasks are created late in the game and don’t flow all the way. Some teams visualize tasks as well, but it is optional.
• Requires weekly planning.
• Daily tracking is done via a Kanban board to maintain flow.
• Goal is to make incremental progress and limit WIP (work in progress) both row-wise and column-wise.

ScrumMaster role:

• Leader, facilitator, protector, gatekeeper, coach, even described sometimes as a sheepdog.
• Works as a servant leader.
• Doesn’t practice command and control.
• Crucial in ensuring the success of the Scrum team.
• Master of Scrum, not a Master of the Team.
• Enforces the Scrum process.
• Ensures full team involvement in all meetings.
• Radiates information to the larger organization.
• Shields the team from external interference.
• Keeps the process moving.
• Tracks and resolves team impediments.

Challenges:

• Sometimes the team has to do some bug-fixing, and sometimes the client asks for small and/or urgent tasks, which leads to Context Switching. This is an impediment for the team, and even though the product owner understands it, client and product nature makes these emergent tasks unavoidable and creates unpredictable velocity because of their urgency:

• “Drop whatever you are doing, there’s a server on fire and we don’t care if velocity drops – go and fix it now.”
• “As soon as you finish what you are doing right now, please choose this urgent task.”

• Limiting the Work in Progress, which in a Scrum context basically means limiting the number of Product Backlog Items in progress at any point in time. Once the limit is reached, the alternative to starting a new story is to go and help others deal with their story. This can mean helping others in your area of expertise or going upstream or downstream to help.

Managing Risk in Scrum, Part 2

  

 Email Article  

Tweet  

  

by Valerie Morris

In my previous post, I discussed the five risk areas found on most projects and how Agile addresses them.

Managing risk is prevalent in Scrum on a daily basis.  Discovery, analysis, and mitigation for risk happens organically in Agile, and particularly in Scrum.  Let’s compare risk management practices between traditional/”waterfall” project management and Scrum.

Traditional project risk management is a knowledge area in PMBOK.  Risk management in Scrum is not mentioned as a formal tenet of the framework.  Scrum has enough structure to plan and deliver quality software incrementally with inspection and adaptation.  Scrum gives you front row access to identify and mitigate risk daily.  Scrum does not ask you to be stupid on purpose by ignoring risk.

Virtual Parkbench: Retrospectives for Distributed Agile Teams

  

 Email Article  

Tweet  

  

by Dhaval Panchal

For large distributed retrospectives, where participants are in different cities, I have created a variation of popular group discussion technique called “Park Bench”.

Some Background

I was coaching within a large organization with different Scrum teams distributed in three separate cities: Bellevue, WA; Chicago, IL; and Waterloo, Canada. This organization had executed many projects using Scrum in pilot mode, and on my recommendation they wanted to retrospect on different pilot Scrum projects that were executed in these different cities. To manage participation of large number of people, we split these groups in two batches of 30 people each (I facilitated two separate retrospectives). In each of these retrospectives, there were various exercises; some of them were breakout exercises in which people at their respective locations would participate locally. One of the main exercises was ‘Virtual Park Bench’ to enable discussions between people in different cities mentioned above.

For the purposes of this blog, I will not describe the entire retrospective format. Instead, I’ll focus on the variation of the Park Bench technique and how I addressed the situation when there were some issues. The setup for the retrospective included a live video feed from all locations. In other words in Bellevue, we had direct video and audio feed that displayed happenings in two separate monitors, one for Chicago and another for Waterloo.

Park Bench

In this group discussion technique, there are about 4 empty seats (park bench) facing rest of the participants in the group discussion At any given time, only three seats can be occupied by the participants; the other seat is kept empty. Only those seated on the ‘park bench’ can talk while the rest of the participants only listen. If some one wants to contribute, they can take the fourth seat to join the park bench. When this happens, one of the existing speakers must vacate their spot and leave the discussion. This ensures that only three seats are occupied most of the time. This setup allows a large group to focus their discussions on a hot topic. These group discussions are timeboxed and enable everyone to participate on the central topic of discussion.

Virtual Park Bench

In the virtual setup, we had two chairs in each location and the video cameras were focused on these six seats. The rules were similar to a typical park bench exercise. Whenever there were more than three people on camera feeds, one of the existing people had to leave and make room for new participants. There were many breakout exercises in the full retrospective, and we had setup for virtual park bench to allow for engaging conversations between people from different locations. This section was timeboxed for 45 minutes.

During the retrospective, the discussions were passionately engaging and people from different cities and from different Scrum projects were discussing their experiences. One simple rule of this exercise, that only three people can be on camera in discussion, was working well. As a facilitator for this retrospective, I explained the rules and ensured that they were being followed.

After the first fifteen minutes of this discussion format, I realized that only a few people were repeating themselves on the park bench and that the discussion was becoming polarized. There were others whose voices needed to be heard. Sensing that a few people were monopolizing the discussion, I interrupted and introduced one more rule. This new rule was that each person leaving the park bench had to invite another person from the larger group to join the discussion. The person requested to join had to take a seat on the park bench and could choose to not contribute — in this case, the person had invite someone else before leaving the park bench. This minor modification worked extremely well. We were able to politely manage the more vocal members of the group, and also ensure that the quiet ones had an opportunity to express themselves. The ensuing discussion following this minor modification was much more balanced and I feel that it enhanced the value of of retrospective for the participants.

Takeaways

In hindsight, I feel that for distributed retrospectives, when facilitating the virtual park bench discussion format, I will always use the modified rule of inviting people. For balanced discussions, every one should be awarded the opportunity to share their perspectives — meetings via webcams often tend to get monopolized since it’s easier to forget others who are not physically in front of you. (Out of sight, out of mind)

The Afternoon ScrumMaster: Keeping Agile Teams on Track

  

 Email Article  

Tweet  

  

by Dhaval Panchal

Context explains a lot of our behavior.

I’m going to recount a very intriguing case that I feel I can now retell to prove my point. In the warm summer months of August, I was engaged with an ambitious client who wanted to pursue Scrum adoption across the board. Alas, this enthusiasm extracted a steep price from the servant of the ‘Flying Wizards’ company team. A lot of time has passed, and my metaphorical obfuscation will protect the innocent.

The team was readied for the first wave. This group, veterans of two previous sprints, spearheaded the assault against a corporate culture that demanded action, a culture where stories of their Mongolian-style releases (raids) were recounted in post-release parties amidst much wine and rancor. These are fighting folks who soon realized that much is placed at risk when waging big wars — much more could be achieved if they were to master their lost art of guerrilla warfare, of winning regular manageable battles. In this pursuit, Scrum was ushered in to bring back the collective spirit of teamwork, shared accountability, and smooth releases.

As the coach for the Flying Wizards and two more first-wave teams, I was thrilled to see these teams get on to a stable start. Being one of the only two coaches at this organization, my day-to-day attention soon shifted to other teams, but I maintained medium- to light-touch consultation with the Flying Wizards and other first wave teams. Over my ritualistic morning coffee, I would often run into the ScrumMaster for the Flying Wizards team. Soon a pattern seemed to emerge where the dutiful ScrumMaster would appear very tense and worried, with little to no time to talk until noon. Strangely enough, our banter would return after lunch time. I decided to investigate further.

I attended their daily standup and realized that the nature of the meeting had drastically changed into a ‘command and control’ style operation. Later that afternoon, I talked to the ScrumMaster about it, how I was puzzled by his behavior, and asked why he was driving the team like a drill sergeant. He explained his behavior by saying that he felt responsible for the sprint commitment and would do whatever it took to make sure that the team delivered. To ensure this, he needed to understand a solution path fully or have the team follow his commands. Therefore he was very busy before and after the stand-up in the morning, and it was typically by noon that he freed himself from his micro-monitoring tasks. He needed to know and keep track of what the team was doing, and how! He had become an Afternoon ScrumMaster.

After further inquiry, I learned that the Generals had reverted to form. At a recent departmental meeting, their senior vice president had talked about the seriousness of the organization’s commitment to Scrum. To accomplish their objective, it was declared that the ScrumMaster was the ‘single-wringable’ neck. A slap on my forehead later, it was clear why this had backfired.

Able leaders do not pass the buck. After my conversation with the ScrumMaster, I met with the Sr. VP, who took ownership of these unintended consequences. He recognized that the rest of the organization had interpreted his commitment towards Scrum as reverting to the hierarchical ways of past. He promptly clarified his messaging through the various channels at his disposal.

Epilogue

Misinterpretations are common within any large organization. This is part of the any organizational fabric. The courage to seek clarity is a trait most desired in a ScrumMaster. Would you have succumbed? Are you an Afternoon ScrumMaster?

What Does “Going Agile” Really Mean?

  

 Email Article  

Tweet  

  

by Valerie Morris

I hear people say “we’re going Agile.” When I ask them what they mean by this statement, the most popular answer seems to be “we’re changing our processes in the way we deliver.” This external-focused change will not supply the success and benefits many want to achieve.

Changing the mechanics of how we work seems like an easy place to start. Training sessions are focused on telling and showing people “how” to use a process. We attempt to put some “why” in the discussion, but it is viewed as a theoretical why. Describing the Agile Manifesto and principles to someone gives information they can reference when choosing how they work.

 External changes, like process, only effect short term gains. Internal changes, like values, yield long term gains. People and processes continue to evolve through inspection and adaption. The manifesto and principles are the core components to inventing and reinventing our agile journey.

We use learned behaviors and previous experiences to guide our actions. We cannot change our behaviors until we internalize “being agile” and align our values to the Agile Manifesto and its principles. This personalization of the manifesto and its principles brings the art and science of the agile frameworks together. One without the other will create chaos in every environment. People are personally invested in what they do — sometimes this investment is a passive investment because they have not aligned “what” they do to their value system of “why” they do it.

Communication, trust, collaboration are themes that resonate in the Agile Manifesto and principles. My experience of successful agile transitions and adoptions is about embracing and actioning the manifesto and principles.

Fostering Collaboration in a Multicultural Scrum Team

  

 Email Article  

Tweet  

  

by Valerie Morris

I was talking with a colleague who is a ScrumMaster for an international team. All of the team members are co-locate in the same physical locale and are working together as a Scrum team. So, what do I mean by international team? Often, we use the term international to insinuate geography — I am using the term to represent cultural and diversity about this particular Scrum team, called Mad Dog. There are 9 members on the team representing Russian, Japanese, Chinese, Indian, Scottish, and American cultures. This diversity creates a rich opportunity for team members to form relationships outside of their primary language and customs.

In our conversation, the ScrumMaster told me about a situation some of the team members were experiencing with team conversations. Here is the scenario he presented to me:

“Recently I had a delivery team member (now a former delivery team member) complain that other team members were speaking a foreign language in the team room and that it was an impediment to him. I didn’t give it too much thought because I thought it was a onetime occurrence. Now I’m seeing it very often. What is your perspective on how I can address this with the team?”

In my response to him and anyone else struggling with this same thing, I recommend bringing this topic up in a conversation about the team’s working agreement. We are comfortable with our learned primary language and customs. Being on the outside of one or both if these may cause people to feel left out or insecure. This is an area to build trust and acceptance of a multinational team. As a ScrumMaster, you must facilitate a discussion with the team about “what a team is”. Remind people about the team values of openness, courage, and respect. The diversity of a team can be embraced through all of these values. The team will come to an agreement on this topic if you help them find their voices.