Quantify problems before solving them

I was recently asked: "How many automated tests, do you think, we need?". An underlying premise was that I would provide an expert opinion on whether the team had the right amount of tests.
I could only reply: "I don't know. If you have a problem with quality, you might need more. If you have a problem with the maintenance of your tests, maybe you need fewer. However, if there is no problem, you're probably doing the right thing."

This one can be abstracted, away from the specific issue of test automation.

If there is no problem, there is nothing to fix. But how do you know if you have a problem then?

Here is a simple suggestion:  Collect data. Then, decide based on facts.

This is an example of how you can track:
Each time your team encounters an issue and spends time with or because of it, make a mark. Your result might then look like this, depending on which activities you are tracking and how you track:

In your retrospectives, you can simply look at the numbers and ask the following questions:

• Does this make sense?
• If not: What should we do about this?
• Will we gain more insight if we get more data in the next iteration?

Summary

"Data Driven Decision Making" is not rocket science. Collecting data can be simple and easy - and require very little preparation or technology. While you may want to refine your collection process depending on your understanding of the problem, the simplest possible solution will often suffice to rule out wasting time on dealing with corner cases or imaginary issues.

Stakeholder Management 101

In large enterprises, Product Owners often get bombarded with stakeholder requests of all sorts, which they all need to manage. Soon, the poor PO will find themselves juggling requirements rather than advancing the product in the best interest of the companies. Because all of these requirements are important to the person raising them, the PO will quickly become the victim not only of enormous pressure, but also of constant nagging "Why isn't this done yet?"

Here is a simplified request appraisal process for Product Owners to stay ahead of the game:

Evolving Kanban Boards

Regardless of whether your board is electronic or physical, boards have a huge advantage of making workflows visible and making problems transparent without much overhead.

Here is a real world example of a electronic Kanban board. Let us discuss what this board actually means. As a disclaimer: This is not intended to be a pattern of "how your Kanban board should look like", but "how you could work on your Kanban board". Feel free ignore the detailed contents, because they are irrelevant to our cause in this article.

First thing you may notice: the board is a bit more complex than our usual "toDo, In Progress, Done" board.
This board has evolved over time and it is owned by the team. As such, it does not reflect "how the team should be working", but "how the team is actually working".

A little background

This board belongs to a cross-functional feature team, applying a rigorous Test-First Zero-Defects approach which mandates "no code change without test coverage" and "no deployment with known defects".
Consequently, there is no "In Test" or "Fix" column: Devising the right tests (e.g., "analysis") is as much part of software development as fixing any potentially discovered defects.
When the team moves a backlog item into "Done", it is unconditionally ready to go live.

An evolution journey

As the team discovered that the original 3 columns "ToDo, In Progress, Done" do not provide a sufficient level of transparency to understand at a glance what is actually going on and how they could collaborate, additional columns came in.

The first column that came in was the "to Review" column.
With this, a developer indicated that "My code is ready - from my perspective. I need a code review". Along with the Review column came the Working Agreement to always accept a review before starting a new Work Item. This was intended to minimize inventory.

When a work item was technically complete, the Product Owner inspects the delivered software and determines whether a go-live is a good idea. This may be by discussing with real users, with relevant stakeholders or simply by looking at the software on screen. In some cases, the item is so simple that simply trusting the developers to have completed the Acceptance Criteria is enough.
As the responsibility for this decision rests with the Product Owner, developers move tickets to "Resolved" when they have built Working Software ready for a demo.

The Review process became a bit more complicated, because this team is not  fully autonomous - they are part of a large scaled Scrum organization. Occasionally, the input of members from other teams became essential to maintain Collective Code Ownership. Because such reviews from other teams could take a while, the team created an [in] "Review" column.
The Source Code Management System (in their case, Stash) takes care of managing team external Pull Request reviewers and their feedback - but the ticket sticks "In Review" as long as essential feedback is still missing.

An organization problem sometimes made it impossible to merge fully tested, reviewed code: The Red Master.  Nobody is allowed to merge into a Red Master for any reason other than fixing the broken build - so the team introduced an "Pull Request Open" column to indicate work items that are just waiting to be merged into a Green Master.

