"Selflessness gives one center.
Center creates order.
When there is order, there is little to do."

From the Tao of Leadership by John Heider, adapted from the teachings of Lao Tzu

Series: Barriers to Organizational Transformation

The Barrier
This is the first post in the ‘Barriers to Organizational Transformation’ series and it is the Friday before Memorial Day so I thought I’d start with something light but important: Those corporate security policies that disallow openly displaying information on walls, hallways, etc.

The Effect
As you can imagine, the problem with these outdated and frankly useless policies is forbidding to put up any vital visual management tools (e.g., task-boards, burn-down charts, defect rates, etc.), architecture diagrams, meeting boards, etc. and have to erase everything from whiteboards at the end of the day.

I have actually been present at sites where we just got through getting the team bought-in and excited about the idea of transparency though visual indicators and information radiators, agreeing upon and constructing the visual information radiators and installed them and then promptly being asked to rip them down by security the VERY SAME DAY! This was not just a blow to morale, but set the transformation back since it was one of the pilot teams. Unfortunately, I see this barrier in almost every client I work with.

The Reason
The reason behind this policy is that they do not want vital information to be seen by someone on the outside, especially corporate spies. While I can understand this, consider the amount of security that needs to happen before someone can even get in, starting with a badge that has to be authorized by a guard or an electronic system. I have seen this policy enforced even when there were 3 separate locked doors standing between the would-be ‘spy’ and the information.

Consider a couple of things:

1. Would someone who can breach physical security not be able to get to your wiki, most of which are available on the intranet w/o a username and password?
2. Is the fact that John Q Engineer is blocked on task #3 on day 5 of the sprint actually useful information? Will your competition’s CEO look at that information and say, “My plan to take over the world is coming together nicely, now that John is blocked on task #3 ”?
3. Even if it is a guest or a customer, would it really matter if they looked at that information?

The Solution
Fortunately, the solution to this, even in the some of the most rigid environments, is reasonable simple (compared to the other barriers, anyway). Meet with one of the managers (the highest-level manager you can get to) of the security group in your physical space and go over the use and importance of these information radiators with them. Explain to them what they are and why they are needed and why the information isn’t harmful and they will usually grant an exception. In many cases, there is an exception form that has to be signed by a manager or director within your group.

Sometimes they will ask you to obfuscate some of the information or ask that just a small part not be displayed or taken down and locked up when not being used. We concede to some of these, especially architecture. Many of those are easily resolved by doing what we need on the whiteboard, taking a high-quality picture (or set of pictures) and displaying them in a secured site.

I once had one of these meetings where they said everything is allowed to stay up as long as you write the codename backwards. We had to laugh at the fact that we have a codename for a codename. Like someone from the outside is going to look at it and say “utkubmiT? What’s that? Darn-it! My plans are foiled once more!” None-the-less, it was a small price to pay and we complied.

Do you have any war stories with this barrier? Please share. We’d love to hear them.

Series: Agile Roles and Responsibilities Series

Many pundits preach that the agile organization will not have managers – that teams will self-manage and can carry out all responsibilities of traditional functional management. This includes HR responsibilities, major conflict disputes, etc. “The team is self-managing, which includes all management responsibilities,” or so I keep hearing. Call me a heretic, but I’ve never subscribed to the scalability of this model. For most large-scale (esp. global) organizations, this is not a reality. Not only are functional managers not going anywhere, but they are, in-fact, essential to an organization’s transformation to Agile practices. However, their roles will need to change. Whether they embrace or reject this change could mean the difference between success and failure going forward.

To highlight the differences, let’s lay out the major responsibilities of a traditional functional manager:

1. Handle HR functions (e.g., Hire and fire/lay off, harassment, physical violence, larger-scale verbal assaults, etc.)
2. Champion causes/break down barriers
3. Maintain standards (quality, technical, ethical ) across the different teams
4. Develop employees technical and other necessary skills
5. Create, manage and restructure cross-functional resources
6. Execute performance evaluations
7. Set up work processes (esp. for their team)
8. Break down and assign tasks
9. Project manage the team (usually with a gigantic Gantt chart and a weekly status meeting)
10. Be responsible for the team’s commitment and deliverables

(I’m sure I could have listed another 20 responsibilities but I tried to focus on the top 10. If you feel there are important responsibilities I didn’t cover and a through on whether an Agile manager will retain or relinquish them, please feel free to list them in the comments.)

