Category Archives: English

Posts in english

Next CSM Training in English | 22+23. Juni at Lipno Lake, CZ

faciliteitenLakeside view – this will be an idyllic place for a training!
To support the young Czech Scrum Community there will be a Certified ScrumMaster Training to a very affordable price at Lipno Lake (~1h from Linz in Austria) in the Czech Republic. Because the location is a Holiday Resort, accomodation is included in the overall price of €900 excl. VAT. We hope to meet you there! Register here >>


Kanban or Scrum? – First Generation Agile Methods

I found again some very interesting wrong interpretations about how Scrum works.

Kenji Hiranabe and I discussed this point over a year ago before his second Kanban articlefor InfoQ. I argued and I believe Kenji concurred that Agile methods like Scrum are really small batch transfer push processes. There is no explicit pull system within a Sprint and it’s a stretch to suggest that the batch transfer at the beginning of a Sprint – the selection of the backlog – is a truly “pull” process. It is never described this way. It is described as a negotiation where the team estimate a set of stories that the product owner wants done. They compare the estimate with the previously achieved velocity and decide what can be fitted into the available time in the Sprint. If it were truly a pull system then there wouldn’t be any negotiation. The product owner would have a prioritized backlog and the team would simply pull the top (however many) stories from it and start work. (more …)

I do not want to argue about, if Scrum is a pull system or not – because everybody who does Scrum correctly knows it is a pure pull system and if you understand to what every Scrum teams evolves it practices than you will see that there is absolutely no difference between Kanban ideas and what Scrum does. The real point is:

They are both on different levels. Henrik Kniberg, has written an excellent article about Scrum and Kanban and does a really interesting mistake in this article:

Scrum and Kanban are both process tools

