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

Don't keep your Information on ICE

Yesterday, Scrum was such an easy game to play

The Purple Pill in Scrum and Agile

Which Scrum Certification is Best?

Remote Support - PM Network (March 2018)

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)

Q&A with Ken Schwaber

With Scrum being by far the most influential and pervasive framework for delivering Agile projects, I thought it might be interesting to find out why Scrum has been so successful, any challenges it may face when scaling, and how it might evolve in the future.

To investigate these topics further, who better to ask than the co-founder of Scrum itself. Ken Schwaber, who also founded and chairs, graciously accepted my request to answer the following questions.

1. When you first created the Scrum framework, did you believe it could become as widespread as it has?

No, I didn’t. I knew it worked for me at the organizations and on the projects where I used it. I knew waterfall was draining the life out of software development and angering our customers, so I thought I would share it with others. But, as life is very complex, who can ever predict outcomes (empiricism of Scrum).

2. Why do you believe Scrum is the most popular framework for delivering Agile projects?

It is very simple. Every person adds their interpretations, so they can use it in their context and it becomes pretty universally applicable. It is just really, really hard to use; Scrum makes transparent facts that are contrary to human nature’s desire for good things to happen. Scrum sometimes makes really unpleasant things visible. The choice is to figure out what to do to solve the problems, or to “modify” Scrum so the unpleasantness is again hidden.

3. What do you see as the major challenges to scaling Scrum at the enterprise level?

Enterprise cultures are very different from Scrum’s culture. The Scrum Master has to make Scrum work as well as possible, regardless. For instance, a customer demands that something be done by a certain time. Scrum may disclose that is impossible and trade-offs have to be made. The power structure in a hierarchical organization (only tell me good news) often finds that unacceptable. So the customer is caught between desires and possibility.

4. Should the name Scrum Master be changed to Scrum Coach to adhere more to a servant-leader relationship?

I think that is a bad idea.

5. How can non-development projects benefit from Scrum?

Whenever something changes, that is development. When water acidifies, that is the water developing from one state to another. To understand the greatly needed applicability of Scrum, read Tomas Friedman’s book, “Thank You For Being Late.”  Our world is getting more complex, not less. Scrum is needed more, not less. Scrum is a way of dealing with the significant cultural upheaval that we are going through.

6. Where do you see Scrum 5 years from now?

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.

                                                               * * *

I wish to thank Ken Schwaber for his great insights, and Lindsay Velecina at for her assistance during the Q&A process. The world is a little wiser about Scrum as a result.

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 26, 2018 04:42 PM | Permalink | Comments (27)

The Creepy Scope

We are all familiar with scope creep and how if left unchecked it can consume a project pretty rapidly. Depending at what stage of the project we are in when the scope starts to get out of hand, our risk contingencies and planned responses may be too little too late.

In the Scrum world, a major source of scope creep are the items that find their way into the Sprint Backlog and sometimes bypass the Product Backlog refinement process altogether.

Here are three ways the dreaded creepy scope can make their way into the Sprint Backlog and threaten the stability of the Scrum adoption within an organization:

1. Sprint Hijacker
In most organizations there are some very influential stakeholders or customers that don't mind bypassing protocol to get what they want. In fact, it is partly why they are so successful. These individuals want their feature included in the current Sprint and jumping the queue in order to do that is just collateral damage.

Some team members may even develop a rapport with the Sprint hijacker and let some features in, making it more a case of Stokholm Sydnrome than positive feelings toward the hijacker. In these circumstances, both the Product Owner and the Scrum Master need to step in.

The Product Owner needs to consult with the stakeholder to ensure that any requests for "urgent" features find their way into the Product Backlog, and then refined and prioritized along with all the other items. The Scrum Master must shield the development team from any external distractions which reduce their performance or jeopardize the Sprint Goal. The Sprint Hijacker is one of these external distractions.

2. The Boy who cried Wolf
If the Product Owner is not on his/her game, or they are less than honest, they may create an oversupply of Must Have's that should be Should Have's, Should Have's that should be Could Have's, and Could Have's that should be Won't Have's to enter the Product Backlog.

Incorrect prioritization gives a false impression that some features are more important than they really are. When the Product Owner allows this to happen, the Development Team soon gets wind of the boy who cried wolf and this can cause them to lose trust in the prioritization process and the Product Owner. The Development Team may then compensate by adjusting their estimates, or worse still, treat a feature as anything less than a Must Have.

If this is done enough times, the product becomes a very different beast. The key here is to ensure honesty, integrity and transparency in the Product Backlog refinement and prioritization process.

3. GPDoD
I had to fit an acronym in somewhere. GPDoD is my acronym for Gold Plating the Definition of Done. Oh yes it happens. The Definition of Done (DoD) within a Scrum Team is a "shared understanding of what it means for work to be complete, to ensure transparency". As the project progresses, the DoD can change, become more detailed, and require more steps. It is basically a checklist to ensure that everything the team said would be done, is done, and the feature/increment is potentially shippable.

