In my experience, the most successful changes to an organization’s approach to project management have occurred when a small group of practitioners just decided to go for it. Whether they have used an approach elsewhere and want to bring it to their new organization or have heard about something different and want to try it – the grassroots interest and enthusiasm of a group of people who think they can improve their ways of working cannot be matched as a foundation for success. That’s how it was for us at Promega when the .NEXT team decided to try Feature-Driven Development, created a hybrid project management model, and then extended our learning and use of agile as we moved forward.
Sometimes it is a senior management decision to attempt use of a specific, different project management approach on certain projects or within selected parts of an organization. This often involves telling a working team or group that they will start using an Agile approach instead of whatever they have been using, most likely a phase-based or plan-driven approach. This can potentially go well, or could be disastrous, depending on the circumstances. Attempting to use agile on a project for which an agile framework is not a good fit or jamming agile practices into an environment where people are not ready or the culture poses challenges are almost certain to result in poor outcomes and a negative view of agile as an approach to project management.
This is where a hybrid approach comes in. Many organizations can successfully transition from a plan-driven to a hybrid project management approach that blends the working elements of existing plan-driven project management with agile practices to provide results that are aligned with that organization’s needs and goals. If this is what seems to make sense for you, it is important to approach the experiment in a planful and intentional way. This starts by assessing where your organization is on the continuum.
Where Are You?
The business the organization is in
Risk tolerance – both due to the business and due to culture or leadership
Organizational culture
Service life of the products or deliverables
Economies of scale
Need for innovation
In order to consider how to help your organization succeed with a hybrid agile approach, it is important to carefully consider where your organization is on the continuum.
Placement of example companies on the Waterfall – Agile Continuum
A 50-year-old family-owned publishing and consulting company – third generation now running the company; transformed from printing and publishing to software and services company. The original company culture morphed over 50 years from very conservative with a focus on printing and publishing, certainty of outcomes to a more software-oriented and agile product and company culture.
A 40-year-old global biopharmaceutical research and manufacturing company still led by the founder. The founder started the company by walking from lab to lab at a major research university selling a reagent to bench scientists. That entrepreneurial spirit created a very flat and informal business culture and still contributes to rapid and sometimes risky product development initiatives.
A 5-year-old Software-as-a-Service (SaaS) product company having acquired its two biggest customers so far, seeking investors and new customers. This company is very new, still developing its culture and by necessity incredibly agile. Rapid shifts to their evolving platform and needs of their customers require significant agility in culture and practice.
A 55-year-old health insurance company, privately held, very traditional and conservative, but realizing its product and IT practices are out of date. This company reached an epiphany: it recognized that it is as much a technology company as an insurance company. It realized it needed to leverage its best people and technology to evolve and grow their business, and so changed their project model and organizational model to try to become “more agile.”
A 100-year-old community college transforming its student experience with new business processes and technology. This academic institution adopted a product-oriented mindset to change business process and implement technology with more organizational agility than they have ever experienced. They adopted agile and ongoing release methodology to deliver regular and incremental business value and student-facing features.
A 130-year-old builder of submarines for the US Navy and other navies around the world. There is no tolerance for risk when building a submarine that must function under the pressure of the ocean 1000 feet below the surface. Submarines are in service for many decades, and the basic structural design of submarines does not change significantly over these decades. Because of the military connection, there is a strong hierarchical command-and-control culture in place by necessity.
A 90-year-old Scandinavian builder of jet fighter aircraft. Perhaps against typical assumptions of an aircraft manufacturer, this company uses scaled scrum to improve and deliver a better aircraft design every six months, and its base fighter is considered the most cost-effective military aircraft. This is an interesting balance of economies of scale and long service life against a need for innovation and some tolerance for risk if it results in a better product and overall program cost management.
Assessing Projects
There are several things to consider when you are evaluating the types of projects your organizations typically perform and how they help to determine where you are on the continuum. Let’s look at some examples and characteristics of projects that are representative of the ends of the continuum.
First, let’s consider the project environment that is generally predictable: the projects yield deliverables literally or figuratively built in concrete, brick, steel, glass – things are going to be built once and then remain the same for a very long period of time – deliverables with a long service life, like a building, a ship, or a power plant, or implementing a major software system such as enterprise resource planning (ERP) or electronic medical records (EMR).
With projects like these, objectives tend to be stationary – we know what it is we are trying to achieve at the outset and then we know that target is not going to change. In fact, in these scenarios, change is not desirable once the project is underway, and allowing change in the context of the project could be damaging. We have to consider project planning the way one would consider firing a bullet from a rifle – once we fire the bullet, we are not going to be able to guide it on a trajectory – we have to be certain when we fire that we are on target, so we take time and aim carefully.
This means we seek lots of strategic input at the very start of the project. This contributes to a highly detailed plan to enable us to hit that stationary target. In projects that are suitable for a plan-driven or waterfall approach, we generally gain economies of scale on larger projects, and we get 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.
Now, let’s consider a very different project environment. In this environment, project outcomes may be difficult to predict because rapid change is the norm, as is often the case in an environment like technology startups, software development, ecommerce, mobile gaming, life-science research, or new product development. In this environment, the targets are usually moving. Change is good, and the impacts of resisting change could be damaging to the outcome of the project.
Once the work is started, the assumption is that we can guide our work, much like one can steer a guided missile in flight. You launch the missile, you launch the work, and then you can make course corrections to ensure that you hit the moving target or achieve the desired outcome. We seek strategic input throughout the entire project life cycle – it’s not something that is provided upfront and then fixed, but rather input we seek constantly to ensure that we are on the right track.
Waterfall or agile aspects of projects – (Collyer, Warren, Helmsley & Stevens, 2010, p. 108)
Assessing the Organization
When I began teaching agile project management 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 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 (HBR is where Scrum first appeared in Takeuchi and Nonaka’s 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” (as I was drafting this chapter, I literally got an email with this as the subject line).
Agile and hybrid 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 well-known winery are just a few examples of organizations that have adopted agile practices in some form (some as hybrids) 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).
It is critical to assess whether your organization is in a good position to make the transition to an agile project management approach or to a hybrid agile approach. There are a number of areas that should be considered and evaluated as you consider introducing a new 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 or hybrid approaches to project management especially difficult.
Organizations that operate in highly regulated industries may find “full” 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 organizations like these, 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 for whom I have done agile training and coaching 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 or hybrid agile approaches 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 new project management practices 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 or hybrid 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 a new approach, as well as develop good processes to support the implementation.
Tips for Successful Implementation
Leadership buy-in and support
Evangelists
Some small, quick wins – start small, evaluate, adapt
Good training – common training
Build good processes
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. This is once again where a hybrid approach may be your best option – recognizing the history and culture may preclude full adoption of agile, the hybrid approach could acknowledge these aspects while still bringing desirable benefits. 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 will discuss in future chapters, 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 or a hybrid to see how things 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.
Practical Examples
I will refer to my early experiences with hybrid agile approaches at Promega Corporation often in this book. In 2009, a new senior leader (Kari) joined Promega to take on executive oversight of both marketing and IT. Kari had come from a successful career at a regional consulting firm where she grew the business by implementing ecommerce projects using agile practices. Joining Promega, she found a small but enthusiastic group of evangelists willing to embrace and grow some of the agile experiments we’d already tried. Kari brought in some trusted consultants and invested in training to help extend the interest and capabilities, and we began to use agile practices more and more – not only on IT projects but on cross-functional marketing/IT projects as well.
At CloudCraze, I joined a small product development team attempting to use agile (Scrum) led by a VP who was also sold on the necessity to use agile for our software development endeavors. Coming in with previous training and experience as well as credibility in that I had begun to teach agile for the University of Wisconsin, the leadership team embraced and supported ongoing learning and adoption of Scrum – not only for product development but for our customer-facing software implementation projects as well.
While consulting for a large health insurance company, I was asked to spin up and lead a web portal enhancement project on which the company wanted to try agile for various reasons. Despite the challenges present in the scenario, the endeavor did have the support of senior leadership. The company also accepted my offer of some short, semiformal agile orientation sessions to generate some basic awareness of agile within the organization. Agile definitely took off there – after I completed my assignment, the company did a major reorganization of their PMO and their IT department and launched an agile transformation program.
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 and hybrid agile approaches rely on constant direction and involvement from product owners, and many times the people filling this role 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. For example, 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. Again – this is where a coordinated, hybrid approach that allows flexibility depending on the project type, department needs, and other factors can be the best choice. Earlier, I noted the encouraging trend from the late 2010s into 2020 showing that 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/hybrid agile implementations fail or become muted often experience this because the people attempting to implement the new method 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 a new approach and helping them to assess how to get the adoption and implementation on track.
Be careful promising your stakeholders that moving to Agile will increase delivery speed right out of the gate. Methods like Scrum and Kanban help to quickly expose issues around delivery, but they don't fix them. When you first adopt Agile, you will be presented with these opportunities to address your issues, but that takes time and experimentation. Initially you might actually be SLOWER until you can address the right issues. If people come into Agile thinking that at the end of your first Sprint there will be some significant increase in productivity, they might be disappointed and start to think Agile is the problem. Set expectations appropriately and help people learn to see the value in exposing and addressing underlying issues. Show them the value in slowing down to speed up. (Norman, 2019)
Summary
We’ve discussed the importance of understanding where your organization and the type of projects it does sits on the continuum spanning waterfall practices on one end and highly agile practices on the other end. Assessing elements such as culture, risk tolerance, need for scale or innovation, and organizational hierarchy are all important aspects of determining what type of hybrid suits your organization and its projects, and what elements of waterfall and agile you will bring to this hybrid. In Chapter 3, we will discuss how to approach building a hybrid methodology by using the example from an organization where I helped to design, build, and implement a hybrid agile project management methodology that proved to be very successful.