Project Management


Scrum is the most popular framework used within an agile environment to convert complex problems into valuable products and services. In this blog, we will examine all things Scrum to shed light on this wonderful organizational tool that is sweeping the globe. There will be engaging articles, interviews with experts and Q&A's. Are you ready to take the red pill? Then please join me on a fascinating journey down the rabbit hole, and into the world of Scrum.

About this Blog


Recent Posts

The Agile Engine

Scrum at School

Why SAFe may not be safe

Scrum on Mars

Scrum vs Kanban

The Agile Engine

In his 2006 book Innovation: The five disciplines for creating what customers want, Curtis Carlson said that “innovation is the primary driver of prosperity”. Many Agile enthusiasts who have read his book agree, and take it one step further, asserting that Agile is the “world’s best innovation engine” (Denning, 2015).

This may very well be true. Certainly, for Agile practitioners, Agile and its various approaches (i.e. Scrum, Kanban, DSDM) offer a creative and innovative way to solve project problems in an efficient way. It’s the reason why there are literally thousands of blogs dedicated to these Agile methods alone, including this one. So, with so many successes, why change anything at all? If it ain’t broke, don’t fix it, right? But I would argue that this complacency is actually part of the danger.

In our project world, every successful Agile delivery is a celebration of the framework we know so well. Every year the surveys boast growing numbers of successful projects under Agile and Scrum, and our old waterfall friend loses yet another trophy to its Agile counterpart.

But who is driving the Agile engine? People like you and me are driving it. No matter how squeaky clean and efficient the Agile engine is, if there is a problem with the driver, then you won’t get from Point A to Point B, and even if you do, you may arrive at a place you weren’t expecting.

Agile exists as a framework and approach shared by like-minded people with a common purpose. If we rely too much on the engine to steer itself, we will lose the innovation within ourselves, and instead, become slaves to an Agile prescription mandated by certifying bodies and self-proclaimed experts.

We have talked a little about the Agile engine and the driver. But no one has mentioned the fuel. That is a very different story for another time!
                                                      * * *
Denning, (2015). Agile: The World’s Most Popular Innovation Engine. Leadership Strategy. Forbes Magazine.


Thank you for your interest in the Scrumptious blog. If you have any ideas for Scrum topics, please message me here. Until next time, remember, projects can be Scrumptious!
Sante Vergini Signature

Posted on: November 30, 2019 07:09 PM | Permalink | Comments (22)

The Great Pretender


Most of you would probably have heard of the 1950's song with the same title. Here's the opening lyrics to that song:

Oh yes, I'm the great pretender
Pretending I'm doing well
My need is such, I pretend too much
I'm lonely but no one can tell

There are many pretenders in the Agile world. These individuals profess to be advocates for Agile, but either consciously or subconsciously exhibit anti-agile behavior. If I had a dollar for every person I've met in an Agile environment that talks the talk, but doesn't walk the walk, I might have saved a tidy sum.

In a recent experience, I came across a manager at a major Australian institution. Agile was a relatively new thing there, but the IT department in particular had matured enough to adopt some semblance of structure and value that kept the gravy train in operation. The reputation of this manager was one of an Agile though leader, and the department's achievements had been celebrated throughout the institution, so much so that this manager's word was never questioned with regards to the future adoption of Agile. But upon closer inspection, I discovered that the grass wasn't so green on the other side.

It became apparent that there were murmurings from within the team of professionals that reported to this manager. At first glance, major initiatives and deliverables were being met, and these brought value to the relevant business units. So, what could possibly be going wrong in this recent incantation of Agile across the institution?

The answer lies in the Great Pretender syndrome.

The manager knew all too well that "Agile" was a strategy that this institution had bought into, and like anything bought into, people will carry on kicking and screaming before they admit anything is going wrong. This allowed the manager to lead initiatives with an Agile flavor (the talk), such as prioritizing deliverables, planning and documenting only what was required, involving the business at planning sessions, professing that teams manage their own tasks, and the list goes on. However, behind the scenes, the manager was not assisting teams to be autonomous, manage themselves, hold retrospectives and reviews (which would have uncovered errors, issues and anti-value), and continuously improve the adoption of Agile (the walk).

Yes, there were the occasional team meetings, but these were predominantly geared toward making the manager and the delivery of initiatives look as rosy as possible to internal customers. Further, while the manager professed to support transparency and open discussions, when push came to shove, their opinion was final and no one could dispute this. In fact, on one conversation, I recall the manager saying "we don't debate here" when someone pointed out an error the manager had made. In another example, the manager would often micro-manage some team members to the point that the deliverable was not met on time. So rather than remove obstacles and be a servant leader, this manager had become the biggest obstacle of all.

So how does the great pretender get away with anti-agile behavior? Well, there are several reasons, and here are some that come to mind.

The allure of momentum

