Scrum Project Management for IT Data Center and Infrastructure Teams

24 January 2013

Introduction

What are the plausible steps and best practices for incorporating a Scrum project management framework into the data center and infrastructure teamwork at a model organization?

The Enterprise Web Reporting pilot project goal was to successfully justify the case that by applying Scrum techniques, disciplines, and principles, data center and infrastructure teams can work in synergy with business and Scrum development teams to assure that proper planning is in place to fulfill and meet release-planning initiatives. The project demonstrates that using Scrum project management resulted in improved operational processes and provided the Scrum development team with increased productivity and a quality product for each sprint, as risk was minimized downstream. The overall synergy of the teams for this pilot project was demonstrated during the preplanning phase leading up to the start of every sprint, as well as during the sprint life cycle, especially when unknown risks arose. The case demonstrates both tangible and intangible benefits from the amount of work completed throughout the sprints.

The project analysis involved going through each current department within the organization, reaching out to other model companies from previous jobs I'd had, and tapping into my IT network of friends with expertise in infrastructure, data center, and Scrum/Agile frameworks. Online Scrum groups and the Scrum Alliance website provided information to assess similar challenges other organizations have experienced with incorporating their infrastructure and data center teams with Scrum development life cycles.

Project findings

With the adoption of Scrum and Agile methods as the primary project management process, it has become imperative to align infrastructure operations to this method. This adoption can solve challenges with current formal project management and align infrastructure teams to company goals more effectively. While Scrum is primarily used with software development, many of its characteristics can be applied to infrastructure project management needs. Here I outline the goals, challenges, processes, and requirements of Scrum for an iterative incremental process for infrastructure operations.

1. Process methods, values, and goals

Agile software development principles are based on the core values defined in the Agile Manifesto. These values are:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

These values align well with lightweight software development project management goals. However, because of more rigid requirements (purchasing versus creating differences), stability needs, and scope restrictions, these values are not as clear-cut for an infrastructure operations-based team. A context-adjusted set of values taking into account the differences in methods and structure with defined expectations and applications is necessary.

The "InfraScrum" core values are defined as communication, collaboration, agility, and accountability. The following outline lists each core value and how components of the process directly accomplish them:

Communication

  • For leadership
    • Transparency: Centralized backlog providing detailed insight into Infrastructure stories (projects).
    • Prioritization: Ability to align/prioritize backlog to corporate leadership goals.
    • Productivity: Estimation of story hours completed based on estimates.
  • For team members
    • Eliminate silos: Infrastructure stories are presented to team members as a group. Decision and work are divided as a group. This promotes self-organization and team accountability.
    • Encourage feedback: Stand-ups and retrospectives are used to get immediate and post-release feedback from team members on how to improve processes and future implementations. Allows teams to have partial ownership of their processes.

Collaboration

  • Stakeholders: Stories are submitted by specific stakeholders who provide clear requirements. Stakeholders engage throughout the process for refinement and feedback.
  • Outside teams: Teams outside infrastructure are brought in to participate in relevant evaluation and scoping of stories. This can eliminate common scalability, interoperability, and overexpenditure. Problems that often occur with isolated infrastructure implementations receive attention.

Agility

  • Backlog: The backlog, as in Scrum processes, allows a centralized request database of stories for the team. This backlog can be prioritized and organized to allow quick changes in direction to align with corporate goals.
  • Sprints: Sprints allow the team to have a simple but effective way of evaluating, scoping, and implementing prioritized stories as a team. Because team members assign stories to their sprint backlog based on the amount of points they can complete in a sprint, the team is more effective and ultimately more productive.
  • Stories: User stories replace formalized documents and allow a simple set of requirements to be defined by a stakeholders or IT leadership members. Stories can be further refined and any necessary acceptance procedures can be included to define successful completion.

Accountability

  • Business needs: Backlogs, clearly defined stories, and sprints allow corporate goals to be evaluated and implemented with priority, estimates, and progress visibility.
  • Infrastructure standards: A clear and defined process that increases team communication and story tracking is a foundation before integrating organizational policies. Work standards are enforced by the team and are accountable to the team.
  • Productivity/staffing: A centralized backlog allows IT leadership to review story completion and estimation for evaluating team productivity and staffing needs. It also prevents low-priority stories from being perceived as lost to stakeholders.

