Thursday, June 2, 2016
On numerous occasions I’ve observed long-time members of the Agile community complain about misinterpretations of what Agile means, and how it performed. Frequently this is precipitated by yet another blog post about how terrible Agile is, and how it damaged the life of the blogger. Sometimes it’s triggered by a new pronouncement of THE way to practice Agile software development, often in ways that are hardly recognizable as Agile. Or THE way to practice software development is declared post-Agile as if Agile is now obsolete and ready to be tossed in the trash bin. (Continued)
Saturday, December 12, 2015
The simplest method of estimation is to compare the anticipated work to past experience. And we all have experience that we can use. The big question is how relevant is that experience. A secondary question is how clearly do we remember that experience.
We always have experience, of course. We weren’t born developing systems. We’ve tried things, and learned things, from childhood onwards along a path that’s lead us to today’s situation. In all the things we’ve done, there’s something that we can compare with the work we’re facing. (Continued)
Wednesday, October 28, 2015
Even when you’ve done something many times before, sometimes you forget something or make a mistake.
This morning I was on my way to visit a client and realized I’d forgotten something. It seemed to me important enough to do something about it, so I went back home and got it. The unanticipated delay threw my schedule into disarray. I wasn’t going to arrive by the time I wanted. I was frustrated and unhappy with myself.
I see similar things happen all the time in software development projects. Something throws off the schedule. People get unhappy. (Continued)
Wednesday, September 2, 2015
“I need this project done by date D and within cost budget C. Now calculate an estimate on the project.”
A friend of mine used this example to illustrate anchoring bias in estimation. Note, however, that he doesn’t make the question explicit. Further conversation revealed that he had in mind that the date and cost should be the output of the estimation. With that assumption, that statement preceding the request will definitely anchor the answer, and realizing that this bias is likely will call into question whatever estimate is given.
Given the stated need, however, I would reframe the call for an estimate from “When will this project be done and how much will it cost” to “What is the likelihood that the project can be done within these constraints?” (Continued)
Tuesday, June 2, 2015
Sometimes we intentionally make our work more visible so that we can more easily see what’s going on. We do this so that, as a group, we get a better picture of the whole of the group’s effort. At it’s best, this is more than a dashboard that displays information. Instead, it’s a tool that’s used by the people doing the work in the process of doing that work. (Continued)
Sunday, May 31, 2015
Ryan Ripley has posted the second Agile for Humans podcast where he, Amitai Schlair, and I discuss the life of a consultant, how to make retrospectives valuable, and the place of managers in an Agile organization.
Thursday, March 5, 2015
The number one problem I see at clients is that there is no time to learn. Without time to reflect on how things are working, we don’t notice the things that we’re accustomed to not working very well. Without time to research what others are doing, we can’t make informed choices about things we might want to try. Without time to try experiments, we can’t find out if a different approach will work better for us, or not. Without time to try multiple experiments, we can’t evaluate what works for us over a broad range of situations rather than latching onto the first idea that appears to work at all.
To a large degree, Agile software development IS learning. We try things mindfully, watch the results we get, reflect on why we get those results, and adjust. We do that at multiple levels of granularity, from choosing what products to develop to writing code that works reliably.
It takes time, but it pays off over time. To keep doing the same things in the same way suggests that we know everything there is to know about it, and there are no improvements left to make. That we are already at top speed. That we can only do worse than we are right now. I find that highly unlikely.
There is always more to learn. There are ways to learn better ways to learn.
Tuesday, February 17, 2015
Should your tests mock outside services or not? I keep seeing discussions on this topic. On the one hand, it lets your tests be in control of the testing context. Otherwise it may be very difficult to create a reliable automated test.
- The external service might return different results at different times.
- The external service might be slow to respond.
- Using the external service might require running the test in a particular environment.
- It may be impossible to generate certain error conditions with the real service.
- There may be side-effects of using the real service.
On the other hand, our mock of the external service might differ from it in important ways.
- Our mock service might have a slightly different interface than the real one.
- Our mock service might accept slightly different parameters than the real one.
- Our mock service might return slightly different results than the real one.
- The real service might change behavior, and we won’t notice until we deploy to production.
This leaves us in a quandary. What to do? (Continued)
Friday, February 13, 2015
My article, Agile Adoption: Changing Behavior by Asking the Right Questions, has been published over on ProjectManagement.com (free registration required). It talks about when managers want change, but don’t want to squeeze the Agile out by force.
Thursday, February 12, 2015
An open letter to a programmer who thinks that code coverage by integration tests eliminates the need for unit tests. (Continued)