I'm frequently (weekly) asked by clients I visit, "Where doesn't an agile development approach work?"  Or, they tell me an agile approach won't work in their environment for numerous reasons.

In my experience, general agile development practices are superior when the problem domain is complex and/or dynamic, and solving the problem benefits from a more empirical approach.  This is true even with distributed teams. 

This is because in dealing with complex problems, the natural cognitive approach for human beings is to decompose the problem into smaller pieces, and work to understand the smaller pieces so that those pieces can enable an understanding of the whole problem domain.

The amusing thing to me is that this behavior happens within the phases of sequential, phase-based approaches to software development projects, yet the overall approach ignores this and tries to freeze the dynamic nature of the problem domain.  Agile project management expresses this idea up through its execution approach with the inspect and adapt cycle.
 
Does this require more communication/collaboration? Yes. Is this an issue with agile processes? No.  The same conversations need to occur to understand and allow requirements to evolve. It is a choice by the organization undertaking the problem whether they have the conversations or not.

If you have a problem domain that is simple, one where using the same sequential process results in getting the same outcome that is within your acceptable measure of quality, then use that approach.

I was just recently at a client that stated that agile wouldn't work for them because the high degree of complexity in their problem domain and because of their distributed team nature. They continued to explain that using waterfall enabled them to not have to communicate as much :-)

Waterfall software development methodologies allow people to sweep all types of process, organizational and interpersonal dysfunction under the proverbial rug and defer the problems this causes until the "death march" -- or in the worst case, after the so-called value has been delivered to the customer and they find dysfunction in terms of their needs not being met or poor quality.

So the next time you hear this question, consider whether the issue is the approach, or because of lack of discipline, lack of competence, organizational dysfunction or interpersonal dysfunction within your team; all of which, agile approaches are brutally blunt at pointing out.  Many just don't want to deal with the impediments and feel more comfortable "sweeping them under the rug".

The initial training that our organization will focus on is agile values, principles and practices. This training should target a wide functional band of the organization, including senior management, middle management, and team leads as well as software dev, QA, Business Analysts, Project Managers, Program Managers, Product Managers, HR, and Production Ops. Training the different parts and functions of the organization is essential for all involved to understand their roles and responsibilities in the new agile project management approach. There will undoubtedly be fear of change and cynicism, but without training and the opportunity to hear and address fears during the assessment, this fear can become insurmountable. It is also essential to allocate adequate time and funds to execute the training in a quality manner. 

Following the education of the organization on agile values, principles and practices, we’ll need to assess the impacts that successfully adopting them will have on the organization.  It is only after folks are exposed to what agile is all about that it can sink in and allow them to better assess their attitudes towards the transformation to agile.  Can you see the mini-Deming Cycle going on here? :-)

This is an excellent time to engage an external agile coach to help facilitate discussions around fears and misunderstandings, and provide real-world examples of how others have faced the same challenges and succeeded.  The agile coach can work with each of the functional groups, at each level, to determine their concerns and explore possible solutions.  An agile coach can also help ensure that each functional group is prepared for the coming pilot projects – I suggest preparing a readiness checklist. Begin to plan for quick, simple, first-cut solutions to a wide range of concerns.  And once again, avoid big up-front planning, don’t go too deep yet.

In my opinion, building a group of internal agile coaches should be in the agile adoption plan of any reasonably large organization.  This allows the organization to develop its own 'agile mythology' that is passed down by word of mouth, not unlike tribal lore in more primitive cultures.  It embodies the organization's own unique context.

Having the assistance of external agile coaches during the planning and execution of the agile organization releases is essential. As the organization matures through their releases, the need for external agile coaching should diminish to the point of just having check-ins with the organization's own internally grown agile coaches.

