"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: Agile Transformation Anti-patterns

I remember that day like it was yesterday. The click of the camera, the awful picture, the waiting for what seemed like hours and finally, that moment where I was handed, still hot off the lamination machine, freedom, emancipation, liberation – or as you may call it, a driver’s license! That was one of the most memorable moments of my life (don’t tell my wife). And it was hard-earned! All those days of repeatedly practicing K-turns, parallel parking, mastering the art of the 4-way stop and just generally surviving driving in New Jersey! All those skills that we can now exercise in our sleep (but really, really, shouldn’t) weren’t as intuitive or simple back then. It took a lot of practice and more importantly, coaching when we were learning.

Even though I knew that Driver’s Manual inside-out and received only one question wrong on the written exam (which I still don’t know the answer to, btw), I would never dream of getting behind the wheel of the car with just my learner’s permit and a vision to one day own that 1983 Honda Civic. I needed a coach sitting beside me, working with me and guiding me as I was driving. It was nearly impossible for most of us to go directly from passing the exam to the road test. I needed that guidance and practice in my own car.

Getting a driver’s license is the same learning model as becoming a doctor or an Agile practitioner:

• Training and reading build knowledge
• Applying that knowledge so that the desired outcome can be repeatedly achieved is skill
• Repeated application of that skill in different circumstances forms experience

This process, unfortunately, is lost on most sponsors who cause one of the biggest transformation anti-patterns: Coaching not necessary – the thought that one 2-day course or just reading some books will instantly create a set of Agile practitioners. It takes time, dedication, experimentation and most of all, coaching, from an experienced coach that is either in-house or external.

Would you trust a lifeguard who received her certification on the Internet based on an online exam and no practice? What about a surgeon who has never had any internships, residencies or any hands-on experience? Would you trust him to operate on you? I understand that a newly trained Agile practitioner isn’t going (usually) to kill anyone if they miss an iteration goal or their retrospective goes sour but the concept is still the same – getting results from an Agile transformation takes experienced practitioners. Training, no matter how good, will only build knowledge. Applying that knowledge so that the desired outcome can be repeatedly achieved is skill. Repeated application of that skill in different circumstances forms experience. One cannot go from knowledge to experience and one cannot build skills in the classroom. To achieve the desired results from a team, it takes time to nurture and grow them, and that includes coaching along the way.

Don’t get me wrong. I’m not out to say that agile practitioners aren’t bright and can’t apply what they have learned in the class or book within their own environment. But consider your unique environment – your corporate culture and the quirks that are yours alone, your current environment, infrastructure, leaders and their leadership style, organizational structure, incentives, and so on. There are so many parts to the makeup of an organization that sometimes it isn’t obvious how to apply what they have learned. A 2-day course (or even a 10-day course) cannot cover all possibilities. And what about scaling? The more teams there are (esp. distributed teams) the more the challenges the newly trained practitioners face. It gets overwhelming, especially for new practitioners.

In addition, please don’t misinterpret my views about classroom time. I have been an instructor for years. I love teaching and I will be the first to point out that classes and books are an essential start. They add the knowledge which is required to start the journey. However, it will never build skills. Application of that knowledge in your own environment will do that. And the more complex the environment, the harder it is to apply that knowledge. Coaching from someone who has done it before and seen many of the pitfalls the team may be headed for will work with them to navigate the rocky terrain, teaching them within their own context and arming them with the tools to apply that knowledge to make wise decisions. In essence, the coach’s job is to work themselves out of a job. Repeated application of that skill in different circumstances forms an experienced practitioner who, by the way, is your next coach.

Don’t try and save the cost of some coaching and try and get everyone trained instead, thinking those will bring about results. Instead, consider picking a smaller subset of the whole who can be trained AND coached in their own environments, who, because of the coaching, would come up to speed faster, avoid common mistakes and would ultimately coach the next generation. Consider what you may consider an expense may actually be an investment, which will pay dividends for years.

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?

