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)

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)

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

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

Conversation with Mike Griffiths

Categories: Agile, Scrum, Scrum Team

The Scrumptious blog is honored to welcome Mike Griffiths for a conversation about Scrum. Mike is one of the co-creators of DSDM and author of "PMI-ACP Exam Prep" which is the number one resource in my view for passing the PMI-ACP exam. It certainly helped me. Mike's full bio can be viewed at the end of this blog post.
 
1. Why do you believe Scrum is the most popular framework for delivering Agile projects?

I believe Scrum became popular because it is a clean, simple to understand approach. While it is difficult to master, the initial process is very easy to grasp. People are drawn to simple solutions. Like the Atkins diet that can be summarized as “Do not eat carbs”. When people are looking for guidance they want something they can quickly comprehend.

Personally, as a co-creator of DSDM, I was first a little envious of Scrum’s success. However, when you step back and realize that all agile approaches bring agile concepts to a wider audience, you can see the bigger picture benefits. Recently I have been impressed with the work of the Agnostic Agile community who seek to promote the benefits of agile separate from any specific approach.

2. In your book "PMI-ACP Exam Prep" you talk about both relative estimating and ideal time. There has been some confusion in the Scrum community about when to use story points and when to use ideal time for estimating and forecasting. Are there any circumstances in Scrum when estimating in hours and not points makes more sense?

For the PMI-ACP Exam we wanted people to know about estimation in both hours and in points. So, I cover both in my book. I see using points (or some other unit) as a next step in the evolution from estimation in hours. It avoids the artificial ceiling issue that can occur when a team has achieved its hours worth of work for the week.

3. One of the biggest problems with the implementation of Scrum is apathetic middle-management, even when Scrum has been sanctioned at the Executive level. Can you suggest ways for organizations to overcome this issue?

I rarely meet apathetic middle-management. I meet a lot of resistance in middle-management, but there is always a good reason for it. I suggest we work with them, find the cause of their misgivings, concerns or confusion. Maybe they do not understand, maybe there is a fear of loss (job security, status, role competency). Once we know why they seem to be resisting we can work with them to resolve it. Finding a way for them to get a gain rather than a loss out of transitioning to agile usually works well. Yes, traditional management roles are eroding, but there is a big demand for people who can straddle the agile to traditional space well. Perhaps by taking an active role in the transition as an enabler they can build valuable skills that increase their corporate value?

As such, I have never had long term conflict with middle management. Despite the stereotypes of them, most are smart, hard working people trying to do their best in a difficult situation that measures their performance using antiquated metrics. Spending time listening to their concerns usually helps uncover implementation risks that can be avoided before they become issues. They are a useful early warning system for implementation problem areas – engage them actively since they are well embedded in corporate culture and take their concerns seriously. Being prewarned of concerns can highlight the need for more information sessions and training. I’d rather tackle these misgivings proactively than when trying to get a project decision approved.

4. We all know Scrum is very well suited to IT and software development. How about non-tech domain such as construction and education? How can Scrum be applied to these and other non-tech domains?

Agile approaches, including Scrum work well for all knowledge work projects. These include teachers, lawyers, design engineers, marketing, etc - in fact any domain where subject matter experts come together to collaborate and solve novel problems. Environments where the bulk of the work is invisible and intangible (ideas, data, design) work well with agile approaches.

The steps of frequently reviewing increments of the solution are valuable to surface potential misunderstandings between contributors and sponsors. They also help assess the viability of the emerging product and encourage process improvement. Agile and lean have been applied very successfully to both construction and education as both the Lean Construction Institute and Agile In Education groups document.

5. Many of the benefits of Scrum are associated with reduced time to market which increases profits. How do you view the benefits of Scrum in the not-for-profit sector that isn't financially driven?

The terms you mention: “reduced time to market” and “increased profits” are proxies for Return On Investment and Value. Not-for-profits are typically even more focussed on ROI and value than for-profit organizations since they have to do more with less. Usually from modest income sources and donations they need to effect the maximum changes they were created for.

This is the perfect environment to apply agile’s lean inspired minimization of waste, value optimization, and continuous improvement models. Successful for-profit organizations can become fat, lazy, complacent and wasteful. They see what they are doing is working and fail to see the need to continuously improve, continuously cut waste. Instead they just want to scale up and crank their machine faster to produce more profits.

