How To Set Smart(ish) Goals For Testers Part 3

 

Last week I appeared as part of the QA Touch Virtual Series. I spoke on the topic of goals and setting goals. I used the presentation to bring together a number of ideas about goals and goal setting, and this essay, in turn, is based on the presentation. This is Part 3, please read parts 1 and 2 before reading this section.

Read Part 1                  Read Part 2

Part 3: 

Setting goals is important for deciding and communicating what you want to achieve in a specific period. Goal setting provides value by forcing a degree of introspection, acting as a filter to separate the important from the irrelevant, and as a guide to channel behavior. Like many things in life the journey is often as important as the destination; however, setting goals is complex because there several systematic problems that affect setting goals.

 

How To Set Smart(ish) Goals For Testers Part 2

 

Last week I appeared as part of the QA Touch Virtual Series. I spoke on the topic of goals and setting goals. I used the presentation to bring together a number of ideas of goals and goal setting, and this essay, in turn, is based on the presentation. This is Part 2 of a rough transcription of the webinar (note — I have moved several slides around as I have created this essay).

Read Part 1       Read Part 3

Whether we are considering goals for groups of testers or teams that include testers, there is a natural tendency to set goals that are specific to a process. Examples of areas covered by specific process level goals include code coverage, test case automation, or (god forbid) the number of defects found or defect removal efficiency. While two of the four might be valuable focus areas, none of the examples are based on systems thinking view of the output delivered from a value chain therefore rarely impact the bottom line significantly. Other than a few specific scenarios, testing, is not the output of a value chain. In a software development organization, software products that people spent money on are an output. In an automobile manufacturer, cars are the output. Every team needs to have goals based on their contribution to the value stream. Four basic metric categories that need to be considered are:

 

How To Set Smart(ish) Goals For Testers Part 1

Read Part 2      Read Part 3

Earlier this week I appeared as part of the QA Touch Virtual Series.  I spoke on the topic of goals and setting goals. I used the presentation to bring together a number of ideas of goals and goal setting, and this essay, in turn, is based on the presentation.

We set goals to establish a vision of tomorrow and to provide motivation and feedback for following a path towards those visions. We use goals to decide what knowledge and capabilities we need to acquire and how to line up our resources to reach toward the future.  Goals can be a powerful tool.  As with all powerful tools they can be misused or overused. 

 

Avoid Impossible and Unvoiced Expectations

Unless you ask, you’re not going to get what you want.

In the long run, goals must be based on our expectations. The Merriam-Webster Online Dictionary defines expectation as “a belief that something will happen or is likely to happen.”  They provide the motivation to begin a new project or to plan for the future. The belief that something good will happen can provide a significant amount of energy to propel toward our goals. When we discover that our expectations are impossible they stop being motivators. I realized many years ago that the possibility of winning the lottery is not a motivator to me, I understand statistics and therefore I don’t play. For me, saying that I expect to win the lottery has no motivational power because I have no expectation of winning.  If I were to set a goal of winning the lottery with no real expectation of achieving that goal I would be setting myself up for disappointment. Another example of the impact of the mismatch between goals and expectations can be seen in poorly set project estimates.  Occasionally (I am being kind), I see PMOs or managers set an estimate for a project team without input or participation.  Usually the estimate is wrong, and wrong low.  There are many physiological reasons for setting a low estimate, ranging from creating an anchor bias to providing the team a stretch goal. In most cases, no one on the team is fooled (at least more than once), therefore no one is motivated.

Second criteria for maximizing to potential for meeting expectations is to voice the expectations.  My wife occasionally berates me about letting unvoiced expectations get in the way of a good time. These expectations usually have to do with the dining while out and about. Expectations that are unvoiced, and therefore potentially unmet, can cause anger and resentment. We can’t simply assume that the picture we have in our head about the future will just happen.  A number of times over my career as a manager, employees have come to me to let me know that they had wanted to be assigned to a specific project after someone else had volunteered.   In most cases these employees had formed an expectation about their role and the project but had never voiced that expectation.  Because the expectation was unvoiced it had far less chance of being met.