These core values enforce the spirit of the Agile method while maintaining standards that are essential to infrastructure support.

2. Challenges

There are two main challenges that we faced in implementing InfraScrum in an infrastructure operations team: Scrum process compatibility with infrastructure specialization and department adoption.

While the Agile method brings improvements in many areas, Scrum itself has many aspects that don't fit with an operations-based team. In Scrum processes, architecture and design decisions are part of the iterative process. They are made as late as possible, with the goal of increasing agility to customer requests. This works wonderfully with a development team where interoperability and product control can exist completely within a team or group of teams. Also, in development teams there is less specialization among peers, allowing cross-pollination to work effectively. However, in an infrastructure operations group, decisions on architecture usually require long-term considerations because of purchasing/budgeting, strict interoperability requirements, support staffing, and knowledge requirements for design decisions. It's usually difficult to change direction on decisions that affect product selection, networking configuration, or security enforcement. A small infrastructure team can also have specific specialization in networking, systems, security, and storage knowledge. Because some stories require specialized knowledge, they must be handled differently as a team. As a remedy to this, stories that are affected by these factors are automatically split into multiple stories, with long-term decisions being worked by architects and leadership before implementation stories are started. On the tail end of this team, accountability on documentation and cross-training can slowly move them from specialization to generalization.

Sprint length is another Scrum characteristic that we realized required modification for use in InfraScrum. Shorter sprint lengths created a meeting overhead that is especially costly to a team that is dedicated to support roles. Because infrastructure teams will release products to multiple platforms and most often perform the release process internally, a set release date is unnecessary for the team. An InfraScrum team will work sprints closer to 30 days or more, with releases happening constantly throughout the sprint. We learned that another option was to perform some planning and retrospectives for several smaller sprints. Instead of a retrospective at the end of a single 30-day sprint, they could be held every other two-week sprint. Regardless of the size of the sprint, expectations for story completion will be based on sprint windows.

Agile method-based processes are foreign to a team experienced in operations-based team processes. Because of a wide variety of core competencies in infrastructure teams, individuals tend to carve out their responsibilities by projects they complete. While this does create strong subject-matter experts (SMEs), it reduces agility and causes silos within a team. To solve this problem, implementing InfraScrum along with enforcement of policies concerning documentation, cross-training, and communication (planning/stand-ups) were included as part of the process.

With any new environment, we run the risk of performing rework if we go ahead and build out environments too early on, especially if we haven't had enough time to test and validate our design one environment at a time with code. How do we align the planning for these tasks so that the required environments are ready for a particular development sprint?

What we learned was that if we don't provide, early on, the specifications and sprint release plan to the infrastructure and data center teams, we won't be able to fulfill the desired requirements for the development teams to complete their tasks and business requirements for the sprints within the release plan. We learned early on that concise planning, communication, and timing became extremely critical to the success of the InfraScrum teams.

3. Current process steps

The current environment build-out process steps were outlined to allow for clearer insight into what the required lead times would be, so that the infrastructure and data center teams could successfully fulfill the business and development sprint release plan requirements. We learned the importance of sharing with the business and development teams what the burn rate (velocity) was, so proper planning could be established early on and we could all be successful in aligning all our deliverable timelines.

Current state: Steps involved to build out new virtual machines for a development, QA, promo, production, and disaster recovery environments

  1. Request form submitted with requirements
  2. Technical spec form reviewed, elaborated, and ready for approval
  3. Quote for pricing sent to vendors
  4. Capital/expense request form submitted for approval
  5. PO submitted
  6. Invoice created
  7. Invoice received with delivery date
  8. Invoice approved
  9. Invoice paid
  10. Hardware delivered
  11. Build-out of spec
  12. Infrastructure team works with development team on install, configuration, and setup of software and application(s)

Burn rate (velocity)

Elapsed time: 60-90 days

