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

Distance makes the heart of Scrum fonder

The Scrum Certification Factory beefs up training courses

Meet me in the Middle

The Scrum Time Machine

The Scrum Time Machine

In the 1970's, I was captivated by the Doctor Who TV series, mainly through its third and fourth "regenerated" main character. My favorite episodes were always the ones involving the Daleks who were "violent, merciless and pitiless cyborg aliens, who demand total conformity to their will, bent on the conquest of the universe and the extermination of what they see as inferior races". Battling such heartless galactic fiends required Doctor Who to come up with his usual ingenious solutions. But when the odds were stacked against him, he always had that ultimate trump card: the Tardis.

The Tardis allowed Doctor Who to travel in time. The best way to solve a problem is to be transported to the time and place of the conflict or issue. In Scrum projects, we can also do this. We have our own Tardis to see back in time, and into the future.

Expert Judgment
PMBOK 6 defines Expert Judgment as "judgment provided based upon expertise in an application area, knowledge area, industry, etc., as appropriate for the activity being performed." While the definition and expectation are that these experts are human, I like to think "experts" can include AI, research literature, best practices, etc. These knowledge experts can take us back in time when certain issues were tackled and resolved by the implementation of knowledge applicable to the context. When we engage expert judgement, we are in fact engaging knowledge, skills and experience gained in the past, and can apply it to the future.

Lessons Learned
Lessons learned in traditional waterfall projects are gathered at the end of the project. This is all well and good when we find past lessons learned that relate to our current project. But what better lessons learned are there than the ones we discover on the project we are working on right now? In Scrum, we capture these lessons learned in each and every Sprint, not just at the end of the project. Further, we analyze these lessons learned and see what we need to change to improve the current and future states. This goes to the heart of the inspect and adapt nature of Scrum projects.

Retrospective Timeline
Continuing the theme of inspect and adapt, the Scrum Team meets at the end of the Sprint, for their final meeting inside the Tardis: the Retrospective. Think of this meeting as an opportunity to take the team's lessons learned throughout the past Sprints, and create an action plan for implementing improvements in the future. An interesting exercise during the Retrospective can include the Timeline technique, to "diagnose the origin and progression of a single problem or a number of problems". First, we define our time range, quite often the past Sprint but could also be the past release. Then the team plots the good, bad and any significant events that occurred during the timeline. Colored sticky notes are used to categorize each of these three states. Creating this graphical timeline gives the team the opportunity to discuss, recall and uncover issues and causes that perhaps would not have been identified by just looking at a lessons learned register, or even discussions during the Retrospective meeting.

Remember the Future
A popular team and stakeholder collaboration game. The team is asked to imagine that the future release (or the project) is already complete and everything is perfect. Each member of the team creates a list of everything that was completed and delivered to make the release so successful. These are written on sticky notes. The team then take their sticky notes, removes all the duplicates, then groups the sticky notes into similar categories. By doing this, the team is creating a memory of the past, by transporting ourselves into the future, and sequencing the steps and events required to get us to that imagined future state.

Project Pre-Mortems
These are, as Mike Griffiths calls it, a "pessimistic view of Remember the Future". Instead of transporting ourselves into the future and imagining the release or project success, we imagine its failure, and then brainstorm the steps that may have led us to this failure.

A Scrum resistant culture, management or staff is analogous to the Daleks. Doctor Who represents the Scrum Master or Coach battling the traditional mindset, and coming up with innovative ways to achieve a transformation. One of the tools used is going back to the past and looking into the future, as Doctor Who often did in the Tardis. If we never look back or into the future, our Scrum projects may end up hearing that dreaded familiar sound that Doctor Who feared so much: "Exterminate! Exterminate!"

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 be Scrumptious!
Sante Vergini Signature




Posted on: July 14, 2018 08:41 PM | Permalink | Comments (33)

The Scrum Cold War

A cold war is all about bluff, threats, posturing, propaganda and one-upmanship. The purpose is to leverage one's influence, especially in the mind of public opinion, but always stopping short of engaged warfare. However, even if we don't use the heavy bombs, and instead use slings and arrows, the damage to the project can still end in a death by a 1000 cuts.

