Real Scrum vs the Real world
Hi everyone.
This is a holistic post and just a discussion topic.
I've been involved in agile development for about 10 years, and I have been very close once to a pure implementation.
We had a client who was willing to participate daily, UAT on the fly and re-priortize the backlog.
However she still had to move some business UAT out of the sprint.
In my experience 90% of all SCRUM projects are not SCRUM for multiple reasons
but some of the major:
1. the testing/UAT/QA phases are often not a daily part of development, but scheduled segments
2. Many projects dont clear the backlog if tasks are half done, they spillover into next sprints
3. MANY MANY projects dont have clients/business owners that completely fullfill the PO role
Now instead of just discussing how you can force people to use real SCRUM, I was wondering.
Has nobody ever tried making a framework that takes all the beauty from SCRUM, but incorporates it in a real world
with waterfall expectations to some of the process ?
I'm thinking 80% SCRUM, 20% real world experience.
I'd like a framework like that.
Has nobody ever tried making a framework that takes all the beauty from SCRUM, but incorporates it in a real world with waterfall expectations to some of the process ?
Mercy, yes. Lipstick is smeared on that pig all of the time. It has many names: waterscrumfall, wagile, sucky scrum, and (uncharitably, perhaps) SAFe.
The problem is disillusionment over outcomes when nothing really changes.
thx
It has many names: waterscrumfall, wagile, sucky scrum, and (uncharitably, perhaps) SAFe.
Yes, a fish with feathers that can't swim or fly.
Has nobody ever tried making a framework that takes all the beauty from SCRUM, but incorporates it in a real world
The unified process folks tried something although they didn't use Scrum. The unified process model is a software development approach that consists of four phases of inception, elaboration, construction, and transition. When Agile ways of working became popular it died out and is no longer popular.
Many Scrum efforts are not Scrum because people choose to change Scrum rather than choose to change their culture, ways of working, organizational structures, customer and vendor contracts, etc. Changing Scrum is easy (i.e. we'll do UAT at the end of the Sprint) because it doesn't rock the status quo but never gets you the results you were after to begin with. Being a change agent is hard stuff. Scrum points out all of your challenges but doesn't claim to fix them - people have to.
Scrum does not claim to be a silver bullet, a one-size-fits-all approach, nor is it always the right framework for every product or project. Scrum's best fit is for complex work, where more of the requirements are unknown than known and the implementation is far from certain. Hence your best shot at solving complex problems is through an empirical approach of making decisions based on facts, leveraging short feedback loops to manage risk and gain validated learning.
It's a simple 14-page framework that is intentionally incomplete where you can bolt on other ways of working, practices, and techniques.
No one should ever be forced to use Scrum.
It is not Scrum that does not work, it is because only a piece of an organization unit/process has been changed. In my experience, energy goes into organizational changes around the Scrum team over the Scrum Team.
If a company do not want to change the structure, I would question why Scrum is used.
Again I have to say the 0 or 100 / all or nothing attitude that follows these forums seem pointless.
Why would you even waste your time commenting on these topics when the intention is not to help but to point out when someone is wrong.
Martin you say why if SCRUM is not 100% followed do you even use it?
Well thats because you can actually do 90% SCRUM and still see amazing results and use many of its benefiths even if the client refuses to go all in.
which is true to many things.
Hi,
I'm currently working on that and I believe the best approach is to tackle one problem after the other to potentially progress on an implementation of Scrum
Highlighting bottleneck for the team to deliver value (instead of bottleneck to implement Scrum) choosing your battle, and finding people who are happy to challenge the status quo. Avoiding burning bridges while maintaining integrity and assertiveness is tough.
For example, I'm working with a PO to get development contracts made with a SOW defined at a high level and then ensure the whole team BA, Architect, developer and SME working as a single team to get stories defined to a detailed level, build, QA tested, UAT tested and deployed in prod as a single unit (or a bundle).
With another Product Owner, I'm losing the battle of the Gantt chart... And I'm working on being ok with that
Hope it can help
You are essentially saying that frameworks don't work in the real world, so you want to create another framework. Your big flaw is thinking that this particular framework is the problem when in fact it's adopting a foreign framework in general.
FWIW: You can check out the Scrum patterns movement that promotes the idea that you pick just the patterns you find useful.