Skip to main content

Tag: Development

How Deep Does the Reuse Rabbit Hole Go?

Introduction

Requirements reuse is a topic that has been discussed and documented for a long time. In 2010, Yuri Chernak describes the state of reuse, as well as the challenges for broad adoption. Requirements reuse holds the promise of “faster, better, cheaper.”

The company I work for recently published a study that quantifies the importance of reuse to product-development professionals: 95% said reuse is important to delivering on time.

It all boils down to efficiency. Yet, despite all the enthusiasm, reuse is rarely implemented in a way that provides the promised value. Several key factors are associated with this:

  1. The definition of reuse needs to get beyond “copy and paste.”
  2. Successful reuse requires an organizationwide adoption model.
  3. Technology isn’t always aligned with desired capabilities.

Let’s go through each in turn.

Defining Reuse

According to BABOK, reuse falls under the “Requirements Management & Communication” section. In general, the BABOK is fairly light on this topic, referring to reuse as a “repository,” and advising businesses to identify a person “to manage the repository.” There’s mention of “impact analysis,” and that requirements should be identified as “candidates” based on an organization’s long-term needs.

These are all important concepts, some of which will be addressed in more detail here, but I think a more practical definition is in order. Here’s my attempt at defining reuse:

Reuse is an agreed upon policy, where by, separate or related teams, projects, or departments, are able to utilize previous work done in such a way that new work can be accelerated. In addition, on going changes to the reused information should be shared, such that the different entities can accept, reject or merge the work.

The idea here is that while many people view reuse in terms of copy and paste, or linking, it is more around utilizing work done, and keeping that work synchronized over time and across teams.

Example: Team A has just completed building a product. The product could be hardware, software or even a combination. Now Team B is about to embark on a new product that is very similar to Team A’s product. In this scenario, Team B is able to utilize not only pre-existing requirements but also any downstream artifacts such as Use Cases, Non-Functional requirements, regulatory laws, stories, test artifacts and of course the coverage or traceability between them. By reusing this information, Team B has a significant leg up and has saved a lot of work and time and time, (at least 25%, according to the survey).

harris March12 Img01If understanding the definition of reuse is the important first step, the second step is to share this definition organizationwide. 

<< CAPTION: reuse becomes increasingly necessary and provides exponential benefits as products and teams increase in size>>

Successful reuse is an organizationwide adoption

Based on my definition, reuse becomes increasingly necessary and provides exponential benefits as products and teams increase in size; however, as this size increases, reuse also becomes increasingly complex to manage. Therefore, the problem that organizations face is not if reuse should be implemented, but rather how. Like different methodologies, the implementation of reuse is going to vary based on the type of product, the team size, and the organization’s ability to adapt and adopt. 

For this reason, it is important to carefully analyze areas where teams would benefit from reuse and then work backwards to determine the implementation strategy that would have helped. It is also important to find incremental wins while keeping an eye on the big picture so you can expand your reuse strategy over time. For example, you may start by simply reusing the requirements from one product to another, working to keep them synchronized. Later you could continue looking at creating a central repository of common requirements. Finally, you could start looking beyond just the requirements and begin pulling in traced artifacts. This last item is important; reuse is not just a Business Analyst problem, it impacts the entire team. 

As you can see though, this kind of reuse strategy is very difficult to do manually with just documents. To do it right will require more sophistication and better technology. 

Technology isn’t always aligned with desired capabilities

Our desires tend to exist in a realm just ahead of what’s possible. Sometimes technology evolves to meet those desires, even producing unexpected outcomes. Some examples might be Mark Twain’s prediction of the Internet in 1898 through a sci-fi story, or on a more related note, the 2001 Agile manifesto, which called for better collaboration several years before the tools and technologies necessary to facilitate true collaboration were even available; hence, the early push toward entire teams being confined to a single room around a single table. It wasn’t until 2004, when the social networks emerged, that we began to see an evolution in business software and human behavior that favored the kind of collaboration necessary to push Agile into the enterprise. This area continues to rapidly evolve.

The same is true with reuse. The topic has been around for years but until recently, it was very difficult to manage complex reuse without adding an exponential amount of administrative work to keep track of everything. Too much reliance on the trust of too few, rather than on tools or technology.

Some of the solutions today offer some form of reuse, all of which are designed to enable teams to better reuse work that has been done. This might be just around requirements but I believe it goes deeper than that.

How deep does the rabbit hole go?

This brings me to the final question: how deep does the rabbit hole go? Well, considering that we could start with the most basic of copy and paste, this does feel like the beginning. As we go deeper we see that requirements are being shared but remain the same, existing in different places. Deeper still, we see the requirements are being separated but stay synchronized through a change-control process. Digging further down, the lines become blurred as we question what a requirement really is: the text, the meta-data…what then should be synchronized… all aspects of the requirement?, or just certain ones? What about any attachments associated with the requirement, or relationships to upstream or downstream? Does the traceability remain or do the test cases also get reused?

Reuse is a powerful strategy. When done right, reuse provides huge rewards. To reap those rewards as a user, manager or executive taking the plunge, you’ll need to be smart and communicative to avoid losing your head.

Don’t forget to leave your comments below.

Want to Improve? Don’t Make Resolutions. Play Games and Keep Score!

It’s the New Year. And everybody decides to start a new year with resolutions, resolving to change their behavior for the better. They are going to lose weight and exercise more. They’re going to spend more time with their family, instead of work; they’re going to read more and watch less television; and so forth. And as we find every year: we just can’t keep to our resolutions. Here’s an idea to help you achieve the behavior you would like: instead of making resolutions, play games and keep score.

Playing the Game

Last year I had a couple of engagements in Phoenix, Arizona with the same company at the end of June and early July and talked to two different groups of business analysts, software developers, testers, and so forth. In the first session, a young man asked how he could become “spontaneous”. I asked what that meant, and he said that he wanted to be able to contribute in meetings and gatherings instead of remaining quiet and in the background. He wanted to be able to give voice to his thoughts and opinions. In the second meeting, a young fellow asked how he could become less “shy” in business settings. What they wanted was some kind of magic phrase from me or timeless advice that would change their perspective and suddenly make them more loquacious and outgoing. Unfortunately I didn’t have such a magic phrase.

What I did have was a program of practice. I thought up a game they could play that would do the trick painlessly. I suggested that they make a commitment to making one statement and asking one question in each meeting they attend. Any question and any statement would be acceptable. A question such as “would you mind repeating that, I didn’t hear you?”, and a statement such as “I agree with that” would be allowed. I told them to create a spreadsheet, and keep score of the number of times they made a statement and asked the question in a meeting. The spreadsheet is for keeping score: the Rows would be the meetings and the columns would say how many questions they asked and how many statements they made. “Do this for about three months,” I told each of them, “and if you find that you are routinely meeting your quota of questions and statements, increase your quota”. 

