Scrumptious

by
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

RSS

Recent Posts

The Agile Engine

Scrum at School

Why SAFe may not be safe

Scrum on Mars

Scrum vs Kanban

The Agile Engine

Engine
 
In his 2006 book Innovation: The five disciplines for creating what customers want, Curtis Carlson said that “innovation is the primary driver of prosperity”. Many Agile enthusiasts who have read his book agree, and take it one step further, asserting that Agile is the “world’s best innovation engine” (Denning, 2015).

This may very well be true. Certainly, for Agile practitioners, Agile and its various approaches (i.e. Scrum, Kanban, DSDM) offer a creative and innovative way to solve project problems in an efficient way. It’s the reason why there are literally thousands of blogs dedicated to these Agile methods alone, including this one. So, with so many successes, why change anything at all? If it ain’t broke, don’t fix it, right? But I would argue that this complacency is actually part of the danger.

In our project world, every successful Agile delivery is a celebration of the framework we know so well. Every year the surveys boast growing numbers of successful projects under Agile and Scrum, and our old waterfall friend loses yet another trophy to its Agile counterpart.

But who is driving the Agile engine? People like you and me are driving it. No matter how squeaky clean and efficient the Agile engine is, if there is a problem with the driver, then you won’t get from Point A to Point B, and even if you do, you may arrive at a place you weren’t expecting.

Agile exists as a framework and approach shared by like-minded people with a common purpose. If we rely too much on the engine to steer itself, we will lose the innovation within ourselves, and instead, become slaves to an Agile prescription mandated by certifying bodies and self-proclaimed experts.

We have talked a little about the Agile engine and the driver. But no one has mentioned the fuel. That is a very different story for another time!
                 
                                                      * * *
Sources:
Denning, (2015). Agile: The World’s Most Popular Innovation Engine. Leadership Strategy. Forbes Magazine.

 


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: November 30, 2019 07:09 PM | Permalink | Comments (15)

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

Why SAFe may not be safe

Dictator
 
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:

 SCRUM

 KANBAN

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)
ADVERTISEMENTS

"I have made it a rule never to smoke more than one cigar at a time."

- Mark Twain

ADVERTISEMENT

Sponsors