Assessing Projects

There are a number of things to consider when you’re evaluating what approach – agile or a traditional plan-driven approach – may be best for a type of project. In a plan-driven or waterfall scenario, the environment is assumed to be predictable – we assume that there’s a tendency toward stability and a way of thinking in terms of projects that deal in concrete, brick, steel, glass. Things are going to be built once and then remain the same for a very long period of time – a long service life, like with a building, a ship, or a power plant.

These targets tend to be stationary – we know what it is we are trying to achieve at the outset and then we note that target is not going to change. In fact, change is bad, and allowing change in the context of the project could be damaging. We have an assumption that the work can be directed. We have to consider it the way that we would consider firing a bullet – once we release that work, we are not going to be able to really guide it on a trajectory, but rather we have to be certain as we start the work that is going to achieve outcomes, so we aim carefully before we release.

We seek all of our strategic input at the very start of the project given some of these other factors, and therefore that drives a highly detailed plan to enable us to achieve that stationary target. In projects that are suitable for the plan-driven or waterfall approach, there is usually an understanding that we gain economies of scale as we go with larger and larger projects, and that we get some economy of scale as we release large increments of the project. We have a strong emphasis on control, on managing all the outcomes, on trying to stick to the plan and assessing our progress and adjusting to closely follow that plan to achieve our goals.

Agile projects assume some different things. We assume that our outcomes may be difficult to predict because rapid change is the norm, as is often the case in an environment like high technology, software development, biological research, and life sciences, where we may see weekly change. This type of environment lends itself to getting value from agile project approaches – the targets are moving. Change is good, and the impact, if we resist change, could be damaging to the outcome of our project.

Once the work is started in an agile environment, the assumption is that we can guide this work, much like one can guide a missile in flight. You launch the missile, you launch the work, but then you can make course corrections to ensure that you achieve the desired outcome. We seek strategic input throughout the entire project life cycle – it’s not something that needs to be given upfront and then ideally does not change, but rather something we seek constantly to ensure that we are on the right track.

Rapid feedback enables us to stay close to hitting the moving target (like that gazelle being chased by the cheetah) that may very well be the strategic objectives associated with this project. We can keep it relevant in the situation by doing rapid iterative releases so that the value can be assessed and aligned with ongoing strategic objectives. We use adaptation to achieve our goals and therefore we give up some degree of control in favor of that adaptation.

Assessing the Organization

In 2011, a question that I asked in class was “is your organization ready to adopt agile as a project management approach?”. As I write in 2020, it’s perhaps more appropriate to ask, “why wouldn’t your organization be ready to become more agile?” Throughout the 2010s, Harvard Business Review (HBR) published a series of articles on agile practices in business (recall HBR is where Scrum first appeared in the Takeuchi and Nonaka article in 1986). These articles (many coauthored by Jeff Sutherland as well as Hirohito Takeuchi) examined the increasing adoption of agile practices and discussed both cautionary perspectives and advocating for the adoption of agile practices. The new buzz phrase that I see everywhere is “organizational agility”.

Agile methodologies have moved out of new product development and software development into many other verticals and organizational types. Organizations as diverse as John Deere (farming equipment), National Public Radio (public radio), Saab (fighter jets), and a winery are just a few examples of organizations that have adopted Agile practices in some form to improve their management and operations and get people out of their functional silos and into new and different ways of thinking (Rigby, Sutherland & Takeuchi, 2016).

You must assess whether your organization is in a good position to make the transition to an agile project management approach. There are a number of areas that should be considered and evaluated as you consider introducing this approach to project management. A thorough, honest, and realistic appraisal of your organization can give you a sense of the size of the hill you are about to climb.

Start by considering your organizational culture. Culture is a complex and multilayered element in this discussion, but one important and obvious consideration is the culture’s willingness to accept or tolerate change. Change is never easy, but organizations with a culture that is especially resistant to change, or that has had difficulty with change in the past, may find adoption of agile approaches to project management especially difficult.

Organizations that operate in highly regulated industries may find agile does not suit or support their other processes or provide a level of comfort comparable to plan-driven project management approaches. That said, there are practitioners who have implemented agile in regulated environments with appropriate focus on testing and validation processes. In fact, it is in organizations like these where hybrid approaches can work well, mixing elements of plan-driven and agile project management to achieve desired results.

Multitiered and highly bureaucratic organizations are likely to find adoption of agile more challenging than flatter organizations with less bureaucracy. The constant and generally informal communications processes inherent in agile come more naturally to the flatter organizations that have already streamlined their processes and trimmed or avoided bureaucracies.

Take a hard look at your middle management. As organizations grow and mature, it is common to see the growth of middle management layers. It is quite common to see middle managers develop a tendency to focus on defining and protecting their turf or fiefdoms, and these organizations have to address these problems, ideally before considering a methodology that will expose these types of organizational dysfunctions.

Bureaucracies and middle management fiefdoms sound fairly daunting, but given where I am based (Madison, WI), many of the organizations I have done agile training and coaching for are state government agencies and the IT department of our flagship state university, as well as within the large insurance companies that are fixtures around Madison. These organizations decided it was worth the effort to try to adopt agile practices to improve their project delivery and operational execution.

Critical Success Factors

As with any change initiative, there are critical factors that can help increase the odds that experimentation and adoption of agile can be successful. The support and buy-in of the organization’s senior leaders are critical, as with any initiative. Cultivation of respected evangelists in the organization who are willing and able to generate interest and support from peers in the organization will help, as will lining up some smaller projects with which to get some quick wins early in the adoption process.

Once the organization decides to go further with agile, it is important to plan for and invest in good training. This lays a solid foundation of common practices and brings most of the organization in at the same level. Developing and training internal experts combined with solid externally sourced training helps ensure that the organization is well positioned to implement agile, as well as develop good processes to support the implementation.

Brian Rabon (n.d.) describes some additional ideas for implementing agile project management. Rabon notes that easing into adoption and being pragmatic in one’s approach is key. Rabon notes that not every aspect of a methodology should be dogmatically implemented, because (as noted previously) company history and culture has a significant impact. The need to embrace change as part of agile is key – a fundamental part of using agile is accepting change. This does not mean abandoning change management, but rather accepting the more flexible perspective that agile brings to change within projects.

Rabon reinforces servant-leadership as an important element. As we’ve discussed previously, servant-leadership is key for the scrum master/agile PM and senior leaders working in agile environments. Rabon reminds us that being a project manager in agile means it is about the team, and that command-and-control methods will not work. Lastly, Rabon suggests finding a good project or customer as a candidate for piloting agile practices. The project might be a small, less-visible project, but the customer should be one that is willing and able to be fully engaged in the ongoing involvement needed throughout the agile project life cycle (Rabon, n.d.).

A common practice when trying new ways of doing things is to do so on low-stakes or under the radar projects. That way, those interested in experimenting with a new approach (Linux servers, agile development, remote work, flex hours, etc.) can see what works and doesn’t work prior to publicizing their experiment. In this way, a small group of practitioners in an organization can try out some practical elements of agile to see how they work in their setting. As a trainer, consultant, and leader, I encourage and support this practice because I have seen it work multiple times, and because the alternative (doing things the same old way) is increasingly unacceptable even while attempting massive change may be too big of a hill to climb all at once.

Typical Impediments

There are challenges typical to the adoption and implementation of agile in many organizations. It’s become widely accepted that rigorous implementation of agile will reveal or highlight problems in other areas – one thing I like to say is that there is nowhere to hide on an agile team, and the same is true in an agile organization.

Often, the challenges are with management or at the organizational level. Many senior leaders think that agile is a quick or magic fix and therefore expect to see the benefits from agile without making real changes in supporting business processes and philosophies. As we discussed in a previous chapter, senior leaders must be part of the change and must in fact be the removers of impediments at the leadership and organizational level.

At the functional level, there are plenty of obstacles as well. Too often, team members, especially those who feel that they don’t really need to be in every daily stand-up meeting, find reasons not to attend, and soon the value of their involvement is lost along with the expectation. Along these same lines, the stand-ups themselves may be poorly run, or run in an undisciplined way that diminishes their value and makes people not want to participate.

Team members also may resist some of the other changes in routines that come with best practice implementation of agile, such as co-location and ready accessibility. The collaborative team work and accountability required for successful agile can be an issue for people who see themselves as above their peers. As well, some people just don’t want to give up their private offices or other perqs of their positions for the relative equality of an agile team.

Agile relies on constant direction and involvement from product owners, and many times the people who are in this role are people who are, or choose to be, too busy to provide the close engagement and involvement required to be a strong product owner. It may also be that they may not be willing or able to make the tough decisions needed to regularly prioritize a backlog of features that can’t all be realized in a single project or release.

Another impediment emerges when managers use the metrics generated in agile to put pressure on the team. Instead of using velocity as a measure of sustainable performance and throughput, they pressure the team to work faster or take on larger commitments.

Additional challenges come when one area in an organization such as IT or product development chooses to adopt agile while the remainder of the organization retains other methods for managing projects. Elsewhere in the book, we’ve talked about the encouraging trend from the late 2010s into 2020 showing that embracing agility throughout organizations is gaining traction, so hopefully this impediment decreases in frequency.

In software development, a challenge comes in the change of mindset from project-based software delivery to an ongoing, sustained delivery model in which a team can maintain a pace of regular value-adding releases. Generally speaking, the change in mindset from getting all features, benefits, and value all at once at the end of a long project can be a problem for organizations – they cannot adapt to the roadmap approach in which prioritized business value is delivered incrementally and ongoing.

The ownership of the product owner role can be a challenge in some organizations. It requires hard choices and discipline to constantly assess the value of the product backlog and accept that you can have some things now and some things in later releases.

Organizations that see their Agile implementations fail or become muted often do so because the people attempting to implement agile ultimately give in to the resistance of the culture and dysfunctional elements. Influential people in the organization, often people who are fearful, resistant or skeptical of any type of project management use this influence to undermine the adoption for fear of the change it may effect or out of impatience or lack of appreciation for the value it could bring. The challenges noted here are where an agile coach can be extremely valuable in reminding an organization why they started with agile and helping them to assess how to get the adoption and implementation on track.

Summary

Implementing agile can take many forms. Whether a grassroots initiative or a top-down decision from leadership, implementing agile practices comes with many challenges and potential impediments. Organizational culture, as with any other significant change, tends to be the largest obstacle to successful adoption of agile or hybrid agile practices. We have discussed several ways to prepare to attempt agile and identified elements of the organization you should know about as you consider whether agile is a fit for your project or for your organization.

In the next chapter, we discuss approaches to scaling agile practices. We will discuss approaches and impediments to implementing agile as well as review questions that should be asked to determine if an organization is ready to start using agile or an agile hybrid.