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?
Leaders exert influence for success
Education and Training,
Human Aspects of PM,
New to Project Management,
PM Think About It,
PMI Pulse of the Profession,
Reflections on the PM Life,
Categories: Agile, Benefits Realization, Best Practices, Career Help, Change Management, Communication, Complexity, Education and Training, Ethics, Facilitation, Generational PM, Human Aspects of PM, Human Resources, Innovation, Leadership, Lessons Learned, Mentoring, New to Project Management, PM Think About It, PMI, PMI Pulse of the Profession, PMOs, Portfolio Management, Program Management, Project Delivery, Project Failure, Project Planning, Reflections on the PM Life, Roundtable, Stakeholder, Strategy, Talent Management, Teams
By Peter Tarhanidis
Whenever I’m in a leadership role I try to be sensitive to the level of influence I gain, retain and lose. Influence is a precious commodity for a leader. And it can be disastrous if you lose your team or if tensions arise that reduce one’s effectiveness to achieve a goal.
I recall one of my client assignments where the goal was to ensure a successful integration of a complex merger and acquisition. The team had slipped on dates, missed key meetings and there were no formalized milestones.
I set up casual meetings to discuss with each member what would motivate them to participate. One clear signal was that management had changed the acquisition date several times. This disengaged the team due to false starts that took time away from other priorities.
During the sponsor review, I reported there was a communication breakdown and that no one shared this effort as a priority. At that point, the sponsor could have used his position of power to pressure everyone to do their part. However, the sponsor did not want to come off as autocratic.
Instead, he asked if I would be willing to find an alternative approach to get the team’s buy in.
I realized my influence was low, but I wanted to help improve the outcome for this team. So I talked again with each team member to negotiate a common approach with the goal to be integration-ready without having an exact date.
Ultimately, our goal was to have all milestones met while a smaller core team could later remain to implement the integration when management announced the final date.
A leader uses influence as part of the process to communicate ideas, gain approval and motivate colleagues to implement the concepts through changes to the organization.
In many cases, success increases as a leaders exert influence over others to find a shared purpose.
Tell me, which creates your best outcomes as a leader: influencing others through power or through negotiation?
by Cyndee Miller
Ahhh, late December—my time for curling up with some holiday bonbons, a nice bourbon and obsessively reading every year-end recap article, deep analysis, listicle and infographic out there. There’s loads of stuff on music, politics, books, technology, business and just, well, 2016 life in general. (The Economist even has a country of the year. Spoiler alert: It’s Colombia.)
But there’s not a whole lot of ink devoted to what went down in project management over the past year. So consider this a not-so-super-scientific look at the year that was in Project Management Land.
But on a grand scale, things were looking pretty good. The global economy continued to regain its footing (although not quite everywhere.) And project, program and portfolio managers remained in high demand across sectors and around the world. With good reason, they’re getting stuff done even amidst mind-boggling change.
No shocker here, much of that change revolved around tech, with industries like aviation and healthcare going in for major upgrades and overhauls. The Internet of Things entered the buzzword lexicon a few years back, but in 2016 we started to see what it might mean for project pros in everything from mobile to the once-staid auto industry. And as more and more devices get connected, project managers entered the front lines of the battle against cybersecurity threats. Then there are the drones, coming soon to a project site near you.
Even in such a tech-drenched year, there is no doubt that it still comes down to people. Robots will not take over the profession any time soon. For one thing, their leadership skills are just not where they need to be. Plus, they stink at managing teams.
2016 was a powerful reminder that project, program and portfolio managers are at heart change agents. Sitting at the intersection of strategy and the status quo, they’re the ones who figure out how to make change happen—and stick. And process-fueled technical knowledge alone isn’t enough. Strategic leadership skills are a must-have—and that message came through again and again and again.
Strategy is all about the pursuit of advantage—which means achieving the right goals at the right time. There’s a reason PMI’s Thought Leadership Series and Pulse of the Profession In-Depth reports focused on benefits realization. In 2016, it wasn’t just knowing how to deliver the goods, but why the goods matter.
Those are my highlights. What’s your big takeaway from the year? Is the great debate over agile approaches actually still a debate 15 years after the manifesto was published? How are PMOs faring? And what happens when there’s a PMO agile smashup?
Agile, connected cars, change management, whatever—what are you thinking about as 2016 closes?
By Christian Bisson, PMP
My last post about change stuck with me, so I want to revisit the topic by focusing on organizational cultural change here. Culture change means implementing new habits, new ways of thinking, new ways of working and so much more.
It presents a major challenge.
Why? Well, it’s more than processes, tools or documents—creating an organizational culture means changing people. This is as challenging as it gets.
When you’re looking to implement a culture change, here are few items to consider:
1. It takes time.
Most people will expect cultural changes to take a max of a few weeks, which is generally unrealistic. To level set expectations, share a roadmap of your changes.
The map should include high-level milestones of what the change will entail — training, meetings, etc. Then specify the objectives so people are on the same page as to why this is being implemented.
The roadmap will ultimately show that the changes are under control. It should mitigate any concerns or problems people will imagine.
2. You’ll need support.
A culture cannot be changed by just one person. There needs to be buy-in and it must be obvious.
I once had to implement daily Scrums with about 15 people, all of whom were accustomed to daily Scrums being long, painful meetings.
Changing that perception to one where meetings would last less than 10 minutes, where people would be on time, stand up and commit to the work they would aim to accomplish, was a challenge. I started by seeking out the colleagues in the group who were already on board with the change.
These early adopters helped me push others to stand up, be on time and ultimately helped keep things rolling when people went on tangents or brought up items out of turn. They were the first to jump in and “commit” to tasks rather than just saying whatever to get the meeting over with. It created a snowball effect, and we soon had efficient 10-minute meetings in place.
It’s a small example of a culture change, but it shows that having buy-in made all the difference.
3. Seek feedback.
All team members react different during a culture change. Some will let frustration accumulate and burst when it’s too much, others might complain as time goes, others will be constructive, others will never share, etc.
You want to take control over that by welcoming feedback, as often as you can, from as many people you can. Obviously, don’t talk to everyone everyday. Use your judgment — for example, you might want to talk to those colleagues impacted the most every week, while speaking to others only monthly.
While more time-consuming, gathering feedback from people is better done one on one. It gives you a chance to connect with the individual. If you speak in large groups, the majority of people will remain quiet while others take over.
How have you tried to implement changes to your organizational culture? Share your stories and your tips!
by Roger Chou
When the Bureau of Standards, Metrology and Inspection in Taiwan's Ministry of Economic Affairs decided to adopt ISO 21500 as the Chinese National Standard (CNS) for project management, they turned to a virtual team of volunteers to review and implement the standard.
After being asked to head this committee, my first step was to make Scrum practices the method for doing the work. From there I worked to:
1) Centralize collaboration.
Since our committee of more than 30 volunteers (broken into three teams) worked virtually, we needed a tool to communicate and collect information. We relied on the LINE communication app and Google Docs.
2) Create a product backlog.
This backlog was a key reference tool for the committee. It included key stakeholder interviews and user stories that established the needs of CNS.
For example, one story said:
“As the Committee for Chinese National Standards on project management, I want the second version revised to cover our terminology standards so that it won’t waste our time in reviewing the work.”
3) Plan how to perform the work.
I instructed the individual team leaders to let their team members break the user stories into tasks to help them feel ownership of the work and create more accurate tasks.
The tasks were set up to be no more than one day’s work over four sprints (4 weeks total), allowing us to keep the momentum going.
4) Meet regularly with team leads.
This helped ensure teams were working effectively with each other. In this meeting the individual team leads were asked the following questions:
- What has my team finished since the last meeting?
- What will my team do before the next meeting?
- Are there any impediments in my team's way?
- Are there any impediments caused by my team for other teams?
5) Hold sprint reviews.
Throughout the length of the project we held weekly sprint reviews with external stakeholders.
This step not only ensured the volunteers worked to a high standard, but since this work was reviewed collectively, it served as a reminder of the commitments the teams had made to each other — be that deadlines or level or work.
When the final project was completed, it was submitted for review with a panel of industry, government and academic leaders. Our final step was to create the final user story:
“As the product owner of the project, I want to collect each volunteer’s reflection and thoughts, of about 100 words, to make the closure report, So that I may let those new to project management know how to run virtual teams with Scrum and I want to publish these stories.”
Work on this project was constant, sometimes requiring long nights of work. But it was always as a labor of love.
How do you streamline projects for virtual teams? What would you have done differently when managing a large volunteer effort like this one?