Scrum & Agile Methodologies - Cross-Functional teams

3. Do not design your teams to be cross-functional

When we started out with Scrum we were told that Scrum teams should be autonomous and that they should be able to handle vertical, end-to-end user stories. We consequently setup teams which had all of the skills necessary to implement a story including tools, server components and management components. This did not work very well and we abandoned it after 1 sprint.

The problem was that our developers have different areas of expertise - some are very talented server developers, some have great Eclipse plugin development experience and others are web app specialists. We found was that at the end of the sprint there would always be a single grouping on the critical path and that there were other team members who did not have enough skills in specific areas to take tasks and complete them efficiently. This was wasteful.

We then re-organised our teams so that developers with similar skills were co-located (eg a tools team and a server team). Using this configuration some end-2-end use cases could not be assigned within a single team. This means that we have to co-ordinate the efforts and backlog for the tools and server teams but also ensures that overall resource utilization is much higher.

There is one downside to this approach - in cross-functional scrum teams developers are forced to learn new skills and product areas thus improving cross-training. This can be a good thing once you have good oversight of the designs and code that they produce. However I am not sure that it is realistic to expect developers to be generalists and to be able to turn their hand to any development area. Developers tend to specialise and become expert in specific areas (eg. tools development, DB, security etc)- ignoring this fact means that you must resign yourself to estimate tasks on the basis that it may potentially be done by somebody who does not know the functional area, who has limited prior knowledge of the technology areas which they may be required to use and who may not be interested in the specific technology area. It is similiar to having a sprinter but deciding that you will enter him/her in the decathlon. It the Cape Clear product development team the developers can develop their skills within the team and can of course transfer between teams occasionally. This recognises the developer's existing skills, experience and ambitions - to extend my athletics analogy it may be possible that the sprinter can be trained as a 100m, 200m and 110m hurdles runner but not as a shot-putter!


The

Scrum & Agile Methodologies - System Testing

2. Scrum is not suited to planning system test cycles

The reason for the (Ha Ha) in my first post in the series is that our iterations are not actually potentially releasable. We have a suite of tests which are not run on a continuous basis which need to be executed before release. These include platform testing, performance and stress tests - we also have (to our great shame) some manual UI tests.

The point is that we need to go through a system test and fixing cycle before we ship any software release out the door. When we need to do this SCRUM does not help. Scrum relies on your ability to predict upfront what tasks you are going to work on and to estimate them - clearly you do not know what bugs you are going to find so you cannot use scrum to manage this
While Scrum is good for software development cycles - use a standard test plan and for system testing.

Agile Methodologies & Scrum - Sprint Duration

At Cape Clear we practise Agile development and planning - we use Scrum to create a product backlog and have iterative development cycles, continuous build & test etc. While I love the visibility, control and feedback that the process gives us I have found that we needed to tweak it to work for us - This is the first of a sequence of posts which summarise how we have customised Scrum:

1. Iterations can be too short.

The general recommendation is that iterations should be as short as possible - we decided at the outset to try 4 week cycles however we subsequently moved to 6 week cycles. We did this for 2 main reasons:

• The overhead of Scrum (1 day planning & 1 day review & retrospective) per team was too big. We run 2 separate teams - therefore the overhead on a 4 week iteration would be 3-4 days every 20 - which I think you will agree is not very desirable. Management (especially me!) found that the planning overhead very burdensome and the teams felt that they were only really hitting their stride when they had to stop and re-plan. So we changed it. There are times when the 6 week cycle is quite long - when an analysis task (we call this a SPIKE task) must be completed in one SPRINT in order to facilitate planning for a subsequent sprint. This can cause an undesirable sequential dependency which can be worked around by good ol' fashioned common sense if it causes a problem.
  
• Our product stories tend to be quite complex - by this I mean that we are not building a web app in which the delivery framework is well understood and the functions discrete. We are building middleware infrastructure with deep dependency chains which straddle tools, runtime and management infrastructure. In order for each iteration to be "potentially releasable" (Ha Ha) - we wanted to be able to define stories at a product capability level, we did not want our stories to straddle multiple sprints if we could help it.
  We found that 6 weeks encompassed all but the most fiendish stories so we settled on this.
  

My recommendation therefore is to choose an iteration cycle to suit you and your team - don't be swayed by the purists who insist on bi-weekly iterations at the most - I suspect that this is good for simple or prototype developments - it is not good for product development.