But that's when everything goes right. It can also go terribly wrong. Most of us know what gold plating is. While this is a term we normally associate with waterfall projects, they can still infect Scrum projects even with a rock-solid DoD.

Gold plating can happen through a number of ways: a relationship with a customer or stakeholder that includes some bells and whistles that are not required, an enthusiastic developer who just wants to increase customer satisfaction, misunderstanding of the customer's requirements, miscommunication with the Product Owner, and the list goes on.

This phenomenon is not only limited to the features we and the customer see. Gold plating can also manifest itself down at the code level where da Vinci developers want to tweak the code beyond what is required to meet the DoD, simply because it is aesthetically pleasing to their idea of good code writing.

                                                                * * *

If you are concerned that the creepy scope may visit your Scrum neighborhood, my advice is to grab a large poster and pin it on the wall with large block letters quoting:

"Done means Done. Not Done and then Some!"

Schwaber, K. and Sutherland, J. (2017) The Scrum Guide. 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: February 20, 2018 06:22 AM | Permalink | Comments (17)

3 Signs that your Scrum Team needs a Tune-Up

At the heart of every great Agile project that uses Scrum, is the Scrum Team. These are small but competent groups of individuals packed with all the skills and experience necessary to produce valuable products and services.

The Development Team is the nucleus of the Scrum Team; anywhere from 3 to 9 people who are collectively responsible for each feature and increment they produce. Unlike almost any other kind of team we are familiar with, the individuals that make up the Development Team have no title, no rank, and no specialization exclusivity.

Revolving around the Development Team is the Product Owner and Scrum Master. These three entities form the Scrum Team as a whole. It is the expectation of most projects that the Scrum Team will work productively, consistently and harmoniously. However, this is not always the case.

Let's take a look at 3 warning signs that the Scrum Team needs a tune-up, and some questions that may be asked to help identify the cause.

  1. Reduced Velocity / Increased Lead Time
    Velocity is the amount of work capacity the team can produce every iteration or Sprint. Lead time is the amount of time it takes for an entire process between two defined points, say from Backlog entry to acceptance by the Product Owner. Both velocity and lead time are separate measurements, but closely related. For example, a reduced velocity is likely to accompany increased lead time. When measuring the team's past performance, a sudden reduction in velocity or increase in lead time should be a cause for concern.

    Are there any blockers preventing the team from working at their previous work rate? Does the team have all the tools and knowledge to convert user stories into features? Is the Product Owner giving clear information regarding the items in the Backlog, and prioritizing them in such a way as to optimize the Development Team's work? Is the Scrum Master ensuring that the team is not distracted by external factors, including stakeholder requests?
  2. Bad Apple
    Sometimes a member of the team doesn't fall into line with Scrum's 5 values, especially regarding commitment, focus and respect. In order for any team to function effectively, all members need to commit to their shared goals, focus on the work at hand, and respect each other throughout the project. When one team member becomes the black sheep of the family, it's time to start examining some possible reasons for the behavior.

    Does the team member fully support Scrum? Can the Scrum Master provide any assistance to the team member if the latter does not fully support or understand the Scrum framework with its rules, roles, values, principles, artifacts and events? Did the team member have more authority in their previous role and now finding it difficult to be an equal team member? Is there some kind of conflict between the team member and others within the team? Do they feel appreciated and included at the same level as other team members? Are there any private issues that require attention? Remember stress, fear and depression can be serious conditions that should not be taken lightly. These and many other possible causes need to be investigated before the bad apple infects the rest of the apple tree.
  3. No Show
    The no show Product Owner or Scrum Master is someone who doesn't show up either physically in person, or via other communication methods such as email or phone call. Sometimes the Development Team need input such as Backlog item clarification from the Product Owner, or obstacles removed by the Scrum Master. These issues can manifest themselves several times a day, and a no-show member of the Scrum Team can delay incremental delivery.

    Is the Product Owner and Scrum Master spread too thinly between teams or other responsibilities? Are they committed to the Scrum Team? Did they sign off on the Sprint Goal? Does the Product Owner have true authority over the Product Backlog and is he/she in sync with what the stakeholders need? Is the Scrum Master following Scrum strictly or haphazardly? Is the organization truly adopting Agile/Scrum?

I have only listed 3 signs that a Scrum Team needs close attention, but there are many others. Can you think of any? I would love to hear about your experiences with a Scrum or any Agile team that started to go astray, and was in dire need of a Scrum Mechanic to step in and give the engine a tune up.

Schwaber, K. and Sutherland, J. (2017) The Scrum Guide. Available from:
Griffiths, M. (2015) PMI-ACP Exam Prep. RMC Publications, 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 also be Scrumptious!
Sante Vergini Signature


Posted on: February 10, 2018 05:18 AM | Permalink | Comments (19)

"You can make more friends in two months by becoming interested in other people than you can in two years by trying to get other people interested in you."

- Dale Carnegie