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

Applying Scrum to Research Projects

Categories: Agile, Scrum, Scrum in Academia

It has long been understood that Scrum is very well suited to software development projects. However, the literature is scarce regarding examples or case studies of Scrum being used in non-technology applications such as construction, education and research-based projects. The research sector is not well known for deploying Scrum to get its product to see the light of day. But the more you think about it, what organization isn't involved in research of some kind or another?

Corporations perform research all the time to get competitive advantage or to learn something that affects their bottom line. Government institutions use research for all sorts of information affecting their constituents. Further, educational institutions use research-based projects as the foundation for higher learning.

With all these applications, surely Scrum can venture out of the software-development industry and bring some value to research-based projects. The good news is it can, and already has, but there isn't much news about it.

The Federal University of Amazonas in Brazil published a paper in 2016 detailing the "use of Scrum for the management of research-orientated projects". They concluded that the application of Scrum had brought about productivity improvements, enhanced knowledge sharing and increased engagement (Sanchez, 2016). Also, at Lund University in Sweden, similar benefits were discovered (Pearson et al., 2012). Both studies found that small teams indicative of Scrum were well suited to higher learning objectives. However, they also noted that Scrum needed to be modified slightly to suit the reality of the research-based product life cycle. In particular, Daily Scrums were not possible; instead opting for weekly events.

The Scrum Team consisted of the researchers, supervisors, and sometimes other parties such as participants in studies, teachers, academic officials and subject matter experts. When reading these case studies, one gets an idea how Scrum may be adapted to the research industry.

In 2016, Jeff Sutherland made the following statement:

"Many of the leading research labs in the U.S. use Scrum. The one I have worked with most often is the John's Hopkins Applied Physics Lab, the leading Naval research lab. Their research plan is their backlog. They map it out like an AI tree. Time boxing the research stories gets them done twice as fast. And the quality of the research is much higher with daily meetings."

So these case studies along with confirmation from the co-author of Scrum is very encouraging. I am currently working on some other examples of the way we can apply Scrum to research-based projects, including my own personal story, so stay tuned for that in the future.

References:

1. Pearson, M., Kruzela, I., Allder, K. and Johansson, P. (2012) On the use of Scrum in Projecrt Driven
Hight Education. A research paper presented to the Department of Psychology, Lund University,
Sweden. Available from: https://www.researchgate.net/publicatio
/267690193_On_the_Use_of_Scrum_in_Project_Driven_Higher_Education

2. Sanchez, J. (2016) On the use of Scrum for the management of research-based projects. Nuevas
Ideas en Informatica Educativa.
Volumen 12, pp.589-594. Available from: http://www.tise.c
/volumen12/TISE2016/589-594.pdf

3. Sutherland, J. (2016) Do you know of research teams adapting Agile frameworks and/or Design
Thinking techniques for managing research projects? Quora. Available from: https://www.quora.co
/Do-you-know-of-research-teams-adapting-Agile-frameworks-scrum-kanban-XP-etc-and-or-Design
Thinking-techniques-for-managing-research-projects

 


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, 2018 11:45 PM | Permalink | Comments (31)

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

"When I have a kid, I wanna put him in one of those strollers for twins, then run around the mall looking frantic."

- Steven Wright

ADVERTISEMENT

Sponsors