Mix & Match
by Cyndee Miller
It was almost like watching rival cliques at school, die-hard agilistas matching wits with waterfall purists. The drama was always quite civil, mostly limited to snobbish comments dismissing the merits of the rival approach.
But lately — and frankly, I never thought I’d say this — they’re learning to play nice.
Some of this comes down to organizations not willing to take sides. They’re simply letting the best approach win.
“Most companies are becoming more results-oriented and less methodologically dogmatic,” said Bryan Berthot, PMI-ACP, PMP, project manager, AT&T Entertainment Group in a recent article on PMI.org. “They empower their project teams to choose their preferred project management framework — as long as they deliver results.”
Forget the preconceived notions. Teams are using whatever they need for the project at hand.
Check out the numbers in PMI’s 2017 Pulse of the Profession: While plenty of project professionals said they relied on agile or waterfall for recent projects, 20 percent used hybrid. And 23 percent relied on something other than agile, hybrid or plan-driven approaches, which could be a further blend or customization of approaches.
Social networking king and Silicon Valley mainstay LinkedIn seems like a natural for all agile, all the time. But when the company launched an overhaul of its website, the project leaders decided to go hybrid.
Mind you, this is a company steeped in sprints and fast-track developments, and now it’s adopting an agile/waterfall hybrid approach. The rationale? Allow project managers to incorporate user and stakeholder feedback — while retaining a sense of urgency.
“This hybrid approach enabled us to define requirements at the beginning of the project and provided the needed flexibility and transparency to adapt to the fast-changing requirements,” Ranjit Dhaman, PMP, senior staff technical program manager at the company, told PM Network. “We were building a foundation for future product innovation, and a quick turnaround time was needed to keep up the pace with daily product releases.”
It’s not just agile teams adopting waterfall ways, of course.
French tire-maker Michelin says it’s developing an agile approach to project, program and portfolio management.
“We believe that agility could also be used in multiple ways — in everything we do,” Philippe Husser, senior partner, progress direction, said in PMI’s latest Pulse of the Profession. “The world is changing very quickly around us, so much so that we cannot afford anymore to have projects taking two to five years to deliver because, during this time, the initial requirements have changed.”
The company now has project managers, along with a steering committee and project sponsor, select the best approach for each project together.
It’s just like those fine ladies of En Vogue would say: Free your mind and the rest will follow.
What’s happening on your projects? Do you and your teams gravitate toward one approach? Or are you doing whatever you need to do?
by Cyndee Miller
Agile is the punk rock of project management. After years of living on the fringe, it’s officially gone mainstream—much to the joy of some and the utter dismay of others.
Like punk, it was built around a call to disrupt the status quo.
When a group of software programmers wrote the agile manifesto 16 years ago, the big goal was to embrace change: “to be aware of changes to the product under development, the needs and wishes of the users, the competition, the market and the technology,” Andy Hunt, a co-author of the agile manifesto, told PM Network last year.
While that purpose still holds true, the agile club is no longer limited to software developers, startup leaders and waterfall haters. An HPE survey showed agile’s ascendancy from anti-establishment to mainstream really took off in the past five years, with a significant adoption inflection point occurring around 2010. And check out the current numbers: Ninety-four percent of the survey respondents in the latest VersionOne State of Agile survey said their organizations practiced agile. PMI recently partnered with Agile Alliance on an Agile Practice Guide.
Some of this comes down to the business world’s obsession with digital transformation, which 42 percent of execs say they’ve begun, according to a 2017 Gartner survey. As Jason Bloomberg, president of Intellyx, wrote: Companies are increasingly going agile “to successfully navigate the disruptive waters that threaten to drown them.”
Take South Africa’s Standard Bank. Facing competition from a rapidly expanding fintech sector, this 155-year-old bastion of financial service embarked on a multiyear digital transformation—with a shift to agile software dev at the center, according to McKinsey.
Not everyone, however, was onboard. I know, shocker, right? To change hearts and minds, the company’s CTO and his team held town hall meetings to explain their logic and set targets for the transition, gave teams autonomy to make decisions on how to go about their day-to-day functions, and co-located team members for better collaboration.
So far, so good. In early agile engagements, Standard Bank reported productivity increases of up to 50 percent and unit-cost reductions of up to 70 percent per function point.
But for some, agile’s entrance into the mainstream has given rise to a new challenge: the dilution of the very term. Mr. Hunt told PM Network the word has become “sloganized” and is “meaningless at best, jingoist at worst.”
In that same article, Jordi Teixido, PMP, COO at Strands, Barcelona, Spain, said: “Agile is wonderful when you’re really iterating and collaborating, but it’s also a refuge for mediocre practitioners who are unable to document or express their requirements or forecast what they want to build. If you don’t follow the rules of the game in waterfall, everyone knows it. But in agile, that’s harder to tell from the outside—and because of that, some people use agile on projects that would be far better under waterfall.”
What do you think? Is your organization using more agile? And do companies have a grasp on what the term really means?
Maximizing the Value of Agile
By Lynda Bourne
Everyone wants to “go agile.” But far too many organizations seem to think agile is simply a different way of doing project work that will miraculously achieve major efficiencies.
For the approach to achieve its promise, the upper echelons of the organization need to become agile aware and adapt the way projects are initiated, funded and governed so that the project team can optimize their use of agile processes to create value. After all, one size does not fit every situation in an agile world.
I’d like to look at the differences in the management approach that are needed to maximize the value of agile in different situations.
One quick note: Different agile methodologies have different terminology and approaches. For this post, agile is defined as producing an output using a series of relatively short, time-boxed iterations, or sprints, where the work to be accomplished in each sprint is sized to be relatively consistent (e.g., can be accomplished by a team in two weeks), and what is to be done in each sprint is determined during the lead-up to that sprint.
There are three environments where the agile approach can add value:
1. Maintenance environments: In these efforts, the application of agile concepts without the need for project management overheads can be very beneficial. Techniques including small focused teams, short sprints, backlog prioritization, and management. Burn down reporting can show how much maintenance work is facing the teams, the team efficiencies, and the overall backlog trend.
Agile does not need to be embedded in a program or project to be effective. In this situation, the finance and resources (i.e., the agile teams) are the fixed constraints; the organization’s budgeting procedure funds a predetermined level of staffing on an annual basis. The management variable is the amount of work accomplished each month and deals with new and emerging maintenance issues and minor enhancements in a timely manner based on some effective form of prioritization.
2. Contractual or legal obligations: In projects like these, the scope of work is fixed (or at least subject to formal change control) and the management variables are efficiency and cost consequences. In this environment, with adaptation, a whole range of standard project management processes such as earned value can be applied to the oversight of project work and used for management reporting and project control. The agile teams still function in the traditional agile way, sizing the amount of work included in each sprint, producing usable outputs in short intervals and progressively building toward the completed project. The management challenge is achieving the specified scope within the approved time and cost parameters.
3. Projects that lack a defined scope: In these projects, the client often has a vision of what the outcome should achieve, frequently framed in terms of business improvements. In this situation, the project is on a journey to optimize the delivery of as much of the vision as is sensible. The management variables for this type of project include scope, cost and time.
Decisions will have to be made about which parameters are more important—either as an overall consideration or on an element-by-element view of the various components within the project.
a. In some projects, time to market is a key factor, possibly with scope as the second most important factor. And, to a large extent, how much it costs to achieve the necessary scope within the deadline will be a consequence rather than the control. The primary management challenge is delivering the scope required to implement the vision within the time constraint as efficiently as possible.
b. Other projects have the quality of the vision as their primary drive, and the management challenge is to achieve all of the vision for the optimum time and cost outcomes. Decisions on how much and how long can vary depending on progress toward achieving the vision. Obviously, there must be some cost and time constraints. And a key conversation with the client has to be around the value proposition of still achieving their vision based on cost information to date, with the possibility of adapting the vision based on learned experience as the project proceeds.
c. Lastly, in some projects where the available funds are limited, the challenge for management is to achieve as much of the vision as possible within the defined funding limit, frequently with time as an additional limitation imposed by the funding cycle or the market. To maximize value, the client needs to be fully engaged in the decision-making process around scope inclusions, deferrals, and exclusions.
Once you understand the agile framework you’re operating within, the real challenge is making sure your clients and other senior stakeholders also understand that an agile approach to project delivery requires very different governance and decision-making processes. Organizational agility starts at the top by setting the right challenges for the agile teams within the right funding model. The next step is to use appropriate assurance functions to make sure agile teams are delivering what’s needed to create value—old-fashioned budgeting processes are unlikely to be appropriate.
How do you go about engaging your senior stakeholders in this type of conversation?
by Christian Bisson, PMP
A scrum master is an essential part of an agile team. However, it seems their role is often underestimated or misunderstood. In this article I’m hoping I can shed some light on the value they bring.
How People See Them
Here’s what I’ve heard over time:
Elves of happiness
Since scrum masters want teams to perform well, they want to make sure team members are happy. That sometimes makes others think that all scrum masters are trying to do is to make everyone happy without an actual purpose behind it.
Since scrum masters often talk to the team and gather information about the status of a project, they are often mistaken for coordinators—people tasked with giving a status report to the product owner or taking notes during meetings.
Some people simply have no clue what scrum masters do, thinking they are an overhead that could be removed without any impact because they don’t actually “produce” anything.
What They Actually Do
Help teams grow
One of the scrum master’s main tasks is to educate the team with agile principles, but also to help the team become self-sufficient. In a way, their main duty is to actually become useless as the team becomes more mature.
Scrum masters can do so by sharing agile knowledge and by coaching teams as they go through retrospectives where the team is motivated to talk about how they can improve.
There are so many different roadblocks that can reduce a team’s efficiency—whether it’s poorly defined requirements, inefficient meetings, lack of documentation or communication, or conflicts. A scrum master can help tackle anything that might slow down the team.
Keep the focus on the right place
Not being hands-on in projects allows scrum masters to have a different point of view that allows them to re-focus teams when needed. Whether it’s toward the developers and their commitment to the sprint, or product owners and their focus on a product’s vision, scrum masters make sure to remind everyone where their effort should go.
It can be hard to quantify a scrum master’s usefulness since they do not actually produce deliverables. But having experienced an agile project both with and without a scrum master, I can vouch for their role. They bring so much on a day-to-day basis to the teams they work with, which in turn brings quality products to clients.
Have you experienced working with scrum masters? What do you think is most important about their roles?
By Kevin Korterud
I experienced my first agile project nearly a decade ago. At the time, agile was still an emerging concept. I remember thinking there were all sorts of activities going on that I had never seen on any of my projects. People were standing up for meetings, marker boards were filled with things called “stories” and delivery moved forward under the framework of a “sprint.”
At the center of this whirl of frenetic activity was a person who the team called a “scrum master.” At first, I thought this person was a project manager. But they were doing things that were outside of the traditional project management realm.
Since that first experience, agile has matured and continued to grow in popularity. This trend prompted me to examine the evolving role of the scrum master in complex agile delivery environments. Here are my observations:
1. Agile Delivery is Becoming Mature
Agile delivery teams used to function within isolated pockets. But, as the use of agile—as well as the size and complexity of solutions being delivered—grew, new methods, such as SAFe®, were developed to help orchestrate agile delivery across an organization.
With agile becoming more common in organizations as a delivery method, the overall need for scrum masters’ general process advice diminishes. Agile teams over time—as well as with the support of enterprise framework methods—will become more self-sufficient, which reduces the need for some of the current activities performed by scrum masters.
2. Higher Engagement and Direct Accountability
One of the guiding principles for scrum masters is that they are not supposed to intervene with the team and are not responsible for delivery outcomes.
While a focus on process advice was essential during the early days of agile, today’s larger and more complex solutions demand that delivery quality issues be identified as soon as possible. In addition, there is also a need to ensure on a more frequent basis that the solution being created will yield the desired business outcomes.
Given its proximity to agile delivery teams, the scrum master role is positioned to leverage a higher level of engagement and accountability. In addition to traditional agile process advice, scrum masters should also serve as a durable checkpoint for both delivery quality and alignment to business outcomes.
These checkpoint activities would include reviewing user story quality, monitoring non-functional requirements and checking solution designs against business needs. As other roles in agile delivery possess some form of delivery accountability, the scrum master must also become more engaged and accountable in order to remain relevant.
3. Emerging Project Managers Becoming Scrum Masters
While scrum masters are not meant to be project managers, that notion is preventing project managers from becoming scrum masters, especially earlier in their career. Emerging project managers invariably have some form of solution delivery experience. They know what makes for sound requirements (especially non-functional), designs, testing, quality and implementation plans.
As the level of complexity and scale increases with agile delivery, so does the need for some form of delivery oversight at the agile team level. With the scrum master position in their repertoire, teams would have developed competencies and know-how for scaled agile delivery, release train engineer, program manager, etc.
Scrum masters have played an essential role in the growth and adoption of agile as a practical means of delivery. Their direct interactions with agile delivery teams create a unique opportunity to expand their influence in generating valuable outcomes for end-users, consumers, customers, employees or suppliers. To do so, they need to further extend themselves— both in terms of skills and engagement—to remain relevant in today’s complex delivery environment.
How do you feel the scrum master role has evolved? Are newly minted project managers the scrum masters of tomorrow?