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

Scrum vs Kanban

The Great Pretender

Avoid a red card in Scrum

Q&A with Chief Project Officer - Peter Moutsatsos

What should Scrum look like in 2019?

Scrum vs Kanban

We all love Scrum right? It provides a great framework for providing valuable solutions in an Agile way. When it comes to adopting an Agile framework within organizations, it really has no competitors. But often I get asked the question: "What about Kanban; is that a better way of doing things?"

Of course, this depends on how you define "better". If we are to understand these two powerhouses in the Agile world, it would be prudent to take a brief look at their similarities and differences:



Has specifically defined roles

Does not have mandatory roles

Uses Velocity, Burndown Charts to            manage and measure performance

Uses Lead Time, Cycle Time, WIP, Cumulative Flow Diagrams to manage and measure performance

Agile approach

Lean approach

Uses time boxes

No time boxes, just continuous flow

Work is based around capacity

Work is based around capacity

Daily meeting

Daily meeting

More structured framework

Less structured framework

Uses a product/issue backlog

Uses a product/issue backlog

More concerned with productivity

More concerned with efficiency

No changes allowed during Sprint

Changes can occur as needed

As Shakespeare might have said: "To Scrum or to Kanban, now that is the question." Actually, your organizational strategy or specific business requirement will answer that question better than Shakespeare could ever do. In reality, the two can exist together, and often do.
Take a software upgrade and rollout across an organization for example. Many projects such as this begin with Scrum (delivery of the solution), then transition to Kanban for support and issue logging (maintenance of the solution). This example might be closer to DevOps, but that is another buzzword for another buzztime!
Can you think of any other similarities or differences between Scrum and Kanban?

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: April 30, 2019 11:49 PM | Permalink | Comments (17)

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)

Avoid a red card in Scrum

Categories: Agile, SAFe, Scrum, Scrum Team, Scrumian

When I started this Scrum blog over a year ago, I was encouraged by all the positive attributes of Scrum, and its scalable parents such as LeSS, DaD, SoS, Nexus, SAFe etc. SAFe is what I have been working with since 2018. Having said that, the benefits of Agile and Scrum can only be realized if they are being implemented correctly, and by correctly I mean in terms of the process, regularity, and consistency. In my experience, this is not the case with almost every organisation I have been exposed to.

Here’s some basic examples specific to Scrum. In my own workplace, standups dropped from daily ceremonies to twice a week. Not everyone stands up. The timebox is rarely met (in one case it went twice as long). It is not encouraged to ask questions nor discuss topics at any length during a daily standup, and yet they often are. Almost every participant talks about what they have on today, but rarely anything about yesterday or what they have been working on. This becomes even more important when the daily standups have been reduced to (in our case) twice a week. There are team stand-ups at the program and portfolio level, but very rarely at the project level, where the delivery of value actually takes place. Some critical team members have never been invited to team/project standups, such as testers who are so crucial to governance. The customer is involved to some degree in PI (Program Increment) planning sessions, but rarely throughout the sprint. Retrospectives per value stream are either not held or ineffective, and there is no review ceremony that involves customers to see the progress of incremental delivery, other than the occasional status report or update over the phone or email. I could go on, but I want to end on a positive note.

As my Scrumptious blog bio states: “Scrum is the most popular framework used within an Agile environment to convert complex problems into valuable products and services”. I still hold to this view. But it is up to us as project and Scrum professionals, or team members in a Scrum environment, to pick up the ball and run it through the goal line. When something is not right, call it out. It is for the benefit of the team, project and organization as a whole.

Don’t get a Scrum penalty. Kick a Sprint goal instead.

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: February 28, 2019 05:14 PM | Permalink | Comments (13)

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)

What should Scrum look like in 2019?

Categories: Agile, Scrum, Scrumian


This will be a short blog post, but one that I think is an important topic to think about. A lot of people make New Year resolutions. Perhaps it's to lose weight, get healthy, travel to some exotic destination, or achieve some career goal.

But what are the New Year resolutions for Scrum? How can 2019 influence Scrum's progression as the dominant Agile framework in the world? We can take a look at some of the comments Scrum professionals made during 2018 in this very blog to get an idea of where Scrum may be heading in 2019:

Ken Schwaber
"To deal with greater complexity, we may develop infrastructures that describe how to manage risks and better tolerate R&D. Scrum will be right in the middle as meaningful possibilities emerge."

Mike Cohn
"I hope we see an end to methodology wars; Scrum vs. Kanban, SAFe vs. LeSS, Disciplined Agile, Enterprise Agile and every other scaling framework. Instead of arguing about methodologies, we need to focus more on agile as a large set of practices, some of which work well in combination."

Dave West
"I expect to see Scrum surrounded with more and more amazing practices and technology."

Mike Griffiths
"It would be great if Scrum and all the agile approaches were just wrapped into a better commonly accepted framework for collaborative development. Or replaced completely by something better."

...and our very own

Kiron Bondale
"Agile purity should focus on values & principles - those are too often lost when attempting to be purist about methods and frameworks."

Rami Kaibni
"If Scrum is to survive in industries other than software, then it should be flexible so we need to be realistic about this."

Sante Vergini
"I call on all Scrum advocates to go beyond their certifications, beyond the clock-on and clock-off usage of Scrum at work, to embrace all the richness that Scrum has to offer, and radiate it throughout the world."

What do you think? What New Year resolutions should Scrum make to move it to the next level?

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: December 31, 2018 10:21 PM | Permalink | Comments (17)

"The higher up you go, the more mistakes you are allowed. Right at the top, if you make enough of them, it's considered to be your style."

- Fred Astaire