5 Patterns for agile leadership (Summary)

Being an agile leader is a difficult task: Your job is not to tell others what to do, but to enable them to do the right thing. But that may be very hard, based on management practices you might have learned over the years. Failure to provide a proper environment for your workers will most likely make you completely un-attractive as an agile leader. 

In this simple guide, we provide you with an overview over 5 patterns that you should heed in order to become a better agile leader.

Will people avoid you or flock to you?

Here are the patterns:

1. Grow, don't exploit
2. Clarify goals, don't confuse
3. Support, don't impede
4. Focus on outcomes, not status
5. Capture hearts, don't break them

By following these five simple patterns, you can become a valuable, positive manager in an agile organization.

Guide: Agile Leadership (5) - Capture hearts, don't break them

The fifth and concluding part in this agile leadership series is the question: "What can I do to engage my employees?" The answer is simple: Treat them like human beings. Here are five anti-patterns for managing in an agile environment, including ways to improve your behaviour.

Will you break or warm a heart today?

A prophet in his own land

Managers are often tempted to listen to big ideas coming from reputable consultants, industry thought leaders - or, in general, specialized trainers for certain topics. On the other hand, they completely ignore the knowledge and expertise that already exists in their own company. A very sad, yet recurring theme in many corporations is that consultants simply ask employees "What would you do?", then sell these ideas with their consulting brand logo at a hefty markup. Management applauds these ideas and wonders why nobody ever thought of that before. Those who came up with the original idea are then commanded to implement it without any reward. Yet another, similar recurring theme is to send people to expensive, pre-concocted trainings where they learn little or nothing of relevance, all the while ignoring all the valuable knowledge and expertise these people possess.

When you hired people, you probably did that because they were good. Rather than treat them as inventory, find out what else they can do and how else they can contribute. Harness the creative potential of your existing workforce.

Putting people down

There is no better way of making employees leave than to put them down. It does not matter if this happened publicly or privately, intentionally or unintentionally - the effect is equally devastating. A single inconsiderate statement, such as "You know, you really need to start learning from others." can do an inconceivable amount of damage to a relationship. You may be unaware of where a person's threshold is, but once they feel that you do not trust them or they can not trust you, they have no choice other than leave your company, regardless of how valuable their contribution may be and how much they like the work.

A word, once spoken, is impossible to re-capture. You have no right to judge others on partial information, much less do you have the right to put them down. Learn to be cautious of what you say- Remember that business objectives can only be attained in an environment of trust.

Exploiting feelings

People are not machines, and they have feelings, too. It may be tempting to utilize people's feelings to achieve specific goals. For example, you can play on a developer's pride in their workmanship to get them to do overtime, maybe to exhaust themselves to the point of burn-out. However, none of that is sustainable and all of it will usually result in broken trust.
While you should not treat your employees like machines, you should never use their feelings against them in any form or fashion.

As an agile leader, you need to be aware of the emotions of those around you and understand the impact of their emotions on their work. An important part of your work is to cherish those with negative feelings and build collaboration on positive feelings.

Unfair Comparisons

People are different. Everyone has a different background. Probably the worst thing you can do to someone's morale is hold something against them that they had no control over. For example, "Why do you think Tim is a better Scrum Master than me?" - "Because we sent Tim to a Certified Scrum Master course, and you don't have that certificate." - well. By comparing based on what opportunities people had rather than on what they did from there, you end up completely discrediting whatever effort someone has put into their career. By holding people's opportunities they never had against them, they will be very reluctant to take any second-class opportunities.

Base your esteem of a person based on what opportunities they had and what they made out of that.

Partiality

Probably the most effective way to destroy morale is by playing favorites and showing obvious bias. There is a proverb, "Proximity creates trust", and it is easy to show preference to those who are closer to you than others. By basing business decisions on proximity, you encourage lobbying and partiality. Actually getting work done becomes irrelevant: Your company structure will turn sour, and once you reap these behaviours, it will be very difficult to revert.

