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 at School

Why SAFe may not be safe

Scrum on Mars

Scrum vs Kanban

The Great Pretender

Scrum at School

Have you walked around some of our classrooms lately? They are a far cry from when I was attending school several decades ago. Back then the classroom resembled something out of Pink Floyd's The Wall: rows of wooden desks, teachers preaching and writing from morning until afternoon, students sitting at attention and only speaking if they raised their hand and the teacher granted them permission. It was expected that children had empty minds just waiting to be filled by teachers who held the keys to all knowledge. Imagine if that was our workplace today? It used to be that way in school and at work.

Over time, the education sector changed significantly. Pedagogies became more constructivist with approaches such as project-based learning leading the way. Teachers became facilitators rather than directors, and the child had their own voice and agency in their educational journey. Physical environments also changed. The walls came down and large open-plan learning environments sprang up like a tropical forest among the mud plains. One-way instructional education transitioned into a collaborative educational experience involving the child's home, school and wider community.

The black chalkboard with barking teachers at the front of the classroom became a thing of the past. Instead, children were immersed in an engaging and vibrant learning experience. Rote learning gave way to experiential learning. Students joined the teacher in a partnership, standing alongside them at the modern blackboard.

This is what the classroom used to look like:

And this is what it looks like in many classrooms today:

A slight difference!

When I visited my child's school last year, I noticed the whiteboards were not covered by endless rows or words. They were covered instead by columns, colored sticky notes, and bright messages and pictures. It was a Scrum Board detailing the most recent research project of the class. These were not KPMG consultants, but 6-year-old children designing, planning and executing their own projects using Scrum to assist in collaboration and workflow.

Scrum is just one of those easy to understand approaches that can assist children to learn, and adults to work. Kids are leading the way because as we all know, resistance to cultural change is the biggest obstacle to successful Agile projects. Kids minds are more flexible, open and dynamic than most adults could ever hope to be. Why is that? Mostly it's by choice. We can learn something from the new educational practices in our schools, which involve elements of Scrum at many schools.

The next time you find resistance in the workplace, or even find yourself swimming against the tide, consult your child on the best approach to handle your Agile project at work, or watch how they learn in the classroom. They might be able to teach you something.

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 31, 2019 04:40 PM | Permalink | Comments (17)

Why SAFe may not be safe

SAFe or Scaled Agile Framework is probably the most well-known approach for scaling Scrum for larger organizations and projects. While Scrum is the framework, SAFe is the scaling up of that framework. When projects get too large for a single team to handle, the approach is often to use Scrum of Scrums. But sometimes even Scrum of Scrums can't handle the complexity of some very large enterprises and their numerus initiatives that span multiple departments. In these situations, scaling frameworks such as SAFe promise to assist in alleviating the burden.
However, these large scaling frameworks do have some problems that warrant consideration before adopting them, and SAFe is no exception.
Problems with SAFe
In my view, SAFe fails at least one of the four Agile manifesto values: Individuals and interactions over processes and tools. You only need to take a look at the SAFe diagram to know that it does not reflect the reality in the working environment, nor is the level of complexity necessary.
SAFe adds so many unnecessary processes. For starters, the PI (Program Increment) planning sessions usually last 2-3 days, or at the very least slows down effective work for that amount of time. Planning to some degree is necessary, but in my experience the days of PI planning could have be done in a tight, focused half-day session, or at the very most one day, with "back to normal" work starting on the next day. This was never the case in my experience, with the day following PI planning as a kind of holiday from the actual activities associated with the objectives agreed upon in the PI.

Then there are meetings. When I worked in a SAFe environment, every day there were meetings to discuss program or portfolio initiatives. It begs the question, are initiatives at the program/portfolio level changing that rapidly that they need to be discussed with the team every day? How about a daily project-level or stand-up meeting (which were basically non-existent); wouldn't that be a better use of time and resources?
This bring me to the second of four values in the Agile Manifesto that I believe SAFe may fail: Responding to change over following a plan. 