Due to not only being a large scaled Scrum organization, but also due to B2B dependencies, the team quickly discovered that sometimes, they would be blocked based on external dependencies. They introduced an "On Hold" column to park any work item which they could not feasibly make progress on because they had to wait for an external party to complete their work. Examples for "on hold" would be, for example, an interface adaption in an external 3rd party software.

After introducing Kanban for a long time, the team encountered a new problem: They could pull work as fast as it arrived. However, not every request that was brought forth to the team makes sense. Any feature and/or information requests were parked on the "Backlog", for the Product Owner to inspect. The Working Agreement became that the Product Owner had responsibility to groom and refine stories in the Backlog before developers would pull them.

Had the PO decided the items would actually be an improvement towards the product vision - and met the team's Definition of Ready, the item would be moved to "Selected for Development". The Team's Working Agreement became that the team completely ignored the "Backlog" column, because it could contain worthless, incomprehensible or conflicting requests - or simply those which were misrouted in the organization.

Conclusion

The specific status model of a team's Kanban board must suit this specific team.
This article is not intended to provide a "better model", but to provide an understanding in the though patterns which can lead teams to evolve their board.

It is generally the best approach to start with a simple board. During Kaizen Events, you might then add columns when inevitable. Working with a complex board and not knowing how (or why) to work with it from the beginning is not a good idea.

This article purposefully omits the steps where workflow columns were added and later discarded because they were found un-necessary. That happens - and is actually good, because it means that people care and Continuous Improvement works.

DEEP or SEED backlog?

In Scrum training, we learn that a Product Backlog should be DEEP, i.e., "Detailed Appropriately. Estimated. Emergent. Prioritized."

Consider your backlog as SEED!

However, I personally feel that another acronym might fit better: SEED. As in:

Sorted.
Estimated.
Emergent.
Detailed Appropriately.

That's not really a stretch, because when people say "Prioritized", they explain what we acually do: Not prioritizing, but actually sorting so that there is only one #1 in the list.

The real difference: Mindset

Seeing that SEED and DEEP pose the same requirements towards the backlog, one might argue that there is no difference. The difference would be in the mindset of the Product Owner, not in the Backlog itself.

DEEP: "I need to put deep thought into this, make it really deep." - After doing a detailed planning of the product, we concluded that this is the best way to implement it - which is not what you want from the initial backlog!
 SEED: "It's a seed. Let's see what becomes of it." - the kernel of the seed (Backlog items) have a lot of power and potential, but you can't really predict the future state.

Let us take the example of an acorn. The acorn is a specific type of seed and you can pretty much tell that by growing it, you'll end up with an oak. But you don't know yet whether it will grow at all, whether it will have a split trunk or how much fruit it will yield.

We want a Product Backlog that is brimming full of potential, but we have very little understanding of what we will be seeing in a couple of years.
This makes the Product Owner the gardener of their very own tree (the product), definitely in charge of raising it properly - but not doing everything right now: Let your product grow at a natural pace!

Towards the backlog as a Seed, you can ask the following questions:

• Can something meaningful grow from this?
• Do we have the proper conditions to grow this?
• Given the current state of each item, can we actually grow it?
• Will we end up with a tree or a mutant jungle when this grows?

Summary

Keeping not only the individual letter items of the acronym, but also the acronym SEED as a whole in mind when setting up or working on your backlog will help you focus on getting meaningful items in there, while keeping useless waste out.

Successful Continuous Integration

Continuous Integration is a staple in most organizations these days. Setting up CI is seemingly trivial, given Web instructions and a bit of hardware, any developer can do that in a reasonably short period. However, CI in many organizations is highly dysfunctional, sometimes nobody is aware of the dysfunction - sometimes, it is visible, but the root cause is just out of reach.

Let's take a deeper look at CI:

CI is much more than just a tool!

 Too often, people jump into the solution space too quickly and say "We need a CI tool". That's like saying "We need a car" without even considering where you intend to go: A tool is not a solution unless you define the problem first. For many developers, it's simply a habit, because every good software project these days has CI. But why? Let us start differently.

Process

Let's ignore for a second the seemingly trivial "After a merge, automatically build and run tests, then report failures" aspects of the CI process and dig into the real question "What do we actually expect from our CI process?" - what do you expect from your CI process? That should be, first and foremost, "instant feedback". But: Feedback on what? Based on what feedback you are looking for, you must design your own CI process to give you the most important feedback clearly, quickly and reliably. So, the difficult question becomes "How do we get that?"

