“There is only one correct way to do any job!” said Taylor, smashing one of those real curvy, tricky serves at Deming.
“Let people contribute in the best way that they can envision,” retorted Deming as he calmly returned the serve from 8 feet behind the table.
“Employees are evil and lazy!” screamed Taylor as he sliced a murderous shot high into the air, the backspin causing a local singularity in the spacetime continuum.
“The success of the company is good for all, and people want to succeed,” offered Deming, backhanding a low shot with sideways spin just over the net.
“Managers are the ones that know the answers!” shouted Taylor, cutting his forehand all the way across the table.
“Hmmmmm,” said Deming, who could be a very thoughtful guy given the right circumstances, “the people closest to the problem are more likely to come up with a correct answer.”
“Supervision!”
“Empowerment.”
“Punishment!”
“Trust.”
And on and on. They never did finish the game.
Here’s the interesting thing: we’re still playing this ping-pong game.
Here’s another interesting thing: many people don’t seem to know it.
Many people make the mistake of viewing Scrum and Agile and Lean as sets of practices. “If I do kanban, I’m Lean.” “If I do sprints, I’m scrummy.”“If I do BDUF and most of my projects are late, then I’m waterfall.” (Oops, well, the last one is actually true, but the first two aren’t.)
The thing is, you’re not Lean unless your company commits to the two pillars of Lean: continuous improvement and developing people. You’re not Agile unless you create and foster self-organizing teams. You might be doing a lot of Agile practices, and you might even get better results than you used to, but you won’t be Agile. If you accept this limitation and you are doing Scrum, then you will be doing ScrumBut.
So I smile to myself (I think it’s to myself) when I hear management say things like “We’ll never be totally Agile in this company. There will always be waterfall projects.” I smile because what that really means is that they’ll never be Agile at all. Lean and Agile fit into the framework of Deming’s System of Profound Knowledge. Plan-driven, hierarchical command & control methods descend from Taylor. You can’t follow both at the same time.
Really? Yes. Would those managers supervise and micromanage some employees while supporting and developing others? Would they dictate commitments and solutions to some while allowing others to determine their own fate? Would they trust the people on the Agile projects and punish the ones on the waterfall projects? Would they hold individuals accountable on waterfall projects while holding teams accountable on Agile projects?
Of course not.
What they will do is treat everybody the way they always have. They will beam with pride when teams gather in their little circles every day, and then they will dictate to them that the manager is actually still responsible for delivery and ask for lists of who will be assigned to which task in the next sprint. They will refuse to make priority decisions and instead direct people to work on multiple projects at a time, and they might even decide just how many design documents each team should have. They will do this because that’s how un-Agile projects do it and for some reason this makes management require it of all teams. (What has always seemed odd to me is that they won’t demand that waterfall teams release an increment of working software each month because the Agile teams do it. So I guess it only works one way.)
And they’ll wonder why this Agile thing gets so much hype, since it really doesn’t seem all that different from what they’ve always done. And really, the results aren’t that great.
You can’t be both Agile and not Agile. You can’t be both Lean and fat…er…not Lean. Not at the same time.
If your company is not fully committed to agility then you won’t achieve it, and your results will be a self-fulfilling prophecy of unrealized potential.
About the Author: Alan Atlasis a Soul Musician, Certified Scrum Trainer, and Agile Coach at Rally Software Development. Subscribe today to get free updates by email or RSS.
I smile because what that really means is that they’ll never be Agile at all. Lean and Agile fit into the framework of Deming’s System of Profound Knowledge. Plan-driven, hierarchical command & control methods descend from Taylor. You can’t follow both at the same time.
When I am coaching a team through their first iteration, I often have a Scrum Master and/or team lead pull me aside prior to the retrospective to express concerns.
Sometimes its about things they know the team should address in the retrospective.
(e.g. “we need to get better at estimating”)
It may also be about things they wish the team wouldn’t bring into the retrospective.
(e.g. “we want longer iterations”)
These team supporters are coming from a place of concern for the success of the team and their Agile adoption, but they aren’t trusting that the team will make the right decisions on their own.
They want me to make sure the team talks about - and only about – these specific items, sometimes asking me to explicitly bring the issues in with a softer (i.e. manipulative) approach. I tell them I can’t and I won’t.
I tell them they need to trust the team and trust the process to determine where to focus their collective energy, passion and time in order to improve their process and product. And almost always, the issue a compassionate and involved leader hopes the team will focus on is exactly what the team ends up discussing and moving forward with.
This isn’t just about the team taking responsibility for their work and their improvements, it’s about creating sustainable decisions the team can own.
Good team leaders and Scrum Masters create a space where teams can inspect and adapt safely and successfully, so they can continue to find ways to improve.
While the answer MAY be “Yes!”, I posited that there may be a way to save our PMOs from going the way of the now extinct dodo bird.
8 Ways To Re-Tool a PMO in an Agile Environment
Have the PMO involved in helping rollout Agile on several pilot projects
This experience forms the roots for how the Agile PMO will engage throughout the organization with other project teams.
Besides ensuring that Agile training occurs, the Agile PMO can become the coaches of coaches, training the ScrumMasters of each team. They can also be the Agile voice into the business to ensure the Product representatives are fully bought into their role in Agile.
Learn from Lean: start a Kaizen and Gemba mentality now
The PMO should be the shepherds of continuous improvement so that the Agile adoption is not only sustained; it is vibrantly organic, every improving. This means moving beyond team-level iteration-focused retrospectives.
Kaizen events create cross-team learning. This learning exposes team practices that can be useful at an organizational level. In such cases, the team practices are elevated to the organizational “Standard of Work” (see later item). Moreover, the Kaizen event clarifies when a practice does not serve the entire organization and can remain a team practice, supported by team agreements and adhered to by the team.
In addition, in between Kaizen events, apply “Gemba”. An Agile PMO learns about the organization and spreads knowledge through the organization by being involved in projects. That means going to see, or “Gemba” according to Lean practices.
Being engaged with teams rather than dictating from afar may be a dramatic shift in PMO behavior. And, it is pivotal to teams’ respecting the role of the PMO in creating a successful Agile adoption.
Change your definition of “Standard of Work”
This is not a set of standards defined by and enforced by the PMO for project conformance.
In Agile, as guided by Lean practices, a standard of work is a statement of what is currently useful, how things are currently done. It provides a team a backdrop from which to perform continuous improvement through Kaizen events such as retrospectives.
The Agile PMO, rather than controlling and patrolling, engages in facilitating teams in continuous learning. This PMO encourages empowered teams and amplifies the learning that arises when such teams are truly empowered.
A great way to provide this facilitation and to engender cross-team involvement is to help organize and facilitate program-level and multi-program release planning meetings and product councils. The Agile PMO formulates a rhythm and a continuously improving agenda to help these meetings deliver the greatest benefit across teams.
Along with being facilitative, Agile PMOs act as Servant Leaders. They serve their organizations by finding out what they need and getting it for them.
They lead by serving. They remove impediments. They measure what is a problem for teams so that they can serve teams be removing the problem. They don’t look for status from teams; they look for how they can serve teams.
So, for an Agile PMO, leading the Agile rollout means finding out what teams need and delivering that. It is about creating collaborative plans, not collecting statuses. For more about Servant Leaders in Agile, check out the first section of my book Collaboration Explained.
Provide guidance on regulatory adherence
In organizations that must adhere to Sarbanes-Oxley, FDA, HIPAA, or other regulatory guidelines, the Agile PMO can represent these “red” (immutable) stories in each team’s Product Backlog.
The PMO governance work can be the guide to each Product Owner on how to deliver the documents or features that help the entire organization remain in compliance with these regulatory constraints. Governance is now a service to project teams versus being a control mechanism.
Seek guidance from Lean to use Flow, Pull, and Innovate as guidelines for organizational-level Agile adoption
Much of the guidance here has a hint of Lean about it. That is because PMOs work at an organizational level. Moving Agile beyond one or more pilot teams requires guidance for maturing and scaling.
I recommend applying a 5-step approach which is based on Full, Pull and Innovate principles from Lean Thinking.
Once Development group is working with the business to deliver prioritized, valued items, the Agile PMO can bring in other ‘back office” functions to help ensure a growing Agile adoption.
Finance, HR, infrastructure, the executive team, and others must eventually all accept the Agile approach for true organizational change and value.
The Agile PMO has an opportunity to be the mentors and guides for this growth and maturation.
Foster useful metrics
Let go of that Waterfall security blanket around what are useful project or program metrics.
Determine which metrics to track that directly help organizations concentrate on value delivery.
Whatever does not deliver value is waste. It may be temporarily necessary waste. Or it may be a pernicious, embedded waste that has been assumed to be necessary.
An Agile PMO ferrets out these “false friend” metrics and works with teams to determine metrics around value: test coverage, team velocity, agile adoption assessment, defect counts, definition of done.
RallyDev.com
