Mark’s experience matches our own and that of many other testers we’ve met who’ve moved from traditional to agile development. If you’re a tester who just joined an agile team, keep an open mind and consider how your teammates might have different viewpoints.
Management Expectations
When we think of challenges involved with adopting agile, we generally think of the actual team and the issues it encounters. However, for successful agile adoption, management buy-in is critical. In a phased project, management gets regular updates and sign-off documents indicating the end of each phase. Upper-level managers might not understand how they’ll be able to gauge agile project progress. They might fear a loss of control or lack of “process.”
Cultural Changes for Managers
In an agile project, expectations change. In her previous life in waterfall projects, Janet remembers hearing comments like “this feature is 90% done” for weeks. Those types of metrics are meaningless in agile projects. There are no sign-offs to mark the end of a phase, and the “doneness” of a project isn’t measured by gates.
Meaningful metrics are determined by each project team. In Scrum, sprint and release burndown charts track story completion and can give managers a measure of progress, but not any hard “dates” to use for billing customers. Test matrices can be used to track functionality test coverage but do not provide sign-off documentation.
The other change that is difficult for some managers to understand is letting the teams make their own technical decisions and manage their own workloads. It’s no longer the manager who decides what is good enough. It is the team (which includes the customer) that defines the level of quality necessary to deliver a successful application.
Agile teams estimate and work in smaller chunks of time than traditional teams. Rather than building in contingency, teams need to plan enough time for good design and execution in order to ensure that technical debt does not increase. Rather than managing the team’s activities at a low level, managers of agile teams focus on removing obstacles so that team members can do their best work.
Janet’s Story
I asked the vice president in charge of a large agile project what he found to be the most difficult part in the new agile environment from a management perspective. He said that in a traditional waterfall type project, the reports all showed that everything was going according to plan until the very end, and then everything was in a panic state and “nothing worked.”
In the agile project, there were problems every day that needed to be addressed. Agile projects were more work on a consistent basis, but at least he was getting realistic reports. There were no surprises at the end of the project.
—Janet
Business stakeholders don’t like surprises. If they can be convinced to give the team enough time and resources to make the transition, they’ll find that agile development lets them plan more accurately and achieve business goals in steady increments.
Sometimes it’s actually management that drives the decision to start doing agile development. The business leaders at Lisa’s company chose to try agile development in order to solve its software crisis. To be effective, they needed to have a different set of management expectations. They needed to be sensitive to the difficulty of making big changes, especially in an organization that wasn’t functioning well.
In all cases, managers need lots of patience during what might be a long transition to a high-functioning agile team. It’s their job to make sure they provide the necessary resources and that they enable every individual to learn how to do high-quality work.
A Testing Manager’s Transition Tale
Tae Chang manages a team at DoubleClick that conducts end-to-end testing to ensure that all integration points, both up and downstream from the target of change, are covered. When they implemented Scrum, the development teams were reorganized into numerous application teams. Communication problems resulted in missed dependencies, so Tae’s team stepped up to help make sure problems were detected early.
Tae told us, “I believe agile development effectively magnified the importance of cross-team communication and a coordinated end-to-end testing effort. It was not easy to work out a noninvasive (in terms of fitting into current sprint structure) integration testing process; in fact, we are still tweaking it, but the overall benefit of such a testing effort is apparent.” Their teams began to slide into the “mini-waterfall” trap. “In retrospect,” explains Tae, “one of the reasons for this is because we started with the agile process before internalizing agile practices.”
Knowing that test automation and continuous integration were key, the teams at DoubleClick came up with new ideas, such as a specialized build and automation team to help the development teams cope. They brought in expert training to help them learn TDD and pair programming. They started taking steps to address their legacy system’s technical debt.
Tae’s team attends all of the sprint planning and review sessions, using both formal and informal communication to facilitate cross-functional communication and coordinate testing and releases. He has found that it helps to keep meetings small, short, and relevant. He’s also a proponent of everyone sitting together in an open work area, as opposed to sectioned-off cubes.
Tae offers the following advice to testers making the transition to agile:
“Agile development in general will initially frustrate testers in that they will not have access to full requirements documentation or defined stages of testing. In my view of agile development, at any given moment, the tester will be engaged in tasks from multiple stages of the traditional development process. A tester can be sitting in a design session with engineering and product management (she should be taking notes here and start thinking of areas of risk where proposed code change will most likely impact) and on the same day work on automating and running test cases for the proposed changes. It’s a change in mind-set, and some people are quicker to adapt than others.”
Tae’s experience mirrors our own and that of many other teams we’ve talked to.
If you’re a QA manager, be prepared to help your testers overcome their frustrations with moving from defined, sequential testing stages to fast-paced iterations where they perform widely varied tasks on any given day. Help them adapt to the idea that testing is no longer a separate activity that occurs after development but that testing and coding are integrated activities.
If you’re a tester or other team member who isn’t getting the support you need in your transition to agile development, think about the difficulties your managers might be having in understanding agile development. Help them to understand what kinds of support you need.
Speaking the Manager’s Language
What do business managers understand best? It’s the bottom line—the ROI (return on investment). To get the support you need from your management, frame your needs in a context that they can understand. Your team’s velocity translates into new features to make the business more profitable. If you need time and funds to learn and implement an automated test tool, explain to management that over time, automated regression tests will let your team go faster and deliver more functionality in each iteration.
Lisa’s Story