As an agile leader, never decide when you have only heard one side of the story, even if it was related by your closest and dearest coworkers. Spend time to find out both sides of the story and be slow in judgment. Never let any partiality or bias show.

Summary

What sounds trivial can be very hard in practice: People have feelings. In a human workplace, you better take heed of that. Mending broken trust is impossible, cheering up a person who has been discouraged takes a lot of time.
Now is a good time to stop all the behaviours that can devastate a person's feelings, and start thinking of ways to cherish those around you.

Guide: Agile Leadership (4) - Support, don't impede

The fourth part in this agile leadership series is the question: "What can I do to increase the effectiveness in my company?" The answer is simple: Clear the way. Here are five anti-patterns for managing in an agile environment, including ways to improve your behaviour.

Controls and Reports

Probably every form of control and report existing in your company has only one objective: Cover someone's behind in case something goes wrong. None of them has the purpose of actually advancing whatever strategy you are pursuing. Likewise, asking people to give you explicit status updates only covers your own ignorance regarding what is going on: What will you do with this information? Will you use that to benefit those doing the work?

There is a better way than reporting: Gemba, a fundamental Lean technique. Without soliciting information that forces people to interrupt their work, start looking around what people are actually doing and asking appropriate questions to learn what is going on.

Demands

It's very tempting to ask people to do something that helps whatever goal you currently have in mind, but - as mentioned previously - this disrupts whatever else they are doing. Plus, you need to think of the consequences that the work you are just generating has on the primary objective of your organization. Most of the things that come to your mind are just that: Work, or Non-value adding activity. For example, you want a weekly coordination meeting for your division: These meetings are dreaded by all except those who call for them. You're not helping anyone, much less your organization's profitability by demanding others to do things. There is pretty much nothing a manager can ask from a self-organized team which actually benefits the company.

Get the question "Who can do this..." out of your head. To have any purpose for your existence as a manager in an agile organization, your primary question should be: "How can I help you". However, be aware that you may lack information on the consequences of your actions, so be cautious where you tread.

Fixed Structure

You have proably spent a lot of time setting up the structure in your sphere of control to optimize whatever goals were important in the past. Unfortunately, there is no guarantee that this structure is still consistent with being agile, i.e. the ability to act easily, fast and cheap on changing circumstances. This might include old hierarchies as well as corresponding roles, meetings and reporting chains. Treating any of these as sacred will result in sub-optimization. Scrum does not consider a "manager" role, and this is no accident. Management structure is not necessary to succeed, although managers always find reasons why their role should exist.

Rather than justifying their existence, try finding reasons why your role and structures under your control should not exist, then work towards making this happen. As a manager, you are most valuable when you tear down any kind of structure which blocks those who actually do productive work.

No-Go areas

The worst kind of impediment a team can face is a no-go area, a red line that can't be crossed even when it's essential to succeed. For example, a no-go area could be BYOD: What is the reason for a no-byod policy? Typically, no-gos are driven by fear, sometimes irrational, sometimes based on anecdotal evidence. But how can you succeed as long as fear of negative things drives your thoughts?

As a manager, you should identify the no-go areas in your company and remove the "Stop" signs, so that people can do what actually makes sense. Lead by example, show courage instead of cowering to suppressing fear.

Prescriptive solutions

Some old-school managers still cling to the concept that somehow, they are smarter, more knowledgable or more intelligent than their subordinates. While that may have been a merited concept a hundred years ago, it most certainly is not a useful premise in the age of creative work. If anything, managers might have focused their education on a different domain than others. Domain specific work that can't be done automated in the 21st century tends to be so intricate that managers who are not actively doing it can barely comprehend it. How would you prescribe an appropriate approach that you can't grasp?

When you feel things are moving in a wrong direction, do not fall for the temptation of prescribing a remedy. Much rather, spend time on educating your staff what the problems are, help them gain a deeper understanding regarding potential approaches - and let them work out their own solutions.

Summary

