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

Scrum.org beefs up training courses

Meet me in the Middle

The Scrum Time Machine

Applying Scrum to Research Projects

Losing a Scrum Team member

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

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

Product Backlog vs Story Maps

A product backlog is the entire list of all the "features, functions, requirements, enhancement and fixes" identified as being needed to produce a product or solution. Typically, these features are broken down into user stories, and these stories are generally understood to constitute the majority of the Product Backlog. However, not all of these items will actually end up in the product/solution, due to prioritization and certain constraints (ie. time and cost).

The Scrum Team occasionally works together to refine user stories, and work on prioritization. This is crucial in order to know what is valuable to the customer, and what trade-offs we can make if a particular constraint forces us to pick and choose between what stories are in and what stories are out.

But what if the backlog is large? When we sit down with the team and especially the customer, should we hand out a long list of potentially hundreds of stories, and be flipping between them? Can we really get an idea of the entire product or solution that way?

In 2005, an Agile practitioner named Jeff Patton had similar issues with the Product Backlog before eventually describing it as a "bag of context-free mulch". He decided to come up with a smarter solution; something that was in his view a "better version of a product backlog". And so, the Story Map was conceived.

Basically, to create a Story Map, we take sets of features and their associated stories, write them onto sticky notes, and lay them out horizontally, while grouping the stories by feature vertically (in ascending order of value/priority). What we get is something like this:
 


Imagine each of these sticky notes describes a feature or user story. Can you see that this visualization is a little easier to look at than a long list of the same descriptive items but in text format?

Ok now that we have a basic Story Map, how do we structure it? Well, the top line (blue) is what we call the Backbone. These are the features that are critical for the product to function and are non-negotiable. The second layer (pink) includes the minimum set of features and stories that the customer defines as the Minimal Viable Product or MVP; sometimes called the Walking Skeleton. The Scrum Team knows that they must deliver both the backbone and walking skeleton in order to have a viable product as determined by the customer.

Underneath the backbone and walking skeleton (yellow), we have the remaining user stories, with higher priority ones toward the top, and lower priority ones toward the bottom. Our Story Map now looks like this:



Obviously the Story Map is often a lot bigger than the one we have shown here. It could fit onto a large whiteboard, a section of the wall, and I have even seen them extending down a hallway of an office building.

Now, we can go another step further with the Story Map. Once we are pretty confident of the features, stories and the map, we can then start planning our releases, to which our Sprints will eventually be scheduled within. Once we get down to this level of planning, our Story Map becomes a Product Roadmap, which is basically a Story Map with a simple project timeline.



Which would you rather work with when discussing the project with the team and customer? A traditional product backlog, or a Story Map and the subsequent Product Roadmap? Remember, we always need the Product Backlog as this is the master file of all the items that will and could be in the final product. A Story Map and even a Product Roadmap (with only upfront releases) may not show all the stories.

So in summary, what are some of the advantages of using a Story Map over a product Backlog?

  1. Easier to breakdown the product into releases, and MVP
  2. Better visualization of the Product Backlog
  3. Easier to show customers and stakeholders key areas of the product
  4. Easier to enter the Story Map data into software such as Jira
  5. Relative sizing is easier when you can see the stories laid out
  6. Makes Prioritization less complicated

Can you think of any others?
 


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 26, 2018 08:37 AM | Permalink | Comments (14)

Interview with Dave West, CEO of Scrum.org

Back in February, my interview with Ken Schwaber, the co-creator of Scrum, revealed some very interesting things about the world of Scrum. This month, we are honored to have the CEO of Scrum.org, Dave West, talk to us about where Scrum is heading, how it applies to non-software domains, and how to overcome management resistance to the use of Scrum in the organization.

1. Why do you believe Scrum is the most popular framework for delivering Agile projects?

I think there are a few reasons. 1. Simplicity - Scrum is very easy to understand. 2. Community - there are so many people who know Scrum, have seen it used and can put context to its use in their situation. 3. It’s not a methodology - For complex situations it would be impossible for anyone to prescribe a complex set of practices that apply to every context. Scrum provides just enough structure to raise transparency and empower the team to build the right process for their situation. 

