Reblogged with permission from Jem D'jelal, the original author of this content, as a contributor to blogagility.com. Originally published on LinkedIn July 11, 2016.
Jem D’jelal Coaching individuals & teams to find “better” ways of working.
Going on the adventure that is Scrum involves an appetite for change & a disruption budget.
Not everyone has that appetite.
Not everyone has the budget.
I’m not one to settle for mediocrity but I’m also not one to sink companies with blind passion.
I’m also not interested in trying to sell Scrum to people. I’ll tell you what it is, what it can do & invite you on a journey – but I’m not trying to sell you double glazing windows.
Part of being a good ScrumMaster is knowing when & when not to use Scrum.
If working in teams is not important.
Scrum’s real power is not in the individual, but in the collective effort of the team. I’ve come across plenty of humans who sit in the same place but are not connected to one another. Disconnected socially & with the work they complete. Now of course if the aspiration is to try Scrum, then that’s a dysfunction which you’d want to address. If there is no interest in “Teams”, stop. In such cases Kanban might be a better bet. As the chap who popularised Kanban said: “Kanban is not about teams, it is about providing a service” – a team effort is not required.
If the business can’t commit to a Product Owner.
Scrum teams can be thought of as Entrepreneurial Teams. Like a little business that have all of the right skills to make it work. From concept to cash. The Product Owner is significant part to that puzzle. The innovation captain that not only sets the vision but is part of the team’s DNA. Available, qualified, inspiring & actually up for trying his or her hand at the role. The last part is the deal breaker for me. We, as ScrumMasters can train & coach PO’s on the skills required but without the desire to “try” the PO role it’s never going to work.
If the business want to own the “what” & the “how”.
So often I hear of “Technical” Product people who want to drive the details of an implementation. If you’re in such a situation you need to challenge the paradigm – thats IF you want to give Scrum a go! Teams who don’t own the solution lose out on the intrinsic motivation that creates a sense of purpose & autonomy – resulting in creative & invigorated teams. If they want the business person to create the solutions & have the developers execute the tasks – Scrum will have no chance in working with a disempowered workforce.
If you’re only building steering wheels.
Scrum teams are trying to create potentially shippable stuff at the end of their sprints & that means being product centric. That’s not to say that if you have back end teams & front end teams you can’t use Scrum – you can. But at some point, there needs to be an aspiration for this Entrepreneurial Team to be able to go from Concept to Cash without having to hand over their work to another team & then another …..and so on, to build a meaningful product centric thing. If the nature of the work is building components & management have no ambition to disrupt & would rather fine tune the workflow of an component team, I’d say Kanban is your friend.
If management insist on creating team leads.
Self organisation doesn’t work when you create a level of authority within the team. If you explain the impact of creating mini managers within a Scrum team to the person hiring you AND THEY STILL want it, go deeper. For example some managers want the role “because they need to hold someone accountable”. It’s a paradigm which is based on a lack of trust. If the coaching & mentoring doesn’t take you forwards, Scrum’s not the right choice.
If your work is brown field & super duper reactive.
A contentious point here. Scrum is here for new Product development, on the whole. But in reality, few of us get to work on green field projects & with no disturbances. So this is really about using empiricism to figure out the art of the possible. If you have a Product Development team with 80% support work vs 20% New Product Development, by all means make the case to illuminate the truth of the nature of the work. But, if that work is the accepted reality (i.e. no appetite for investing in an app.support team, won’t let move legacy clients over to the “new world” because of down time)… then maybe Scrum isn’t the right approach.
If the team are not given a chance to experiment with Scrum.
It’s important that management understand that Scrum will bubble up all of the problems to the surface. It is not a magic wand! If the expectation is that Scrum will make everything perfect & that failure is not acceptable – I’d be very uncomfortable with using Scrum.
If you do not have buy-in from at least one “senior” peer in management.
Yes you can do Stealth Scrum & create a case for others to try it – but you’ll always hit an organisational wall. You have the roles, buzz terms, ideas – but Sales are still agreeing on crazy deliverable without the team doing the work being involved in the decisions made. Without some senior muscle you’re heading for a hard time.
If management can’t be bothered to hire an experienced ScrumMaster.
It’s pretty much what it says on the tin. If you’ve a developer who want’s to their hand at Scrum & the best management can do is change the title of the new grad who has joined, then..think twice. Scrum is deceivingly easy to understand, but very difficult to actually do well. An inexperienced SM with no coaching or experience will likely give people a bad experience with Scrum as opposed to seeing the use of Scrum.
THE ART OF THE POSSIBLE
ScrumMasters are there to highlight dysfunction, to help transform the work place – to relentlessly pursue perfection.
That should be considered with what, is possible.
The appetite,desire & constraints of an organisation must help you determine when Scrum is the adventure you take, or not.
blogagility.com 