Scrumorakel - Blog - Comments

Andreas Edelmann: Estimating relative sizes (e.g. story points)

nospam@example.com (Andreas Edelmann) — Wed, 31 Dec 2014 16:11:34 +0100

Forget everything you know about velocity and methods to increase it. I discovered an awesome method which will change everything and change the thinking of Scrum for you completely. A while ago I planned a sprint with my 5 person Scrum team and I used this motivation method to increase the velocity by 70%! The only things I needed for that was some Euros and the imperturbable believe in the power of the "hang a carrot in front of a bunny" effect. So I transferred this effect to my team and made a genius change...I replaced the carrot with a Döner and pow the velocity increased by 70%. Promising my team to get a Döner if they beat the hell out of the story points was a big success. At the end I had costs of 18€ and an nearly empty backlog plus a good feeling going into holiday.

At the end as some of you may have noticed I am just joking. Yes the story is true, but it was more a funny competition and should not stand for any serious method motivating your team with food or other stuff. The consensus of this comment is that in my opinion also for Scrum the fun at work, to enjoy what you are doing is one of the most important things. What in detail that is for your team you have to find out by yourself.

Scrum tool: Change Is Hard

nospam@example.com (Scrum tool) — Fri, 16 May 2014 14:56:08 +0200

Very true. Waterfall has been around for a long time and most organizations feel uncertain about scrum implementation simply because they lack a clear understanding about the framework. There is a still a tendency to compare waterfall with Agile, and most people fail to understand both the development methodologies are very different, and therefore cannot be compared. It is true about the “comfort zones” - managements find it difficult to change because they are very much used to their comfort levels and abhor doing anything different unless strictly required.

Dominik: A critical view on SAFe

nospam@example.com (Dominik) — Sat, 01 Mar 2014 09:55:23 +0100

Here is the most recent article on SAFe, written by Ron Jeffries (you should know him!):
http://xprogramming.com/articles/safe-good-but-not-good-enough/

Hans-Peter Korn: A critical view on SAFe

nospam@example.com (Hans-Peter Korn) — Mon, 16 Sep 2013 13:45:00 +0200

Holger, you ask:
"how much derivation from SAFe would be okay to still say you're basically doing SAFe (similar to the discussion of how close you have to follow the exact words from the Scrum guide)."
I would say: There is NO value to follow some rules - value is generated, when those "rules" are emerging which are as far as possible appropriate for the specific situation of an enterprise. And I am glad, that - in contrast to Scrum - yo may take (and modify) from the SAFe-documentation what is useful for the specific situation. And you may name the result SAFe or "whole scale agility" ... or whatever you want. See for that - as an illustration - http://www.prettyagile.com/2013/09/a-perspective-on-scaled-agile-framework.html which is recommended by Dean.

Coming to "I understood, Dean recommends to start off on the team level."
Well, this is one possibility. I myself do not prefer this. I - based on the idea of "governance by context", coined by Helmut Willke - prefer to start on the program level as the context for the work of the teams and give the teams the freedom (and responsibility) to organize themself in an appropriate way within this given context.

Holger Schauer: A critical view on SAFe

nospam@example.com (Holger Schauer) — Mon, 16 Sep 2013 09:26:30 +0200

I like this overview and criticism a lot, but would like to add to the discussion of how "agile" SAFe my understanding of how Dean explained how to introduce SAFe in an enterprise on this years GOTO Zurich (which I guess you might have heard yourself while you were there): from what I understood, Dean recommends to start off on the team level. If you've introduced agility on that level successfully and need to go beyond that level, take it to the program level and if you need to handle multiple programs, take it to the upper level.

My understanding of this is that this is intentionally done to ensure that the influence of the teams is big. The question whether this is really how SAFe is put into practice, is of course valid, especially now that SAFe seems to get more and more attention from bigger enterprises. It's also sad that SAFe as a framework is intentionally silent on how to introduce SAFe -- I also fear that many enterprises might be tempted to leave many things as they are if there is the superficial impression that the old way is compatible with the SAFe way (e.g. a very hard division of labor and responsibility) when SAFe itself recommends high interaction between teams on all levels.