2. 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 have a lot of empathy for middle managers and the place they find themselves in. They are stuck between a rock and a hard place. The rock are their executives who want more ‘stuff’ cheaper and of a higher quality. They believe that agile will do that without necessarily changing any of the things that are the problem. The hard place are the teams who want to be more agile, but don’t want to be more disciplined or transparent. And the middle managers are expected to support this change without any support. So, of course they focus on the practices that they have always used in times of stress. More control, less transparency and lots of individual accountability. We need to break this cycle and that requires managers to:

  1. Be educated in understanding what the change means to them, their boss and to the teams they manage. They have a key role in creating an environment that enables Scrum to spread. Some agile change leaders say the only way for agile to succeed is to ‘fire’ all the middle managers. Instead I think they need to become a key driver for the change. And education is the start for that change, but in the context of their value.
     
  2. Look at changing the way the teams align to the work. For many agile situations that means aligning the teams to customers and products. By shaping the teams in response, not to specialist skills, but outcomes you can increase focus and improve understanding.
     
  3. Empower ‘Product Owners’ who can make decisions. For many organizations there are many decision makers which slows down delivery and builds ‘compromised’ solutions.
     
  4. Support ‘Scrum Masters’ to ensure transparency and help remove impediments. Scrum Masters support teams and teams of teams, the agile manager needs to provide the glue to support those Scrum Masters as they enable change at the team, team of team or organizational level.
     
  5. Use an agile approach to support the change to agile. It would be silly to think that agile can adopted in a waterfall manner, but for many organizations Because adopting agile is complex they should apply use an agile approach to increase transparency and drive the change.
     
  6. Adopt measures that are based on direct rather than circumstantial evidence. For example, instead of looking at velocity, focus on total time for resolve an issue or the innovation rate. By putting a dashboard up that has real business meaning and focusing on improving those numbers with agile, everyone is pulling in the same direction.


3. 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?

You are right that Scrum was created in response to the complexity of software projects. But it can and is being applied to numerous situations that are outside of the software domain. For example they are applying Scrum in Ghana to help reshape how their Police Force deliver value to their citizens. In Holland Scrum is being used in education. It is also used in numerous engineering contexts building cars, jet fighters or even robotic vacuum cleaners. There are two elements that all of these situations have in common. Firstly, there is a team. Sometimes that team is not very functional, or even thinks it is a team. Scrum brings people together and helps team form. The second element is the complexity of the situation. Complex situations require an empirical approach which Scrum provides. Scrum provides a simple framework for progress through transparency ensuring that the team has a clear goal and a mechanism to review that goal on a regular basis.

4. 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?

Value - Profit is one form of value, but it is not the only form of value. Scrum is a value based approach where the Product Backlog is ordered in terms of value. Of course the Product Owner is empowered to make the call on value, but the Sprint Review is focused on reviewing the increment in the context of value. Non-profits, like any organization should have a clear definition of value. Scrum then delivers it in an increasingly effective way. One of the major benefits of using Scrum in the context of a non-profit is that it gets everyone on the same page as to what value is and how each Sprint is incrementally delivering towards that goal.

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

The biggest flaw in Scrum is it biggest strength. Simplicity. It is quick to understand, but that does not mean that it is easy to use. When people find using Scrum hard they often give up. They  decide, in my opinion incorrectly that Scrum is too simple and does not work. They then look to other things that are more complex to solve their problems. Scrum is a bit like losing weight. The actual principles of losing weight are simple, food in vs energy used. But losing weight is hard because there are so many things that stop you eating correctly and exercising enough. Also losing weight, like adopting Scrum can be much harder in certain situations. How many times have you given up on a diet because it ‘does not work’ when actually the problem is nothing to do with the diet, but instead the situation you are applying it.

6. 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?

One of the great things about Scrum is the simplicity of the role names. The Product Owner owns the product, the outcomes you are seeking. The Development Team member is part of a team responsible for developing the solution. The Scrum Master is responsible for helping the team ‘DO’ Scrum. Now, doing Scrum is hard because Scrum is being executed in the context of the environment that might be very anti-Scrum. That means that the Scrum Master has to deal with lots of challenges to help the team ‘DO’ Scrum. The expectations of the role are clear. Coaching is one ‘stance’ of the role, but so is facilitator, trainer, mentor, manager, impediment remover, etc. Barry Overveem wrote a fantastic white paper on the 8 stances of the Scrum Master which can be found here. Of course many coaches do more than coach the team, but by having a clear role that is outcome focused you encourage the Scrum Master to use any stance that is required for the team to Master Scrum.

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

There are 2 things I get out of helping organizations more to Scrum. Firstly I get to see them deliver more stuff that is of value. We live in a world of opportunity, where almost anything is possible (think flying cars, a cure for cancer or free energy). If I can help organizations realize just a little bit more potential, the world is a better place and amazing things will happen. Secondly I love to see happy, excited, motivated teams. Seeing people excited to come into work and solve hard problems is a great experience and I am VERY grateful that I get to do it every day.

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

Unless something really odd happens (and touch wood it will not), the world is only getting more complex. That complexity will require teams of people to deliver value in more and more agile ways. Scrum I hope is at the heart of each of those teams. In five years I expect to see Scrum surrounded with more and more amazing practices and technology. These practices help Scrum Teams deliver more and more value. I hope that I am part of the community that is helping people understand and apply Scrum; A community that is building bridges to other communities to apply their ideas on top of Scrum; A community that is more professional and lives the values of Scrum every day.

To quote Ken Schwaber: "the first 20 years of Scrum was just the warm up".

                                                           ***

Based on the principles of Scrum and the Agile Manifesto, Scrum.org provides comprehensive training, assessments and certifications to Scrum professionals. Throughout the world, their solutions and community of Professional Scrum Trainers empower people and organizations to achieve agility through Scrum.
 


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 23, 2018 07:15 PM | Permalink | Comments (13)
ADVERTISEMENTS
ADVERTISEMENT

Sponsors