I find one of the important early mind shifts to be a switch from thinking of unit tests as test to thinking of the set of all tests as your spec.
If your spec is clean, you could delete your product code, hand it to someone, and they would implement the same product, with roughly the same design.
If your product code is clean, you could delete your spec. Hand the code to someone and they could extract the spec from the code, ending up with a similar spec.
The first of these is called TDD. The second is called working effectively with legacy code. Continue reading “Your test are just your spec. NBD.”
A couple centuries ago, fires were seen as a natural side effect of cities. If you put that many businesses and houses together, sometimes it would just all burn down. Cities were useful, so you accepted that every once in a while a whole lot of people would die in a fire.
Much of the software world is in the same state today. Bugs are seen as a natural side effect of code. If you build systems that solve that many interesting problems for people, sometimes it will just all screw up. Software is useful, so you accept that every once in a while a whole lot of people’s work will die in a bug.
The people building and debugging software today have similar methods of working to the people building and de-firing cities then. But today, fire fighting and city planning are different. They prevent fires. Fires still happen, but no cities burn down and few people die. Let’s do the same with bugs. Continue reading “Treat bugs as fires”
In one sense, units don’t matter at all. In another they are critical. It’s all human psych.
The fundamental problem is a cognitive bias termed the Planning Fallacy. This well-documented bias shows that the human brain, even with training, always estimates outcomes on the information it knows. We have a well-researched, systemic bias that causes us to consistently under-estimate, even when we take this bias into account during estimation.
In the Agile world, we accidentally discovered a system that works around that bias. But most of us don’t know that we’re applying it, and the others don’t see why they should. Continue reading “Planning with any hope of accuracy”
One set of people seems very concerned with defining exactly what Agile is. They want a particular set of practices done in a particular way at a particular level of discipline. From them we hear the constant refrain “that’s not Agile|Scrum|Whatever” or “Kanban|Whatever is/is not Agile.”
Another set of people feel that Agile is a spectrum. A given team may be more or less Agile. They focus on the values and way of thinking. If you think Agile, then you are Agile regardless of your degree of practice. From them we hear the constant refrain “you can’t do Agile, you can only be Agile.”
They’re both wrong.
Continue reading “That’s Not Agile”
Most teams are perpetually only 3-6 monthsÂ from being able to ship low-bug software when desired and deliveringÂ end-to-end business value out of each single team (making decoupling trivial).
But they choose to go a different, more costly direction.
They aren’t dumb. So why do they repeatedly make a dumb decision? And what can we do about it (whether we are on such a team or not)? Continue reading “Being Awesome Step 1: Stop Making Dumb Choices”
My position on architecture is different from most peoples’. My view works really well at scale (much better than the traditional view, in my experience), but it is very different.
I start with one traditional definition of architecture: any decision that would be costly to change. However, I also know that I (and those on my teams) learn quickly. Every problem that I found difficult at some point has later been found to be easy…once we learned more. This gets me to my final definition.
Architecture is any decision you makeÂ that you are not yet smart enough to be able to change on a whim.
The best large systems have no architecture, under my definition, at all. Continue reading “Architecture – Scaling Design”
I hear a lot about Scaling Agile these days. Every time I hear it I have to shake my head. The fact that people are asking how to scale Agile means that they don’t know how to do Agile. The fact that people are designing frameworks for scaling Agile means that they don’t know how to do Agile either. Agile done right (beyond the 1-star level) consists of two steps:
- Change the rules of the game (by changing the details of how software is created moment-by-moment).
- Adapt everything else to take advantage of the new reality.
This is why when you ask “how do I scale Agile?” to someone who can ship at will, they look at you with a blank stare. If you’re thinking about “scaling Agile,” then you probably haven’t really benefitted from your agile implementation. If you had, then the question wouldn’t make sense to you either. You would just scale your business in a few obvious ways, look around, and repeat.
There isn’t a special method to scale Agile. The team just does whatever it was doing before, only it stops doing whichever parts it doesn’t need anymore. Continue reading “Scaling Agile – the Easy Way”
Dynamic Governance is an organizational pattern designed to maximize flexibility and alignment in organizations where ideas can (and should) come from anywhere in the company, while still scaling to very large organizations and working towards prescribed goals. It is used very commonly in large companies in The Netherlands (under the name Sociocracy). It has been used in organizations in the US (hospitals, software companies, apartment complexes), but is much less common. It has been used with organizations up to ~100k people.
If we define the goal of making decisions as enabling concerted action, then consent among a small team (defined below) is one of the most efficient and effective decision-making strategies known. Dynamic Governance is a method to scale consent-based decision making. Continue reading “Sociocracy / Dynamic Governance – A Primer”
I work at Microsoft. You may have heard we had a recent company-wide re-org. As part of that, SteveB changed the definition of what it takes to be successful in Microsoft. Collaboration is now among his 5 key traits. In the details, he said it is â€œmore than just being nice to work withâ€ and includes successfully coordinating with others.
True, butÂ collaboration is also a lot more than coordination. Continue reading “Collaborating on collaboration”
I want to get the team off to a good, clean start.
My challenge is that we are not used to working collaboratively in this group / company. The point of this experiment is to work collaboratively and to see how that impacts productivity and flexibility. For example, what does the ramp-up cost look like to work in an area where only one person is a SME?
Therefore, everything I do today is focused on ensuring a collaborative team. Continue reading “Coaching Day 1: Getting a clean liftoff”