By Taralyn Frasqueri-Molina
A lot of things change when moving from traditional project management frameworks to agile ones. But what doesn't change (or shouldn't!) is how much and how often teams communicate.
Agile frameworks don't actually require daily stand-ups or regular retrospectives. But you should consider adding some new trade tools and a few other staples to your project management toolkit if you’ll be working in an agile context. You may find that they quickly become essential to keeping communication flowing through your team—and your project on track.
Here's a short list of tools I've used on all of my projects.
Sync-ups/Planning Meetings: This helps me start a project off right by making sure the product owner and execution team are on the same page. We set expectations, talk requirements and the direction for deliverables in areas such as UX, design, marketing.
Daily Stand-Ups: Quick check-ins with the entire team help gauge project health and bring roadblocks to the forefront sooner rather than later. This is also where we address scope creep, taking note of good ideas that need more exploration before being included in the backlog.
Retrospectives: After each sprint and after each project, a retro helps the team ensure processes are working— and decide if we want to carry over those processes to the next iteration.
Wiki: These often get a bad rap but can act as an excellent centralized location for real-time documentation editing and sharing. In my experience, it can serve as a digital asset management (DAM) system for sharing web copy and design assets. While not a perfect DAM solution, it will do in a pinch.
Instant Messaging: Whether collocated or remote, teams sometimes need quick answers to questions—and a meeting can be overkill as a way to get answers. The challenge with instant messaging, though, is to make sure teams are on the same page about how and when to use an IM tool.
Email: This tool still reigns supreme when it comes to quickly keeping a lot of people in the loop about what's going on. Even if it's an email directing people to a wiki, it's still one of the best tools for mass communication. But maybe not for decision-making!
What tools am I missing? And do you find any of the tools mentioned particularly good or bad for certain kinds of communications? Share your thoughts below.
Agile, or Real Agile?
By Christian Bisson, PMP
Agile approaches allow for iterative and flexible avenues to develop software. (It can be used in other fields, of course; I work in the software world.) When used properly, it can be an efficient way to adapt to changes in requirements and scope, and provide stakeholders with an up-to-date and ongoing list of deliverables to review.
Unfortunately, it’s a misunderstood approach that leaves many of us wondering if they’re really working in agile ways. Here are a few misconceptions I’ve encountered throughout the years.
Things just change names
My favorite misconception of agile is that terms suddenly need new names.
Meetings become “scrums” or “daily scrums”—even though the team is just having a regular meeting. A “week” becomes a “sprint”—even though there is no deliverable/release at the end.
Going faster is agile
Project managers sometimes “crash” a schedule to speed up project deliveries, knowing that it uses more budget in order to meet a deadline. Sometimes “crashing” is confused with “agile,” which is thought to deliver projects sooner and cheaper by having everyone start their work sooner than they would have in a traditional waterfall approach.
Having people start sooner and risk rework is still crashing even if the practice is called “agile.”
Stakeholders don’t have to be involved
Stakeholder involvement is a critical part of the agile approach. It requires them to be available and in constant discussion with the team. This prevents surprises and allows constant feedback.
The misconception I see sometimes is that a team can work “full agile,” with stakeholders only involved when they receive assets and go through their typical review cycles.
We’ll just “try” agile
Agile is not about trying out a new software. It’s a culture, and it involves everyone from stakeholders to the team. Some believe that a few people can “try agile” on a project and see how it goes, even though none of them worked in an agile environment before.
Scope and cost can be fixed
Although agile could work with a fixed cost, it is quite the trap. Agile assumes that what will be delivered is the work that the team was able to deliver in a set amount of sprints, and each sprint will cost a certain amount based on the team’s size (among other things).
This means that if a feature took twice the amount of time estimated because it was decided to create something a bit more complex, then another feature might be removed or budget will be added to compensate. However, if you keep the budget the same but still expect to deliver everything planned on day one, then this more complex feature is simply scope creep.
These are just a few examples of agile misconceptions. My bottom line: When I’m told stakeholders want to use “the agile approach,” I make sure to ask for a definition of agile.
Have you encountered other agile misconceptions? Share them below!
In recent years, agile approaches have rapidly gained ground in many parts of the world—but not everywhere. Some areas of Asia, including where I live (Taiwan), have generally speaking not yet embraced agile ideas and practices, despite their value and potential in the region. For this reason, I’ve been working to promote the adoption of agile approaches.
What is agile? It means being flexible and able to quickly adapt to unpredictability. Agile approaches are useful where the environment is constantly changing, where requirements are not fixed or where stakeholders face constant uncertainty.
Agile is typically used in software development, but it’s becoming more suitable in any organization facing rapid changes. Developed over 20 years, agile practices focus on customer value and emphasizing collaboration.
My work has involved training Agile Certified Professionals (PMI-ACP)®, organizing agile communities, promoting agile practices and reporting on the successful use of agile. I have a digital magazine, “PM-Mag ,” with over 100,000 readers across the Chinese-speaking world. Two of the editors have earned the PMI-ACP® credential.
Through my company, I ‘ve also commissioned reports and articles about the use of agile to generate its acceptance and support. I’ve also taken advantage of other media (such as radio and YouTube videos) to raise awareness of agile in the project management world. And then there are other more novel approaches—like an ACP song played at events and before speeches. I introduced a “Hybrid PM” badge that I award to project managers I see taking up agile ideas.
In the last year alone, I trained 149 PMI-ACPs, accounting for nearly 50 percent of the PMI-ACPs currently working in Taiwan.
It was my honor to win the 2015 Agile Award for Person Who Has Done the Most to Promote Agile. The competition was strong, and I’m very humbled by this recognition.
Currently in their sixth year, The Agile Awards are organized by business management consultancy Yoh to recognize businesses, organizations and individuals who actively promote knowledge of agile, as well as its proper application and development. In the past, the awards have been dominated by Europeans and Americans.
I hope that my recognition will spur more international recognition of agile methods in project management, encouraging the further development of agile in Asia and allowing European professionals to understand agile application and development throughout Asia.
To improve the acceptance of agile even more, I encourage those who have already gained their PMP to learn from agile, especially the concepts of incremental delivery, adding business value and embracing change. These new ways of running businesses can improve the competitiveness of small to medium-sized businesses. The added value is too great to ignore.
By Kevin Korterud
I’m frequently asked how program managers can synchronize projects using waterfall approaches with those using agile or other approaches. As programs are launched to address larger and more complex business problems, harmonizing a program’s projects becomes an essential component of success.
In my last post, I shared two tips for achieving harmony: remember that there’s no such thing as agile or waterfall programs, and make the correct delivery approach choice before a project begins.
Here are two more tips.
3. Establish a Program PMO and an Agile COE
One of the critical success factors for any large program is the program management office (PMO). The program-level PMO enables the program manager to spend time on higher-value activities while the PMO creates the operational governance, reporting and overall management foundations required to run a program.
As agile and other delivery approaches mature, there is a great need for a COE (Center of Excellence) model that fosters efficient and effective delivery approaches for projects on programs. Just as PMI has created a consistent approach to project management, agile and other delivery approaches are at a point in their maturity cycle where consistency is needed for them as well.
An agile COE can facilitate this consistency while serving as a clearinghouse for improved agile practices. This COE can also address different variants in waterfall, supplier and governmental delivery approaches, thus resulting in an overall harmonized approach for program and project delivery.
4. Speak the Same Metrics Reporting Language
George Bernard Shaw once said, “England and America are two countries separated by a common language.” Being a program manager with projects utilizing multiple delivery approaches can feel like living in one country separated by multiple languages!
On a program, it is essential that no matter their delivery approach, projects need to be able to both accurately describe their progress and do it in a way consistent with other projects. When dealing with projects with multiple delivery approaches, a suitable translation needs to be in place for progress metrics. This is particularly necessary for stakeholders such as finance, human resources or other business functions where an easily understood definition of progress is critical.
For example, agile projects do a great job in counting projected versus actual requirements and their weighted points. Using the total and completed requirements, a percentage completion can be calculated that is consistent with a waterfall delivery approach. Other agile-specific metrics such as effort per story point can be used to supplement the core progress metrics.
In addition, even between waterfall delivery approaches there needs to be defined a consistent approach for earned value structures, tracking actual cost and other progress essentials. (Note that aside from progress metrics, the concepts of risks, issues, dependencies, milestones, cost forecasts and governance escalations all remain the same no matter the project delivery approach.)
Program managers are orchestrators of both project delivery and the attainment of business results. They need to be always thinking about eventual business outcomes, no matter which delivery approaches are in play. Remember: no one chooses an airline or car model because the company used agile or waterfall on their projects—it’s all about the experience.
What methods have you seen employed in programs to handle multiple delivery approaches?
By Kevin Korterud
As both a project and program manager, I’m always keen to have projects and programs take the right first steps toward success. In the past, this would involve selecting the unified delivery approach used for all of the projects on a program. The idea was to impart consistency to the way projects were managed as well as produce common metrics to indicate progress.
It’s not that easy anymore. Today’s programs have projects with agile, waterfall, supplier, corporate and sometimes regulatory-mandated delivery approaches. In addition, these approaches as well as the different arrangements made with suppliers (e.g., time and materials vs. fixed price with deliverables) have dramatically increased the level of complexity and diversity of delivery approaches within a program.
So as a program manager, how do I keep all of these projects in sync no matter the delivery method? As a project manager, how can I execute my project in concert with the overall program in order to maximize the value that will be delivered, while avoiding schedule and cost overruns resulting from projects not operating in harmony?
These are emerging challenges for which there are no single easy answers, of course. But I have found a handful of tips useful in getting a program’s projects to operate in a synchronized manner. I’ll share the first few in this post and the final ones in my next post, appearing later this week.
1. Remember: There’s No Such Thing as Agile or Waterfall Programs
Given the mix of project delivery approaches, the program needs to properly segment work to manage the budget, resources and schedule regardless of the project delivery approach. In addition, the schedule alignment points, budget forecast process and deliverable linkages need to be identified between the various projects.
Typically, I find that while there is effort to plan for these items at the project level, the upfront effort for this harmonization at the program level is underestimated or sometimes left out altogether—program managers think the project teams will figure this out themselves. This sets the program up for schedule and budget overruns as well as overall dilution of the program business case.
Some ways for a program manager to harmonize projects on a program include:
2. Make the Correct Delivery Approach Choice Before a Project Begins
The type of delivery approach for a project is determined by the type of work being performed and the end consumer of the project’s deliverable.
For example, a project on a program that is slated to create a consumer portal would be a desirable candidate for an agile delivery method. Another project that involves heavy system integration that a consumer never sees would be a candidate for a waterfall approach. A project to pass data into a government system would likely have its delivery approach set by the governmental body.
So before a project starts, program and project managers should agree on the optimal delivery approach that is the best fit for the project.
Look for more advice in my next post on synchronizing a program’s projects, regardless of delivery method.