The Third Leg of Emergent Design: Acceptance Test-Driven Development (ATDD)

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)”

Design Patterns: The Second Leg of Emergent Design

TDD is the first leg of emergent design or what could be called Agile Design. Design patterns are the second. They’re often described as “solutions to recurring problems in a context.” In this way they can be thought of as recipes that have been learned. But patterns open the door to much more; they are examples of ways to think. Patterns hide varying behavior, structure or which objects to use. Continue reading “Design Patterns: The Second Leg of Emergent Design”

What Type of Client I’m Looking For. Maybe You’re Looking For Me

I know I’m on the edge. And I know I don’t fit everyone – both in style and approach. I prefer working with people who want to think, people who have confidence in themselves. People who are open to learning but don’t believe what they are told until they understand it. People who look for consultants to guide them – not direct them.

I believe frameworks have their place to provide insights on where to start and what to do but are a risk when just followed- which is what most promoters imply when they say “you have to do this until you understand.” I believe that statements says more about their ability to explain and points to a weakness in their framework than it does about who they are talking to.

I have always questioned stock answers, because I believe HL Mencken’s comment – “for every complex problem there is a simple, neat solution that is wrong” applies all too often. The quick fix might get you started but it might also be exactly what gets you even more stuck after just a little while.

I believe that a good approach provides immediate value. And if it doesn’t, then a better approach is available.

If you have similar beliefs, I believe you’d find me valuable to work with.

Test-Driven Development (TDD): The First Leg of Emergent Design

I am heartened by the surge in TDD training. To me, TDD is the second most important thing for devs to learn. ATDD is the first.

TDD is not just the automation of unit testing. It’s also intended to improve design and sustainability.

TDD’s formulation of tests, prior to code, drives design. High quality code is easy to test. The reverse is also true. Code that is easy to test is higher quality than code that isn’t. I labeled this quality, “testability,” in my book Design Patterns Explained. Test-First is a process where deciding on your tests before writing your code improves your design. Continue reading “Test-Driven Development (TDD): The First Leg of Emergent Design”

Shift Your View To What’s Important

One of the major tenet’s of Lean is to not focus on individual activities but to look at the flow of value from concept to realization. Focusing on people, btw, is not Agile in my mind. We should be trusting and respecting them – not judging them. They are doing the best they can. management must provide them with a great eco-system in which to self-organize in order to achieve the business’ objectives.

The challenges around velocity illustrate this. If one understood the goal is to shorten cycle time (the time from concept to realization) it would be clear that managing (not measuring) velocity has no value. Many of the challenges we have in Scrum and SAFe is because these frameworks have us subtly look at the wrong thing.

But these things sure look important so someone sometimes has to shake us up to look at the right thing. The beauty is, once we look at our present in the right way, we can reflect on our past and instantly get a lot of experience. This is why newbies don’t have to be patronized and told to just use things as they are. They can think for themselves with years of experience once they know what to look at. This is the difference between giving advice and giving a new way to see a problem. I prefer the latter.

The Insidious Side of Scrum and How I’d Fix It (and yes, I know it wouldn’t be Scrum anymore)

Scrum is based on empirical process control. If I understand this correctly, this means that we base our actions on what happens and inspect and adapt accordingly. Scrum is accordingly set up with a set of rules, roles, artifacts and events designed in such a way that if they are followed good results will happen.

Continue reading “The Insidious Side of Scrum and How I’d Fix It (and yes, I know it wouldn’t be Scrum anymore)”

INVEST is a goal, not a guide

I–Independent
N–Negotiable
V–Valuable
E–Estimable
S–Small
T–Testable

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.

We need disruption in Agile Training and Coaching

Certifying bodies promoting a particular brand have changed the industry for the better in many ways.

But they are businesses. And their model is selling training. As much as possible, as you’d expect from any business. And the people they support’s model is training and placing coaches.

Brands compete – so it’s not surprising to see a focus on the brand in workshops instead of activities everyone needs to learn. If the focus were on the work much of Agile training would look similar.

Training today is not that dissimilar to what it was 20 years ago – intense workshops with follow up coaching. The first is inefficient (people don’t retain much from workshops) and the second is expensive.

We need a disruptive force here. But don’t expect the certifying bodies to provide the disruption – they have no incentive to make things more efficient. Expect the disruption to come from somewhere else.

Agile Developer Habits 101 – Focus on Finishing to Manage Work in Process

Kanban suggests we manage work in process (WIP). Many people interpret this to mean add WIP limits on queues. But that’s not the only way to do it. And it often takes a very disciplined team to do that.

An easy way to start managing WIP is to simply build a habit of looking to finish something before starting something new.

Habit – manage Work in Process

Trigger: When you complete a task.

Action: Look to see if there’s another task that’s already been started that you can finish. If it’s yours, just finish it. If it’s someone else’s see how you can help them.

Intention: Avoid increasing WIP above capacity without having to put a lot of effort on it while also creating opportunities for cross-learning and collaboration.

Agile Developer Habits 101 – How Will I Know I’ve Done That

I have learned that developing good habits is key in improving my abilities. A series of good small decisions can often prove to be better than infrequent good ones. The most effective way to develop a habit is to have a trigger for it. That is, when an event occurs, do the thing you want to. Otherwise good habits just devolve to good ideas that don’t happen.

One good habit is to validate you understand something that someone has requested of you. In this case our trigger can be a request. The habit is to validate it by asking them what their acceptance criteria is. This doesn’t mean that they are right in their criteria – people often ask for the wrong thing. But a critical first step is to ensure you understand what they asked for.

Habit – validate understanding.

Trigger: When someone asks you to do something.

Action: Ask – “how will I know I’ve done that?”

Intention: Validate that what they say matches what you heard.

Habit – understand their why

Follow up Action: Ask – “and why do you want that?”

Intention: Validate you understand their objective as their might be a different way to achieve that.