Quite often in organizations, we have several of these cold wars between colleagues, managers and subordinates, and between departments. In Scrum projects, if the team is not in harmony, then a cold war can brew to the surface between the two most notable protagonists within the Scrum Team; the Product Owner and the Scrum Master.

Product Owners have a tough job. They are usually the face of the Scrum project and exposed to stakeholders more than anyone else on the Scrum Team. Therefore, in addition to their role of maximizing the product value by managing the Product Backlog, they also have to play a political game with stakeholders who have their own agendas. Sometimes this dynamic can produce pressure for the Product Owner to perform at a higher than optimal rate, and that pressure invariably trickles down the Development Team, often in the form of pushing extra work onto the team, or in some way compromising Scrum values and principles.

This is a common way for conflict between the Product Owner and Scrum Master to occur. The Scrum Master's role is to protect the team from obstacles and also the integrity of the Scrum framework. Obstacles could be a technology the team needs but doesn't have yet, other departments fulfilling their requirements before the team can proceed, training requirements, protection from stakeholders who distract the team unnecessarily, and also the Product Owner who tries and buck the system by slipping in some extra work or some other form of anti-Scrum pattern, since after all, they (like customers) value results over following Scrum protocols.

The Scrum Master is also not immune from starting the initial fire to a cold war. Conversely to a Product Owner, sometimes the Scrum Master is so obsessed with the Scrum framework, that they often lose sight of the purpose of the project, which is to continually produce value, in the minds of the customer and the Product Owner, after each Sprint. The Scrum Master is also supposed to assist the Product Owner with the Product Backlog and convey the project vision and goals to the Development team. Ultimately, although the Scrum Master's role is more inward looking, it is also responsible for ensuring that the organization effectively adopts Scrum in the most beneficial manner. This can only occur if the Scrum Master works hand-in-hand with the Product Owner, since as I stated earlier, the latter has such an influence within the organization, especially with the stakeholders and customer of the project.

A practice that I always try and promote is for the Product Owner and Scrum Master to sit down at the start of the project and delineate the boundaries of their roles and responsibilities. Further, and very importantly, they should achieve agreement on the right balance between ensuring the value of the project is maximized, and adhering to the values and principles of the Scrum framework.

Conflict in business is often necessary, but war is never so. Neither is the threat of war, nor a death by 1000 cuts that a cold war invariably brings. Healthy conflict between people and philosophies can strengthen the team, project and organization, provided it is handled in a mature and non-destructive manner.

"Never in the field of human conflict was so much owed by so many to so few." - Winston Churchill.

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: June 05, 2018 11:10 PM | Permalink | Comments (19)

How SAFe is Scrum?

One of the issues with Scrum is when we need to expand the team, or the Scrum project size. In other words, scaling Scrum. There are various scaling approaches, but one of the most popular is called SAFe or Scaled Agile Framework.

Many people get confused with the difference between Scrum and SAFe. Is it just Scrum on steroids, or a Scrum project that has outgrown the Scrum Team? Both approaches do share some attributes. For example, they are both based on Agile principles and adopt relatively short iterations.

But what happens when a Scrum project is so large, that there are numerous teams working on different stages of the product? Often these Scrum Teams might have their own Product Backlog, ceremonies and artifacts. Many Scrum Teams also have their own cadence adding more complexity to the project. Coordination of all these activities can start to break down, and Agility is sacrificed.

SAFe extends the functionality of Scrum to allow it to scale to a very large size. It does this firstly by creating four dimensions for the management of these large project: Portfolio, Value Stream, Program and finally Team. Scrum is most applicable at the Team level of the SAFe framework. In other words, when you are viewing SAFe at the Team level, it is very difficult to tell the difference between Scrum and SAFe.

However, at the Program level, we start to see a bigger crossover to SAFe and away from traditional Scrum. At this level, there are multiple Scrum Teams working effectively as a larger team, called the Agile Release Train or ART. They can consist of up to 150 people. Timeboxes here are called Program Increments or PI's which typically consist of 5 iterations. The PI begins with a planning meeting to discuss the vision or goals, and the upcoming features for that PI, in much the same way as a Sprint Planning meeting is performed before each Sprint. Usually the team plans the upcoming 4 iterations, and the fifth and final iteration is called an Innovation Planning iteration or IP. During this "Innovation" part of the iteration, the team can be creative and come up with ideas similar to hackathon. During the "Planning" part of the iteration, the team can hold a retrospective on how to improve the ART during the next PI, demo the achievements of the PI that just concluded, and also plan for the next PI's features.