The not-for-profits I have worked with naturally took to agile approaches quickly. Their own principles on effecting positive change in the world fit with the agile mindset. Not for profits usually have a more socially aware culture that maps to agile’s mindset of empowerment and trust. If we use Frederic Laloux’s color framework, not-for-profits are Green and Teal organizations that fit well with Agile’s green culture and values. For these reasons and more I think agile approaches (including Scrum) are a great fit for not-for-profits.

6. What are the biggest flaws in the Scrum framework?

Ha, as an outsider to the Scrum community, I should be careful here. I respect Scrum and cannot argue with its success. If I had to think of some potential downsides I would say it sometimes appears to act as a walled garden. By this I mean changes are slow and funnelled through releases of the Scrum Guide. It also uses proprietary names of things to retain distinction and IP protection. Some of these names like Scrum Master raise eyebrows in conservative organizations. Other agile approaches have more professional, enterprise-friendly terminology, but none have Scrum’s market share.

Scrum’s simplicity is both a strength and a weakness – it is quick to grasp, but there is a lack of clarity on how to grow and scale. This has led to the proliferation of scaling approaches that appear confusing and sometimes contradictory to people new to the field.

7. In my Q&A with Ken Schwaber, I asked him should the Scrum Master role be renamed Scrum Coach to adhere more to a servant-leader model. He thought that would be a bad idea. Can you share your thoughts on this matter?

I will not try to guess Ken’s reasons for thinking this a bad idea. Personally, I think adopting a Scrum Coach title would have some advantages and disadvantages. On the plus side, it sounds more like a supporting, servant leadership role, as you suggest, that it should be. It is also not as pretentious as claiming to be a “master” of anything. That alone would go a long way to easing acceptance in many markets outside of the US.

On the downside, there is a championing role for agile concepts that some people may feel diminished with a “coach” title. Personally, I think we can only coach for positive change, trying to demand people never works long term. The cynical side of me wonders if the title “Scrum Coach” is too generic a term to be claimed under Scrum IP. It might already be public domain and seen as an erosion of the protected Scrum framework.

For my part, I don’t really care what we call people, if they are doing good work. As mentioned in Q1, the Agnostic Agile community wants to rid the world of proprietary names and instead spread the ideas as a free to use framework. That’s an idea I support more.

8. Your book suggests 12 members or less for an Agile development team, while the Scrum Guide advocates 9 or fewer. What is the ideal development team size and why?

I think it depends on the domain and what you are trying to build. For software projects, I have seen many very productive teams using 3 developers. 1 BA, 1 QA, and 1 SM for a total of 6 people – I do not think there is a magic number. Obviously, as team sizes grow, there are more communication channels to manage which takes more effort and increases the risk of miscommunication and confusion. So, I guess my recommendation would be as few as you need. 

9. What do you enjoy most about assisting organizations transition and succeed with Scrum?

It is great to see people ditch non-value adding work and focus on achieving results. Intuitively people want to do this but are often bound by corporate policies and frameworks that they do not have authority to change. Transitioning to agile approaches helps people see and take ownership of their actions. They get to work closer with the business and their customers. They experience the thrill and ownership of improving their own processes.

It is very satisfying to be a part, in small way, of increasing someone’s engagement and happiness at work. It is them making the change and getting the results, but if I played a part, it is a good day.

10. Where do you see Scrum 5 years from now?

Ideally dead and buried. It would be great if Scrum and all the agile approaches were just wrapped into a better commonly accepted framework for collaborative development. Or replaced completely by something better. However, we have been saying this for over 10 years and it has still not happened, so I expect it will still exist.

It’s ironic that agile was once the new rebellious upstart to replace the corporate mandated processes. Now, for many people entering the workforce it is the established, mandated process. I am hopeful that people will once again rise to replace it with something better. Staying the same is a recipe for stagnation and decline. Change can be evolutionary or revolutionary. Evolutionary change is usually small, slow, controlled and generally successful. Revolutions are big, messy, risky and exciting/alarming depending on which side you are on and if it is successful or not.

                                                              ***

Mike Griffiths is one of the co-creators of DSDM. He served on the board of the Agile Alliance and the Agile Leadership Network. He remains active in the agile community and takes the agile message to those that need it the most – old-school project managers. Seeing the biggest resistance to agile values in command-and-control management, Mike tries to influence project management from inside the PMI. He helped create the PMI-ACP credential – an approach agnostic certification. He was recently chair of the Agile Practice Guide, a joint publication by the Agile Alliance and the PMI. Mike lives in Canmore, Alberta and maintains the blog Leading Answers at www.LeadingAnswers.com.
 


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, 2018 07:06 AM | Permalink | Comments (21)
ADVERTISEMENTS
ADVERTISEMENT

Sponsors