Why it Works

The magic of this particular game is twofold. First of all, of course, they would overcome their fear of speaking in front of a group and give them the mindset that what they have to say is just as important and interesting as what anyone else has to say. The second bit of magic is that over time, there will be natural positive feedback from others in the groups or meetings. People might say “yes, I’m glad you asked that; I didn’t hear either”, or “thank you for agreeing with me”. Even a nod or smile will serve as positive feedback and help overcome the fear (the fear that is based on rejection or disapproval from others) so that the game player will be encouraged to do more.

One of the fellows, the second one, wrote me an email in August telling me that it was working. He found it much easier and comfortable even to talk in front of a group of people and he mentioned anecdotally that it gave him confidence he didn’t know he had which was helping in other aspects of his life as well.

The reason this game works is misdirection. Your focus in the game is not on learning how to talk in crowds or overcoming fears; your focus is on getting your quota per meeting. As you look at your spreadsheet and see zeros you will resolve to eliminate those zeros in the next meetings simply to win the game. It becomes more of a scorekeeping exercise than a behavior modification exercise. Can I go for three months coming up with at least one thing to say and one question asked in each meeting, business or social? Without being aware of it, you will find that whatever the behavior you wish to change – whether it is to add a new behavior, alter an existing behavior, or remove a behavior you’d rather do without – will be changed and new habits developed. And usually, you won’t even know it happened until you look back at where you were when you started the game.

Another Good Example 

Late last year a fellow down in Austin, Texas, by the name of Jia Jiang, decided to overcome his fear of rejection and his emotional and even physical reaction to rejection. He decided to play a game in which every day he would purposefully make a request of someone for something which he knew would be rejected once a day for one hundred days. He videotaped each encounter. He asked an editor at Bloomberg BusinessWeek if he could write articles for the magazine even though he had no experience; he asked a professor at the University of Texas in Austin if he could teach one of the professor’s classes; he asked the flight attendant on a Southwest Airline flight if he could give the preflight safety announcements; he asked a Domino’s employee if he could deliver pizzas. He asked a stranger to lend him $100, and another stranger online for a Black Friday sales event if he could cut in front of him. He received negative responses in all cases. In the beginning it was difficult, even when he knew he was going to be told, “No”. As he proceeded through his hundred days, he found it becoming easier and easier to accept rejection. And as usually happens with games of this type, when the targeted specific behavior changes other behaviors also change. In the case of Jia, he found that he was more able to ask for even preposterous things. His confidence increased to such a degree that an increasing number of requests toward the end of his hundred days, the person being asked did not say “No”.

How it’s done

So what does that mean to you? As with anything a business analyst does, you first understand the as-is situation which means an honest self-appraisal and self-assessment. You may not need one, but it’s good to do one anyway. You can do this in a number of different ways. The least painful is to identify people that you would wish to emulate, people you admire –people who are alive now, people who have lived sometime in history, people you know, people you don’t know, even fictitious people. Then identify the characteristics of those people that you admire. For example, if you want to be a better business analyst look around to those who seem in your eyes to have it together as a business analyst: people in your organization, people in your professional groups, people you know only online or through conferences. Define why you think they are a top business analyst. (Note that there is no finite definition of a top business analyst. What we are talking about is what you think the characteristics of a top business analyst are).

Once you have determined those characteristics that you find admirable and that you wish to emulate, make a list of them, prioritize them and pick one, just one, of the characteristics, or behaviors. Then make a game of challenging yourself to do something that will overcome whatever obstacle you have to achieving that behavior or characteristic. Set a timetable for performing the game and the important thing is to keep score. Without the scorekeeping and the daily revisiting of the score pad to update the score, the behavior modification becomes a simple matter of willpower and that does not always work. Keeping score gives us a constant reminder and places us in a competitive situation and that will provide the motivation to keep you true to your goal.

The Hard Part

The hard part isn’t really doing the assessment, although some will people find it difficult, and the hard part isn’t really deciding on which characteristic of behavior you would like to adopt. In the end it really makes no difference because when you have adopted one behavior you go back to the list and pick the next one until you are satisfied that you are a top business analyst or whatever you want to be. The hard part is coming up with a relatively nonintrusive, challenging, and achievable game for which you can keep score. But there usually is at least one game for every behavior you would like to modify. To back up that statement I will offer the following: if you determine behavior you want to change and cannot come up with a game to play, drop me a line and likely I can give you one. And I’d love to hear about your successes.

So play the game, keep the score, change your behaviors without pain, and as the U S military outfit says, in 2013, “be the best you can be”.

Don’t forget to leave your comments below.

Fostering Team Creativity: The Business Analyst’s Sweet Spot

FEATUREOct23rdThe 21st Century BA Series From Tactical Requirements Manager to Creative Leader of Innovative Change

As we look ahead into the next century, leaders will be those who empower others.

—Bill Gates, American business magnate, philanthropist, author, and is chairman of Microsoft

The need for effective team leadership in the business world can no longer be overlooked. Technology, techniques, and tools don’t cause projects to fail. Projects fail because people fail to come together with a common vision, an understanding of complexity, the right expertise, and effective methods and tools. Team leadership is different from traditional management, and teams are different from operational work groups. Successfully leading a high-performing, creative team is not about command and control; it is more about collaboration, consensus, empowerment, confidence, and leadership.

Effective Teams

If a business analyst is to step up to the task of becoming a credible project team leader, she must have an understanding of how teams work and the dynamics of team development. Team leaders cultivate specialized skills that are used to build and maintain high-performing teams and spur creativity and innovation. Traditional managers and technical leads cannot necessarily become effective team leaders without the appropriate mindset, training, and coaching.

                                                A small group of thoughtful people could change the world. Indeed, it’s the only thing that ever has.

            ––Margaret Mead, American cultural anthropologist, author, lecturer

Teams are a critical asset used to improve performance in all kinds of organizations. Yet business leaders have consistently overlooked opportunities to exploit the potential of teams, confusing real teams with teamwork, team building, empowerment, or participative management.[i] We cannot meet 21st-century challenges––from business transformation to continuous innovation––without high-performing teams who are comfortable with turning uncertainty, complexity, and ambiguity into innovation.

The Power of Teams

Examples of magnificent teams are all around us: emergency responders, symphony orchestras, and professional sports teams, to name just a few. When we see these teams in action, it feels like magic. These teams demonstrate their prowess, creativity, accomplishments, insights, and enthusiasm daily and are a persuasive testament to the power of teams. Yet the business project environment, especially the IT project environment, has been slow to make the most of the power of teams. It is imperative that business analysts who aspire to develop into creative leaders understand how to unleash this great power.

New Product Development Teams

Business success stories based on the strategic use of teams for new product development are plentiful. For example, 3M relies on teams to develop its new products. These teams, led by product champions, are cross-functional, collaborative, autonomous, and self-organizing. The teams deal well with ambiguity, accept change, take initiative, and assume risks. The company has established a goal of generating half of each year’s revenues from the previous five years’ innovations and the other half from new products not yet invented. 3M’s use of teams is critical to meeting that goal.[ii]

Another success story is Toyota, despite the company’s engineering problems that led to unprecedented recalls in 2009–2010. Toyota continues to boast the fastest product development times in the automotive industry, is a consistent leader in quality, has a large variety of products designed by a lean engineering staff, and has consistently grown its U.S. market share. Teams at Toyota are led by a chief engineer who is expected to understand the market and whose primary job is vehicle system design. The chief engineer is responsible for vehicle development, similar to the product champion at 3M.[iii]

Economists have been warning us for years that success in a global marketplace is contingent upon our capability to produce products on a tight schedule to meet the growing demands of emerging markets. The same is true of projects to develop software products and solutions for business problems, to improve business performance, and to use IT as a competitive advantage. It’s not enough to deliver projects on time and within budget, and scope; it is now necessary to deliver value to the customer and wealth to the organization faster, cheaper, and better.

The Wisdom of Teams

For the business analyst who is struggling to understand how to build high-performing teams, a must-read is The Wisdom of Teams by Jon Katzenbach and Douglas Smith.  The authors talked with hundreds of people on more than 50 different teams in 30 companies to discover what differentiates various levels of team performance, where and how teams work best, and how to enhance team effectiveness.

Wisdom lies in recognizing a team’s unique potential to deliver creative results. Project leaders strive to understand the many benefits of teams and learn how to optimize team performance by developing individual members, fostering team cohesiveness, and rewarding team results. Katzenbach and Smith argue that teams are the primary building blocks of strong company performance.[iv]

The Stages of Team Development

As a member of the project leadership team, the business analyst is partially responsible for building a high-performing team and fostering creativity and is fully responsible for building a high-performing requirements team and proposing innovative solutions. To successfully develop such a team, it is helpful to understand the key stages of team development. We use the classic team development model from Bruce Tuckman as a guide, since the Tuckman model has become an accepted standard for how teams develop.

The Tuckman Model

The Tuckman model that outlines the five stages of team development—forming, storming, norming, performing, and adjourning—has become the gold standard for studying team dynamics.[v]As a team transitions from one stage to the next, the needs of the team and its individual members vary. A successful team leader knows which stage the team is in and skillfully manages transitions between the different stages. The following figure depicts the typical stages of team development.

kitty1Oct23rd

Stages of Team Development

In the forming stage, participants are introduced when the team is established and also as new members join the team throughout the project. The goal of the project leadership team in this stage is to quickly transition the individuals from a group to a team. During the forming stage of team development, members are typically inclined to be a bit formal and reserved. They are beginning to assess their level of comfort as colleagues and teammates. There is likely to be some anxiety about the ability of the team to perform, and there might be hints about the beginnings of alliances between members.

During this stage, the project manager’s job (with the support of the business analyst and other project leads) is to encourage people to not think of themselves as individuals but as team members by resolving issues about inclusion and trust. Team members may wonder why they were selected, what they have to offer, and how they will be accepted by colleagues new to them. Individuals have their own agendas at this stage because a team agenda does not yet exist. It is during this stage that the team leaders present, and give the team members the opportunity to refine, the team vision, mission, and measures of success. Allowing the team members time and opportunity to express their feelings and collaborate to build team plans will help members begin to make the transition from a group of individuals to an effective team. During this stage, team members form opinions about whom they can trust and how much or how little involvement they will commit to the project.

Storming is generally seen as the most difficult stage in team development. It is the time when the team members begin to realize that the task is different or more difficult than they had imagined. Individuals experience some discrepancy between their initial hopes for the project and the reality of the situation. A sense of annoyance or even panic can set in. There are fluctuations in attitude about the team, one’s role on the team, and the team’s chances for success.

The goal of the team leaders in this stage is to quickly determine a subset of leaders and followers and to clarify roles and responsibilities so that the team will begin to congeal. Individuals will exert their influence, choose to follow others, or decide not to participate actively on the team. For those who choose to participate actively and exert their influence, interpersonal conflict might arise. Conflicts also might result between the team leaders and team members, particularly if team members believe the leadership is threatening, vulnerable, or ineffective.

It is important to realize that conflict can lead to out-of-the-box or out-of-the-building thinking (described in Chapter 4), so the team leaders should encourage new ideas and viewpoints. For team leaders who do not like dealing with conflict, the storming stage is the most difficult period to navigate. Although the inevitable conflict is sometimes destructive if not managed well, it can be positive. Conflicting ideas, raised in an environment of trust and openness, leads to higher levels of creativity and innovation.

The job of team leaders is to build a positive working environment, collaboratively set and enforce team ground rules that lead to open communication, and gently steer the team through this stage. The common tendency is to rush through the storming stage as quickly as possible, often by pretending that a conflict does not exist, but it is important to manage conflicts so they are not destructive. It is also important, however, to allow some conflict because it is a necessary element of team maturation. If new ideas are not emerging, and if team members are not challenging each other’s ideas, then creativity is not happening.

Norming is typically the stage in which work is being completed. The team members, individually and collectively, have come together and established a group identity that allows them to work effectively together. Roles and responsibilities are clear, project objectives are understood, and progress is being made. During this stage, communication channels are likely clear, and team members are adhering to agreed-upon rules of engagement during exchanges. Cooperation and collaboration replace the conflict and mistrust that characterized the previous stage.

As the project drags on, fatigue often sets in. Team leaders should look at both team composition and team processes to maintain continued motivation among members. Plan to deliver short-term successes to create enthusiasm and sustained momentum. Celebrate and reward success at key milestones rather than waiting until the end of a long project. Continually capture lessons learned about how well the team is working together and implement suggested improvements.

During the performing stage, team members tend to feel positive and excited about participating on the project. There is a sense of urgency and a sense of confidence about the team’s results. Conflicts are resolved using accepted practices. The team knows what it wants to do and is reveling in a sense of accomplishment as progress is made. Relationships and expectations are well defined. There is genuine agreement among team members about their roles and responsibilities. Team members have discovered and accepted each other’s strengths and weaknesses. Morale is at its peak during this stage, and the team has an opportunity to be highly creative.

The performing stage of team development is what every team strives to achieve. It is difficult, however, to sustain this high level of performance for a prolonged length of time, so capitalize on it while you can. The business analyst and project manager need to hone their team leadership skills to develop and sustain this most creative stage. The best course of action for the team leaders is to lightly facilitate the work: consult and coach when necessary, encourage creativity, reward performance and achievement of goals, and generally stay out of the way.

Adjourning can be thought of in the context of loss and closure. This stage of team development can be easily overlooked, as it occurs before and during a project or phase and for a short time after a project or phase is finished. During this stage of team development, the team conducts the tasks associated with disbanding the team and, to a certain extent, breaks the everyday rhythm of their contacts and transactions.

There is some discomfort associated with this stage. Surprisingly, even people whose teams have had performance issues can experience sadness or grief during this closing stage. The project leadership team should act quickly to recognize the accomplishments of individuals and the team as a whole and to help team members transition quickly to their next creative opportunity.

Traversing the Team Development Stages

The stages of team development are very much an iterative dynamic. Any change in the makeup of a team throws the team back to the very earliest stage of development, even if for a very short time. This is due to the natural evolution of teams, the addition of new members, removal of support, or changes in roles.

The balancing and leveling of power is another constant dynamic present in teams. The shifting of practical power among the core leadership team members might cause a team to revert back to the forming stage. Although this reversion might last only a short while, it is still significant; team members will have to accustom themselves to the new order. The time spent in any of the stages subsequent to the reentry into forming can vary, but make no mistake; the team will experience storming again before regaining a foothold in the norming or performing stage.

As a member of the project leadership team, you should acquaint yourself with the cycles of team development so that you can understand what the team is experiencing and manage any changes in the team’s composition or dynamics. The following table provides a quick reference on the characteristics of each team development stage.

 kitty2Oct23rd

Characteristics of Team Development Stages

Leadership Modes through the Stagesof Team Development

There are many team development models that one can use to guide team development at any given point in the project life cycle. David C. Kolb offers a five-stage team development model that suggests leadership strategies for each stage, from the team’s initial formation through its actual performance.[6]

Each stage of Kolb’s model suggests that the business analyst and project manager continually adjust their leadership styles to maximize team effectiveness and creativity. Kolb contends that a team leader subtly alters his or her style of team leadership depending on the group’s composition and level of maturity. The seasoned business analyst moves seamlessly between these team leadership modes as he or she observes and diagnoses the team’s performance. The business analyst needs to strive to acquire the leadership prowess described by Kolb. In the following table, Kolb’s stages are matched with essential leadership skills. It is particularly important for the business analyst to know when and how to assume a particular team leadership role as teams move in and out of development phases during the life of the project.

kitty3Oct23rd

FacilitatorKolb Team Development Model

In the business analyst’s function as a facilitator (the BA’s sweet spot), the main goal is to provide a foundation for the team to make quality decisions. When the team first comes together, the business analyst uses expert facilitation skills to guide, direct, and develop the group. Skills required include understanding group dynamics, running effective meetings, facilitating dialogue, fostering creativity, and dealing with difficult behaviors. Expert facilitators possess these skills:

  • Understanding individual differences, work styles, and cultural nuances
  • Leading discussions and driving the group to consensus Solving problems and clarifying ambiguities
  • Building a sense of team
  • Using and teaching collaborative skills
  • Fostering experimentation, prototyping, emergence of many like and dissimilar ideas
  • Managing meetings to drive to results
  • Facilitating requirements workshops and focus groups.

To become more credible as a team leader, the business analyst ought to acquire professional facilitation credentials such as those offered by the International Association of Facilitators (IAF). IAF’s work has identified the following six areas of core competency required for certification of facilitators. Each area is defined in more detail.

  • Create Collaborative Client Relationships
  • Plan Appropriate Group Processes
  • Create and Sustain a Participatory Environment
  • Guide Group to Appropriate and useful Outcomes
  • Build and Maintain Professional Knowledge
  • Model Positive Professional Attitude.[7]

Mediator

Transitioning from facilitator to mediator poses a challenge for new business analysts. It requires the business analyst to refrain from trying to control the team and lead the effort. The business analyst must be prepared to recognize when conflict is emerging (as it always does in teams) and be able to separate from it to mediate the situation. Although the mediator does not have to resolve the conflict, he or she must help the team members manage it. Meditation skills include:

  • Conflict management and resolution
  • Problem-solving and decision-making techniques
  • Idea-generation techniques.

Coach

Coaching and mentoring take place at both the individual and team levels. Coaching is appropriate when trust has been established among the team members and communication is open and positive. The business analyst as coach uses experiences, perceptions, and intuition to help change team members’ behaviors and thinking. Coaching tasks include:

  • Setting goals
  • Teaching others how to give and receive feedback
  • Creating a team identity
  • Developing team decision-making skills.

Consultant

As the team begins to work well together, the business analyst transitions into the role of consultant, providing advice, tools, and interventions to help the team reach its potential. The business analyst then concentrates on nurturing the positive team environment, encouraging creativity and experimentation, removing barriers, and solving problems. Consulting tasks include:

  • Assessing team opportunities
  • Supporting and guiding the team to create a positive, effective team environment
  • Aligning individual, team, and organizational values and strategic imperatives
  • Fostering team spirit.

Collaborator

Few teams achieve an optimized state and sustain it for long periods, because such a state is so intense. At this point, both the work and the leadership are shared equally among team members. The business analyst might hand off the lead role to team members when their expertise becomes a critical need during different project activities. Collaboration skills include:

  • Leading softly
  • Sharing the leadership role
  • Assuming a peer relationship with team members.

Clearly, project team leaders need to understand the dynamics of team development and adjust their leadership styles accordingly. Once a high-performing team has emerged, it is often necessary for the team leader to simply step aside. The following table maps the variations in leadership modes to the two team development models we have presented.

kitty4Oct23rd

As you plan your professional development goals, it is wise for you to include training in facilitation, mediation, coaching and mentoring, consulting, and collaborating.Mapping of the Team Development and Leadership Models

Best Team Leadership Practices for the Business Analyst

Coming together is a beginning. Keeping together is progress. Working together is success.
—Henry Ford, a prominent American industrialist, the founder of The Ford Motor Company, pioneered the development of the assembly line and mass production

The business analyst has dual team-leadership roles: (1) in general, he or she helps the other team leaders (the project manager, lead technologist, business visionary) build and sustain a high-performing project team; and (2) he or she is directly responsible for building a high-performing requirements ownership team—a team of business subject matter experts (SMEs) who take ownership of the business strategy to be advanced, the business need to be satisfied, and the business benefits to be realized by the solution. In addition, the business analyst instills in the requirements ownership team the understanding that it is their responsibility to spend enough time and energy to truly understand the business, to “think out of the building” by conducting research and analysis of the opportunity, and to collaboratively create to develop an innovative solution, as opposed to simply meeting requirements.

Who Should Take the Lead?

As a member of the project leadership team, the business analyst strives to help the team members determine who should take the lead depending on the expertise needed. For example, the project manager takes the lead during planning and statusing sessions. The business analyst leads during problem definition, opportunity analysis, solution and requirements trade-off analysis, requirements negotiation and conflict resolution, cost-benefit analysis, business requirements elicitation, solution requirements elicitation, and requirements analysis, review, and validation sessions. The project manager and business analyst may jointly lead discussions centered on issue resolution and risk analysis. The business representative should assume the lead when talking about the business vision, strategy, and benefits expected from the new solution. Then the business analyst again assumes the lead when the team is validating that the business benefits will actually be realized. Likewise, the lead architect or developer (or both) leads discussions on technology options and trade-offs. The challenge is for the core leadership team to seamlessly traverse through the leadership hand-offs so as not to interfere with the balance of the team.

The Requirements Ownership Team: A 21st Century Imperative

The business analyst’s leadership role undoubtedly involves forming, educating, developing, and maintaining a high-performing requirements team and keeping the team engaged throughout the project. The first task is determining the appropriate business and technical representatives needed to navigate through the requirements activities, then securing approval to involve them throughout the project. This is no small task, since business teams are accustomed to providing minimal amounts of information to project teams about the requirements (and these often are phrased in terms of the solution instead of the business need), and then sending the team off to do the real project work. The business analyst uses her influence, negotiating skills, and credibility to secure the participation of key business SMEs throughout the project. This involves building a strong relationship with the business owner, who is often the project sponsor, as well as other key business leaders who are influential in committing the essential SMEs.

As the requirements team comes together in workshops or other working sessions, they will inevitably pass through the same team development stages as the larger project team. The business analyst must navigate the team through the challenges of each stage of team development. The goal for the business analyst is to optimize the dynamics and expertise of the business SMEs to foster an innovative and creative atmosphere for determining business opportunities and solutions. Remember: business analysts are not note takers—they are creative leaders.

What best practices should you as the business analyst employ as the requirements team leader?

  • Meet face-to-face with business representatives, customers, and end users early and often.
  • Devote time and energy to guide the requirements ownership team through the stages of team development, changing your leadership style as the team moves in and out of stages.
  • When forming the requirements team, utilize the core team concept (small but mighty collocated teams that work collaboratively). Involve key technical SMEs (architect, lead developer, application portfolio manager) in the key working sessions of the requirements ownership team.
  • Spend enough time training requirements team members on the requirements practices and tools the team will use so that they will be comfortable with the process before they jump in head first.
  • Build a solid, trusting, collaborative relationship among the project team members and the requirements technical and business SMEs.
  • Bring in additional SMEs and form subteams and committees when needed to augment the core requirements ownership team.
  • Establish a requirements integration team to structure requirements into process groups and to manage interrelationships among requirement groups.
  • Encourage frequent meetings among the core requirements and project team members to promote full disclosure and transparency as the inevitable trade-off decisions are made.

It is not enough for the business analyst to develop requirements engineering knowledge and skills. It is also important to understand—and use—the power of teams, which leads to much more creative solutions.

Creativity: A Right-Brain Pursuit

A creative team that comes up with brilliant ideas is one of the most valuable resources any organization can have. If you want to give your creative team the best possible chance for success, give them clear ground rules and then let them run free.
—Bill Stainton, TV executive producer, speaker, author

At this point, you might be questioning our assertion that business analysts should serve as creative leaders. You might be thinking that analysts are just that—analytical, logical, methodical, questioning, reasoned, and rational. Isn’t this left-brain stuff? In fact, the business analyst needs to learn how to optimize both sides of her brain. How is the business analyst to become a creativity catalyst? By using creativity-inducing tools and techniques that make use of structured, proven problem-solving and decision-making methods (left brain) and cleverly augmenting them with investigation, experimentation, and yes, experiencing a little bit of chaos along the way (right brain).

As business analysts rise to the top of their game, they will skillfully learn to balance both the left and right sides of the brains of their SMEs (see below) in addition to their own brains. They will inspire teams to invent, imagine, and experiment. But they also will have a keen understanding of the business opportunity, the customer desires, the market window, and the executive team’s tolerance for ambiguity and research. The seasoned business analyst will instinctively know just the right moment to end experimentation and have the team put a stake in the ground. They will understand the concept of last responsible moment decision-making (i.e., do not shut down experimentation and lock into a design until it would be irresponsible to delay solution construction any longer; a delay would mean that the solution would be suboptimized and the opportunity lost.)

 kitty5Oct23rd

Right Brain vs. Left Brain Preferences

Getting There: From Ad Hoc Group to Working Group to Creative Team

According to Bill Stainton, whose presentations combine “business smarts with show biz sparks” (this is a great mental model for the creative business analyst leader), the only difference between creative and non-creative people is that creative people believe they are creative.[8]Stainton suggests that it is the job of the leader of a creative team to make its members believe that they too are creative. The leader of innovative teams does this by providing:

  • Direction. Set down boundaries, rules, and clear targets for the team. Some believe rules and boundaries limit creativity. In fact, clear targets focus us on the task at hand and liberate us to be creative.
  • Freedom. Do not tell your team how to achieve the targets. Creative people need the space to “play, explore, and discover.”
  • Stimulation. Creative people thrive in an inspirational environment, but their creativity dies in a sterile one.[9]

Commonly Understood but Little-Used Practices

The team leadership practices leadership consultant Don Clark suggests are well known, but they are not implemented often enough. A great team leader is constantly assessing the extent to which his team possesses these critical elements:

  • Inspiration: Continually reinforce the importance of the creative process to the organization as well as the value of the opportunity at hand.
  • Urgency: Develop and maintain a sense of urgency; this keeps the creative juices flowing and time-boxes decision-making.
  • Empowerment: Keep the team informed; challenge them with fresh facts and information. New knowledge just might redirect their effort or rekindle their creativity.
  • Togetherness: Teams need formal and informal time together to build constructive relationships and trust each other. One team member remarked, “We did our most creative work on a sailboat.” The team leader serves as the catalyst that brings the team together.
  • Recognition: Recognize accomplishments and communicate enthusiastically about successes. Insist on working toward small wins to sustain motivation.
  • An overarching goal: Although your team might have a number of goals, one of them must stand out as nonnegotiable.
  • Productive participation of all members: If certain members of the team are not truly engaged, the team decisions will not benefit from their perspectives, and the team may miss out on creative ideas. Communication, trust, a sense of belonging, and valuing diversity of thought and approaches are all elements that encourage full team participation. Diversity is a vital ingredient that fosters team synergy. If team members are not all engaged in articulating new ideas and challenging each other, the team has not yet reached its most creative point.
  • Shared risk taking: If no one individual fails (we all sink or swim together), then risk taking becomes a lot easier.
  • Change compatibility: Being flexible and having the ability to self correct.[10]

Collaboration: The Glue That Binds Creative Teams

Perhaps the most essential element of great innovation teams is collaboration. Jim Tamm, a workplace expert specializing in building collaborative work environments and the co-author of Radical Collaboration, tells us that collaboration does not magically happen. He contends that collaboration is both a mindset and a skill set—both of which can be learned—that can make a big difference to a company’s bottom line. After almost two decades of teaching collaborative skills in highly challenged and hierarchical organizations, Tamm discovered five essential skills for building successful collaborative environments:

  • Think win-win. Foster a positive attitude among your team members; recruit and reward people who are fun to work with and aren’t afraid of (and in fact, actually welcome) challenges and hard work.
  • Speak the truth. Dishonesty is toxic in the workplace. Always be open and honest, and expect others to do the same.
  • Be accountable. Take responsibility for your performance and interpersonal relationships. Focus on innovative solutions—the hallmark of successful teams.
  • Be self-aware—and aware of others. Work hard to understand your own behaviors, and work just as hard to diagnose and optimize the behaviors of your team.
  • Learn from conflict. Expect and capitalize on conflict—it happens whenever people come together. The secret to success is to use the conflict to learn and grow.[11]

The Innovation Imperative

Every organization—not just business—needs one core competence: innovation.
—Peter Drucker, writer, management consultant, and self-described social ecologist

The United States has enjoyed a preeminent position in the world economy for decades, largely riding the wave of success brought about by the world’s greatest innovators: Alexander Graham Bell, Henry Ford, George Eastman, Harvey Firestone, John D. Rockefeller, George Westinghouse, Andrew Carnegie, and of course, Thomas Edison. However, the 21st century brought with it immense global competitive pressure that is putting the U. S.’s economic domination at risk. Studies indicate that global innovation leadership is shifting away from the U.S., heading east to the emerging markets of China, India, and South Korea. Now is the time for us to revisit tried-and-true innovation skills and practices and once again seize competitive advantage. Business analysts are well positioned to play a vital role in this effort as they work with teams across the enterprise.

Innovation Is a Team Sport

According to Jon R. Katzenbach, author of Teams at the Top, and Stacy Palestrant, a team is “a small group with complementary skills committed to a common purpose, performance goals, and working approach for which they hold themselves mutually accountable.”[12] It may be easy to define what Katzenbach calls real teams, but they are very hard to build and even harder to keep going.

Sustained Inspiration

Katzenbach and Palestrant write that teams can initially sustain their inspiration, motivation, and drive if they are presented with a compelling performance challenge. As BAs begin to work on mission-critical innovation projects, they are undoubtedly presented with a compelling performance challenge. At the outset, teams seem to ride on the wave of their instincts and desire to do good work. Real teams, however, succeed only if their leaders make sure the team members consistently apply what is referred to as the essential discipline. In a situation where performance challenges are changing rapidly, which is almost always the case in today’s Internet-speed business cycles, it behooves team leaders to continually assess team health and instill team discipline.[13](*Is this entire paragraph based on Katzenbach & Palestrant? If so, insert new note.)

A Team Culture of Discipline

As Jim Collins writes in Good to Great, it is important that organizations build a culture of discipline.[14]It is a commonly held misconception that the imposition of standards and discipline discourages creativity. A project team is like a start-up company. To truly innovate, the team needs to value creativity, imagination, and risk-taking. However, to maintain a sense of control over a large team, we often impose structure, insist on planning, and institutionalize coordination systems of meetings and reports.

The Entrepreneurial Death Spiral

As we have discussed, the risk of requiring too much rigor is that the team becomes bureaucratic. Collins calls this the entrepreneurial death spiral. He contends that “bureaucracy is imposed to compensate for incompetence and lack of discipline—a problem that largely goes away if you have the right people in the first place.” The goal is to learn how to use rigor and discipline to enable creativity. Great teams (think emergency responders and surgical teams) almost always have rigid standards; they practice the execution of those standards over and over again until they become second nature; and they work hard to examine each performance and improve the standards based upon experience. So, as Katzenbach tells us, “Team performance is characterized at least as much by discipline and hard work as it is by empowerment, togetherness, and positive group dynamics.”[15]

Quick Team Assessment

Jim Clemmer writes, “Despite all the team talk of the last few years, few groups are real teams. Too often they’re unfocused and uncoordinated in their efforts.”[16]Clemmer developed the following set of questions based on his consulting and team development work. This team assessment and planning framework can be used to help newly formed teams come together and get productive quickly or to help existing teams refocus and renew themselves. Use this simple approach to assess team performance by having your team develop answers and action plans around each question. Perhaps add a question or two about creativity, innovation, and operating at the edge of chaos.

  • Why do we exist (our purpose)?
  • Where are we going (our vision)?
  • How will we work together (our values)?
  • Who do we serve (internal or external customers or partners)?
  • What is expected of us?
  • What are our performance gaps (difference between the expectations and our performance)?
  • What are our goals and priorities?
  • What’s our improvement plan?
  • What skills do we need to develop?
  • What support is available?
  • How will we track our performance?
  • How/when will we review, assess, celebrate, and refocus?[17]

Putting It All Together: What Does This Mean to the Business Analyst?

The lesson for the business analyst is this: work hard with other project leaders to impose a culture of discipline in your project team. Build improvements into the team’s interactions, imaginings, experimentations, problem-solving, and decision-making processes at every feedback point. Become an expert at developing and sustaining high-performing teams. To do this, you need to develop your unique leadership style, one that makes high performers want to be on your team.

Don’t forget to leave your comments below.


 

Endnotes

[1]. Thomas A. Stewart, “The Corporate Jungle Spawns a New Species: The Project Manager,” Fortune (July 1995): 179–80.
[1]. Jon R. Katzenbach and Douglas K. Smith, The Wisdom of Teams: Creating the High-Performance Organization (Boston: Harvard Business Press, 1993), 20-21.
[1]. Poppendieck, LLC, “Reflections on Development,” www.poppendieck.com/development1.htm (accessed May 2011).
[1]. Ibid.
[1]. Katzenbach and Smith, 24-26.
[1]. Bruce W. Tuckman, “Developmental Sequence in Small Groups,” Psychological Bulletin 63, no. 6 (June 1965): 384–399.
[1]. David C. Kolb, Team Leadership (Durango, CO: Lore International Institute, 1999), 9-18.
[1] International Association of Facilitators. Online at: http://www.iaf-world.org/index/Certification/CompetenciesforCertification.aspx (Accessed May 2011).
[1]. Bill Stainton, “How To Lead a Creative Team,” http://ovationconsulting.com/blog/how-to-lead-a-creative-team (accessed August 2010).
[1]. Ibid.
[1]. Don Clark, “Growing a Team,” http://www.nwlink.com/~donclark/leader/leadtem.html (accessed August 2010).
[1]. James W. Tamm, “The ‘Red Zone’ Organization,” Innovative Leader 14, no. 5 (January–March 2006), http://www.winstonbrill.com/bril001/html/article_index/articles.html (accessed August 2010).
[1]. Jim Clemmer, “Harnessing the Power of Teams,” http://ezinearticles.com/?Harnessing-the-Power-of-Teams&id=109593 (accessed August 2010).
[1]. Ibid.
[1]. Jon R. Katzenbach and Stacy Palestrant, “Team Leadership: Emerging Challenges,” Innovative Leader 9, no. 8 (August 2000), http://www.winstonbrill.com/bril001/html/article_index/articles/451-500/article482_body.html (accessed May 2010).
[1] Ibid.
[1]. Jim Collins, Good to Great (New York: HarperCollins Publishers, Inc., 2001), 120–143.
[1] Jon R. Katzenbach and Stacy Palestrant, “Team Leadership: Emerging Challenges,” Innovative Leader 9, no. 8 (August 2000), http://www.winstonbrill.com/bril001/html/article_index/articles/451-500/article482_body.html (accessed May 2010).