Current state: Steps involved to upgrade a current development, QA, promo, production, and disaster recovery environment

  1. Request form submitted with requirements
  2. Technical spec form reviewed, elaborated, and ready for approval
  3. Data center reviews spec and checks in-house inventory for virtual resources
  4. Infrastructure team works with development team on install, configuration, and setup of software and application(s)

Burn rate (velocity)

Elapsed time: 1 day per environment

4. Process potential

We aligned InfraScrum processes to be nearly identical to Scrum. Daily stand-ups, retrospectives, and product owner backlog grooming all function in the same way. While some internal team mechanics will differ slightly, the communication with outside teams and departments will be consistent with Scrum.

The implementation of InfraScrum focused on achieving core values by setting attainable goals. As these goals were met, more advanced milestones were set, consistently drawing the team further into an Agile process. Also, a continuous effort was made to limit meetings to a minimum to maintain support levels and productivity outside of project management processes.

The process for working and completing a story was slightly different for InfraScrum than for other Agile methods:

  • Evaluate product priority, cost/ROI, product options, and alignment with company technology. (Product owner and ScrumMaster)
  • Scope out product impact to existing systems, interoperability, scalability, and support cost. (Product owner and ScrumMaster)
  • Design networks, systems, servers, services, and components with detailed documentation and materials. (Product owner and ScrumMaster)
  • Implement product using design materials with testing/development when impact evaluation requires. (Team)
  • Document product for maintenance, metric/KPI, existing documentation, and support requirements. (ScrumMaster and team)

Summary

After executing our hardware build-out plan early on for our piloted Scrum project, we knew that there would be lessons learned both with resource planning and testing of our environments. We effectively leveraged, early on after our first sprint retrospective, what the gaps where and acted swiftly to enhance the InfraScrum process. We evaluated the outputs during our Scrum piloted project. By proactively building out a new infrastructure in advance, we were better prepared and ready to support the environments within the Scrum development sprint cycle. We worked with the business on having a monthly sprint release planning meeting whereby we reviewed the user story and sprint backlog deltas and worked with and negotiated the reprioritized backlogs to minimize downstream risks toward protecting the sprint development cycle. This meeting also allowed for more effective resource planning and support during the sprint. What we learned quickly is that the more we proactively planned, communicated, negotiated, and elaborated upfront, the less risk we brought with us to each sprint.

Tangible benefits

  • Less rework
  • Reduced risk to the development efforts
  • Reduction in project defects
  • Reduction in sprint impediments
  • Improved sprint velocity for each team
  • Improved ROI for the organization

Intangible benefits

  • Streamlining of communication and team synergy
  • Historical findings provided useful parametric estimation for future sprints and other similar projects
  • Increased team chemistry and empowerment
  • Streamlining of deliverable artifacts replaced through team collaboration and self-organization

Project rationale

The infrastructure and data center is at the heart of almost every large-scale Scrum/Agile development initiative. As much as the founding fathers of Scrum and Agile development have done a great job with understanding the benefits of using this project management framework to bring throughput and ROI back to an organization quickly, there clearly is a gap in how it can fit in within other areas of information technology. New and existing build-outs of infrastructure environments can cause a huge dependency for development work efforts to start or be completed toward meeting the demands of quicker cycle time and throughput. Even the infrastructure and data center areas have their own dependencies with finance and business in receiving approval prior to starting their work efforts and placing orders with hardware vendors.

I selected this project because the use of Scrum and Agile development frameworks is growing fast and is becoming the leader in software development life cycle processes for businesses today. I have been asked numerous times by infrastructure managers how we can leverage and use Scrum well enough so that we can better plan and align dependency tasks to fulfill both the business and development program and project initiatives. Without proper planning and coordination, bottlenecks occur for many projects. Many projects have been delayed or have failed due to the lack of effective and proper processes.

We were able to develop a process that worked well through the use of proper planning, communication, and execution. By using our InfraScrum model, we piloted an enterprise reporting strategic initiative by applying InfraScrum procedures, techniques, disciplines, and principles to all of our environment build-outs.

The following is a snapshot of some KPI's within the project sprint release plan:

Project Release Velocity % Increase/Decrease Impediments
Sprint 1 -33% 18
Sprint 2 +25% 11
Sprint 3 +50% 5

