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”
Among the things needed in the Agile space are better training methods and a better way to use frameworks. This pertains to all organizations coming to Agile: They are rightfully concerned about what the kind of Agile training they’ll get. They want improvements, not frameworks. At best, frameworks are a means to an end.
Recently, I wrote to such an organization with these concerns. It had a proposal for a small-scale adoption of Lean-Agile involving 3-10 teams with associated Product Owners. Continue reading “An Open Letter to Participants When We Go In To Train”
In the same way that looking at the value stream helps you observe how value moves, looking at the value stream helps you discover challenges you are facing. Here are some of the most common challenges.
- It takes too long to get anything done
- Work is not properly prioritized
- Chunks of work are too big
- Too many things are in work
- There are unclear requirements
- Teams don’t understand the needs of the business
- Some people have too much to do and are constraints on multiple teams
- There is high technical debt
- There are many integration errors
- There is insufficient collaboration
- Ops is blindsided and pulled in many directions
- There is a lack of visibility of what is taking place
Often, these challenges are apparent when work is stuck in large queues just before the step where the problem is. Lean suggests that instead of focusing on how people can work faster, you should take steps to keep queue size down. Usually, this involves working on small batches, how you do work, and how you organize talent.
Scrum and Kanban are the two most popular Agile team-level methods available. While the difference between them is mostly thought to be sprint-based or flow-based, that is just one way in which they differ. Other significant differences include how to start, how to improve, and how people should be organized. They are based on different theories of how to manage software development work and whether you need to change your roles. And this creates other differences such include the amount of discipline to use them and the cultures in which they fit. Continue reading “Why Agile Coaches Need to Know Both Scrum and Kanban”
We hear so much about how adopting Agile is hard. It is worth looking at the exceptions in order to learn why it doesn’t have to be that way.
Let’s consider the case of a dev group of 75-300 people. This is a good example of a common situation. The organization was looking at improvements, focusing on product management, and organizing how people work together. Specifically, here was what they paid attention to. Continue reading “The Common Aspects of Almost-Instant Agile Success”