Belinda Hardman is a senior project manager/Scrum master for Morningstar. She shared her wealth of project management expertise within the technology sector during a recent TechDebate in Chicago in which the panel discussed the applications of agile development to traditionally non-agile projects. Thankfully, I had the opportunity to speak with Belinda about the topic in a bit more detail.
Sphere Software hosts a series of TechDebates around the world. For more information or to register, visit www.techdebate.org. Also, we’re always on the lookout for debaters—if you have something to say, let us know at https://techdebates.sphereinc.com/debater-registration.
Why is agile development typically superior to waterfall constructs?
BELINDA: Managing projects using a sequential, or waterfall, methodology is frustrating because it requires a lot of time planning and gathering requirements upfront. Often, as a project moves forward, business needs change or you discover new constraints or dependencies, necessitating re-planning or redesigning a major section of the functionality. Waterfall requires everything to be planned and deadline dates established from the beginning, so adjusting as requirements and needs evolve becomes very difficult—and there are always changes.
Also, it’s stressful to have to go back to stakeholders and explain that changing requirements set back both the budget and the schedule. Agile has eliminated some of this stress by reducing ineffective upfront planning and accommodating learning and changing needs along the way.
There are always unknowns, but agile allows us to be a lot more pragmatic and move forward with what we do know. Because agile allows for adaptability and even welcomes change, this leads to a better experience for everyone involved, facilitates clarity by helping us focus on one sprint’s worth of work at a time, and ultimately leads to a better product.
When using a waterfall construct, you’ve often waited until the end of the project to get user feedback. The development team delivered what was requested, but the user is too often disappointed since business needs may have changed, or because the user needs were not clearly understood at the beginning of the project. It’s a morale-killing and expensive proposition.
How do you make agile development, and the uncertainty that comes along with it, more comfortable?
BELINDA: There are some organizations that are very resistant to agile. Within these organizations, senior executives are most likely to be resistant to it, but this has changed a lot just in the last few years. I’ve had the most success by trying to mitigate risk for these stakeholders because uncertainty is the root of their resistance to agile.
I address the things that are taking those resistant to agile outside of their comfort zones, allowing them to see that in the long run, agile is better because it puts them in the control seat, calling the shots. I also convey that it’s much better for us not to take their requirements, hole up in a corner somewhere attempting to interpret those requirements and hoping that we get it right. Rather, we will be getting their feedback along the way, and changing business requirements can be addressed so that the work results in a valuable end product.
Which project management approaches are the most important for keeping a project on track?
BELINDA: Active and open communication in all directions is vital within an agile environment. You run the risk of losing credibility and trust if you don’t keep communications open. Maintaining trust among all stakeholders is critical.
As a project manager or scrum master in an agile development environment, you are situated in the middle of the action. You must be very effective at listening to the development team, the product team, and the needs of the other stakeholders. Also, you must be a good negotiator so that when challenges arise you can walk the line between technology and business, effectively explain the situation, and outline the options for moving forward as well as any tradeoffs.
Listening, communication, and negotiation skills, as well as the ability to secure trust, are essential within an agile environment, but are also important for any kind of project management. However, when there’s uncertainty, as there is within an agile environment, trust is even more crucial.
How do you assure effective communication among stakeholders?
BELINDA: Agile ceremonies go a long way. Most agile ceremonies—retrospectives being the exception—are open to stakeholders being there to observe even if they don’t actively participate. This helps foster the needed openness and trust. End-of-sprint reviews with stakeholders, in addition to the agile ceremonies, are also helpful because these reviews are opportunities to share progress, risks, and uncertainties, and obtain feedback.
You have made some changes to your current team’s agile development construct. How has this gone and why did you make this change?
BELINDA: I’ve reduced the length of our sprints from one month to two weeks. Our one-month sprints were tied to update release cycles, but there’s no reason sprints must be tied to release cycles.
Now, at the end of each two-week sprint, when we have a potentially releasable increment, we review where we are and plan the work that needs to be accomplished in the next two weeks. This structure adjustment has allowed us to work two weeks ahead of our release schedule to give us a nice long period for testing. Being in the financial services industry, we must be very careful to make sure updates work as they should.
The big change when we moved from four-week to two-week sprints was breaking our stories down into smaller pieces. At first, I received pushback and it took some adjustment on both the product and technology sides.
In the past, there was a tendency for a product team to write big stories and hand them off to the technology team, rather than for story creation to be a collaborative effort. Now there is a lot more collaboration going on, resulting in a better shared understanding of the work, better story breakdown, and easier story creation.
My goal for the shorter sprints was to bring more focus to the team, and we achieved that. I also wanted our work to become more of a steady stream rather than peaks and valleys of activity. Before, the development team would have a lot of work for three of the four weeks of the sprint, and then quality assurance would be slammed the fourth week and the development team would not have much to do. This roller-coaster kind of structure is taxing on an organization and wastes valuable time. We’ve gained additional benefits from these shorter sprints, also. We have shorter planning and backlog grooming sessions, more consistent delivery of our commitments, less stress around releases, and more cohesion between product, development, and QA. There were some growing pains, but it was well worth the effort for the team and for our product.
Our company, Sphere Software (https://sphereinc.com), is the sponsor and organizer of Techdebates.org and also finds great value in these follow-up discussions with industry experts. Sphere is a technology consulting and solutions company. Everything we do is designed to accelerate your business, remove technical constraints and eliminate staffing bottlenecks.
