This is a long rant. You have been warned.
This situation arose because of differing software development philosophies between my team, here at this client-site, and that of the management and stakeholders. The project is a very large effort (150+ people, spread over about 10 teams) and is a port of an existing system written in C++ to a J2EE stack. The original system took 3-5 years of work (including starts, back-tracks, support, and maintenance) and involved over 300 people. There are a few developers across the porting teams that have been around on the older system for all this time. The above mentioned difference in philosophy manifests itself through the opinion about what role these folks ought to play.
Management believes that these experienced folks represent all the domain and technical knowledge that is needed to complete this port successfully. I believe that this is not the case – I believe that there are multiple reasons why this will not be effective – a) the ratio of these folks to people that do *not* understand the domain is very low b) these people are *not* very effective at being analysts – who would be the people who would be doing this on a regular project.
The situation on the ground has been manifesting itself in subtle ways, thereby contributing significantly to the fact that the overall velocity of the project is quite low – and though it is increasing, it is doing so quite sluggishly. I’m adapting the following from a write-up of these problems and proposed solutions – in the hope that if people have experienced similar situations – they can share.
A team often runs into story cards that seem to be of a particular size (when estimated) but during the sprint, these cards grow (usually slowly) into much larger, almost monstrous cards. This results in a couple of things – a) the story takes very long to complete and b) some unprioritized work gets done or some prioritized work remains undone. This, in turn, results in an inefficient use of developer time and potentially in unmanaged scope growth.
Another effect of this occurrence is that of dampened morale within the team. When a card takes much longer than originally estimated, it creates a feeling of not knowing the requirements well and of not having any confidence in the estimates. It also creates a feeling of not making progress, which is in general, a morale dampener for any team.
This is a very large project. Estimation of overall effort has been done at a high-level. The fact that comparatively little time (theoretically, just enough) was spent on backlog creation is one reason why it is almost normal to expect to discover more details around a story when working on it. There are two issues around this – that of being in control of this process of discovery, and that of managing the growth when it happens.
Being in control
It is important to recognize and to expect details to emerge after developers start to deep-dive into the existing code. These stories were typically created with a high-level look at functionality – indeed, some stories read “Provide observation data-source to consumers”. Currently, this process is implicit – it happens and the scrum-master watches for it (as should developers!) and catch items as needed. This, however, is reactive rather than proactive, and is at times therefore, not the most efficient.
An example of this inefficiency is – sometimes a pair of developers realizes that they have a couple of extra tasks to complete before they can call a story done. They decide that it is not a huge deal (after all, although these tasks do impact the story time – they were just estimates) – and carry on. And after burning through more time, they find two more tasks. By this time, however, they’re almost done, and they decide to just bite the bullet and do these as well. So, after having burned through a lot more time than estimated, when they finally discover even more work and alert the scrum-master – it is quite late in the process – they have impacted the sprint and might have done things that were not needed right away (that were covered in other stories or that were scheduled for another time). This could be attributed to the confidence (hubris?) of the programmers – blindly believing that they can complete the new tasks in the same amount of time – but is often a genuine case of discovering more functionality after getting deep into implementation.
If instead, the team or pair spent a certain amount of time dedicated to code-browsing etc., then most of these spawn cards can be caught upfront. This doesn’t mean a loss of agility – it can stay a just-in-time task. This way, the backlog gets refined quicker, and also allows these types of tasks to be planned better.
Managing the growth is a two part thing – that of process and that of the administrivia. From an administration perspective, once developers call out attention to the fact that their story is larger than they thought it was, scrum-masters can make adjustments by spawning new stories not directly tied to the goals of the story in question. They then also make sure that module and sprint backlogs reflect this change.
The other aspect of making sure growth is managed is a more difficult one. It is because the above (administration aspects of this issue) relies on two things – the fact that stories have a well-defined scope and acceptance criteria (so that developers can tell when they’re doing something beyond immediate necessity) as well as that the team having an attitude of always wanting to be as close to a working system as possible. This means, they ought to approach implementing every story from the perspective of doing only the simplest thing that works. This doesn’t mean that complexity is avoided – only that the needed complexity is built up, slowly and incrementally across multiple business stories. When this attitude exists, developers quickly flag items that they think will impact the goal of the simplest thing that works.
The first aspect of this – the story itself, is discussed below under “analysis”. The second aspect of this – that of attitude (which is not a bad word!) is a more subtle issue. This can only come from practice and mentoring and seeing this process work – and then by finally (and truly) believing in it.
On a typical agile project, a section of the team-members are business analysts. They play the role of the customer – indeed; they are often referred to as proxy-customers. The responsibility of the BA is straight-forward – they are to understand the domain and create small, manageable, testable stories that provide demonstrable business value. In the absence of this group, this task falls on the very experienced developers that were mentioned earlier. They’re supposed to solve the problem of exploding stories and such.
A large part of the solution seems obvious – developers flag the scrum-master when they see that a story touches things that they didn’t originally think of. Specifically – it means, being able to distinguish functionality in the old code-base that is outside of the specific and precise scope of the story at hand. (Remember, in a non-porting project – anything not in the story is automatically out of scope. In this case, the code beckons – and the developers follow.) This means that stories need to be precise about what is in and what is out. This is hard – who does the needed investigation inside the code-base to create these clear, manageable, testable, demonstrable stories – ones that add business value? In this situation, this job is assumed to be the responsibility of the SMEs (the famous experienced people in question). This is misleading – the SME often is also a developer, prone to the same inclinations as other developers.
The solution aspect of this section is this – we need to improve the analysis process and skills. It is important that the needed investigation is done before implementation (not waterfall – but just in time to remain as agile as possible) and that these stories be written in a way that makes it unambiguous and well-defined in terms of scope (this doesn’t preclude questions to the SME later on, but serves as a better starting point and reference document.)
It is important to be clear about expectations. The teams need to truly believe that this is a normal aspect of delivering this system – and that their estimates are in the end, just that – estimates, albeit that they will get better with time as they get better at the process as well as they gain knowledge about the domain/system. They need to understand what the plan for the overall project is and where it is heading. This information may not be clear today – but developers have as much skin in the game as does management – and they need to understand the larger picture of the whole project – one that they’re spending a significant amount of their day on – indeed, lives on.
It is also important to re-iterate the process with every team member. Agile is hard – it requires discipline (although sometimes it doesn’t look that way!) People need to be mentored as to how the process helps and how to do it right. It is hard to expect people to do things that they don’t necessarily understand. XP practices make the pain of change (scope change etc.) easier to handle – we need to be sure all things are being done to take advantage of these practices. These practices include – test-driven development, automated testing, pairing, refactoring, continuous integration, and others. We need to be sure we’re doing these in the best and most optimal way.
Teams need time and mentorship before they take ownership of the process, the code-base and the success of their projects.
If every developer on these teams was a subject-matter-expert, then theoretically, this problem would go away. However, it is not the case – most developers have been on the projects for only a few months – some even lesser. Therefore, it falls on the current SMEs to help. However, these people are often spread thin – the ratio of SME to non-SME-developer can become dangerously low. Further, SMEs are often developers – and they spend most of their time coding – leaving less time to do story-writing or code-investigation or helping people understand domain. Finally – developers are not the best people to do this type of work – they are just wired differently.
An ideal world
In an ideal world, there would be enough skilled resources to staff all needed roles of a project. The project’s budget would also be large enough to support this. We don’t live in an ideal world – and hence, these types of projects get born. And to do the best job possible on them, it becomes necessary to be creative about the process followed and optimum use of everyone’s skills.
Better stories would lead to a better overall understanding of the system – not only by the developers but also by QA people. This will help them be useful – they will not write tests that expect results that developers (who wrote the code!) tell them – they will actually test the code from a functionality perspective!
Better stories can potentially help drive integration better – since they allow stories to be well-defined and well-sized – and this in turn allows greater visibility into the work-queue. Better visibility allows for better planning – within the module, across modules and across to other systems.
In the end, it must be realized, that the key to solving this particular problem comes down to analysis – regardless of who does it and what it’s called. It is also important to realize that a porting project, many times, needs just as much of it as any other project – regardless of how much money was spent on developing the original system. This is important to make this project a success.