by on

We are inept at perceiving the effects of debt, we grossly underestimate compounding factors and fall into a debt trap. Debt is tempting, it gives that edge to own things which is not possible now but only with the future effort that we can conveniently borrow and buy. There is a saying in Tamil, buying something in loan is like lighting a fire with borrowed hay but to repay it has to be paid in wood for same volume. If instant gratification takes priority then debt that needs to be repaid will hit us hard and bring us to a grinding halt. Corporates love debt, because with a lower cost of interest they will be able to create a high value output. This is where debt helps, if we are able to create something that is more valuable that can repay the debt with interest and still leave us with lots of money then debt is good.

Developers take debt analogy to code and create technical debt to get features fast to production, one major drawback is that most of us don’t understand monetary debt and its impacts well even though it can be quantified; but take decisions on technical debt which is difficult to quantify.

Let us have a look at an analogy, Neo has a trash can in his area that has to be cleared periodically. Clearing the trash can whether it contains little trash or full can of trash takes the same effort, so he prefers till the trash can fills up. The trash accumulates in a way that it doubles every day if not cleared. A new person Brio takes up the place of Neo, Neo explains that the first day only a gram of trash gets generated after clearing, but if left uncleared it doubles every day. He used to clear it every 10th day as it is around 500 grams by that time.

Brio observes that the trash piling up day to day is trivial to care about, around the tenth day he notices that trash is 500 grams and barely fills the can, he decides to come back 10 more days later forgetting the fact that it doubles. 10 days later what was a small can trash turns into an unmanageable heap of mess which is about 500 kilograms. The power of compounding is too easy to miss in the initial days, it will hit us hard who are used to linear maths.

Same is applicable for technical debts in an application. Tradeoff decisions have to be recorded and visited at frequent intervals to see if it is causing any harm than the convenience it provided. Technical debt also paves way for ‘Broken Windows’. Software development is a social activity, it will be very easy to make a broken window the new norm when code changes hands. Run your tech retrospectives; review code, design and architecture as an entire team at frequent intervals, that will help to manage technical debt better. Remember, it is not like corporate debt which is manageable by numbers.

by on

Requirements

Release planning is largely an empirical activity. Capturing the requirements effectively is the first step. Capture the thoughts of product owner or client in a free flow, map them to user journeys and fine grain them to small requirement statements. Each of these granular requirements which can be expressed in a sentence or two will be the basic building blocks of the final product. It is popularly called as stories and getting them right is the first step of a successful release planning.

Visual triaging

sticky-note-681016_1280

Write each of the stories on to index cards or stickies, preferably colour coded based on parent features and put them up on a wall or a large table so that you can see all of them at once. This helps to see the spread of the requirements and allows to dive into deeper details for ambiguous entries.

If the ambiguity does not resolve with deep dives we quickly get the developers to do a spike (proof of concept) to validate our understanding. The proof of concepts have to be very quick but deep enough to provide us an understanding to estimate the effort involved.

Sizing

When talking about sizing, people immediately try to force fit their stories into fibonacci series or arbitrary small, medium, large. Instead we need to create a real world analogy for sizing the stories as mentioned in one of my previous posts. The last few years I have been using Scooter, Car and Bus as my sizing references for stories; and as I expected most of my sizing meetings have shrunk to less than half of what it used to be when using fibonacci or t-shirt sizes. If you have outliers which do not fit in any of the categories we temporarily park that in a trailer or ship category if very large or in bicycle if it is too small. The outliers are revisited and the stories are rewritten to see how they can be fitted into the sizing slots. The very large stories always have been unpredictable and skew the time taken for a point metrics, so we have to break them before the end of the sizing phase.

Velocity estimation

Remove the sizing details from the stories, pick developers in a round robin fashion and let them pick what can be done in five ideal days. That is there are no meetings on that day, no holidays, high availability of all machines and tools, no dependencies.  The developers each should do around 5 iterations of picking stories and the result has to be captured like below.

Developer 1

Week 1 S,S,M
Week 2 S,S,S,S
Week 3 M,M
Week 4 L
Week 5 S,L

Developer 2

Week 1 S,S,S,M
Week 2 M,S,S
Week 3 M,S,M
Week 4 L,S
Week 5 M,M