Probably the hardest part in agile management is accepting that you either are superfluous - or you are doing something wrong. Nothing you can do "down the line" will benefit your company.
But what you can do is go "to the side" (into other organizational areas) and "up the line" (higher in the hierarchy) to resolve impediments.

Guide: Agile Leadership (3) - Clarify goals, don't confuse

The second part in this agile leadership series is the question: "How can I direct my employees in the right direction?" A seemingly easy question that is difficult to answer: First, find out what the right direction is. Here are five anti-patterns for managing in an agile environment, including ways to improve your behaviour.

Where are you headed?

Unclear direction

Let's face it, when your direction is not clear, how can you expect anyone to follow you and be clear about where they are headed? The easiest way to find out which direction people are heading is by asking around. Grab ten people at random, invite each individually to a coffee and ask them what the direction of the company is - and how they are contributing to the effort. The answers may be sobering. Are you aware of potential conflicts between different goals that you did set? How do you expect others to resolve a conflict you have generated?

Articulate the one, singular course you are setting in one sentence. Avoid long sentences, avoid "and" / "or" clauses - and use simple terms. Ask yourself "Does that make sense?", then get feedback from others. If they need to interpret or misunderstand you, rework. After you came up with a powerful, yet simple statement, use every opportunity to communicate it. Do others quote you correctly?

Conflicting priorities

Goals can conflict on many levels. Even company goals can clash or contradict one another. For example, you might set the goals of "being the most agile company in the region" and, at the same time, "growing the business by selling new services". Sounds simple enough. But: What do you prefer? People working on becoming more agile, or people working on introducing new services? You can say "Both", but: where is the priority?
Managers easily fall into the trap of simply adding new objectives, without clarifying how they fit into existing priorities: Do they override, abolish or subject to existing objectives?

Keep the list of objectives short, as with each additional item, you are adding confusion.
As long as you are simultaneously pursuing more than one goal, be very clear which is more important. Whenever you are setting new goals, take your time to clarify what this means to existing objectives. Do not hestitate to openly abolish existing goals, to help your employees be clear that they are no longer valid.

Systemic inconsistency

The goals you set are actually irrelevant as long as your organization makes it impossible to each these. For example, you can not set the goal of "becoming an agile company", while keeping existing roles, silos and escalation policies in place.

Before setting a goal, spend time to understand which forces in your system contribute and/or distract from this goal. Actively work on resolving issues which distract from or oppose the goal you have set.

Perverse incentives

Sometimes, you want to achieve a certain goal, yet there are (dis-)incentives within your system that make it unattractive to reach that goal, leading people inherently to pursue different goals. For example, you might set a goal to "let everyone work in Scrum teams", and then forcing people in Scrum teams to abandon their chosen area of focus and expertise, nurturing resistance rather than support for the agile transition. Another example of perverse incentives might include providing new responsibilities to grow people, without rewarding the obtained results: you're actually encouraging people to find a better job elsewhere - or resist personal growth!

When you have a goal, spend time to think "What could happen when people do this?" Put on different thinking hats and think of potential consequences. Keep in mind that you are working in a complex system, and the more complex your organization is, the more likely you are forgetting some important constraint!

Whimsical input

When you just need something done, it's very tempting to find someone who can help you with that and set them right on the task, especially if it's just a small thing. This does affect both the autonomy of whoever you are talking to as well as their otherwise determined objectives. Are you aware of what your simple demand does to the overall company strategy?
Here is one example: Jim is your expert on explorative testing, so you want Jim to hold a workshop for all interested employees: It's just two hours. But: Plus preparation time, Jim may not be contributing to the team's primary objective for a full day. Did you consider whether exploratory testing is even needed - or appreciated - by the others? You are quickly opening a can of worms with every single, simple request.

Scrum is very clear that nobody, NOBODY except the Product Owner gives work to the teams - and even then, only in rare, special circumstances can that be done outside pre-determined planning intervals. Get used to the idea that any form of assignment, even voluntary, is not your job.