To me, it's also highly unclear of how much derivation from SAFe would be okay to still say you're basically doing SAFe (similar to the discussion of how close you have to follow the exact words from the Scrum guide). I'm going to take a look at Scott Amblers DAD http://disciplinedagiledelivery.com/ since I think that he takes the approach of providing a set of questions and recommendations on how to solve a given task (e.g. release management), which looks more open and less prescriptive to me.

Hans-Peter Korn: A critical view on SAFe

nospam@example.com (Hans-Peter Korn) — Sun, 15 Sep 2013 20:23:44 +0200

Dominik, at the beginning of your blog I read:
"..discussion in the community whether SAFe is really Agile or not.." and after this you take the "Agile Manifesto" as "THE" reference for "agile".

In your critical view on SAFe I see a lot of your personal interpretations why you think, SAFe is not conform with the four values of the manifesto. But for me no one of your interpretations is the only possible one - and therefore a clear contradiction to that values.
For me SAFe - same as Scrum - can be implemented in a way following this values or in contradiction to them. And - we all know - the majority of implemented practices naming themself "Scrum" are in contradiction to one or more of that agile values (and are not following the Scrum Guide completely - as it should be, see "End Note" on page 16)
BUT: Many of them are working reasonably well.

So: Does it really matter, if something is in line with the Agile Manifesto?
No. The goal of a business is not to be in line with a Manifesto. The goal of a business is to make profit.

And to make profit in our very volatile recent age means, to have "the capability to successfully cope with changes in circumstances“ (which is the definition of "agile" of David S. Alberts in "The agility advantage - a survival guide for complex enterprises and endeavors" DOD-CCRP, Washington 2011. ISBN 978-1-893723-23-8
And he describes this "components of agility":
o Responsiveness
o Versatility
o Flexibility
o Resilience
o Innovativeness
o Adaptability

For me this "definition" of Agility fits much better and is much more adaptive to different kinds of changes in circumstances of bigger enterprises than the definition of the "Agile Manifesto" which is too much restricted to the development of products, especially of software, only.

So:
1.
I doubt, that a discussion how far something is "agile" or not is adding any value to an enterprise
2.
If we have such a discussion anyway we have to create a shared understanding of "agile" in an enterprise context first.

Dominik: A critical view on SAFe

nospam@example.com (Dominik) — Sun, 15 Sep 2013 11:54:51 +0200

Hi Rainer,

Thank you for your comment!
I see your point and agree that SAFe can be used in an agile way. My main critic is that this is not instilled in the framework itself but has to be interpreted that way by the "user" of the framework - which is difficult due to the shortcoming pointed out above.

There are alternative solutions available, the best of which (in my opinion) is that of Larman and Vodde. Unfortunately it's not exactly a "blueprint" and therefore much more difficult to implement.

Too bad the world is complex and there aren't silver bullets

Rainer Grau: A critical view on SAFe

nospam@example.com (Rainer Grau) — Sun, 15 Sep 2013 11:04:12 +0200

Hi Dominik,

Your critics is valid in many aspects - but there are buts on my side regarding you critic:

Fact is that thing in real live are more complex if size and number of persons involved are beyond a certain limit.

I see this limit at about 40 individuals working on "PRODUCT" in the same context. under these constraint (constraints matter!) the Scrum idea with its 3 roles does not scale anymore. There are the three levels of portfolio, program and team that Dean identifies. That is in sync with my experience. Then - well - new names for rsponsibilities start appearing ... and that are roles like a program manager or an enterprise architect. Does'nt matter how you call them, you need names to understand a responsibility of a person.

Dean has the standing to give the community a blueprint. I see SAFe as a valid and possible blueprint - but implementing this, you should "inspect and adapt" to the context - as Ken proposes to do.

