Entries by Dominik Maximini

The Scaled Agile Framework, developed by Dean Leffingwell, is getting more an more traction in Europe and the U.S. Many companies try to adopt the framework, or parts of it, in order to increase their Agility. However, there is a controversial discussion in the community whether SAFe is really Agile or not. This post describes my view on that.

Agile Manifesto

The Agile Manifesto says:
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.”

That means that Agile comprises of continuous improvement, people, collaboration, product delivery, customer collaboration and requirements change. If a framework calls itself “Agile”, it should fulfill those.



SAFe

First of all, I like Dean and the notion of having a solution for big companies that aids them in becoming Agile. If you don’t know SAFe yet, I recommend you visit http://scaledagileframework.com/. That website is very well designed and shows you detailed information on all aspects of SAFe in the so-called “Big Picture”.
In short, SAFe divides product development into three levels: Team, Program and Portfolio. Along with that go a couple of artifacts, roles and responsibilities. The devil is in those details (as of 11th of September 2013).


Team level

The Team level is basically standard Scrum. But wait: Not 100% standard I would say.

• The Product Owner is not necessarily responsible for the return on invest of the product. This is attributed to the “Enterprise Product Manager”. In addition, the PO should “participate” in the “extended product management team” and is usually part of the development organization, not of product management. This means that we are back to the good old days where there was a chasm between product management and development rather than working hand-in-hand as it is intended in Scrum.


• The Scrum Master is described as “management/leadership proxy” as a part-time role (25%) for a developer. He should also focus on spreading technical practices throughout the company. While technical practices are certainly important, this strong focus, the limited time and the complete lack to mention the role of a change agent means to me that SAFe does not want the Scrum Master to help spread Agility throughout the enterprise. So the main benefit of this role is chipped away.


• The Development Team is called “Developers and Testers”. This is good, but lacking other roles such as UX, Architecture, Database, etc. We will encounter those again on the Program level. SAFe does not explicitly say that those roles may not be on the Development Team, but people reading the chart and looking at their own org charts may be tempted to think so.


• SAFe involves a “HIP”-iteration, meant for “Hardening, Innovation and Planning”. It also gives some reasons why HIP-iterations are necessary: 1) Some quality measures might not be economical every Sprint and have to be done once per Release. 2) “care must be taken to provide scheduled time for innovation, exploration and out-of-box thinking”. 3) Release planning must happen somewhere. It is true that some quality measures cannot be taken every Sprint and need specific time allocated for that. On the other hand, innovation and release planning should not just happen once a release, but continuously. Imagine somebody walking up to you, saying “be innovative now, you got 3 weeks!” Doesn’t have the right ring to it. On top of that, the name “hardening” is a concept often already known to enterprises. If they sense that this is a good thing and their “solution” [SAFe] has it as well, they might just stick with what they have and not change a bit. So inspection and adaptation goes out the window.


• There are common Releases for all teams prescribed. While this is not bad or a violation of Agile, I don’t like the fact that it is prescribed. What if a company would be better off having one always working “release branch” and all teams constantly contributing to it at different points in time?

Program level

The program level is designed to manage the team level in SAFe. While this is an existing condition in many companies it is not what Agile aims at. Let’s take a deeper look:

• The roadmap contains the higher-level planning for the Teams' backlogs. The first sentence explaining the roadmap speaks for itself: “The purpose of the program roadmap is to establish alignment across all teams involved in the ART [Agile Release Train] while also providing predictability to the deliverables over an established timeline horizon.” So the teams are not allowed to self-organize their alignment and predictability is the goal rather than maximization of value? Hmm...


• Product management does all the prioritization and value analysis. SAFe accepts the status quo in many enterprises and distinguishes between Product Owner and Product Management. Product Management also does the customer interaction. This does not help collaboration but is a tayloristic division-of-labor approach.


• By the way: There is a team of “Business Owners” who have the last say on ROI etc. So who is responsible now: Product Management, Product Owner, Business Owner – or maybe even somebody at the portfolio level? I lost track.