When you have a few wins on the board, and those wins become consistent, it can feel like the momentum is moving in the right direction. But if you are a puppeteer, you can make the puppet appear to be anything you want it to. De-prioritizing projects that you believe may be politically hot, diverting resources from one project to another to ensure it succeeds at the expense of another, and managing resources with the threat of consequences are just some of the ways to make value only skin deep. Sometimes, it may look like progress, but progress at what cost?

One-way feedback process
How any serious Agile transformation can accept a one-way feedback process between managers and subordinates is beyond me. Yet this is exactly what was happening in this institution. You simply cannot champion a transparent, innovative and fear-free working environment if the feedback process only allows managers to give feedback to subordinates, and the feedback from subordinates stops at the supervisor, and is only in a one-on-one setting. Who in their right mind is going to give honest feedback when the only judge of that feedback is the person you are giving it to? 360-degree feedback must be the hallmark of any good Agile environment, and that feedback must flow up the ladder to at least 2-3 management levels above the subordinate. This greatly reduces the chances of the pretender becoming a toxic leader, or their immediate manager protecting them from senior management review.

Emotional debt
You can only stomp on people for so long, even if it is ever so effortlessly. Just like technical debt, emotional debt can build up over time and bite you back. This is precisely how revolutions begin. A project may be tracking well on paper as evident through the deliverables being met, but festering within the belly of the collective can sometimes dwell resentment, anger and demotivation. Fear may drive human motivation in the short term, but in the long run, the human spirit yearns to break free and be what it is destined to be: Agile.

Can you think of any examples of the Great Pretender in your workplace? Is your Agile environment really only skin deep? Is your servant leader really just a leader of servants?

"He who is not a good servant, will not be a good master." - Plato

Thank you for your interest in the Scrumptious blog. If you have any ideas for Scrum topics, please message me here. Until next time, remember, projects can be Scrumptious!
Sante Vergini Signature

Posted on: March 31, 2019 02:05 AM | Permalink | Comments (15)

Q&A with Chief Project Officer - Peter Moutsatsos

Peter Moutsatsos

Recently, I have been thinking about the relatively recent role of the Chief Project Officer in organizations. How do they stack up against other CxO's and how do they assist organizations provide real value to customers compared to a CIO or CTO? To answer these and other questions, I went in search of a senior project management professional who holds that CPO title for a major organization.

Peter Moutsatsos, Chief Project Officer for Telstra, Australia's largest telecommunications company, joins us for a very revealing and fascinating Q&A session. Please welcome Peter to our Scrumptious blog.

1. Why do some organizations need a CPO?

When you consider the accountabilities that all other C-suite executives hold, there is no single accountable person who is on the hook for successful project delivery.  Sure, most CEOs, COOs and CFOs are accountable for the outcomes of major projects, especially how these projects contribute to the financial performance of the company.  However, the delivery of these projects and the advancement of professional project practice are the lead indicators that ensure these successful outcomes are met.  That’s where the CPO can add a lot of value.  The CPO can focus exclusively on successful project delivery, developing project talent, and effective project sponsorship.  A CPO helps an organisation to shine the light on project delivery as a critical skill within an organisation.  CPOs know that corporate strategy is achieved through the execution of successful projects.  A CPO can make sure that the right people have the right tools and skills to work on the right projects that will maximize strategic outcomes.

2. What sets a CPO apart from a CIO/CTO?

I have met and spoken with a number of CIOs on this topic.  The main differences are subject matter expertise, their strategy lens and their place in the corporate value chain.  A CIO/CTO tends to be more upstream in a value chain.  They are mainly accountable for information technology strategy and defining the future information and technology architecture of a business. The CIO/CTO role has become increasingly complex over the years as more companies struggle with accelerating advancements in technology, digitization and cyber-related challenges.  This has meant that their focus has had to change in order to be effective in navigating these challenges. This involves a certain level of strategic thinking, information technology know-how, global connections and technical skills in order to be successful. A CPO tends to be downstream from the CIO/CTO.  The CPO’s contribution is to work with the CIO/CTO to frame project alternatives, select the right projects, help prioritize programs and projects, identify and develop key talent to lead major technology initiatives, develop and maintain project methodologies and to provide quality assurance over project delivery. This way, the CIO/CTO does not need to worry about delivery sufficiency and project management competency.

3. How does a CPO differ from a head of Portfolio Management?

The difference between a CPO and a Head of Portfolio Management is more complex to define.  This is because most companies have a Head of Portfolio Management before they create a CPO. The main difference between the two roles would be separating genuine portfolio management and planning from project portfolio delivery. The different roles would emerge because a business has grown large enough to warrant the Head of Portfolio Management to focus on optimizing the corporate portfolio, balancing trade-offs and priorities within each business unit and ensuring that the right mix of projects are funded.  These high stakes trade-off and portfolio re-balancing activities would detract from the same person also focusing on how well each of the funded projects are performing.  In companies that have many projects in-flight at any one time, the CPO becomes a critical function to monitor the delivery aspects of these projects, without also having to be concerned with optimizing the project portfolio.

4. Is Agile one of the skills a CPO needs in their toolkit?