Summary

Objectives management is a tough topic. The more complex a company, the more difficult it is to understand the consequences of your action. Your first move should be to simplify, clarify and reduce the complexity of existing objectives. Then, become more cautious when introducing new objectives and consider the overall systemic impact of setting any objective.

Guide: Agile Leadership (2) - Focus on outcomes, not status

The second part in this agile leadership series is the question: "How can I make my employees more productive?" The answer is simple: Don't. Here are five anti-patterns for managing in an agile environment, including ways to improve your behaviour.

Which effect do you prefer?

Ignoring visible outcomes

Probably the most effective way to demotivate employees is by ignoring the outcomes both of their work and yours, trivializing their achievements and demonstrating by example what you consider acceptable. You must acknowledge both the positive and negative results of any action. When your employees do things, that should be acknowledged. Flatly skipping over achievements will make them feed under-appreciated. Likewise, glossing over already existing detrimental effects of mismanagement will make them lose hope in your organization.
Highlight the positive effects of a person's work and they will do more of that.
Acknowledge mistakes you have made and open the road to continuous improvement.

Lack of foresight

Managers are expected to understand the consequences of their actions. However, people are not simple, and organizations of people are highly complex. What seems straightforward is oftentimes not. 

For example, by introducing a no-telecommuting policy, you might subliminally convey the idea that presence is more valuable than results, reducing their performance to zero. 

Stop creating rules and setting directions. Start telling people which goals you have in mind. Let them figure out the best way to reach these goals and provide some leeway for inspect+adapt learning.

Forgetting intangible outcomes

You may be using a whole lot of metrics to determine how well your company is doing. However, the overall outcome of any direction you have set is often the result of things you can hardly quantify. There are two kinds of intangible outcomes which you might be unaware of. 

The first is delayed outcome, i.e. things that will not be manifest until a later date. For example, a serious interference with peoples' work will likely result in something being "shoved under the rug".

The second kind is subjective outcome, such as personal satisfaction. Breaking people's autonomy and strive for mastery may be effective to achieve a short term business goal, but will ultimately leave your workforce dissatisfied. 

In knowledge work, you can't plan for a single outcome. Stop managing top-down, rather work upwards to provide an organizational structure. The only way that you do not need to worry about the outcome of your decisions in the downward direction is by getting out of people's way.

Forgetting morale as outcome

Morale is a very difficult, yet important factor to manage. Just take some time to figure out what affects a person's morale positively or negatively, short-term and long term. 

As a teaser, try answering the question: "Can you actually afford to assign a task to someone?" and use the following modeling variables: 1- morale, 2 - clarity of task, 3 - desirability of result to you, 4 - desirability of result to them, 5 - difficulty, 6 - effort, 7 - unexpressed attitude, 8 - amount of feedback in the process, 9 - amount of feedback on result, 10 - perceived autonomy,  

You will discover that morale is the result of highly complex interactions between many factors and impossible to control. 

Morale directly correlates to sustainaibility, yet you have no way of controlling it. The best you can do is to remove demotivating factors in your organization and stop your own demotivating behaviours and foster anything your employees feel that have a positive impact on their morale.

Watching activity

Agile work is the work of solving unsolved problems. This is creative work. It seems very tempting to draw a line between how busy people are and how much progress they make. But beware: There is no such correlation. If anything, it is a negative relationship: Busy people don't have time to solve problems. A very simple way to prevent your teams from doing really meaningful work is by watching how busy they are and having them report status.  

Stop finding new ways to make your workers busy and fill their slack time. To manage in an agile way, you need to look out for things that make people busy and try to eliminate anything that causes bustling. Create slack so that people get their heads free to solve problems.

Summary

Productivity is a detrimential metric for system optimization: when people feel they are being rewarded for being productive, you will have a very busy organization. But you will stop making meaningful progress.

Stop focusing on productivity and start focusing on the outcomes you want to achieve. Free your workers to reach these outcomes.