One of the most misinterpreted and misapplied terms in our Industry is the term ‘empowered’. I hear it used over and over from organizations that are new to Agile concepts and have usually know just enough to be dangerous - and dangerous they become. Although I’ve seen this term misapplied in many different roles, it is usually my experience teams that are the biggest culprits, and that’s who I’ll focus on in this blog. Using it more like the term ‘anarchy’, the term ‘empowered’ misused as a reason to get away with everything from reprioritizing the Product Backlog to missing iteration goals. This behavior is one of the most disruptive forces in an Agile transformation.

I thought I’d shed some light on that term and where the term ‘empowered’ does and does not apply.

Let’s start with the definition of empowerment:

em•pow•er•ment [ɪmˈpaʊəmənt]
n
1. the giving or delegation of power or authority; authorization

When it is said that “teams are empowered”, they are given certain authorities where management approval is no longer necessary. This authority is over HOW they work, which includes (but isn’t limited to):

• Own the delivery of an integrated, high quality vertical slice
• Creating, owning and managing the Iteration Backlog – the list of tasks the team collectively needs to complete in the current iteration toward the iteration goals
• Owing their own work-processes – how members of the team work together within the team. This includes, but isn’t limited to, setting up their own meetings, rules of conduct, team norms, etc. – basically those processes that are needed to work effectively as a team
• Being able to create and own their architecture (this may be limited to architecture of a particular section for large-scale development)
• Own their technical practices – be able to practice paired programming, Test-Driven Development, Continuous Integration, Refactoring, etc. without Product Owners or managers telling them not to

However, there are bounds to that empowerment and teams that exceed those bounds are teetering on the edge of:

an•ar•chy ( n r-k )
n.
1. Absence of any form of political authority.

Empowerment turns into anarchy when we here statements like the following thrown around by team members - “We are empowered to...”

• “Change the features in the Product Backlog because we didn’t like what’s there”
• “Change the order of the Product Backlog because the high priority items are boring”
• “Not help our managers, other teams or other colleagues outside the team because we are empowered not to be interrupted” Aside: I actually knew of a team that enclosed themselves behind locked doors so they wouldn’t have to speak to anyone between iterations. I understand empowered not to accept scope creep but not letting anyone even ask a simple question is ridiculous.
• “Deliver nothing!” I knew of several teams that delivered 0, nothing, nada, zip, zilch, you get the picture, for multiple iterations because they told the Product Owners (who weren’t trained, btw) that “the teams were now empowered to choose their own work.” Ummm, no.

So what’s the line between genius and madness - between empowerment and anarchy? Two simple mental models that will act as your litmus test:

1. Product Owners are empowered to decide WHAT features the teams will work on and in which order
2. Teams are empowered to decide HOW they will work on delivering those features.

Two notes to keep in mind:

1. I don’t mean to imply that there is no collaboration but rather final authority on both sides. Teams are welcome and encouraged to give input on priorities but the final decision is the Product Owners and the teams are NOT empowered to override that priority. Product Owners, etc. are welcome to give input and best practices on task breakdown, max. number of hours per task, technical norms, technical practices, etc. but the final decision is up to the team.
2. When you have multiple teams, there may be organizational norms and best practices that the team may have no authority over. It is up to management and ScrumMasters to collectively determine on a case-by-case basis if those are helpful or barriers.

The whole point of these particular empowerments are to create the most innovative and effective organization. It also focuses the different roles to accomplish their goals efficiently. Be wise and watch out for words that are thrown around without making sense.

All projects have at least one thing in common at inception: uncertainty. This may be uncertainty over how best to use a new technology, how to design a new feature, how to learn a new development language or even how to create a new process that will work better for us. Throughout planning, we may be able to identify many of these points of uncertainty but one thing is for certain: these points of uncertainty are some of the main causes of risk within a product development life-cycle.   