We need to make sure our expectations of the future are possible.  Expectations that are goals are important motivators but only if they our our expectations therefore those we believe they will happen. Voicing our expectations is also an important step towards realizing those expectations.  Like the raise you want but have not taken the opportunity to ask for.  An unvoiced expectation is less apt to evoke feedback, for example, if you asked for a raise that did not match your performance  as a child you may well have been told no.  But, unless you ask and make your case, you may never get that raise.  Set your goals and expectations, share them and listen to the feedback.  Avoiding impossible and unvoiced expectations will  educe the potential for disappointment and resentment.

 

Measuring Test-Driven Development

Measuring TDD is a lot like measuring a cyclone!

Teams and organizations adopt test-driven development for many reasons, including improving software design, functional quality, time to market or because everyone is doing it (well maybe not that last reason…yet).  In order to justify the investment in time, effort and even the cash for consultants and coaches, most organizations want some form of proof that there is some return on investment (ROI) from leveraging TDD. The measurement issue is less that something needs to be measured (I am ignoring the “you can’t measure software development crowd”), but rather what constitutes an impact and therefore what really should be measured. Erik van Veenendaal, an internationally recognized testing expert stated in an interview that will be published on SPaMCAST 406, “unless you spend the time to link your measurement or change program to business needs, they will be short-lived.”  Just adopting someone else’s best practices in measurement tends to be counterproductive because every organization has different goals and needs.  This means they will adopt TDD for different reasons and will need different evidence to assure themselves that they are getting a benefit.  There is NO single measure or metric that proves you are getting the benefit you need from TDD.  That is not to say that TDD can’t or should not be measured.  A pallet of measures that are commonly used based on the generic goal they address are:

 

Scaling Agile: Goal Coordination More Than Planning

When the goal is complicated architecture, everyone needs to coordinate.

Much of the work to coordinate and synchronize goals happens during planning.  As Mike Cohn described with the metaphor of the Agile planning onion, Agile planning is not a one-time event nor are planning activities confined to the beginning of an increment or a sprint. However, delivering work using Agile is not just a big ball of planning. Goal coordination and synchronization activities need to happen outside of planning activities.  Several non-planning Agile techniques are useful for ensuring coordination.  The degree of usefulness is a function of size, complexity and the Agile maturity of those involved. The techniques include:

Test First Development (TFD) in all of its forms (including Test Driven Development, Behavior Driven Development, and Acceptance Test Driven Development) begins by establishing how the developers will prove the work they are planning to deliver.  Expressing how the solution will be proved before writing the first line of code anchors the functionality being delivered to the effort’s goals. All of the test first development techniques can be applied to any size project; however, these techniques require teams that have access to the correct tools and have at least a moderate Agile maturity.   

Definition of Done provides a team or teams with a set of criteria that they can use to plan and bound their work based on an overarching definition of done. A definition of done that includes integration activities or a check against the increment’s goal is an effective means of keeping goals synchronized. The definition of done is applicable to all efforts regardless of size, albeit as complexity increases this technique becomes even more powerful.

Continuous Builds is a process in which every time code is checked back into the code repository the application or product is built (or compiled).  The build is immediately followed by some form of testing to make sure the “build” still works.  Continuously building the software ensures that any one team or developer does not go too far off track because the code and testing act as an arbiter that the product works. This technique is applicable to all efforts (Agile or not, big or small); however, I have noticed that the use of continuous builds requires some experience and maturity with Agile.

Scrum of Scrums (SOS) is a mechanism that brings all of the Scrum Masters involved in an effort together to coordinate a group of teams so that they act as a team of teams. The SOS provides a platform for coordinating and synchronizing goals by ensuring teams are aware of what other teams are doing and whether they have had to make adjustments to the goals.  An SOS is useful for coordinating efforts of all size; however, as efforts scale past two or three teams other coordination techniques are needed in addition to the SOS. 

Demonstrations, also known as demos, are Agile’s mechanism to share what the team has been accomplished.  Scaled Agile efforts often have demos at the team level at the end of every sprint, an integrated demo (all teams) and then a larger demo before a release.  Demonstrations provide the ultimate proof of what has been built allowing stakeholders to determine whether the effort’s goals have been met. Demos are useful for every Agile effort.  Larger efforts will do demos both at the team level and then as a consolidated demo for the overall product.

