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

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)

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)

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!"

References
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 (35)

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

Sponsors