The best way to mitigate risk is to take uncertainty out of play. However, the way this is accomplished may mean the difference between a successful project or a gigantic failure. When faced with uncertainty, it is incredibly easy and tempting to fall back to the traditional methods of dealing with that uncertainty:

1.  Make unfounded assumptions and forge ahead confidently, never looking back.

2.   Deny the uncertainty and forge ahead confidently, never looking back.

3.  Brow beat your developers until they say they have a solution (which is all you need to hear as a Manager) and forge ahead confidently, never looking back.

Please comment if any of these methods ever consistently worked for anyone. I’d love to hear from you. 

These methods all center around getting some plan down on paper after some small initial discussions, set it in stone and forge ahead assuming nothing will change. This path is almost certainly ineffective because we have not understood the problem and have no strategy to find the answers to those uncertainties. Why do we do this? Haven’t we learned from the past? Unfortunately, learning from past experiences would mean going against  certain aspects of many organizations’ development culture and uttering the three most appalling, dreadful and hideous words that a developer can say: “I don’t know.” 

We as developers have a stigma around those words. In some organizational cultures, they are taken as a sign of intellectual weakness among peers. In others, it is an expectation from the management that if you are a subject-matter expert, you know what you need to.  The fear for most is hearing those three words thrown back in your face at the dreaded performance review.   If you have other reasons, please let me know.

The truth is that some of the smartest developers I know, the ones I most respect, often say those words and say it proudly. In a true Agile culture, it is not only OK to say those words, it is expected.  It is a sign of greater intelligence. Better to establish we don’t understand the right path than pull something out of thin air (or some other, more undesirable place – use your imagination), even if you are almost certain to be wrong, just so you can appease your peers or manager.

With that said, simply stating “I don’t know” isn’t good enough. It should be followed by “Let’s conduct an experiment.” An experiment in its simplest form is the process of answering a question. “Is design A better than design B?” “Should we build it or buy it?” “Should we use this form of visual management over our previous one?” Whatever needs to be done to answer your question will be your experiment.  It does not have to be long, complicated or over-analyzed. It just has to be enough to either get you to an answer or to unveil the next step toward the answer.

The only way to mitigate or eliminate risks is through gaining knowledge. One of the best ways to gain knowledge is through experimentation. An experiment is simply a way to an answer to our unknowns. Those answers could mean the difference between project success and failure.

I would love to hear more on and discuss more about experiments you have conducted to overcome uncertainty. Please feel free to post in the comments.

And a brave new one it is!  We at Agile Ethos would like to proudly announce the launch of our blog!  It is our outlet to share our knowledge, talk about our beliefs and just vent once in a while.  We are trainers and coaches who believe in what we do – transform organizations to have the highest quality, value to the customer, efficiency and by the way, be a great place to work!  And yes, it is possible!  We’ve seen it happen many times.

We hope to use this blog to share our experiences and insights on what it takes to transform an organization, including leadership, organizational structure, process, culture and technical skills.  Expect many blogs to share and test new and innovative ideas with you.  We hope you’ll comment one way or another.  Expect other blogs to share key learnings that every leader and change agent needs to know.  Expect some blogs to ask you questions and hopefully hear back a few answers and finally, expect a few to just keep you up to date with what’s going on with us lately. 

Our associates have decades of industry experience and have seen, heard and battled much in our professional lives.  Thought our experiences, we hope you will learn, grow and interact with us.   Feel free to post examples and pictures on topics that resonate with you or challenge us respectfully on those issues you don’t agree with so we can dialog about them.  Please let us know which topics would interest you and we’ll do our best to cover them.  Ask us questions you’d like us to answer and we will do our best to respond.  

You can follow AgileEthos on Twitter for tweets about new blogs, subscribe to the RSS feed or simply check back with us every 1 – 2 days for new posts.   Whichever way you follow, we’d like to hear from you.