Scope

In order to answer the question, "What feedback are we looking for?", we first need to answer the question "What does Integration actually mean?"
Are we trying to integrate:

• pieces of code into a repository? 
• features into a system?
• activities into processes?
• processes into process chains?
• components into a larger system?
• systems into a larger ecosystem?

Depending on what your question is, the feedback you are looking for differs.
Just as an example, let us look at the question "Is our User Account functionality OK?" in comparison to the question "When 10000 users are on our site at the same time, will everyone be served without encountering problems?" - you obviously need a completely different approach to get feedback here.
Before you can answer how you want to get the result, you must define what result you expect and why you need that information.

Test Suite

Once you know what you want and how you want to get it, that obviously just needs to get done. However, it shouldn't just "get done", but it should get done well. Common problems in CI test suites are:

• Poor coverage, i.e. the information "it passed" is not meaningful
• Flakiness, i.e. the information "it failed" is not meaningful
• Interdependence, i.e. the information "27 tests failed" is not meaningful
• Slow tests, i.e. the information "It finished" is no longer meaningful

Associated with these problems are low value of feedback, high maintenance efforts and productive defects - visible in dissatisfied customers and high cost of development.
Frequently asking "Does our test suite solve the problem we have?" is quite important. While adding tests as needed is easy, both weeding out unnecessary tests and refactoring for optimal information value are often tough calls.

Mindset

The biggest problem with CI in many organizations is that they do not realize that CI is neither a tool nor a process - but a way of working supported by these. Developers do not serve the CI tool and their job is not to keep the master green. As long as developers consider CI a burden rather than a help, then no specific implementation will yield the desirable benefit. Much rather, CI helps developers get their job done well and a red master is an indicator that something is wrong.
Good CI will not only fix a Red Master, but trigger Continuous Improvement [also "CI"] when the Master goes Red: "Why did it turn Red? What can we do to avoid that situation in the future?"
Working on a proper CI mindset goes a long way in successfully implementing CI. A key aspect of this mindset is frequently asking "Which problem are we actually trying to solve with CI? Do we do that?"

Tool

A fool with a tool is still a fool: The tool must be adequate to solve the problem at hand and set up properly to deliver the intended benefit.
Initially, CI tools are empty shells that trigger build jobs and report Pass or Fail. Configuring a source code repo and defining the test suite to execute is done quickly. But you may want to set up individual build chains for different problems, depending on what you are trying to achive. What these chains do, how they interact and what you do with the resulting information is something the tool can not help you with.

Summary

CI supports good software development, but it is not a mandatory component of software development. If your current CI is limited to having an automated build and test job but you've never considered the big picture, chances are you are doing Cargo Cult CI - lots of work for little value. When you see symptoms like developers ignoring Red Master or not even waiting for the CI to complete, you should definitely take a break and do a Retro with the topic: "Let's talk about CI."

How SOLID is your code?

Recently, I heard a statement: “We hired a consultancy to make a code review for our team and they said our code has a lot of technical debt, because it is not SOLID.”

The SOLID principles (Single Purpose, Open-Closed, Liskov Substitution, Interface Segregation, Dependency Inversion) are five basic principles of Software Engineering. However, there is a reason why they are “principles” and not “laws”.

The small picture: Never “Done”

I will assume for a minute that our team has a DoD stating “Code must be SOLID”. Now, we are in a mess. Suppose I write a mere “Hello World” program. My first draft will have a static main printing “Hello World” to the screen. But that's not Single Purpose: Text and screen output are in one method. Let's separate them. Oh wait – I have another problem now, my print method depends on an implementation of my text method – fixed. Let's add an abstraction layer. Oh wait – we have a problem now. I need to extract the interface. … I think you get the idea. Give me any piece of source code and I can both tell you which principles it violates and also which principles will be violated when you “fix” the violations. But: Where is the value in that? Is our goal to make perfect code or to deliver Customer value? You should be “Done” when the product meets its purpose, not when you think it looks perfect.

The medium picture: SOLID != Clean Code

Let us start by clearing out a basic misunderstanding first. Clean Code is code that is easily comprehensible, easily maintainable and easily adjustable. SOLID is a set of principles to keep in mind to reach this objective. But SOLID is not the only thing you must do.

