Tales from the Trenches: Conquering the Challenges of Transforming to Agile


There is a lot of hard work and recalibration needed to adopt an agile approach. Just as one does not simply walk into Mordor, you also cannot simply decide to be agile. In this article, Alison Jacques describes her IT department’s experience transforming to agile and shares some of the lessons learned and tools she’s adopted to ensure continued success.

Over the past few years, my coworkers and I in the IT department at PTC realized we were not consistently meeting customer needs and expectations for large-scale business systems application implementations. The waterfall development process we had been using was not flexible or fast enough to respond to evolving needs. We needed to embrace change as a fact in our environment instead of fighting it.

In deciding how best to address this problem, we looked to the company’s software development  organization, which had transformed from waterfall to agile a few years prior. The department had faced similar issues in meeting customer demands and staying ahead of PTC’s competitors. Taking our cue from them, we adopted agile for two major projects—our SalesForce.com implementation for the sales organization, and our Integrity implementation for research and development. Our initial goals were to improve our performance in delivering critical business process solutions to our customers and to strengthen relationships with business units throughout the organization.

Project Bios
Both projects are very large in scope and impact:

SalesForce—Implement the cloud-based SalesForce.com solution to manage forecast, pipeline, quotes, orders, and bookings in one solution for sixteen hundred sales and six hundred sales support users. The project length was nine months and the IT team was approximately twenty-five people.

Integrity—Implement PTC’s Integrity product to manage the software development process in our eighteen hundred-member research and development organization. Competitor products to Integrity include VersionOne and Rally. Goals include reducing our dependency on third-party tools, standardizing the solution used to manage the PTC software development process, and investing in our own product suite. The project length is two years and the team size is currently about fifteen people.

Challenge 1: Story Writing
Moving from the five- to ten-page requirements document to an agile one-liner (“As a _[role]_, I want to _[action]_ in order to _[outcome]_.”) was not an easy transition, and it was not effective. Some classic issues we encountered included users incorporating solutions in their agile stories and users basing their stories on existing functionality instead of their business needs. These stories did not provide the kind of development flexibility to address the business need, and they did not scale well. It took some time to get customers used to thinking about what the underlying business needs were. Once they got the idea, the agile stories improved greatly.

However, the agile story format was not detailed enough to provide the information the team needed to begin the development process. We now had the business concept, purpose, and flexibility needed, but we lacked details to help the development team get started. What were the acceptance criteria for the story? What assumptions was the user making when writing the agile story?

In short, we needed a happy medium. We wound up creating a one-page story template (see below) that is a hybrid of the formal requirements document and the agile story. The template includes assumptions, constraints, acceptance criteria, and testing points. It takes the best of both approaches and combines them into a lightweight, informative document that both business users and developers can easily leverage.

The story template also reflected the more collaborative approach we adopted—IT business analysts working closely with their business counterparts to draft, review, and finalize the story templates. This collaboration strengthened our relationships with key business stakeholders and avoided the “throw-it-over-the-wall” syndrome we had previously experienced in the waterfall process.


User Comments

1 comment

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.