Scrumptious

by
Scrum is the most popular framework used within an agile environment to convert complex problems into valuable products and services. In this blog, we will examine all things Scrum to shed light on this wonderful organizational tool that is sweeping the globe. There will be engaging articles, interviews with experts and Q&A's. Are you ready to take the red pill? Then please join me on a fascinating journey down the rabbit hole, and into the world of Scrum.

About this Blog

RSS

Recent Posts

Losing a Scrum Team member

The Scrum Cold War

How SAFe is Scrum?

I think we can. I know we can.

Please don't bug me

How SAFe is Scrum?

One of the issues with Scrum is when we need to expand the team, or the Scrum project size. In other words, scaling Scrum. There are various scaling approaches, but one of the most popular is called SAFe or Scaled Agile Framework.

Many people get confused with the difference between Scrum and SAFe. Is it just Scrum on steroids, or a Scrum project that has outgrown the Scrum Team? Both approaches do share some attributes. For example, they are both based on Agile principles and adopt relatively short iterations.

But what happens when a Scrum project is so large, that there are numerous teams working on different stages of the product? Often these Scrum Teams might have their own Product Backlog, ceremonies and artifacts. Many Scrum Teams also have their own cadence adding more complexity to the project. Coordination of all these activities can start to break down, and Agility is sacrificed.

SAFe extends the functionality of Scrum to allow it to scale to a very large size. It does this firstly by creating four dimensions for the management of these large project: Portfolio, Value Stream, Program and finally Team. Scrum is most applicable at the Team level of the SAFe framework. In other words, when you are viewing SAFe at the Team level, it is very difficult to tell the difference between Scrum and SAFe.

However, at the Program level, we start to see a bigger crossover to SAFe and away from traditional Scrum. At this level, there are multiple Scrum Teams working effectively as a larger team, called the Agile Release Train or ART. They can consist of up to 150 people. Timeboxes here are called Program Increments or PI's which typically consist of 5 iterations. The PI begins with a planning meeting to discuss the vision or goals, and the upcoming features for that PI, in much the same way as a Sprint Planning meeting is performed before each Sprint. Usually the team plans the upcoming 4 iterations, and the fifth and final iteration is called an Innovation Planning iteration or IP. During this "Innovation" part of the iteration, the team can be creative and come up with ideas similar to hackathon. During the "Planning" part of the iteration, the team can hold a retrospective on how to improve the ART during the next PI, demo the achievements of the PI that just concluded, and also plan for the next PI's features.

The Value Stream level put simply is just a bunch of ART's for a larger solution that cannot be delivered using a single ART. At the Portfolio level, you guessed it, the focus is on the management of multiple Value Stream, but also takes into account strategic themes and budget considerations for each Value Stream. During these upper levels, there are many different job roles that we won't get into here, but needless to say, the number, diversity and criticality of these roles also scales with the SAFe framework itself.

So, in order to make Scrum safe when scaling up, we sometimes need to make it SAFe.
 


Thank you for your interest in the Scrumptious blog. If you have any ideas for Scrum topics, please message me here. Until next time, remember, projects can be Scrumptious!
Sante Vergini Signature

 

 

 

Posted on: May 31, 2018 11:51 PM | Permalink | Comments (9)

I think we can. I know we can.

Categories: Agile, Scrum

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

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

The-Little-Engine-That-Could

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

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

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

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


Thank you for your interest in the Scrumptious blog. If you have any ideas for Scrum topics, please message me here. Until next time, remember, projects can be Scrumptious!
Sante Vergini Signature

 

 

Posted on: May 29, 2018 04:56 AM | Permalink | Comments (17)

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

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)

Interview with Mike Cohn

Categories: Agile, Scrum

Recently, I asked some questions about Scrum to Mike Cohn, one of the premier Scrum and Agile authors and practitioners in the world today. Mike managed his first Scrum project in 1995, and is the co-founder of both the Scrum Alliance and Agile Alliance. I wish to thank him for his wonderful contribution to our Scrum community, and the Scrumptious blog.

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

I think there are two reasons. First, in many ways it’s the most widely applicable and the least prescriptive. Unfortunately, though, many have been slowly making Scrum more prescriptive over the past handful of years.

2. In your book "Succeeding with Agile: Software Development Using Scrum" you wrote that one of the attributes of a good Product Owner is that they are available. What are some ways to handle an absent Product Owner who is also an influential stakeholder?

I think the issue is that the more a product owner can be available to the team, the better. So it’s not an all-or-nothing situation. Some product owners do things like tell team members to put some phrase (like [Urgent] or [Today]) in email subject lines, and they’ll reply that day no matter what.

Even better are product owners who make sure they go sit in the team’s area for an hour or two pretty much each day. This type of product owner may sit with the team from 1–3 every day when in the office. And they’ll just do their normal work, but within arm’s reach of the team. Even if the team doesn’t need the product owner some days, the team benefits from knowing it won’t be hard to get time with the product owner.

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?

In Succeeding with Agile, I wrote about how about organizations and people move through a cycle of awareness, desire and ability. Managers at any level need to become aware that agile is a better way of working. Then they need to have the desire to make the change. And finally, the ability to make it happen. That book covers very specific ways to make each of those happen.

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?

All organizations have financial objectives. Often a not-for-profit organization’s financial challenges are more difficult because they have fewer raising of generating money. A not-for-profit should gain all the same benefits of becoming agile as any other organization.

5. You are a well-known proponent of the stand-up meeting. What's your advice for those Scrum teams who still sit down for the Daily Scrum?

I actually don’t think sitting down is that big of an issue as long as meetings remain short. But if your meetings seem to be taking longer than they should, stand up. Any meeting will almost certainly be shorter when you do.

6. Scrum professionals debate over the use of UAT and when it should be performed. Many suggest it should be done at the end of the Sprint, some suggest just after the Sprint has been completed, while others prefer it during the Sprint Review. Ideally, when is the best time to perform UAT and why?

Ideally a team should perform user acceptance testing within a sprint. But it’s usually not up to the team. Yours may be an absolutely amazing agile team running one-week sprints and creating prodigious amounts of high quality work. But if your customer or stakeholders say they can’t be bothered looking at the product more than once a month, you don’t really have any choice.

The best a team can do in those situations is make the issues with infrequent UAT visible to the stakeholders. Often the stakeholders will eventually start to test the system more frequently.

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

It is, of course, satisfying to see an organization once they’ve really become great at product development. But the most satisfying for me is the time when the ideas first start to take hold. Employees become more engaged and start to love their work. And leadership starts to embrace their role of helping to create the culture rather imposing deadlines or ways of working. To me, this is like the moment a roller coaster is just cresting the top of an incline. Up until then it’s been hard work but things are about to get fun.

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

I suspect exactly where it is right now. But what I hope we see is an end to methodology wars; Scrum vs. Kanban, SAFe vs. LeSS, Disciplined Agile, Enterprise Agile and every other scaling framework. Instead of arguing about methodologies, we need to focus more on agile as a large set of practices, some of which work well in combination. Ivar Jacobson has been promoting this idea for a few years and I’ve written about it as well. I’d like to see more debate and discussion on the practices of agile and less fighting among the major frameworks.
  


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 21, 2018 05:59 PM | Permalink | Comments (18)
ADVERTISEMENTS

"New York is my Lourdes, where I go for spiritual refreshment; a place where you're least likely to be bitten by a wild goat."

- Brendan Behan

ADVERTISEMENT

Sponsors