Tool means “anything used as a means of accomplishing a task or purpose” ( Process means how you work. Scrum and Kanban are process tools in that they help you work more effectively by telling you what to do. Java is a tool, it gives you a simpler way to programming a computer. A toothbrush is a also a tool, it helps you reach your teeth so you could clean them. (Henrik Kniberg, Kanban vs Scrum -A practical guide)

Although Ken always refer Scrum as a framework:

Scrum is a framework for developing complex products and systems. It is grounded in empirical process control theory*. Scrum employs an iterative, incremental approach to optimize predictability and control risk. Within each iteration, Scrum employs self-organizing, crossfunctional Teams to optimize flexibility and productivity (Scrum Guide, Scrum Alliance)

Scrum is much more than a tool. And Scrum is definitely not “only” a tool. Scrum is a mindset, in the same sense as the Toyota Production System was always a mindset a philosophy and not only a tool:

What is the secret of Toyota’s success? The incredible consistency of Toyota’s performance is direct result of operational excellence. Toyota has turned operational excellence into a strategic weapon. This operational excellence is based in part in tools and quality improvement methods made famous by Toyota in the manufacturing world, such as just-in-time, kaizen, one-piece flow, jidoka, and jeijunka. These techniques helped spawn the “lean manufacturing” revolution. But tools and techniques are no secret weapon for transforming a business. Toyota’s continued success at  implementing these tools stems from a deeper business philosophy based on its understanding of people and human motivation. Its success is ultimately based on its ability to cultivate leadership, teams, and culture, to devise strategy, to build supplier relationships, and to maintain a learning organization. (The Toyota Way, Liker, p. 6)

You can translate / rewrite this whole paragraph for Scrum:

What is the secret of Scrum enforcing companies. …. This operational excellence is based in part in tools and quality improvements made famous by the agile software development movement: test driven development, continuous integration, pair programming, one-story-at the time, the task board …. the continuous success steems from a deeper business philosophy that is embedded in Scrum: we value transparency, honesty and  courage and we believe in people are adults, they can make decisions, they want to achieve things and  a lot of more things.

People who want to see Scrum as a tool, do not see that all these tool thinking leads again and again back to the idea that Scrum is a silver bullet or a methodology or a process tool. It is NOT!

The second thought I want to make clear here:

Scrum like all early (first generation) Agile methods really do not change the project management paradigm very much. They still use projects as the frame of reference and still have the triple-constraint (iron triangle) of scope-schedule-resources as an underpinning. (more …)

That is wonderful: The whole idea is incredible: Scrum is a first generation agile method! That is b….t

Scrum is now the de facto agile software development standard as it has evolved from the idea from managing a project to managing whole enterprises using Scrum. Scrum always talked about value adding, Scrum brought the whole flow idea into the agile community. Lean is a subset of all this – as we learn in Likers, Toyota Way that Lean is only a subset of the Toyota Way.

So comparing Scrum with Lean is nonsense as Scrum is lean by definition.

To enhance practices of people that try to develop software within Scrum by using some more clever ideas how to use a taskboard (btw, it was invented by the XP people and then transformed in the de facto work standard by Tobias Mayer and me) for Scrum teams are fully embraced by all Scrum people.

Because — Scrum teams use what works to make them more successful. They want to become truly knowledge based teams using all ideas about how to establish a the learning organization (Senge).

When Should a Process Be Art, Not Science – Review

“The movement to standardize processes has gone overboard. Some require an artist´s judgment — and should be managed accordingly.” Joseph M. Hall and M. Eric Johnson.

Two well known teachers wrote an article in the Harvard Business Review that I want to bring to your attention: When Should a Process Be Art, Not Science by Hall and Johnson.

There are some processes that naturally resist definition and standardization—that are more art than science. Helping executives understand which should not be standardized and how to manage artistic and scientific processes in tandem is the purpose of this article.

Scrum was designed to “control chaos” and to establish a way of working in a high demanding, chaotic environment: Software Development.

As I always try to explain: Scrum can be used in any environment that needs a huge amount of judgment in which you need to adapt to new aspects with very high frequency: Software Development, Marketing management, Campaign Management, Business Development, Sales, Customer Service, System Administration and and and …(Side note: That is the reason why Kanban is not the right tool for this – Lean management needs stable environments.)

The two professors see a need for an empirical control processes in most business environments, too.

They call these processes artistic processes. A different name, but the same idea.

What they also say, and this is one of my claims since years.

“Not only does standardization reduce accountability, but it causes workers to switch to autopilot.”

When you have a work standardized and two high skilled worker on this process.Then it will happen that you bore your people to death. They will go on autopilot, they do not think anymore. They only do their work.

“An artistic process has to rely on external measures of success, like customer feedback.”

“Many Processes Are an Art:

  • Leadership Training
  • Auditing
  • Customer Service
  • Software Development”

The two profs give us an advice how to bring people to the level that they can live with artistic processes:

„If a process is artistic, invest in giving employees the skills, judgment, and cultural appreciation to excel in variable conditions.“

So basically what they say is, that you need to train your people again and again, that you must enable them to improve themselves.

But how do I get the right process for my situation?

The three steps to run the right process in you company:

  1. Identify what should and shouldn`t be art.
  2. Develop and infrastructure to support art.
  3. Creating appropriate metrics: Feedback
  4. Periodically reevaluate the division between art and science.

Getting art and science work together

    F.e. Support process that can be standardized.

      Building an effective training program

        Artist must learn their skills of trade. They often have to undergo a formal apprenticeship of informal mentoring and probationary period during which their freedom is curtailed.

        • Tolerating failure: The variations that are the hallmark of artistic processes make it impossible to satisfy every customer on the first try.
        • ScrumMaster and Domainleads – our solution for large organizations

          A wonderful article about organization of a department or company using a matrix organization I found here:


          Optimize Communication, Throw the Boss Out

          Yoda-metrojp-85740389 It is well-known that difficult goals are best achieved when people work in small teams of under ten people. Various agile methods were created based on this principle. Communication in teams is optimal when the lines are short. But that doesn’t tell you how to structure an organization with hundreds or thousands of people. The solution of simply dividing them into many small teams is clearly insufficient. How do all these teams fit into a bigger picture?

          I strongly recommend to read the whole article. —————–

          More about my solution to this you will find tomorrow …

          Software Delivery at the Next Level: Continous Deployment

          You do continous integration – but every release is still a big THING. You fear it, you sit there and you hope it will work. In case you are in this situation, you are obviously behind the next development in our industry. A friend reommended a posting to me that I liked so much, I must put it here again:

          So what should Alex do? Continuously deploy. Every commit should be instantly deployed to production. Let’s walk through her story again, assuming she had such an ideal implementation of Continuous Deployment.
          Alex commits. Minutes later warnings go off that the cluster is no longer healthy. The failure is easily correlated to Alex’s change and her change is reverted. Alex spends minimal time debugging, finding the now obvious typo with ease. Her changes still caused a failure cascade, but the downtime was minimal. (found at T. Fitz Blog)
          When he posted this, what happend, people do not believed him, so his next blog posting is even cooler:

          Continuous Deployment isn’t just an abstract theory. At IMVU it’s a core part of our culture to ship. It’s also not a new technique here, we’ve been practicing continuous deployment for years; far longer than I’ve been a member of this startup.

          It’s important to note that system I’m about to explain evolved organically in response to new demands on the system and in response to post-mortems of failures. Nobody gets here overnight, but every step along the way has made us better developers. (Fitz)

          So – teams who are not able to do this — you are too slow and not professional anymore.

          Great test coverage is not enough. Continuous Deployment requires much more than that. Continuous Deployment means running all your tests, all the time.

          Well, and there are teams who do not even do tests. And if you do not believe Tim:

          The point is that Continuous Deployment is real. It works and it scales up to large clusters, large development teams and extremely agile environments.

          My message to all Teams that are not doing Unit Testing, Automated Integration Testing, Continuous Integration and Deployment: “Start to work in this … hard, harder. Do more. If this is possible than you MUST do it also.

          My message to Customers: When this is possible than demand it from your teams also.

          You want to find a new product – start to play seriously

          “I did not hire the 26 year old game designer, who was fresh from university, I hired the 16 year old boy who was still in school as our new game designer. He still has new fresh and completely different ideas.”A well know person in the German video game industry told me this a couple of month ago. I was puzzled! What – a 16 year old is of value for a multi-million Euro product?

          Then I had another of this flashes. We talked to a CTO of a big social network and he told me that he works now with people from school because these pupils (around 14 to 16) have super cool ideas for their platform.

          WHAT THE HELL IS GOING ON! Are we cool Baby Boomers, Generation X people,  or “Generation Umhängetasche” not able to create new ideas and new new products? Are we guilty in terms of having giving up our creativity for the security of having money and being safe?

          Why is the answer to this question so important right now? Because we need new ideas! Everywhere … not only our ecosystem problems forces us to do this, no — we need new ideas to give fresh and insightful impulse for our life and business. And this is a problem for all of us. If we want to stay successful in our business, we want to have an interesting and successful life. So — if we baby boomers wants to keep our security, our life style, we need new ideas…..

          Oh, now you will say, and now Boris will tell about that Scrum will be the rescue. No! What I want to show you are a very important talk given by Paula Scher.

          As an artist she is known for her large-scale paintings of maps, covered with dense hand-painted labelling and information. She was involved in the planning of a new multi-use “urban center” in the Mount Vernon Square neighborhood of Washington D.C., and teaches at the School of Visual Arts in New York. (wikipedia)

          She has given an incredible good talk at TED. That I want to share with you:

          She shows us a way to go out of the zone of having new ideas. Do something that you do NOT know. Get out of your comfort zone.

          3 Secrets of a good ScrumMaster

          A good ScrumMaster has to know and execute 3 secrets I believe:

          * He/She clarifies his role and confirms this mandatejolegat-gloger-scrum-master

          1. Ensure that you are able to execute your role
          2. Get the allowance to be the teams ScrumMaster from the team
          3. Work with your management to make your role clear and build standing

          * He/She builds a very good relationship with everybody on his team

          1. Work on knowing your team members quite well
          2. Help them to become stonger and stronger
          3. Work  on a clear understanding what everybody want to achieve as a team member

          * He/She inspires people

          1. By caring for people
          2. By caring about the relationship with these people
          3. By try to help the people to become better than they ever cold