So what in this list changes? That can be answered by the overarching mental model: The Agile management (as a whole)’s mission is: To do what needs to be done to create an innovative, flexible and continuously-improving environment that will allow teams and Product Owners to succeed. This means creating an organization that is capable of executing Product Backlog changes at any time (including at the 11th hour) as efficiently and with the highest quality possible.

To accomplish this, Agile Managers would still handle responsibilities 1 through 4 - traditional HR functions, develop employees, set up and maintain standards (optionally with the help of Agile technical leads) but will hand over the their project and process management responsibilities (given in steps 7-10) to the ScrumMasters (if practicing Scrum) and feature teams.

But why give up those traditional responsibilities of ownership, assignment and management of tasks? Several reasons come to mind (feel free to add to or contest these):

• Allows the team to own their commitment, and just as important, own it as a team
• Allows the team to focus on the greater iteration goals instead of just their individual tasks
• Empowers them to self-improving

Many managers are concerned this hand-off of responsibilities diminishes their role. I feel it is quite the opposite - that it focuses their role and elevates it to a more strategic level. Instead of being consumed by tasks that teams are perfectly capable of performing themselves (albeit, teams usually need help at first), Agile Managers will now work as a group to see which changes need to happen organizationally – those that we never saw before or saw but were too busy (or un-empowered) to do anything about. This change will let them focus on:

• Setting up and managing cross-functional teams
• Creating and managing needed infrastructure (e.g., testing platforms, continuous integration, etc.)*
• Break down organizational barriers, usually raised by ScrumMasters and teams through Daily Scrums and Retrospectives or similar events
• Create and manage technical standards across the organization (with the help of teams and technical leads)
• Creating, training and supporting change agents (e.g., ScrumMasters) within the organization

*Note: I don’t mean to imply that the managers code the infrastructure themselves (although, they are free to do so if they want). I just mean they will look at the largest gaps and create internal teams to work on them as needed.

Item 5 deals with the creation, allocation and evaluation as teams. The Agile Manager still own this responsibility but performs it very differently than they would have traditionally. They don’t design the organization by architecture, layer or component (e.g., the GUI team, OS team, driver team, database team, etc.) but rather by vertical features. Additionally, a set of Agile Line Managers should treat all resources reporting to them collectively as a pool of resources where teams can be “pulled” from, instead of individual resource ownership. This means that Agile Managers will collaboratively assemble the best teams for a group of features and not just have teams by virtue of reporting structure. (I will follow this up with a deeper post on this topic).

Last in the list is item 6, which, like item 4, is also a transformed activity owned by managers. Managers are still responsible to perform evaluations but they will do this based primarily on the team’s performance rather than an individual. It is also a great practice to do this as a team of managers, instead of individual evaluations. (We’ll debate the right performance measures as well as the idea of abolishing performance reviews on another post).

Finally, it is up to the managers as a whole to set the culture to continuously improve and continuously experiment to do so. An Agile manager’s motto should be “It’s OK to Fail”, as long as we do it fast and learn from it toward the right goal. They know that the phrase “I don’t know” is a much better phrase than an uncertain answer based in no data or reality given because one is expected.

The fact is that Managers make or block Agile transformations. There is a lot of talk of top-down leadership and bottom-up push but the managers connect these domains. They are the ones that can greatly accelerate or critically hinder a transformation. Which camp are your managers in?

Series: Agile Roles and Responsibilities Series

Anyone who knows me knows that I love ScrumMasters.  My family had to get used to the idea of being second in line, but they’ll get over it.  Why the love affair? Simple.  They are the organization’s change agents!  Their #1 role is to continuously create positive changes.  (FYI, if you thought that the role of the ScrumMasters is to be a simple project manager or task-master, read this first: ScrumMasters are not Task Masters)

They create positive change by:

• Setting up, owning and upholding the process of Scrum
• Ensuring that the process is followed by all
• Identifying, escalating and having barriers broken (this doesn’t mean they necessarily do the breaking)
• Teaching the process of Scrum to all parties
• Working with Product Owners, managers and the development team (including architects, testers, etc.) to evolve the organization
• Leading a team to increase their productivity (velocity)
• Facilitate the roles within the organization to work efficiently, effectively and most importantly, together
• Being enablers, problem solvers, and more…

