In This Issue
- Adding a New Agile Team Member
- Book Review: Smart (Enough) Systems
- Hot Links
Adding a New Agile Team Member
Throughout 2007 I spent a lot of time running workshops on how to scale agile software development practices to meet the real-world needs faced by modern IT projects. Documentation is always a popular topic of conversation, and invariably someone makes the claim that one of the reasons why IT teams need to write comprehensive documentation is to ensure that new people can be easily added into the team. Although the desire for documentation appears to be a fundamental tenet of the traditional software development religion, the fact is that documentation is an incredibly poor way to communicate information and it often hinders more than it helps you. Yes, new people can be assimilated into your team without the crutch of excessive documentation.
First, let's consider the traditional approach to assimilating a new team member who will be henceforth known as "the newbie". Although every organization will be slightly different, the general pattern is the same: You first cover the important things with newbies -- where's the coffee, the restroom, and their work area. Then you take them around to everyone's desks to introduce them, or if you're "lucky" there will a team meeting where you can do all the introductions at once. The newbie promptly forgets almost everyone's names, everyone knows this is happening, but they'll either pretend it isn't happening or make a lame joke about it. Then one or more senior people take the newbie aside and do a quick overview of the project, often a discussion around a whiteboard where you sketch out the architecture and business need(s) being addressed.
The next steps are to provide the newbie with a mound of documentation (really advanced firms have this material online, although new hires likely won't have access to it yet), banish them to their cubical for several days (or sometimes even weeks if you're still trying to determine what their actual role on your team is), and tell them that you're available to answer any questions they may have (this appears to be nice on the surface, but in reality you're doing little more than giving them false hope because they'll never be able to find you between meetings). At this point the primary goal of the newbie is to stay awake at their desk as they pore through the documentation and their secondary goal it to try to learn something from the morass of information provided to them. Sadly, the documentation will not only prove to be contradictory but also out of date, and because they're not familiar with the system they won't be able to easily determine which information is pertinent and which isn't. The final step is to assign the newbie a straightforward but relatively insignificant task to work on in order to gain some initial experience and to allow them an opportunity to hopefully identify how the system sort of actually works.
Okay, to be fair that's a bit jaded, not to mention Dilbert-esque, but it's not far off the mark for many organizations. In traditional project teams comprehensive documentation is used as a crutch in assimilating a new team member, just as it's used as a crutch in other aspects of the traditional software process. Agilists prefer to do better.
With an Agile approach you'd still need to cover the basic logistics and introductions to the rest of the team. However, because of the greater level of collaboration and teamwork on Agile teams the introductions should go a bit smoother as you'd simply dovetail into the normal daily communication routine. From this point Agile teams prove more effective at assimilation.
As with a traditional team you'd want someone to do a walkthrough of the current scope and architecture of the effort. Where the Agile team would differ is that this can be anyone on the team, not just a "senior person", because of the greater knowledge that Agile team members have of the project. When you adopt the strategy of non-solo development with Agile practices such as pair programming and modeling with others, when you swap pairs regularly, and when you adopt concepts such as collective ownership where everyone on the team can potentially work on any work product, then you find yourself with team members who have a much greater understanding of what they're working on. Of course with you apply Agile approaches on large teams then the detailed knowledge that people have will often be at the subsystem level because you'll have organized your team into smaller subteams, although in this sort of situation you'd be bringing a new person onto a subsystem team anyway. Because of this greater working knowledge that people have a common strategy is to have a relatively junior team member, perhaps the previously newest member of the team, pair with a senior person to do the walkthrough. This not only gets the job done, it tests that person's knowledge and provides an example to the new team member of someone who recently went through the learning process.
The next step on the Agile assimilation process is to have the new person pair with someone right away to actually work on implementing new functionality. You want to bring the person into the team as quickly as possible, and the best way to do that is to actually get them working with the rest of the team. The first week or so the more senior people on the team will volunteer to pair with the newbie as they'll need a bit of hand-holding to learn the development environment. Most Agile teams swap pairs regularly, this is called "promiscuous pairing," so that knowledge and skills are spread throughout the team widely. For new people the implication is that they'll not only learn the environment quickly, they'll also build bonds with other team members quickly, streamlining the assimilation process.
I believe that the Agile approach to assimilating new people into the team is more effective for several reasons.
- First, it's very attractive to the newbies because they can become productive fast, usually their most important goal.
- Second, this approach has a very low impact on the existing team because the newbie is dovetailed into the existing environment easily. Yes, it's a bit tough if you bring several people into the team all at once, but then again this is a tough situation with a traditional approach as well.
- Third, it removes one of the primary reasons that people use to justify overly comprehensive documentation.
- Fourth, it provides a viable strategy for handing a system over to a maintenance team because you can bring members of that team in towards the end of the development effort as you migrate existing team members out. This avoids an end-of-lifecycle handover where you risk losing important knowledge.
When you need to bring up a completely new team all at once to take over development of an existing system you've got a serious problem, regardless of the strategy you've taken. The Agile approach obviously won't work because there's no one to with existing knowledge to pair with, and the traditional one won't work because of the difficulty of wading through comprehensive documentation which people are likely to assume is out of synch with the actual code. However, all is not lost. Agile teams make it a practice to write high-quality working code, to have full regression test suites, and to write concise overview documentation to address the issues which can't be captured easily in executable specifications. Compare this with the mid-level quality code produced, the spotty test coverage, and the detailed documentation by typical traditional teams and you can quickly see that at least the Agile teams have minimized this risk. My advice, of course, is to not get yourself into these sorts of situations in the first place.
Traditionalists will justify extraneous documentation on the false assumption that new hires need detailed documentation. Given the choice of reading detailed documentation and becoming a working member of the team right away, most newbies would prefer the latter. Perhaps the only real advantage of comprehensive documentation is that you can sideline a new person long enough so that you can figure out what to do with them. If that's the case, perhaps you should consider fixing your human resource (HR) process challenges instead of covering them up with a documentation band-aid.
Book Review: Smart Enough Systems
Smart Enough Systems: How to Deliver Competitive Advantage by Automating Hidden Decisions, by James Taylor and Neil Raden, describes a vision for how organizations can become more competitive through using technology in new and innovative ways. Yes, I realize that this sounds like some sort of 1990s, business reengineering cliche, but the fact remains that this is a good book for anyone interesting in the business implications of modern IT technology. A "smart" organization is one that is high performance in execution, customer focused, data driven, real time, loosely coupled, focused on learning, and agile. That's agile in the business sense as well as agile in the IT sense of the word. The authors bring decades of experience to bear to describe enterprise decision management (EDM), which is about learning broadly, deeply, and quickly through feedback provided by "smart enough" systems that implement critical business rules in the support of timely decision making.
The book is organized into an introduction and 11 chapters:
- Introduction: The Smart Enough Systems Manifesto
- The Need for Smart Enough Systems
- Enterprise Decision Management
- Why Aren't My Systems Smart Enough Already?
- Core Concepts
- Data and Analytics
- Business Rules
- Adaptive Control
- Readiness Assessment
- Getting There from Here
- EDM and the IT Department
- Closing Thoughts
The rules of modern business have changed, and our strategy must change with them. We're now outsourcing more and more work yet we don't want to lose our core IP and we must still conform to local regulations. As organizations move to service oriented architecture (SOA)-based approaches they must do so intelligently -- having the "same old same old" implemented in a new manner isn't going to add much value. Smart Enough Systems is for senior business leaders as well as senior technical people, particularly any IT person in lead roles implementing key systems within your organization.
Hot Links
The concept of generalizing specialists is described here.
Best Practices for Agile/Lean Documentation describes 18 best practices for improving your approach to documentation and specification on software development projects.
In Communication on Agile Software Projects I examine various communication strategies that you can employ on a software project. You have more options than you think.
I recently started blogging about how to scale agile software development to meet the real-world needs of modern organizations.
The Agile Alliance homepage is the best starting point for anyone interested in
The Agile Models Distilled page provides links to overviews of a wide variety of models.
The Principles of Agile Modeling v2 are described here.
The Practices of Agile Modeling v2 are described here.
Check out the Agile Modeling mailing list here.
