The N+1 Iteration syndrome

I constantly ask myself if i know what is next at the end of a sprint or iteration and that I should make an effort to know what is coming up next, I observe that just like me the members of the team are only focussing only on the card that there magnet is on in the current iteration. Adapting to a constant flow of user stories and requirement is not easy for any team and is as important as focussing on the stories in the current iteration. We as a team focus on the user stories in the board, but it may be worthwhile asking ourselves how many people in the team are really aware of what is coming up in the next iteration. If members in the team were asked to answer to this question honestly you will find that a vast majority probably don’t have much information or are totally ignorant. I prefer the term N+1 for the next iteration. In most teams I have worked this is a problem that is evident in one form or the other and some common symptoms I find are the ones mentioned below.

Symptoms

• Analysts find it frustrating that they have to repeatedly read the story out and explain the same story more than a few times.
• Team velocity sways massively and the standard deviation to average velocity is quite high
• Requirements workshops are almost absent and it seems like analysts are in a different time zone on the user requirements on most occasions when compared to the team.
• Team members are not sure about the size of the story and try to come up to a size as close as possible to the rest of the team rather than putting any effort involved in understanding the size of the story.
• Constructive discussions, debate and any implementation concerns are almost absent
• The team seems to easily agree on the size of the story and gets swayed into a conclusion by anyone who can speak the team into a conclusion
• Large stories seem to be finished earlier than they ought to be and some of the smaller stories seem to take more time and some times end up looking like large stories.

This syndrome manifests itself in different ways and consequences range to varying degrees of severity on the functioning of an agile team. The team should address this situation if they do find these symptoms, the effects of not addressing this problem could result in false velocities, skewed metrics, increase in cost of the project and finally manifests itself in a loss of trust from the users for whom we actually work on the project. I wonder if I am making a big deal out of this, but this may be because I perceive the consequences of this syndrome to grow exponentially into bigger problems and can be quite damaging for the future of the team and the project.

We can mitigate some of these symptoms, a few ideas that allow you to improve and move in the right direction are below

• Introduce a N+1 sprint section on the left and side of your Kanban or sprint board and line up stories that will flow into the next sprint.
• Encourage analysts who are working on N+1 Q to speak about there analysis during your stand ups, this helps spread awareness of the N+1 iteration on a daily basis. Truth is in an iteration the analyst is probably working 50% of their time on the N+1 sprint and the other current sprint.
• Encourage your team members to pair with analysts and discuss and learn what they are working on, if you can allow your developers and QAs to pair for 5% of the iteration on a rotational basis with the analyst. These pairing sessions really helps non technical analysts to learn a few tricks and understand why you would think the story is complex or simple
• Have mini 15 minute sessions every day after the stand up to pick up one story from the N+1 board and discuss with the analyst, testability and implementation details. This will mitigate the loss of requirements workshop they are long and can be boring anyway , small cycles of these sessions will get the team to be constantly involved in requirements.. the term cross functional teams was not coined just for developers and QAs , it did mean all functions in the project.
• Have some ground rules for your planning session,
  • Team comes attend the planning session with an awareness of the stories flowing into the Kanban,
  • You really don't want estimating to eat up all your planning time, clearly planning is not only to estimate it is also about discussing priorities and setting goals for your iteration, spend some time planning how you would action retrospectives as well.

You will see that the team will at least loose the perplexed “I don't know what you are talking about look “ and the “I cant be bothered” attitude , this could be a good starting point to address the problem. This will allow your team to be more involved in planning as much as they are involved in the progress of the sprints.

Pair Usefully and Code Effectively

Pairing is of real value when two developers work with each other in a such a manner that they allow the other person to teach and learn new ways of working. This mutual learning process will ensure that the competency of the team will grow uniformly. In my current job we almost never work alone we always pair. Recent retrospectives have been focussing on how we get the most out of our pairing sessions. Some developers said we don’t swap pairs enough, there were questions about how and when do we determine it is a good time to swap pairs.

Well there is probably no hard and fast rule on pairing but some of the things we seem to recognise in a team are as follows.

1. Story Champs - A story owner or champion should be present on the story who will see the story go through the board

2. Story Progress - Having a story champion will allow you to swap pairs across a story reasonably well without affecting the progress of the story.

