Risks in Agile projects Henrik Emilsson
Agile development methods are becoming a more popular way of producing software in contrast to traditional project processes. This has affected the testing profession in many ways, which has given us both benefits and new challenges.
In a way, agile development methods can be seen as a reaction to a couple of traditional project risks. But even if some risks have been addressed by these methods, there are certainly new risks that are introduced.
I have more than 5 years of experience working in Agile development teams and I love this way of developing software. Still, I have seen a lot of new risks that has been introduced with these approaches; risks that sometimes are ignored, and sometimes they hit the project with full strike.
So,
* what new risks have been introduced in Agile development?
* And especially, what new risks are introduced for testing in agile projects?
* Which risks are applicable for testers in a project where developers do unit tests and testers are supposed to do acceptance tests?
* Which risks can affect the testing in a project where you end up as the only tester out of 8 team members of a Scrum team?
* Which risks are to be found in an agile project where one test team is supporting several agile development teams?
So, can we (I invite you all to this task) identify and define 5 core risks that are applicable for testing in agile projects?
By core risks, I mean risks that would be so common that they could be considered to be valid in most contexts.
And…
Can we try to find out about how risks can manifest in agile projects and what their transition indicators are?
I guess this would be a good way of learning how to mitigate and take actions to minimize the costs for the risks to materialize.
As risks are something that will always exist in software development, it is better to manage them than to ignore them.
I will start by listing a few. Some are generic risks for agile development as a whole and thereby also affecting testing.
Risk:
Management is running projects in same fashion as earlier (or think that it should be run as earlier).
Risk manifestation:
* All communication from the project to management is supposed to be done according to the previous process (documentation, specification, reports, etc).
* Project has no contact with customers or customer representatives.
* Release content and project scope needs to be specified in advance, decisions should be made before proceeding with project, etc.
* Test documentation is supposed to be at the same level as earlier, a cost that requires lots of resources.
* Political issues between project teams and management (e.g., team want to show that the new method is better than the old, and management want to show the opposite; which might lead to unproductivity and hostile environment).
Transition Indicators:
* Agile method is implemented without management support (guerilla style).
* Important stakeholders from management dislike the new method.
* Management says “Do as you want, but we wanna see some results by…”
* Management is not interested in investing in the time it takes to learn a new method.
Risk:
Work packages are too large or include too many sub-tasks.
Risk manifestation:
* Iteration builds are never completed according to planned scope.
* Quality of testing is low.
* Quality of iteration builds are low.
* Disappointed customer or customer representative (e.g., sprint reviews are often late and/or functionality has a lot of bugs and/or functionality is not finished).
Transition Indicators:
* Work packages are often larger than 16h.
* Test tasks are not detailed.
* Estimation of test tasks are mirrored to estimation of implementation tasks (the time to test a block of functionality is not proportional to the time to implement it, there can be large differences between implementation and testing – sometimes it takes less time to test than implement and vice versa).
more to come…
Risk:
The test team has too many different projects, trying to assist everyone to their best effort.
Risk manifestation:
* Cannot promise any of the project managers any given test time allocated.
* Causing frustration among managers since they lack control of the situation.
* Can seem a bit unprofessional since testers can just state that they should just trust them.
* If extra resources are needed it is hard to prove why you need them since you seldome have any measures, you go by gut feeling.
Transition Indicators:
* Hard for the test lead or team leader of test to plan.
* Long term planning seldome done, short term plans by the week is more frequent.
* Test team has little time to spend time with other project members, instead the test team grows stronger and more defensive.
Risk:
Testing of iteration builds are too shallow.
Risk manifestation:
* Disappointed customers or customer representatives because iteration builds are broken/unusable.
* Late project or improductive team due to too much time spent on fixing bugs from earlier iterations.
* The amount of testing tasks is never decreased.
Transition indicators:
* Only minor bugs are found during testing.
* Serious bugs are never found until next iteration or at customer site.
* No testing is done on currently developed functionality.
* Bugs aren’t fixed immediately; time is not set off to fix bugs introduced in the current iteration.
* The team is lacking testing resources.
* The amount of testing tasks seem to increase for each week.
* Developers are not doing any unit tests.
* Developer work packages are too large and thereby being finished (or discovered not to be finished) late in the iteration.