When we create a work artifact on software project, we usually create it with the understanding that somebody else will need to use it. The who, when, and where of that somebody has a huge impact on whether or we can consider our work “done” or not. To be done, we must determine if the work is Appropriate for the Environment in which it will be used.
Think of two teams: Team A and Team B. Surprisingly, both are working on the exact same product, using the same technology, and the same development lifecycle. Team A has been working together as a team for about five years. They are co-located and have deep knowledge of the technology and the customers.
Team B, on the other hand, is a bunch of new hires straight out of college. They still have not all moved to headquarters yet so most of them are telecommuting. Team B has a basic understanding of the technology and has heard of the customer.
Since we are working on the exact same product, etc. you might expect that they should produce the exact same work artifacts. In fact, you might be able take a work artifact from one team, substitute it for the same artifact on the other team, and nobody would notice.
Absurd you say? Rightly so, but why?
You point out that Team A can probably take a bunch of shortcuts that would be dangerous for Team B. Why can Team A take shortcuts? Because I made Team A different from Team B in the two areas that are critical for being Appropriate for the Environment: Competency and Distance. The more competent you are, the less detail you have to have in your communication to get your message across; the more distance, the more detail you need.
Competency here is not about how smart a team member is, it is how much knowledge they have about the technology being used and how much knowledge they have about the needs of the customer.
A student in one of my seminars was a great example. He was a PhD in Geophysics that went on to get a Master of Software Engineering. He was responsible to create software for other geo-scientists. During the seminar he stated that when he gets a requirements specification from the non-software scientists, he would scan it, ignore most of it, and build what they needed. His customers were delighted. Since he understood both the technology and customers needs, he would get the the gist of what they were looking for and could move forward.
Contrast that with a client in telecommunications which was outsourcing to Russia. The client would send a specification to the Russian body shop, Russia would code it to spec, send it back, and it wouldn’t work. Russia understood the technology but not the customer. The client put more detail into the next specification it sent to Russia but it came back with the same problem: exactly to spec but not useful. Only when they reduced the detail and sent a designer (somebody who knew the customer) with the specification did they get useful software.
As competency–knowledge of the technology and the need–increases, the need to put detail into communication decreases. Team A, with abundance of both, probably has far less detail in its project plans, specifications, and even code comments. Would it harm Team A to put all the detail in? Probably not directly but much of the detail would be wasted effort and may impact morale (taking time to produce not needed stuff).
Distance, a second critical area, can be measured in at least four dimensions. Physical distance, of course, but also time, culture, and team size. One of key lessons that organizations have learned with distributed development is the inability of work artifacts alone to solve the distance factor. For example, bringing the team physically together at the start of a project is considered a best practice by many companies. Leading companies invest in telecommunications and travel to deal with distance issues.
It is somewhat ironic that we see a rise in Agile programming practices with an emphasis on little to no distance in the team and at the same time a rise in distributed development (some outsourced) that has a high distance factor. Enter the somewhat oxymoronic “Distributed Agile”. Sure, we can bring collaboration solutions to help lower distance issues, but Agile at a distance requires higher detail in our work products than co-located Agile.
The size of the team has a distance impact. As the grows, it is more and more difficult for each member share a common set of information. While a team of 100 may be co-located on the same floor of the same building, it is unlikely that they actually share a common understanding of the work at hand. In a sense, the large number of communication links creates distance.
Both Team A and Team B have to deal with the last two critical areas of Appropriateness for the Environment: Criticality/uniqueness and legal/regulatory. If there is a law that says you must, well, there you are. Criticality/uniqueness is a bit more subtle. If the item in the work product is critical for success or is different than what we have done before, then it is worth the time to put in more detail. Leaving the detail out, even competent people may assume that it is business as usual.
An example was some work I had done to remodel a bathroom with a contractor. The contractor, assuming business as usual, had quoted and planned to install a standard 24” towel bar. I had to make sure it was very clear that I wanted three towel hooks (three daughters) instead of a towel bar.
To say a piece of work is “done”, we must consider if the amount of detail is Appropriate for the Environment. To do that, we must look at
- competency in the technology and the customer needs,
- distance: physical, time, cultural, and team size,
- legal/regulatory requirements,
- and the criticality/uniqueness of the item.
How do you determine the right level of appropriateness? That is far more of an art than a science. Often it is a matter of trial and error until you find the right spot. However, as a thought exercise and a discussion point, it can help you contextually determine when something is “done”.
Like this post.