In my experience and based on discussions with some of my peers in the agile development community, one of the most important criteria for success with agile is that it have a fertile environment to take root and grow.  In an organization this can be best characterized by executives that are willing to provide and support an environment for learning and adapting, which enables continuous improvement. Executive support for the pilot projects to serve as learning opportunities is essential, and as we know, we learn more from failure than success.  This requires the fertile environment that fosters learning and adapting that I mentioned above.

Once you can secure even a microcosm of the this type of environment, then you can look for projects that can meet the following criteria. 

Pilot Projects Should Be Visible & Meaningful
Don't be tempted to select pilot projects that are off the radar and of little importance. You are just inviting those fearful of change to sabotage your efforts because the cost is low to them and the organizations. Be sure to pick projects for your pilots that have visibility & meaningful impact to the business.

Early agilist and inventor of the Adaptive Software Development process, Jim Highsmith, probably put it best in Agile Software Development Ecosystems: “Don’t start with an initial ‘learning project’ that is of marginal importance. Start on a project that is absolutely critical to your company; otherwise it will be too difficult to implement all the hard things Scrum will ask of you.”

Of course if your efforts are more grass roots, the level of criticality will have to be balanced because it can be difficult to get stakeholders to take a risk when they aren't yet educated on the benefits of agile. In other words, they may be missing the reward data when they intuitively perform a risk/reward analysis.

Another important criteria for selecting candidate pilot projects is project length. Look for projects that have a relatively short release time line, preferably less than 90 days. This makes it easier to demonstrate the delivery of value and keep momentum and interest high. Nothing makes converts quicker than successful delivery of value; getting early and frequent ‘wins’ is important.

Once you've identified some candidate pilot projects, now you need to consider your ability to staff the key roles.  You don't want a critical project to be your pilot project if you can't put 'A' players on it that are dedicated and committed to its success. Let's take a look at the key roles.

Product Owner Role
It must be understood that the Product Owner is perhaps the key role to staff with strong players to help ensure your pilot project's success. This role must be committed to the project and empowered to decide on scope and schedule.

From my experience, not having a strong product owner role that is deeply involved with and available to the team, and who is empowered to make decisions about scope and schedule control, is usually one of the main impediments to success with agile.

I refer to the PO as a ‘role’ because it is unlikely to be one person in a successful scaled effort. Once we have secured the right player for the Product Owner role we need to ensure the availability of a dedicated and cross-functional team.

Dedicated Cross-Functional Team
To help demonstrate the true capabilities of an agile team, it is important that the team for our pilot project(s) be cross-functional, with representation from Dev, QA, UI, business analysts and if appropriate, tech writing.  Another advantage of starting out with a cross-functional team is that they will all get educated and indoctrinated into agile and will take the message back to their functional constituency to help get others at least curious about trying out agile.

Our cross-functional team needs to be dedicated to the pilot project effort. If the pilot team is split amongst multiple projects, this has a high probability of failure. It puts at risk the trust the team has with respect to the organization's commitment to the change, it will effect the commitment of the team and it can compromise the team’s velocity.



Scrum Master / Agile Project Manager
The final role that we must be sure to select wisely is the Scrum Master (if Scrum has been chosen as the agile project management framework) or the agile project manager. This individual needs to have a strong understanding of agile project management and the approach the team has selected.  They also must have strong facilitation skills. 

Additionally, it is highly useful for this individual to have experience with escalating issues in their organization and know the right people to get things done. This will be vital in their agile role on the pilot project, as they clear the impediments for the team to allow them to be as productive as possible.

Summary
With our candidate pilot projects identified and available staffing considered, we should now be able to select the specific pilot project(s) that will have the right visibility / important and the right staffing to maximize our chances for success. In part 5 of Using Agile to Scale Agile, we'll discuss agile assessment, education and coaching for our pilot project pilot team and the wider organization as part of our overall Agile Transformation efforts.  Stay tuned...

• Productivity
• System quality
• Flexibility
• Collaboration level