Dynamic Testing (execution of the code), by definition, generates results that are compared against some expected result (even exploratory testing).  Those expected results represent an instantiation of the goals and objectives of the overall effort.  Testing, while important, without the structure of test-first development is a very weak tool for coordinating and synchronizing goals. Do not use this technique alone regardless of the size of the effort. 

Techniques for synchronizing special types of goals and objectives such as process improvement or technical goals are: 

Retrospectives are a platform for teams and teams of teams to examine their performance and to make changes to improve their delivery of value.  When an effort or organization has productivity, quality, and/or efficiency goals, retrospectives (using techniques such as the 6 Thinking Hats) are highly effective.  The retrospective provides a platform to share the objectives and then to synchronize on the steps needed to meet those goals and objectives.

Common Architectures and Standards are typically an instantiation of the technical goals and objectives of the organization. Efforts of all size can use a set of standards or a published architecture to effectively coordinate activity.  Examples of using an emergent architecture to provide guidance can be seen in the SAFe concept of the architectural runway.  The runway is “built” just ahead of the need of the teams generating the functionality that will leverage that architecture.

The effectively coordinating and synchronizing goals is a requirement for any effort, if the effort is going to deliver value efficiently. Agile efforts often use many of these techniques in combination.  Each technique interlocks and overlaps with other techniques so that an environment is created that supports team’s ability to self-organize and self-manage.   The number techniques and how strenuously they need to be pursued is a function of how many teams are involved, Agile maturity and complexity.  Conceptually an effort with two collocated teams and simple business problem to solve will need less goal coordination than an effort with many teams that are spread across the globe. The one absolute when it comes to goals and teams is coordination is always required.

 

Scaling Agile: Goal Coordination Begins With Planning

Where are we going?

As we noted earlier in this theme, coordinating and synchronizing goals across multiple teams is not a new problem. Solving the problem at scale requires integrating specific steps into how work is being delivered.  Building coordination and synchronizing steps work best if they are part of activities that are naturally designed to consolidate and disseminate information, while also avoiding the construction-related steps. Identifying the steps to coordinate and synchronize goals is a first step in scaling Agile.  The size and complexity of the effort will contribute to the selection process.  For example, delivering functionality from two collocated teams will need less overt goal coordination than an effort with twenty teams spread across the globe.  Because adding coordination and synchronization steps into the workflow may feel like overhead to individual teams, care should be taken. However, well-executed coordination will provide a significant payback both for the team and to the overall effort. The Agile planning mechanisms that are excellent tools for coordinating and synchronizing goals include:

 

Scaling Agile: Coordinating Goals

Coordinate to achieve your shared goals.

Effectively scaling any methodology is a problem of establishing, coordinating and controlling the goals of each team that is working together to deliver a project or product. Clearly scaling any type of work is not straightforward.  At the very least, every new person and team increases the number of possible communication channels. The formula, n (n – 1) /2, is non-linear; a project with 2 teams has one channel while a project with 10 teams has 45.  Many Agile techniques were developed (or, at least, evolved) as team level, and don’t address goal coordination.  Scaling Agile requires taking a different tack than just adopting classic plan-driven methods and frameworks and putting them on top of team-level Agile. 

 

Agile Practices at Scale: The Real Issue

Greater scale, more problems?

In 2016, scaling Agile is a contentious topic.  Frameworks and techniques for scaling are often lambasted as semi-Agile or perhaps even backdoor waterfall techniques. Occasionally you still hear that if a piece of work is too big for one team to complete in a reasonable period of time, it should be broken down or just not done. Rather than throw the baby out with the bathwater, many organizations have taken a more pragmatic approach and adopted techniques to scale Agile. These techniques reflect the differences between a single-team Agile project and a scaled project.  Careful observation can trace most of these perceptions back to a single difference.

 

Setting Goals: A Simple Checklist

Your goals can be your roadmap.

We set goals to help channel our energy and filter out the less relevant demands on our time and attention.  Goals should reflect what is important to you now and be sticky enough help keep you on track when things get tough. However, context and circumstances do change, and when they do, goals can change.  For example, one of my neighbors had set a goal of canoeing in the Canadian wilderness in all four seasons in 2015. The goal had to be replaced when his wife was diagnosed with cancer. He replaced the original goal with a new more pertinent goal. Given the importance of goals to direct our behavior, allocate our effort and to defend our attention, a simple checklist might be useful when creating resolutions or setting annual goals.