Adopting Agile Project Management: Corporate Culture Must Match

Instructional design teams are increasingly looking to agileproject management as a way to adopt a successive approximation or iterativedevelopment approach, as well as a way to manage the near-constant change weface in our organizations. Agile offers project teams the ability to refinescope as the team gathers more information, checks-in often with projectsponsors, develops and releases iteratively, and estimates tasks at a verygranular level. It’s a solid method coupled with an attitude that expects andaccepts change. The promise is huge.

After the initial excitement about agile wears off, therealization dawns. “I’ve got to get my team/clients/boss/SMEs on board withthis … or it will fail miserably.”

Yes. You do need to get your team, your clients(internal and external), your boss, and your SMEs on board with this. Becauseif you don’t, it is likely to failmiserably. Ok, so maybe not miserably,but you’re on to something here. Agile is more than a project managementmethod. It’s a culture. The good news is that it solves many of the stickingpoints with the old waterfall-based approaches to projects.

How agile is different from waterfall approaches

Training, consulting, software development, and otherindustries all used to manage projects with a waterfall-shaped approach (Figure1).

Figure 1:The waterfall model of project management

The trouble with this model is that change happens allthe time (and we come up with new ideas and technologies all the time) so weneed a model that allows us to learn and adapt to change on a regular basis.Here’s a new model that I’ve proposed previously in Learning Solutions (Figure 2).

Figure 2:The agile approach to project management

There are several advantages to this agile model, compared tothe waterfall model. These include:

• Easierproject cost and timeline estimating
• Early andoften release of a workable product
• Constantlearning and improving based on real-world feedback
• Fasteridentification of errors in assumptions

Why doesn’t every organization use agile methodology? Change andculture.

Yet this agile approach requires an organizational culture thatsupports learning by doing, constant experimentation, and high degrees ofcross-functional communication. And not every organization is there.

Agile’s approach to change is what sets it apart fromother project management systems. Agile embraces change. After all, what goodis a beautiful eLearning course that hasn’t changed to include current information?

Agile started in the software industry and its roots areapparent in its manifesto: We are uncovering better ways of developing softwareby doing it and helping others do it. Swap out “developing software” for eLearning,training, development, consulting, planning a wedding, and the manifesto canapply to pretty much any undertaking—the best way to get better at anything isto do that thing and help others do it.

Values and focus, trust and process

The Agile Manifestogoes on to say that, with agile, we value:

• Individuals and interactions over processes andtools
• Working software (or insert your deliverable ofchoice) over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Every project has a little bit of both sides of each statement,but agile users have found they’re more effective when they focus on the firsthalf rather than the second.

Are you noticing a trend in agile language? There’s a lot ofpeople and trust involved: helping,individuals, interactions, collaboration… And if you look at the 12 agile principles (alsosee Sidebar 1), you’ll see even more: customer, people, motivated individuals, support, face-to-face, teams,reflect. It quickly becomes apparent why this approach to projectmanagement requires the people of the organization to create a culture thatsupports agile processes.

So what is culture?

Organizational culture is the way people behave inorganizations, and the meaning that we assign to those behaviors. It includesthe organization’s values, norms, tools, language, habits, artifacts, and spaces.Culture refers to both explicit and implicit aspects of the workplace. Cultureis “the way we do things around here.”

The explicit aspects can be codified in the employeehandbook, policies, and the like. The implicit aspects of culture are the thingsthat newcomers have to observe and infer, like communication preferences,management styles, degree of collaboration, definitions of success. These maynot be carefully articulated anywhere, but that doesn’t make them any lessimportant to consider. Implementing agile can get a little tricky because many agilebest practices affect those “in the air” cultural norms.

What does an agile culture require?

Implementing agile is often viewed as implementing a newtool, maybe even one that will change the culture a bit. Agile can start to change the culture, but theculture also has to change for agile to work effectively.

Constant communication