• Contract for a process that leads to a result instead of for a specific result. Targeting a specific result doesn’t allow for change / improvement. You have to have been right up front (rarely the case).
• Close customer collaboration is more important than contract negotiation, so the project can fulfill your business objectives instead of your lawyer's.
• Agile contracts should maximize the efficiency of software development and thus minimize the risk of a lawsuit occurring.
• Identify what to contract first. This should be done by those who understand agile processes and the value the customer is truly looking to have delivered. Once this is understood, then consult your lawyer to put it into legal-speak.

• Minimize dependencies
• Train everyone on common team practices & tools
• Integrate work on regular basis
• Consider integration teams
• Deliver value through vertical slices of architecture
• Include outsourced partner on customer feedback and continuous improvement

I remember the first time I drove a car on a race track.  I was hooked, and to this day I am a motorsports fan and occassionally enjoy getting to autocross or driving on race tracks.
 
The basic knowledge of how to become a race car driver is not hard to learn from books and lecture.  I've been to several driving schools.  The hard part is applying all you learn to driving the car on the track with speed and smoothness.  The greatest improvements I've made in my driving have always come when I've had a coach in the car with me, either driving the car for me to observe or as a passenger providing feedback and instruction. There is a reason that professional race car drivers have undergone many hours of professional coaching long be fore they will ever be awarded a racing license.
 
Becoming a competitive race car driver is basically the same same learning model as becoming a doctor or a practitioner in an agile software development organization:

• 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 agile adoption anti-patterns: Coaching not necessary. This is the idea 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 agile coach who 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 hands-on experience? Would you trust him to operate on you? I understand that a newly trained agile developer 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. One cannot go directly from knowledge to experience, and one cannot build skills in the classroom. To achieve the desired results from agile teams, 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 you have learned. A 2-day course (or even a 10-day course) cannot cover all possibilities. And what about scaling agile? The more teams there are (especially distributed teams), the more  challenges the newly trained agilists face. It gets overwhelming, especially for new practitioners.

In addition, please don’t misinterpret my views about classroom time. I have done my share of teaching. 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 new 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, who 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 agile coach.

Don’t try and save the cost of some coaching and try and get everyone trained instead, thinking this 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, will come up to speed faster, avoid common mistakes and ultimately coach the next generation. Consider that what you may consider an expense may actually be an investment, which will pay dividends for years. 

Remember, nothing breeds acceptance of change in an agile transformation like success.  A well trained and coached agile core group with multiple successes is the best marketing for the effort and the best foundation fo scaling agile. 

I'd like to thank Darian Rashid of Agile Ethos, a VersionOne Partner, for collaborating on this post with me.

In my last post in this series, Using Agile to Scale Agile, we generated an initial Agile Transformation Backlog by doing a gap analysis of where our organization is today vs. where we envision it to be on the other side of our agile adoption. In this post we look at constructing our Agile Transformation Roadmap / Release Plan that will give us a high level plan of the execution of our agile transformation. 

It is important to remember that a critical factor to our success in using Agile to scale Agile is to always be mindful of the basic agile methods when we are making decisions.  Keep the Agile Manifesto in mind:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

The only adjustment I make is to substitute “Working software” with Working Agile Organization. In my opinion keeping things simple, attacking small slices of the organizations and having embedded in the culture the idea of continuous improvement will help to ensure success in your agile transformation efforts.  

Before we continue, let me say, there is no one right way to do this… as with most complex problems, context is very important for crafting your approach.
 

Here is an example of what a high level Agile Organization Release Plan might look like.  I've set it up using VersionOne's release planning capabilities.  Using a tool like VersionOne for planning and tracking an agile transformation gives the effort the visibility and transparency it requires.  It also enables those involved (just about everyone in a company eventually) the ability to contribute ideas and have them seen and considered in a common environment / tool.

Agile Organization Release 1