To make code easily comprehensible, you may need code conventions and syntax checkers – and you will definitely need a well written, readable tests.

To make a product easily maintainable, you need Continuous Integration, not just as a tool, but as a mindset. You should be working on a usually Green Master that is sufficiently robust to give developers rapid, useful feedback. This, of course, requires lots of thought put into your test suite – potentially more than you'd put into your productive code.

To make a product easily adjustable, you need to think not only about your source code, but also about architecture and design. This, in turn, means that you must refactor not only on code level, but also on infrastructure level.

The big picture: Agility

Inexperienced agile teams may be tempted to add “Code is SOLID” to their Definition of Done. While it is a good idea to produce clean code, SOLID is not a desirable purpose in itself. First and foremost, why do we strive for Clean Code? 

Behind Clean Code is the 4^th agile value “Responding to Change over following a plan”. At the same time, you have the 1^st Agile Principle: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software” and 10^th Agile principle: “Simplicity – the art of minimizing the amount of work done – is essential!” Clean Code has the objective of making code easily workable, with the goal of creating a flexible product that can be adjusted incrementally without ever slowing down in pace. To reach this objective, we must be able to minimize the effects of change. This requires changes to be elementary and good automated test coverage. And this is where SOLID comes into play: When you need to invest a lot of effort, either into making the change itself or validating that change, your code is not good. SOLID gives you a simple set of rules, not only how to add a change, but how to structure your code so that you can change it later.

Agility neither advocates keeping SOLID principles nor disregarding them. Much rather, SOLID is a tool to minimize overall work done – both now, and in the future. When you know with a high amount of certainty that the amount of work you will invest on a piece of code in the future is lower than the amount of work you would invest into SOLIDifying your code now – then don't. That's not in the spirit of agile software development, because SOLID is not a customer value: Working software is.

Summary

Whenever you make a change to the code, you should make this change in a fashion that will not purposefully reduce the quality of your code, and that means: Future comprehensibility, maintainability and adaptability should not deteriorate below their current stage. When changing code, think about refactoring before you leave.

In refactoring, remember: Minimize the total amount of work done. Do not apply “SOLID” when it's simply a waste of effort. On the other hand, apply SOLID when you know for certain that you will get back to a code segment.

Three things a good Scrum developer brings

It's usually not about how many years you have worked in Software Development, not about how excellent you are in a specific discipline - although it certainly helps, it may occasionally be detrimental. That is the case when a developer's history makes it impossible for them to move forward.

Here are the three things which make a good Scrum developer:

1 - Engineering Practice
Mastery in Engineering Practice is very hard to achieve - but if you don't even have these as basics, everything you produce will most likely cause more problems than it helps: Technical debt is much harder to manage than avoiding.
Getting the basics down on these only takes a couple days - getting the practices on a value adding level takes a fairly long time.
Think, among others, of:
Emergent Design - The art of designing your code so that you are never maneuvered into a corner where you can't meet a reasonable customer request due to technical constraints.
Sustainable Test - Moving from simply writing unit or behaviour tests to the level of testing the right thing, the right way, to get meaningful feedback at minimal cost - while equally avoiding the pitfalls of flaky tests and constant test rework.
Clean Code - Applying SOLID principles "just enough" to end up with easy-to-understand, well-tested, robust code that does not rely on heavy documentation and is easy to work with.
Refactoring - Tweaking the code just at the right time to make it fit for the current purpose without breaking anything.

2 - Lean Thinking
Your horizon must extend far beyond the Software level, Keep Lean's "Optimize the Whole" in your head. You must grow your product, avoid waste, eliminate "work to do", simplify processes, keep customers happy and your organization profitable. At the same time, you don't want to get stressed - and to focus: Quite a feat. Can you properly apply these to your work?
Value - Discriminating "what is asked" from "what is useful".
Value Streams - Discerning the easiest way to get from customer need to customer satisfaction.
Flow - Slicing down the work, avoiding BUFDs and Big Bangs.
Pull - Leaving the tiresome treadmill of featuritis, moving towards sustainable pace without losing business opportunities.
Perfection - Never being content with "good enough", while at the same time avoiding the waste of "gold plating".

