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 »
Posted in post | Tagged estimates, planning, psychology | Leave a Comment »
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 »
Posted in post | Tagged Agile, context, customization | 13 Comments »
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 »
Posted in post | Tagged Agile, catalyst, champion, mind-shift, transitions | 2 Comments »
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 »
Posted in post | Tagged Agile, architecture, design, scaling | 7 Comments »
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 »
Posted in post | Tagged Agile, scaling, shipping | 14 Comments »
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 »
Posted in post | Tagged Agile, governance, scaling agile, sociocracy | Leave a Comment »
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 »
Posted in post | Tagged Agile, collaboration, model | Leave a Comment »
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 »
Posted in essay | 5 Comments »
I am forming a new team. We are doing this as an experiment, so we are documenting the heck out of it. As part of this effort, I am publishing “Coach Arlo’s Secret Agenda”—a daily journal of what I intend to teach each day and what the results were. This is/will be a name-scrubbed version of that series.
Welcome inside my mind as I go through each day and detail of spinning up a new team and transitioning it to agile at the same time. Continue Reading »
Posted in post | Tagged coach, experience report, story, transition | Leave a Comment »
Recently on twitter, Clayton asked for a good book about unit testing without mocks. I don’t believe such a thing can be written, so I’ll try to write it in one blog post. First, here it is in one sentence:
Mocks are a smell. They tell you that your code depends on some semi-related part of the system. Rather than work around the design defect, fix the design.
The trick is figuring out what smell you are observing and how to “fix” it. Basically, what alternatives exist. Down the rabbit hole we go. Continue Reading »
Posted in post | Tagged design, no mocks, tdd | 23 Comments »