The amazing thing is that the ScrumMaster role doesn’t call for any managerial authority over the team, Product Owners or other managers.    They lead by influence, not by authority.

Although SMs are an essential part of the team, they are not wholly devoted to just their team.  This means although the SM belongs to the team, they are not just there for the team.  If the SM is doing their job correctly and efficiently, they are working 1/3 of their time with the team to deal with team issues, break barrier, 1/3 of their time hand-in-hand with POs and 1/3 of their time with Management.   So with all this, when do they have time to code?  In my humblest of opinions, they don’t .  The ScrumMaster is a full-time role – but before you jump all over me, that is a different post and discussion.

When a team is newly formed, this balance will be shifted more toward the team but over time, new teams will be comprised of members that have done this before and not need to take so much start-up equity from the SM.   So, what are SMs doing with each of these three roles?  Helping them meet their goals. Removing barriers when possible and escalating barriers when appropriate.  Installing, teaching, upholding, and most importantly, evolving the process of Scrum within the organization toward the very concrete goal of reducing defects and increasing velocity (in that order) for the organization collectively (starting with their team).  This means working with the POs to complete the release plan, working with teams on iteration planning, reviews and retrospectives and working with management on what they need to do: Transform the organization into an agile organization that can move to the beat of the Product Owner (Yet another post). 

This, however, does NOT mean that SMs project manage.  The teams and Product Owners need to do that themselves. The ScrumMasters are ensuring that the release and iteration plans are being set up and helping evolve the process, not doing that work for the team.

I could write a book on the topic so forgive me if this bite size morsel is leaving you in want.  I will be filling in many of the gaps in future posts.  As always, I look forward to your comments.

Experimentation is the key to learning and continuous learning is the core of Agile and iterative methods.  A wise man once told me that we know the least about our product and the optimum process to build that product when we first start. I could never (or never wanted to) argue that point. When we are at crossroads facing an unknown path, experimentation lets us understand which avenue is best. 

Experimentation means to find that path wisely. Don’t get into analysis paralysis. Here are some suggestions to make your experiments a success:

1. Make your experiments iterative so that the lessons from the initial ones can be used to plan and create the next ones. 
2. Make your experiments short and tactical so that you can learn quickly about what works, and more importantly, what doesn’t work. 
3. Finally, and most crucially, an experiment that fails is just as important as one that succeeds.  The answer will guide you on how to proceed from that point. Don’t be tempted to think that a set of experiments that ‘fail’ aren’t a success. The experiments simply yielded an answer. 

If you have more suggestions on how to conduct a good experiment in your environment, feel free to post them in the comments. In addition, if you’ve learned something that changed the way you work through experimentation, please share it with us.

Series: Agile Roles and Responsibilities

It always bewilders me to think about the amount of teams out there who designate the ScrumMaster as a ‘Task Master’. In these teams, the ScrumMaster’s role is often seen as that of an administrator. This ScrumMaster schedules, plans and runs the meetings, including the Daily Scrum.    His job is to make sure all the perceived overheads of the iteration are completed so that the team can focus on their “real” job. “Come around and get our hours every day so we don’t have to input them,” the team may say. “And while you’re at it,” they may add, “be a dear and handle any interruptions that come our way, would you?” However, this is a mistaken notion.

ScrumMasters are called what they are for one very simple reason: They own the process of Scrum.  They have one of the most complex and difficult jobs in the development organization: To create and maintain the processes by which we work. In short, they need to be change agents. 

I don’t mean to imply that ScrumMasters don’t work within the team. On the contrary, they work intimately as a part of the team to help create and adapt processes within the team. However, they aren’t the ones that manage the team and the team’s meetings and events – the team itself does that. It is perfectly fine for the ScrumMaster to perform those activities when working with a newly formed team but with the understanding that those are owned by the team and will be transitioned to the team as soon as possible.

What, then, should the ScrumMaster be doing once those items are transitioned? Everything else that falls under the ‘own the process of Scrum’ category. This includes working with Product Owners just as intimately as the team, to help with release planning and tracking, bridging the gap between the Product Owner and the team. This also includes working with existing management to solve deeper organizational issues that is beyond each team. Finally, they are responsible for working with other ScrumMasters to maintain a coherent process across the organization. In the end, a well balanced ScrumMaster will work in equal parts with the team, the Product Owner and the organization. 

This may be a good time to mention that the role of the ScrumMaster is a full-time one, but that is another blog entry.