Integrating Agile in a Waterfall Practice (Part 3): Integrating Your Strategy

In the last article in the series, we explored the Agile methodology, as well as how it can force an organization to shift their mindset. Now that we understand the concepts, terms and roles in the Agile framework – we can explore how to take them into consideration when developing a strategy for integrating Agile in an enterprise.

In the previous article, we mentioned that any number of Agile methods could be applied to a given project setting; assuming that doing so would provide a benefit of some kind. While this is true, it will only work if it’s been fully-implemented.

Implementing Agile Concepts vs. An Agile Framework

If we decided to apply the Kanban approach to visualize project work, then the benefit would be that each team member is “on the same page” for how each task will be achieved. This doesn’t necessarily mean the work will progress any faster or that we see an increase in quality. You might even decide to introduce Scrum concepts with a sprint framework, daily stand-ups, and perhaps if we’re lucky enough – there will be a scrum master to facilitate your interactions. However, that doesn’t mean your teams deliverables will be based on what the business values. In order to do that, you need to set and develop user stories that utilize the product backlog with a clear product owner.

To simplify things: If your plan is to introduce a few concepts of agile, then your goal isn’t to implement Agile as a framework; and therefore, your results won’t achieve the same level of benefits as those who have gone “all-in” with the transformation Agile requires. You must adopt the mindset and behaviors necessary to achieve the full benefits of integrating an Agile strategy.

Team Method vs. Scaled Approach

In PMI’s Agile Practice Guide, these components are described in two different terms, the first being a “team method,” which would include those individual components described above. The second term to know is “scaled approaches,” which harmonizes various methods into an enterprise framework. Each of the team methods can be implemented with some benefits gained, but if expectations are you are now fully Agile, then you run a significant risk you’re overstating the expectations. The Agile Practice Guide provides a graphic on page 100, which shows these team methods and scaled approaches relative to coverage against your delivery processes and the depth of process impact.

Therefore, the key question in developing your Agile integration strategy is, how Agile do we really want to be? Do we desire a complete transformation of both the framework and the corresponding mindset (and organizational) changes? How far do we want to scale through the enterprise? What are some realistic expectations of the value we expect to achieve? Is management pushing us to move towards Agile? If so, how well do they understand the framework and mind-set changes implied therein (after all, who doesn’t want to be more agile)? What does it really take to become an Agile organization?

These four considerations will help explore the answer to those questions. While this is not intended to be a comprehensive list, it should at least serve as a useful starting point for integrating agile into your organization.

Organizational Characteristics: One of the more difficult core concepts of the Agile framework is the decentralization of decision making. The Scrum is most effective when it is self-organized, self-directed, and self-correcting. In other words, management is there to support the team rather than direct the team. Can the organization’s culture, hierarchy, and operating model adapt to this concept? Each one of these areas should be explored. Have you thought of engaging Human Resources in your Agile strategy discussions?

Project Portfolio: Suitability for Agile in your portfolio of projects is typically driven by the way requirements are managed. If there is a need for stringent cost, schedule, and scope controls and reporting you may find value in certain projects by implementing Scrum. In order to implement Agile more fully there will need to be a discussion with the PMO on how to complete the overhaul of the project controls and reporting processes to incorporate how progress and project health are measured.

Resource Commitment: Most Agile experts would agree the value gained by the framework can be largely tied to the focus on getting a dedicated Scrum team together. This can be with either a collocated facility or the tools to work in a distributed, but interactive, team setting. Having the team members allocated across multiple projects significantly degrades this value. In addition, your Finance organization can struggle with how project budget and funding cycles are allocated.
Technology Profile: Agile was originally an outcome of the desire to build software more efficiently and effectively. This business environment remains the “sweet spot” for Agile projects; however, the methodology can be, and is now, effectively deployed in several industries and domains.

Although this is a very high-level description of the general considerations for your Agile strategy, we are hoping it gets you started with thinking through how you might come up with integrating your strategy. You may find this is much more involved than just having the discussion with your IT and/or PMO staff, but will quickly expand into discussions involving Human Resources, Finance, and other key business function areas. In the next article of this series, we lay out some considerations as you begin to implement your Agile strategy.

(This is the third in a five-part series on this topic where we will discuss how organizations can approach or refine their Agile delivery methods.)

---

---

---