• Identify the right projects to pilot with
• Educate & assess – education is key, make sure adequate training is provided to all involved. If possible, no function for the scope of the pilot should go untrained 
• Enlisting an agile coach to help in planning transformation and then be present during the execution provides continuity and much-needed coaching to new agile teams on understanding agile principles and practices and reinforcing them.
• Select an initial agile development approach for pilot projects
• Establish 2 accountable teams – one for the leadership and one working team
• Execute initial pilot projects
• Design and institute first-cut agile project governance
• Retrospection

• Adjust from learning from pilots and other Release 1 transformation efforts
• Begin broader organizational alignment 
• Launch and assess several more pilot projects - Seed new projects with experienced people – Expand training and coaching program
• Assess and modify the agile governance – map to existing systems as needed to keep people comfortable

Agile Organization Release 3

• Start to leverage more tools to help scale our agile efforts
• Expand our agility to encompass agile engineering practices, this includes: 
  • Daily build capability and continuous integration
  • Automated testing: including unit, system and acceptance testing
  • Test driven development 
  • Pair programming 
  • Design collaborative workspaces - This usually requires assistance from the leadership team to assist in changing policies to approve workspace reconfiguration… too often the cost of this is looked at without any regard for the benefit it delivers 
  • Consider a combined Lean Agile approach, applying WIP limits as well as defect queue thresholds.

Keep in mind that since we're dealing with changing processes, roles, and behaviors, this is complex stuff and we just can't plan too much in advance.  It's better to lay out the basic ground rules and then let the teams self-organize around the transformation problem with guidance from coaches.  Change that teams arrive at themselves is the kind of change that sticks.  If it is forced on them, its likelihood of success is greatly diminished, in my experience.

In my next post in this series we'll take a more in-depth look at Release 1 of our transforming agile organization.  Stay tuned...

In my first post in this series, I set the stage for using Agile to scale Agile development within an organization.  In this post we'll explore at a high level how we get started using Agile to scale Agile, and the steps and deliverables needed to take us to the point where we can make use of an Agile Organization Release Planning process for our organization.

First, let’s take a small step backward and ask the obvious question: “Why use Agile to scale Agile?”  Here are a few good reasons:

• Agile project management approaches shine when dealing with complex, highly dynamic problem spaces…and transforming an organization is just that!

• Use of Agile for scaling reinforces an organization’s commitment to Agile to its members.

• It can aid in embedding Agile into the culture of an organization at all levels.

• Having a continuous improvement cycle built in to change initiatives is very important and at its core, Agile provides this principle/practice.

So where do we start?  First, our organization should have a clear vision of itself on the other side of the transformation, including what it will look like and what it will be capable of doing.

As part of this exercise, the sponsors of the agile transformation must identify the clear business benefits linked directly to our organization’s strategic goals that will be served from adopting Agile methods. Getting alignment with these goals is important.

Next, we must identify misalignment to being Agile within and across the functional areas of our organization.  This will help us to build out our product backlog or, as I’ll refer to it, the  "Agile Transformation Backlog."

Also, we want to avoid big up-front planning for the scaling efforts.  We just don’t know enough and there isn’t a crystal ball!

Next we will want to Plan for "releases" of our Agile organization. Just as we use agile software development to plan releases and iterations to build a product, we can use it to plan for releases of an Agile organization.

We’ll need to execute our Agile scaling in an incremental and iterative fashion.  Doing so will enable our agile teams to continuously groom the Agile Transformation Backlog.  It is important to avoid having everyone go agile at once because you can greatly increase the likelihood of misunderstanding, confusion, and failure.

You will want to hand-pick the first Agile pilot projects.  Are they likely to succeed?  Do they have the necessary training and support?   Look for the opportunities to get wins and experience on smaller efforts, and then start to scale up to the bigger/harder projects.

As we progress through our Agile organization release plan, we’ll want pay particularly close attention to retrospection to gain continuous improvement.  Through regular review and retrospection, we can adjust the release plan as we learn from pilot projects' iterations.

