Agile in the Age of Pandemic: Best Practices, Part II

Last time we met, Agile-nauts, we were talking about best practices for launching an Agile program with a Remote By Design approach. This post focuses on what happens after liftoff: Best practices for actually running Agile within an enterprise. Ready to bring the concept down to earth? Let’s make it real.

Run Effective Standups and Scrums

Standups and scrums—you must ensure that these are effective cross-team collaborations. Standups should give team members a quick review of the overall project and what each team and member is working on. Standups can also be a forum to share insights and lessons learned.

SEE ALSO: Why agile teams drive digital transformation

Ensure that your scrum master is dedicated to the stream of work and not multitasking. The scrum master is a maestro, the leader who can’t afford to be distracted. In addition, a scrum master has to maintain a reasonable level of objectivity; having a scrum master too deeply involved in the actual development of code can backfire, as they may lose the perspective necessary to steer the team, play occasional referee, remove barriers and generally keep the team operating efficiently.

Finally, don’t let the scrum or standup devolve into a specific problem-solving session. Doing so can result in the whole team going down a rabbit hole that likely only a few can follow and even less can contribute toward a solution. Instead, take these sessions offline with a small group to brainstorm approaches or possible solutions.

Take Bite-Size Sprints

Continuous development is central to Agile. It ensures the team iteratively builds upon their work to achieve an objective. To enable this, check that your sprints actually are sprints—small, bite-size cycles. Usually, sprints last for about two weeks, and keeping your team’s scope tight will make it possible for them to deliver on time. An endless sprint runs against the purpose, concept, and fundamental principle of Agile. Keep it short!

And take it one step at a time. Multiple sprints working through the backlog in small increments will show the progress and productivity of the team. Failing to follow this approach may result in reducing productivity and team motivation.

Be Flexible, but not Too Flexible

It’s important, with Agile, to attain the right level of flexibility. One example: Assignments should be fluid and should be defined by the team. External team assignments not only break a fundamental concept of Agile, but they also make teams rigid and unable to adapt to dynamic needs.

An example of Agile rigidity to avoid—always assigning a specific set of tasks to one person (“Fred shall always do the front-end work!”). When one person is the only individual responsible for a specific type of work, it prevents cross-training and constrains resource flexibility, skill sets, and abilities, which is a critical flaw in an Agile approach.

One last type of malleability that should be avoided—and something Agile teams almost always face—is the desire to add work to in-flight sprints. Given the short, fast nature of sprints, it usually doesn’t make any sense to add stories. This is not the same as story expansion as a result of in-flight development for those stories already in the sprint, although that too should be monitored closely. Think of adding stories to in-flight sprints as the Agile version of “scope creep.” Yuck.

Leverage Automated Testing

With Agile, there’s a pressing need for aggressive and short lead-time testing. This testing is necessary to validate development and ensure quality code delivery.

To make this possible, the Agile team should seriously consider adopting automated testing. The iterative nature of Agile requires a significant amount of testing, which needs to be done concurrent with development, or nearly so. One option here, but by no means the only one, is test IO’s open source crowd-testing platform.

The requirements for rapid and multiple rounds of testing likely can only be achieved by automated testing. Such testing provides a quick turnaround and feedback to the development team and confirms the developed or refactored code has not broken any existing functionality or other code libraries in the sprint. You should aim for a high level of automated testing, greater than 50%, ideally aiming for 80% or more.

SEE ALSO: “SEO technology is the answer to the challenges that agile organizations face”

Plan… but Don’t Over-Plan

Agile teams often overprepare. Yes, planning is important, and teams need to identify and articulate their overall big picture plans, but there’s a big difference between laying out an overall vision and micromanaging a sprint. The reason Agile teams can often fall into this trap is because many of them evolve from a more traditional type of development—looking at you, waterfall!—where teams are required to understand every requirement to the -nth level of detail.

Instead of taking this type of all-inclusive approach to stories they tackle, Agile teams should move forward with stories for which they understand what they need to do or accomplish in their next two-week effort. Further stories can be discovered and prepared in future iterations and sprints in a process known as backlog grooming. Agile teams should implement a collaborative and efficient framework to capture project and sprint requirements that doesn’t mire them down in excessive detail but, at the same time, provides enough clarity to proceed toward each sprint’s development goals.

So… do you feel ready for the reality of Agile? Sure you do! With these five best practices, you can manage your Agile journey, confident that you have some core principles guiding you on your way. And, hot on the heels of this piece, our next and final post will focus on outputs of a sprint and how Agile teams can successfully manage the sprint iteration process. Keep an eye out for it, Agile-nauts!

The post Agile in the Age of Pandemic: Best Practices, Part II appeared first on JAXenter.