I know there is a lot of debate at the moment about agile.  I like to frame the debate as being about agile as a mindset vs agile as a method.  I believe a CPO needs agile as a mindset in their toolkit, not so much agile as a method. Of course, knowing about all project methodologies is very useful for any executive to have.  However, a CPO, or any project professional, will be more effective if they can demonstrate flexibility and agility in how they approach a particular project.  Methodology alone is not that important.  What’s more important is knowing how to be an effective leader, understanding your customer and knowing which combination of tools in your toolkit will get the best outcome.

5. How do you see the future growth of CPO's?

I believe every decent sized organization needs a CPO.  I feel that there are quite a lot of CPOs out there at the moment, however, they are probably operating under different role titles.  As these people start to become more valued in their organizations for their ability to advance project delivery and to drive successful outcomes, we will see their roles relabeled to CPO, which will give the impression of a sudden increase in this critical function. The same thing happened in the mid 90s with CIOs.  Before CIO became mainstream amongst the C-suite, they were IT Managers.   The IT Manager role elevated to CIO when these IT managers started to have a greater say over company strategy and technology became an increasing factor in strategic objectives.  The same will happen with the growth in CPOs.  Increasing digitization across all industries, disruption from an increasing number of start-ups and greater pressure on CEOs and Boards to deliver greater returns to shareholders will result in new strategies to combat these challenges. These strategies will be achieved through successful project delivery, so you will see more projects in future and hence a growing need for a CPO.  


You may be asking what does the role of the CPO have to do with SCRUM? I am happy you asked. The answer may exist in one of the answers from Peter himself. One of the key competencies in the CPO's toolkit is an Agile mindset, and while he stresses mindset over method (quite rightly so), most organizations apply a framework for delivering Agile projects. The most popular framework being SCRUM of course. In fact, Telstra adopts SCRUM which I guess is the cherry on top.

So fellow Scrumians, thank you for reading this latest blog post, and a personal thank you to Peter Moutsatsos (LinkedIn profile) for his great responses and contribution to the project management world.

Thank you for your interest in the Scrumptious blog. If you have any ideas for Scrum topics, please message me here. Until next time, remember, projects can be Scrumptious!
Sante Vergini Signature



Posted on: January 29, 2019 02:17 AM | Permalink | Comments (24)

Meet me in the Middle

In early 2017, I was assisting an organization with their Agile transformation. The initial meetings went well, with the Board of Directors approving the overall strategy for implementation, and were excited about the possibilities for better ways of working.

In typical fashion, we began with a few small pilots with the delivery teams, which went very well. After six months of various team formation challenges, mainly to do with former team leads reluctant to relinquish control, these teams became for all intent and purposes, Agile.

When the Board saw such great progress, they were keen to move forward with the organization-wide Agile transition. If the techy people in the company can become Agile, and senior management were also on board with the program, surely other business departments riddled with friendly middle managers wouldn't present much of a problem, right?


The first major challenge in any Agile transformation is changing the mindset. Why? Because there is often resistance. Why is there resistance? Well for a number of reasons, but they are all related to fear or ignorance in some form or another. The most common three reasons middle managers' resist an Agile transformation are:

Loss of control/influence
By their very job title, "managers" manage people, which affords them a degree of control that for the most part served 20th century corporations very well. Regardless of the severity of their autocratic style, managers almost always had control over what the employee worked on, how they worked and where they worked. Agile takes control out of the equation, which means hierarchy, conformity and fear are no longer used as weapons to get work done. When that occurs, innovation, collaboration and flexibility can thrive.

Threat of losing their job
As organizations become more Agile, middle managers find themselves managing less and less people. This may not be such a concern to them if only one or a few departments become Agile, which is the case in most organizations. They could simply slip into other middle management roles. But what about the company that is very serious about making an organization-wide move to Agile and better ways of working? In this scenario, many middle managers will metaphorically barricade themselves inside their various departments and start stocking up on ammunition to resist the Agile revolution.

Hanging on to the past
This phenomenon is more common than you think. Human beings naturally gravitate around the status quo, resisting change, holding on to the past. The past is comfortable, familiar, and a good friend. Unfortunately, the status quo in today's business environment will render the organization: state zero. There is something to be said for the traditions of the past. They help us define who we are as a society today. However, if changing traditions were always taboo, we would still be burning people at the stake. Traditions are great, but when it comes to an organization's survival, I'm afraid they have to take a back seat.

The age of continuous improvement, incremental value delivery and iterative feedback, inspection and adaption is upon us. Agile isn't coming, it's already arrived, and the train has left the station. Many middle managers will miss that train, not because they were late to the station, but because they don't have a ticket. My advice to them is to become more Agile, because in an Agile world, it's all about meeting in the middle, not being middle managers.

Thank you for your interest in the Scrumptious blog. If you have any ideas for Scrum topics, please message me here. Until next time, remember, projects can be Scrumptious!
Sante Vergini Signature

Posted on: August 16, 2018 03:10 AM | Permalink | Comments (40)