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

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)

Avoid a red card in Scrum

Categories: Agile, SAFe, Scrum, Scrum Team, Scrumian



When I started this Scrum blog over a year ago, I was encouraged by all the positive attributes of Scrum, and its scalable parents such as LeSS, DaD, SoS, Nexus, SAFe etc. SAFe is what I have been working with since 2018. Having said that, the benefits of Agile and Scrum can only be realized if they are being implemented correctly, and by correctly I mean in terms of the process, regularity, and consistency. In my experience, this is not the case with almost every organisation I have been exposed to.

Here’s some basic examples specific to Scrum. In my own workplace, standups dropped from daily ceremonies to twice a week. Not everyone stands up. The timebox is rarely met (in one case it went twice as long). It is not encouraged to ask questions nor discuss topics at any length during a daily standup, and yet they often are. Almost every participant talks about what they have on today, but rarely anything about yesterday or what they have been working on. This becomes even more important when the daily standups have been reduced to (in our case) twice a week. There are team stand-ups at the program and portfolio level, but very rarely at the project level, where the delivery of value actually takes place. Some critical team members have never been invited to team/project standups, such as testers who are so crucial to governance. The customer is involved to some degree in PI (Program Increment) planning sessions, but rarely throughout the sprint. Retrospectives per value stream are either not held or ineffective, and there is no review ceremony that involves customers to see the progress of incremental delivery, other than the occasional status report or update over the phone or email. I could go on, but I want to end on a positive note.

As my Scrumptious blog bio states: “Scrum is the most popular framework used within an Agile environment to convert complex problems into valuable products and services”. I still hold to this view. But it is up to us as project and Scrum professionals, or team members in a Scrum environment, to pick up the ball and run it through the goal line. When something is not right, call it out. It is for the benefit of the team, project and organization as a whole.

Don’t get a Scrum penalty. Kick a Sprint goal instead.
    


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 28, 2019 05:14 PM | Permalink | Comments (16)

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

"I'd rather be a failure at something I love than a success at something I hate."

- George Burns

ADVERTISEMENT

Sponsors