Look for Next Month’s Article: Igniting Creativity in Complex Distributed Teams


[1]. Jon R. Katzenbach and Douglas K. Smith, The Wisdom of Teams: Creating the High-Performance Organization (Boston: Harvard Business Press, 1993), 20-21.
[2]. Poppendieck, LLC, “Reflections on Development,” www.poppendieck.com/development1.htm (accessed May 2011).
[3]. Ibid.
[4]. Katzenbach and Smith, 24-26.
[5]. Bruce W. Tuckman, “Developmental Sequence in Small Groups,” Psychological Bulletin 63, no. 6 (June 1965): 384–399.
[6]. David C. Kolb, Team Leadership (Durango, CO: Lore International Institute, 1999), 9-18.
[7] International Association of Facilitators. Online at: http://www.iaf-world.org/index/Certification/CompetenciesforCertification.aspx (Accessed May 2011).
[8]. Bill Stainton, “How To Lead a Creative Team,” http://ovationconsulting.com/blog/how-to-lead-a-creative-team (accessed August 2010).
[9]. Ibid.
[11]. Don Clark, “Growing a Team,” http://www.nwlink.com/~donclark/leader/leadtem.html (accessed August 2010).
[11]. James W. Tamm, “The ‘Red Zone’ Organization,” Innovative Leader 14, no. 5 (January–March 2006), http://www.winstonbrill.com/bril001/html/article_index/articles.html (accessed August 2010).
[12]. Jon R. Katzenbach and Stacy Palestrant, “Team Leadership: Emerging Challenges,” Innovative Leader 9, no. 8 (August 2000), http://www.winstonbrill.com/bril001/html/article_index/articles/451-500/article482_body.html (accessed May 2010).
[13] Ibid.
[14]. Jim Collins, Good to Great (New York: HarperCollins Publishers, Inc., 2001), 120–143.
[15] Jon R. Katzenbach and Stacy Palestrant, “Team Leadership: Emerging Challenges,” Innovative Leader 9, no. 8 (August 2000), http://www.winstonbrill.com/bril001/html/article_index/articles/451-500/article482_body.html (accessed May 2010).
[16]. Jim Clemmer, “Harnessing the Power of Teams,” http://ezinearticles.com/?Harnessing-the-Power-of-Teams&id=109593 (accessed August 2010).
[17]. Ibid.

Five Lessons Learned from Harry Potter in the Room of Requirement

FEATUREOct9thOn a recent plane trip, when I saw Harry Potter and the Deathly Hallows 2 for a second time, I was struck by the scene in which Harry Potter enters the Room of Requirement. This magical room is one that “a person can only enter when they have real need of it [and…] is always equipped for the seeker’s needs.” It has a way of transforming itself as the need changes, so sometimes it is nearly empty and sometimes jam-packed with different objects from chamber pots to jeweled crowns. I sometimes imagine that our requirements workshops are held in similar rooms of requirements. Each time we elicit requirements from our subject matter experts (SMEs), the room is different. Each person entering the room, virtually or physically, has specific needs and each idea its own use. Sometimes there are an abundance of ideas generated and sometimes very few. And each requirements workshop can be filled with overwhelming challenges. In this final film, the ability of good to triumph over evil depends on finding a lost diadem, or crown, in the Room of Requirement. The intrepid business analyst (BA) faces similar challenges in their requirements rooms. Here are some that Harry and BAs both face:

  1. Getting the high-level” what” is much easier than getting the necessary detail. Harry knows what he needs to find in the room of requirement– a diadem. So how hard can it be to find it once he’s in the room? Very hard, because although he has the high-level “what,” he has no idea what it looks like. He has no detail describing it, and he is frustrated as he looks around the very large room filled with objects from floor to very tall ceiling. He seems to have forgotten that to use the Room to maximum effect, those who enter are advised to be very specific about what they are looking for.” [1]After some minutes searching fruitlessly, however, Harry uses an effective technique to find the diadem. He listens.

    As BAs, we are often given high-level requirements. The level is too high, however, to describe the need in enough detail to build the end product. For example, user stories describe high-level requirements, but need to be fleshed out. Use case models provide high-level processes, but without the narrative flow of events, the requirements remain incomplete. A business process with the primary path but no alternate paths is also a good start, but only a start. And one of the best ways to get that detail is active listening.

  2. When we are under a great deal of pressure to find what we seek, we usually rush superficially through the business analysis work. Harry and his friends have almost no time to find the diadem. With no plan to guide them, they search frantically and chaotically. It isn’t until Harry takes the time to get additional information from an important stakeholder (the Ravenclaw ghost) that he can really focus on his goal.

    As BAs we are often under pressure to complete our business analysis work quickly. When we give in to such pressure, we often misdirect our efforts and the result is rework, dissatisfied customers, and an effort that costs more in time and budget, to say nothing of team morale. Like Harry, we need a plan, we need to be focused, and we need to take the time to talk to stakeholders who can guide us to the correct and complete requirements.

  3. Some people have a vested interest in throwing up roadblocks. Harry soon learns that he is not alone in the Room of Requirement and that others desperately want to prevent him from succeeding. In the battle of Good (represented by Harry and his cohorts) vs. Evil (represented by Draco Malfoy and his cohorts), Evil has a vested interest in preventing Harry from first entering the Room of Requirement and then finding the diadem.

    Unfortunately, we sometimes encounter stakeholders who do not want to see the projects succeed. Those who resist change (sometimes for good reasons), who have to learn to use a new systems or follow a new process, who have to sell and support new products, who will no longer be domain experts, and/or those who might lose their jobs in cost-cutting effort, may use a variety of tactics to stall or stop the business analysis activities. We need to do what we can to build trust with them, to understand the root cause of their fears, to explain how the change benefits them, and to get their input—even when they are reluctant to give it.

  4. It takes courage to enter the Room of Requirement. One of the few things we know as Harry enters the Room of Requirement is that success is critical and must be achieved, regardless of the certainty of danger and possibility of death. And indeed, among other things, Harry and his friends face the Fiendfire, a monster of fire that consumes everything in its path as it envelops the Room of Requirement.

    As BAs we sometimes face our own Fiendfires. Uncooperative, unavailable, or unengaged SMEs, sponsors who don’t understand why it takes so long to elicit requirements, pet projects that do not align with business goals and objectives , and technical experts who are needed but are working on other projects, are just a few of the many “fiendfires” we face. Our tendency is to yield to time pressures and try to do everything ourselves, but that’s not usually the right thing for the organization. And it takes courage to take the time to understand the real business need, to recommend the right thing, and to refrain from moving forward ourselves without engaging the stakeholders. It takes courage to explain why requirements activities take time and why key stakeholders are needed. And it takes courage to point out the risks when they are not.

  5. We cannot succeed by ourselves. Harry Potter needs the help of his close friends Ron and Hermione. They work as a team, each with different talents. Each is an important part of the team and if any were missing, they would not be successful. From time to time one of them goes missing, but success is only attained when the three of them work together.

