I'm a new Scrum Master. Should I be updating the team's burn charts?

I'm a new Scrum Master. Should I be updating the team's burn charts?

No! Emphatically, NO! As Scrum Master, you should not be updating the burn charts.

“Why not?”, you ask.

“Isn't my job to help the team? Besides, updating the burn charts is in my job description.”

If this situation seems familiar, you're not alone. The vast majority of Scrum Masters are expected to do things that are antithetical to the role.

Yes, you might find yourself teaching your team some techniques for tracking their progress like a burn chart. Heck, you might even find yourself modeling how to track, but make no mistake, it is not your job to track the team's progress.

Read More

Scaling — What's it all about?

Recent discussions around scaling agile remind me of the applicability of the shu ha ri model in martial art to success in agile. The path to mastery is not found in a cookbook or by taking a pill. As in the martial arts, scaling agile requires starting with the simple and progressing through practice to mastery.

Scaling agile requires starting with the simple and progressing through practice to mastery.
rock.jpg

Getting started is simple

The first step in scaling agile is easy — well, relatively easy compared to later steps. Before you contemplate scaling, first make sure you can create a single effective agile team. At a minimum, to create a single effective agile team you must start by giving the team what it needs to be successful, then listen for their emerging needs, and fulfill those needs quickly. Given the right ingredients and the right support, accomplishing this first step is almost a given barring major organizational culture issues.

But it gets harder

Step 2 gets a bit more complicated. On the surface it's pretty straightforward. Simply repeat whatever you did to create that first effective agile team. Be prepared though. It might not be so easy the second time around. Here’s why:

To achieve the first effective agile team, most organizations do things like dedicate staffing to the team; establish a team room; allocate tools, equipment, environments, and so forth to that team's exclusive use... in other words, remove all of the impediments that might otherwise get it the team's way of being an effective agile team. Then, if anything was missed and the team discovers a new impediment, swoop in and get the impediment out of the team's way.

Removing impediments for the agile team usually has the side effect of further constraining the rest of the organization.
rockwall.jpg

The problem lies in that removing impediments for the agile team usually has the side effect of further constraining the rest of the organization. For example, pulling staff to work on just one initiative, without reducing the total number of initiatives in progress, increases the workload for the remaining staff. Likewise, reserving a conference room for the exclusive use of an agile team as their "team room" takes formerly shared space out of the pool of available shared space for the rest of the organization.

So, while achieving the first team was relatively easy, getting a the second team to the same level is progressively harder. And…

We’re not done yet

Once you’ve proven that you can create a single agile team and then that you can do it again with a second team, you are still not ready to scale. You must now be able to repeat the process that you used to create your first 2 effective agile teams until you have enough teams to meet the demands of the initiative you wish to tackle.

notre dame façade.jpg

And here is where the wheels might fall off the bus. Unless something is done to balance the needs of the agile teams with the constraints of the environment in which they operate, the teams will cease to be effective agile teams — and you can’t scale effectively without the building blocks of these effective agile teams.

Scaling agile changes the organization

The organization’s capacity to make and absorb change limits the rate at which it can create effective agile teams.

The bottom line is that scaling agile requires significant organizational change. The ripple effect of the changes realized by the act of creating a single agile team grows with each additional effective agile team. The cumulative effect of these ripples gives rise to massive waves of change that can overwhelm an unprepared organization. The organization’s capacity to make and absorb change limits the rate at which it can create effective agile teams. Increasing that capacity is ultimately what agile is all about.

 

4 things - self-organizing teams

Organizations steeped in a command and control hierarchical culture sometimes struggle with the concept of a self-organizing team. Releasing "control" to the team is a scary leap of faith and not a leap to be undertaken without proper preparation. Before setting a team loose to find it's own way, here are 4 critical things to put in place to increase the chances of having a successful self-organizing team.

  1. Shared Goal - Establish a shared understanding of the goal.  A shared goal focuses the the team members' energies in the same direction. This laser-like focus leads to quick, targeted results. The shared goal is an essential container for a self-organizing team's creativity, setting both boundaries and direction. Absent an effective container, prepare for chaos.
  2. Dedication - Ensure that each team member is fully available to the team. Part-time is only acceptable if it does not create impediments to the teams' progress (in practice, it is rare that part-time availability does not impede flow).  Dedicate space, equipment, and tools so these resources are always available without delay when needed. Waiting kills momentum and focus.
  3. The Right Stuff - Staff the team with a mix of people that in combination have the appropriate level of knowledge, skills, expertise, leadership, and accountability to get the job done. Attitude and aptitude play a big role as well. Also, provide the things the team needs to do the job including workspace, tools, and equipment. Don't starve the team!
  4. A Sense of Urgency - Give a deadline, leaning towards a shorter timeframe. Agile frameworks impose short iterations during which real, meaningful, and measurable progress is made towards the goal. Deadlines encourage action. As Samuel Johnson said, "Depend upon it, sir, when a man knows he is to be hanged in a fortnight, it concentrates the mind wonderfully."

And finally, listen and respond to the team's needs. A team starting out is never perfectly staffed and outfitted despite best efforts.  If a team discovers a way to improve and needs help to implement the improvement, give them the help they need. With the proper ingredients for success, self-organizing teams thrive and become a powerful, nimble, and effective engine for delivery.