Getting back to business, part 3: Plans

While last post was mostly about discussing various ways to ideally improve my current development methodology, this post is more centered on practical considerations. In it, I will discuss such important matters as what I am actually able to do and when I should do it. Another important subject wil be discussing what should be done with existing TOSP code and documentation.

How much would all of this cost?

In last post, four areas of improvement were discussed: feature design, implementation planning, progress monitoring, and everyday workflow. Let’s translate the suggested improvements into precise work patterns and wonder how much they will cost and which benefits they will brink.

  • Putting TOSP’s vision on paper is a one-time job, which can be carried out in a single week-end and is useful for future feature planning. Thus, it seems like a good idea.
  • Describing features in terms of UML-like use cases can easily take a week of useful work time, but user stories are lighter-weight, better-suited for planning purposes, and with appropriate INVEST precautions become just as efficient for formalizing what features are supposed to do. If stories can also be written in half a day, that would be a good cost compromise, since I rarely come up with features ideas faster than once per month on the average. Aside from the story-writing job itself, I’ll also have to come up with a quick and dirty story storage and prioritization system, another one-time job that shouldn’t take more than a week-end.
  • Multiscalar planning ranging from project-wide organization to everyday development, with intermediary release and iteration scales, is going to take more effort than the previous two tasks. It should, however, help dramatically with my current issue of losing willpower after about a month (since milestones are reached more frequently), and it could be done in a week if I keep at it. Beyond that initial work, updating the roadmap would be easier, and should typically be done in a day unless there is something special to take care of. As mentioned earlier, planning individual technical activities could speed up subsequent development, since I’ll have less stuff to do simultaneously, so it’s hard to evaluate the net cost of this measure.
  • Putting an efficient project monitoring system in place through a mixture of automated tests and regularly parsed check lists in another expensive task, because there’s a lot of code and written documentation to write. I’d evaluate its cost as one week to put everything in place, plus half a day at the end of each iteration to conclude on that iteration’s monitoring process.
  • As for work practices, they could be introduced iteratively over the course of a first iteration, at a regular pace. This would require another half day of initial planning to slice this up into small blocks of habit that can be independently learned and distributing them over said iteration.

If I take into account everything, the net cost of this would be two weeks, two days, and two additional days of management work per iteration, plus a slower initial iteration so as to put the new programming practices in place. Considering that I’m going on a two weeks long trip to India with my girlfriend in about two weeks, it’s not unreasonable : I can start with the heavy work in the remainder of these two weeks, then try to work on lighter tasks during the trip, at times where there isn’t much else to do, such as in night trains, when it’s my turn to keep our belongings under watch. By the time I’m back here, I should probably be almost done, or else something went terribly wrong with the previous duration estimations.

What am I going to do, starting tomorrow?

If the cost of the migration is acceptable, the next question is that of how, exactly I should do it. If I don’t have some kind of detailed checklist of what’s to be done and what’s already done somewhere, it’s kind of hard to figure out how far I’ve gone. So here is a TO-DO list proposal on that front:

  • Write a project vision that fits in a small paragraph (so, around 50 words at most) and meets the criteria defined earlier. (Done, 18/04)
  • Start to write some sort of Excel file that will act as a project management tool and user story storage area. Begin by writing TOSP’s name and vision on top of it. The point of using spreadsheet software here is to easily add automatically computed quantities (a possible candidate being task priorities or “total time” indicators) without sacrificing visual organization. (Done, 20/04)
  • Add a structure for storing user stories, in a two-level hierarchy (top-level goals and finer-grained descriptions). It should provide a way to store priorities, value, cost in work hours, and risk levels, along with functional tests and where each story is currently assigned. (Done, 20/04)
  • Copy the “INVEST” criteria for user story evaluation in a safe and easily accessible place, preferably in the aforementioned document, alongside the project vision, since it serves a similar role of ironing out user stories. (Done, 20/04)
  • Write a project-wide plan, by giving myself a realistic time budget for taking TOSP somewhere and coming up with a range of high-level user stories (such as “I shouldn’t have to worry about where my data is”), which will be stored in the aforementioned user story backlog. Give those imprecise value/cost/risks evaluations too, even if they are to be updated later, so as not to get too easily carried away into planning more than I can actually do.
  • Define milestone releases (3 months?) within that project-wide timing, and roughly distribute high-level stories across them.
  • Start to define the first milestone release by breaking up its high-level stories into finer-grained chunks, evaluating the value/cost/risk associated to it, and distributing them across three weeks long iterations.
  • Make a separate sheet in the aforementioned story backlog for technical tasks. It should allow storing expected delays, actual time spent working, tests, and qualitative observations for other stuff such as risks.
  • Put an easily accessible burndown/burnup chart at the top of that page which represents how much work has been done and how much work is left versus how much work was expected.
  • Perform technical planning of the first iteration.
  • Define coding goals and the pace at which they are to be introduced in the first iteration.
  • Publish the project backlog in the Github source tree + adjust blog widgets and/or Github wiki to reflect the new organization (with e.g. quick access to these “Getting back to business” posts, and perhaps time counters for iterations and milestones too since those are easy to set up in WordPress).
  • Start coding, and hope this new project management methodology will live up to my expectations!

Conclusion

At this point, I think that I have a good enough plan to get the migration to that new management style going, and no time to waste if I want to have it almost done by the time I’m back for India. So, without much ado, here I go!

2 thoughts on “Getting back to business, part 3: Plans

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s