Skip to main content

Tag: Team

Seven Common Mistakes with the Daily Stand-up Meeting

The daily stand-up meeting, also known as the daily scrum, may be the best of all of the agile practices. Why? Because it meets three criteria:

1. It’s easy to start using
2. It can often be used without other agile practices
3. It provides great value

Stand-ups can be interjected into waterfall teams and they can be used without converting to iterations or other common agile practices. From an adoption perspective, the resistance to using stand-ups is low. From a value perspective, teams quickly see the how the stand-up identifies risks and issues early. The stand-up gives them more time to react and still hit their goals.

As good as the stand-up meeting is, if done incorrectly it can do more harm than good. As an agile coach I have found I often skimp on stand-up training because it seems so simple. But this skimping has come back to bite me several times. How have I been bitten? By the seven common stand-up mistakes below.

Mistake # 1 – Not Standing (the daily sit down)SmithDec18 Img02

Teams usually stand when they first start doing the daily stand-up because they have just came out of agile training and they were taught to stand. But as time progresses it is common for some teams to assume standing is a formality and they start sitting more and more. This especially common if the meeting is in a conference room where chairs are available.

Standing is not a formality but rather a key success factor in establishing collaboration and keeping the meeting short and effective. How can you keep the team standing? Here are some tips that usually help:

  1. Try to do the stand-up where chairs are not available.
  2. Keep the team focused on the three key questions: What did you do since we last met? What will you do between now and the next meeting? Do you have any blockers or constraints that are impeding your progress? It is common for team members to explain their impediments in detail, and for a dialogue to start up between a few team members on how to resolve the impediment. This is fine if a solution is agreed to in a few seconds, but usually this a long conversation that ties up the whole team when only a few team members are needed. So as a Scrum Master, coach, or team member, get select team members to work impediments together after the stand-up.
  3. Use a physical status wall (covered in mistake # 5 below).

Mistake # 2 – Team Members Not Showing Up On Time

Many teams struggle with team members drifting into the stand-up, often 5 to 10 minutes late. This contributes to the issue noted above, not standing, but also demonstrates a lack of personal discipline. Here are some tips for addressing the late arrival issue.SmithDec18 Img03

  • Pick a time of day that the team all agrees to, to have the stand-up. Sometimes management will ask the Scrum Master to have the team meet at a certain time, but I have found it is better to meet when everyone has arrived at work, and at a time the team all agrees to.
  • Get support from line managers. Agile is about team self-management and self-discipline, but everyone does not arrive at this state at the same time. If you are a Scrum Master, work with all of the managers who team members work for, and get agreement that the daily stand-up is important, and that punctuality is important. Line managers can emphasize these values when they do one on ones with their team members.
  • Provide a buffer between meetings that occur before the stand-up. If there is another meeting that precedes the stand-up, make sure the stand-up is not scheduled when the other meeting ends. Instead add a buffer of 10 to 15 minutes so that the stand-up is not impacted by any upstream meetings that runs over.

Mistake # 3 – Allowing DistractionsSmithDec18 Img04

Daily stand-ups are ineffective if the team is not focused during the stand-up. Here are some tips for keeping the focus:

  1. Location, location, location. If you do your standup meeting in the wrong location the team will get interrupted by passers by, or be distracted by eye candy such as the street below. Pick a location without chairs, some level of isolation, and if possible no windows.
  2. Set a team norm of no cell phones or laptops during the standup.
  3. Focus on good meeting etiquette – no side conversations or whispering.

Mistake # 4 – Updating the Project Management Tool During the Stand-upSmithDec18 Img05

Are you using an online tool to track project status? Maybe Mingle, Rally, or VersionOne? Many times the team will stand idle while someone is updating the tool during the stand-up. Try to avoid this at all costs. Have someone take hard copy notes and update the tool later, or even better, use a physical status board and have team members physically update their tasks during the daily stand-up. Remember that the tool serves the team, the team does not serve the tool.

Mistake # 5 – Not Using a Physical Status Wall

SmithDec18 Img06I love electronic project management tools. They let me consolidate information and do reports across a portfolio of projects. But the tools can impede collaboration during the daily stand-up. If one person is projecting the virtual status wall from an electronic tool, and discussing it with the team, the team often becomes an audience and just listens. However, if you have a physical wall with task cards, team members move and update their physical cards during or before the stand-up, which leads to much richer discussion and interaction. You can use an electronic tool in parallel (most of my clients do). It may be a little redundant, but the value a physical wall provides offsets maintaining 2 tools. And it will lead to a better stand-up meeting.

Mistake # 6 – Not Having a Dedicated Team Room

SmithDec18 Img07

You may be wondering why you need a dedicated team room for a stand-up. You do not need a dedicated team room for the stand-up meeting, but you do need one for a good stand-up meeting. Confused? Here is the scoop. If your team is distributed all over your campus, and they come together physically each day for 15 minutes, do you think you can get them to only discuss status? I have not been successful in doing this. Developers and testers will want to get into testing details during the stand-up, user experience wants to talk to developers about screen details, and so on. If you have a dedicated team room, team members can talk about the construction details all day long, and they will not need to deviate from the stand-up status/impediment discussion.

Mistake# 7 – Not Using a Stand-up for Distributed Teams

SmithDec18 Img08Most companies I work with have team members in the United States, India, and China. These teams will often tell me they cannot do stand-ups because everyone is in different time zones. I understand this issue but I also understand that we undertake a lot of risk if we do not communicate daily. To get around this issue I have teams do the following:

  1. Do a stand-up meeting at each location. At a minimum get team members synchronized at each site
  2. Have one team member from each team work a staggered schedule. These team members on staggered schedules can do a video call or audio call to synchronize each day, and then take that information back to their local teams.
  3. Use electronic tools to share status details. Electronic tools really show their value with distributed teams. Everyone can see the status information around the world, as soon as it is entered.

Follow these steps and you will establish a sound daily stand-up process, which will provide a great foundation for all of the agile practices you use with your team.

Don’t forget to leave your comments below.

Finding The Right Blend: Sometimes Pure Agile Isn’t The Way To Go

Agile Hybrid/Blended Approach

Only a fraction of organizations will migrate to Agile methods completely and for all projects. The reality is, many types of projects are not well suited for Agile approaches for a variety of reasons. Some organizations run multiple projects across many departments and corporate entities, many of which may not have the inclination or resources to manage in an Agile manner. Others have made significant investments in traditional or proprietary methodologies and are not prepared to simply abandon them. Further, many companies are global, with development resources located around the world, in different time zones, with varying local corporate cultures and working styles. 

For all of these reasons, Agile project managers need to be prepared to work in cooperation with non-Agile project managers, teams that employ traditional methods, and organizations that have resources scattered around the globe.

How the Blended Approach Works 

Agile adoption doesn’t need to be an all-or-nothing, either-or scenario. The very incremental, iterative concepts that Agile project managers (PMs) apply to their projects can also be applied to Agile adoption. For instance, teams that are migrating to Agile methods can adopt certain elements, such as user stories in place of requirements definition, and incremental, rather than “big-bang” planning, as ways to ease into the Agile migration. While these incremental methods will not offer all of the advantages of the total Agile environment, they have the advantage of being less disruptive to existing approaches and offer “proof points” to reassure managers and teams that these methods can deliver the expected results.

Where Agile Fits 

There are a number of areas where the Agile method can fit into a non-Agile project. Remember that the success of Agile methods revolves around the customer and the team. It is really about collaborating at all levels of the project. When they work in concert with one another, the project deliverables are much easier to complete. In your Waterfall or non-Agile project, look for places where you can easily adopt the top four key Agile methods: 

  • Iterative delivery of customer value
  • Early and frequent customer feedback
  • Working in highly collaborative, multifunctional teams
  • Continuous inspection and adaptation

The preceding methods are based on the Agile Manifesto’s value statement. The focus of the Manifesto is on the following: 

  • Individuals and interactions
  • Working software
  • Customer collaboration
  • Responding to change

Take a look at your Waterfall project and identify where you can leverage the power of customer involvement. Typically, you will be able to modify your Communication Plan, Stakeholder Management Plan and Risk Management Plans with an Agile approach. This proactive approach will allow you to ensure that impediments, which delay delivery of product, are managed and eliminated. 

Proof Points 

Because Agile methods focus on the customer, team, iterative delivery, and continuous adaptation or change, it is recommended that Waterfall-focused organizations begin to test the waters of Agile by using “proof points.” Proof points are areas within a Waterfall project where you can “prove” the power of Agile elements. Not only will this help move the project forward, but also, it highlights the value of the Agile methodology and helps an organization transition from using 100% Waterfall approaches to Agile methods. 

Good opportunities to show proof points are within the planning, requirements and team communications areas of a project. 

  • Start by approaching the work on a project by not only planning the entire project, but also planning the specifics of how a certain work package can be delivered. 
  • Implement the practice of user stories to define the requirements differently.
  • Leverage the power of daily stand-up meetings (5 to 10 minute meetings in which everyone stands to keep things brief ). They allow the project team members the opportunity to share work progress and possible obstacles that may lead to challenges in completing the work package.
  • Use daily stand-up meetings to empower the team members to have open communication, while supporting each other to eliminate impediments.

These areas begin to shift an organization’s mindset on how projects can be delivered differently. They offer the opportunity for organizations to embrace Agile while in the comfort of traditional project management. 

Not One Size Fits All 

It is important to recognize that Agile project management is not a one-size-fits-all philosophy. In fact, a foundational concept of Agile is the idea that every project should be considered as a unique entity, and PMs must make determinations for each unique effort regarding the amount of documentation, process rigor and management oversight required. This adaptive approach to project management also enables the ability to interweave elements of traditional project management into an Agile approach.

There’s no reason why an Agile approach cannot have a Gantt chart if managers or stakeholders request one—as long as it’s made clear that the chart will only schedule out as far as the iteration or release currently being built. The knowledge areas, process areas and artifacts of traditional project management are still applicable in an Agile environment, as long as they are adapted to the core concepts of incremental, iterative design and change readiness. Agile methods are called “adaptive” for a reason. Agile project managers need to remind their stakeholders and teams that agility is the very opposite of rigidity and inflexibility. Both the substantive and human elements of change must be considered, and the transition should be made to an Agile environment that is appropriate to the culture and practices of an organization.

Don’t forget to leave your comments below.

Tap into the Power of Thanks

Six Effective (and Affordable) Ways to Improve Your Organization’s Morale, Motivation, and the Bottom Line

In so many organizations, employees go through their days assuming that their coworkers, and especially their bosses, don’t notice or appreciate all of the hard work that they do. And if that’s the way they feel, employees won’t have any true motivation or dedication, and productivity will be mediocre at best. 

In the midst of an already-tough economy, this is the absolute last thing you want for your organization. In a very real way, tapping into the spirit of Thanksgiving can tip the balance between success and growth and stagnation and failure.

If you’re a leader who wants to harness the power of thanks (or even an employee who wants to start a grassroots movement), read on for six how-to tips:

Always say “thank you.” By taking a few seconds out of your day, you will improve another person’s mood, day, and productivity level. You’ll also be making yourself more approachable and likeable, and over time your team will begin to relate to you more positively. Actually, I have found that consistent and heartfelt recognition—when it is deserved, of course—is a better long-term motivator than money.

Take intent into account. I often tried to show my employees just how much I appreciated them by sending high achievers to sports games, highlighting various employees in company newsletters, planning company parties, etc. Sometimes those plans were well received; other times they weren’t.

Inevitably, there will always be someone who says, “Gosh, the food at this party tastes horrible,” for example. I’m bringing this up because you need to remember that despite negative feedback, showing gratitude is always the right thing…and the majority of non-complainers probably loved your gesture.

Start being more open. If you’re a leader, constructively tell your people how they can improve their performances. If you’re a team member, be proactive about asking your coworkers and boss how you’re doing and how you can get better at your job. And no matter what your position is, learn how to receive constructive criticism.

Showing others that you care enough to either help them or to improve yourself is a form of gratitude, because you’re demonstrating that your team is worth the investment of your time, energy, and advice.

Learn to graciously accept thanks. How you respond to appreciation is also important. If you brush off compliments or ignore expressions of gratitude—even if it’s because you’d rather stay out of the spotlight—you’ll eventually stop hearing “thanks!” altogether, and you’ll be discouraging the person complimenting you from reaching out to others in the same way. Whenever someone thanks you or notices something positive about you, try to truly engage with them and let them know that their words have been meaningful.

Keep the gratitude going outside of your organization. Thank your customers or the people you serve for choosing your organization, and for trusting your team with their money, health, products, or publicity, to name a few examples. This is something that many clients don’t hear, so when they do, their loyalty to your company is strengthened. You might also consider offering discounts, coupons, or promotions to show customer appreciation.

Use gratitude to reinforce stellar performances. Using gratitude to shape your team’s habits and priorities can be every bit as valuable as training programs and industry conferences…at a fraction of the time and cost.

Whenever I saw an employee going out of her way to make sure that the product a client purchased was the best possible value, I thanked her for doing it. If a store manager made a mistake and came clean to me about it, I thanked him for that, too. Never forget that whatever you acknowledge positively will be repeated.

Throughout my years of leadership, I became more and more amazed by just how strong the power of thanks really is. Gratitude is an amazing motivator, it strengthens employee and customer loyalty, and it really can allow you to see a positive change in your company’s bottom line. And especially in today’s not-so-stellar economic environment, it’s extra-important to give your people something to be positive about and thankful for.

Don’t forget to leave 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.

The Broken Telephone Game of Defining Software and UI Requirements

The broken telephone game is played all over the world. According to Wikipedia, the game is played as follows: “one person whispers a message to another, which is passed through a line of people until the last player announces the message to the entire group. Errors typically accumulate in the retellings, so the statement announced by the last player differs significantly, and often amusingly, from the one uttered by the first.”

This game is also played inadvertently by a large number of organizations seeking to define software and UI requirements by using information passed from customers to business analysts to UI/UX designers and then to developers and testers.

Here’s a typical example:

  • The BA or product owner elicits requirements from a customer and writes them down, often as a feature list and use cases.
  • The use cases are interpreted by the UI/UX team to develop UI mockups and storyboards.
  • Testing interprets the storyboards, mockups, and use cases to develop test cases.
  • The developers then interpret the use cases, mockups and storyboards to write the code.

As with the broken telephone game, information is altered with each handoff. The resulting approach includes a lot of rework and escalating project costs due to combinations of the following:

  • Use cases don’t properly represent customer requirements.
  • UI/UX design is not consistent with the use cases.
  • Incorrect test cases create false bugs.
  • Missed test cases result in undiscovered bugs.
  • Developers build features that don’t meet customer needs.

The further down the broken telephone line the original requirements get, the more distorted they become. For this reason, UI storyboards, test cases and code typically require a lot of reworking as requirements are misunderstood or improperly translated by the time they get to the UI and testing teams.

How Can We Reduce the Broken Telephone Effect?

The good news is that there are some reasonably simple changes to processes and deliverables that will decrease the broken telephone effect. The following techniques share the goal of reducing handoffs and translations.

Interview the customer with cross-discipline teams

One method is to involve the BA, UI/UX and quality assurance people directly in the elicitation process with the customer. You can even make a case to include the lead developer as well. Having all disciplines represented during the interview process lets each party hear requirements directly from the customer, reducing the reliance on BA documents alone. An equally important benefit is that each discipline brings a different perspective, which can lead the interview process down different paths of conversation and requirement gathering.

For example, the QA resource may ask more questions about the requirements related to edge or error conditions than the BA or UI/UX resource. Putting a UI/UX member in front of the customer will provide a chance to understand features that are frequently used to manage the cognitive load of the end user.

Combine and evolve use cases, UI mockups, and UI storyboards into an integrated deliverable

Another approach to reduce the broken telephone effect is to avoid creating use cases, mockups and storyboards as separate deliverables by combining them into one “integrated deliverable.” To create an integrated deliverable, start with the use case and attach UI mockups to each step. This automatically creates a UI storyboard that has the same steps (including main and alternate flows) as the use case, and means they don’t get out of sync. Also, since the UI mockups are attached to each step, you know they will be consistent with the purpose and requirements outlined in the step.

Often, new requirements or changes to existing requirements emerge, and if your storyboards and mockups are separate from the use cases, the original use cases are not updated. This creates confusion for your developers, testers and stakeholders. Combining your use cases, mockups and storyboards into one integrated deliverable makes it much easier to keep all three in sync, dramatically reducing the potential for conflicting requirements.

The integrated deliverable approach encourages collaborative and combined authoring and review of use cases and UI/UX design by your BA and UI/UX teams, resulting in more accurately defined and understood requirements.

To bring this concept to life, here’s an example that starts with the use case defined by the BA or product manager, without any mention of UI-specific requirements.

Use Case: ATM Cash Withdraw

The steps with the Y-shaped symbol are steps with alternate flows.

Oct9thMartin1

Alternate Flows

Oct9thMartin2

Oct9thMartin3

When the UI/UX team starts attaching UI mockups to each of the steps, a UI storyboard is created that uses the same exact main flow and alternate flows as the use case. A UI storyboard expressed in terms of a main flow and alternate flows has the benefit of reducing the number of traditional linear storyboards. If you were to create traditional UI storyboards for each of the unique paths through the use case above, you’d have 11 in total, with duplicated steps across them. UI storyboards with main flows and alternate flows reduce rework and errors that pop up in linear UI storyboards.

You can do this in Word by inserting UI mockup images created in a different UI mockup tool, but keeping the UI mockups up to date in the will become time-consuming and error-prone. Products such as PowerStory (a plugin for PowerPoint) make this easier by enabling you to combine use case steps with UI mockups to create UI Storyboards.

In the following screen shot you will see that PowerStory adds a panel specifically designed for creating main flows and alternate flows of use cases, and associates the steps in these flows with typical slides in PowerPoint.

Oct9thMartin5

As before, the steps with the Y-shaped symbol beside them indicate an alternate flow. When you hover over the icon you can view and enter the alternate flows associated with that step.

Oct9thMartin6

PowerPoint is an extremely powerful tool for creating UI Mockups that can support more UI design ideas than typical wireframe mockup tools, especially with plugins like PowerMockup and Microsoft’s upcoming storyboarding plugin.

Write use cases and UI storyboards with testing in mind

Test cases typically include a “user action” followed by an “expected result.” If you spend a little more up-front time defining which steps are “user actions” and which steps are “expected results” when creating your use cases and UI storyboards, you can save your testing team time. Use cases are well suited for this approach by defining the principle actor for each step. Any step where the actor is a system should be classified as an “expected result” step for the test case, and any step where the actor is an end user should be labeled “user action.”

One of the test cases derived from the combined use case defined above is shown below, following the rule that a step with an end user actor is an action and a step that has a system actor is an expected result.

Oct9thMartin4

Automate the creation of your test cases directly from your use cases

Using tools that will automatically generate test cases from your use cases and UI storyboards will save you a significant amount of time and money typically spent by your testing team creating manual test cases. In the context of this article, it also eliminates a handoff and thus mitigates the broken telephone effect. When QA teams interpret requirements and translate them into test cases, they might misunderstand requirements and create faulty test cases and/or miss requirements and their corresponding test cases.

Key Points to Take Away

Developing software requirements, UI designs, and test cases can mirror the broken telephone game we all played as kids. Every time we pass information on, it gets changed and misinterpreted, leading to increased project costs and the delivery of the wrong solutions to your customers. Following the steps outlined above, you can reduce the broken telephone effect and follow a more streamlined process to clear and lucid product development.

Don’t forget to leave your comments below.