Guide: Agile Leadership (1) - Grow, don't exploit

The first part in this agile leadership series is the question: "How do I get the most out of my employees?" The answer is simple: Grow them. Here are five anti-patterns for managing in an agile environment, including ways to improve your behaviour.

Do you grow those who work for you?

Focus on existing capability

A tester is a tester and will always be a tester? No! People were not born tester and probably did not get a degree in testing. Someone made them be a tester.
Like they learned testing in the past, they can learn new things today and tomorrow. Of course, "tester" is just a placeholder for any kind of role you have in mind for a person.
Find out which challenges your staff would like to tackle and then provide the opportunity!

Expecting sacrifice

Your organization has goals, and you want motivate people to reach these goals together with you. You can't rely on people to always have the same goals like your company does. When people set back their own personal goals in order to advance your goals, there better be something in it for them. In cases where you can't naturally align them, at least make sure that there is a sound relationship between your company goals, employees accomplishing them - and rewards for personal sacrifice!

Taking mastery for granted

People like to master skills, but they still want to get something out of that. You can't expect a developer to become an expert in lots of engineering practices and still work for junior level pay. In a world where the War for Talent is fully engaged, you want to make sure that people don't have to worry about paying their rent, otherwise they will leave. When people develop new skills, especially when they master an extremely rare talent, keep the pay up to date.

Taking undue advantage

Just because people have mastered a skill does not mean they lose the autonomy to do what they like. For example, just because your quality expert has mastered TDD does not mean that they want to abandon whatever they are doing and become a professional TDD trainer. This one will backfire most sorely when you exploit people's abilities without considering the impact on the purpose of their work.
When people achieve mastery in an area, make sure they feel it is appreciated and valuable, not a drag or pressure.

Being generous at their expense

When you think that employees have signed a contract which legally forces them to invest their life for the company, think again. In the era of Knowledge Work and Talent Shortage, it's the other way around: You have managed to acquire a desparately needed talent to voluntarily dedicate a portion of their time to your company, and you better use that opportunity well! Expecting your employees to invest overtime, inconvenient commutes or even their hard earned money for your purposes is thebest way to sustainably repel talent,
Honour your employees' voluntary commitment to your company. Find the best possible ways that they feel their resources are well invested. Never make unreasonable demands. When people go beyond contractual limits, always make sure that it's appreciated.

Summary

Exploiting your employees will negatively impact these three dimensions, reducing the effectiveness of your company and ultimately resulting in disgruntled employees who will have no alternative to leaving.
Growing your employees will positively affect all of the dimensions Autonomy, Mastery and Purpose, resulting in highly motivated employees who will do their best to advance your business.

Guide: Approaching test coverage for Legacy Code

A standard question in teams just transitioning to agile software development is: "How can we be agile when our Legacy product has (close to) 0 Test Coverage? Doesn't it take years to reach decent test coverage?"
In a previous article, we covered the Testing pyramid: We will base our approach on this model.

The test pyramid

One basic assumption: The system works

Without automated tests, legacy systems are often bug-ridden, so developers are in a vicious circle of "We can't write tests without knowing where the defects are, and we can't fix the defects without tests". We simply break this loop by assuming that the system, as it is currently being delivered to customers, works. Then, we build tests based on how the system currently works. As we discover "That's not what it should be doing", we are still free to add the intended behaviour into the Product Backlog. Creating automated tests can start without further delay when we simply produce tests for the system we already have.

Start by introducing some E2E Tests

Depending on testing knowledge and available tools, starting with E2E Process tests is always an option - Selenium IDE covers you for all web applications. 

Approach: Grab your favorite testing tool and start making automated tests.

Advantages: E2E process tests can cover a huge portion of the application with very few test cases in a very short time. For example, the E2E process chain of an entire e-commerce site may be roughly covered by half a dozen E2E tests.

Disadvantages: E2E process tests require a massively complex setup. They are often flaky and hard to maintain. 

