The Golden Middle: Just The Right Amount Of Documentation In our Loved Agile

You are here

BalanceLots of complaining is often heard all around all kinds of agile projects. It is mostly happening due the lack of proper documentation. The complaining, I mean. Scrum is great as it is because it allows for the properly working software to get into the market within a shorter range of time. And thus the nasty habit of not giving a damn about the documentation was born. Yet if all is documented properly the things may go even faster.

The catch here is that a properly working software is valued way above proper documentation. And that is a fine and working approach. Yet documentation still has its value and is not to be neglected. So how does one find the golden middle in all of this? Let’s look through some actual live examples. Thus all will be easier to understand.

Example # 1

Let’s meet with our team number Alpha. We have some experienced scrum experts on the team. How would the tester reply on your rational question that is related to the issues he might face due the documentation lack? He will be surprised with it. His only answer will be something of a ‘we are one, we are a unity’ sort. If he has a question he is asking his teammates. There is a business analyst on the tester’s right and the developer on the left. All is shared, code comes out practically bugless. Why worry about documentation at all?  Yet there is a slight uncertainty. Who is defining the systems behavior? What I mean is who is practically responsible for the software meeting business requirements? Everybody on the team? Highly doubtful.

Example # 2

Team Beta is different. There is less cooperation and the roles are more traditional. How will they manage the same issue? So let’s have a conversation with their tester and their analyst. The analyst guy will be showing us some documentation samples he’s already made. And it actually looks nice. So let’s transfer his designs into some tests, shall we? We’ve done all that and unfortunately found a huge issue. And some more details are required in order to test some function in a proper way it was meant to be tested. The data is not even close anywhere near the design. Some sample conditions that might actually matter a lot are nowhere to be seen in his use case. Then the analyst is saying that such kinds of things are never documented.  Yet the tester does need those? How does everything work on this team you ask? When a tester possesses these detail he is documenting them in his test design. That way he will be able of knowing when his tests are successful. Despite even the fact he is destined for lots of boring regression. Does that sound right to you? It just might.

Example # 3  

On the Charlie team the business analyst is accepting the fact that testers need more data. And is willing to grant them with it. But, there’s always a ’but’, the analyst is taking some responsibility of himself. He will be responsible for the whole functional system descriptions only. The developers are to decide on all relating to technical implementation. They are to add their decisions with the appropriate details into the design on their own. And the data is still incomplete. Testers are pissed. How’d that happen? All point out to the developers as the business side is constantly doing their fair share of the deal. There is just no actual process for the developers to be documenting their choices in a proper way. And we are back to regression. Lame.

All we see from the examples above is that testers do need a proper amount of information to do their job in a proper way. It does not matter how they are gaining that info, just make sure they are gaining it at all without any severe difficulties and you will have an even smarter software. Good luck!