Agile Development or how many balls you think you can juggle?

Most of the time, when people talk about project management, they only consider a phase between the official start of the project M1, and beta release date M2, as a “real work”. As explained earlier, this is a wrong approach, and you should avoid skipping very important preparation/workshop phase, which although sounds like a waste of time, is extremely important step in overall process.

We often associate this time frame with “busyness syndrome”, stress, heavy workload and stuff like that. In this blog post, I will try to make an overview of tasks that people should be doing in this time slot, and explain one way of organizing teams around various parallel activities.

But before I move on, I would like you to imagine the following:
You are the captian of the ship, and you need to get your guys from point A to point B in couple of months. On this journey, there will be some storms, troubles with a ship, and sometimes, issues with a crew. Before you start the journey, make sure that every crew member is good at something – and willing, otherwise, should not be on the ship in the first place. You need to explain the purpose and destination of the trip, and not to forget, what is the role and expected contribution of every person. During the journey, you will have the chance to adjust your direction at fixed time intervals. The actual length of one time interval will depend on the inertia of the system – the ship itself. Bigger the ship, longer the intervals. The end of a time interval (iteration or sprint) – is your correction point. At that moment, you position the ship for the next round, and till the next point arrives, the ship must go in the same direction. Once you reach the end of the interval, you adjust the path, and move on to the next point. Within one interval, nothing can disturb the crew – that is your task too. If you pictured this story right, this will be kind of zig-zag path journey, going from A to B. (If you are a guy that hates blog posts that are longer than few lines, you can as well stop here, that is all you need to know 🙂 )

And here we go, well almost….few more checks first…

  • First do your journey preparation as described before
  • Choose your iteration span – (you start iterating from M0, but you may as well decide later to have a different span between M0-M1 and the rest of the project lifecycle- although this is not a good practise). I personally prefer short iterations, fast feedback is always good (imagine taking shower and having to adjust hot and cold water – while the time between your action and the tap actually responding is 4-5 seconds – this is always fun, I had it few times). If you think you need long iterations (longer than 4weeks), you either manage a space shuttle program, or your processes are really lousy.
  • Decide on the branching strategy (see my post on the maintenance), and check this site  (thanks Joachim @joachimvda for the link) and awsome CRISP folks for one more great article.
  • Find a good build manager, setup jenkins, bamboo, git etc …
  • Find a good Test Scrum Master (this is something new, no?)
  • And fasten your seat-belt…..hmmmmm, i just realised I am on the ship actually, anyway …GO!!!

Juggling intro (now I am almost there…)
In all scrum books you can find something that is called “definition of done”. Idea behind this is that you don’t close the iteration till everything is developed and TESTED wiithin the same iteration. Some years back my test manager and I have decided to tweak this a little bit, by developing things in one iteration, and testing the same load in the next iteration, while dev guys would already work on something new at that time. If you have dev/test teams that are not on the same location – not even on the same continent (like it was in my case), this approach seemed more optimal to us. I also must say that this only works if your iteration are short. BTW, if you are familiar with kanban, this is exactly what I think these guys tried to fix as well (more about this in another blog post). One not that pleasant artifact of this choice is that the time between the code freeze and the time that the beta load is fully tested is also delayed by one/two iterations.

Finally, let’s do some Juggling!!!

Correction point C0: scrum kick off meeting (discussing/work split for iter1)

Iteration 1 (1 ball):

  • RD guys develop new stuff in ITER_1

Correction point C1: scrum kick off meeting (demo’s iter1, work split iter2), the current load is labelled (LAB_1) and handed over to the test team

Iteration 2 (3 balls):

  • RD guys develop new stuff in (ITER_2)
  • TEST guys test load (LOAD_1)
  • TEST guys fire bugs against LOAD_1

Correction point C2: scrum kick off meeting (demo’s iter2, work split iter3, assign issues of iter1), the current load is labelled (LAB_2) and handed over to the Test team

Iteration 3 (4 balls):

  • RD guys develop new stuff in (ITER_3)
  • RD guys fix bugs from (LOAD_1)
  • TEST guys test load (LOAD_2)
  • TEST guys fire bugs against LOAD_2

Correction point C3: scrum kick off meeting (demo’s iter3, work split iter4, assign issues of iter1,2), the current load is labelled (LAB_3) and handed over to the Test team

Iteration 4 (5 balls):

  • RD guys develop new stuff in (ITER_4)
  • RD guys fix bugs from (LOAD_1, LOAD_2)
  • TEST guys test load (LOAD_3)
  • TEST guys fire bugs against LOAD_3
  • TEST guys validate tickets from (LOAD_1)

Correction point C4: scrum kick off meeting (demo’s iter4, work split iter5, assign issues of iter1,2,3), the current load is labelled (LAB_4) and handed over to the Test team

Iteration 5:

  • RD guys develop new stuff in (ITER_5)
  • RD guys fix bugs from (LOAD_1, LOAD_2, LOAD_3)
  • TEST guys test load (LOAD_4)
  • TEST guys fire bugs against LOAD_4
  • TEST guys validate tickets from (LOAD_1, LOAD_2)

Correction point C5: scrum kick off meeting (demo’s iter5, work split iter6, assign issues of iter1,2,3,4), the current load is labelled (LAB_5) and handed over to the Test team

Iteration 6,7,8 ….