The table shown above is what a high-level current vs. future state analysis might yield for an organization going from waterfall to agile.  This type of analysis provides a good initial framework for developing the Agile transformation backlog.  All of the misalignment items should have backlog items in the Agile Transformation Backlog covering how each functional area would get from the current state to the future state.  The organization will want to produce a deliverable, such as the one shown, and share it broadly to get feedback.  This is important because the perceptions of gaps between current state and future state can differ greatly between people.

So with an initial Agile Transformation Backlog in place, we can move on to planning our Agile Organization Releases.  I will pick up on the Agile Organization Release Planning topic in the next part of this series... stay tuned!

My last post in this series, The Elephant In The Room – Part II, discussed why this type of impediment is tolerated in many agile development organizations.  I also explored how understanding the context and motivation behind a team member’s poor performance can change other team members' perceptions of it.  I discussed the importance of not labeling someone as a low performer before making sure that the individual is in the right context to leverage their strengths. 

In this post I will be exploring some tools and tips for understanding what motivates people, how they operate when things are going well and when things are in conflict, and what types of positions work best fit a person.  Armed with this knowledge, teams can be assembled that have complementary motivations, strengths and interests.  Teams formed with this knowledge of each other are much better equipped to build understanding, more open communication and trust.  In my experience, assuming you hire intelligent and technically competent people, these are the key ingredients for achieving sustainably high performing agile teams.

There are three tools or instruments that I have seen used effectively in software development management to equip people with an understanding of their own motivations, values, strengths and communication style as well as those of their team members. The three are:

1. Strengths Deployment Inventory (SDI) - A suite of psychometric tests and a practical methodology for empowering people to improve relationships and manage conflict more effectively. SDI is rooted in the theory of Relationship Awareness®, a self-learning model for effectively and accurately understanding and inferring the motive behind the behavior.

2. StrengthsFinder 2.0 - This is a book and on-line instrument that enables people to understand and develop their strengths rather than trying to improve on their weaknesses.  When used in an agile team environment it allows team members to understand and leverage their other team members’ strengths, and not interact with them by targeting their weaknesses.

3. Belbin Team Roles - This tool looks at the team dynamic based on roles within the team.  It identifies nine different roles.  Based on an understanding of these roles, teams can be assembled with the best complement of team roles to help ensure success.

Ok, so you have either been experimenting with Agile software development and have had solid success, or your leadership has read about or heard from their peers that this Agile thing is worth taking a look at.

Regardless there is considerable overlap between these two situations.

Let us go with the scenario where we have had several individual teams deliver value much more effectively than our other non-agile teams.  There is a general feeling in our leadership that we can enjoy the same type of improvements if we were to leverage Agile development more broadly throughout our organization.

We have identified or created what we feel is a reliable process.  We have standardized high-­level  process steps, deliverables, agile tools and artifacts. We have developed metrics for tracking progress and measuring the delivery of value.

So we’re ready to scale, right?  Maybe not… it looks like we might have a problem.

The problem is that our organizational structures, resource management approach, governance model, HR practices and other aspects of our business are all aligned for waterfall delivery. These types of misalignment call for possibly significant organizational changes.

 We have to ask ourselves, how skilled are we at planning and executing change management? 

So, where do we go from here?  Where do we seek help?

Why don’t we leverage what we’ve already learned with our initial Agile successes?  Use Agile to scale Agile.

Now if you will, imagine if our organization was to identify a vision for itself that was purposeful and inspiring, that our leadership has also provided a list of challenges to our teams that needed to be overcome to realize that vision. They then empowered the teams to solve the problem and the team themselves came upon Agile as a solution. 

Now that is the stuff of successful Agile Transformation… When the whole organization can carry the banner for change, its probability of success is much higher.

In my experience, unfortunately, most organizations are not in a position either structurally or behaviorally, or both,  to do this, so we’ll need a bit more traditional leadership driven approach to using Agile to scale Agile.

