is able to evaluate all the pertinent information needed to make intelligent planning decisions. Provided with this visibility and the context in terms of business value, the guesswork is taken out of sprint planning for them.
Quality in Agile – A new paradigm for QA
Quality Assurance is an area that many enterprises struggle with when they shift to Agile. The initial tendency is to look at each sprint as a “mini-waterfall” with a testing window at the end. However, the reality is that Agile calls for a much bigger shift. It requires a fundamental change in the way traditional delivery organizations structure their teams and their work, because Agile testing happens in concurrence with development activities in a sprint.
An area of particular challenge is around test automation. According to Agile principles, every feature that gets developed within a sprint must have associated test cases that have been run. Unfortunately, automating the tests is not always possible – and sometimes creates waste. For instance, if the user interface of a release is going to change significantly in a given sprint, any test cases that are created and automated will have to be scrapped and redone.
One way to overcome this issue along the road to adopting Agile is to make slight adaptations to this Agile practice. For example, a feature or story is completed in a given sprint if the team has designed the test cases and run them manually to ensure they work. The automation is then completed in the next sprint. However, there are many risks involved in taking this approach. One of the tenets of Agile is that there is a clearly defined set of deliverables that must be met before a user story (or feature) is considered complete. By changing the completion criteria, and signing off on a feature or user story pending an action that will take place in the following sprint, there is the risk that the team will forget to complete the action – automate the tests – when they get focused on the next sprint.
Provided the necessary means are in place for managers to have the visibility they need - as described above - this kind of approach can actually work. If the cumulative number of test cases are shown for the release, and if this number fails to go up in a given sprint, it is likely that the tests from the previous sprint were not automated.
Managing a Successful Transition
When going through an Agile transition, evaluate it from the perspective of the business and ask, “How is Agile working for us?” Ultimately, businesses could care less what methodology teams use, as long as they are delivering predictable, high-quality results. To manage that, you need intelligence. You need to see what’s working and what isn’t, identify trends, surface areas that need more attention, and make informed decisions.
Chances are, most enterprise development organizations will never be completely Agile. Nor should they. The reason for any transformation is not to standardize on a process, but to create a high-octane, optimized delivery engine that makes the best use of its resources to deliver business value. You need to be able to manage both Agile and traditional projects – rolling them all up into a single dashboard. Further, you need a holistic view of delivery across this portfolio, into specific projects and down into teams and tasks. This information will help to plan and manage an organization's transformation. As you are making decisions on how to transform an entire organization, providing visibility into current and historical metrics is the only way