3 - Agile mindset
A key pillar of agility is the Inspect and Adapt mechanism. Regardless of how professional you are, you're probably not a prestidigitator. How well do you do in this arena?
We don't know - There are many things we don't know. Some things we know that we don't know, and other things we don't know that we don't know.
We must learn -  We must continually strive to learn and incorporate our learning into our approach and behaviour. We must accept that yesterday's "right" may be today's "wrong".
We must collaborate - No one person can know or do it all. Only by collaboration can we attain the best possible outcome. This collaboration includes developers, business people and customers alike.

Summary

Being a good Scrum developer requires much more than being a good programmer. The mindset change and learning required to grow into this role may require quite some time, but it's a road definitely worth taking.
Of course, understanding your delivery framework, such as in this case, Scrum, is also advised, but that's probably the easiest part to pick up.

T-Shaped People: What and How

T-Shaped People in a cross-functional team will solve capacity problems much easier than limited domain experts. In general, agile methodology calls for T-Shaped People. Unfortunately, there may be cases where the basic approach may not work, or worse: be counterproductive.

Skill can be learned

Developers learn each of their domains, such as Java, C++, Python, PL/SQL etc. Picking up basics in a skill usually doesn't take more than a couple of days - mastery will take long, however. The more frequent a skill is utilized, the more fluent developers become. For example, simply confronting a front-end developer with the Unix Shell will permit them to pick up enough bash to get basic stuff done. Over the months, the developer will gain sufficient expertise and confidence to do even more intricate tasks in the new domain without relying on help.

Not everything is worth knowing

Certain skills may simply require a high level of expertise before they are actually valuable. For example, basically knowing Testing is not valuable in and of itself - if you don't understand what you must look for to catch the hidden bugs, your test may provide a false sense of confidence and cause more harm than good - so the team actually has to decide whether this specific skill is actually worth distributing in the required depth.

It is good to have more than one test expert on the team, but whether everyone should be able to pass the ISTQB Foundation Level without studying - is a completely different question.

For T-Shaped growth, apply the simplicity principle: Acquire as much skill as necessary to resolve potential bottlenecks, but do not revel in domains that are not your own.

Maintain Diversity

Do not confuse "T-Shaped People" with an anonymous mass of developers where everyone is equal. People still have individual strengths, individual focus and personal goals. One developer may really dig numbers, while another digs performance. Diversity is good. A Cross-Functional team should celebrate diversity rather than blending towards equality.

Again, the goal for T-Shaping is not to make everyone equal, but to resolve bottlenecks.

Not everything needs to be T-Shaped

One lesson of T-Shaping that is difficult to understand: Some people are simply not fit for certain tasks.
While our environment can force us to be more or less plan-oriented or more or less creative, the inherent brain-orientation will limit our performance in a specific domain. For example, a Left-brainer can learn how to use a drawing tool or a Right-brainer how to use a planning tool - but their approach will still be different, and - consequently, the result.
In some cases, this is actually desirable. In other cases, it is a clear reason for that person not to take on a specific task. In these cases, it's still viable to consider passing the buck on that one.

When "good enough" is too high

In rare cases, the limit for "good enough" is so high that only domain experts should take on a task. A specific case here would be the design of graphics and sound. Such artwork is either "good" or completely unacceptable. There is not much middle ground.

While you can train a Java developer to use a paint tool, the result of taking on a "paint a landscape" task will most likely be underwhelming. In such a case, it is definitely not worth considering shaping a "T".
The benchmark definition of "acceptable" set in the specific domain may occasionally turn the business value of T-Shaping so negative that it is simply not worth considering.
In this case, the organization must find different alternatives.

Summary

The simplest approach towards T-Shaping is simply picking up what you need on the go. However, you must ask the question "Will we need it?" and "Will the output actually be valuable?". If the answer to either of these questions is "No", then the organization must find different ways of ensuring that the specific skill does not become a bottleneck.

What it means to have T-Shaped People

Agile practice advocates a "Whole team approach". This means that not individuals, but the whole team is responsible for results. One of the pillars of this approach is "T-Shaped people", where team members are highly qualified experts in one domain, but at least basically proficient in other domains.
 

T-Shaped People solve Bottlenecks

The main reason for T-Shaped people is resolving bottlenecks within the team.

Eli Goldratt's Theory of Constraints states that the output of a system is limited by the slowest component, the so-called "Bottleneck".

