What is the problem anyway?

The major documentation question asked:

If we do not document everything, how do we know we’re going to get what we want before, and how can we verify that we got the right stuff after doing the project?

Of course the question implies an answer:

If we document every aspect of the project thoroughly up front, we know what has to be build before starting the work and we can easily verify whether the product delivered met the original requirements.

The problem of course is the answer was already implied in the question!

Types of documentation

In my humble opinion two types of documents live within the (software) project realm, no more, no less:

1. Documents needed for all team members to work on the project.
2. Documentation to be shipped with the final product.

Let us explore these two types and try and figure out what needs to be created, when and to what depth.

Documents needed for all team members to work on the project

In an ideal world we would like to hand over all work from one person to another by direct communication; talking to each other, preferably in the same room. There are however plenty of situations where it is more convenient or better to document something. Be it whether we have to transport knowledge through time and space, we need to write something down, because we tend to forget, or maybe writing something down just helps the thinking process.

However, at some point in time we, the software industry, started confusing these kind of work documents with documents that should ship with the product. Hence the weird Idée fixe that functional & technical design documents should be made in line with the actual product developed after finishing the project. When questioning people as to why they want to do this, the most common answers contains arguments like:

• We need to know what was build
• For maintenance purposes
• When something doesn’t appear to work, we need to see how it was originally intended

All of these reasons are bad reasons to try and maintain some big fat document that was created for the sole purpose to communicate what to build in the first place. After finishing a feature and having shipped it to a production environment, any document which was created during the building process with the intend to support this process has become obsolete!

How do we know what was build?

simple, look at the product in the production environment!

How can we do maintenance without documentation?

Any document needed to do maintenance should be created as a part of the shippable product. However this is not the same thing as a design document! Most software a) has a not-so-very-long life span (5 year old software is pretty old), Modern day programming languages make it doable the create readable and human understandable software, thus lowering the need to create separate documentation (the code is a large part of the documentation). The important thing here is to determine what kind of documentation is really needed to do maintenance. Find the stakeholders and talk to them! In my experience there are usually a few architecture diagrams and some supporting tables that are used, but most of the describing text is never (ever!) read.

How can we find out what was originally intended?

Well … this isn’t really important now is it? When some product is being used in a production environment, the only relevant question is: Does this software fulfill our needs. If not, what do we need to add or change to the current working product!  Any debate about what was originally intended is a waste of time.

Apparently we humans have this strange urge for others to acknowledge we were right, before we move on to the part were we can actually work on a solution. It is just so refreshing when you let go of this urge and right away go for the core question; Do we need to make an alteration to the system?

As soon as you accept that documents that are solely written to support the product creation process are to be disposed of as soon as the project is finished and the product is delivered, you hopefully also can start resisting the urge to make any such document over complete and 100% correct! This is exactly why writing documents is such a time consuming (and therefore expensive!) task. Once you accept that you just need to write down just enough to convey your message or to support your memory, you will also understand that pen & paper, photographs of whiteboard drawings, scribbles on the back of a coaster, story boards, etc. suffice for these purposes!

Documents that ship with the product

Depending on the product, the customer, install base, etc. etc. there will be a need to ship a certain amount of documentation as integral part of the product. Typical examples are:

• User manuals
• Deployment manuals
• Maintenance manuals (intended for operating the software)
• Technical documentation (intended for maintaining the code base)

What types of documentation should be shipped with the product is to be established long before declaring the product as done. After all, the product is not done before all parts of the product to be shipped are done! So typically you need to agree what documentation to ship with the product before starting to build. (Especially when in a client-vendor relationship).

When you’ve agreed on what documentation the product should ship with, you can still be creative as to the form of the documentation. You can write lengthy user manuals, or you could use more 2.0 techniques like screen casting to record the documentation. The latter is generally cheaper (statistically about 10 times cheaper!) and more like likely to actually be used.

Whatever the documents to be written in your project, please stop confusing work documents needed to support the process with documents as an integral part of the final product.

After some time, most organizations will get the concept of multi-disciplinary teams. The advantages of having teams consisting of designers / analysts, developers and testers become apparent pretty soon after trying this. Total project time goes down and quality of deliverables goes up. Of course having multi-disciplinary teams makes resource allocation much simpler than doing it the usual waterfall way where the developers could not start before the designers were done and the testers should be allocated after the developers did their thing. Nowadays, doing it Agile, all disciplines can be allocated about the same time for much of the same duration!

But … there are projects out there which are doing Scrum in a cool and multidisciplinary environment, (so far so good); however, from time to time they need a specialist to do some work for the team. Such a task is specific in a manner that no one on the team has the skills (or authority!) to perform the task. An example could be that you need someone with knowledge about some (legacy) system to interface with. Ideally you would want one or more team members to learn that skill. In reality though, this is just not always feasible, e.g. would require expensive training for just a few tasks, interferes with another department’s turf (!!!), etc. . .

There are several ways to handle this organization wise.

One option

just “loan” the specialist to do the task at hand and give him back to his normal department / job after the task is done. This option has the advantage of the specialist being distracted from his or her normal job the least while the team can continue with the other, “normal” team tasks, in the mean time. There are some drawbacks though:

1. Resource allocation!

   You might get a resource allocation problem since the specialist’s main responsibilities are in his / her day-to-day work. This would introduce a major and maybe even reoccurring impediment for the team, since the specialist is not always available to do work for the team when required. This problem can be dealt with by reserving some time in the specialists “normal” schedule, so helping out another team doesn’t conflict with his / her day-to-day tasks. Another thing is to try and identify the specialist task well in advance (maybe even a sprint in advance) so the required time can be allocated.

2. Is the specialist committed (enough)?

   Another risk is that the specialist is not as committed to the projects results as are the other team members. The commitment problem should ideally not be there at all, since all people within the company hopefully share the same company goals. It would be obvious that the project results contribute to the company’s results, thus anybody committed to the company results should be committed to the project results. Note that a lack of commitment usually is a result of people being called on not getting “their own” work done and / or do not get credit for lending their specialist services to (other) projects. So this can be helped by freeing up some time to help out your colleagues.

3. Task switching is a major form of waste!

   As most of us know: task switching consumes lots of time and should be avoided as much as possible. Therefore: try a save up several tasks for the specialist which can be done sequentially. You won’t avoid task switching all together, but at least you can try to minimize it.

For this option you’ll have to make very sure all prerequisites for the specialist’s task are met before the specialist starts. In general people find it very annoying having to lend their services to a team when the task is not yet completely outlined.

Another option

Add the specialist to the team for one or more sprints. This requires the specialist to be exempted from his normal duties of course, but immediately gives him the much needed focus to do the job right. Biggest problem with this solution is: who’s going to do the specialists “normal” job while he is busy helping out with the project. Usually this is something that can be worked out with other specialists or a department manager just fine. As long as the period the specialist is unavailable for normal duties is not too long and plan able.

Overall

For both options it is best if the specialist can work in the team-room for the duration of the task / sprint. This encourages communication, minimizes distractions from the “normal” job and gives the specialist the feeling of being part of the team.

Whatever for you choose, make sure to evaluate it! During retrospections and other feedback moments, find out whether the chosen solution works for both the team and the specialist and find out whether you can improve on it. You might find that some skills can be learned by the “regular” team members after all or you need more of the specialist’s time so he / she can be added to the team.

Conclusion

in some cases it is just unavoidable that you need a specialist to do some tasks that the “normal” team members are just not trained for or skilled at. I like the solution best to add the specialist to the team for one or more sprints until the specialist job is done. But loaning the specialist for the duration of the tasks at hand can be more practical when there is just not enough work for the specialist to fill a sprint.

Beware of task switching though! It is one of the majors forms of waste!

To answer the question we will have to establish a definition for both. Let’s start with impediments. Assuming we’re doing Scrum as a way of getting the work done, an impediment is everything that slows down work or stops it completely. In other words, impediments are obstacles that have a negative impact on the sprints’ velocity. Typical examples include missing or incomplete information about a certain user story or the lack of tools or hardware required to complete the work.

Risks on the other hand are possible events that, if they do occur, have a negative impact on the desired outcome of the project. Of course this includes events that impact sprint velocity, but are not limited to this. Negative impact can also mean some event causing a lack of performance in the final system to occur. For example, we assumed to be able to use a certain hardware platform to get the performance we needed, but the risk exists that the intended hardware just will not deliver the promised speed.

Note that something that is sure to happen (and has a negative impact on your project’s outcome) is not a risk, but a problem! Problems always have to be dealt with, so put the required actions on the backlog. Dealing with problems is more like crisis management and not risk management. Whenever a risk materializes it has become a problem. Any mitigation work, required to handle the situation after a risk has materialized should also be put on the backlog.

The most important difference between risks and impediments is that risks are possible events and obstacles that could occur and impediments, in general, are already reality.

Now that we have established that there is indeed a difference between impediments and risks, we can now answer another question: “Why manage both and not just the impediments?”. Management of both impediments and risks is very important. Managing your impediments is pretty obvious; these are obstacles which are already upon us. The team is experiencing some sort of blockage which stops them from achieving maximum velocity. So removing these obstacles should make work go faster. This minimizes the risk of not meeting deadlines for major milestones or even the entire project.

Acquiring and managing risks is just as important as managing the impediment list. Although risks are not problems yet and may even never materialize, it is very important to know which risks there are and what you are going to do about it if and when they materialize. By determining both the impact of a risk after it should materialize and the chance it actually could materialize you can determine how important it is to manage a certain risk. You could choose to take actions to prevent the risk from happening (removing the risk) or do some preparation work which helps minimizing impact when the risk materializes. Note that some risks are just not worth preparing for. For example: If a space shuttle should crash on the building your team is working in the project will most probably fail, the chance if such an event happening however is close to zero, so you do not want to waste valuable resources in managing this risk. On the other hand, the chance that any team member comes down with the flu is very real. The impact is a delay in your project. If this is not acceptable you will have to do something to minimize impact when this risk materializes, such as overstaffing or adding more slack into sprint planning.

In Scrum the ScrumMaster is responsible for creating, maintaining and working the impediment list. The ScrumMaster is responsible for getting the items on the list resolved. Note that he/she is not solely responsible actually resolving the items, but at least should convene impediments with someone who actually can resolve that impediment.

Managing the risks could be a job for the ScrumMaster too, but as the project gets bigger or spans more than one team, there should be a Project Manager involved. It is then his/her task to get possible risks identified and manage the list. This is not the responsibility of the ScrumMaster since there are risks that supersede the span of control of one team. Next to that, the ScrumMaster is probably busy enough working the impediments, without having to worry about and take action to prevent things that could happen.