Category Archives: agile

Prioritize and Say No Properly – A First-Hand Report

In one of our last articles, we went into more detail about the success story of our service team. Today, we’d like to give you some insights into some of the team’s learnings: With growing task areas, the team had to learn what it means to prioritize and say no.

In addition to the daily work, the team had all kinds of other tasks to take care of. Plus, there were requests from employees and customers – tasks and requests that could not be scheduled in this way. The sheer volume of these unplannable things soon meant that the team could not keep up with the daily work.

Continue reading Prioritize and Say No Properly – A First-Hand Report

Manual for Setting up Kanban

E-T-A has been using lean in production for years – and is expanding its capabilities with agility. As part of our joint work in agile transformation, E-T-A and wibas colleagues meet to work together on establishing agile techniques and agile thinking. Yesterday Stefanie and Katja from E-T-A sat together with three wibas colleagues Rafael, Daniel and Malte. Our question was: „How do we set up work with the Kanban Framework in a team?“ For this purpose we developed a guide which we share with you here. This is our System Thinking Approach to Introducing Kanban (STATIK).

The result: more than a board

When we tried to pin down the objectives of the workshop (how you do it as a good moderator) we quickly realized that it is not just about a board with cards, but about implementing the Kanban Framework.

Why is Kanban more than just a ­board with colorful stickers on it? Because Kanban defines principles, roles and meetings that make Kanban the useful method. So the following is a guide how to start using the Kanban framework in a team – and not just the board.

In the spirit of the principles “Evolutionary Change” and “Start with what you do now”, our workshop is not about implementing Kanban in its full beauty, but about starting. So it may be that we leave out some things from the Kanban framework at the beginning (a “Proto-Kanban”).

Who’s coming?

We invite the team that does the work to the workshop. We come as Flow Master, i.e. as an Agility Coach who understands Kanban and facilitation. As Flow Master we support moderately and bring in techniques such as board design. Or in short: As Flow Master we moderate, the team designs its Kanban.

Kanban lives from the people who use it.

The steps in the workshop

Our basic idea of the workshop is: First the team understands the value stream with its rules and limits. Then the team visualizes the value stream with a board. Finally it establishes the roles and events. Susanne, Agile Coach at E-T-A, knows why we let the Team do the work: „If the Agile Coach develops or even maintains the board, the team does not work with it.“ We coaches nod. „Sure, it’ll be your board, not the team’s.“