The Value Stream level put simply is just a bunch of ART's for a larger solution that cannot be delivered using a single ART. At the Portfolio level, you guessed it, the focus is on the management of multiple Value Stream, but also takes into account strategic themes and budget considerations for each Value Stream. During these upper levels, there are many different job roles that we won't get into here, but needless to say, the number, diversity and criticality of these roles also scales with the SAFe framework itself.

So, in order to make Scrum safe when scaling up, we sometimes need to make it SAFe.

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: May 31, 2018 11:51 PM | Permalink | Comments (10)

Please don't bug me

Bugs are pesky little things. They pop up everywhere, can be really annoying, and don't want to go away. Thank goodness we aren't in the Matrix where agents can hold us down while they implant metallic bugs into our body in order to locate us.

There are three main classification of bugs in my view: Genuine Coding Bugs, Non-Genuine Coding Bugs, and Human Bugs.

Genuine Coding Bugs
Most of us are familiar with coding bugs that appear throughout the project. These are genuine bugs that need to be addressed before they get more difficult and more expensive to fix. They can be mitigated through practices such as Test Driven Development and Continuous Integration. But the fact is there will always be bugs in every Scrum project. They should be listed in the Product Backlog as a bug, prioritized, and given the appropriate attention that maximizes value.

Non-Genuine Coding Bugs
There are also non-genuine bugs that slither their way into the Product Backlog. In other words: fake bugs. These are usually tasks disguised as bugs that get pushed into development. Stakeholders are the usual suspects, but Product Owners are also guilty of this practice. The Scrum Master should watch out for this problem, but they are not always technically competent to know the difference. The Development Team (in the absence of a credible Product Owner), or rather the developer who is asked to work on the "bug" as a matter of urgency, knows very well if the bug is really a bug. However, developers sometimes allow these "bugs" to be pushed through, perhaps because of a close relationship with the requester, or due to a passive personality.

Human Bugs
Human Bugs can be the most difficult to deal with if the Scrum Master and/or Product Owner are not on their game. Stakeholders are very welcome into the collocated work area, especially to view information radiators and clarify something with the Scrum Team. But their presence should be kept at a reasonable minimum, which basically means just enough to maximize value, not the reverse. This workspace is not, unfortunately, the only time stakeholders can morph into bugs.

Stakeholders may wander into the Daily Scrum, and through human nature, ask a question here and there. This cannot be permitted as it breaks the momentum of the Daily Scrum. Stakeholders at the Daily Scrum can attend if they must, but should never speak, only observe. I also believe that any line manager of a Development Team member in the Daily scrum should not attend at all. Remember the team must be allowed to work in a safe space, able to fail, make mistakes, and present issues with their progress or the team's progress. What if one of these issues is their line manager perhaps giving them little tasks here and there. Is the team member supposed to say: "What's stopping me from finishing this user story is my manager always giving me little tasks here and there." Should they say that in front of their manager? I don't think so.

Regarding the Retrospective, under no circumstances can a stakeholder or line manager attend this meeting. In fact, it is my view that even the Product Owner should only attend part of the meeting, but there are two camps on that one. The retrospective is a BUG FREE ZONE.

So, what happens when stakeholder bugs find their way into your Scrum project? That's easy. Take out the bug spray. Naturally this is not real insect spray, no matter how tempting the thought might be. It is something the Scrum Team member can say or do when the bugs come out. Here are just a few examples of using Bug Spray:

1. Stakeholder wants to add some "bugs" disguised as tasks. Developer: "Please speak to the Product Owner."

2. The Product Owner wants to add some "bugs" disguised as tasks. Developer: "This is a task, not a bug." Failing that: "Please speak to the Scrum Master."