For example, testing and coding often have vastly disproportionate effort: If there are 10 user stories "waiting for test", it makes more sense for a developer to test one of them than developing 2 more stories.

The classic argument, "Hire more testers" is not the solution for dealing with bottlenecks, because bottlenecks may arise and dissolve fluently. For example, your DBA may be sick - or your Frontend Developers take a 2 week's vacation. The duration of the bottleneck is too short termed to onboard a new person, but too long to simply let everyone else idle.

T-Shapedness develops over time

Usually, teams setting out on the Agile Journey are constituted of domain experts with a limited horizon. Coders are unfamiliar with test practices, Analysts are unfamiliar with modern software development frameworks, DBA's don't know how to code, etc.

We can simply accept this at the start: Nobody has been born a master. First, bring together a team where all necessary capacities exist and simply let people collaborate. Encourage pairing for mutual learning, and the necessary "T" will nevolve.

There is no reason to not encourage becoming T-Shaped, because a team of T-Shaped People will always fare better than a team without the "T".

T-Shaped People are not "Master of all Trades"

T-Shaped people are able to help out in times of need. They can grab a task that is stuck to increase the flow within development - but that doesn't mean they are nearly as good as the dedicated expert. This means that they may need significantly more time to achieve the result. Likewise, they may miss elegant solutions. We accept these downsides because a slow result is still better than no result - and refactoring allows us to increase the elegance of a solution if it ever matters.
In the end, it's not about perfection - but about achieving the best possible result with the people available.

Summary

Working towards T-Shaped people is an important way of increasing output and utilization of the team, while minimizing overall cost of development. T-Shaped developers are not supermen, but apt at always taking one step forward, regardless of the domain they are working on.

TWEAK: Knowledge

Creating great products requires the right environment, the right people - but also the right knowledge. In an ever evolving world, knowledge is not something you can "have", but something to continually strive for. On the quest for mastery, knowledge needs to be taken with special consideration. For each domain, you should see if your team is "struggling to keep up", "well in the loop" or "forerunner". While not everyone can win the race, it is a good idea to invest effort into getting ahead of the game.

As a Scrum Master, you should encourage everyone to broaden their knowledge regarding:

• Technical ExcellenceRegardless of whether it is Java, CSS, JavaScript, Databases or virtualization technologies - the team must be keen on their technical skills.
• Engineering Practices
  Testing, Refactoring, Emergent Design, Automation and many others are all essential to build the product right - all of these are easy to learn, but extremely difficult to master. 
• Product Domain
  Developers who are only technical experts will build the wrong product, unless they actively strive to understand the domain of the product they develop. Low hanging fruit may be out of your reach when you can't make the right connections.
• Agility
  The ideal of infinite Return on Investment requires responding to demand without any delay. Every step you take to be more agile will pay off - but what steps are available to you?
• Organizations
  The team must take steps to actively shape the organization in a positive fashion. To do this, they must understand well how their organization and the world around them "ticks".

Since "knowledge" itself is so broad, there is no definite way to approach broadening knowledge. You may read books, share experiences with your team or others in the organization - build up Communities of Practice, join Special Interest Groups or whatever you see fit. You need to make sure is that people are thirsty for more knowledge. You can't "push" knowledge. People must want it.

TWEAK: Ambition

Ambition is the desire not to just fulfil a duty, but to excel - do something better, achieve something better, be something better. There are many ways to increase ambition in a team, but Trust, Willingness and Energy are preconditions. Ambition is usually present in every person, but unfortunately dormant in poorly managed organizations.
As a Scrum Master, you should look out for these factors to raise ambition:

• Feedback Loops: Acknowledge and credit:
• Positive attitude
• Good ideas
• Good results
• Opportunity: Provide the means for developers to:
• try out new things
• be themselves
• Accomplish something
• Safety: Give people an environment where they can safely:
• Try things that might fail
• Say the wrong thing
• Be silly when they feel the need to

There are pretty much two styles of ambition. Negative ambition cares only for personal advantage and is destructive towards the organization. Positive ambition cares for mutually building things up and usually benefits the individual as much as the organization. Raising up ambition is as important as turning negative ambition into positivity.

TWEAK: Energy

