(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.)
In the last article in this series, we explored Agile as a methodology, as well as a mindset shift for an organization. In the discussion we explored the concepts of Agile as a family of methodologies and described some of the key concepts, terms, and roles included in the Agile framework. Now that we understand those elements, let’s explore those things and take them into consideration as you develop your strategy on integrating Agile into your enterprise.
Before we go too far into this discussion it should be noted there is a lot of material publicly available on the benefits of Agile and the necessary commitment of the organization as a whole to achieve those benefits. Any number of forums, LinkedIn threads or other Web sites are devoted to this subject and outline the failures or successes in this area. However, in the previous article, it was mentioned any one or combination of the Agile methods can be applied in a given project setting assuming doing so would provide a benefit of some kind. While this is true, it is only true to the extent the methods be fully implemented.
Implementing Agile Concepts vs. An Agile Framework
In other words, if our decision is to start applying the Kanban approach to visualizing project work, the benefits of having each of the team members “on the same page” for each task to be achieved. This doesn’t necessarily mean the work will progress any faster or with better quality (although you may have solved a communication problem). Or, you may introduce Scrum concepts with a sprint framework, daily stand-ups, and have a scrum master to facilitate your interactions. But if you’re not developing user stories using a backlog with clear product ownership, then you may end up with a more collaborative team that is not necessarily driving delivery priorities based on business value. In each of these situations you have implemented some Agile concepts, but you haven’t necessarily implemented Agile as a framework. More importantly, you haven’t adopted the mindset behaviors necessary to achieve the full benefits being realized by those who have gone “all in” on the transformation required.
Team Method Vs. Scaled Approach
In the 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?
To help explore the answers to those questions there are four areas of consideration you can explore. This is not intended to be comprehensive, but rather give you a starting point for your thoughts on coming up with your implementation strategy.
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 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.