3. Stakeholder wants to speak during the Daily Scrum. The Scrum Master needs to ensure that only the Development Team speak unless they have a question (usually to the Scrum Master or Product Owner). The Scrum Master should speak to the stakeholder privately and coach them on why it is not permitted to speak during the Daily Scrum.

4. Stakeholder wants to attend the Retrospective. The Scrum Master must make a stand and not permit the stakeholder (other than Scrum Team members) to attend the Retrospective under any circumstances. Remember, this is a BUG FREE ZONE.

                                                                * * *

The Development Team need to be focused on delivering the product, not struggling with impediments. The entire Scrum Team is responsible for minimizing bugs. Whether it be genuine, non-genuine, or human. Bugs are a necessary part of Scrum projects, but that doesn't mean we can't have the appropriate Bug Spray for it.

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: May 12, 2018 02:44 AM | Permalink | Comments (12)

Interview with Dave West, CEO of

Back in February, my interview with Ken Schwaber, the co-creator of Scrum, revealed some very interesting things about the world of Scrum. This month, we are honored to have the CEO of, Dave West, talk to us about where Scrum is heading, how it applies to non-software domains, and how to overcome management resistance to the use of Scrum in the organization.

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

I think there are a few reasons. 1. Simplicity - Scrum is very easy to understand. 2. Community - there are so many people who know Scrum, have seen it used and can put context to its use in their situation. 3. It’s not a methodology - For complex situations it would be impossible for anyone to prescribe a complex set of practices that apply to every context. Scrum provides just enough structure to raise transparency and empower the team to build the right process for their situation. 

2. One of the biggest problems with the implementation of Scrum is apathetic middle-management, even when Scrum has been sanctioned at the Executive level. Can you suggest ways for organizations to overcome this issue?

I have a lot of empathy for middle managers and the place they find themselves in. They are stuck between a rock and a hard place. The rock are their executives who want more ‘stuff’ cheaper and of a higher quality. They believe that agile will do that without necessarily changing any of the things that are the problem. The hard place are the teams who want to be more agile, but don’t want to be more disciplined or transparent. And the middle managers are expected to support this change without any support. So, of course they focus on the practices that they have always used in times of stress. More control, less transparency and lots of individual accountability. We need to break this cycle and that requires managers to:

  1. Be educated in understanding what the change means to them, their boss and to the teams they manage. They have a key role in creating an environment that enables Scrum to spread. Some agile change leaders say the only way for agile to succeed is to ‘fire’ all the middle managers. Instead I think they need to become a key driver for the change. And education is the start for that change, but in the context of their value.
  2. Look at changing the way the teams align to the work. For many agile situations that means aligning the teams to customers and products. By shaping the teams in response, not to specialist skills, but outcomes you can increase focus and improve understanding.
  3. Empower ‘Product Owners’ who can make decisions. For many organizations there are many decision makers which slows down delivery and builds ‘compromised’ solutions.
  4. Support ‘Scrum Masters’ to ensure transparency and help remove impediments. Scrum Masters support teams and teams of teams, the agile manager needs to provide the glue to support those Scrum Masters as they enable change at the team, team of team or organizational level.
  5. Use an agile approach to support the change to agile. It would be silly to think that agile can adopted in a waterfall manner, but for many organizations Because adopting agile is complex they should apply use an agile approach to increase transparency and drive the change.
  6. Adopt measures that are based on direct rather than circumstantial evidence. For example, instead of looking at velocity, focus on total time for resolve an issue or the innovation rate. By putting a dashboard up that has real business meaning and focusing on improving those numbers with agile, everyone is pulling in the same direction.

3. We all know Scrum is very well suited to IT and software development. How about non-tech domain such as construction and education? How can Scrum be applied to these and other non-tech domains?

You are right that Scrum was created in response to the complexity of software projects. But it can and is being applied to numerous situations that are outside of the software domain. For example they are applying Scrum in Ghana to help reshape how their Police Force deliver value to their citizens. In Holland Scrum is being used in education. It is also used in numerous engineering contexts building cars, jet fighters or even robotic vacuum cleaners. There are two elements that all of these situations have in common. Firstly, there is a team. Sometimes that team is not very functional, or even thinks it is a team. Scrum brings people together and helps team form. The second element is the complexity of the situation. Complex situations require an empirical approach which Scrum provides. Scrum provides a simple framework for progress through transparency ensuring that the team has a clear goal and a mechanism to review that goal on a regular basis.

