Instructional design teams are increasingly looking to agile project management as a way to adopt a successive approximation or iterative development approach, as well as a way to manage the near-constant change we face in our organizations. Agile offers project teams the ability to refine scope as the team gathers more information, checks-in often with project sponsors, develops and releases iteratively, and estimates tasks at a very granular level. It’s a solid method coupled with an attitude that expects and accepts change. The promise is huge.
After the initial excitement about agile wears off, the realization dawns. “I’ve got to get my team/clients/boss/SMEs on board with this … 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. Because if you don’t, it is likely to fail miserably. Ok, so maybe not miserably, but you’re on to something here. Agile is more than a project management method. It’s a culture. The good news is that it solves many of the sticking points with the old waterfall-based approaches to projects.
How agile is different from waterfall approaches
Training, consulting, software development, and other industries all used to manage projects with a waterfall-shaped approach (Figure 1).
Figure 1:
The waterfall model of project management
The trouble with this model is that change happens all the time (and we come up with new ideas and technologies all the time) so we need 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 to the waterfall model. These include:
- Easier project cost and timeline estimating
- Early and often release of a workable product
- Constant learning and improving based on real-world feedback
- Faster identification of errors in assumptions
Why doesn’t every organization use agile methodology? Change and culture.
Yet this agile approach requires an organizational culture that supports learning by doing, constant experimentation, and high degrees of cross-functional communication. And not every organization is there.
Agile’s approach to change is what sets it apart from other project management systems. Agile embraces change. After all, what good is a beautiful eLearning course that hasn’t changed to include current information?
Agile started in the software industry and its roots are apparent in its manifesto: We are uncovering better ways of developing software by doing it and helping others do it. Swap out “developing software” for eLearning, training, development, consulting, planning a wedding, and the manifesto can apply to pretty much any undertaking—the best way to get better at anything is to do that thing and help others do it.
Values and focus, trust and process
The Agile Manifesto goes on to say that, with agile, we value:
- Individuals and interactions over processes and tools
- Working software (or insert your deliverable of choice) 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 first half rather than the second.
Are you noticing a trend in agile language? There’s a lot of people and trust involved: helping, individuals, interactions, collaboration… And if you look at the 12 agile principles (also see 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 project management requires the people of the organization to create a culture that supports agile processes.
Sidebar 1: The 12 Agile Principles
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity—the art of maximizing the amount of work not done—is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
So what is culture?
Organizational culture is the way people behave in organizations, and the meaning that we assign to those behaviors. It includes the organization's values, norms, tools, language, habits, artifacts, and spaces. Culture refers to both explicit and implicit aspects of the workplace. Culture is “the way we do things around here.”
The explicit aspects can be codified in the employee handbook, policies, and the like. The implicit aspects of culture are the things that newcomers have to observe and infer, like communication preferences, management styles, degree of collaboration, definitions of success. These may not be carefully articulated anywhere, but that doesn’t make them any less important to consider. Implementing agile can get a little tricky because many agile best practices affect those “in the air” cultural norms.
What does an agile culture require?
Implementing agile is often viewed as implementing a new tool, maybe even one that will change the culture a bit. Agile can start to change the culture, but the culture also has to change for agile to work effectively.
Constant communication
Team members must communicate with one another. Project sponsors and project leads must communicate. Agile needs organizational cultures that support such frequent communication across organizational boundaries and up and down the hierarchy.
Agile principles encourage face-to-face communication as much as possible. Agile teams meet daily in stand-ups and scrums. A stand-up is pretty much what the name implies—members stand around in a circle and report in on work accomplished, plans for the coming day, and blockers standing in the way. Standing up keeps meetings short and focused.
Presenting information visually is a practical way to achieve constant communication because anyone can take a look at any time. Make planning and project or individual status very visual with prominently placed cork boards and 3x5 cards, or software and apps with group-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. Tasks should be written in such a way that anyone who could be assigned would understand what needs to be done and how to do it. (Learn more about organizing boards and writing cards here.)
Problems need to be reported early. Agile can accommodate changes and upsets well—as long as people are aware that they need to make changes. In fact, the only real problem is pretending that there isn’t one. Agile teams take advantage of stand-ups to express concerns, and they use color coding on planning boards to show which tasks have issues.
Many organizations and individuals have to amend their definition of success to report problems early enough to leverage agile’s flexibility. Management and staff alike have to view problems as problems, not failures. A problem can be solved, but a failure seems irredeemable. So if you view problems as failures, the temptation for a team member is to keep the problem hidden and the temptation for the project manager is to assign blame when problems eventually surface (as they always do).
When everyone accepts that problems are only problems, it suddenly becomes easier for everyone to communicate. Of course, the causes of problems should be researched and learned from—in fact, periodic reflection is an important part of agile—but perpetuating a culture in which problems are viewed as failures doesn’t benefit anyone, least of all the project sponsors.
And that brings us to the need for frequent communication with project stakeholders. Ideally, you’d have project stakeholders participate in the agile process very actively. This isn’t always possible, but you can still communicate via weekly updates to review tasks and scope.
Accepting—even welcoming—change
Agile can leverage change because it focuses on rapid iterations and prevention of waste. However, it can’t accomplish this goal if certain cultural practices aren’t in place.
While it’s tempting to see change as something that gets in our way and keeps us from delivering our work on time and in budget, agile welcomes client requests for changes. Change is not perceived as something to be feared and avoided because those who fear it are prone to resist it—making it hard to propose a change. Or conversely, they may rush to make the change. They want it done and over so they can be comfortable again.
But sometimes the best way to be fast is to go slowly. Agile teams take time to reflect on the change, consider its repercussions on the project, and adjust their tasks and plans accordingly. By accepting change for what it is—an opportunity to support the organization’s need for something different—the team’s attitude is a positive one. Additionally, agile teams periodically reflect on their projects and processes as a whole. By taking 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’s continuous attention to technical excellence and good design. By thoughtfully designing projects from the outset and striving for technical excellence throughout, the team can rapidly accommodate changes because they’ve been anticipated. Teams know there will be changes, so they intentionally design a project that can evolve. And when a project’s technical components are continuously monitored and adjusted, teams don’t have to make major overhauls to the technical base to accommodate change.
Technical excellence and good design might seem at odds with delivering working products frequently, but they’re actually interdependent. By delivering a product frequently, you’re able to get feedback from project stakeholders early and often. This feedback informs the design of the project and its technical requirements. Intentional design and technical capabilities allow for frequent delivery, which is part of welcoming change.
Trust in the team, trust in the project sponsor
This can be one of the hardest cultural changes for organizations to make, particularly for those that thrive on control, but it does result in more efficient, responsive production. Unfortunately, there’s no handy trick like holding meetings while standing or creating color-coded planning boards. This shift must happen from the top of the organization on down and it must be authentic. Appearing to give control without actually doing so undermines trust. When people don’t trust their environment, they spend time and energy protecting themselves, leaving little time and energy to respond quickly to change.
A strong project sponsor who is engaged across organizational and functional boundaries is key to success. This is someone who can make the hard decisions around prioritizing work, and who has the authority and courage to modify the project scope when new information is uncovered or when essential work takes longer than expected. Again, this person must be trusted at all levels of the organization.
One way to build trust among the team members and with the project sponsor is to involve the sponsor in the estimating process. A software development project manager shared this story with me and it sums it up just right:
Many years ago, we asked my project sponsor to be involved in the estimation process. She was initially uncomfortable participating because she "didn't understand the development process," but we included her anyhow and talked through the numbers. At one point we came to a feature request for “online documentation.” The project sponsor estimated eight hours, and the developers on the team all estimated 40 hours. Something was clearly off! This provoked conversation about the feature and it turned out that the developers were thinking of some pretty sophisticated context-sensitive help, while the project sponsor was thinking that a static FAQs page would be sufficient. Because they had such divergent numbers, the conversation brought out the discrepancy. And, after that, she was a much more willing participant in the project. This builds trust, one conversation at a time.
Relentless tuning
In agile’s definition of success, a minimally viable working product is the measure of progress. Activities that don’t directly support that goal are eliminated or minimized. In this way, the team builds deliverables in small increments, releases usable product frequently, and uses those releases as opportunities to collect feedback that will improve the outcome.
At the same time, the agile organization’s culture should foster simplicity—or the art of maximizing the work not done. There’s no advantage to doing extra work because the client might not want any of it. The more work you don’t do, the more time you have for tasks that create exactly what the client does need. Make sure you’re working on essential tasks by communicating frequently with the client to get approval for tasks. Then work only on authorized tasks.
Relentless tuning is baked right into agile’s principles: at regular intervals, the team reflects on how to become more effective, then tunes and adjust its behavior accordingly. One logical time to stop and reflect is at the end of an iteration. These meetings are often called “retrospectives,” which is a wonderfully elegant name for the team just discussing what worked well and what needs to improve. These meetings are another example of the trust required in a successful agile culture. Participants need to trust that everyone was doing their best work during development of the iteration. In other words, these aren’t meetings to assign blame or point out mistakes. Rather, these are opportunities to refine processes and to prepare for the future.
How to get there
If you’re contemplating adopting an agile approach, and the thought of implementing new project management practices and changing your culture seems overwhelming, take a deep breath and use the processes of agile itself to help you. Agile encourages looking at the scope of the whole project and breaking it down into smaller, discrete pieces. So instead of asking yourself, “How will I get this all done?” ask yourself, “What one change can I make to our culture that would have an impact on making an agile adoption successful?” Then plan the tasks it will take to enact that change. After the change has been in place for a while, go out and get feedback from others. How are they feeling about the change? What would they do differently? Is it positively affecting their productivity, attitude, and so on?
You can also spread out the responsibility for creating the change. Collaboration is another tenet of agile, so take advantage of it. Assign others to brainstorm ways to implement agile processes bit by bit so that the switch to agile project management is more of an evolution than a revolution. Similarly, ask others to figure out how to incrementally institute cultural changes. This approach is doubly beneficial: you’re not the only one responsible for the change and when others feel they have a role, they also feel a commitment to seeing the initiative succeed.
There are sure to be bumps along the way. When this happens, take another deep breath and remind yourself that this is when agile performs its best. As a team, evaluate the problem, come up with solutions, and embrace the change.