Final point: Dean at least provided us with positive and guiding thoughts and ideas. Other people offer only critics without adding value to the community (you're not one of those, I know!).
But I think when sending critics, we should add as well ideas to address the critics with value That's harder to do.

...and as you say .. not so easy, there is nothing like the silver bullet. An as I know Dean, he does not think that SAFe is "THE" silver bullet.

Best Rainer

Dominik: A critical view on SAFe

nospam@example.com (Dominik) — Sat, 14 Sep 2013 11:34:16 +0200

Hi Christiaan,

you are most certainly correct: Some people out there use Agile terminology without being Agile. I call those "facade Scrum" implementations.

I am heavily working on the clearer picture your are mentioning. If you want to, you can contribute as well. Take a look at the surveys here: http://scrumorakel.de/surveys/ - they will be available until end of September.

Let's improve our world!

Dominik

Christiaan: A critical view on SAFe

nospam@example.com (Christiaan) — Fri, 13 Sep 2013 13:51:07 +0200

Nice post Dominik! I agree with your analysis and conclusion. SAFe seems to be preoccupied with structure and process instead of promoting a (radical?) mindset, culture and philosophy.

But can't the same argument be leveled at Scrum ? It's perfectly possible to have a team that works according to the Scrum framework (they walk the walk and talk the talk), but that lacks the Agile mindset. I have seen several examples of this. Applying Scrum won't automatically change corporate culture. To me, Scrum is also mostly focused on structure and process. It is often assumed that agility will follow automatically, but I strongly doubt that.

The same applies to SAFe. There certainly is a potential for radical change, away from a tayloristic approach. But it is not implied and not actively promoted. It may be a first step in a larger transition.

Don't you think we are drastically in need of a clearer picture, a stronger vision, of what this 'Agile mindset' actually means? Without a strong vision, it's hard to generate energy for (radical?) change, as Kotter would say. On a more philosophical level, all this talk of 'Agile mindsets' is certainly quite abstract.

Erich Buhler: A critical view on SAFe

nospam@example.com (Erich Buhler) — Thu, 12 Sep 2013 14:52:28 +0200

I agree that SAFe does not fully instil a different mindset but it provides a starting point for everyone coming from a traditional enterprise project management environment and looking to "easily" accommodate into the agile world.

Most of us worked for huge companies with enormous projects and know how complex, ??irrational and painful their processes, role interactions and structures are, making really hard for them to move away from the traditional ecosystem.

Incorporating SAFe can offer a solution without much hassle but at the cost of loosing part of the Agile *mentality*.
Who is going to make sure that inertia doesn't pull the whole company back to the command and control days? That is a huge risk and unfortunately there is no specific role to look after that area in *SAFe*. Everything relies on the good will of people not crossing that thin red *line*.

But it is not all good or bad in life... SAFe provides many great tools and the book offers some deep analysis into the problematic suffered by enterprise companies at the time of trying Agile.

Most of the ideas found in the book can be cleverly implemented in huge projects and get good results as long as you have in mind that the most important thing is making the shift towards the agile mindset and making sure people do not just accommodates to new Agile reality.

Dominik Maximini: How to prepare for the Professional Scrum assessments

nospam@example.com (Dominik Maximini) — Sat, 27 Jul 2013 22:48:44 +0200

I especially recommend you to read "The Enterprise And Scrum" by Ken Schwaber. It is truly a precious source, if you want to learn about Scrum.

Dominik Maximini: The "Nature of Scrum Survey" awaits you!

nospam@example.com (Dominik Maximini) — Thu, 30 May 2013 14:46:08 +0200

The goal is to find out which cultural characteristics are inherent to Scrum. "None" is also a possible answer. In a first step, I will analyze Scrum. An analysis of Agile, XP or other methods might follow later (I am not sure, yet). The same is true for an analysis of national (e.g. USA) or professional (e.g. IT) cultures. At the end of the day, companies shall have the chance to generate an expectation of what to expect when they introduce Scrum. They should know what they are up to. They can then decide if they want to/should/can go for Scrum, or if they want to think about alternatives. After all, Scrum might not be for everybody.

Hans-Peter Korn: The "Nature of Scrum Survey" awaits you!

nospam@example.com (Hans-Peter Korn) — Thu, 30 May 2013 14:42:31 +0200

Interesting to see something as a "Scrum Culture"!
Is it seen as a subset of the "agile culture"?
Is it a "new" culture - or similar to "cultures" existing since centuries (i.e. at SEMCO and Morning Star)??
And:
I am wondering how far the "mantra": the company has to change the culture - otherwise Scrum will not work will turn out as "true".
If it is true, then Scrum is not a - tailored - solution for some specific and important challenges of a company but a "dogmatic solution" and therefore causing inappropriate problems in a company.

Maybe we can discuss this at the SCRUMDAY in Berlin here: http://www.scrum-day.de/workshops/dieagileorganisationvomhypezumdailybusiness.php

Dominik Maximini: The "Nature of Scrum Survey" awaits you!

nospam@example.com (Dominik Maximini) — Wed, 29 May 2013 07:22:57 +0200

Update: The survey will also be available at the Scrum Day Europe this year.

Dominik: The "Nature of Scrum Survey" awaits you!

nospam@example.com (Dominik) — Sat, 18 May 2013 08:13:37 +0200

Hi Koen,

as of now, this is not planned, yet. However, your idea is excellent; I will contact Gunther and ask him if he wants to distribute the survey there as well. And of course, you can always use the online surveys here: http://scrumorakel.de/surveys/

Koen Halma: The "Nature of Scrum Survey" awaits you!

nospam@example.com (Koen Halma) — Fri, 17 May 2013 08:35:03 +0200

Will this survey also be available on the Scrumdayeurope even in Amsterdam on the 4th of july?

Dominik Maximini: How to prepare for the Professional Scrum assessments

nospam@example.com (Dominik Maximini) — Sun, 07 Apr 2013 13:14:40 +0200

Some clarification on the PSPO I assessment: You will have to answer 60 questions in 60 minutes. It is harder than the PSM I assessment and I strongly recommend you revisit the course materials (in addition to the other preparation steps) before trying it.

Charles Bradley: Book review: Succeeding With Agile (Mike Cohn)

nospam@example.com (Charles Bradley) — Tue, 02 Apr 2013 22:20:52 +0200

Ahhh, thanks Dominik. Now I understand what you mean. When will your book be translated to English?? Sign me up!

Dominik Maximini: Book review: Succeeding With Agile (Mike Cohn)

nospam@example.com (Dominik Maximini) — Tue, 02 Apr 2013 20:16:48 +0200

Hi Charles,

well, there are tons of literature out there. Most of it is rather superficial though. So far, there is only one book that explicitly talks about organizational change and Scrum - but it's only available in German and the author is myself.

If you are in for a deep dive on organizational change, you probably want to start with John Kotter's "Leading Change", continue with Schein's "Organizational Culture and Leadership", Deal's and Kennedy's "Corporate Cultures", and Cameron/Quinn's "Diagnosing and Changing Organizational Culture". Once you have gone that far and still want to dig deeper, top it with Martin's "Organizational Culture". This should put the other books into perspective.
You will have many ideas and notions then. Most likely, you will also have identified an area where you want to investigate further. However, with organizational change it's similar as with being a good Scrum Master: You can read as much as you want, visit courses by the dozens and still won't improve much unless you put your knowledge to daily practice.

Best

Dominik

Charles Bradley: Book review: Succeeding With Agile (Mike Cohn)

nospam@example.com (Charles Bradley) — Tue, 02 Apr 2013 20:06:43 +0200

> In summary, again, I liked the book a lot and recommend you to read it. However, it is entry literature - not an advanced guide to organizational change.

Are there any books you DO recommend as an "advanced guide to organizational change"?

russ: One Scrumguide is not enough

nospam@example.com (russ) — Tue, 12 Mar 2013 11:37:22 +0100

Of course you are correct that experience transcends learning.

Here in the West it was formalised in Bloom's Taxonomy, but most knowledge systems have multiple levels of knowledge and understanding for those who invest the time.

The established wisdom is that these deeper levels are there to be "discovered" rather than "documented" so that students attain and realise depth of understanding incrementally.

For this reason, guides such as you suggest have traditionally been valued and protected. Some exist only as an oral tradition, some are "concealed openly" via symbolism and tradition.

It's a little like having an "advanced" options menu. It tends to attract the attention of those who would do better with "simple options"!

Thanks for an enjoyable and thought-provoking article.

Max Janzen: One Scrumguide is not enough

nospam@example.com (Max Janzen) — Mon, 11 Mar 2013 15:08:12 +0100

Hey Dominik.

It’s very interesting idea which you described. I would like to try to reconsider what you said in reverse order.
Creating the “Ri – Scrumguide” is a great idea and would help to define the fundamentals and the core of the philosophy. This would make the mastering of Scrum easier, because every member would have the same “process – goal”.
The “Ha – Scrumguide” would stay the same (more or less) and describe the necessary artifacts, rules and so on.
I have the most problems imaging the new “Shu-Scrumguide”. Currently, there are in existence a lot of books, which describe most “best practices” about implementation of Scrum Framework, providing the artifacts and following the rules. The challenge is to found the best one for the current situation. In my opinion, the ultimate best practice would be too abstract to use or too static to be acceptable in any situations. Another problem might be to try implementing a scrum in form “step-by-step” order. In my opinion the aspect of “inspection and adaptation” is very important for acceptance and understanding of the framework.
In conclusion, I would prefer to add a new chapter on the current Scrumguide to describe the “Ri-State”, instead of creating the three new ones.

Kind Regards
Max

Andy Geldman: One Scrumguide is not enough

nospam@example.com (Andy Geldman) — Thu, 28 Feb 2013 19:11:09 +0100

Interesting idea, I like it!

I think teams new to Scrum (Shu) benefit from doing it "by the book" until they really understand why they are doing it and can (carefully) make some adjustments.

Shu teams could be too eager to move on to the Ha stage. To avoid that, rather than presenting the three guides side-by-side, the user could be walked through a few very quick questions before being pointed to the appropriate guide for them.

The Ri Scrumguide sounds like it would be the Agile manifesto...

Stefan: Was sagen Zertifizierungen aus?

nospam@example.com (Stefan) — Mon, 01 Oct 2012 22:44:06 +0200

Hallo Dominik,

Danke, Dominik, für die schöne Zusammenfassung. Inzwischen hat die Scrum-Alliance zum Glück etwas angezogen, was die Qualität der Tests betrifft und ist, glaube ich, auf einem besseren Weg.

"IMHO ist das PSM II derzeit das einzige Zertifikat am Markt, mit dem man als ScrumMaster ein Alleinstellungsmerkmal erzielt."

Ich würde den Certified Scrum Practitioner noch erwähnen. Meine Erfahrung ist, dass diejenigen, die CSP sind, doch wirklich eher diejenigen sind, die dem Thema leidenschaftlich gegenüber stehen und meist sehr kompetent sind (das ist meine Erfahrung). Vermutlich liegt das nicht unbedingt an der Zertfizierung selbst (es gibt keine Kurse dafür), sondern weil eben genau Zertifizierungen in der agilen Welt (och) nicht so eine Rolle spielen und wichtig sind wie in der traditionellen Welt. Wenn dann eben doch jemand sich die Arbeit macht, CSP zu werden, macht er das meist eher aus Interesse als aus Titelgründen.
Natürlich wird umgekehrt nicht unbedingt ein Schuh daraus: Es gibt viele, die auch ohne Zertfizierung sehr kompetent sind!

-=Stefan=-

Dominik Maximini: The reasons why distributed teams are less effective

nospam@example.com (Dominik Maximini) — Thu, 30 Aug 2012 22:00:21 +0200

Hi Vikram,

yes, some tools/remedies are proposed in the book. Unfortunately, there is nothing like a blueprint - standard solutions tend not to work for complex problems.
Your tool is looking good, yet some options can be argued about (e.g. the KPI area). I guess it all comes down to the question how one uses the tool in practice.
What we never shall forget though is, that individuals are more important than tools. Not even the best tool in the world can spare us the hustle of interacting with the people and addressing their needs.

Keep up the good work!

Best

Dominik

vikram kapoor: The reasons why distributed teams are less effective

nospam@example.com (vikram kapoor) — Thu, 30 Aug 2012 21:15:53 +0200

Dear Dominik,

Informative article. Maybe somebody can create a closeness model whereby a solution is proposed per distance category. For example what can you do with cultural distance. Perhaps that is a part of the book "Uniting the Virtual Workforce". I shall order it. We want to play a part in decreasing this distance and have therefore created an Agile cockpit (www.agilecockpit.com) to reduce this distance perception and written a small book on it "Engaging offshore teams is childplay(www.prowareness.com). Have a look at them and give feedback!

Regards,
Vikram Kapoor