4. Many of the benefits of Scrum are associated with reduced time to market which increases profits. How do you view the benefits of Scrum in the not-for-profit sector that isn't financially driven?

Value - Profit is one form of value, but it is not the only form of value. Scrum is a value based approach where the Product Backlog is ordered in terms of value. Of course the Product Owner is empowered to make the call on value, but the Sprint Review is focused on reviewing the increment in the context of value. Non-profits, like any organization should have a clear definition of value. Scrum then delivers it in an increasingly effective way. One of the major benefits of using Scrum in the context of a non-profit is that it gets everyone on the same page as to what value is and how each Sprint is incrementally delivering towards that goal.

5. What are the biggest flaws in the Scrum framework?

The biggest flaw in Scrum is it biggest strength. Simplicity. It is quick to understand, but that does not mean that it is easy to use. When people find using Scrum hard they often give up. They  decide, in my opinion incorrectly that Scrum is too simple and does not work. They then look to other things that are more complex to solve their problems. Scrum is a bit like losing weight. The actual principles of losing weight are simple, food in vs energy used. But losing weight is hard because there are so many things that stop you eating correctly and exercising enough. Also losing weight, like adopting Scrum can be much harder in certain situations. How many times have you given up on a diet because it ‘does not work’ when actually the problem is nothing to do with the diet, but instead the situation you are applying it.

6. In my Q&A with Ken Schwaber, I asked him should the Scrum Master role be renamed Scrum Coach to adhere more to a servant-leader model. He thought that would be a bad idea. Can you share your thoughts on this matter?

One of the great things about Scrum is the simplicity of the role names. The Product Owner owns the product, the outcomes you are seeking. The Development Team member is part of a team responsible for developing the solution. The Scrum Master is responsible for helping the team ‘DO’ Scrum. Now, doing Scrum is hard because Scrum is being executed in the context of the environment that might be very anti-Scrum. That means that the Scrum Master has to deal with lots of challenges to help the team ‘DO’ Scrum. The expectations of the role are clear. Coaching is one ‘stance’ of the role, but so is facilitator, trainer, mentor, manager, impediment remover, etc. Barry Overveem wrote a fantastic white paper on the 8 stances of the Scrum Master which can be found here. Of course many coaches do more than coach the team, but by having a clear role that is outcome focused you encourage the Scrum Master to use any stance that is required for the team to Master Scrum.

7. What do you enjoy most about assisting organizations transition and succeed with Scrum?

There are 2 things I get out of helping organizations more to Scrum. Firstly I get to see them deliver more stuff that is of value. We live in a world of opportunity, where almost anything is possible (think flying cars, a cure for cancer or free energy). If I can help organizations realize just a little bit more potential, the world is a better place and amazing things will happen. Secondly I love to see happy, excited, motivated teams. Seeing people excited to come into work and solve hard problems is a great experience and I am VERY grateful that I get to do it every day.

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

Unless something really odd happens (and touch wood it will not), the world is only getting more complex. That complexity will require teams of people to deliver value in more and more agile ways. Scrum I hope is at the heart of each of those teams. In five years I expect to see Scrum surrounded with more and more amazing practices and technology. These practices help Scrum Teams deliver more and more value. I hope that I am part of the community that is helping people understand and apply Scrum; A community that is building bridges to other communities to apply their ideas on top of Scrum; A community that is more professional and lives the values of Scrum every day.

To quote Ken Schwaber: "the first 20 years of Scrum was just the warm up".


Based on the principles of Scrum and the Agile Manifesto, provides comprehensive training, assessments and certifications to Scrum professionals. Throughout the world, their solutions and community of Professional Scrum Trainers empower people and organizations to achieve agility through Scrum.

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 23, 2018 07:15 PM | Permalink | Comments (14)

"Live as if you were to die tomorrow. Learn as if you were to live forever."

- Mahatma Gandhi



Vendor Events

See all Vendor Events