BAs can be successful only when we work together with the other stakeholders. Collaboration is one of the key success factors to navigating through the Room of Requirement.

Don’t forget to leave your comments below.


[1] Wikia, Harry Potter Wiki, http://harrypotter.wikia.com/wiki/Room_of_Requirement, viewed on January 5, 2012.

 

What Are the Stages of Team Evolution?

Almost half a century ago, the American psychologist Bruce Tuckman published a theory of team evolution.[i] Agile software development teams did not exist at the time, but Tuckman’s Group Development model applies well to them. According to the model, a team has to proceed through a certain sequence of stages on the way to the desirable stage, performing.

In the initial stage, forming, members learn what the team is supposed to accomplish. They get to know each other and their first-draft idea of roles and responsibilities. In this stage, most of the work is still individual, and some members try extra hard to look good. The forming stage is generally short-lived, overshadowed by the realities of the next stage.

In the second stage, storming, the team experiences conflict and difference of opinion. Some of the decisions they need to make draw out tensions and emotions. There might be some jockeying for influence and leadership. In a new Agile team, the first several iteration planning sessions tend to include disagreements about estimation approaches, the extent of detail in user stories, and task assignments.

If the team can pull itself out of storming, whether on its own or with your guidance as the Agile team leader (ATL), it reaches the third stage, norming. Members understand the rules of engagement. They establish, follow, and adapt agreements. Everyone understands the team’s goals the same way and cooperates to achieve them. They know and follow their process.
The fourth stage, performing, is the big deal. A performing team doesn’t just hum along — it buzzes. Its members are motivated and delighted to be there. They don’t have to speak with the same voice, but they don’t let conflict turn into confrontation. Consensus and self-organization are easy for them. They don’t worry about making their team work anymore; that has been taken care of, and now they focus on results. They don’t merely cooperate, they collaborate.

The following diagram[ii] shows the change in the team’s effectiveness in the various stages. Note that the qualitative effectiveness level in norming is similar to that of forming. In forming, they are a group of individuals who apply themselves; in norming, the added value of their teamwork may still not compensate for the energy they spend on being a team.

GilBrozaAug71

This model has several important implications for you. The team is at risk of never reaching norming. Team growth is evolutionary, and success is not inevitable. Even with the most suitable people using the best methods with good support, there is no guarantee they will graduate from the storming stage. Some teams may appear to have normed, but in reality they put on a happy face, stifle all conflict and differences, and defer to their product owner and managers.

Three teams were working on a single program. To be cross-functional, each team had been formed with half of the Batch Team (back-end) specialists and half of the Online Team specialists, in line with the main technological divide. Each half was further divided into programmers and testers, working in handoff fashion. Iteration planning sessions were muted and ineffective; retrospectives were louder but resulted in little traction. After a year of using Scrum, they struggled mightily to figure out roles and collective ownership — self-organization was all but moot. Few people seemed happy.

Expect conflict. If you put intelligent, capable people together and ask them to share responsibility for a goal, how likely are they to agree on the means to get there? How likely are they to exhibit a healthy balance of leadership and followership? Conflict is necessary for the elaborate dance of team growth. It is not inherently detrimental, unless it is allowed to devolve into confrontation and one-upmanship.

The road to low performance is paved with good intentions. Whenever you add people to a team, even temporarily (such as contractors), you knock the team down a stage or two as they adjust to their new composition. New permanent members require an investment of time, energy, and goodwill from veteran members. If you redeploy a valued member to seed or help another team, the remaining members will restorm to fill the void and adjust their leader-follower patterns. (You can mitigate the effect by seeking their agreement to the move.) If you remove a noncontributing member, the team will have to adjust the norms they had established to accommodate that person. All these changes in team composition spell a drop in performance, which might last longer than you intend, even indefinitely.

“Our team was originally bolstered with several contractors, who stayed for differing periods. Only once the last contractor had left and we had settled into a stable team — well over a year after the team was first created — did I feel the team really started to jell.”

— Ian, software ATL in a hardware company

About the book

The excerpt above is from the book The Human Side of Agile: How to Help Your Team Deliver which will be available September the 12th. The human side of Agile is tricky. It’s the least manageable, understood, and appreciated asset in an Agile environment. Even if your customers are reasonably happy and your developers seem to be doing okay, you know your team is capable of more: delivering great products and staying ahead of ever-changing demands. You want to feel good about using Agile and to create the conditions for great results, but the skills you honed in traditional environments don’t always apply to the role of Agile team leader. The Human Side of Agile fills this gap, guiding you to:

  • Establish yourself as a confident and capable leader who adds value
  • Build and lead an engaged team that can handle almost any challenge
  • Cultivate collaboration and a continuous improvement mind-set
  • Reap the full benefits of Agile in the real world with real people

[i] The original paper is Bruce Tuckman, “Developmental Sequence in Small Groups,” Psychological Bulletin 63 (1965): 384–99. For a recent review of the concept, see Mark K. Smith, “Bruce W. Tuckman — Forming, Storming, Norming and Performing in Groups,” Encyclopaedia of Informal Education (2005), www.infed.org/thinkers/tuckman.htm. In 1977, Tuckman added a fifth stage, “Adjourning,” to describe the dissolution of the team (Bruce Tuckman and Mary Ann Jensen, “Stages of Small Group Development Revisited,” Group and Organizational Studies 2 (1977), 419–27). While this important stage is potentially stressful for some members, it is outside the scope of this book.

[ii] Based on Jon R. Katzenbach and Douglas K. Smith, The Wisdom of Teams: Creating the High-Performance Organization (Harvard Business Review Press, 1992).

Don’t forget to leave your comments below.