• There is an additional Release Management Team that is responsible for coordinating the outcomes from the teams in a release. It comprises of senior management of different departments. Again, the teams are not doing this self-organizing but there is a central authority doing this.


• A funny thing exists in SAFe and is called “System Team”. It is described as follows: “The system team is often responsible for initially building some of the initial common development infrastructure and then moves on to other program level activities, including system-level continuous integration and end-to-end testing.” While I do understand the need for somebody providing and maintaining the development infrastructure, this system team can be easily mistaken for a central quality institution. SAFe does say that the responsibilities are shared between the development teams and the system team, so the developers are still responsible. Unfortunately, the structure can easily be mistaken for the System Team ordering the development teams around on what to do. I believe the concept of “System Team” needs some intense rework.


• There is a “Release Train Engineer”, described as “Uber-Scrum Master” or “Agile Program Manager”. While I do like the idea of having a Scrum Master on the level of management, I do not enjoy some of the responsibilities attributed to this garbled role: "Escalates impediments" (so he doesn’t solve them), "Reports status to Release Management Team" (which might lead that role to fulfill the needs of the RMT rather than those of a Scrum Master), "provides input on moving team members to address critical bottlenecks" (here the resource-shuffling game starts and shows the taylorisitc mindset again). SAFe does describe the RTE as being a servant leader, but the responsibilities make it hard for anybody filling that role to comply.


• The UX function is also outsourced to the program level. They are not part of the development teams but rather “provide Agile Teams with the next increment of UI design, UX guidelines, and design elements in a just-in-time [...] fashion.” Where is the team approach? Collaboration? Do we now have to wait a Sprint before we get our UI design? Maybe two? Or three?


• There is a System Architect role as well. He is to “evaluate design alternatives, and perform cost benefit analysis”. He also – amongst other things – responsible for creating Architectural Epics and Features for the development teams to implement. So the teams do not self-organize in that regard and are not responsible for their own architecture. Further down, the Architect is described as not being allowed to dictate anything but rather being a mentor and coach. In my opinion, this description does neither fit the stated responsibilities nor the standard (by traditional managers) understanding of the role and thus is not helping Agility.

Portfolio level

On the portfolio level, “programs are aligned to the enterprise business strategy and investment intent.” I believe this level to be important and won’t criticize much here since most enterprises will be busy with the program level anyway. It’s just important to note that there are again a couple of roles (Enterprise Architect, Epic Owner, Program Portfolio Management) with differing responsibilities.


Conclusion

While I do not approve of the style Ken used to criticize SAFe or the “one is better than the other” comparison of Anderson, I do believe SAFe to be Janus-faced. It most certainly can be interpreted and lived in an Agile way and will work like a charm then. However, the descriptions and corresponding interpretations of most readers/users will lead to nothing but the preservation of the status quo. SAFe does not help to instill a different mindset. On the contrary: people don’t have to change with SAFe – they can just go on as they always did and call themselves Agile now. Two questions arise:

1. Why is this a problem? I don’t need/want to be Agile!
   Well, then go with traditional models and don’t use one that has “Agile” in it’s name. A tool called “Scaled Agile Framework” should be Agile and you should only implement it if you want to be Agile.


2. Are there alternatives?
   Unfortunately, not many. But you might want to take a look at this little article by Larman and Vodde. They have written a book on the topic as well and it is much closer to Agile in my opinion.

We also looked at the Agile Manifesto at the top of this post.
Agile comprises of continuous improvement, people, collaboration, product delivery, customer collaboration and requirements change. In my opinion, SAFe fulfills product delivery, [arguably] customer collaboration and requirements change. It falls short of fulfilling continuous improvement (Agile Masters are ripped of their balls), collaboration (of different functions) and people (self-organization is hampered). SAFe itself is very much process-focused and not aiming at being optimized itself.

It all can be summed up the following way:

SAFe believes that the world is good as it is and the existing companies, processes and structures created that world. So the status quo has to be accommodated.
Agile believes that the world is not a good place (at least for people working in software development) and should be improved. The status quo – especially the tayloristic thinking - has to be changed.