Team members must communicate with one another. Projectsponsors and project leads must communicate. Agile needs organizationalcultures that support such frequent communication across organizationalboundaries and up and down the hierarchy.

Agile principles encourage face-to-facecommunication as much as possible. Agile teams meet daily in stand-ups andscrums. A stand-up is pretty much what the name implies—members stand around ina circle and report in on work accomplished, plans for the coming day, andblockers standing in the way. Standing up keeps meetings short and focused.

Presenting information visuallyis a practical way to achieve constant communication because anyone can take alook at any time. Make planning and project or individual status very visualwith prominently placed cork boards and 3×5 cards, or software and apps withgroup-wide access. Wonder if another team member is available to help you?Check their board. Need to change the priority of a task? Reorder the cards. Tasksshould be written in such a way that anyone who could be assigned wouldunderstand what needs to be done and how to do it. (Learn more about organizing boards and writing cards here.)

Problems need to be reportedearly. Agile can accommodate changes and upsets well—as long as people areaware that they need to make changes. In fact, the only real problem ispretending that there isn’t one. Agile teams take advantage of stand-ups toexpress concerns, and they use color coding on planning boards to show whichtasks have issues.

Many organizations andindividuals have to amend their definition of success to report problems earlyenough to leverage agile’s flexibility. Management and staff alike have to viewproblems as problems, not failures. Aproblem can be solved, but a failure seems irredeemable. So if you viewproblems as failures, the temptation for a team member is to keep the problemhidden and the temptation for the project manager is to assign blame whenproblems eventually surface (as they always do).

When everyone accepts thatproblems are only problems, it suddenly becomes easier for everyone tocommunicate. Of course, the causes of problems should be researched and learnedfrom—in fact, periodic reflection is an important part of agile—but perpetuatinga culture in which problems are viewed as failures doesn’t benefit anyone,least of all the project sponsors.

And that brings us to the needfor frequent communication with project stakeholders. Ideally, you’d haveproject stakeholders participate in the agile process very actively. This isn’talways possible, but you can still communicate via weekly updates to reviewtasks and scope.

Accepting—even welcoming—change

Agile can leverage change becauseit focuses on rapid iterations and prevention of waste. However, it can’t accomplish this goal if certain culturalpractices aren’t in place.

While it’s tempting to seechange as something that gets in our way and keeps us from delivering our workon time and in budget, agile welcomesclient requests for changes. Change is not perceived as something to be fearedand avoided because those who fear it are prone to resist it—making it hard topropose a change. Or conversely, they may rush to make the change. They want itdone and over so they can be comfortable again.

But sometimes the best way to befast is to go slowly. Agile teams take time to reflect on the change, considerits repercussions on the project, and adjust their tasks and plans accordingly.By accepting change for what it is—an opportunity to support the organization’sneed for something different—the team’s attitude is a positive one. Additionally,agile teams periodically reflect on their projects and processes as a whole. Bytaking time to evaluate what is and isn’t working and adjust appropriately,they’re positioned to welcome change when it comes.

This approach complements agile’scontinuous attention to technical excellence and good design. By thoughtfullydesigning projects from the outset and striving for technical excellencethroughout, the team can rapidly accommodate changes because they’ve beenanticipated. Teams know there will be changes, so they intentionally design aproject that can evolve. And when a project’s technical components arecontinuously monitored and adjusted, teams don’t have to make major overhaulsto the technical base to accommodate change.

Technical excellence and gooddesign might seem at odds with delivering working products frequently, butthey’re actually interdependent. By delivering a product frequently, you’reable to get feedback from project stakeholders early and often. This feedbackinforms the design of the project and its technical requirements. Intentionaldesign and technical capabilities allow for frequent delivery, which is part ofwelcoming change.

Trust in the team, trust in the project sponsor

