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.

Challenge 2: Timing and the Globally Distributed Team
We had numerous challenges in this area:

• Determining sprint length
• Aligning schedules for vacations, holidays, quarter-end moratoriums, etc.
• Globally distributed teams
• Incorporating integrated user acceptance testing

We started with two-week sprints but ran into the obstacles of holidays, moratoriums, story writing, team member availability, porting, and sprint planning activities. It became almost impossible to complete everything in a two-week timeframe and at the same time achieve a meaningful level of development.

Agile recommends collocation of the team; when this is not possible, a lot of timing obstacles arise that must be carefully addressed. In today’s world, many organizations do not have the luxury of putting everyone in the same room. Consequently, things like optimizing the lag time between time zones, ensuring timely responses to issues, and facilitating handoffs become more challenging.

Both projects wound up with three-week sprints. This allowed some flexibility when dealing with holidays, moratoriums, and other scheduling obstacles.

Testing is included in our story definition of done; this includes user acceptance testing (UAT), not just developer unit testing. And we’ve found there is a lot of value in performing thorough regression testing each sprint. In the Integrity project this is handled by both automated testing and manual testing by developers in the last couple of days of the sprint. This has recouped time later on in the reduction of defects found in shipped code. It also removes the need for formalized end-game UAT, as we are getting that input on a sprint-by-sprint basis.

When development is complete for a particular phase, we launch a pilot in the production environment. We ensure that features and functionality still in development but ported to production in the sprint cycle are hidden from users via security and account privileges. When you are managing multiple phases, leveraging security to limit access allows you to continue moving finished code to the production environment even when the phase is not fully complete or the business is not ready to roll it out. Pilots give the end users time to adjust to the new features and allow for more relaxed rollouts.

Finally, we have implemented a number of measures to address the constraints associated with working with globally dispersed teams. These include limiting scrum calls to fifteen minutes and putting lengthy topics in the parking lot to be addressed via email. This focuses the team on the critical updates and ensures we are not keeping anyone longer than necessary.

We’ve also published photos of all the team members in SharePoint so that we can see each other. We have leveraged collaboration tools with video so that our scrums and other meetings are live. During the India daytime, developers record demos of completed functionality for U.S. stakeholders to evaluate the next day—much more efficient than trying to schedule lengthy demo sessions with all stakeholders.

Challenge 3: Role Transformation
While agile is not exactly the wild west, it does allow for more flexibility in interpretation than some other approaches do. This includes flexibility in the traditional roles we associate with software development—the program or project manager, the business analyst, and the customer.

The program or project manager role has traditionally been more focused on control and compliance. In my case, I’ve adopted the ScrumMaster role in addition to my program manager role. (Yes, I have done this in spite of the mountain of articles written on why this is not a good idea!)

So, how do I manage both? Generally, it means I need to switch hats pretty frequently. When I have my program manager hat on, I’m thinking about what’s best for the project: Are we keeping to scope and budget? Are we on track to deliver as scheduled? How best do I communicate status to my sponsor? When I have my ScrumMaster hat on, I’m thinking about what’s best for the team: Am I removing obstacles for developers? Is everyone challenged and empowered? Are we consistently leveraging and improving the agile approach? By balancing both roles, I am more closely connected with my product owners, sponsors, and team members than I would be in a traditional project management role. I need to ensure that I continue to be flexible and adaptable to successfully manage the project’s progress as well as the agile process.

The business analyst role is also changing in the agile environment. In waterfall, the business analyst is a middleman. Emphasis is on producing a requirements document or functional specification for the development team. Now, the business analyst’s focus is to build a strong relationship with business stakeholders and collaborate with them on building the stories that will produce a viable working solution quickly and efficiently. Business analysts need to adopt more project management activities, such as maintaining a broader perspective on the program and overall process cadence; understanding and communicating tradeoffs among time, scope, costs, and quality; and taking more ownership and accountability for the program’s success.

Finally, the customer’s role is changing as well. Agile requires more dedicated and frequent engagement from the customer in the product owner role. This continuous engagement ensures that the initiative is truly collaborative and continually meeting the customer’s need. No more is the customer on the outside, waiting for the black box of waterfall development to complete, only to find out the solution built to spec is no longer viable. The product owner is now a member of the team—fully engaged and equally responsible for the success of the final product.

Challenge 4: How to Know When to Be Agile
After a lot of reading and thinking about the different kinds of projects in PTC’s IT organization, we developed a questionnaire designed to help determine whether agile or waterfall is appropriate. The key here is to remember that it’s not necessarily cut and dry; you can adopt a hybrid approach to your project if that is the best fit.

We didn’t have this template when we embarked on our agile mission. It evolved out of a realization that there are both benefits and drawbacks to any methodology.

Final Thoughts
In agile, the heart of success is in the end result—working code that can be evaluated by customers. However, a fully optimized process will include efficiencies that come with regular review, analysis, and improvements to the process itself.

The most important thing we’ve learned is that it was great to try “pure” agile, but we needed to tailor our process to ensure we could operate as effectively and efficiently as possible in our particular environment. My parting advice to you is that there is no need to adopt agile principles blindly. Take them and customize them to what makes sense for you. Don’t be afraid of waterfall or hybrid projects. Creativity in your approach—thinking outside the box for any process or principle—will improve the likelihood of success in your environment.