Energy is how things are in motion. Low Energy usually implies that something, somewhere is impedited. Leadership activates energy, on which others either thrive. Similar to physics, in an agile environment, there is the law of "conservation of energy" , i.e. energy exists - the question is: In which state?
As a Scrum Master, here are some forms of energy to look for:

• Motion: Do you see things happening regarding:
• Improving the product?
• Improving the process?
• Teamworking?
• Technical excellence?
• Becoming a better organization?
• Heat: Do you see people caring about these?
• Light: Do people communicate about these, make them transparent?
• Magnetic: Where is conflict or tension regarding these?
• Nuclear: Where is unharnessed, raw potential to create motion, heat or light?

You must understand where the energy is - then, how it can be harnessed - and with whom to work. Where is the heat, where is magnetism - Do you want to shed some light, or set things into motion? There are many ways and there is no "final state". Harnessing energy is a continuous process, and the less directed it is, the more agile the organization becomes. 

The only important aspect of working with energy is: Always make sure the energy is positive. 

TWEAK: Trust!

Your team requires a high level of trust within, from the outside in, and towards the outside. Otherwise it will be difficult to perform properly: Performance will be wasted on "looking good" rather than "being good". Schemes and politics will reduce results accordingly, so trust is your primary factor to work with.

As a Scrum Master, here are the dimensions you should consider:

• Does the team trust 
• each other?
• the Scrum Master?
• their management?
• Product Owner?
• Customers?
• Is this trust mutual?
• What is the basis of the trust relationship?
• Is the trust relationship also transitive, for example: Does the Product Owner also trust the Management dealing properly with the team?
• Is the trust relationship also indirect, for example: Do Customers and Management trust each other?

Building trust is the first and most important pillar for team success. Only when trust is present, technical improvement activities will be effective.

Planning Poker: Why Points, not hours

Many Scrum teams struggle with Planning Poker and it's proper use. A recurring question is: "Can't we just use hours instead?". A mistake some teams make is converting the Points back into Man-Days.

The purpose of Planning Poker

Sprint Planning should contain a C-C-C process (Card, Conversation, Confirmation). In brief: 

1 - the PO displays what they want

2 - the team can probe whether they understand the idea in the same way

3 - the team discusses how they want to approach the topic,

4 - Everyone agrees that this is what will be done.

5 - Rinse, repeat until the team decides their capacity is reached.

Estimation in Story Points is used to quantify complexity of the task. It is actually expected that estimates vary until the team has reached a certain agreement on the complexity. 

Disregarding the accuracy of an estimate, a precise discussion of the factors contributing to complexity will bring the team's estimates closer to each other.

An example dialogue during Planning Poker

The Product Owner introduces the new Widget that will shoot our sales through the roof. Tim estimated a 20, Jane estimated a 3. Jane reasons: "All we need is to build some plastic device, put a chip on it and contact our service URL."

Tim then turns to the PO, "So, you expect the Widget to be usable from anywhere?" - "Yup" - "Even when no Wi-Fi is available?" - "Yup." - "Can we build a first version assuming Wi-Fi is present?" - "Yup." - the precision increased, but the Story has already been split into two pieces. Also, everyone on the team now understands why Tim had serious reservations about the complexity of the issue.

While Tim may now agree with Jane regarding the estimate for the first version, Jane may now also have serious reservations about the second stage, because nobody knows how complex this issue gets if "everywhere" also includes underground, in the absence of cellular and satellite signals.

Estimation is for Innovation

One of the first things which classic project managers must get used to is the idea that software development, as the name indicates, is development. Development is not just working according to plan, but the creation of something which was not in existence before. 

Software is always new: If we use something existing, we simply buy and/or include it. But we don't build it. If we build it, it's new. This means, nobody has done it before - or, at least, not exactly in the same way that we need it. 

How can you know how long something takes that nobody has done before?

You can't - and this is why at best, we estimate, not a detailed forecast.

Let's estimate

To give you some understanding of the difference between an estimate and the quantification of an effort forecast, let's play a game.

As a Product Owner, I have great visions and would ask you to do some estimation for me.

Here are 5 items which will bring great value to mankind:

• Cure for Cancer
• Immortalism
• Cold Fusion
• Warp Engine
• Terraforming

Now, I would like you to estimate these items for me. You can probably come up with a numbering between 1 and 20 for these items, where "1" is the least complex and "20" the most complex issue.