When we collect all the developers’ estimate and average out, we will be able to come up with the ratio of S,M,L like 1:2:4 , 1:3:7 or anything but not necessarily fibonacci. If we had taken fibonacci there would be too many arguments whether a story is a 2 or 3, but we avoid that argument if we let the velocity estimate give us the ratio. The ratio then becomes the points for a size, if the ratio turns out to be 1:3:7 then our S is 1, M is 3 and L is 7.

Realism infusion

It is not possible to plan for work in ideal days; there will be meetings, holidays, sick time, vacations, down times etc. We need to account for those. If the velocity estimate which we can call it as raw velocity comes out to be 10 points per week then we deduct the appropriate numbers to get a highly probable velocity. Typically this works out to be around 70% of raw velocity but it purely depends on the teams.

Prioritization

Clients will always say that they want all the features they have envisioned, but there are many stories where an app ends up where most of its user use only the 20% of it, the remaining is a long tail with very little returns to the effort involved. The product owner has to come up with the must haves for an initial set of features. There are many popular techniques used, MoSCoW prioritization method is one that is frequently used. If there are many people who will prioritize then each of them should come up with their own priorities and the chief product owner takes a call with a common denominator. The explanation is simple but most of the clients struggle to come up with a prioritized list as the illusion is every thing is a priority.

Sequencing

The stories are sequenced against a weekly timeline put up on the wall or a large table. The stories are then picked up in the order of feasibility with priority given to difficult and important stories. This step will give us lots of options on the number of parallel streams of work that can be run, what are the dependencies between stories, the order in which the features can be completed, the team ramp up and ramp down plans. The kind of mix and match we can do depends on the granularity of the stories and the amount of dependencies between them.

After the last step has gone through few rehashing we will be able to come up with an initial release plan to start with, this plan should always remain as the reference and re-planning has to happen on a monthly or fortnightly basis to keep adapting to the learnings we get as move along. Many people treat the initial release plan as a sacred rigid plan but that was just a guideline to tell us how to approach development. It is a waterfall project if the initial release plan was delivered as is.

by on

sashimi-472778_640At a fine dining restaurant if I complained that I did not like the food; immediately the chef, waiter and the food taster run to the dining table to assure that I don’t feel disappointed and provide me an alternative as soon as possible. If you take a look behind the kitchen door then we will come to know that they take lots of precautions to make sure that this never happens at the dining table. Chefs have a tough time to keep taste and quality up to the mark irrespective of the availability of ingredients and limited time.

A typical restaurant is staffed with a chef, chef’s cooking assistants, butcher, waiters, managcook-196932_640er, janitors, food tasters and a lot of machines which speed up the process of cooking. Cook’s best use of time is spent cooking the food, but does it mean the cook should not get a feel whether the food is cooked and is it as per the customization the waiter described?

Let us a take a scenario where the manager is able to hire more food tasters and shifts the burden of the quality to the food taster. Cooks will be able to create lots of dishes as per the recipe given by the chef without giving a second thought about the balance of ingredients, texture and the level of cooking required. The dish will ready to present in a finished state when it reaches the food taster, if any fault is found then the dish had to done from the beginning which will increase the workload of the cook further and reduce the output considerably as the reworks are expensive, eventually will make the customer wait more or increase dining table incidents.

What looked like a clever idea on paper backfires as cooking for fine dining is not something that could be made into a template and responsibilities could be in silos; it is a complex system with a strong feedback loop at every stage. The scene at programming is similar at many cases, developers are encouraged to write only the code and leave the testing to the QA as the perception is that the best use of a developer’s time is to make her code. Seasoned programmers know better that unit tests are also code, if you are not testing then you do not know what you program.

Cynefin_as_of_1st_June_2014Programming is an emergent practice, which matches the complex domain in the Cynefin framework by Dave Snowden. Each project will be unique and a pattern will emerge over time which will be efficient for the team if there is a strong feedback loop. Trying to separate out of responsibilities like testing to just one small group will push the team into a cycle of code, test and fix with long feedback loops, eventually causing delays. Quality has to be assured at every stage of application development, responsiveness determines who is competitive in a complex environment.

Image courtesy: http://pixabay.com & http://www.wikiwand.com/en/Dave_Snowden