This doesn’t fit together. SAFe isn’t Agile. It could be a small step on the way to Agility, but it certainly is not the end state (if something like this even exists in Agile).

I just read The Professional ScrumMaster's Handbook, written by Stacia Viscardi, a Scrum coach. While the book was certainly entertaining, it was not exactly educating for me as a Scrum Coach; that is, I didn't learn much from it. If you are just embarking onto your Scrum Master journey, however, the book is nevertheless very valuable for you. I am a critical reviewer - you will notice that when reading this article.

Now, here is what I think:

The audience is stated as "This book is not for ScrumPuppets who simply do what they're told; rather, The Professional ScrumMaster's Handbook is for anyone who wishes to be a true ScrumMaster as the role was originally intended: a fearless, professional change leader."
I liked that excellent intro, which set very high expectations for me. Unfortunately, the brilliant term "ScrumPuppet" only appears once in the whole 308-pages-book and didn't even make it into the index. I was a little bit disappointed about this. In addition to that, the topic of organizational change is not covered deep enough to live up to my expectations as advertised. The topic of how to be a change agent is covered, while the higher-level process of changing a organization's culture is not. On the other hand, the book goes into depth what a Scrum Master should do and not do, which characteristics and skills he needs and so on. The true value, however, lies in the described experiences of the author, which are quite beneficial for the reader.

Chapters 1 to 3 dive into Scrum. I very much liked the description of the history of Scrum, including it's roots and the background of Ken and Jeff. Very comprehensive, very good! Unfortunately that's about what I liked in those chapters. There is a constantly alternating mix between the core elements of Scrum and value-adding best practices. While this is certainly a good idea, an unexperienced reader will not be able to discern between those two and might conclude that everything described is part of Scrum, which is not the case. In addition to that, the author uses her own terminology in several places (e.g. "Scrum Delivery Team" on page 18) and also displays her own interpretation of the application of Scrum, without making the deviations from the Scrumguide (I won't discuss the differences of the Scrumguide and the Scrumalliance's Agile Atlas Core Scrum, since it is not "blessed" by Jeff and Ken) transparent (e.g. "everyone is welcome to attend" [the Daily Scrum] on page 21). In fact I got the impression that the author didn't read the Scrumguide and might lack some knowledge about the most recent developments of Scrum (e.g. commitment vs. forecast).