It is desirable to invest effort to refactor E2E process tests so that their test objective can be reached with less complexity. As more scenarios get covered by component integration tests, the amount of required E2E tests should shrink.

Turning E2E into Component Integration Tests

When new features are realized, the interactions, data models and transitions of a specific test step may change. These changes should be tested on a smaller scope by moving the test to component integration level. 

Approach: 

1. Extract the relevant test (steps) from the test code of an E2E test (or start an entirely new test).
   This may require you to rewrite existing test activities using a different technology. 
2. Create a specific integration test for the sub-scenario.
3. Refactor your product source code in whatever ways necessary to make the integration test executable.
   This may require major refactoring, and even the introduction of new mockable interfaces into the productive system.

Advantages: Integration tests pinpoint problematic areas much better than E2E tests. It is significantly easier and faster to add additional test coverage or modify tests when the system changes.

Disadvantages: Integration tests are still fairly slow and difficult to set up and debug. They are oftentimes still unnecessarily complex. 

Therefore, it is desirable to refactor integration tests so that the risks are already mitigated on Component level.

Turning Integration into Component Tests

When the underlying logic of in one area of the product is changing, it should be tested on the smallest possible scope by moving the test all the way down to component level. 

Approach:

1. Extract the relevant test steps from the test code of an Integration test (or start an entirely new test).
   If you didn't do this already, you will now need to rewrite the test activities in the language of the source code.
2. Create a specific unit test for each specific logic element you are working on.
   Mind the pre- and post-conditions of your tests!
3. Refactor your product source code in whatever ways necessary to make the unit test pass.
   This may require major refactoring.

Advantages: Component tests are extremely fast to execute, extremely accurate in exposing defects and easy to maintain.

Disadvantages: Component tests may require significant re-engineering on Legacy code. They are not intended to uncover problems occurring exclusively when components interact.

Summary

With this approach, you can cover a broad spectrum of your application in a very short time in order to increase agility when working with Legacy code. 

E2E process coverage removes major risks from development quickly, but developers will have major headaches with flaky tests. 

Moving test activity to an integration level becomes a parallel activity to the development of new features. Your tests will become faster and more stable, but you may require significant changes to the existing architecture in doing so.

Unit tests will over time become the most reliable and fastest way to assure product quality and maximize developer feedback Their fine granularity means that, you will need a lot of tests to cover the product well. This takes time.

What does the Test Pyramid mean?

Have you seen the "Test Pyramid" yet? There are dozens of versions going around in the Internet, most look somewhat like these two:

Common test pyramids seen on the Internet and in Testing Literature

Have you ever wondered what these pyramids actially represent? What are the underlying assumptions of these models?

What they all have in common is that they start with "unit test" at the bottom.

The first question we need to answer is: "What is a unit test?" Unit test specifically implies testing a component in isolation. This is often understood as "The tests that developers do [on their machines]." Where this concept exists in the back of people's heads, the test pyramid represents -from bottom to top- a separation of concerns and the breadth of the pyramid connotates distance from real customers. Is that the intention?

Let us dig into the left model.

UI-Acceptance-Unit Pyramid

There are three basic assumptions in this model:

1. UI testing and Acceptance testing are two different things
2. Acceptance Testing does something other than unit testing
3. The UI does not get unit tested.

Think about it for a minute. 

What are "UI tests" that have nothing to do with product acceptance? What do unit tests actually do if they do not verify acceptance criteria of the product/ feature/ requirement? Why is the UI, if it's not a unit (= component) of the product? Why would you not unit test one of your units?

A proper understanding of unit testing and the application of modern UI testing frameworks reveals the inconsistencies in this model. 

UI-Service-Unit Pyramid

This model makes similar assumptions:

1. The UI tests are not part of service tests (i.e. the UI does not belong to the service)
2. Service Testing does something other than unit testing.
3. The UI does not get unit tested.

Take your time to reflect on these assumptions.

Where is the UI, when it's not part of a service? What happens during "service testing"? Why do we need "service tests" after we have proper unit coverage? 