Here are the steps of our moderation plan:

  1. We ask the workshop participants about their experience with Kanban. The query helps us as moderators to understand how many explanations we have to include on the way. Our motto is: we explain stuff when it is needed. This saves us a big Kanban explanation at the beginning.
  2. We let the team describe the value that it delivers to the customer through their work. This understanding is important so that we can align the process with this value.
  3. We let the team write some typical customer requests. This helps us to better understand what the customers want. We also have a few examples for service requests so that we can try out Kanban in a later step (see #9).
  4. The team does a brief review of its work with two questions: What is going well? Where does the team see room for improvement? This gives everyone a feeling for „where we start“.
  5. We let the team identify the flow of work. To do this, we go with the team through the process step by step and let the team model its workflow. We use sticky notes for this purpose, where each note represents a step in the process. In this way, the workflow is created dynamically and can be easily extended and modified.

As coaches we support the team with questions such as:

  • What are the steps you do as a job?
  • What is the result of the step?
  • Where does the work come from?
  • What kind of work is that?
  • What makes a good process?
  • How does the implementation of work happen with you?
  • How do you choose work?
  1. Based on the above workflow, the team creates its first board. For this we first clarify whether the workflow is always the same or whether the tasks are completely different. If the tasks are always the same, each work step is represented as a column in the Kanban (each column has the sub-columns “in process” and “finished”). For very different activities we design a board with an individual decomposition of the work into tasks.

Examples for Kanban Board Desings.

  1. We let the team determine the limits of parallel work – these are the so-called “work-in-progress limits” or “WIP limits”. By limiting the amount of parallel work, we eliminate waiting times and shorten lead time. We become more efficient. For good WIP limits, it is important that the team starts with initial limits, observes lead times as the work progresses, and then adjusts the WIP limits so that the work does not jam at any point.
  2. We let the team formulate its policies in the course of work. We ask for this:
    1. What does it mean when a step is done? Are there criteria for this? This becomes something like a „definition of done“ for the respective „done“ columns (or possibly only for the last done column).
    2. We ask the team how they select their work from the queue (the first column in the Kanban). Are there policies for this? How is the queue ordered? The results at this point are typically policies for ordering or prioritizing the customer requests.
    3. Are there other policies that are important at work?

The team writes these policies on large Post-Its (we often take A5) and hangs them above the board. Policies for defining „done“ make sense e.g. above the respective „done“ column.

  1. We test the Kanban Board with typical requests from step three. That means: we run a customer request „through the board“ and simulate the work for it. If necessary, we adapt the board.
  2. If we have time, we can include a simulation of Kanban at this point, so that the participants learn how Kanban works. For example, we could use the Okaloha Flow Game or the TWIG Game. Such a simulation helps to give the team an understanding of Kanban that would otherwise need some cycles in real life.
  3. We clarify with the team the roles of the Kanban framework (Flow Master and Service Request Manager/Product Owner) and we determine who will take over these tasks. At least for the near future.
  4. We clarify with the team what the cadences of the feedback loops are. By “cadence” we mean: how often do we do which meeting. We find the Kanban Meeting (“Standup”) and the Service Delivery Review particularly important. Actually, the Replenishment Meeting and the Delivery Planning Meeting are also important, but we can also introduce these in a later step. For all meetings we determine when and how often it takes place (and of course: who comes and how long it takes).
  5. The team loads the board with the current status of work.
  6. We ask what else the team needs to get started.

That agenda itself we *of course* have on a Kanban board. On the one hand, because we want to set an example of Kanban, but also because the agenda changes during the day and we can react.

For such a workshop we need at least four hours – a whole day would be better.

We lied. That wasn’t a manual.

We have briefly outlined how to set up Kanban with a team. Of course, this is only a small part of the truth. We cover the details of setting up Kanban in our official training KMP I. There you will learn the exact process of Kanban, the principles in detail, facilitation techniques and board design variations.

Team of authors

The team of authors: Stefanie Stampfer and Katja Kiel from E-T-A with the three wibas colleagues Rafael Kasprzak, Daniel Schauperl and Malte Foegen. If you still have questions, ask them here in the blog – we will be happy to answer them. Or call us: 06151 – 50 33 49 0.

Descaling instead of scaling: Why scaled agility should simplify the organization.

 

Quo vadis agile scaling?


More cheese, more holes

More holes, less cheese
More cheese, less cheese

Is this paradox cheese? Possibly. And is it transferable to the organization of organizations? It is possible.
One thing is certain: to achieve more with less in terms of organisation is not such a far-fetched idea at the latest on second thought. Especially when it comes to scaled agile frameworks, this idea is just too contrary. Continue reading Descaling instead of scaling: Why scaled agility should simplify the organization.

How do you “scale” agility? An interview with Malte Foegen.

How do you decide which agile approaches to take out of the agile toolbox when it comes to creating an agile organization?

I look at every team and every level for itself. This is the only way to find out which agile approach makes sense for which team and at which level.

And you can’t just take a Scaled Agile framework like that? Continue reading How do you “scale” agility? An interview with Malte Foegen.

Agile Myths: User Stories – a mandatory format for Scrum Teams?!?

The User Story format is often used by Scrum teams to document requirements. It’s a short syntax that sounds totally simple, but when we sit down and try to fill this syntax with life, we quickly realize that it’s not that easy. Some of you may have stumbled across user stories that somehow sound “artificial”. So what is it about this little sentence? Why do so many people use it? And do Scrum Teams have to document requirements in the user story format? Don’t they otherwise make a “real” Scrum? Continue reading Agile Myths: User Stories – a mandatory format for Scrum Teams?!?

Agile Myths: Agile Solves all my Problems

 Agility – the solution to all problems: We no longer run over project time and budget, our clients are always satisfied with the results of our work and we work fulfilled and motivated. Agile methods are often seen as a way to achieve such results. But does such a miracle cure even exist? One thing is for sure, there is a market for this demand as well.

Agile Culture

Agility provides one thing above all, a culture with values and principles that can change a company from the ground up if you get involved in it.

Continue reading Agile Myths: Agile Solves all my Problems

Agile myth: Writing user stories is Product Owner work

Again and again I am confronted with the statement that only the product owner writes and prioritizes user stories. The Product Owner is the person who prioritizes the Product Backlog. But for reasons I don’t understand, many people seem to be convinced that it is a core task of the product owner to sit down at his desk and write a user story until it is ready for a sprint. Is that really what the Scrum Guide says? Continue reading Agile myth: Writing user stories is Product Owner work

What is agility, anyway?

Time and again, customers ask us what is actually “agility”. Malte Foegen describes the term “agility” very aptly in one sentence:

“Agility is fast responsiveness in a complex world.”

Often, this still leaves questions unanswered. Examples are: Isn’t that the same as flexible? Adhoc? Does it have anything to do with the fact that we, as a modern employer, offer home office? And let’s be honest: How does all this fit in with responsiveness and fast regular deliveries?

Reason enough to get to the bottom of the meaning of the term!

The term “agility” as we know it today first appeared in 2001: 17 people spent three days in a ski lodge in Utah and defined in the “Agile Manifesto” how they envisioned the development of software. The result is the Agile Manifesto and twelve principles. The Agile Manifesto still exists today in its original form; at wibas, we now summarize the twelve principles into five. In addition, different agile frameworks bring their own values or principles. Kanban, for example, which can be combined very well with agile working, is also directly oriented to the lean principles; with Scrum, we also talk about the Scrum values:

Agile is therefore someone who aligns his actions as best as possible with the values and principles of agile methods.

What does the agile manifesto got to do with Scrum?

If you look at the context chronologically, the obvious answer is “nothing”. After all, the “Scrum” framework is six years older than the Agile Manifesto. But: The inventors of Scrum, Ken Schwaber and Jeff Sutherland, belong to the circle of 17 representatives of different development frameworks, who were present in said lodge in Utah; they have co-created the term “agile” on the basis of their invention Scrum; Scrum is therefore one of the frameworks, which is based on the Agile Manifesto, the values and principles – but probably not the only one.

In addition to Scrum, there are also other frameworks such as Design Thinking, which are based on agile values and principles. Even if there are differences within the frameworks, they use a common toolbox of (interchangeable) agile techniques, such as Pair Programming (Pair Working) or Continuous Deployment. To understand what agile means we need to keep in mind a golden rule: Agile starts with values, not with the implementation of a technique. It may seem scary, but the fact that I use Pair Working does not make me agile! The goal I pursue with it and the attitude makes me agile!

So much for the theory – but what’s behind it?

The big breakthrough of agile methods took place in software development. In other words, in an industry that traditionally works on a project basis. If we think of complex software products, it quickly becomes clear that the development time can easily take longer than a year. A lot of time, considering how quickly the industry and its business environment have changed in recent years. Of course, we want the software we develop today not to be obsolete by the time it is released. Today, we set ourselves the goal of developing a product that, when it is ready, will be state of the art. A laudable goal. However, today we have no idea in which direction the technology for implementation or the interest of our target group will evolve. Under these circumstances, it has been possible to build successful products in recent years by using agile frameworks.

Following the success of software developing companies, more and more companies in the areas of hardware and organizational development are also relying on agile frameworks and techniques.

What do agile companies do differently in their daily work?

While classically operating companies try to describe the target state of the product at the beginning of the project term, agile companies have invested their energy in the past years to remain responsive to ongoing changes. In doing so, they invest in degrees of freedom for the future. This primarily requires short development cycles and equally short coordination intervals with customers. These, in turn, require a close and open customer relationship that allows appropriate exchange and, if necessary, supporting conditions (e.g., suitable infrastructure for meetings and exchange), as well as the use of modern development techniques such as “continuous deployment” (software development) or “rapid prototyping” (hardware development). As a result, agile companies can constantly take customer feedback into account in planning, i.e. react flexibly.

That sounds a somewhat situationally elastic.

Of course, agile companies also have a clear direction and communicate it. However, we are talking here about a vision or a target corridor, not a target described down to the last detail.

However, there is still a significant difference between agile and situationally elastic: Agile frameworks (only) allow flexible changes within a clearly defined set of rules. At the same time, they also help to reflect on goals along the way and to adjust them if necessary.

…that may be the case in the software industry, BUT…

The speed of adaptation of customers and technical development on the market are faster in the software industry than in any other traditional industry or service sector. Nevertheless, even away from software development, companies today are forced to adapt quickly to the market in order to succeed in competitive situations. Industry and service organizations have therefore demonstrated how agile principles, frameworks and techniques have helped improve products and services in other areas. For example, our customers also rely on our experience in agile methods when building vehicle modules or improving customer services.

In their book “Organization in a Digital Age,” Malte Foegen and Christian Kaczmarek provide insights into practices that have proven successful in this regard.

Then everything is settled, isn’t it?

Theoretically, yes. Which is a good first step. In practice, however, there is a big difference between applying a technique, i.e. “we can deploy continuously” and “we have managed as a company to adapt to customer and market needs in an agile way.”

But that is a goal, we could call it a vision, that should be achieved in an agile way rather than a situation-elastic way. If you consider this vision worth striving for and would like to take the first step in this direction as a company, why not attend our agility workshop?