I can change the rate at which I learn things. So can you. It doesn’t depend on topic or natural inclination. It doesn’t depend on intelligence. It’s all in how I set up my learning experience.
I am not a professional instructional designer but I pair with them. I am a professional coach. And I am a professional learner. Here are the techniques I use to learn, instruct, and coach more effectively. I hope you find them useful. Continue Reading »
Posted in post | Tagged anzaneering, brains, learning, mob programming, pair programming | 4 Comments »
I typically ignore planning in this blog. Not because it isn’t important, but because it isn’t important until later. You need to be able to deliver if you want your plans to mean anything.
However, there is one topic that I think worth discussing: estimating your work. I find this worth discussing because I see so many people do it wrong and suffer massive pain that they could have avoided.
Which causes deadline pressure. Which prevents them from making the improvements that would help them deliver. Continue Reading »
Posted in post | Tagged estimates, estimation, stories, velocity | Leave a Comment »
A manager recently asked me how to measure whether the teams were unit testing. He believes that they are. He has heard strong alignment among ICs and managers. He also knows that the teams have no way to see if they actually are unit testing or how well.
He, like most people, asserted the use of code coverage as the core metric. Both total and per-commit delta.
I agree that we need some optics. I just think code coverage is a crap measure. Continue Reading »
Posted in post | Tagged metrics, tdd, unit testing | Leave a Comment »
Someone I know had the following conversation recently during code review:
- [WontFix] //depot/[elided].cs: Line 232
- [reviewer]: Unit test this directly
- [author]: the integrations test this. Don’t see any direct benefit of UT it directly. (26 minutes ago)
He wanted advice on how to get past this. His goal is to get his team to write direct unit tests, as opposed to multi-unit component and integration tests. But how? And what does he do in code review to help the team accomplish that in specific cases? Continue Reading »
Posted in post | Tagged change, code review, culture, habit formation, learning, mobbing, pair programming | 1 Comment »
I got a question this morning:
We are struggling to define a standard MVP across the teams. Do you guys have any suggestions for us?
One question: why do you need a standard? What problem are you really trying to solve?
I ask because the point of doing MVPs is to support validated learning. It assumes a development process that is based on running experiments to learn things, not on building things to a definition / spec.
Experimentation is inhibited by over-standardization, so you must be wanting to do this for some other reason (probably status reporting or other forms of status). Continue Reading »
Posted in post | Tagged HDD, hypothesis, mmf, mvp, planning | Leave a Comment »
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 »
Posted in post | Tagged Agile, legacy, tdd, test first | Leave a Comment »
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 »
Posted in post | Tagged Agile, anzaneering, bugs, refacctoring, risk | 6 Comments »
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 »