Agile Framework: Growing Pains and Progress

By: Matt Angerer

Agile methodologies like Scrum have become increasingly popular in software development since the Agile Manifesto was published in 2001. Scrum is an agile framework (or process) for product development, not project management.  Sources state that the earliest known agile software project occurred in 1982, but the mainstream adoption of the framework didn’t occur until about 20 years later. During those 20 years, software IT projects leveraged the Waterfall framework originally devised by NASA. The continuous feedback loops of the Waterfall framework introduced an inherent level of risk that often manifested itself with defects discovered very late in the delivery lifecycle. Winston Royce of NASA detailed the Waterfall framework in 1970, but made a point to emphasize that his proposed software delivery framework was inherently risky and invites failure.

Agility is the act of basing actions on current reality, as opposed to being predictive or plan-driven. According to Exploring Scrum: The Fundamentals 2nd Edition 2013, agility has two primary facets: physical agility and mental agility. The Agile framework itself isn’t rocket science to learn; conceptually, it’s pretty easy to grasp. The difficulty lies in the execution of Scrum on a day in and day out basis.

The Challenge in Scaling Agile

In typical Scrum fashion, your Product Owner (PO) is feeling pressure from the stakeholders to schedule more user stories into an upcoming Sprint. Meanwhile, your Scrum Master is busy protecting the team from unnecessary distractions and the team is growing weary from sprint after sprint. The stakes couldn’t be higher to deliver a high quality product to the business who has invested millions into this new IT project. Failure isn’t an option. 

While agile strategies certainly offer the promise of faster time-to-value and improved quality, scaling challenges continue to plague Agile teams. Managing multiple agile projects scaled across a global enterprise remains a significant challenge, particularly without sacrificing quality. This can be especially problematic in the fast-paced industry of software development.

The reality is that most organizations have a long-standing history of implementing software with a traditional Waterfall framework. If you look at global ERP implementations of SAP or Oracle, the framework laid out by a Solution Integrator (SI) is prototypically a waterfall with sequential feedback loops: Plan, Analyze, Design, Build, Test, and Deploy. However, many teams are now realizing the benefit of “Mini Teams” within the larger Project that dance to the beat of the Agile drummer. Let’s start with the basics before introducing a few tools like HP Agile Manager, HP ALM, and the NexGen Synchronizer.

Start with a Visionary Roadmap

Prior to launching any new project, particularly an agile one, development teams must first ensure they understand everything going into that project. By doing so, your team will be able to realistically calculate time and resource commitments. In order to launch a project, the best practice approach is to create a visionary roadmap that includes all of the project variables.

Once the initial proposal has been approved, the overview can then become a critical part of the project roadmap. Skipping the “visionary workshop” is like forgetting the flour in your cake recipe. It’s a vital part of realistically calculating time and resource commitments, and assists management in selecting projects that align with your organization’s goals and capabilities.

Continual Improvement and Monitoring

Given the fast-changing needs of the development industry, it will also be necessary for your team to monitor the project continuously. In the past, time-reporting systems were common, but today that’s no longer sufficient. By incorporating up-to-the-minute visibility into your work strategy, your team will be better equipped to make the strategic decisions necessary for completing projects quickly.

Although the initial proposal may contain a large number of indistinct features, those features can then be broken down into smaller, defined components more easily utilized in the next phase. Recall that agility is the act of basing actions on current reality, as opposed to being predictive or plan-driven. This very principle of Agile requires everyone to continually monitor the current build and not blind themselves with an outdated MS Project Plan or GANNT chart that is no longer relevant.

Agile Gone Global

Beyond the basic concepts of continual improvement and monitoring, your Agile teams must work together during Sprint Reviews to select the user stories they will commit to. It’s logical to break down user stories into manageable tasks and is nothing new in the field of project management. It’s also necessary for the team to meet on a daily basis to discuss the progress made. But, how does an organization manage multiple Agile projects across a global organization?

It’s unrealistic for geographically dispersed development teams to co-locate into one physical location for every IT project. Another challenge facing organizations worldwide is integrating their Quality Assurance (QA) teams into the testing efforts of each Agile sprint. In the next ResultsPositive blog, we’ll introduce a tools framework that your organization can leverage to help:

  • Manage multiple IT projects (both Agile and Waterfall) across a global environment
  • Facilitate both physical and virtual “Daily Stand-Ups” to keeps teams on the same page
  • Implement Virtual Planning, Story, and Task Boards for Decentralized Scrum Masters
  • Cater to your Developers Desire for Less Overhead and More Focus
  • Link Agile IT projects with Waterfall IT projects

Agile framework like Scrum are a mainstay in the development industry. While agility continues to gain traction, growing pains will inevitably follow. Check back next Monday, when we explore a tools framework that allows organizations to effectively scale Agile across the enterprise.

Subscribe for the latest RP Blog Updates:

  • This field is for validation purposes and should be left unchanged.

Related Posts

Leave a Comment

LeanFT Banner