For every sprint, a % increase/decrease reflected more or less work committed and delivered from its predecessor.

Impediments showing a decrease from one sprint to the next reflected an improvement with minimizing risk downstream, as well as the team being able to adapt swiftly in coming up with workarounds and contingencies.

Note: At the time this pilot project was started, we still hadn't completed all the sprints for the entire release plan, so the amount of information available reflects statistics from three sprints out of the total six planned for completion.

Personal/professional expectations

The current pilot project has allowed my organization to test and validate the benefits associated with implementing and applying Scrum techniques, disciplines, and principles. By providing findings and documenting real issues, we were able to achieve our goal and meet our expectations. In turn, real solutions were discovered and tested. I was also able to take the opportunity to compare environment build-out approaches and procedures for all different types of infrastructure and data center environment build-out models.

Project objectives

Findings in this project have become useful for all hosted and nonhosted infrastructure and data center areas. InfraScrum project management performed a multitude of steps to assure that proper planning, control, and execution were effectively and efficiently laid out so that the delivery of software met and fulfilled the expectations of the customer. All Scrum development teams encounter dependencies from infrastructure and data center teams for physical and virtual hardware to be set up and configured as per specification. It's impossible to expect and include infrastructure and data center environment tasks into a given sprint at the same time developers start their work efforts. It's also challenging when you believe you have effectively planned in advance and tested environments, only to find out that things don't work per development requirements. However, there is a way we can make sure we minimize risk and plan in advance by working with the business to identify all hardware and software needs proactively.

The best result was finding all solutions relative to aligning the build-out of environments to be ready to fulfill sprint planning needs for development of a shippable product. We came upon plenty of technical and resource issues during testing of plausible solutions. These detail findings where not to be discussed in this project, but rather certain findings will provide the means for identifying the amount of lead time required so that infrastructure and data center deliverables can be met. We also would determine how to best use similar resources during the preplanning phase of building out environments as well as during the sprint development cycles, when environment troubleshooting support would be required.

This project will be very successful if I'm able to find what planning methods and techniques can best resolve the dependency chain that most development shops encounter when they're trying to complete their tasks. Many Scrum and non-Scrum teams will gain benefit from this paper, which I plan to submit to the participants for their benefit.

I hope you enjoyed my journey through the world of InfraScrum and can take what I've learned and apply it accordingly, so that both infrastructure and development teams can work in better harmony, both benefiting from Scrum and Agile best practices.

References

Agile Advice. Agile infrastructure projects – lessons learned. 2009. Retrieved February 7, 2009, from http://www.agileadvice.com/2005/09/28/agilemanagement/agile-infrastructure-projects-lessons-learned/.

Agile in Action. Infrastructure isn't all it's cracked up to be. 2007. Retrieved February 7, 2009, from http://www.think-box.co.uk/blog/2007/01/infrastructure-brings-pain.html.

Ezine Articles. Scrum sprint zero. 2009. Retrieved February 8, 2009, from http://ezinearticles.com/?Scrum-Sprint-Zero&id=1679334.

Scrum Alliance. 2009. Retrieved February 15, 2009, from http://www.scrumalliance.org/.

Yahoo Scrum Development Group. 2009. Retrieved February 15, 2009, from http://scrumdevelopment@yahoogroups.com.

Article Rating

Current rating: 5 (3 ratings)

Comments

Anita Coggins, CSM, 8/31/2013 10:49:56 AM
I've been doing project management for infrastructure teams for the last 15 years. Most of my support has been at the PMO level. I'm currently working with a client to implement many of these concepts with good success. I would be very interested in any additional metrics and lessons learned as you walk through the pilot. Our biggest challenge is to help development teams understand the necessity for their teams to implement release planning in order to synchronize with infrastructure release and sprint planning. When organizations begin agile practices at the team level, they tend to omit the practice of release planning. However as more and more teams in the organization attempt to deliver value with lean frameworks, the constraint to flow will always be infrastructure. I believe infrastructure is where any organization should start agile practices if they want to be truly agile. This article is a great framework for that model!

You must Login or Signup to comment.