This can be one of the hardestcultural changes for organizations to make, particularly for those that thriveon control, but it does result in more efficient, responsive production. Unfortunately,there’s no handy trick like holding meetings while standing or creatingcolor-coded planning boards. This shift must happen from the top of theorganization on down and it must be authentic. Appearing to give controlwithout actually doing so undermines trust. When people don’t trust theirenvironment, they spend time and energy protecting themselves, leaving littletime and energy to respond quickly to change.

A strong project sponsor who isengaged across organizational and functional boundaries is key to success. Thisis someone who can make the hard decisions around prioritizing work, and whohas the authority and courage to modify the project scope when new informationis uncovered or when essential work takes longer than expected. Again, thisperson must be trusted at all levels of the organization.

One way to build trust among theteam members and with the project sponsor is to involve the sponsor in the estimating process. A software development project manager shared thisstory with me and it sums it up just right:

Many years ago, we asked my project sponsorto be involved in the estimation process. She was initially uncomfortableparticipating because she “didn’t understand the development process,”but we included her anyhow and talked through the numbers. At one point we cameto a feature request for “online documentation.” The project sponsor estimated eighthours, and the developers on the team all estimated 40 hours. Something wasclearly off! This provoked conversation about the feature and it turned outthat the developers were thinking of some pretty sophisticatedcontext-sensitive help, while the project sponsor was thinking that a staticFAQs page would be sufficient. Because they had such divergent numbers, theconversation brought out the discrepancy. And, after that, she was a much morewilling participant in the project. This builds trust, one conversation at atime.

Relentless tuning

In agile’s definition ofsuccess, a minimally viable working product is the measure of progress.Activities that don’t directly support that goal are eliminated or minimized. Inthis way, the team builds deliverables in small increments, releases usableproduct frequently, and uses those releases as opportunities to collectfeedback that will improve the outcome.

At the same time, the agileorganization’s culture should foster simplicity—or the art of maximizing the worknot done. There’s no advantage to doingextra work because the client might not want any of it. The more work you don’tdo, the more time you have for tasks that create exactly what the client doesneed. Make sure you’re working on essential tasks by communicating frequentlywith the client to get approval for tasks. Then work only on authorized tasks.

Relentless tuning is baked rightinto agile’s principles: at regular intervals, the team reflects on how tobecome more effective, then tunes and adjust its behavior accordingly. Onelogical time to stop and reflect is at the end of an iteration. These meetingsare often called “retrospectives,” which is a wonderfully elegant name for theteam just discussing what worked well and what needs to improve. These meetingsare another example of the trust required in a successful agile culture.Participants need to trust that everyone was doing their best work duringdevelopment of the iteration. In other words, these aren’t meetings to assignblame or point out mistakes. Rather, these are opportunities to refineprocesses and to prepare for the future.

How to get there

If you’re contemplating adopting an agile approach, and thethought of implementing new project management practices and changing your culture seems overwhelming, take a deep breathand use the processes of agile itself to help you. Agile encourages looking atthe scope of the whole project and breaking it down into smaller, discretepieces. So instead of asking yourself, “How will I get this all done?” askyourself, “What one change can I make to our culture that would have an impacton making an agile adoption successful?” Then plan the tasks it will take toenact that change. After the change has been in place for a while, go out and getfeedback from others. How are they feeling about the change? What would they dodifferently? Is it positively affecting their productivity, attitude, and soon?

You can also spread out the responsibility for creating thechange. Collaboration is another tenet of agile, so take advantage of it. Assignothers to brainstorm ways to implement agile processes bit by bit so that theswitch to agile project management is more of an evolution than a revolution.Similarly, ask others to figure out how to incrementally institute culturalchanges. This approach is doubly beneficial: you’re not the only oneresponsible for the change and when others feel they have a role, they alsofeel a commitment to seeing the initiative succeed.

There are sure to be bumps along the way. Whenthis happens, take another deep breath and remind yourself that this is when agileperforms its best. As a team, evaluate the problem, come up with solutions, andembrace the change.