This series of posts will explore using an Agile release model for transforming our hypothetical organization to an Agile organization, as is required to successfully scale agile principles and practices.

Enabling teams to better build understanding, open communication and trust is the lubrication that makes the human machines in a knowledge worker factory inter-operate smoothly. Without it gears grind, there are blow ups, and meltdowns, all of which result in highly ineffective and inefficient operations.

It has been said in many fields of endeavor, including agile software development, that we should do those things that we see as hardest (and often least popular) first and more frequently until they are not seen as being hard.

Unfortunately, in Agile Development Organizations, it isn’t the processes, tools or hardware that generate the most significant challenges to delivering value, especially at scale. It is the human and organizational interaction dynamics that pose the biggest challenges, yet they are the least dealt with in the Agile Community.

Look at the books that are available, the speaking topics accepted at conferences, the white papers published and the posts on blogs within the Agile Community. The vast majority have to do with agile processes and tools for project and program management, automation and engineering practices.

One might say that the human and organizational issues are common to all teams and not just agile teams, so why focus on this? This observation is absolutely true; the problem is that Agile approaches are far more dependent on highly iterative human interaction and communication. Multiply this by the need for this collaboration to be between a much more cross-functional collection of people and you quickly see why this is a huge challenge. 

In a more traditional functionally siloed organization, people tend to communicate mostly with people that have the same functional focus and likely, more common motivations. These functional groups tend to have much less communication and collaboration with those in other functions that frequently have different motivations. In the worst cases the communication between such functions happens almost exclusively through detailed documentation, and rarely is communication face to face, except between managers. 

Having worked in that type of environment during my career as I’m sure many of you have, I don’t think it’s necessary to go into why this leads to low levels of trust, dysfunction, low productivity and frequent customer dissatisfaction with the deliverables of such organizations.   Perhaps the biggest crime of such environments, IMO, is that it can strip people of their passion and drive them and beat them down to becoming “paycheck players” (do the minimum they have to collect their paycheck).

So how do we address this big “Elephant Impediment” in the room? First of all, I believe that Agile Teams and the Managers in Agile organizations should be provided with some training on basic tools to enable them to be higher functioning in communicating and collaborating out of the gate.  Over the past fifteen years that I’ve managed people, the one tool I come back to is SDI which stands for Strength Deployment Inventory. It is based on a psychological theory called Relationship Awareness Theory. It has proven to provide an excellent basic understanding for team members about the different Motivational Value Systems (MVS) that exist, which shape how people tend to communicate both when things are going well and when things are not going well. SDI also provides a simple conflict evaluation and resolution model. With the basic understanding of SDI and equipped with a basic vocabulary for describing styles, agile team members can effectively craft communication, verbal or written, so as to avoid misunderstanding and eroding trust and to just plain save time.

For Managers, there are some agile techniques I’ve used with success that enable a people manager to gauge how the individuals they are responsible for are contributing and what their level of job satisfaction is. I will explore both SDI and Agile approaches to people management in my next two posts.  Stay tuned!

In my last post I began the discussion about the big Elephant Impediment in many agile development teams.  Here I will continue the discussion of why we tend to have them around and also explore making sure you actually do have this Elephant Impediment and not something else.

In the current politically correct and litigious American social and business culture, many companies are resistant to removing those non-committed, low performing resources in fear of legal action or because some managers fear it is too much of a hassle given the corporate policies put in place for doing so. 

Instead, low performers are often tolerated and allowed to reduce the capabilities of a team and bring down the morale of others on the team.  This is especially damaging to an agile team where respecting the commitment a team makes requires empowering them to be decision makers, self-organizing and largely self-managed.  To not do so will usually handicap an agile team in realizing continuous improvement which also impedes their ever reaching the ‘perform’ state.  So how does this form of impediment get removed?  The answer is with courage and servant leadership.