In chapter 4, the tide turned for me. The author comes up with very clever and colorful comparisons (e.g. comparing the sprint boundaries to castle walls or comparing stressful pace with writing to the very last second in an exam - which of course doesn't exactly raise quality). She also gives good practical advice for certain situations a Scrum Master will face sooner or later. This trend continues through the next chapters as well. Here is one especially nice tidbit, I want to share with you (page 136): "Just like the snake sheds its skin every so often to reveal shiny new scales, an individual, a team, and an organization must shed its old culture skin by creating new knowledge and sharing stories about the new way of doing things."

Of especially high value is chapter 6, where Stacia shows different information levels and compares them brilliantly with different magnification levels of a microscope. 1x magnification is the product vision, 2x the product roadmap, 4x the release plan, 8x the product backlog, 16x the sprint, 32x the tasks, and 64x the team room. Each magnification is explained and augmented by best practices and examples. The average reader benefits greatly from that.

The author discusses the values of Scrum in chapter 7. A good idea with many important hints. Unfortunately, some important studies are mentioned - but not named or referenced in the text (e.g. pages 186 and 188). This is very unfortunate since this critical information cannot be used to work with management or critics - especially since this information is correctly displayed throughout the rest of the book. So yes, the information itself in this chapter is helpful, but you will have to do your own research to validate some of the points.

Chapter 8 - Everyday Leadership for ScrumMaster and Team - straightens chapter 7 out again. An excellent self-reflection exercise and the plea to push your boundaries beyond the comfort zone fire off your thoughts and are supported by all sorts of analyses about your Scrum Master personality. Very helpful, especially for the just-starting Scrum Master.

Chapter 9 deals with shaping the Agile Organization. I expected instructions for organizational change here, but wasn't able to find a central theme. My impression was that of a collection of interesting puzzle pieces that are scattered around, not forming a clear picture. So while the individual sections are interesting and good, don't expect them to form a wonderful sculpture.

This gets a little bit better in chapters 10 and 11, where at least some of the (new) puzzle pieces are fitted together, still not forming a clear picture yet. However, even though the borders are blurry, you still can see some of it. In other words, some very important facts are highlighted and explained. There definitely is a lot to be learned from those chapters (for a new Scrum Master); still, the big picture evades my grasp. The title of chapter 10 is "Scrum - Large and Small", which is then followed by some challenges, which apply to small Scrum implementations as well (at least in my opinion). So the challenges are great to learn from, but they don't specifically contribute to large-scale Scrum. Some other important aspects of scaling Scrum are not mentioned at all - so don't expect a scaling-Scrum-guide or something like that!

Summing it up, there is a lot of useful information in that book. A new Scrum Master should read it to learn from Stacia's experience. However, the new Scrum Master should not read it as his first book, because he could get confused by the aforementioned statements. In addition, after you read about the history of Scrum, hop on to chapter four. Be aware that this book seems to be a "Minimum Viable Product" with still some room for improvement. I count on the second edition removing the shortcomings of this first one and raising the books value even higher!

You most likely will remember the start of our great study, the "Nature of Scrum Survey". The original idea was to collect 200 or more responses (so it is remotely statistically validate-able) and conduct the statistical analysis in August. Even though many people participated and offered their opinions, only 165 replies (74 for the Schneider questionnaire) could be gathered. This is not enough, as you can see in the burndown chart (yellow is the main study, blue the Schneider add-on):



To make this even worse, there was a break out of the summer holiday epidemic, so a simple extension by a week or two won't work. Instead I decided to extend the data entry period to end of September / early October. If you are waiting for the results, this means that you will have to wait a little while longer - sorry about that. I believe this to be necessary since the quality of the results is more important than a quick answer.


In case you want to support the endeavor and haven't filled out the survey yet, visit http://scrumorakel.de/surveys/ and sacrifice some of your precious time. You are of course welcome to spread the link among your networks. The more replies we get, the better the results will be.

Have you already heard about Lean Startup? It's a valuable method to reduce uncertainty and reduce complexity. In my opinion, it's a tool every Product Owner should know. It's also a must-have for every startup and research project. I won't explain the method now since it is quite straightforward (if you want to learn more, read the book The Lean Startup: How Constant Innovation Creates Radically Successful Businesses).


What I am noting is the rise in Lean Startup events. The community seems to be growing significantly. A very interesting mix of people, consisting of entrepreneurs, big company people, "normal" Scrummers - they are all there. If this is an interesting piece of information for you, keep your eyes open for a LeanStartup Meetup or a LeanCamp. For example, soon there will be a LeanCamp in Stuttgart. Looking forward to meet you there!

What is the nature of Scrum? What are it's cultural characteristics? What are companies going to face if they introduce Scrum while trying to maintain their existing corporate cultures?

I am going to find out - with your help!
At http://scrumorakel.de/surveys/ you can find two surveys, each of which will take you around 30 minutes to complete. While this is quite a lot of time I am asking of you, you will help thousands of companies worldwide in their Scrum adoption. This might include your own as well at some point in time. If you have to make a choice, only do the first survey. They are ordered in terms of business value

Be part of the Agile spearhead and help to make the world a better place to work in!
In exchange for your effort, you of course will receive the results of the study as soon as they are available.

The survey will only be available for a limited amount of time. Don't miss your opportunity.

Note: If you are attending the Scrum Day in Berlin this year, I suggest you fill out the survey there.

As soon as I had more than 1.000 unique visitors a day, a massive Spam attack was launched on this Blog (or maybe it was unrelated). This basically means that many many people (or robots) wrote comments to my articles. They all went into the same direction: "Great Blog ... unspecific blablabla ... fantastic something generic ... blabla ... link to an website that wants to sell you porn/viagra/some-other-stuff-you-definitely-don't-need".
Since I am not in the mood of deleting dozens of comments each day, I hardened the comment policy for this Blog: You now can only write a comment within 14 days after the post has been released. Afterwards, you will have to send me an email in order to publish your comment or to release the barrier for a restricted amount of time.

Sorry for the inconvenience!

Frederick Winslow Taylor wrote his Book "Scientific Management" back in 1911. His book is available for free online - consider reading it. Taylor wanted to end the "waste of manpower" and stated that "In the past the man has been first; in the future the system must be first." (p. 7) Taylor quickly added: "This in no sense, however, implies that great men are not needed. On the contrary, the first object of any good system must be that of developing first-class men; and under systematic management the best man rises to the top more certainly and more rapidly than ever before."

While this sounds pretty good, his own work clearly shows that he did not regard workers as more than a cog in the machinery. His basic assumption was that workers didn't put all their effort into their work. "For every individual, however, who is overworked, there are a hundred who intentionally underwork - greatly underwork - every day of their lives, and who for this reason deliberately aid in establishing those conditions which in the end inevitably result in low wages." (p. 18)
Taylor wanted to change this condition in order to increase the wealth of the United States by improving the situation for both workers and companies. His way to do this was: "to work according to scientific laws, the management must take over and perform much of the work which is now left to the men; almost every act of the workman should be preceded by one or more preparatory acts of the management which enable him to do his work better and quicker than he otherwise could." (p. 26) - Scientific Management was born. It states that managers have to "gather together all of the traditional knowledge which in the past has been possessed by the workmen and then of classifying, tabulating, and reducing this knowledge to rules, laws, and formulae which are immensely helpful to the workmen in doing their daily work." (p. 36). In addition, manager have to "develop a science for each element of a man's work, which replaces the old rule-of-thumb method", "scientifically select and then train, teach, and develop the workman, whereas in the past he chose his own work and trained himself as best he could", "heartily cooperate with the men so as to insure all of the work being done in accordance with the principle of the science which has been developed" and "there is an almost equal division of the work and the responsibility between the management and the workmen. The management take over all work for which they are better fitted than the workmen [...]." (ibid.)

What does this mean?
It means that Taylor wants the worker to stop all thinking. He considers thinking something the manager has to do. The manager is the one who should know the job of the worker in all details and to spell out how this worker should do the work. It also means that the work should be simplified and atomized to an extend "that it would be possible to train an intelligent gorilla so as to become a more efficient pig-iron handler than any man can be." (p. 40)

Of course, I don't approve. While Taylor certainly had the best intentions, he created a tool that helps to make people obsolete and worsen their working conditions. While it may have been adequate back in 1911, it certainly is not in todays economy. However, there are some successors to Scientific Management that can be useful in certain situations: Operations Management, Operations Research, Cybernetics, Total Quality Management, Six Sigma and Lean Manufacturing (maybe some more).

The first thing that is important to notice is that all tools have their use - but if you use them in the wrong context, you might hurt your goal. Ever tried to drill in a screw with a hammer? There you go.


Closely connected with Scientific Management is the phrase "resource" for employees. You maybe have seen a situation where somebody just put "some more resources" onto a project. Let's look at the term resource: "An available supply that can be drawn on when needed. Often used in the plural." (the free dictionary). It is also defined as "The total means available to a company for increasing production or profit, including plant, labor, and raw material; assets" (ibid.)
So I am a "means" to my employer. We should check what "means" means in that context: "the medium, method, or instrument used to obtain a result or achieve an end" (the free dictionary).


Now we can see the connection between the term "resource" (used for an employee) and Taylorism: Both imply that the human being is merely an "instrument used to obtain a result".


In today's world, people don't want to be just an instrument. They want to be valued for their personality, their resourcefulness (isn't it interesting how this word can also mean something tremendously positive?), their efforts and their learning. Some even want to find personal fulfillment in their work. This is especially true for well educated people in the western hemisphere, for example software developers, managers, Product Owners and Scrum Masters. So here is the 2nd thing we can learn from that: Never call your colleagues "resource"!

Yesterday I met my friend and fellow trainer Jean Pierre Berchez. We discussed some concepts from the Scrumguide. As you probably know, the principles of Scrum (like inspection and adaptation) are constantly applied on Scrum itself. That means, the Scrumguide is evolving in an iterative way. There are constantly some discussions going on, if some best practices (e.g. the DoD) should be declared "mandatory" in Scrum or if some other parts (e.g. the distinction between Sprint Planning 1 and 2) should be removed.

We discovered that the answer to those questions depends on who is asking them.

I am sure you are aware of Shuhari. It is a Japanese martial arts concept that describes different stages of learning. Shuhari roughly translates to "first learn, then detach, and finally transcend." The "shu"-state is about learning fundamentals, techniques and heuristics. Once one progresses, he/she reaches the "ha"-state, which means "detachment from the illusions of self". If one achieves mastery, he is in the "ri"-state, where "there are no techniques or proverbs, all moves are natural, becoming one with spirit alone without clinging to forms". I have previously explained this concept slightly deeper.

If we apply this concept to the Scrumguide, we quickly discover that it leads to some insights: Somebody reading the guide and being in the "Shu" state will need more guidance than somebody in the "ha" or "ri" state. So if you are just starting with Scrum, you will be very happy to find the three questions for the Daily Scrum, the distinction of Sprint Planning 1 and 2, maybe a guidance on how to do a Retrospective or even some standard items that can usually be found in a Definition of Done. Once you are in the "ha" state, you will want to get rid of the "rigid cage" that is being imposed on you by the "shu" rules. However, you will still need some unmovable boundaries to help you not to go astray (at least not too far). When you finally have reached the "ri" state, you don't need any framework at all. All you need are the values and basic principles of Scrum - everything else will come naturally to you and you will be able to taylor the framework to your needs without losing agility (which most often happens if somebody not in the "ri" state starts tayloring Scrum).

For this reasons I hereby pledge for three different versions of the Scrumguide:

1. The Shu Scrumguide should be more like a compendium, including very strict orders on what to do. It should also include best practices. It is important, however, to make transparent to the reader what are best practices and what really belongs to Scrum. Whoever reads the Shu Scrumguide should be able to set up a Scrum Team right away with clear guidance on how to do it.


2. The Ha Scrumguide should be quite similar to the current version. It should include a lot information on what to do, but no more details on how to do it. So this is basically a guide that includes the information about what is included and mandatory in Scrum. No best practices are shared here.


3. The Ri Scrumguide will be a short one-pager and only include the fundamental principles and values.

Along with their normal content, the three guides should give some hints on how the reader can self-assess his/her knowledge level in order to decide which guide is the right one for him/her. It has to be made sure that "shu" people stay with the "shu" guide, otherwise we will face a myriad of dysfunctional Scrum-But implementations. After all, apprentices always try to circumvent their masters, because learning something new is difficult and painful. However, if you don't go through this pain, you will never become a master yourself.

What do you think about this idea? Rain comments on me!

I just read Succeeding with Agile: Software Development Using Scrum (Addison-Wesley Signature), written by Mike Cohn. It was absolutely worth the money and I enjoyed the reading. However, it is - what a surprise - not a "silver bullet". Here is what I think:


The book is quite lengthy. If you want to read it from start to end, you will have to go through 444 pages. The intended audience is described as "manager, developer, coach, ScrumMaster, product owner, analyst, team lead, or project lead". While this is not completely wrong, I perceived the different chapters as very different in regard to the target audience. No matter what role you would grab for yourself, not all parts of the book will be equally relevant for you. The first part of the book is called "Getting Started" and consists of the sections Why Becoming Agile Is Hard (But Worth It), ADAPTing to Scrum, Patterns for Adopting Scrum, Iterating Toward Agility, and Your First Projects. Cohn goes into the field of organizational change here and tries to explain, how such an endeavor should be undertaken. However, I felt in reading it, that he focuses very much on the developers and clads a developer's position whenever possible. This is not bad, but might be hard to follow for a manager. In addition, Cohn creates his own model for organizational change while going with established ones (e.g. John Kotter) might have been sufficient and less confusing. This first part of the book will be especially helpful for Scrum Masters new to organizational change and people striving to become coaches. In addition, managers with a development background will benefit from it.


The second part of the book focuses on Individuals. It includes the chapters Overcoming Resistance, New Roles, Changed Roles, and Technical Practices. I liked this part of the book very much, because the roles (both Scrum and traditional ones) are described in depth. Cohn also shows attributes of "good" Scrum Masters and Product Owners, which is helpful if you want to find appropriate people to fill those roles and haven't extensive experience, yet. Of special interest for the reader are the hints about tech leads or programmers as Scrum Masters. They are worth a read for managers as well. This reading group will also benefit from the section about the changed leadership role. The last chapter focuses on technical practices (as the name implies), which marks a shift of the audience focus away from manager / Scrum Masters into the direction of developers.


Consequently, the third part of the book "Teams" deals with Team Structure, Teamwork, Leading a Self-Organizing Team, The Product Backlog, Sprints, Planning, and Quality. Those chapters are a treasure for Scrum Masters and developers. Here, the author describes in detail how Scrum works and provides some best practices as well. Basically, this part helps somebody setting up a new Scrum team to make less mistakes. Some paragraphs are interesting for Product Owners as well, but those might decide to let the Scrum Master educate them about it.


In the last Part ("The Organization"), Cohn goes into Scaling Scrum, Distributed Teams, Coexisting With Other Approaches, and Human Resources, Facilities and the PMO. Personally, I didn't like this part. In my opinion, Cohn doesn't dive deep enough into those topics. However, they will be of great value for people starting with Scrum and Scrum Masters who haven't done that several times already. In any case, it is worth to take a look at those chapters.


Finally, Cohn gives a brief look into the "Next Steps" where he tries to cover metrics and agility assessments. Well, don't expect too much from that - I wasn't impressed at all. It is not more than a brief glance at the wide field of metrics. Again, this will be helpful for Scrum Masters trying to get an overview or starting with that topic.


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. If that is okay with you, go for it!

Just recently, my first book Scrum - Einführung in der Unternehmenspraxis: Von starren Strukturen zu agilen Kulturen was published (it's only available in German so far). I decided to share some of the experience I gathered in the course of that endeavor. Please be aware, that those are just my personal insights; you might face different issues and different learnings when going for your next publication. You should also note that I am only talking about Germany - other countries might be different.



Before we dive into details, let's say that publishing a book is not exactly easy. I mean, it's up to you if you can write a book, but it's completely up to others, if you will manage to publish one. Of course, you could use a print-on-demand supplier or just put it on infoq, but this is not what I am talking about. I am talking about renowned publishers like Springer, Wiley, Jossey Bass - you name them. In my case, it took more time to get published than to write the book. Here is why:


Before I started, I decided that I wanted to publish my book with a well-known publisher. In my opinion, it means less money but greater respect. I made my first mistake shortly after, just before I really started the project (oh yes: writing a book is a project, and a large one at that): I decided to write the book before contacting publishers. What I know now is, that some (not all!) publishers prefer to get a well-designed abstract and discuss it with the author. That way, they have greater influence. Well, I assumed that editors (those are the people who read your work, sometimes help you adjust it, and decide if it's published) didn't have deep knowledge about Scrum. Especially not about changing organizations with/towards Scrum. So how should an editor be able to judge my abstract? On top of that, I had never written a book before. I didn't know if I was able to and how long it would take. In addition, I am not a "guru" person like Ken or Jeff. So people wouldn't buy my stuff because of the author's name. Which again is difficult, if you want to partner with a publisher. After all, they want to earn money with what you write - a good name certainly helps. Why should they waste time with a less-known person?

So I wrote the book. This took quite some time (I estimate the effort to approx. 500 hours). Once I was 95% done, I decided to contact a publisher. What you usually do is to send them an exposé. That is a summary of your book with important information for the publisher. Many publishers have their own format and templates for that - you are well advised to use them. I discovered that I had to do a great deal of market research and self-marketing in order to fill in those forms. The reason for me to write the book was to get a short and easy to understand "bible" of how to transform an organization to Scrum. I didn't know of such a publication, so I wrote it myself. However, I had not conducted a full market research. Of course I read a lot - but I don't know every book out there! This gap had to be closed, so I lost several weeks reading books of other people (and I still didn't read all relevant books). Once I had a good enough market evaluation, I sent my exposé to the first publisher and - waited. Waited some more. And even more. After six weeks, I got a reaction: "This looks interesting, send us the manuscript." Darn - six weeks are an awful lot of time for an agile practitioner like me. But what could I do? So I waited. After another six weeks, they told me that they needed just a little more time. Four weeks later (hooray, the Sprint length was reduced!) they told me, that this topic would not fit their program. At this point in time, I had already waited three months to get a simple "no" - this was frustrating. So I went to the second publisher on my list, who immediately (after three weeks) declined the offer. Number three was more like a dejavu: Three months total waiting time to get a response. Somewhere during the waiting for that publisher, I was furious and changed my approach: I contacted four publishers at the same time. Two of them personally (one at a conference, one with an appointment after they had signaled basic interest). While this finally led to success (two publishers were honestly interested), it led to some conflict as well: A third publisher signaled interest and even arranged for a place in their books lineup, which I had to decline because I already had agreed on the offer of another publisher. I learned the hard way that it is not common in the publishers' branch to contact several publishers at once. I certainly feel sympathetic with the disappointed editor - but what could I do?

One of the other two highly interested publishers took quite some time and asked a number of Scrum people to review my manuscript. After three months without much communication from the publisher's side, I told them that I would not proceed with them. 11 hours later (this is like the speed of light for this branch) I received a friendly email, phrasing joy that I found a publisher (but not trying to change my mind) and sharing the comments from the Scrum reviewers with me. I then understood, why they had been so silent: The reviews were mediocre. Praising style and some ideas, smashing other details. Before contacting any publisher, I of course had asked several professionals to review my work - and it had improved the quality quite a bit. However, those "other" reviewers had verbally ripped some parts of the manuscript to shreds. On a second glance I noticed that they had not read it completely (none of them!). One demonstrated clearly a lack of Scrum knowledge in his/her answer - but dared to provide a bad review anyway. On top of that, some important information - like the target audience - had not been distributed to them. The main content-related feedback point was about missing pictures (I had none in there - it was the 95% version) and missing depth for the target audience (which was not known to them). From those reviews I got the impression of a development team delivering too fast at the end of a release - incomplete, unsatisfying quality and low motivation. Of course some useful thoughts were in those reviews and I adapted the script accordingly. The names of the reviewers are not known to me, so I could not get back to them and discuss their thoughts in detail. This made me fully understand Dean Leffingwell's remark: "Writing a book is the least agile thing you can possibly imagine!" - Bad communication, huge feedback cycles, a gigantic batch size (there is just one batch with everything in there), hardly any chance for inspection and adaptation, no transparency. If by any chance you were one of the reviewers of my manuscript, please get in touch with me. I would be happy to discuss your thoughts and learn for my next book project!

Another notable experience concerns the quality you have to deliver as an author. When I started I had the idea that I would write some 80% version and then would work together with my editor to make it perfect. I was mistaken. You have to provide the 100%, including the elimination of all typos. Even the pictures have to be provided by you (but they will be recreated by the publisher). Only one editor actually made recommendations to me how to improve the book. Those were good, but too late: I already had spotted and corrected those taints myself.


When the contract was finally signed, I had to fill in a couple of forms again (I love administrivia). The publisher took care of the rest and I only had to double-check the final version going into print. The whole process speeded up a lot and I got my first copies a day before Christmas, two months earlier than anticipated. That's where we are now today: 11 months after I finished the 95%-version of my book, three weeks after I received the first copies of my book, one week after Amazon started delivering orders.


As always, I am happy to discuss your thoughts with you. Just post a comment here or drop me an email. Let me know once you have read the book - I yearn for your feedback!