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

[article]

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.

Ask yourself…

Yes

No

Are customer requirements clear?

Waterfall

Agile

Is the business environment stable?

Waterfall

Agile

Is there a likelihood of turnover in the development team?

Waterfall

Agile

Is your development team large (>10 developers)?

Waterfall

Agile

Will your team be 100% dedicated to the project?

Agile

Waterfall

Is time to market the most critical metric?

Agile

Waterfall

Are business stakeholders fully engaged in the process?

Agile

Waterfall

Are requirements likely to change frequently or significantly?

Agile

Waterfall

Are you able to interact frequently with your stakeholders?

Agile

Waterfall

User Comments

1 comment

About the author

Alison Jacques's picture Alison Jacques

With over 20 years in both software development and IT project management, Alison Jacques brings a wealth of experience and learning to bear on challenges in the PM discipline. In addition to being a practicing PM, Alison has tailored process methodologies from CMMI to waterfall to Agile at several companies. Of latest interest to her is the shift from waterfall to agile methodology and how PMs can adapt and leverage this new approach to improve project delivery. Alison holds a bachelor's degree in philosophy from Georgetown University and a graduate management certificate from Babson College. She was certified as a PMP in 2005 and became a CSM in 2012. She is currently working on her PMI-ACP.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!