Schwaber and his negative feelings about SAFe. Reads a lot like the jilted sister. “Only I am allowed to improve. If anyone else does it, they are merely copying me. – Ken” (oh, where did Scrum come from btw?)
Oh, by the way — surprise, Ken Schwaber is involved in a consultancy too that will charge you to “customize Scrum.” Hypocrite. Hypocrite.
Psstt. Hey Ken. SAFe has 27% of the market share in agility. And it is growing 150% per year. Actions speak louder than your words. Relentless improvement Ken. Try it sometime.
Advertisements
If you read it and found some value. Please share it:
Reblogged with permission from Preetam De, the original author of
this content, as a contributor to blogagility.com. Originally published
on The Dark Horse on September 2, 2016.
While reading Invest on an Epic Story and get the job Done, there was a discussion about how the done checklist can be formulated with mandatory and optional sub-tasks. This article can be considered as the prequel which forms the basis of that implementation. A question we always come across while explaining how to define Done for a Story is –
What is “Done” or “Done Done”? How much is enough?
I have been doing research on agile contracting while working on an implementation plan for a client. This is a hot topic now and Dean gives us some great insight into how to form your approach. Adapting your sub-contracting strategy and model is critical if you want to keep using vendors to augment your enterprise.
I am teaching Leading SAFe with my co-instructor Jose (Joe) LaTorre USMC (Ret.) this Friday! The kit is prepared! We have some prep work to do still but I am SUPER EXCITED about teaching the course! Thanks to the Scaled Agile, Inc. folks for the support and to my gracious and eager to learn clients at ESC!
http://www.scaledagile.com/leading-safe/
If you read it and found some value. Please share it:
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.
If you read it and found some value. Please share it:
Reblogged with permission from Jem D'jelal, the original author of
this content, as a contributor to blogagility.com. Originally published
on LinkedIn July 8, 2016.
Jem D’jelal Coaching individuals & teams to find “better” ways of working.
Is that they’ve always been there.
Inside of the Scrum guide or NOT, the values have always been there.
Just today, I over heard this conversation: ” Scrum’s coming out of the dark ages man, it’s doing what agile did with values”.
I almost choked on my sandwich.
It was a display of self control to not interject :s.
So maybe you can help me?
Tell me, honestly:
Now that we see it printed on a piece of paper, is that some sort of call to action, are you now “allowed” to use the values or place a greater emphasis on the values?
I feel uncomfortable with the celebration.
It makes me wonder.
If people are celebrating Scrum Values & it’s been around in popular use for almost 10 years, then:
Have people viewed Scrum as just practices all of this time?
When people learned Scrum, did most not enquire beyond the guide?
When people were taught in a CSM class, were they taught that the guide is all they need to understand Scrum?
If the answer is yes, I think so many of us practising Scrum have been missing the point.
And in many ways it answers a question I’ve had in the back of my mind for so long “Why do more and more developers in London dislike Scrum?”. Well now it seems obvious, perhaps?
If you’ve seen Scrum as an 8 page guide & haven’t used the values then that’s just using a skeleton with no soul.
Scrum isn’t a mechanistic thing which is JUST practices – it’s so much more than that.
So the excitement makes me think, well what have we been doing all this time?
Scrum Trainers, ScrumMasters, Scrum Coaches…surely we’ve emphasised the importance of Scrum value to those learning & the addition to the guide isn’t really a game changer.
Or is it for you?
Maybe you’ve always used the Scrum values & are glad they have made it into the guide as you feel that it’s given the importance it deserves?
I get that angle, I see it.
Just that if people have just felt like we can embrace Scrum values – now – what exactly have we then been embracing?
If you read it and found some value. Please share it:
Today Ken Schwaber and Jeff Sutherland, the creators of Scrum delivered a webinar on their latest update to the Scrum Guide. The update was a simple one, adding the 5 values of Scrum to the Guide. And when I say simple I mean simple in terms of…
