Smarter ideas worth writing about.

Scrum in an Interdependent Environment

 

According to the Scrum Guide, the team model in Scrum is designed as a self-organized and cross-functional team in order to optimize flexibility, creativity and productivity.

Self-organization implies the team selects the best approach for completing their work and cross-functionality implies the team has all competencies required to finalize their work without depending on outsiders.

Does that mean that teams working on applications with multiple dependencies cannot leverage the Scrum framework? No, Scrum can be leveraged by anyone!

In an environment where the product you're working with and the organizational landscape you're dealing with are highly interdependent; a higher level of planning and coordination is necessary to still allow teams to be flexible, creative and productive as it is intended with Scrum.

What can you do to ensure that your Scrum Team is successful in a highly interdependent environment? 

 

 

1. Get In Front Of Your Product Backlog!

Understanding the overall roadmap of your product, and the dependent products will help you better plan the work and manage expectations with your dependencies.

Up front conversations regarding overall solution approach, architecture, and scheduling are very important to avoid unexpected situations that can impact your Scrum Team's ability to execute. Knowing, for example, that one of your dependencies will be refreshed during first quarter would allow you to choose an ideal timeframe for your own changes to avoid conflicting activities.

There are many different techniques and tools to help you in this space, including the following:

  • Backlog Grooming - refers to the activities associated with maintaining your backlog current, granular, accurate and prioritized. These activities include breaking down stories, reviewing and improving stories, smart-grouping of stories (based on technical or business factors), estimating stories, discussing priority, value and risk, and creating story maps.
  • Story Mapping – refers to a visual representation of the "big picture" illustrating how a collection of user stories will deliver together a final product. This map will visually display all user stories associated with a certain feature or project – information regarding sequence, dependency, risk, value and technical factors can be added to the map to help depict the overall product and value to be delivered.
  • Dependency VMS – refers to creating a Visual Management System (e.g.: White Board) to help you track your dependencies, their activities and impacts to your ability to perform as a scrum team. Having this information readily available allows for better collaboration and coordination. Much like all other VMS, you must keep it current and accurate to ensure it adds value.

 

2.  Establish & Socialize Your Sprint Schedule

 "
The heart of Scrum is a Sprint, a time-box of one month or less during which a "Done", useable, and potentially releasable product Increment is created." (The Scrum Guide)

Different teams can have different lengths of Sprints. A Scrum Team may have to coordinate activities with a separate team following a different framework all together. Therefore defining and socializing your Sprint schedule is crucial to effective coordination.

If we continue to use the Internet/Billing products example from above – let's describe each Scrum Team's Sprint schedule as follows:

·         The Internet Product – Scrum Team's Sprint: 2 week long Sprints – Production Release monthly (every 4 weeks)

·         The Billing Product – Scrum Team's Sprint: 4 weeks long Sprints – Production Release bi-monthly (every 8 weeks)

If the two teams understand each other's cadence and Sprint schedules, they will have a better chance for success.

Knowing that Scrum Team 1 (working on the Internet product) will be committing to work every 2 weeks, as opposed to the every 4 week commitment Scrum Team 2 will be making; allows you to plan accordingly.

For example, if the Billing product needs to be modified prior to the Internet product in order to allow for proper integration; then Scrum Team 2 may need to start work on an earlier Sprint than Scrum team 1. 

It is all about transparency, inspection and adaption, as is Scrum!

 

3. Build Flexible Products

In addition to getting in front of your backlog and defining and socializing your Sprint schedule with your dependencies; building flexible products is another tactic for minimizing the impacts of dependencies on your Scrum team's productivity.

Building flexible products consists of designing your solutions in ways that provide your team with a higher degree of independence.

The following are some strategies for building flexible products:

  • Decoupling

Design your solutions to be decoupled from their dependencies – leveraging design patterns that allow your solutions to have a higher degree of independence.

For example:

  • Leverage Data Access Patterns to encapsulate physical data access details while only exposing logical operations.
  • Leverage Service Oriented Architecture (SOA) to expose well-defined business functionality as interoperable services while abstracting the service implementation details from the consumers.

The key is to take into consideration the impact to your Scrum team's productivity your application dependencies will have, and try to minimize such impact with creative software design and solution.

With decoupling comes the opportunity for virtualization – but that topic deserves its own blog post!

  • Toggles

Toggles, or switches, are mechanisms that you can implement that will allow you to shift between versions or environments, or even releases.

Here is an example, from a recent project engagement:

The Project: Consume a new web service version, while simultaneously performing a major enhancement in another part of the same application.

The Risk: Since both work items were being done for the same release and in the same code base, if one of the changes failed, the entire code would need to be reverted.

The Mitigation: Implemented a switch that allowed us to revert the two changes individually, without the need for a code change. With this switch if the new service version consumption failed we would have the ability to turn that functionality off, and move forward with the rest of our changes.

Toggles/Switches can be thought of as contingency features, but also as features that allow you to be flexible. Plug-ins should also be considered as they provide you with the ability to add specific abilities to a larger application enabling customization and extensibility.

  • Automation

Finally the big kahuna: Test Automation!!

Having the ability to automatically test your application's functionality gives you the ability to more confidently make changes.

If you are already working with TDD and ATDD you understand the concept of writing test cases prior to writing your code. This allows you to produce code that is maintainable and most importantly reliable. 

Having your code base covered with tests and better yet automated tests gives you more flexibility to change at a more frequent rate, and allows you to manage some of the indirect impact your dependencies can have on your productivity.

These three tactics are a few recommended strategies that will help you minimize the uncertainty to better manage the complexity of your environment. These will consequently contribute towards building and sustaining a flexible, creative and productive team.

Share: