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

Losing a Scrum Team member

The Scrum Cold War

How SAFe is Scrum?

I think we can. I know we can.

Please don't bug me

Losing a Scrum Team member

Categories: Scrum, Scrum, Scrum Team



It is a natural part of the business environment that people move on from our projects for various reasons. Perhaps they have a better job offer, are needed on another project, or pursue other life choices. When a top team member leaves, it can not only impact the project, but the team itself. People form relationships, collaborate, produce and share knowledge, and add to the lifeblood of the team. When they depart, in some ways it can feel similar to the grief process. Some teams pick up where they left off and quickly get another member up to speed, so that their team is performing at optimal levels sooner rather than later. Other teams fall back into the Storming stage of the Tuckman model.

The Scrum Team is unique in that it has a few clearly defined roles, is empowered, self-organized, cross-functional, small, collaborative, team rather than individual focused and decides how it will produce the project's product or service. While there is a lot of information on how to make a team successful by focusing on team members' skills and attitude, there is less information on how to cope when a key team member leaves the team.

So what can we do when one of our star performers leaves the Scrum Team?

1. Talk about it
It sounds like common sense, but often overlooked. The first thing a Scrum Master should do is get the team to sit down and talk about how everyone feels about the team member leaving, and then the implications for the team and project. This session is a good opportunity for people to express their feelings, as some may have had a long working relationship with the former team member. Further, the team is in the best position to make recommendation on how to fill the gap with the next team member.

2. Fill the gap
Before a replacement team member is found, the Scrum Team need to figure out how the previous work performed by the former team member will be handled. Can some of the team chip in to make up some of the work? Does the team wait until the new member arrives? Is there some improvements the team could make to either people, processes or the product that might save some time to make up for the initial lower productivity? This must be a team decision, and not just the previous team member's work dumped onto the team until a replacement is found.

3. Find a suitable replacement
Now the really challenging part is replacing that great team member. The first suggestion I recommend is not to raise expectations too high for the new team member. It is almost impossible for the team to rate a new team member higher than their former colleague, so give them a chance to fit in and perform.

The three key areas the Scrum Team will need to focus on is skills, attitude, and commitment. The new team member will need cross functional skills in order to succeed in a Scrum Team. They will need the right attitude from an Agile mindset, to a collaborative team player. Finally, they will need full commitment, to the team, to the Scrum values and principles, and to the project and organization. Can you think of anything else?

“Individual commitment to a group effort; that’s what makes a team work, a company work, a society work, a civilization work." - Vince Lombardi
 


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 11, 2018 05:02 AM | Permalink | Comments (14)

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

I think we can. I know we can.

Categories: Agile, Scrum

There's something to be said for the power of positive thinking. It goes to the very heart of any notable achievement, from declaring war against an unsurmountable enemy, to simply embarking on a new Scrum project to deliver a product or service to the market. Without it, it's hard to imagine how anything can be achieved.

In the 1930 epic book "The Little Engine That Could", Watty Piper (really Arnold Munk) told the story of a little blue train that despite the odds and detractors, kept forging up that hill while always chanting its own Sprint Goal: "I think I can. I think I can. I think I can."

The-Little-Engine-That-Could

The Scrum Team, coached by the Scrum Master, is the little engine that could. They are responsible for keeping each other on track, positive, working to the best of their ability not only for the product/service delivered by the project, but as a team by always improving themselves. The Scrum Master ensures that the engine is well oiled, all the parts are operational, and that there are no rocks sitting on the railway line ahead that could derail the project.

The Scrum ceremonies provide a great opportunity to reinforce this positiveness. At the Sprint Planning meeting, we create our Sprint Goal that hovers above our Sprint like a guiding safety flare. During the Daily Scrum we have the opportunity to list the achievements we just accomplished for the previous day and what we will achieve during the next day, which is a good way to spur the team on to continue up that hill. At the Backlog Refinement meeting (my pseudo Scrum ceremony), we get a chance to make the Product Backlog reflect the current state of play by deleting items that are no longer relevant, adding items that are, splitting them into smaller stories, reordering their priority, and refueling the Product Backlog based on value and risk prioritization. The Scrum Review helps us to get positive reinforcement from the customer and the Product Owner that what we are producing is right on the money. Finally, the Scrum Retrospective is all about making a positive change to people and processes through our continuous improvement initiatives. In fact, the Scrum Team should always leave the Retrospective feeling very positive, confident and energized.

If any of these ceremonies and meetings are put off or not done effectively, the Scrum Team can get negative really fast because things can seem overwhelming and not optimized for the engine. In other words, the engine will need to work twice as hard to get up that same hill, and we don't want that right?

"Whether you think you can or think you can't, you're right." - Henry Ford.


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 29, 2018 04:56 AM | Permalink | Comments (17)

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

"It's not whether you win or lose, it's how you place the blame."

- Oscar Wilde

ADVERTISEMENT

Sponsors