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

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)

Yesterday, Scrum was such an easy game to play

Now I need a place to hide away?

Well it's not quite that bad. Scrum has come a long way since Jeff Sutherland and Ken Schwaber decided to shake up the software development world by creating a framework for making products faster, better, smarter and for lower cost, even if it was named after a bunch of sweaty men huddled together with ill intent for the other side.

The Scrum framework as we know it today kicked off in the mid 1990's when they both presented their paper at the OOPSLA conference. But it may interest you to know that it was almost a decade earlier when Hirotaka Takeuchi and Ikujiro Nonaka first coined the term "Scrum" in relation to product development. This revelation came after their study of successful manufacturing firms where they noticed that the winning formula was cross-functional teams iterating during overlapping phases.

Scrum made its way into many organizations over the next 15 years, but it wasn't until 2010 that Jeff Sutherland and Jeff Schwaber finally laid down the framework in a semi-official form we know today as The Scrum Guide. There have been five versions of the guide released since 2010, with the latest being in November 2017.

Scrum has since evolved into a powerhouse for delivering successful Agile projects. But is there any quantifiable data to support its widespread adoption? There certainly is. The "State of Scrum 2017-2018 - Scaling and Agile Transformation" produced by the Scrum Alliance gives us some great insights into the game of Scrum and how it is played today.

Before we look at this data, it's important to know that the information was captured through 91 countries, 27 industries, and over 2000 respondents. 78% of the respondents were in the USA and Europe, while only 10% were located in Asia. Given that Asia represents 58% of the world's population, and is the fastest growing economic region and will be for at least the next decade or so, the Scrum Alliance may want to increase their respondent representation in this region for future reports.

How many use Scrum?
94% of respondents use Scrum in their Agile practices. This is broken down into two main areas. While only 16% use Scrum exclusively, 78% use a mixture of Scrum with other approaches such as XP and Kanban.

What about Team Size?
We all know that a good Scrum Team should be small and flexible. Most people believe that aside from the Product Owner and Scrum Master, the development team should consist of between 5-9 members. The report confirms this, and the average Scrum team size was 7.4. Of the 2000 respondents, 8% had team sizes between 1-4 members. 78% had 5-9 members, while 13% had 10+ members.

Sprint number and length
The average length of a Sprint was 2.4 weeks which sounds about right. An interesting thing I noticed was that the average number of Sprints per project was only 5. This could be that a lot of projects were feature updates or a small list of features regarded as a single project, rather than a huge release. This could also be disguised as a Release or Product Roadmap broken down into small "projects". If we multiply the average Sprint length (2.4) by the average number of Sprints per project (5.0), we get a 12-week average duration for Sprint projects. This was indeed confirmed in the 11.6 weeks reported in the State of Scrum.

Scrum Events
81% of respondents held a Retrospective after the Sprint. This seems high at first glance, but when you really think about it, it's really not acceptable that almost 20% of Scrum teams don't even hold a Retrospective. The whole idea of Agile and Scrum is to Inspect and Adapt, and particularly with processes and team performance, this is hard to do if the team isn't meeting for a Retrospective.

87% have a daily Scrum. Now this is where I start to grind my teeth. Is this a Scrum Master issue, or a team just not committed to Scrum? Similarly, only 86% hold a Sprint Planning meeting before a Sprint. I wonder what these teams were thinking when they head into a Sprint with no formal plan for the next iteration. We respect adaptive planning in Scrum, but progressive elaboration does not mean we can enter the current iteration without knowing what we will do and how we will do it. The Definition of Done and our Sprint Goal is a form of planning, so what the heck was going on in their minds?

                                                                * * *
If your Scrum projects are not half the Scrum they use to be, it is time to buckle down and look at the processes you are deploying and if they follow the Scrum Guide's framework, all the way down to the roles, rules, events and artifacts that deliver value to the stakeholders. Make sure your Scrum projects are implemented in the best way possible now and tomorrow. Don't long for yesterday!

1. Schwaber, K. and Sutherland, J. (2017) The Scrum Guide. Available from:
2. Scrum Alliance (2017) State of Scrum 2017-2018 - Scaling and Agile Transformation.
3. Wikipedia (2018) Scrum (Software Development). Available from:

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 13, 2018 10:33 PM | Permalink | Comments (16)

The Purple Pill in Scrum and Agile

When implementing Scrum, there are always challenges associated with people, processes or the technology we use. Starting out with the right Agile mindset is a good start. However, transitioning from the old way we did things will always introduce trepidation and anxiety to some level. Transition programs of any kind usually go one of three ways:

  • Full Transition
  • Step or Part-Transition
  • Pretend to Transition

Using a color code from one of our favorite films, the Matrix, we might categorize these as the following:

  • Full Transition - Red Pill
  • Step or Part-Transition - Purple Pill (Ok I added this one!)
  • Pretend to Transition - Blue Pill

The creators of Scrum always intended it to be used as per the Scrum Guide, while considering some minor adjustments that may be necessary to facilitate the project. There are some organizations however that sing the praises of Scrum and Agile, but do very little in the way of implementing it into the organization. I have seen many corporate brochures that use the word "Agile" in almost every paragraph, only to find out that Agile is the furthest thing from their mind. The business environment in most cases is hybrid at best, even in the software development sectors.

A case in point was a BPO service delivery firm I dealt with in the Philippines that provided application development solutions to international corporations. They implemented a mixture of Scrum and XP and yes Waterfall. Scrum by utilizing daily scrums, Sprints, Sprint Reviews, Retrospectives etc., XP by utilizing pair-programming, refactoring, embracing simplicity of code, thorough testing etc., and Waterfall by trying to identify all the requirements up-front to lock down scope. This latter practice of course goes against Agile principles of the inverted triangle where time and cost are fixed, but scope may change.

However, a quick look at their flagship newsletter at the end of the year revealed a case study for the same project describing how this "Agile project was a success." I happen to know the project was a success because the client had a deep pocket and was willing to pay the bloated budget to get the job done. This point was of course left out of the case study.

The reality during the project was that the daily stand-ups were in fact sit-downs. Some daily meetings did not happen on time or at all. Retrospectives were almost a repeat of the Sprint Review where the development team talked about the issues the customer raised about the demo more than discussing ways to improve the team's processes and ways of working together. The Product Manager was AWOL for a day or two at a time, and the Scrum Master; well they didn't have one. Instead, one of the development team members who was also team leader no less, assumed the role of "Scrum Coach" to ensure that Scrum and XP principles would be followed. The team member did this by telling the team what processes to do and not to do, while also assessing individual performance as opposed to team performance. A bad idea in Scrum.

This scenario and ones similar to it is what I call the Purple Pill of Scrum and Agile. It is not a hybrid. It is a hybrid excuse for not taking seriously the Agile mindset and giving it a real chance to succeed.

In his book "Succeeding with Agile - Software Development Using Scrum", Mike Cohn outlines why we do Scrum:

  1. Faster Time-to-Market
  2. Higher Productivity
  3. Lower Costs
  4. Improved Employee Engagement
  5. Improved Job Satisfaction
  6. Higher Quality
  7. Improved Stakeholder Satisfaction

    and my favorite...
  8. What we've been doing no longer works

So, if you are involved in a Scrum or Agile project, remember the three golden rules which will help you decide which Pill to swallow:

  1. Ideally adopt a Full Transition: Red Pill
  2. Never Pretend to Transition - Blue Pill
  3. If you're going to take the Purple Pill, at least implement Scrum properly, even if it is in steps, or mixed with other methods such as XP

Cohn, M. (2010) Succeeding with Agile - Software Development Using Scrum. Boston: Pearson Education, Inc.

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 08, 2018 04:23 PM | Permalink | Comments (21)

3 Roadblocks to Scrum

Transformations of any kind within the organization are challenging at best, and disastrous at worst. Sometimes there are dynamics we can't avoid, like the time it takes for that transformation to take hold, or the strategic priorities of the organization not including a 100% full steam ahead of the Scrum implementation (ie. a never ending series of pilot projects).

There are, however, a few major roadblocks that we do have some control over. The first two deal mainly with process, and the third with mindset. We all know that Scrum has rules, events, roles and artifacts. But it also needs to have people with the right mindset, and who follow a proven process.

So, with all that being said, here are 3 roadblocks to Scrum faced by organizations all over the world:

1. Partial or Late Testing
There are some who don't mind leaving testing until after the Sprint, or partially completed by the end of the Sprint. While there are some exceptional circumstances when this may be required, here is Scrum Co-founder Jeff Sutherland's view on this:

"Do not end your Sprint without your software Done and bug free."

According to Dr. Sutherland, bugs that remain at the end of the Sprint can reduce speed of development by 50%, and in some rare cases up to 1,000%. In order to mitigate this, we need to "change engineering practices, implement continuous integration, and incorporate automatic testing into the builds". 

2. Backlog Mismanagement
Garbage In, Garbage Out! The products and services we produce are only as good as the refined Product Backlog items that find their way into the Sprint Backlog. I have spoken about this in a previous blog, but a poor Product Manager can render the backlog ineffective.

Dr. Sutherland asserts that 65% of features developed are "never or rarely used by customers" which means we are doing a "terrible job" in turning customer's needs into usable and relevant features. This wastes time, money and effort. His recommendation for this problem is to get a great Product Owner, produce a quality refined Product Backlog, and get continuous customer feedback in "30 days or less" to ensure every feature in the Backlog are only the features the customers want.

3. Management Involvement
Even when Scrum has been sanctioned at the Executive level, and is running full swing at the project level, if managers do not embrace Scrum and empower the team to work at the best of their ability, Scrum is going to be running with one engine in a two-engine plane. One major catastrophe, and the whole project could come crashing down.

Dr. Sutherland has some good advice in this area:

"Train your management team on how to run a modern corporation. It needs to be Agile and it needs to be Lean. Managers need to make a big shift in the way they think and how they work with teams."

A lot of this can be facilitated through a Scrum Master or coach to guide the organization and its management in the benefits and implementation of Scrum, but more importantly, the mindset, values and principles of Scrum.

                                                               * * *

Remember, a pitfall is a "hidden or unsuspected danger". It can also be defined as a trap; a trap for those who wish to sabotage the implementation of Scrum. We need to navigate the transformation minefield and avoid those pitfalls in order to reach our destination: a product or service that is fast-to-market, bug free, and what the customer really needs.

Sutherland, J. (2012) How to Avoid the Most Common Scrum Pitfalls. Available from:

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 01, 2018 12:07 AM | Permalink | Comments (18)

I think somebody should come up with a way to breed a very large shrimp. That way, you could ride him, then, after you camped at night, you could eat him. How about it, science?

- Jack Handey