Comprehensive software reviews to make better IT decisions
Sprinkle Some Agile Into Your Waterfall Practices for the (WFH) Post-COVID-19 World
Many Info-Tech members are wrestling with how to best manage their software development productivity in the work-from-home (WFH) world created by the emergence of COVID-19, especially for teams using a Waterfall approach. We suggest they sprinkle some Agile practices into their normal routine to improve transparency and show continuous value delivery.
As a prolonged global lockdown (or perhaps several lockdowns occurring in waves) looks increasingly likely, organizations that master effective WFH practices are more likely to survive this pandemic (as well as future high-disruption events). Thankfully, IT work (including software development) is particularly well suited to accommodating WFH.
But how does an organization ensure their remote workforce is being productive? And how do they concretely measure this productivity? The answer is to borrow some key Agile practices and sprinkle them into their existing process.
Our Take
It’s important to know that Agile development methodologies (like Scrum) are particularly well suited to adapting to WFH. This is primarily due to two key characteristics of all Agile methodologies:
- Self-organizing, cross-functional teams: Agile teams take collective responsibility for delivery and are empowered by the organization to decide for themselves what is the most efficient way of working. Rather than imposing a rigid structure and approach on the team, the organization supports the team’s preferred way of working given their constraints (and WFH is just another constraint the team must resolve).
- Continuous, incremental delivery of functionality: Continuous delivery is a cornerstone of Agile, and because of this, monitoring and measuring productivity is relatively straightforward for Agile projects (in Scrum, each sprint delivers working and tested functionality that can be demonstrated to stakeholders – there are few better measures of productivity than working code!).
These two characteristics give Agile teams a leg up on WFH compared to teams using other methodologies (like Waterfall). However, another important characteristic of Agile, its reliance on face-to-face conversation, must be addressed in a WFH context in order to maximize productivity. Thankfully, this can easily be achieved by adopting effective modern collaboration tools that have capabilities like:
- Videoconferencing
- Screen sharing
- Whiteboarding
- Remote desktop
- Recording capabilities
Collaboration tools (sometimes several of them) are used routinely and effectively by remote Agile teams (i.e. teams that are not entirely colocated). There are numerous tools readily available on the market (e.g. Zoom, MS Teams, Webex, Google Hangouts, GoToMeeting, Slack, Miro, RingCentral, Azure DevOps), and although it takes some getting used to, any Agile team should be able to maintain good productivity using them.
WFH presents a significantly bigger challenge for Waterfall development teams. Waterfall is less well suited to effective monitoring of productivity in a WFH context, because concrete results are not seen until quite late in a project/release. Here we suggest that you selectively adopt a small number of Agile practices and carefully introduce them to your Waterfall teams in order to help you more effectively gauge progress and productivity. These practices are:
- Daily stand-ups
- Pre-release demonstrations
- Retrospectives
- Prioritization
By sprinkling in these Agile practices, you will be able to better monitor Waterfall project productivity, while also helping your Waterfall teams to better understand Agile practices in a digestible way (which may help you in the future if you plan to move your teams over to Agile).
Notice that this will require your Waterfall teams to significantly change their normal way of working. And because change is always difficult, we recommend that you assign each Waterfall team a mentor to help them through this transition. If you have Agile teams in your organization, you can draw on some of them as mentors. Pick people who not only have a good understanding of Agile and its principles/practices but also have a knack for helping others understand them better (think Agile Coach, Scrum Master, Agile Evangelist, etc.). If you don’t have Agile expertise in-house, you will need to look externally for a good Agile coach.
Your mentors will need to spend some time working with their Waterfall team to help them understand, adopt, and adapt to these new practices. The approach used should be to guide the Waterfall team on how to develop their software releases incrementally. Here are more details about this sprinkling approach:
- Daily Stand-Up:
A properly run daily stand-up meeting will keep your development teams aware of what other team members are doing (important in WFH) and will also help to quickly identify and respond to problems. It is critical that these daily stand-ups be run efficiently and avoid getting stuck in the weeds. They should be short (about 15 minutes) and avoid problem solving (identify problems, but don’t fix them here). Daily stand-ups are for small teams (roughly 5-7 people) who work closely together and must communicate frequently. For a large Waterfall team, break up into small groups that are currently working together closely and do daily stand-ups for as long as it makes sense. The stand-up group size and makeup may change over the course of the project as different phases unfold; keep it fluid and practical. Your Agile mentors should guide your Waterfall teams on how to do these effectively. The important outcome of daily stand-ups is that people who are currently working closely together know what everyone is doing.
- Pre-Release Demonstrations:
Ask your Waterfall team to rework the schedule into several pre-releases, each of which will demonstrate some subset of the full functionality for project. We’d suggest something in the range of four to eight weeks between pre-releases. Note that the pre-release dates need to be firm; have the team demonstrate whatever they have working on that date, even if not all expected functionality is complete. At the end of each pre-release, the team should have a demonstratable piece of the system available for review by stakeholders. It doesn’t need to be production ready, but it does need to be well tested – it will be important to agree on what this means. Have the team work collaboratively to determine what will be in each pre-release and to work with stakeholders to agree on the definition of done for pre-releases. Note that this can be the most difficult practice for a Waterfall team to adapt to, because full and final requirements and design will not be complete until late in the project, and thorough testing will need to be done incrementally rather than at the end of he project – this is another place where the Agile mentor will earn their keep. Let your stakeholders provide feedback about what they liked and didn’t like in each pre-release demo and utilize this feedback when planning for subsequent pre-release cycles.
- Retrospectives:
Following each pre-release demonstration, schedule time for the team to meet and review lessons learned. This normally happens at the end of the project. Focus on identifying aspects of the new approach that are working (which should continue for the next pre-release) and those things that are not working and can be fixed (which should be fixed before the next pre-release – management needs to provide support for these fixes). It is important for the Agile mentor to ensure a safe, open, and blame-free environment in these retrospectives or their value will be severely diminished.
- Prioritization:
When the team is deciding what features to include in each pre-release, they should prioritize the features by their importance (even if only a rough prioritization) and then work on the highest priority features first. In this way, any missing functionality in the pre-release demo will be the least important. Have your stakeholders tell the team whether the missing functionality still needs to be included in the final release and its priority relative to what is still left to complete in the project.
As a final note, remember that your Waterfall teams will also benefit from the effective use of collaboration tools as discussed above for Agile teams. Good collaboration tools are critical to WFH success no matter what methodology a team follows.
If you would like to share your experiences (successes, failures, insights, etc.) on adapting to WFH, please complete Info-tech’s Remote Agile Story Card survey.
Want to Know More?
Team Collaboration on SoftwareReviews