Successful agile development organizations have servant leaders.  One of the key roles of a servant leader is to facilitate the removal of impediments that either they see for the team or that their teams themselves report.  In my experience, the impediment of a non-committed, low performing team member is one of the more commonly reported impediments that is rarely dealt with for the team and organization’s benefit.

Of course care should be taken when making this assessment. An individual who is not performing well on one team shouldn’t be labeled as a low performer in general.  The question needs to be asked;  Is the non-committed, low-performing resource in the wrong context?  A low performing resource on one team may not be that way in a different context.  By context I mean the combination of work assignment, personal life, company / team culture, personalities, and physical environment. 

For instance, a resource may be committed and capable but there are other things going on in their life that are affecting their performance?  Does the team understand this? Consider the example of a vehicle driving down the road in a sporadic way weaving in and out of traffic… What is your reaction?  More often than not, it’s probably pretty negative and inclusive of an explicative. 


Now take this same vehicle and put a Red Cross symbol and the word Ambulance on the sides… now what would be your reaction?  Having more information can change the way one interprets behavior because it helps them to understand motivation.  This understanding tempers the way one reacts.  This is true in a team environment as well. 

If a team member isn’t delivering on their commitments to their team in a low trust and poor communication environment, the interpretation of the performance is usually pretty negative.  Now say that there was trust and open communication in place.  If the individual who began missing their commitments communicated that their Mother had passed away and they were a bit distracted, the reaction would almost certainly be different. 

Other team members’ negative interpretation of the low performance usually switches to one of understanding and support. Having trust and open communication on an agile team is one of the keys to enabling and realizing value from self-organization.  Team member contribution can ebb and flow to handle situations where another member’s contribution is affected by a change in their context.  This understanding and support only furthers the bonds on the team and elevates the level of trust.  This type of team trust can’t be instilled by an external force such as a manager.

Do you remember back in school, when you reached the level of classes where you had lab teams that were intended to work together on an assignment? Remember how that the group shared in the grade given for the deliverable? 

I remember a team I was on in a biology class that had four people on it who had fairly different motivations. Their levels of contribution to the project ranged from huge to virtually nothing. The team member types ranged from Achievers, those who were committed and motivated to get the ‘A’ to the “Tom Sawyer” type, the person looking to get others to do their work. The Tom Sawyer type knew that the Achiever would not let the team fail and if necessary would do all the work to get the ‘A’ and the “Tom Sawyer” type took advantage of this fact. As you’d expect, there was virtually no trust on this team and its communication was dysfunctional.

Unfortunately, in this academic environment, you had to deal with the situation you were dealt and it often taught a very poor lesson; to be individually competitive and to forget the team. Too often you see this same behavior on teams in the business world today. This behavior is what prevents many teams from ever becoming even functional, let alone high performing. This is especially true for agile development teams. This is the Elephant Impediment that many don’t want to address.

In my next series of posts, I will explore this situation further and provide some insights into how organizations and servant leaders can work to enable agile teams to herd this pesky pachyderm out of their way.

Just recently I attended Lean 2010 in Atlanta, GA, April 21-23, 2010. I ‘learned’ something that I didn’t know before… basically that Scrum / Agile is broken and Kanban software development is the answer. I heard two presenters at the conference giving experience reports that distinguished Kanban as being separate from Agile development approaches.

When I sought clarification, folks could not provide even vague reasons as to which basic Agile principles Kanban violated that made it non-Agile. When I dug deeper, the reason that these organizations failed with Scrum became clear. It had nothing to do with the approach but, as is more the norm, it was organizational issues and a lack of understanding / ability to execute the Product Owner role so as to produce and manage an effective product backlog.

I was amazed to hear how this problem went away with Kanban, that “the work didn’t need to be broken down; it was already the right size because we weren’t worried about iterations.” Wow, I thought, could this be the silver bullet we’ve all been looking for? ;-)

