Interview with Madhur Kathuria

Madhur Kathuria has coached nearly 300 teams for almost 75 clients across the US, Europe, South East Asia, Malaysia and Thailand. In this interview he talks about some of the cultural challenges for agile adoption. Read it here.

Interview with Elena Yatzeck

Elena was Chief Agilist for JP Morgan Chase Treasury Services and is now a VP of Corporate Compliance Tech. Find out how JP Morgan Chase reconciles agile with compliance and risk management demands. Read it here.

Tuesday, November 25, 2014

An Agile Transformation Thanksgiving

How to become less agile through eating too much on Thanksgiving!

Transformation: Converting your waistline from loose casual slim and trim to post-holiday tightness and regret! This will make you less agile!

Self-organization: Everyone gather in the kitchen, and just start cooking! (The more cooks, the better!)

Planning Session: When planning the Thanksgiving meal, everyone gathers in the kitchen and talks through each dish they want. There are too many dishes, so write each dish on a post-it note, affix them all to the fridge, re-order them, stand back and make them all anyway!

Standup (before the meal): Once every hour, everyone stops what they are doing (hopefully cooking) and explains what they are cooking and which wine goes best with their dish. Now take a drink of that wine. Since you are a team, salute the person talking and everyone take a drink. If someone misses the drink, start over. Keep drinking until you get it right.

Standup (after the meal): Once every hour (unless you are asleep), everyone stops what they are doing (probably watching football), get up from your recliner (if you can) and go back to the kitchen. Tell each person (who manages to get there) what you’re going to eat next as you make your rounds.

Taste-driven cuisine (TDC): Taste the dish before you even make it! Pretend to dip your spoon into it, and bring it to your mouth, and prepare to go “ahh!” – but only to find the spoon empty. Keep doing that as you cook until you really do say “ahh!!!”

Crumb master: the dog gets everything that gets dropped! He’s always around, sniffing here and sniffing there, poking his nose everywhere, but doesn’t really do anything! (except provide an essential glue that holds the family together!)

Culture challenges: Get ready for making smalltalk with relatives who you see once a year. And be prepared to listen hard to those who you have trouble understanding, or who spit when they talk, and smile! Drink lots of wine – that helps!

Continuous delivery: “George – bring out the first turkey!”

Sprint 0: The “idea” you have that not eating before this meal will let you eat more. The more time you spend not eating the more you will be able to eat. Also, the amount of running that you can do after dinner (zero).

Executive leadership: Mom is in charge. There is no servant leadership here!

Dealing with interruptions: The dog just won’t stop barking! The doorbell keeps ringing! Kids keep running through the kitchen! “Oh no! – I just poured orange juice into the cake mix! – hey, that might be good!”