This model can be made consistent by clarifying some of the underlying assumptions:

1. "UI" tests actually mean "user testing", where real people use the real product.
2. "Service" tests actually mean "integration testing", or unit interaction testing.

With these clarifications, the model correlates to maturity of the product, and therefore, to the timeline on which tests are made (up = late, bottom = early). It also makes sense to assume that most tests should be made early. 

This model presumes an undesirable structure: The assumption that these activities are indeed separate and impossible to merge or refactor. Therefore, we get stuck with the process in it's current state. Organizational redesign for optimizing the pyramid is pre-empted by the underlying assumptions.

A different Test Pyramid

This model also has underlying assumptions, but they are completely different from the previous models:

1. On an E2E level, the object under test would be the entire product as set up to run in a production-like environment.
   However, that is expensive and difficult to implement and slow to execute. When defects are found, they could have been caused anywhere, anytime in the system, making debugging difficult and tedious.
2. On integration level, the object under test is narrowed down significantly.
   Integration tests are significantly cheaper and easier to implement and faster to execute than E2E. When defects are found, they can be much easier to locate.
3. On component level, the object under test is reduced to minimal scope, which is - in a perfect state - just the single method under test.
   Component tests execute in milliseconds and defects coincide with the failing test. Debugging can quickly pinpoint the faulty line of code.

This model proposes that complexity correlates to the depth of the pyramid. It connotes that you can start anywhere, yet it is desirable to reduce testing complexity by refactoring tests down in the stack.

Summary

No model is really wrong, but some are inconsistent. Models serve to facilitate a conversation. In our case, we created the Test Pyramid as a model for the purpose of explaining the relationship between complexity and effort of testing. Our model is intended to foster an understanding of why high component test coverage is desirable and how to discover if your test suite is adequately built.

The Discovery Questions in agile development

For teams just transitioning to agility, the question arises: "How do we test in an agile team? Which test types do we need?"
There is stuff like the Agile Test Quadrants which are often suggested as guidance. On a different level of abstraction, we have the Test Pyramid. You might look for gaps in your existing test approach and try to cover them as well as possible. You will soon discover that this will not really help, as you merely introduce a structure, but don't solve the underlying "Why" questions.
In another article, we discussed what agile testing is all about.

Let us look at a small visualization of what we are actually looking for when we are discussing quality:

The quality discovery questions.
The matrix can be used to guide a Retrospective on quality.

When we have a new idea (or: Product Backlog item), we first need to discover "What do we want to build in order to make this happen?". This is the specification. The quality of the specification determines the quality of the solution. A basic idea of (A)TDD is to consider functional tests and specification to be the same thing.

In the next step, we need to discover "How do we want to build it, so that it works properly?" This is the source code. Code quality affects both the solution quality and the way how to control quality in the process.

After the code has been built and deployed (into a staging environment) there may still be things going on that we never expected. These are side effects. We need to answer the question: "What happens that we didn't think of?" We don't want that to be many things, but it can always happen.

When we deliver Working Software to the customer, we learn: "What do real users do with the product and how do they use it?" This is user feedback. We use this feedback toadapt our current product in order to maximize value, As we learn more about our users and markets, we will need to adjust our priorities, both strategically for the product and in testing.

Uncertainty

During planning, we try to remove as much uncertainty from implementation as possible. The better our tests are in this stage, the lower our risk of building the product wrong. We do not want to guess whether we built it right based on our idea. We want to be certain. Until we can do this, our first priority is to eliminate the risk of building the product wrong.

After building, we need to validate whether our idea made sense. The more accurate our tests are in this stage, the less likely we will deliver an unsatisfactory product. With the final product in hand, there should be no need to check whether we did do things right based on our idea - only whether our assumptions seem solid.

Early feedback

Each of the four quadrants correlates to a phase in development: Planning, building, deployment and operations. A good way to check whether your current testing approach is effective is by asking the question: "Which activities we do are we doing in which phase?"