For simplifications, I have omitted few more tasks , such as:

  • Bug fixing of the issues of the previous releases (if you have them already out)
  • Validation of these issues in the next maintenance load that goes to the customer
  • Automation work (by both test and dev team) on simulators, test environment etc.
  • Test document update (you need to keep use cases and test execution in sync all the time)
  • Support for the field issues (L3/L4)
  • Sales support …

This would be already 9-10 balls in the air after iteration4! Once you do so many activities in parallel, the best thing you can do is to split test and dev teams (yeah, I know what you will say about cross-functional teams, but this is not the same thing) and let the test manager do the same thing that dev manger does – organize test teams in separate sprints and let him become a “Test Scrum Master”, it sounds really cool!

So, let’s put all things together and write it this way:

COUT(“ARE YOU READY?”);
FOR(I=1;I<NUM_ITER+1;I++){
ALL(KICKOFF_I);
DEV(ITER_I);
DEV(FIX(FIELD ISSUES);
TEST(VALIDATE(FIXED(FIELD ISSUES)));
TEST(UPDATE TEST SPECS);
ALL(WORK_ON_AUTOMATION);
if(I>1){
TEST(LOAD_I-1);
TEST(FIREBUGS(LOAD_I-1));
if(I>2){
DEV(FIXLOAD(2..I-2));
}
if(I>3){
TEST(VALIDATION(LOAD(I-2)));
}
}
}
COUT(“THANKS FOR READING!!”);

In my next blog post, I will mockup one JIRA project and explain the same topic via dashboard graphs and greenhopper screenshots. 

 

Software outsourcing dilemma

For people who have read “World is Flat” it looks obvious that in the world of internet and crowd sourcing, starting software business in the so called “low cost” countries is a logical step forward. Since intelligence, expertise and ambition in people is not bound by race or political border, there should be no reason to believe that there is anything tricky about it. More over, as waterfall has let us believe, good upfront analysis, detailed documentation, proper planning, quality control and right process (CCMI, 6 sigma and similar) should secure our projects from failure. So far so good, and in the end of a day, this philosophy is what has made the call centers in India a great success.

In order to get to the problem, let me start with another book: “Black Swan”. In this book, Taleb not only talked about – well obviously black swans and how much he hates Gaussian and sees fractals all over the place, but he also explained very important concept of scalable and non-scalable jobs:

{next paragraph from novelist Karen Hancock blog}

Non-scalable professions are defined as those with a built-in cap on how much one can earn in pursuing them. A dentist’s recompense is directly related to the number of people he can see in a day, and that number is limited. A watch repairman’s income is likewise related to the number of watches he can repair in a day. Both examples require the worker to be physically present to perform the services they provide. Obviously this category includes all “regular” jobs that pay hourly or salaried wages. When you agree to the hourly rate or the salary, you are in essence capping the amount of income you will receive. Revenue depends on your continuous efforts in the job. This kind of work is largely predictable and, according to Taleb, not Black- Swan driven. They belong to a place he calls “Mediocristan.”

Scalable professions, on the other hand, are those which have no such cap, where you do the same amount of work for one person as you do for one million. Like, say, writing a novel. (grin) Other professions in this category would be entrepreneurial activities, scientific research, venture capitalists, stock traders, etc. The quality of your decisions is more important then the continuity of your efforts. These sorts of professions belong in the land of “Extremistan.”

“A scalable profession,” says Taleb, “is good only if you succeed.”

{end of paragraph}

So, you may wonder what these thing has to do with outsourcing in software business? Here is the funny thing, software business is by definition scalable business while outsourcing business is NOT!

On one hand outsourcing companies are looking to make money by having as many as possible people on the project, while people who owned the project are not only interested in the cost of the project (hopefully), but as well as in potential revenue that they can generate from their customers.

In general, there are two types of software projects, the ones in which the end customer is company that did the outsourcing (retail, governmental organization, banking industry)  – and they are called CDE’s (customer driven projects), and projects in which the end product is a software that the customer resells to the other party. Although it makes sense to go for fixed prices contracts in case of CDE’s, if you want to succeed in the scalable business – you need to be the best in the market, and next to good product strategy and good marketing, you also need to have great software developers.

Most of the big outsourcing companies in India create so called triangle model. At the top would be 1-5% of developers with 5-10 years of experience and they are paid rather well (actually these days their salaries are comparable with salaries in western countries). They are followed by up to 10% of less experienced developers followed by about 90% of junior developers. Salaries at the bottom of the pyramid are sometimes order of magnitude less than of the ones at the top. What customer of the outsourcing company would charge you is the average salary per head. So, one thing is very important to remember, the primary incentive of outsourcing company in this model is to add as many as possible developers to your project, since this is the only way they make money. Another very important feature of this model is that this model breaks if the best developers in outsourcing company work only on one project. As companies in India start feeling the pressure from countries like Vietnam, where costs are even lower, they would probably need to find a new outsourcing model in the future. In my opinion, one of directions that Indian outsourcing companies can take is to work on quality and go up in the food chain, which will eventually bring the prices up and have them compete with smaller agile groups in Europe and US.

Just check what Alistair Cockburn has to say about agile contracts on this link to see what is the dilemma that every subcontracting company has when it comes to software projects (and BTW if you have time read all his books and blogs, guy is just awesome).

In my next blog post, I will talk about my experience with Wipro – our outsourcing partner, and how we started probably the first outsourcing agile group back in 2003. This hard work turned into a great success for both of us and it is something that we are all proud of.