Scaling Agile Requirements to support large DevOps adoption Initiatives
Reedy Feggins 120000A43D Visits (6477)
Perhaps one of the most difficult aspect of scaling agile is the ability to quickly identify, develop and translate large business requirements into actionable stories. Recently, I had the opportunity to work with a Program management team incorporate several lean / agile principles into their existing enterprise agile adoption strategy in support of a DevOps initiative. The customer wanted to implement improvements that would allow their teams to establish agile practices along with continuous delivery, continuous testing to allow them to reduce time to value and improve overall end user experience.
During this effort the topic of implementing DevOps for large programs came up and we discussed the need for them to more effectively identify and plan their initiatives to achieve faster times to market.
Here is a short summary of what we did.
With traditional agile approaches, such as those used by Scrum team, the team is provided with relatively clear and concrete set of requirements, usually in the form of a backlog of user stories. This allow the Product Owner and team to quickly review, estimate effort and agree on scope so that the team can focus the remainder of their time on developing high quality code, usually in 1 to 4 week iterations.
Scaling agile often requires the project, or program, to consider requirements at a much higher level, where the business drivers / needs may require the multiple teams working across several iterations, or releases, to deliver the expected value. Pair this with a lack of collaboration and shared understanding between business and IT stakeholders, identifying and decomposing a large set of business requirements often still requires several iteration before the agile team can actually implement the requirement.
However, using elements of the Scaled Agile Fram
Scaled Agile Framework®, or SAFe, provides organizations with a recipe for adopting Agile at enterprise scale and is illustrated in the big picture as seen above.
Created by Dean Leffingwell, SAFe introduced an m
In SAFe, Business epics are larger initiatives found in the Portfolio level and typically cross business, IT organizational (e.g, may require multiple agile release trains), and business releases (e.g., potentially shippable increments) boundaries. In many causes programs may decide to split, or combine, epics into a set of sub-epics, or program epics, to allow them to implement the way they needs.
Scaling requires organizations to use agile practices to tackle larger business problems then a single, or even a small group of, agile teams can handle. In these cases we have seen three key challenges:
1. Limited or disconnected traceability of requirements at the portfolio, program and team level.
2. Lack of coordination across different projects and programs
3. Inability to assess the impact of requirements change on downstream systems and business processes
For example, let’s say an organization wants to use agile practices to implement a large SAP initiative (i.e., Epic) that they would like to undertake. The business users understand the ROI and potentially even the systems that may be impacted. However, due to lack of a transparent of the underlying system requirements, the business users don't know the architectural impact of implementing a specific business initiative (Epic) and may assume the impact on the existing systems is minimal; which in some cases it is not.
By using the SAFe requirements model, the Program management team (Business Owner, Enterprise Architect, Product Manager) were able to model a set of business and architectural requirements (Epics) that the program will use to build out the solution.
In the example below, the specific architectural enablement (Architecture Epic) will extends the runway to better support the business epic. And by using, Rational Team Concert to plan across teams and releases, the PPM team was able to plan that the architecture epic to proceed the business epic by a few sprints, instead of being done sequentially, thus shortening the overall delivery of the business initiative
Note the following
We first established project areas for a set of agile release trains, using Rational Team Concert to help manage the plans, teams, source code and builds. We also setup a single RTC repository to manage the Features and sub-epics. Each ART would be able to independently plan and track progress while the Product Management, UX, Release Management and shared teams would use a single program area to link to both the stories being executed by the ART teams as well as to create and plan delivery for the specific stories and tasks that they were responsible for, see figure below.
By using IBM a combination of Collaborative Lifecycle Management (CLM) tooling, Kanban, and Story Driven development practices, IT and business worked together to identify, refine and plan their projects and programs across multiple agile iterations. This approach provided the traceability the PPM team need to visual their programs and helped to plan large initiative better.
Developing solutions collaboratively is not easy; it takes commitment and direction. However, by leveraging the skills an experience of the business users, and IT, and by continually “inspecting and adapting” our process to learn better practices, you can optimize success with their agile adoption activities.