3. Keyboard Policy – More often than not this is a reason for frustration among developers in a pairing session. Use TDD to pair effectively.

Eg. Pair made of Dev A and Dev B.

• Dev A writes test to fail – Red
• Dev B implements code to pass the test – Green
• Dev A refactors the code

Alternate between the devs in this cycle will ensure pairing sessions are not driven by just one dev

4.Pairing Overdrive - If at any point during a pairing session one of the two seem to be dictating code for more than a few minutes ( I call this overdrive mode). You should really stop pairing and determine if the pairing session is useful and how it can be made useful , the dev who is on overdrive mode should really take the initiative to bring his/her pair up to speed on the story they are working on and discuss any gaps in each others understanding.. get away from the computer go for coffee break.. really helps.

5. Check-in frequency – When we pair due to reasons beyond our control one of the two dev may have to leave at any time before the other, frequent check-ins will allow you to make sure your CI is effective and also that you can switch machines quickly and effectively.

6. Computer Policy - if a pair is working on machine and dev who owns the computer has to leave, the other dev should be able to continue working on the story ..In such a situation it helps to leave the computer unlocked till your pair can make a check-in and then pull the changes on his computer and continue work, locking your computer and leaving could really be annoying to some one who really wants to continue work.

7. Early Birds –If you come in earlier than your pair, instead of just picking up the story and continuing work it helps to look at your CI server and fix any broker builds. If you do work on the story do make sure you explain what has been done and how far you have progressed so your pair gets up to speed, else you end up with Pairing Overdrive.

8. Privacy Policy – If you are working on your pairs machine and when your pair is not around do not snoop around there mail or respond to IM that they receive even for fun, what seems to be fun may turn out to be an annoyance. Finally there is absolutely no need to get personal during a pairing session, every developer has his own style and strengths it is important to respect that , for all you know they might be really skilled in areas you are not so good yourself..

After every stand up it makes sense to discuss who can swap pairs. Infact before a stand up it helps to be in a checked in state if you want to make sure your team can swap pairs every day

For now this is all.. code carefully and pair usefully  :)

Implementing Scrum

8 Questions to Answer Before You Begin

Iteration Length?

Our organisation has always used two week iterations and sometimes we do wonder if two weeks is optimum, Well the first thought was for enhancement projects two weeks fits the bill, these could be projects where the solution to implement the features is available to the team, but for a brand new project which includes a technical learning curve and innovation, three weeks might be be apt. This is subject to discussion with the teams. Although Scum recommends a 30 day iteration, 2 week iterations yield results and 3 week iterations will yield innovative results. At the end of the day both iteration lengths are within the realm of Scrum and it is a variable available to teams and the product owner, how it is varied or used as long as the goals of the release are met, is not important.

Based on previous experience with two week iterations I have made some observations which kind of remind us the strength of the two week iteration

• Two weeks is just about enough time to get some amount of meaningful development done.
• Two week iterations indicate and provide more opportunities to succeed or fail.e.g, within a 90 day release plan, 5 - 2-week iterations of development and 1 stabilisation iteration at the end make it possible to have checkpoints on the way to the release.
• The 2-week rhythm is a natural calendar cycle that is easy for all participants to remember and lines up well with typical 1 or 2 week vacation plans, simplifying capacity estimates for the team.
• Velocity can be measured and scope can be adjusted more quickly.
• The overhead in planning and closing an iteration is proportioned to the amount of work that can be accomplished in a two week sprint.
• A two week iteration allows the team to break down work into small chunks where the define/build/test cycle is concurrent. With longer iterations, there is a tendency for teams to build a more waterfall-like process.
• Margin of error for capacity planned and available is lesser in two week iterations.

Well the above is on the basis of what I have observed and may be different in your organisation.

Five Levels of Planning in Scrum

In agile methods, a team gets work through iteration planning. Due to the shortness of the iteration a planning gains importance than an actual plan. The disadvantage of iteration planning when applied to projects that run for more then a few iterations or with multiple teams is that view of long term implications of iteration activities can be lost. In other words: the view of ‘the project as a whole’ is lost.

Planning activities for large-scale development efforts should rely on five levels

• Product Vision
• Product Roadmap
• Release Plan
• Sprint Plan
• Daily Commitment

Each of the five levels of planning help us address fundamental planning principles of priorities, estimates and commitments.