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.