This is the second part of my own agile development methodology (you should have part 1/3 fresh in your mind before reading this one). Actually, it’s more about some tips on provisionning / allocating time on different work phases to avoid bad surprises than a real methodology.
Refining and provisioning (non-)production time
I try to pre-allocate tasks inside the 2,5 production days of each iteration as much as possible. Given the subject I’m working on, I will encounter more or less non-productive tasks (much better understood as non-coding, as I’m a developer). Some of them will even prevent me from coding, if I don’t foresee them before needing to do them.
- if the functionality I’m working on touches anything visual, I will provision time to interact with graphist/web designer/ergonomist. Time for integration must also be kept in mind, if I’m not responsible of that part. And of course time for discussions and tests with final customer. This is not the same time as PM time, which is only used to brief/report/prioritize globally on the project and tasks. Here it’s about (co-)working on the tasks themselves.
- If the subject is functional, as opposed to technical or internal, I will provision time for the customer to be able to test it. I’m talking about batcher processes or automated programs that embody my understanding of the customer’s own job. The code itself can have no interface at all; if I misunderstood something, I will certainly have to alter code. The customer could want to (beta-)test it IRL and I will encourage him/her to do so. This time must be taken into account: the customer will report bugs directly to me, and I will need to listen to him/her, reproduce the bugs, track them on the bugtracker myself, etc. It can easily multiply what I initialy thought by a factor of 2. Again it has nothing to do with how great my code is, but how well I understand another person’s job and how easily I can put myself on his/her seat. There are many approaches, regarding time pre-allocation:
- either you provision twice what you think you’ll need. You can provision more, given your knowlegde of the customer and the test procedure itself. This is very hazardous: it relies on luck. There is a substantial risk that you will spend more time than you expected. One of you or your customer (or both) won’t be happy in this case: you will loose time, delay the release, and probably loose money. The customer will certainly not enjoy the new delay, or the supplemental money he’ll have to spend. The problem is not the delay or the money. It’s the previously-unknown or unanticipated state of the situation. This is felt as “ not-under-control ” for one or more of the actors. It will slowly erode the customer’s trust, increase his/her pressure on you, and possibly hit your self-confidence or health, if happening regularly.
- or you could just tell the customer that the estimated time takes only one final rendering/test in account. In case he/she is not satisfied with the result, more time will be needed. For the customer, knowing it before has a better satisfying strength. And thus on you, too, because everyone is more relax (in a relative manner ).
Thus, everything here is about anticipation. And communication with your customer. Be pro-active, talk with others, plan, retro-plan, even informaly. This has nothing to do with code, talent nor money. In fact, this is just common sense. A bunch of others have already wrote about it. This is nothing new nor magic.
- If the functionality depends on some special values or is an import script, I will provision time to spend on duplicating the production data or importing it. Test data (250 records) is a good start. But even if it imports correctly, this doesn’t ensure the next 1M records will. Given the data size, importing can take long. Knowing the size of the real data is essential. With Gb of data going via an XML-RPC tunnel in a single-core process, 30 minutes of import are not negligible. Given the time spend on writing the import function(s), import duration will limit the number of tests I can achieve in 2,5 days! Again, anticipation and data gathering are the keys, even before starting to do anything on my keyboard.
- Some other functionalities needs interactions with external partners. A supplier I/O flow is the perfect example. Does the supplier have a working test environment? A File-format documentation? Don’t smile: some don’t!! They will need time on their side to set things up, or check they work. Coding super-fast won’t help me at all on this particular point. Anticipation will. Ensure everything is OK on the external side before you start. Then your schedule will be better known. You’ll have much stronger confidence. Your customer will trust you more.
- I won’t talk about other tasks, like sysadmin. It’s obviously the same idea, eg: the recipient machine must be setup for the deployment to be successful. If I need to set it up in the middle of a code run or just before deployment, this would be OK in some cases. But it will still prevent me from beiing efficient in most. It will halt the run for a moment and force me to switch and concentrate on different tasks more than necessary. This is waste. OK, not a big deal. But when you’re alone assuming different metiers, 5-10 minutes of switching 2 times a day is more than one hour wasted at the end of the iteration. One hour is valuable: it’s 2 pomodoros, if you know about it. For me, this hour could have been used to code; or rest, contributing to good health. And finally make a better job.
I do all this pre-calculations during PM time, during the first day of my previous post. It takes times to do it right. One day, considering what I already include in it, starts to feel a little short for all of this. But this really helps coding straight to the point. Even with that, we have many other external reasons to fail. Don’t rush.
I’m a coder. I love coding. But I spend nearly more of my working-time not coding. Strangely, this allows me to produce more and code better. And I feel perfectly fine with this