If, for example, you realize that you are discovering or verifying acceptance criteria after deployment, you have potential for improvement. A good way to approach this improvement is by asking the question: "Which activities can we do earlier in order to remove the need to do them (so) late?"

Conclusion

A solid agile test strategy removes uncertainty as early as possible. 

The best way to start implementing agile testing is not by focusing on a prescribed set, but by asking: "How can we remove as much uncertainty as early as possible?"

Definition of Not Done

The Scrum guide states, "When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means. Although this varies significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the definition of “Done” for the Scrum Team and is used to assess when work is complete on the product Increment".

Typically, new Scrum teams draft up a Definition of Done as an exhaustive check-list of all the activities they do in order to mark an item as "Done". But is that the intention?

What "Done" actually means

The simplest Definition of "Done" is simply: "Done". This means that there is no more work to do. This assumes that the team is truly multi-skilled and can do all the work across the entire Order-to-Cash cycle of their product. For many teams, this is usually not the case. They leave items of work open that they can not do.

Abuse of "Done"

A typical DoD might look like this:

1. Specification
2. Coding
3. Build
4. Unit Testing
5. Deployment to Staging
6. Functional Testing
7. Integration Testing
8. System Testing
9. Exploratory Testing
10. All Tests Passed

Impressive. How busy these developers are! I never knew software development was so much work! (cough)
This Definition of Done gives the PO and/or business stakeholders a sense that the developers are doing a lot of work on even the most miniscule backlog item. 

As the team learns more over the product over time, this list is almost certain to expand. Maybe they will add items such as "Branches merged", "Bugs fixed", "Performance Testing" ...

But let's look at the Agile Principles: Simplicity - the art of maximizing the amount of Work Not Done - is essential!
We are not looking for a list of Work Done. We are not looking for effort justification! We are looking for ways of achieving the same goal with less work! A DoD might actually "lock in" a process which makes it impossible to eliminate unnecessary steps.

Living in a "Done" bubble

Did you realize that this DoD is missing something important? Yes - deployment to Production! And that may be no accident. Chances are that there are a lot of activities that are "out of scope" for the development team. They might lack the skills. There might be organizational constraints. In either case, the developers create an "illusion of Done": More work must be done, and they don't own that work.
The team has no autonomy to deliver real customer value - a clear violation of the 1st Agile Principle, and they might not even see how far away they really are from customer value.
From a business side, this is even more scary: The team produces a "Done" product and has no control over how much cost will still be incurred before there is any Return on Investment.

A DoD hides this problem in plain sight.

Fixing the Problem: DoND

The Definition of Done is not a justification for the business of the team - it is a way of managing expectations within the organization and towards customers. Customers don't care what the team is busy with - they want a Product!

The team can be more honest by turning the DoD upside down and clearly revealing what is not done. 

Rather than defining a DoD, the team should draft up the list of limitations which they can currently not do, turning this into the DoND.

For example, a DoND for the above DoD might look like this:

1. B2B Interface Specification (done by Architecture Group)
2. Configuration (done by Configuration Management Group)
3. B2B Testing (done by offshore Testing Group)
4. Deployment to Production (done by SysOps)
5. Data Migrations (done by SysOps)
6. Customer Feedback (done by Customer Service Group)

This makes it clear what risks are still in the product and how they are currently approached.

Eliminate the DoND

A DoND not only contains risk, cost and value delay, but also organizational complexity. A DoND is a clear list of impediments which Scrum Master and the organization's management must eliminate. A stratetic plan how to empty out the DoND and give the word "Done" it's intended meaning can only be implemented with the support of upper management.

Summary

Do not work to produce a DoD. Much less, implement the DoD as a checklist to work off.
Instead, create a DoND as the list of items the team still needs to gain control over to get things Done.

Take this list seriously and do whatever is necessary to boil it down to nothing. Only then will you have a truly self-organized team, which is yet another principle of agility.
Once this list is empty, your DoD will be very concise: "Done".