Automated deployment (pre-production): It’s 2014, and the guys still just sit at the table while the women serve them. ;-(

Automated Deployment (post-production): The rush of air felt when dinner is over and the mass exodus to the living room occurs.

Refactoring: When you run out of wine and have to switch to beer!

Sustainable pace: Eat slowly, or you will get full before the meal is over. Make sure you leave room for that final “Lardening Sprint” – dessert!

Retrospective: “I can’t believe I ate the whole thing! And now it’s time to clean up – gosh, now I wish we had used fewer pots!”

What are your Agile Transformation Thanksgiving ideas? (add as comments)

Transformed! - Not very agile anymore

Tuesday, November 18, 2014

Modes Of Leadership In Agile Transformation

“There are spear chuckers and spear carriers.”

That is what a friend of mine once told me. He had been captain of a nuclear submarine, and so he had a very well developed sense of what leadership was – at least in his world.

The metaphor bothered me, because I am not a spear chucker or a spear carrier. I told him that I was a spear maker. He gave me a blank stare: in his world, the spear makers are military contractors, and they do their work pretty much out of site – before anyone boards the submarine.

Software programmers are spear makers. We are not thought of as leaders. Yet Agile requires us to be leaders: Agile does not work unless team members show leadership. More on that later.

At the organization level, Agile transformation requires leadership as well. The notion that “executive leadership is necessary” is well established. And in the Agile spirit, it implies lots of self organization. But what does that look like? What types of leadership are in play?

Leadership context

Two important contexts of leadership are (1) individual/self, and (2) team/organization. Individual leadership is about personal development. Team leadership is about one’s interactions within a team. I will defer talking about individual leadership until the end of this article.

Team leadership context

If one has a position of explicit authority within a team – e.g., you are the team’s “boss” – then it is useful to talk about the relationships between the team leader and the subordinates. Leader-Member Exchange Theory (LMX Theory) is a widely used model for this. Relationships among peers within the team is also an important element. LMX Theory claims that an “in group” tends to form within a team. The “in group” is the portion of the team that the leader trusts more than the other team members. Getting into the “in group” requires demonstrated loyalty.

Leadership within a team does not always
take the form of explicit authority.

On the other hand, leadership within a team does not always take the form of explicit authority. One can play a leadership role by winning the confidence of others in the team. Further, there can be multiple leaders within a team.

Leadership in a hierarchy has other dimensions: the upward and sideways dimensions. If one has a leadership role within a team, one sometimes might have to represent the team to one’s boss, and to other parts of the organization. This time though, one is representing a team – not merely oneself. The table breaks all this down.

Table 1: Contexts of leadership
Individual context:
1.    Inward focused: Individual leadership (personal context).

Team or organization context (LMX Theory):
1.    Inward focused team leadership: managing subordinates.
2.    Outward focused leadership: representing oneself and one’s team to peers and superiors.

The lines between these modes of leadership are actually very blurry. For example, what constitutes a “subordinate”? If a team has an assigned leader, with explicit authority, then that person is clearly a team leader and the others are subordinates. However, there might be other leaders on the team who have earned a de facto leadership position by demonstrating good ideas, or simply by being persuasive. Leadership is often informal. The official leader might even find him or herself competing with informal leaders, putting the official leader into the position of having to continually demonstrate outward focused leadership to maintain his or her credibility to the team. Forming an “in group” is a tactic that enables a leader to hold onto their authority, by creating a buffer of “informants” and loyal supporters. On the other hand, informal leaders can arise within a group and challenge the official leader. Informal leadership is a source of “cronyism” and corruption in organizations, but can also be a source of great strength.

All three of these leadership contexts are important for Agile transformation, as we will see.

Leadership styles

By “style”, I am referring to the way that you exercise leadership, e.g., by being a bully, or by “killing them with kindness” – or perhaps by simply being the person with the most actionable and understandable ideas. Some schools of thought distinguish leadership styles as “modes”, reflecting that an individual can assume different modes depending on the situation. This is sometimes called situational leadership.

There are limitless styles of leadership – as many as there are leaders. However, a particularly good taxonomy of styles is described in this article: 8 Common Leadership Styles. I summarize some of those styles in the table, and add a few.

Table 2: Leadership styles
Charismatic – Inspires. May be egotistical. People follow because they trust and believe. Examples: Steve Jobs. Adolf Hitler.

Innovative – Able to capitalize on situations. Leads by creating opportunities for others. Example: Elon Musk.

Command and Control – Intensely goal focused and demanding. Leads by explicit authority. Example: a military commander in a live mission situation.

Laissez-Faire – Sets an example, and advocates. Leads through personal credibility attained through prior achievements, reputation, or status. Example: Lawrence Lessig.

Pace Setter – Creates a high pressure environment of high expectations. Leads through setting an example of working extremely hard. Example: Ross Perot.

Servant – Works by enabling others. Leads through explicit authority, but exercises it only by facilitating collaboration and removing obstacles. Example: a Scrum Master.

Transformational – Creates change at a fundamental level, enabling “breakthrough” change to create behavioral patterns that are completely new to those involved. Leads through helping others to understand themselves better and understand their situation better. Example: a group therapist.

Political – Adept at negotiating win/wins with others. Leads through identifying – or creating – mutually beneficial situations with others. Example: any successful politician.

Competitive – Sees everything in terms of a zero-sum game. Leads through aggressively out-thinking others. Example: managers who compete for budget in an organization.

Collaborative – Tries to find the solution that is best for everyone as a whole, and involves others to do so. Leads through arranging discussion forums, establishing new paths for communication, and creating a large social network. Example: the authors of the Agile Manifesto.

Rule oriented – Needs explicit authority to lead, and focuses on having clear boundaries defined for who is supposed to make each type of decision. Leads through having authority granted by an accepted source of authority. Example: a police officer.

Again, these styles are not definitive any more than a list of personality types is definitive: these are only named generalizations to help us to discuss approaches to leadership. You might be able to think of some styles to add to the list. In practice, people use a combination of styles with their own unique personality traits thrown in.

Team Leadership

Inward Focused

Inward focused team leadership involves the interactions between the leader and the team. In other words, it is about the internal dynamics of the team – not the rest of the organization or the outside world.

Inward focused leadership tends to be relatively invisible outside the team except in its outcomes, unless there is such a severe problem that team members revolt.

Inward focused leadership is the mode of leadership that is most often discussed in articles on team leadership, especially in the Agile community, which has had an inward team focus from the beginning.

Transformational approach

Good Agile coaches use transformational leadership. IT executives who want to transform their organization should also use transformational leadership. This entails viewing things as a system, performing introspection on the causes and effects, and changing things in a strategic way so that the desired new behaviors are inevitable and sustainable. A very useful tool for this purpose is constraint analysis: What are the things that are preventing movement toward Agile? Then, consider the causes of those things, perhaps using the Five Whys method, and remove those constraints. And do this not on your own, but by leveraging the thoughts and ideas of the people in your organization.

One of the goals of strategic transformational
leadership is to convert strategic decisions
into repeatable tactical decisions.

One of the goals of strategic transformational leadership is to convert strategic decisions into repeatable tactical decisions that collectively advance the organization towards the strategic changes that are desired. For example, instituting Agile coaches to help teams is a repeatable tactical practice that will have a strategic impact over time.

Transformational leadership is so important for Agile transformation that we will have a series of articles about it.

Servant approach

Scrum Masters use servant leadership. A servant leader is someone who leads softly, by educating, by suggesting, by facilitating, and by enabling. A servant leader sees it as his or her job to remove obstacles for the team, to instruct the team, by advise the team, and to encourage the team to identify and discuss important issues and reach decisions.

Servant leadership is not an abdication of authority.

On the other hand, servant leadership is not an abdication of authority. As James Hunter puts it in his book The Servant, “The leader should never settle for mediocrity or second best – people have a need to be pushed to be the best they can be. It may not be what they want, but the leader should always be more concerned with needs than with wants.”1

For example, a servant leader might propose – might even insist on – certain collaborative routines (such as standups and the discussions that should follow), or assessment practices (such as measuring team velocity), if the leader thinks that that is what the team needs to become more effective. In other words, the leader needs to exercise judgment. There might be teams that are very innovative and can come up with even better practices for achieving the goals, and a servant leader should have an open mind, and when in doubt, lean towards deferring to the team. That is not an absolute though.

Command and control approach

This approach is appropriate for situations in which unexpected things can occur and it is difficult to have discussion to collaboratively decide what to do. For example, in a situation of urgency, such as fighting a fire or a military operation, direct command and control is essential. When seconds count, there is no time to explain a decision or ask for ideas: immediate coordinated action is needed.

Collaboration is extremely important for military operations, but the collaboration occurs before and after the operation – not during. For example, Steve Crago – a former US Marine Corps member and now an Agile coach – says,
“What Scrum would call a Retrospective, the military labeled an After Action Report (AAR). AARs were conducted after every field exercise and/or mission. The difference between an AAR and a Retrospective are varied. AAR’s have a prescribed format and are usually attended by the leadership… each team would brainstorm ways in which to perform at a higher level. We spent hours and hours looking at various ways to do something; and our more experienced leaders at the Team, Squad, and Platoon level were continually showing us how to do something they had learned on previous missions and/or exercises. As I moved up the ranks, I added what I had learned experientially to the knowledge base that was imparted to me; and just like those who had gone before me, I began to train others to find a more efficient, effective way of performing tasks.”

Thus, it is often the case that different leadership styles are appropriate at different times. After a mission, a military leader transitions from command and control to a more collaborative approach. If you are a parent, you probably make these transitions all the time: you might generally want to be mostly a servant leader with your child, but if the child is in danger, you transition to a command mode and direct them what to do, and once the danger has passed, you might transition back and have a “retrospective” to discuss the dangerous situation with them and learn from it.

Command and control leadership can be very destructive if it is used in the wrong situation. It does not utilize the collective insights of the team, and it can make people feel disempowered and helpless. The “bad boss” is a common problem in organizations – managers who give orders but who do not seek the input of their team, or micro-manage how team members do their work. This causes low morale and poor productivity.

Other approaches

The right approach for leading a team is to do whatever works. If the team members are miserable and are not able to have their best ideas adopted, or are not able to work in ways that are most effective for them, then the team as a whole will not be effective. That said, leaders sometimes have unusual traits that compensate for what would otherwise be destructive behavior. Steve Jobs is a famous example of a leader who was autocratic and abusive, yet he was extremely popular within his company, generating great loyalty, and led Apple to great success – twice.

Charismatic leaders inspire others, creating a
belief that there is a worthwhile goal.

Richard Barrett pointed out to me once that Jobs’ success is not evidence that that bad behavior was not destructive: it is possible that if Jobs had been less abusive, then his organization might have been even more successful, or successful sooner. We cannot know. What we can know is that Jobs’ negative behaviors did not prevent success. So what was it about him that generated such a loyal following? Jobs was an example of a charismatic or inspirational leader. Charismatic leaders inspire others, creating a belief that there is a worthwhile goal. If people are committed to a goal, they will tolerate a leader’s quirks. Still, it might be that if those quirks were overcome, that people would be able to perform even better, so even charismatic leaders can have room for improvement.

You might also find that different approaches work at different stages of a person’s or team’s development. When my son was in his early teens, I found to my great disappointment that he only listened when I exhibited anger, so I had to present an attitude of anger to get his attention. That was unique to him. As he grew older that changed, and I was able to use calm reason and sensitivity instead, which was much more pleasurable. A leader needs to be sensitive to what is effective, given the personalities and capabilities of the team, and where they are in their development. This adaptive approach is central to the shuhari method, in which an autocratic leader demands that the student follow instruction and rituals rigidly but once the student has reached the Ha stage, the instructor also engages in introspective discussion with the student. Whether this rigid approach is appropriate for a software team is debatable, but it could be that it is the best approach for certain things, such as when particularly sensitive software modules must be built.

Outward Focused

Outward focused team leadership is about interactions with your environment. If you are a member of a team, but not its designated leader, then your outward focused leadership is about the way that you represent yourself to the other team members. If you lead a team, outward focused leadership is about representing and advocating for the team to the rest of the organization. It includes creating the team in the first place and defining its purpose (“charter”) and scope of action. It includes representing the team in discussions for resources and authority to act, and whatever else is needed to enable the team to perform its purpose.

Outward focused leadership is the mode of leadership that articles about business often emphasize because it is market facing, board facing, and it exhibits power – which is attention-getting. This article is a great example. From the article:
“The best human beings are collaborative, compassionate, empathetic and free of most defects of character. But the best leaders usually are not. By “best leaders,” I’m talking mainly about people who consistently show the ability to get things done—the ability to sell others on an idea, the ability to take them in new directions, the ability to talk their way out of a jam, the ability to come back from a setback, and so on.”

In terms of LMX Theory, outward focused leadership is about your relationships with your superiors and your peers.

Adapt to the situation

Servant leaders often have to take on a different leadership style when performing outward focused leadership. For example, if the team’s project competes with other projects for budget resources, the team’s leader needs to be somewhat aggressive on behalf of the team to ensure that its funding continues. The leadership styles that are potentially effective in that situation are charismatic, innovative, political, competitive, collaborative, and rule oriented. However, the styles that are likely to be most effective are charismatic (if you can pull it off), innovative (if you truly are), political (if you have the knack and like to schmooze), and collaborative (if you are very persuasive).

The right approach depends on your own
abilities as a leader.

So the right approach depends not only on the situation, but also on your own abilities as a leader. Scott Beilke, a principal consultant at Brighton Leadership Group, puts it this way:
“A Sweet Spot exists at the intersection of three areas of [leader’s skills and commitment to change, what change is needed, and the organization’s culture] for any business transformation (Change). It is critical for leaders to get context clarity on these areas to make the difference between a resounding successful change and a crashing failure.”

Team leaders also need to represent the team to a community. When Steve Jobs would speak about upcoming products, he was representing Apple to the world. His “One more thing” announcements were commitments about what Apple would be doing – exciting products to come. In that situation, it helps to sound authoritative, and to put on a charismatic, and possibly even a little command and control, attitude, since your objective is to sound authoritative.

Leaders need to represent their teams in a more mundane context as well. If a senior manager wants to know how the team is doing, the team leader is available to explain the progress and challenges for the team – sometimes information radiators are not enough. Managers like to have a point person with whom to discuss issues one-on-one, in order to circumvent politics and be frank: i.e., to have “powerful conversations”. We have to remember that while Agile promotes transparency, it is unrealistic to think that politics does not operate in all organizations – even Agile ones – and one-on-one discussions are essential for managers to be able to work together. To enable that, teams need leaders who can speak for the team.

Leading without authority

Personal outward focused leadership is very important for Agile teams because Agile relies on a large amount of self organization – i.e., no one is going to tell you what to do at every step. Some Agile teams do not have a designated leader who has actual authority within the team: the team is expected to identify problems, discuss them, and take action. Everyone needs to exhibit leadership for this to work optimally. If only a few people on a team exhibit leadership, then they will have an unfair burden and will not be able to spend as much time as they should on their own work, and also the team will very possibly miss many issues that need resolution.

Informal leadership can be constructive or destructive.

Informal leadership can be constructive or destructive. If a team member is able to cause others to trust him or her, that trust can be misused. In Jim Collins’ latest book, From Good To Great, he states that, “the first job of a new leader is to get the right people in the right seats.”2  The sources of group dysfunction are myriad. Also, groups tend to go through a series of stages in which power structures compete and eventually stabilize – and not always in a good way. In terms of the Tuckman model which is widely quoted in the Agile community, the team can end up in a “performing” state that is far from optimal. According to the Wikipedia article on the Tuckman model,
[The Storming] phase can become destructive to the team and will lower motivation if allowed to get out of control. Some teams will never develop past this stage. Supervisors of the team during this phase may be more accessible, but tend to remain directive in their guidance of decision-making and professional behavior. The team members will therefore resolve their differences and members will be able to participate with one another more comfortably.

In other words, a self-organizing group is not guaranteed to reach a healthy Performing stage without intervention by management.

Extroverts and introverts

People who are extroverts tend to naturally exhibit leadership in teams. People tend to like extroverts and develop trust for them. Introverts have a more difficult time establishing trust because they interact less, and often interact less effectively. Thus, introverts can sometimes find it difficult to exhibit informal team leadership, even if they have ideas that are worth listening to. This is why many teams need an explicit leader, to ensure that everyone on the team is able to be heard, contribute, and exhibit leadership.

This is especially important for Agile because IT people tend to be more introverted than the normal population. It is fascinating that in surveys in which IT people self-assess, they report that they are extroverted; but in objective surveys, IT people are actually introverted as a group. From a 2002 paper in the International Journal of Human-Computer Studies, Personality Types In Software Engineering,
“The personality type most prominent is a combination of introversion, sensing, thinking and judging. ISTJs assume responsibility readily and tend to persevere. From the data it can be deduced that the majority of software engineers (ISTJ) are technically oriented and prefers working with facts and reason rather than with people.”

Thus, as a group, software developers are introverts but do not know it!

Many introverts view Agile with some anxiety. From this blog post,
“…pair programming, bullpens, stand-ups, and scrums. We talk about close collaboration, about embedded customers… Who wouldn’t want to use such a system? Well… introverts.”

We need to consider this when thinking about the ways that Agile teams will self organize and be effective. In particular, if there are some extroverts on a team, we need to make sure that they do not dominate the group. We also need to make sure that discussions are occurring in a way that is effective for everyone, because introverts and extroverts think and discuss issues differently. Simply putting them all together around a whiteboard is not always the most effective approach.

Individual Leadership

This is the type of leadership that you exhibit yourself when you take the initiative to improve yourself. If you realize that you need to learn a new skill, do you set out to do so, or just think about it? Do you reflect on your abilities and personality traits, in the interest of personal growth? Do you listen carefully to others when they comment on your ideas or your character? These are all elements of individual leadership.

Individual leadership is extremely valuable for a happy, successful and productive life – no matter what profession you are in. As Richard Barrett says,
“Organizational transformation begins with the personal transformation of the leaders...The chief executive officer (CEO) or the leader of the organization must be willing and committed to his or her own personal transformation to change the culture. The leaders must live the change they want to see in the culture of the organization. For each member of the leadership group, personal alignment to the organization’s values and group cohesion around the vision, mission, values, and behaviors must become part of his or her personal journey.” 3

Taking the initiative to learn is part of individual leadership. Agile organizations need to have people who are continuous learners. Gone are the days when you learned a skill and used that skill for the duration of your career. Nowadays – at least in IT – skills change every single year. Today’s tools seem like the greatest thing, but three years from now only half them are still in use. Ways of working change too – Agile is an example of that. People can no longer wait to be trained: they have to take the initiative, and this is never-ending.

Ironically, the foundational skills that are durable are the most valuable, but in the IT profession companies do not usually seek those: things like experience with object oriented design, experience building secure and maintainable systems, experience with design patterns, experience at solving problems and learning new things – all those things will get skipped over on a resume. Recruiters scan for the current tools – today they are NodeJS, Cucumber, and whatever – tomorrow they are something else entirely. The truth is, programmers need to continually learn new things in order to stay relevant – they are accustomed to this. Being proactive in learning new things is a form of self leadership. Agile expects it, demands it.

In a future post I will look at the situations in an Agile transformation and the kinds of leadership that they require.

1. Page 66, “The Servant: A Simple Story About the True Essence Of Leadership”, by James Hunter, © 1998, published by Crown Business. 
2. Jim Collins. Good to Great. New York: HarperCollins, 2001. 
3. Barrett, Richard (2006-08-14). Building a Values-Driven Organization (Kindle Location 1143-1156). Taylor and Francis. Kindle Edition.

Tuesday, November 4, 2014

Key Transformation Decision: Adopt an Out-Of-the-Box Approach, Or Craft a Unique Approach?

Organizations like quick answers. If you need to get into a new market, buy a company that is in that market. If you want to make your IT function more agile, pick an agile framework and “install” it. Such frameworks include Scrum and Scaled Agile Framework (SAFe). Both of these provide certification regimes, which organizations like because it turns the skill set into a commodity that can be purchased – i.e., “installed” in a repeatable manner.

Many people in the Scrum community will object at this point: they will claim that Scrum should not be conflated with SAFe. Indeed, the two are descriptions of agile at very different levels. However, each one is a prescriptive model for how to implement agile, whereas the Agile Manifesto is a set of values and principles that one can implement in an infinite variety of ways. So yes, both Scrum and SAFe are “out of the box” frameworks.

That is not a bad thing. Scrum is a great approach for team level agile. SAFe has some really great ideas in it for how to support agile projects in a large organization. These frameworks serve as excellent models for thinking about how to do agile, and in fact it might sometimes be possible to implement them exactly as they are defined. But that is not always the case.

The real question is, what should an organization do to get started with agile? Should it try to adopt a framework? Or should it think through the Agile Manifesto – and other spheres of thought, including Lean, org change, and so on – and define its own path? This is an important strategic decision, and it is important to get such key decisions right early on. (See the article It Is Important To Get Key Choices Right.)

The argument for using an out-of-the-box framework is that it has all been thought through and tried and tested. But that does not mean that it can be applied successfully in every organization; nor does it mean that the path to implementing the framework will be easy. In fact, these frameworks are really future state models, but the hardest part is figuring out how to get there.

One problem with using a framework as-defined is that doing so is inherently non-agile. From that point on, the team looks to the “expert” for guidance on how to do their work.

One problem with using a framework as-defined is that doing so is inherently non-agile. If you force a framework on people, and give them an expert in that framework, you have essentially taken their process away from them. From that point on, they look to the “expert” for guidance on how to do their work. This is completely contrary to the agile value of “Individuals and interactions over processes and tools”, and also contradicts the agile principle of “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done” – i.e., trusting people to figure out how they should do their work. Giving someone a framework and saying “do that” is telling them how to do their work, and is contrary to agile values and principles.

An alternative is to bring in an expert in agile – ideally someone who is knowledgeable of multiple frameworks and multiple spheres of agile thought – and have that expert discuss the agile values and principles with the team in the context of how the team is currently doing its work. Then, work with the team to apply agile values and principles to come up with improvements to how they work. The frameworks can serve as sets of ideas for how to improve things. These improvements can be incremental or radical, depending on the team’s appetite for change – but the team is then in control of the change. The team owns their own process, and does not need to ask the “expert” for permission to try something new.

Let me be clear here that I am not against Scrum or SAFe, or any prescriptive process – in fact, I think they are really important agile models. It is just that I think that teams should decide on their own process, and not have someone tell them that they should use Scrum or SAFe or use these in a certain way. The team needs to be able to understand every change they make to their own process, and have their own performance improvement goals for it. If you give them an entire canned process, and tell the team that all of the practices work together, then the team does not know what to expect: they have to trust the expert and accept on faith that the new process will work. They don’t truly understand it – only the “expert” does. The team has to wait until they have also become experts before they can appreciate the new process. That is not an agile way to do things. That is “big process up front”. It is command-and-control. It is all at once, rather than incremental. It is about “processes and tools” rather than individuals and interactions. It is exactly what we tell people not to do, when we tell them to “be agile” rather than “do agile”.

The Alternative: Take an Issue-Focused Approach

Rather than starting out by telling a team that they need to adopt a framework that they do not yet understand, talk to the team about their challenges. Take an issue-focused approach. Does testing result in lots of rework? Are there bottlenecks, possibly due to certain people having certain tasks that others have to wait for? Is there contention for testing environments? Is there a requirements or design document, but no one to ask about it? And do the requirements or design sometimes need to change, but changes require an onerous change control or review process? Are there third parties who need to perform tasks such as independent testing or security review, and those tasks take a long time and can potentially hold everything up, or result in lots of unanticipated rework?

These are all tangible issues that agile – including frameworks like Scrum, eXtreme Programming (XP), SAFe, Lean, and other agile models and schools of thought – can help with. For example, on the first issue about rework after tests are run, the team can discuss how it might implement a continuous integration (CI) cycle, so that tests are run locally by developers and that way there are no surprises when tests are run in a test environment. With respect to bottlenecks, the team can discuss how to enable more people to work on the items that are bottlenecks – possibly by training certain people using pairing – or if that is not feasible, perhaps the bottleneck work can be started earlier so that it is staggered with respect to dependent work, creating a kind of pipeline or Kanban process. In fact, tangible agile solutions can be found for each of the team’s issues. The best part is, the team is not thrown into an entirely new process overnight, but instead they are inventing their own solutions for their own problems – and moving toward agile in the process.

This approach will improve productivity from the very beginning.

This approach will improve productivity from the very beginning. There will be only a minimal Satir change curve dip, because the changes are incremental and not disruptive. The team will also have higher morale, because the innovations are their own, and they are in full control of their own process. And their old process has not been thrown out the window and derided as “bad” and “waterfall” – synonyms in the agile community.

There is a catch with this approach as well: It will only work if there is authority behind the changes that are needed. Within the team, the team has to be empowered to make its own decisions about how it works, without interference from project management or external entities. Also, the team has to be motivated to improve things, and not stuck in its habits. Some people resist change, even if it might improve things. A team that is composed of people who resist change will not want to devise improvements to its own processes.

If the team resists change, then the agile coach needs to have authority to impose a mandate on the team, such as “We need to improve velocity by 20% over the next four weeks”, or “We need to reduce testing time by 50% over the next two months”. The coach’s mandate can derive from a CIO mandate giving the coaches authority. The CIO mandate can even be specific, by mandating certain agile practices, but that is not a very agile approach – it is prescriptive, just like mandating a framework – yet it can work if the coach is around sufficiently to guide the team in those new practices. In contrast, if the team devises its own way to meet goals such as decreasing test time, they will need less guidance.

Even if the team is motivated to improve its practices, they might still have to comply with externally imposed non-agile practices such as gate reviews and manual testing by an external testing group. In order to negotiate how those constraints can be relaxed, the agile coach needs authority to be able to make “deals” on behalf of the team. In that capacity, the agile coach is acting more like a project manager, even though when dealing with the team the coach acts as a coach. Leadership requires applying the right methods depending on the situation.

The same lessons about imposing a framework apply at an organization level. In fact, at an organization level, it is even more important to allow people to define their own business functions. To do that, people have to first learn about agile. They have to visualize what their function would look like under agile – or even if their function would still exist. Then, they have to make concrete plans for changing their function, with the assumption that change will occur in stages – it will be unusual to get it right from the outset. All that takes time. Pushing a pre-defined set of processes on an organization will likely create a-lot of frustration because the “train is moving” and managers are still on the hook for delivery dates and meeting their various commitments, as well as complying with organization policy that is still in place. Creating entirely new processes and systems takes time, and people need to learn how to operate those new systems – and new ways of thinking to boot – and that takes even more time. This is why a framework – such as SAFe – is a great place to start for ideas, but should not be implemented “out of the box”.

The Big Framework Up Front Can Work

Transitioning a team overnight to a prescriptive agile process can work. I have seen it work – but not often. One case in which it worked well was a project at a company called BCE Emergis during the early 2000s. The project had 80 people (about 50 developers using RUP). The company decided to rapidly adopt eXtreme Programming (XP) and brought in XP coaches to help. We carved out four development teams. I was the lead of one of those teams. The rapid transition to XP worked, because each coach was highly experienced with XP, and there was at least one coach per team. Thus, the coaches were present all the time, and participated in discussions – both planned and ad-hoc.

This is the “Shuhari” model, or apprentice/craftsman approach: an expert (the craftsman, or master) trains an apprentice. The apprentice is expected to follow the direction of the craftsman to the letter until the apprentice learns the craft well enough that he or she can do it on his or her own. Eventually, the apprentice becomes expert enough to make his or her own judgments – even to the point of violating the practices that he or she was taught, if the situation warrants it – in other words, the apprentice has become a craftsman, and understands the reasons for the rules well enough to bend or break the rules when it makes sense to do so. For the apprentice/craftsman approach to be an effective instruction/learning strategy, a craftsman is needed who can spend a great deal of time with the apprentice. This approach does not work if the craftsman or master is seldom available.

Most organizations that adopt agile do not do it in a Shuhari or apprentice/craftsman way: in most cases that I have seen, each coach has a portfolio of projects that they coach – typically from three to ten projects/teams. And for coaches, I am not including recently trained Scrum Masters, who just obtained their two day Scrum certification and have never worked on an agile project before. Those people are beginners every bit as much as the rest of the team is.

Three to ten teams per coach is too many: the right ratio is 1:1. If it is not 1:1, then the team is essentially expected to use an entirely new process that they do not understand, and there is seldom anyone around to guide them. They end up trusting the process and not thinking for themselves, but no one is around to tell them what to do. This can have a very bad outcome, including testing that gets overlooked, technical work that goes undone, and important collaboration that fails to occur, and – worst of all – the organization sees poor results from agile adoption and loses confidence in it.


I really like the expression “fish or cut bait”. If you are going to do something a certain way, really do it. If you are going to adopt a framework, bring in the resources to do it for real – not half way. If you cannot afford those resources, use a different strategy that you can afford and do it right. If you have a few coaches and many more teams, then you cannot effectively use the Shuhari or apprentice/craftsman approach. Instead, leverage the brains on the teams to adopt agile: use the coaches to help the teams to talk through issues, giving them an agile perspective, but don’t expect the teams to adopt an entirely new way of doing things. Empower them to adjust their own processes – which they understand – gradually, learning as they do it. That is more effective if the coach is not always around, in which case the team needs to be able to think for itself, on its own, even as they are learning agile. That is being agile.

Then again, these are complicated issues, and to say that a framework should or should not be imposed in a given type of situation is itself prescriptive. More often, the right answer is a combination of approaches: perhaps some prescription is called for, to push things along, while allowing people to innovate with their existing processes as a starting point. Judgment on the right balance is called for. Advice on that judgment is the value added by agile coaches, at both the team level and the enterprise level, and managers need to apply their experience with respect to organization change in order to find the approach that is best for their organization’s culture and circumstances.

Contributors (alphabetically):
Cliff Berg
Sekhar Burra
Sunil Mundra