As mentioned above, the PI planning sessions in my experience are far too long, lack substance, and are not reflective of the realistic work activity that occurs during the PI and sprints. For example, a large portion of time in the PI planning session was devoted to creating story cards for each project. These story cards were rarely followed nor reflective of the actual work being performed. Rather than the team having input to these story cards, they were left to the project manager of each project, which in a SAFe environment, was the same thing as a Scrum Master. The disconnect between project story cards and workplace reality was no more evident that the daily stand-ups in a SAFe environment where the program/portfolio level "cards" were discussed ad nauseam, but not the individual project level cards. Further, the program/portfolio level cards were created by the Release Train Engineer (RTE) and Delivery Lead with totally different terminology and priority than the teams used in their own project cards. I used to watch the blank faces of these project managers counting the minutes so that they could get back to something valuable, like running their own projects which they now had 30-60 minutes less time to do. These program/portfolio meetings and planning sessions were mandated by the RTE, which brings me to another problem within a SAFe environment: The Release Train Engineer (RTE).
From my experience in Australia's biggest university which had adopted SAFe a few years earlier, the RTE role is a complete waste of time. The normally servant-leader role and roadblock remover was in fact a major obstacle to team innovation and agility, but even worse, it was a purely autocratic role. The reason this can happen in a SAFe environment is because the RTE is left un-checked by way of their Agile expertise. They may have a manager yes, but that manager is usually not an expert in Agile ways and certainly not SAFe trained or certified. This gives license for the RTE to make bad decisions and rule people and processes without recourse, especially if the organization has mandated a SAFe environment. The keys to the SAFe kingdom sit squarely with the RTE. The basic construct of SAFe is the Agile Release Train and so that train is not going away. However, creating an emperor of that train takes away from the usual collaborative team approach in Agile. What I observed were project managers that could have enacted the program/portfolio initiatives set out by the Delivery Lead, but instead were bogged down by the rules, processes and mico-management dogma the RTE.
These are just a few of the observations I made after working in a SAFe environment, which by every measure had full enterprise support, a massive budget and keen Agile professionals. But the veneer of SAFe and the overlords who sung its praises was not persuasive enough in the light of obvious loop holes in the framework; certainly at this institution. Over time, I spoke to 3 of the 6 project managers in this SAFe environment and was surprised to discover their level of disdain for SAFe for the same reasons cited above. Their opinion cannot be overlooked, since as I said earlier, project managers are not only scrum masters in a SAFe environment, they are often product owners as well.

Which brings me to perhaps to the biggest issue in a SAFe environment if not managed correctly. Very often, only one person plays the role of project manager, scrum master and product owner at the same time. When you have this triple role played by one person, and that person reports to the RTE who has become the biggest roadblock of all, the road for SAFe seems very unSAFe indeed.

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 29, 2019 08:50 PM | Permalink | Comments (6)

Scrum on Mars

Once upon a time, in a galaxy not so far away, was a planet named Mars. A company called SpaceX landed the first humans there and colonized the planet. Among the many initiatives to deliver value were some Lean, Kanban and Scrum projects. One lucky Martian was appointed as the Scrum Master and decided that Scrum would be as successful on Mars as it had been on Earth.
Can Scrum be as successful on Mars? Well if you look at projects simply, very simply, they can be broken up into components that deliver predominantly: value and quality. In most of my short research on this topic, "value" gets a big thumbs up. But what about "quality"? That has some mixed reviews. Lean and Kanban are more about quality and reducing defects than Scrum, which leans (no pun intended) to the value end of the scale

Typically, this wouldn't be an issue. Businesses and customers make trade-offs all the time between quality and value, and in some cases, so do project managers, scrum masters and product owners.
But newsflash: we are talking about Mars! A reduction in quality by even 1% could mean the difference between life and death. With such dire consequences, project teams may rely more on Lean/Kanban to reduce defects and waste. So, does Scrum have a place in such a hostile environment? Well, in my opinion, yes it does. Projects can be divided into features that focus on quality, or value, or a combination of both. Since all of these project frameworks use what is essentially a backlog, work can be picked up utilizing whatever framework is appropriate to its feature/story's sensitivity to quality or value, then taken through that framework's system (flow, iteration etc.).
Scrum, of course, can be used for many other value-focused outcomes such as daily stand-ups, retrospectives and backlog grooming. Grooming or refining the backlog is not only a Scrum activity, but the term "grooming the product backlog" was first used by Mike Cohn in 2005 when talking about Scrum, and in 2011 made its way as an official practice within the Scrum Guide.
So, the next time you give it some thought, try and imagine how Scrum might be used on Mars. Put yourself in the shoes of that Martian Scrum Master, because the day will come when they are visited by a very special guest from Venus: the Product Owner.

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, 2019 10:17 PM | Permalink | Comments (18)

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 (29)

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)

"In the beginning, the universe was created. This has made a lot of people very angry, and is generally considered to have been a bad move."

- Douglas Adams



Vendor Events

See all Vendor Events