Case study: Scrum at SolarWinds Inc.

Context and problem areas
LogicNow, a Belarus-based company and AgileLAB's client, was acquired by SolarWinds Inc., a global network & system management software leader. After the acquisition, LogicNow immediately had to align its development and Agile practice implementation approaches with the rest of the now much larger company, so that they all "speak the same language." Meanwhile, SolarWinds' Belarus development office had no clear and consistent view of Agile, the value it brings, its impact on major goals, or how to scale it in the future.

LogicNow turned to AgileLAB to transform their existing development approach, adapt Agile practices to LogicNow's day-to-day realities, and introduce a culture of continuous improvement. This transformation would speed up LogicNow's integration with SolarWinds and improve the efficiency and involvement of everyone at the Belarus office.

The following major issues were identified at the beginning:
  • Teams didn't know or understand Agile principles & values and the Scrum process very well.
  • Different players understood and interpreted the process differently.
  • There were cross-team dependencies.
  • Product owners were overworked.
  • Quality was threatened.
  • Deliveries had to be frequent.
  • The existing process was hard to scale.
  • Personnel were expected to display more initiative and motivation.
With the above issues and the customer's needs in mind, AgileLAB’s first step was to audit the current state of affairs. The main areas we targeted were: Product & Process management, Support, Quality Assurance, and Testing Automation. Based on the analysis results, AgileLAB offered a comprehensive solution that would work with the company's specifics then and there.
Product management
AgileLAB designed the process of getting from an idea to an actionable backlog (Discovery) to be as transparent as possible. Discovery also makes sure that the client understands how many backlog elements Product Owners have to deal with.
On top of that, with the teams reshuffled, AgileLAB managed to cut the number of product backlogs & teams for every Product Owner. After launching and beginning to support the teams, AgileLAB built communication lines between Product Owners and the relevant teams, and engaged Product Owners in team-related events. The Product Owner became the main task source for each relevant team.
New team structure
Teams didn't use to be fully cross-functional. Because of this, AgileLAB had the following goals in mind when reimagining team member roles, backlogs, and cross-team communication:
  • Reduce the number of dependencies between the teams.
  • Make teams cross-functional.
  • Organize a team for technology control and management.
  • Split the Scrum Master and Technical Lead roles.
  • Appoint a team responsible for end-to-end solution testing and delivery (the System Team).
AgileLAB combined a few teams, added certain competences to others to handle new backlogs, and built a number of new ones from scratch.
The Scrum process in OMG!, Ants, and KB teams
Scrum ended up a perfect fit for the three Product teams. The teams follow the same sprint cadence. To sync their priorities, Product Owners have meetings with the Senior Product Owner, responsible for the general Product strategy.
These teams' internal processes have the following qualities:

  • The Product Owner is responsible for the product backlog. Team members may contribute.
  • A typical backlog refinement meeting takes 1 to 2 hours. The meeting outcome is a list of user stories, already scored in Story Points.
  • It takes 2 to 4 hours to plan a sprint. The team breaks user stories down into subtasks and estimates the required man hours. Next, they vote on their confidence and committing to a sprint goal.
  • Sprints are 2-week long. All sprints run for the same length of time with the same cadence.
  • A sprint demo should take 1 hour, even for failed sprints.
  • Regular retrospectives take 1 hour each, with tea & cookies.
Plumbing team process
The Plumbing team develops the platform technology and fixes incidents. Compared to the three Product teams, the Plumbing team is less unpredictable in developing the platform, but more unpredictable in fixing incidents. To facilitate communication between the Plumbing team and Product teams, AgileLAB used Scrum terminology (though this process is no longer Scrum per se) to describe the Plumbing team's specifics.

  • The Product Owner is responsible for the product backlog. Team members may contribute.
  • Sprints are 2-week long. All sprints run for the same length of time with the same cadence.
  • Sprints are run with no planning events.
  • Daily sync meetings are held with a Product Owner present.
  • Meetings to refine a backlog are held twice a week for half an hour. The meeting outcome is a list of user stories and tasks, already prioritized and scored in Story Points.
  • User stories are estimated in Story Points, whereas tasks are estimated in man hours.
  • A sprint demo is provided once every two weeks for 1 hour.
  • The company uses a light version of Definition of Done (DoD) here.
  • Regular retrospectives take 1 hour each, with tea & cookies.
  • There is a Fast-track line on the board with a limit of WIP = 1 at a time. The [Red] prefix is a flag to start handling the task within one hour of its creation.
  • The branching strategy means allocating individual branches for various types of activities: aligning with standards, performance, AntiCrypto, SQL Cloud, and hotfixes.
  • A Product Owner can decide to merge a branch with the "Stabilization" branch.
QA automation team process
  • Sprints are 2-week long. All sprints run for the same length of time with the same cadence.
  • Sprint Planning is optional.
  • Sync meetings are held daily.
  • Meetings to refine a backlog take 1 hour. The meeting outcome is a list of user stories and tasks, already scored in Story Points.
  • User stories are estimated in Story Points, tasks and tests in man hours.
  • Sprint demos are delivered every two weeks and take 1 hour.
  • Regular retrospectives take place, 1 hour each, with tea & cookies.
  • There is a Fast-track line on the board with a limit of WIP = 1 at a time.
Suggested metrics
We suggested and set up a metrics system to make decisions based on objective data. In doing so, AgileLAB specifically considered individual metrics and their scopes to avoid a cobra effect in metrics-based management.
Beyond teams
On top of transforming teams, AgileLAB's consultants delivered the following:
  • Founded a Scrum Community of Practice (CoP). Here, Scrum experts could share their experience, put their heads together to solve issues, and escalate blocking issues to transformation leaders.
  • Implemented quarterly PI Planning. This opened up a wide range of options for transparent communication, aligning all of the participants' goals and expectations, identifying dependencies, and generally accelerating decision-making.
  • Implemented a PI preparation and innovation sprint to prepare for and successfully run quarterly PI Planning. In this sprint, teams finalize the integrations of a given solution, handle infrastructure and system impediments, and compile backlogs for quarterly PI Planning, rather than work on new features.
The results
By the end of the 3-month collaboration with AgileLAB, LogicNow had the following to show for it:

  1. Designed a transformation roadmap to include structural and process changes.
  2. LogicNow's experts completed AgileLAB's training courses to imagine the general Agile concept as well as to understand the Scrum framework, the Kanban method, and scaling principles.
  3. Three Product teams started to use Scrum.
  4. Other teams adopted two-week cadences to embrace scheduling, feedback collection, and continuous improvement.
  5. The transparency and predictability of the delivery process improved.
  6. LogicNow nurtured a unified conceptual framework that helped communicate with other SolarWinds companies using the same language (Agile) and ensure persistent and predictable delivery.
  7. Personnel involvement and change transparency improved. For example, at sprint demos, support technicians started to proactively inquire about the features to be soon deployed to production.
  8. The communication between teams and business representatives improved in both quality and quantity.
  9. Once the project finished, LogicNow got a number of recommendations on what they should do next to nurture an Agile culture and practices.
Contact us

Might be interesting