Almost intuitively, your numbering approach will probably revolve mostly about your understanding of the domain as well as the uncertainty you have. The actual "work to do" will probably play a miniscule role.

Estimates are not Man-Days

Can you now assign hours/months/years to each of these items?

In principle, the problem is identical to Software Development: We may have a certain (hopefully, more intricate) understanding of the domain, but we have never done that exactly same thing before. 

We will not know which solution is correct until the solution is correct and in place.  

Since the course of action is prone to change due to any new information we gain while we are working, it makes little sense to plan a specific course of action. Every step depends on the last step taken, and every result either encourages or discourages the next step we had in mind. Sometimes, next steps only become obvious once a specific result has been obtained.

Summary

The purpose of Planning Poker is the facilitation of discussion about complexity and uncertainty. We care for having a common understanding and dealing with the "known unknown". Removing any last bit of uncertainty about the issue might require more effort than actually coming up with a working solution, so we simply accept this uncertainty.

If the work is totally clear, the item is most likely quite small. When things interact, start to depend or become unclear - numbers will increase. A numerical estimate therefore indicates complexity and uncertainty, not work to do.

We purposefully de-scope capacity planning, because we understand that as soon as numbers increase, there will always be a rather high residual error. We value working software over guesswork numbers, so we only estimate enough to know what we intend to do - not what we will be doing for certain. 

We may have hindsight 20-20, but regarding the future, we will always be guessing.

Effective facilitation

The problem of teams new to agility is that they need to self-organize and may not feel ready for that: Self-organization should never be confused with anarchy or absence of order! But how do you conduct an orderly meeting if it is not organized by the team lead?

The answer is: Facilitation replaces direction.

Who needs to facilitate? The obvious answer would be: "The Scrum Master" - for a Scrum team. Or the team coach for another agile team. But that's not the whole story.
For example, Product Owner might want to facilitate Grooming, Refinement, Planning and Reviews without relying on assistance.
For beginning teams, the facilitator should definitely be an experienced coach or Scrum Master. New Scrum Masters need to learn facilitation as quickly as possible. Without an experienced facilitator, you will be doomed to a boatload of frustrating, boring meetings - and there is no guarantee that it will get better!

More advanced teams do not rely on coaches or Scrum Masters for facilitation: The team can somehow facilitate, based on the team's working agreements and social structure and may just require coach intervention for special occasions.


But how do you effectively facilitate?

Purpose

Borrowing from Dan Pink's "Drive", Purpose is an important element of work.  Whatever meeting you are facilitating, ensure that the purpose is clear and meaningful. This will create engagement.
An important aspect of facilitation is ensuring that the purpose does not get diluted or lost. Intervene when the purpose is obviously lost, but permit potentially valuable sidetracks.

Do nothing

A facilitator's job is not to tell others what to do, say or think. Their job is to get others to do, say or think things. Here are three ways how you can actively do nothing to facilitate the meeting:

• Do not feel compelled to break the silence after a question was asked. Be comfortable with silence. Wait until someone else speaks.
• Accept that some of the things which are said may be off topic or misleading: Do not contradict. If you feel the need to intervene, ask a question without making a statement.
• When a discussion is going on, you may want to take notes, support with visualization or just silently reflect. Do not interfere in a well-going discussion unless the time box is up.

Ask questions

Questions are your most powerful tool for facilitation.
As facilitator, your responsibility is not to tell others anything about the domain of the discussion - your responsibility is to get them to speak. The best way to do this is by asking the right questions.

Games / Exercises

You may want to add some games or other exercises for lightening up the mood or directing the discussion. This may be good to break the ice or to prevent boredom, but be wary that people do not focus on the exercise. This can become a distraction from the original purpose! Do not load a firework of effects without a clearly planned purpose.

Visualize

A good way to facilitate during moderation is by visualizing. This does not typically mean drawing fancy charts, but it means putting the spoken words into something visible for the eye. This is valuable because misunderstandings or uncertainties become really obvious very fast. For example, drawing an arrow to the wrong bubble will immediately be corrected - without you having to say a single word!

Summary

Don't try to change everything at once. Whether you are new to facilitation or "still learning", pick one item that you wish to improve upon and change it for the next meeting. Learn from the feedback, inspect and adapt.
Over the years, your facilitation will continually become more effective through incremental change.