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

Meet me in the Middle

The Scrum Time Machine

Applying Scrum to Research Projects

Losing a Scrum Team member

The Scrum Cold War

Meet me in the Middle



In early 2017, I was assisting an organization with their Agile transformation. The initial meetings went well, with the Board of Directors approving the overall strategy for implementation, and were excited about the possibilities for better ways of working.

In typical fashion, we began with a few small pilots with the delivery teams, which went very well. After six months of various team formation challenges, mainly to do with former team leads reluctant to relinquish control, these teams became for all intent and purposes, Agile.

When the Board saw such great progress, they were keen to move forward with the organization-wide Agile transition. If the techy people in the company can become Agile, and senior management were also on board with the program, surely other business departments riddled with friendly middle managers wouldn't present much of a problem, right?

Wrong!

The first major challenge in any Agile transformation is changing the mindset. Why? Because there is often resistance. Why is there resistance? Well for a number of reasons, but they are all related to fear or ignorance in some form or another. The most common three reasons middle managers' resist an Agile transformation are:

Loss of control/influence
By their very job title, "managers" manage people, which affords them a degree of control that for the most part served 20th century corporations very well. Regardless of the severity of their autocratic style, managers almost always had control over what the employee worked on, how they worked and where they worked. Agile takes control out of the equation, which means hierarchy, conformity and fear are no longer used as weapons to get work done. When that occurs, innovation, collaboration and flexibility can thrive.

Threat of losing their job
As organizations become more Agile, middle managers find themselves managing less and less people. This may not be such a concern to them if only one or a few departments become Agile, which is the case in most organizations. They could simply slip into other middle management roles. But what about the company that is very serious about making an organization-wide move to Agile and better ways of working? In this scenario, many middle managers will metaphorically barricade themselves inside their various departments and start stocking up on ammunition to resist the Agile revolution.

Hanging on to the past
This phenomenon is more common than you think. Human beings naturally gravitate around the status quo, resisting change, holding on to the past. The past is comfortable, familiar, and a good friend. Unfortunately, the status quo in today's business environment will render the organization: state zero. There is something to be said for the traditions of the past. They help us define who we are as a society today. However, if changing traditions were always taboo, we would still be burning people at the stake. Traditions are great, but when it comes to an organization's survival, I'm afraid they have to take a back seat.

The age of continuous improvement, incremental value delivery and iterative feedback, inspection and adaption is upon us. Agile isn't coming, it's already arrived, and the train has left the station. Many middle managers will miss that train, not because they were late to the station, but because they don't have a ticket. My advice to them is to become more Agile, because in an Agile world, it's all about meeting in the middle, not being middle managers.
 


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 16, 2018 03:10 AM | Permalink | Comments (16)

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

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

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

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

Sponsors