In previous posts, I discussed that the first leg of emergent design is TDD, which provides code quality and sustainability. The second leg is design patterns, which provides insights into handling variation. The third leg is ATDD, which provides us a way of discovering and clarifying the value we will get. Continue reading “The Third Leg of Emergent Design: Acceptance Test-Driven Development (ATDD)”
This is almost universally used to teach how to write stories. But notice, it’s a goal, not a method. Goals are good, but in themselves, don’t provide much guidance to get to them (think “buy low sell high”).
A better way to learn to write stories is to take advantage of the discovery & specification phases of Acceptance Test-Driven Development (ATDD). While usually relegated to the 2nd or 3rd round of training we’ve seen light-weight ATDD integrated with initial Scrum training enables teams to write stories right out of the box and eliminates 3 of the major challenges most teams have adopting Scrum:
1) writing small stories
2) having clear requirements
3) understanding why testing cannot lag coding
This is the key to learning Agile- not just learning the end state desired, but using methods that actually help get you there. It is easier to act your way into a new way of thinking than think your way into a new way of acting.
ATDD has the dev team focus on identifying and validating (Testable) Small chunks of Value by “Negotiating” with the PO. Part of ATDD is to decouple (make Independent) the stories. Since these stories are now understood, they are also Estimable.
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
“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:
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.
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”
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”
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”
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”
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.