Unfortunately, after digging a bit deeper it was disclosed that the organizations had actually restructured their Product Owner role by establishing what I, and others, call a Chief Product Owner. Additionally they added a few Business Analysts to work with the CPO in ensuring the Product Backlog contained adequate items that had been sized, estimated and prioritized to feed the development team. This prevented delay, thus waste, for the team by allowing them to avoid becoming idle or having to waste time breaking down queued items that were too big to consume during an iteration.

There was also a claim in one of the experience reports that the presenter’s team saw a substantial increase in productivity when moving to Kanban. Upon further disclosure from the presenter, their implementation of Scrum had been mandated by upper management and pushed upon the team. We all know how well that works without proper transformation consideration given. 

On the other hand, Kanban had been discovered by the development teams in the organization. They evangelized and made the request to move to Kanban, which was allowed. The Team was more productive with an approach that they found, lobbied for and implemented rather than one that was shoved down their throats? Really? Big surprise!

While I realize this was a Lean conference, this type of experience reporting is misleading for folks that are new to Agile or Lean software development. 

Lean / Kanban is not a silver bullet, and the problems that challenge Agile implementations are largely the same. It’s not the process, the technology or the tools, it is the lack of understanding of how to execute change in an organization, an organization's unwillingness to change, and the classic illusion of control, with the belief that projects can be estimated and planned up front and then have teams held to precise commitments.

While Lean and Kanban are powerful 'tools' for a practitioner’s utility belt, they do require a certain amount of trust between management and the teams working in a Lean fashion. This trust, from my experience, is something that comes as teams mature following successful agile executions. Successful delivery and effective continuous improvements are great boosters to trust, but some has to exist to begin with or the change required to become effective with Agile software development won’t likely happen. I look forward to watching teams that have taken the training wheels off their Scrum software development endeavors begin to implement Lean and especially Kanban. 

There are several good books that explore merging the principles of Scrum and Kanban such as “Scrumban” by Corey Ladas.

So before you dump Scrum and chamber Kanban as your silver bullet to slay the agile software development beast, study up, talk to some folks that have been successful with Scrum. Ask what is different about their organization and development context from yours. Then use common sense and make some incremental changes that you can measure and that you think can make a difference in your organization's context.

I was reading some posts on the Scrum Alliance LinkedIn group as I usually do and I read another thread on a person asking for help with trying to figure out the right balance between stories and more detailed specifications in their Scrum software development efforts.  The advice given ranged from zealots bashing the person for doing too much documentation to suggestions for the right people being involved and the analysis techniques that are used by the Business Analyst's role.

The one thing I'm always fascinated by when I hear about the challenges teams have through such posts, talks I attend or just speaking with teams, it's nearly always a look at the process, techniques and tools they use for answers to their problems.  You just don't see the discussion of the dynamic of the people doing the work, how high functioning they are as an overall product development team and the culture of the organization in which they operate.

Process takes shape as a by-product of these forces.  The team's ability to establish continuous improvement is most impacted by these forces.  If there is low or no trust on a team, people will want to write more things down, and they will be much less likely to share the information. When you have a retrospective, you don't get to the root cause of issues.

The same goes for the culture of an organization.  If agile teams live under the illusion of control of management, often characterized in the governance systems of command-and-control organizations, the challenge of building trust between management and teams is often very difficult.  Regardless of this challenge, many will just change process and techniques and ignore this root cause of problems -- and then wonder why they aren't successful when others are enjoying success with the same processes / frameworks.

Let's face it, Agile processes are fairly simple and lightweight, so even if you start with an ill-conceived process or technique for analysis or whatever, it could improve if you had a high functioning team and an organization open to change, both of which are enabled when trust exists.

I know, this is all touchy-feely that folks don't like to discuss, but if it is addressed it is the thing that, in my experience, can lead to the greatest gain in capability for a team and it truly engages people to commit as a team to the delivery of value. 

If you can truly achieve trust within your team and with the organization, watch how fast things improve.