Time flies like an arrow…
… and fruit flies like a banana. It’s amazing to me that it’s been three weeks since my last post. Sometimes real life has a way of consuming the time, leaving little left for philosophizing.
During this time, Brian Marick has been stirring things up at the Agile Alliance. I’ve joined in the discussion of his observations and proposals only a little. Brian’s turned over a lot of stones at once, and it takes me awhile to examine all the things that have been living under them. Being a Myers-Briggs introvert, I tend to discuss these things in my own head before displaying them to the world. Here, though, I’m just thinking out loud and I haven’t come to any conclusion.
Snipping a bit from Brian’s proposal:
It should explicitly focus on helping members of Agile teams succeed, leaving concern with the larger organization to others.
- “Members of the Agile team” is defined to be everyone who’d be expected to attend a team standup meeting: programmers, testers, user experience designers, Scrum product owners or XP Customers, technical writers, and so on.
- “Succeed” means that (a) team members love their work, (b) the business both considers its money well spent and also sees the current version of the software as a readily-tapped reservoir of potential value, and (c) the software is so good that team members bore people at parties describing how easy it is to change, to push builds to production, to debug, and so on.
My first inclination to this is to say no, because I don’t think you can successfully do Agile development at the low level without affecting (or being affected by) the way things are done in the rest of the company. In my experience, implementing Agile at the developer level can be incredibly difficult when the surface level expectations of the next couple layers of management are using a different terminology and different way of slicing the work.
On the other hand, the Agile Project Leadership Network is clearly focused at the management levels, and Lean Software Development, as described by people like Tom and Mary Poppendieck, is focused more toward the executive office suite. So, maybe it’s OK that the Agile Alliance focus on the nuts and bolts at the lower levels. The other levels are not ignored, even if they’re not the focus of the Agile Alliance. It will, however, be important to improve communications between people and organizations focused at these different levels to avoid local optimization.
Brian also says,
Whereas many team members are weak in the basic skills and need to learn them, many others are fluent at the state of the practice and want to improve it…
I think he’s intending to differentiate between developers who want to make Agile more than it is today, and those who sometimes struggle with getting the code to work at all, and would do well to accomplish the basic developer skills of Agile. I can certainly understand and empathize with this distinction. It’s really hard to discuss refactoring with a developer who can’t articulate the concepts of software cohesion and coupling. There is a lot of bad code being written, in spite of the success of the design patterns movement. I’ve interviewed a lot of developers who mention “design patterns” on their resume but, when asked to name some they’ve found particularly useful, can only come up with the Singleton pattern. Contrast that with developers who are discussing the merits of particular techniques of TDD (or BDD) or whether state-based or interaction-based testing works the best.
There’s another area where “many team members lack the basic skills,” however, and that’s in the “Individuals and Interactions” arena. These skills are completely orthogonal to those needed to create “Working Software” and the set of people sorely lacking these skills are likewise distinct, yet overlapping. Yet these skills are incredibly important in team software development–just as much as technical skills. Perhaps even more importantly, these skills are incredibly important to creating a successful Agile environment within the larger organization–especially one that doesn’t yet understand what Agile is and how it can benefit the organization.
Should the Agile Alliance focus on these skills, also? If not focusing, as an association, on introducing the larger organization to Agile, should it be paying attention to ways that the “front line” can successfully introduce Agile? If not, can there be much spread in the successful implementation of Agile Development?
I understand that Brian is trying to draw a line in the sand and say “We’re doing well in this area, so let’s concentrate on it.” I’m grateful that he’s trying to bring a clear focus. I’m just having a hard time seeing a hard line between the front line of developers and their immediate customers, on the one hand, and the larger organization in which they work, on the other.