A Simple Solution to Agile at Small-Scale

I keep running across organizations with 4-10 dev teams struggling with Agile. They look to the two most popular frameworks out there for a solution (Scrum & SAFe) to solve their problems. On one hand they see something that can work at the team but doesn’t help them with their product management. On the other they see something much bigger than they need. They’ve fallen into a trap–looking for a solution instead of solving their problem

What are their problems? Most have trouble Identifying what has the greatest value to deliver, breaking it down into the right size business increments to give to the teams, coordinating their teams’ work, teams not being able to decompose the business increments they’re given into small stories, and building, validating and releasing the code quickly. These abilities should be their focus

When Agile Product Management provides guidance in what’s important, coordinating teams is straightforward. It’s easier to pull a rope than it is to push it. 2-3 days working on prod management, ATDD, a little Scrum and a little Lean is all you need. Invest here, it returns more value. And it’s less expensive. Proper training &coaching methods can get your product folks, 6 teams & their coaches working with Agile methods for less than $40k

Examining Test-First

“Test-first “sounds like it’s about testing, but it’s really about collaboration, shared understanding and better design. Test-first originated with eXtreme Programming (XP) with the focus was on writing tests before code. Fortunately, a natural law of software development is that programs written by first considering their behavior are more flexible and robust than programs written by considering their implementation.

Since then, test-first has expanded to be used between product owners and the team by specifying the requirements in the form of acceptance tests. This is called Acceptance TDD (ATDD)

ATDD requires the collaboration of all parties involved. This collaboration on understanding behavior prior to implementation clarifies what is being required while removing the delay between specification of requirements, their implementation and then their final validation. This both helps ensure the right functionality is built while increasing efficiency.

The benefits of ATDD are

  • improved collaboration
  • clear acceptance criteria
  • prepared for automated testing
  • improved developer-tester communication
  • reduced time for feedback
  • agreement on requirements
  • improved code quality

It’s one of the best steps towards building the right thing in the right way.

For more information see:

Benefits of Acceptance Test-Driven Development using Behavior-Driven Development

How to Start with ATDD using BDD

Why Learning How to Decompose Stories with Acceptance Test-Driven Development (ATDD) Is not Just Decomposition

I’ve been having a very interesting twittervation about how to start teams off with Scrum. I believe you best learn by doing. And that it’s more important to get teams actually starting Agile in the workshop than merely learning Scrum which will hopefully lead you to Agile.

So we “teach” Scrum with a 1-day emulation and discussion of it followed by 3 days of ATDD. This first day teaches the essence of Scrum but it illustrates how teams work – mostly their foibles. 🙂

The other three days are on ATDD. Each day isi split by 1/2 day discussing it & then an hour with each team doing it. What we’re really teaching is – collaboration, test-first, feature slicing, and how to use minimum business increments. These directly address the issues we’ve seen most teams have- unclear requirements, stories too large, POs not appreciating the impact of interruptions and a lack of focus on finishing.

The test-first is mostly about discovery & specification but it also informs design (the 1st mantra of design patterns is designing from behavior).

The result is that once a team gets moving they can keep moving. But a course that prepares you for movement may not ever get you started.

XP is not Scrum with tech practices & knowing why this is so is more important than ever before

I’ve always been bothered by the dismissal of XP as just being “Scrum with tech practices.” But the differences between the two are much greater. First, while XP and Scrum both have related values, the practices of XP are mostly centered around sw development practices (such as paired programming), while Scrum is mostly about non-domain specific team practices. Second, XP includes Acceptance Test-Driven Development (ATDD). ATDD, which is a collaboration between the Product Owner, dev, and tester and which includes neither design nor coding and is therefore, not a technical practice. In other words, Continue reading “XP is not Scrum with tech practices & knowing why this is so is more important than ever before”

The missing piece of Lean Portfolio Management

I am often asked how to do Lean Portfolio Management. Let’s consider what’s needed to do this effectively. The real issue is when different programs require the same limited capabilities. How do you decide which one is more important? Weighted Shortest Job First (WSJF) is commonly used. But ‘business value’, a  key component of WSJF, means different things to different groups.

How can we decide what the business value is when people in different divisions have different views? Continue reading “The missing piece of Lean Portfolio Management”

A missing piece in SAFe product management

Lean suggests that we work with small batches, be able to deliver value quickly and to drive from a business perspective (typically through delivering value to the customer). ‘Deliver value’ means not just to deploy something but to ensure that value can be realized by the intended customer. In other words, we need a definition for the smallest increment of value that delivers value from a business perspective. In other words, it can’t be too small (we may not want to be delivering all the time) but it has to be sufficient (have all the components (e.g., marketing) required to realize value. In other words, minimum yet sufficient. It also must have measurable value from a business perspective. Continue reading “A missing piece in SAFe product management”

The first step in Lean Portfolio Management

Lean portfolio management is an important aspect of enterprise Agility. Organizations always have more options than capacity. One therefore needs to be able to understand what is the most important value to deliver. But what is value to one company may be waste to another. The first step in Lean Portfolio Management therefore, is determining what’s of value to the organization.

This, of course, is typically oriented around value to customers. or example, a financial company might focus on: Continue reading “The first step in Lean Portfolio Management”

Big Room Planning Event tip: Make sure commitments are made for all dependencies

Planning events should be more about collaboration & dependency management than just creating a plan. Teams commit to the plan with the understanding that any teams they are dependent upon will work with them as needed.

During the event this requires both teams to agree to the date a dependency will be built. This is supposed to happen before the stickies & yarn go on the board. But it sometimes doesn’t happen. This must be tracked. This is done easily enough by putting red dots on both stickies involved. This does not always draw these uncommitted to dependencies to enough attention.

Continue reading “Big Room Planning Event tip: Make sure commitments are made for all dependencies”

When given a requirement ask the question, “How will I know I’ve done that?”

Many people think of Acceptance Test-Driven Development (ATDD) as an advanced practice. Others think that using Given When Then (GWT) from Behavior Driven Development (BDD) requires the use of tools. Neither of these are true however. The easiest way to start using ATDD and/or BDD is simply to ask the question “How will I know I’ve done that?” whenever you are given a requirement – even if the requirement appears to be obvious. The reason for this is that it is often the ‘obvious’ requirements that are most misunderstood. Continue reading “When given a requirement ask the question, “How will I know I’ve done that?””

Why you should grow your own Scrum Masters instead of bringing in outside coaches

If you are kicking off new teams there are two types of coaches you can bring in. While it’s useful to bring in someone who can actually help with the work, such as a technical or ATDD coach, when it comes to Scrum or Agile coaches it’s usually better to grow your own. There are several reasons for this:

Continue reading “Why you should grow your own Scrum Masters instead of bringing in outside coaches”