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:


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


Leave a Reply