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)
Sunday, February 8, 2015
The way we express our estimates color both the way we think about the thing being estimated and the way our estimates are heard. (Continued)
Monday, January 12, 2015
If you look at things from the same point of view all the time, you’ll tend to see the same things, and overlook the same things. I discuss on ProjectManagement.com how to vary your view to get a better overall picture.
Wednesday, December 31, 2014
Thanks to Tim Ottinger for reminding me of Arlo Belshee’s post, “Is Pair Programming for Me?” Go read Arlo’s post, as it’s insightful and has more useful content than most articles on pairing. I’m just going to springboard off of one skill that Arlo mentioned being important to learn.
How to avoid “paragraphing” when talking. Learning to speak in half-sentences, leaving room for the other to take the idea in an unexpected direction.
A few years back, I took a course in “Beginning Improv Acting.” (Continued)
Wednesday, December 10, 2014
I sometimes see clashes between Kanban proponents and their Scrum counterparts. Despite the disagreements, both of these approaches tend toward the same goals and use many similar techniques. Karl Scotland and I did some root cause analysis of practices a few years back and came to the conclusion that there were a lot of similarities between Kanban and Scrum [as the poster-child of iterative agile] when viewed through that lens. I also noticed that while Scrum explicitly focuses on iterations as a control mechanism, Scrum teams tend get into trouble when they ignore Work In Progress (WIP). Conversely, while Kanban explicitly focuses on WIP, Kanban teams tend to get into trouble when they ignore Cadence.
A twitter conversation I was in revolved around Cycle Time and Velocity. Since this is a topic that’s come up before, I thought it would be valuable to describe it more fully. Again, I find there to be more similarities than differences between Kanban (which uses Cycle Time) and Scrum (which uses Velocity) in terms of predicting when a given amount of work will be done, or how much work will be done by a given time. (Continued)