How can I rent a 50 foot yacht (or get a job as a scrum master) if I have no experience? You shouldn’t!

Recently, a successful speaker and trainer –whom I also happen to know personally– posted a (German) article on linkedIn, where he “replied” to the many questions he got on “How do I find a job as a Scrum Master if I have no experience?”

He actually did give suggestions. And that is what really made me sad, because the question alone already highlights much of what's wrong in today's post-agile world.

In my opinion the only right answer would have been: "You shouldn't!”

To me, the whole "How can I get a job as a scrum master if I don't have any scrum master experience yet? It's so unfair that they all expect me to have experience." is fundamentally the wrong question to ask.
It is like asking “How can I rent a sailing yacht if I don't have any sailing experience yet? It's so unfair that they all expect me to have experience. How should I ever get the experience if they don’t let me try it out?” or maybe even "How do I get a job as a surgeon if I don't have any experience?"

There are many jobs for which you do need experience.

Let's look at what a master used to be:

In most areas (university excluded) you become a master after you've been an apprentice (usually for three years) and after completing your journeyperson’s time (in Germany usually also three years). After that, you have to pass an examination and deliver a so–called masterpiece.

In the agile realm people can become a “Master” (at least a Scrum Master) after a two-day training course.

The people who defined Scrum (around 1995) were part of the group that wrote the Manifesto for Agile Software Development, so it's safe to assume that they also co-created the first page that starts with "We are uncovering better ways of developing software by doing it and helping others do it.” If one believes that sentence, how much sense does it make to have people who don’t have any actual experience doing it train and coach other people in things they never experienced themselves?

If you look at the original idea of a Scrum Master you will find that the Scrum Master is –to pick just a few items– meant to

• [be …] accountable for establishing Scrum
• help[ing] everyone understand Scrum theory and practice, both within the Scrum Team and the organization.
• enabling the Scrum Team to improve its practices, within the Scrum framework
• [be] leading, training, and coaching the organization in its Scrum adoption
• for more: see the current version of the scrum guide

All of these things are pretty hard to do if you only know them from theory. For similar reasons maritime law makes sure that even though the first journey of a skipper is their first journey as a skipper, it is by far not their first journey in an active role on a ship. In the same vein, new Scrum Masters really ought to have experienced the environment from numerous roles to fulfill the expectations laid out in the framework.

To quote one of the original books on Scrum by Ken Schwaber (Used to be required reading for getting the Scrum Master certification in the olden days):

The Team Leader, Project Leader, or Project Manager often assume the Scrum Master role. Scrum provides this person with a structure to effectively carry out Scrum’s new way of building systems. If it is likely that many impediments will have to be initially removed, this position may need to be filled by a senior manager or Scrum consultant. Schwaber2001, p. 32

On the other hand, especially that innocous “enabling the Scrum Team to improve its practices” from the bullet-list above implies (according to most, but not all, certified scrum trainers (CSTs) I know) all the stuff from the technical side of agile as well.

So please, if we want to achieve the goals we had in the early 2000s, when “lightweight processes” –as they were called before 2001— became “Agile Software Development”, then let’s stop with dishing out the idea that the person who is intended to help people get better at the game, can learn what to do in a couple of days and “on the job.” Let’s be realistic and tell people that they should go through the path of apprentice and journeyperson themselves before they start acting in roles that are designed to be held by experienced people.

Because of all of this, in my opinion, the best answer to the original question “How do I find a job as a Scrum Master if I have no experience?” should have been “You shouldn't.” Amended with the suggestion of better questions to ask.

To me one better question would be: “How can I get the experience that is necessary to be an effective and useful scrum master?” (From my point of view, working as a developer, tester, subject matter expert or maybe even as an intern in an environment that actually has a working(!) Scrum setup are some good ways to get experience.)

In my experience, the (few) people who ask this latter question and try to get that experience usually don't have any problem with job offers – except that they might get too many. After they did get the experience…

till next time
  Michael Mahlberg

Know thy commitment! (In Scrum or in Flow)

I wrote about commitments and commitment points earlier – this is a condensed version focusing on the distinction.

Commitment in Scrum (as part of the planning) was about the promise of a group of people.
(Caveat: The term is not in the Scrum guide in this way anymore)

Commitment in Flow is about the status of a work item.

In flow-based systems, “committed” for a work item means that this work item is being worked on now.

The work item is meant to be neither idling nor pulled back from the workflow until it is released (to the customer to whom it is meant to be of value).

In Scrum, “committed” for a team meant that the team strives to achieve a goal by all means necessary.

The team was meant to work towards this goal and deliver something that enabled the negotiated customer capability.

“Just” a distinction to be aware of in discussions about commitment...

till next time
  Michael Mahlberg

The official way to define a sprint goal...

... doesn’t exist of course.

But please:

“We'll do stories 5712, 3211, 7621 and 3123” has never been a sensible commitment. That’s not why we have sprint goals.

The Scrum Guide states “The Sprint Goal gives the Development Team some flexibility [...]” and “The Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives.”

So, if you ask me

“At the end of this iteration department Y will be able to sell product X via channel C” sounds much more like a useful sprint goal. And much more in alignment with the original ideas of Scrum.

IMHO, one of the most important things about the sprint goal is that little word ‘coherence’ - a clear sprint goal helps in setting priorities, aligning team efforts, and communicating with stakeholders.

Therefore, I suggest to use more than a collection of stories to define the sprint goal.

till next time
  Michael Mahlberg

P.S.: Using numbers to drive a business is considered harmful by many people – to quote W. Edwards Deming Quotes

People with targets and jobs dependent upon meeting them will probably meet the targets - even if they have to destroy the enterprise to do it.

Perhaps sprint goals made up of (story) numbers are also a bad idea.

What is a commitment anyway?

Or: The difference between “having committed to something” and “being committed to something.”

This is not about the old story of the chicken and the pig who want to open a restaurant. Even though Ken Schwaber used this adage to illustrate the difference between commitment and involvement in the early days of Scrum, it is no longer part of the canon.

The version history of the scrum guide makes that quite explicit:

“Development Teams do not commit to completing the work planned during a Sprint Planning Meeting. The Development Team creates a forecast of work it believes will be done, but that forecast will change as more becomes known throughout the Sprint.”

Still I see the term “commitment of the team” quite often. In publications and in ‘real life.’

I have to confess, I am even guilty of using it myself from time to time.

Like with many things in the world, the question is how we use them. In this case it is the question of how we use the term – and the concept – commitment?

There is a fine line, but a very important distinction in who does the committing. A while back I heard some General in a movie say that he “committed 20 troops” to some task. In yet another movie a team member explained the success of his team with the fact that “the whole team was committed to the cause.” So does that mean that the 20 people the General committed to the task will feel commitment to the task and thus succeed? Probably not.

And yet the statement “The team is committed to the sprint goal” is syntactically the same wether the team has committed to the sprint goal (e.g. each team member bought into it) or has been committed to the sprint goal (e.g. some higher authority spoke on behalf of the team without their consent).

till next time
  Michael Mahlberg

P.S.: But then again you might want to consider exchanging iteration based approaches with a flow-based concept and cadences and then you might consider “Department Y will be able to sell product X via channel C” as an idea for a MMF (Minimum Marketable Feature(set))

This is not an Epic

This is a rant...

In a “recent” post Mike Cohn outlines some of the misunderstandings around the the terms «epic», «user story» and «theme».

This article is actually only “kind of” brand new - it is from 2011.

But thanks to the prevalence of Tools and Process over Individuals and Interactions that has been brought to us by tools like Jira for more than ten years now, it seems to me that it is a good idea to look at a few key points again.

For example Mike says:

There's no magic threshold at which we call a particular story an epic. It just means "big user story."

So, sorry folks: an epic does not group a bunch of requirements that do not deliver value on their own together. According to Mike’s old post an epic simply is a story that “[one] didn't get the chance to break […] down into stories that are […] small enough […].”

That’s why it is such a good idea (at least IMHO) to do whatever you like with that “Epic” thingy in Jira – use it to mark other stories, use it as a theme (see Mike’s post for a short explanation of that) use it to signal states if you don’t have a Jira admin in your team etc.

But whatever you choose to do, don’t do functional decomposition by making your epic an enumeration of sub-functions that only deliver value if they are all implemented together.

...end of rant.

till next time
  Michael Mahlberg

Do we have a Definition of Ready (DoR) and Defintion of Done in Kanban?

Funny you should ask – this ties in nicely with the topic of explicit policies.

Here is a short answer regarding DoR and DoD

Conceptually speaking, every station in a workflow has either implicit or explicit entry and exit criteria. The notion of a DoR and a DoD (as they have become widespread in the Scrum community, even though the DoR is not really part of Scrum ^[1]) is modeling exactly this: having explicit entry and exit criteria for a system with one station.

When modeling a system with Kanban, those definitions for ready and done really need to become part of the often mentioned explicit process policies.

An Example

Let’s take a look at a simple example.
Assuming we have two stations A and B –where work flows from A to B– we look at B first, honoring the principle that we work on Kanban boards starting at the point closest to the value generation: the customer facing side.

|    station A   |    station B     |
|  doing | done  |  doing  |  done  |
|        |       |         |        |
|       / \      |        / \       |
|      /   \     |       /   \      |
|     /DoR B\    |      /     \     |
|    (   ⊆   )   |     ( DoD B )    |
|     \DoD A/    |      \     /     |
|      \   /     |       \   /      |
|       \ /      |        \ /       |
|        |       |         |        |
|        |       |         |        |

In this scenario the “Definition of Ready” (the entry criteria) for station B has to be part of the “Definition of Done” for station A. Why? Well, the “Definition of Done” for station A is the DoD for the Doing column of station A. Once a work-item leaves the “Doing” column nothing should be done with it – after all it has left one Doing column and not yet entered another Doing column.

Therefore when B pulls an item it will – or at least should – be exactly in the state it was when it left the Doing column of station A. That being said, there may of course be additional rules governing the entrance to station B (e.g. if the item is part of a multi-part workflow).

For the topic under consideration “Do we have a DoR and DoD in Kanban?” the short answer would be “yes”.

Scaling up

In any life-size system, where we have more that two stations, multiple sets of entry and exit criteria make sense – one set per station (column). Whether we focus on the DoR or on the DoD first, is a matter of focus. Both approaches might be appropriate.

Taking this further, beyond A and B we get something like:

|    station A   |    station B     |   Station C    |…
|  doing | done  |  doing  |  done  |                |
|        |       |         |        |                |
|       / \      |        / \       |                |
|      /   \     |       /   \      |                |
|     /DoR B\    |      /DoR C\     |
|    (   ⊆   )   |     (   ⊆   )    |     . . .
|     \DoD A/    |      \DoD B/     |
|      \   /     |       \   /      |
|       \ /      |        \ /       |
|        |       |         |        |
|        |       |         |        |

From my experience, it is helpful to start thinking this through from the right hand side and consider the DoRs first. But then again life is complex and depending on your actual situation there may be other approaches that make sense.

Ceterum censeo: Of course we can model everything we have in a Scrum process with a Kanban system. Both operate at different levels and Kanban is meant to be able to model existing processes. The question whether you should move from one to the other is non-sensical by definition but conversely adding Kanban to Scrum actually makes a lot of sense.

Cheers
Michael

[1] The Concept of a DoR is actually only sometimes helpful. The more current versions of the Scrumguide just contain the line "Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event." The term "Definition of Ready" is only used in secondary literature.

If you talk about "Moving from Scrum to Kanban" you have misunderstood at least one of them!

• Scrum is a process framework for product development. The Scrum Guide says so. And the Scrum Guide pretty much is the official definition of Scrum.
• Kanban is an approach to process control and improvement. David says so. And he is the one literally defined Kanban for knowledge work

Scrum is defined by a specific set of roles, events, artifacts and rules that can make up a software development process when the specifics for your given context are resolved and defined.

Kanban on the other hand, provides mechanisms for controlling your work and improving the way you work together with a set of principles and practices like visualization, limiting work in progress, managing flow making policies explicit and a couple more.

Kanban does not provide counterparts to the things Scrum provides – rather, it is a complementary approach to any product development approach.

You can easily build a Kanban system for any given Scrum implementation - most of the time you just have to model four or five states, identify one to three capacities and define the cadence for the input queue and the output queue. A very simple approach here is to define the

• Stations as "Backlog", "Selected", "Implementation", "Review" and "in production" (and make them visible)
• (bracket) capacity of "Selected" through "Review" := throughput of last iteration
• input cadence := output cadence := iteration size
• iteration size := your sprint size

Of course the real power of the Kanban approach only begins after this stage, when you start to improve the way you work together collaboratively. But that would be another post...

Most of the time the processes inspired by the Kanban approach end up with a much more flow-based solution than typical scrum processes, and that is what a lot of people seem to mean when they talk about their evolution.

But please don't talk about "moving from Scrum to Kanban" – that would be like saying "I don't use a car anymore, I now use a GPS" – and you wouldn't say that, would you?

till next time
  Michael Mahlberg

We don't use a “process” we have working agreements...

“Yeah, well, I had to work around the process to get this stuff done for the customer.”
Doesn't that sound familiar? And more often than not people on the same team nod in agreement and work on like nothing happened. And soon somebody else says “Yeah, well, I had to work around the process ...”

But how about “Yeah, well, I had to violate what I agreed to upon how we work together to get the stuff done for the customer?”
In my experience people tend to be more easily annoyed or even upset by this latter violation of trust. But even more importantly the likelihood that people will re-negotiate their working agreements is also significantly higher.

That's why I try to convince my clients not to talk about “the process” but rather about working agreements.

Enter Scrum and Kanban

Now this is where approaches like Scrum, XP, FDD, SDSM or Kanban, to name a few, can hugely differ. Take Kanban and Scrum for example.
While Scrum is a Process Framework with very strict roles (at least for the Product Owner and the Scrum Master) Kanban is an approach for process control and process improvement. In many Scrum implementations I have seen, people have to “work around” things from the book. When –to name an example– was the last time you saw a person acting as Product Owner really having the final say on priorities?

Kanban on the other hand explicitly requires that we “Make process policies explicit” (4th General Practice of Kanban) – I like to restate that as “make our working agreements explicit.”

And once we start negotiating these agreements we actually start to “Improve collaboratively, [and] evolve experimentally,” as the 6th General Practice of Kanban describes.

I suggest dropping the chase for the perfect process in favor of finding the best working agreements (aka process policies) for the current situation.

till next time
  Michael Mahlberg

P.S.: The "General Practices" used to be called "Core Properties", but since the Kanban Condensed Guide, "General Practices" seems to be canonical.

The difference between a sprint-backlog and a product-backlog

Those who learned about scrum the old fashioned way might call me names for the title of this articles, but since I run into more and more people out there who mingle both terms I think a clarification might be beneficial.

A product backlog is about what you plan to accomplish

“The Product Backlog is an ordered list of everything that might be needed in the product[…]” (Scrumguide 2013)

And it is good practice to keep these things in the bounds of the INVEST properties. This implies that the product-backlog does not prescribe how the requirements are met, but what should be achieved.

A sprint backlog is about what you plan to do

“The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment.“ (ibid, emphasis added)

Big difference!

So yes, sorry mates, if you want to do scrum (and not scrum but) you'll have to do what used to be called ”Sprint planning 2“: Sit down and plan your work.
There are some options to handle things differently – like breaking down the board and “kanbanizing” that part of the workflow – but then these approaches might no longer be exactly what should be called scrum.

Cheers
Michael

Scrum is abstract

Over the last decade or so I found that more and more sotware developers struggle with scrum.

Especially since so many people treat agile the way it is described in the half-arsed agile software development manifesto or the dark agile manifesto.

So if I change Scrum (my process) - is it still Scrum (the approach)?

One thing that puzzles a lot of people is the fact that Scrum has to be amended past the 16 pages of it's official definition. The definition itself says so.
Yet on the other hand the battle cry of a huge body of people who call themselves agile professionals is "You are doing Scrum-But."
So where does that leave the teams? Torn between "Inspect and Adapt" "Responding to Change" and "Don't do Scrum-But."

Is it Scrum-But, Scrum-And or something completely different?

Of course it is possible to philosophize about this question a lot, but for the experienced software developer it should be easy to grasp. If you have a background in "clean-code" (as Uncle Bob calls it) or are familiar with the SOLID principles for other reasons the following picture says "it all": (metaphorically speaking)

If you look at it as a programming construct Scrum is an abstract class – it defines behavior, data, interactions etc. but some parts are just defined via template methods and stuff has to specified for the concrete implementation.

And for the concrete implementation it makes sense to apply the same rules that make sense when designing object oriented software.

So your subclass should only interact at the designated points without meddling with the innards of the superclass (OCP Open Close Principle). And your implementation should be usable wherever the super-type is usable (LSP Liskov Substitution Principle)

I'm not sure about the other aspects of SOLID, but transferring this thinking for the LSP and the OCP to Scrum implementation – together with the idea that Scrum is an AbstractSuperClass – helps to answer the question whether we're facing a scrum-but or not.

TTFN Michael

We don't do sprints any more ...

... we do iterations instead.

A couple of month ago a client of mine started with an effort to work in an agile way – inspired by scrum, as far as possible.

One of the first things we agreed upon was to avoid scrum-speak whenever possible. For example we don't (yet) deliver (potentially) working software to the end-user at every iteration. So we do not call the iteration a sprint.

There are many other things –like not having a truly cross-functional team etc.– that would make it a plain lie to say that we are using scrum in this project, so we don't call it scrum. We don't call the process-coach a scrum master and so on.

The surprising by-product: better communication

The most fascinating thing here for me was the effect the wording had on upper management. "Cancelling a sprint because the sprint-goal is no longer attainable" is somewhat hard to discuss with people outside the agile world without some in-depth discussion of the terms. "It makes no sense to continue with this iteration because the thing we wanted to achieve with it is no longer achievable" is much easier to grasp.
[Language remark: And this was German by the way – for those who know the language "Wir müssen den Sprint cancelln, weil wir das Sprint-Goal nicht erreichen" is way harder to understand for outsiders than "Wir brechen die Iteration ab, weil das Iterations-Ziel unerreichbar geworden ist"]

There is an adage from Jerry Weinberg wich comes to my mind here:

«If you call the tail of a dog a leg – How many legs does the dog have? Still only four – just calling the tail a leg doesn't make it a leg!»

So, how about you? Do you do Sprints? Do you do Scrum? Do you have a Product Owner? Really?

Why not try an experiment? Instead of using vaguely fitting terms from a process framework, start using terms that describe what you’re doing in “layman's terms” and see what happens.

You might spark a whole new conversation.

till next time
  Michael Mahlberg

Scrum Master or Zen Master?

Another Scrum-Master Anti-Pattern

Well – of course there is not one Scrum-Master anti-pattern. There are dozens.

Let's look at a special one today: The Scrum-Master as the Ruler, the Projectmanager, the Sovereign of the project.

To cut it short – Scrum-Masters are not.
Originally weren't meant to be at least.
Maybe sometimes they actually are – but they should not.

It is about the verb ‘master’

Here is what the dictionary on my computer has to say about the verb master:

2 it took ages to master the technique:

learn, become proficient in, know inside out, know (frontward and) backwards; pick up, grasp, understand; informal get the hang of.

If you look at it that way, a scrum master becomes to scrum what a zen master is to zen: someone who has mastered scrum and now is able to help others – at their request - to become more proficient in what they do.

Of course he also has a lot of other duties as well, but the fundamental idea of ‘mastering the process framework‘ in contrast to being the 'Master of the team' is really a big difference in the attitude.

The Scrum Guide explicitly states that ‘The Scrum Master is a servant-leader for the Scrum Team’, perhaps this is worth taking into consideration from time to time.

till next time
  Michael Mahlberg

Effective daily scrums – and how to achieve them

In this case my advice is contrary to what I usually say. This time my advice is not to go by the book!

Remember the purpose of the daily scrum

The purpose of the daily scrum is to plan ahead for the next 24 hours. It is not about reporting progress. Of course it is an important part of the planning to know the current situation, but the focus should be on the things you are about to do.

"What did I do in the last 24 hours", "What will I do in the next 24 hours", "What hinders me in achieving the sprint goal?" – those (paraphrased) questions from the scrum guide, are there to facilitate a purpose as my esteemed friend and colleague Tom Breur points out. The purpose being constantly navigating the best way to achieve the business goal for the day.

It is like action planning for firemen

The daily scrum is more like firemen planning on how to tackle a burning house they are about to enter.

They don't talk about how they clung to the seats when the fire truck skewed around the corners – it is all about the future.
"I'll go to the left with hose", "I'll break the door open, so that someone can use the powder extinguisher" "As soon as you've broken up the door, I'll use the powder extinguisher to quench the flames in the hallway" etc.

Nobody want's to know how they quenched the last fire – it's the future that counts here. (I really love this example, courtesy of another esteemed friend and colleague, David)

Turn it around

The least you can do, to make the daily scrum more efficient and effective is to turn the questions around. Start with the future, mention any impediments you actually have and then talk a little bit about what you did. If there is anything left that the others don't know from the last daily meeting or the events in between.

It is not for 24 hours!

And what's more: You don't have to talk about your plans for the next 24 hours – all you have to do is to talk about your working time, and in most places this would amount to roughly 8 hours.

Talk about the future

If you have to tell your colleagues what you did in the last 24... sorry, 8 working ours, you probably didn't tell them what you planned to do in the last daily meeting. Or you had to diverge from your plans. If you had to diverge I very much hope you didn't wait till the deadline. After all the daily meeting is a deadline for the things you planned at the last daily meeting. You told your colleagues what you had planned to do between then and the following daily scrum. Usually it is a good idea to let everybody on the team know what has changed just as soon as you find out. It just might happen to interfere with the work of your colleagues as well. After all you would like to know if a co-worker changes his mind if your work depends on their result. Even – or especially – if they have a good reason for changing their plans.

So if you talk about the last 24 8 working hours you'll only end up telling people what they already know. Either from the last daily scrum or from observations and information during the last 8 working hours.

Instead, think of the firemen planning to extinguish the fire in a burning house – or the A-Team planning a mission.

till next time
  Michael Mahlberg

Sprints – Give me a break

An iteration in Scrum is called a sprint ...
Scrum is at least six years older than the agile manifesto ... The Agile manifesto’s principle 8states that “[everybody] should be able to maintain a constant pace indefinitely.”...

How does this compute?

Sprints are related to Scrum

First of all let's re-iterate a well-known fact that often gets overlooked anyway: Scrum is not agile. WHAT? Of course Scrum is an agile Method! But that relationship has a direction. Speaking in terms of set theory what I am getting at is the fact that Scrum is just a Subset of "Agile." Looking at the history of Agile, Scrum is just one of the contributing methodologies that were instrumental in defining "Agile" (via the Agile Manifesto). And in Scrum – if you have read the old book by Schwaber and Beedle – the Idea of the Sprint was "to be able to work un-interrupted towards an agreed upon goal" (paraphrased). With these bounding conditions it makes sense to talk about a sprint, where you look neither left nor right, but focus only on the problem at hand. As long as you are sure that you are able to deliver a “potentially shippable product increment” at the end of the sprint (and not some loosely related artifacts that might be welded together in an upcoming future sprint).
But the metaphor only goes so far – the way I understood it from Ken back in 2005 and try to live it these days – sprinting here mostly refers to the focus on the sprint goal, not to the total exhaustion one would deem acceptable for winning the gold medal at a 100m sprint at the Olympic Games.

Sustainable pace is related to XP

The principle of “sustainable pace” comes – almost verbatim – from eXtreme Programming's definition of this XP "Rule" of set(ting) a sustainable pace. Here the focus actually was on not exhausting ones resources. And no, a resource in this context is not a human being, but a persons mental and physical energy reserves and such – just in the same way a marathon runner uses the phrase “at 35k I just had no resources left.”

All models are wrong - but some are useful!

"Sprint" is a Token, a word that identifies an artifact in the Scrum framework. It happens to be a metaphor as well. Metaphors only translate into different domains so far. As pointed out by the aforementioned quote some models are useful. And to me the Sprint-model is useful with regard to the focus on the next goal, not with regard to the total exhaustion of ones resources.

Your mileage may vary of course, but I think that decomposing the different aspects of the metaphor helps a lot in deciding how to live those aspects in your concrete situation.

So long,
    Michael

The conceptual Pyramid of Agile

Sometimes it helps to organize the different concepts that are common in lean and agile methods by the relationships amongst each other – kind of like in Maslows pyramid of needs

How to introduce a mindset

There is a discussion going on between different fractions in the lean and agile continuum about “the right way” to introduce new processes and mindsets. While one approach argues to start with the values, personally I’m more inclined to start with the practices (the same for Toyota btw, at least according to their European CIO and VP)

At least for some kinds of change-management it makes sense to view lean and agile approaches in a context like this:
Let’s have a look at the layers in this pyramid from the bottom up.

Techniques

The foundation is built from the concrete techniques that are necessary to get the job done. This starts by simply knowing the syntax and semantics of the programming languages used and continues with specific techniques for analysis, design, implementation. Test Driven Development has it's place in this realm as well as continuous integration, automatic builds and build-servers (not the same as continuous integration by any stretch of the imagination), pair-programming etc.

Process

Once you know how to wield a hammer and how to handle a screwdriver – and know the difference between the two –, you still need a bigger plan to build things of real complexity. That is where process comes into play. The same applies in the world of software development. Processes lay out how different steps of work are connected to each other, who’s talking to whom and about what etc.

Process Control

But then again process alone is just the beginning - a means to an end. As one manufacturer of tires once claimed "power is nothing without control."
While processes give a good indication on how to proceed from gathering requirements through to delivering tangible capabilities to end-users they usually say little on how to control the process itself. How to identify weak points, how to coordinate the work between different stations in the process and so on. This is where process control and process improvement come into play.

Examples for the more prominent approaches

XP - foundation for a lot of things

From what I see today in the agile space most techniques which are considered to be part of "common sense" or simple "agile techniques" actually stem from the original description of eXtreme Programming (XP). Test Driven Development, Continuous Integration, Pair Programming, Standup Meetings, On-Site Customers, Sustainable Pace, Simple Design, YAGNI, Planning Game etc. all where first made public via the XP-Website and even more so through the book eXtreme Programming explained (first edition!).

Consequently when I put eXtreme Programming in the pyramid it covers quite a lot of ground. It's the only lean and agile approach that I am aware of, that covers so many topics on the techniques level. And it still does a very decent job on the process level. It even has some very clear points on process control.

Scrum - Widely applicable, and not really software specific

At the time of this writing Scrum has a subjective market share of 92.6% and it appears that almost everybody who is not really part of the ‘inner circles’ of the lean and agile community assumes that Scrum and Agile are ‘almost synonyms.’ Of course nowadays many people claim that Scrum requires unit-testing, continuous integration, user stories and so forth. But if you look it up in the Scrum Guide you'll find nothing like that mentioned - after all it’s only 16 pages anyway. 16 important pages without question, but they don’t tell you how to implement Scrum.
And that’s by intent.
Scrum is like a template that you can and should build upon - but you have to flesh out the detailed workings all by yourself. And they are much more complex than the usual picture that fits on the back of a coaster. (I wrote about this in German a while back - even if you don’t speak the language I think the pictures give a good overview of the differences)

When I try to put Scrum in the Pyramid I end up with a very well defined approach to the topic „process“ – with some very small extensions into process control and techniques.

The Kanban Method - getting control

The Kanban Method for knowledge workers is an approach defined by David Anderson based on the way Toyota optimizes their processes.

While some people see Kanban as a different approach to software development – saying things like “we switched from Scrum to Kanban”. David Anderson himself points out that this is not the case, since The Kanban Method is “just” a way to run the process – what ever your process may be. You can (and should IMHO) even run Scrum using Kanban for process-control.

When placing The Kanban Method into the pyramid it fits nicely into the upper triangle, called “Process Control”, and has just a small, well defined extension into the “Process” layer.

Start with the foundation

A short while ago Uncle Bob wrote a very nice blogpost on ‘The True Corruption of Agile’ and argued in a similar direction - the practices form the culture and the culture is identified by the practices present. So, following this pyramid and Uncle Bob’s point of view, I think it is a good idea to make sure to have the foundation (the practices) intact and use all the concepts on the appropriate level of abstraction.

Where do you try to make changes happen?

’till next time
  Michael Mahlberg

P.S.: I introduced the German version of this pyramid as part of a (German) [podcast episode back in 2012][za-episode], as part of Maik Pfingsten’s Zukunftsarchitekten Podcast.

16 elevator pitches for scrum as a contribution to @boeffi's compilation

As an answer to a recent query for scrum elevator pitches on twitter from @boeffi (Who also runs German blog on software development) I asked myself (and him subsequently) a couple of questions regarding the setting and desired result to target the 140 character accordingly...
Unfortunately (for me) his answer was "All of them".
Please join the discussion at his site

Challenge accepted!

Given that I asked about four dimensions I think 16 "pitches" of less-than-140 characters will do for starters...

The collection of Scrum Elevator Pitches

Please read the disclaimer below - don't use them literally

• The physically realized earned value from delivering fully functional slices in scrum takes ROI from estimatable to measurable
  MSLM: Management, Sell, Long term, Money
• Proccesses like Scrum can help in the transformation of the whole organization towards lean by providing transparency throughout.
  MCLM: Management, Convince, Long term, Money
• By concentrating on the most valuable parts in shippable slices Scrum reduces time to market considerably - often to a few weeks.
  PSLM: Users, Sell, Long term, Money
• Instead of investing the subject matter expert's time in the test at the end Scrum involves him early to build a fitting product
  PCLM: User, Convince, Long term, Money
• One scrum project, budgeted for 10 Mio $ was ended after spending only 2 Mio $ – because it had delivered all the important features
  MSSM: Management, Sell, Short term, Money
• Scrum's focus on a "potetially shippable" increments ensures that the produced product-parts provide real value to the users
  MCSM: Management, Convince, Short term, Money
• The proven prioritization models of Scrum enable you to get high value from the development team early for your time investment
  PSSM: User, Sell, Short term, Money
• The continuous effort you put into specifications can be turned into continuously valuable and tangible results by Scrum
  PCSM: User, Convince, Short term, Money
• Scrum can give organizations the information they need for a fundamental reorientation - or help to make them ready for it
  MSLB: Management, Sell, Long-Term, Buy-in
• Having crunch times and lulls can be countered by adopting the basic Scrum rules - they create a self balancing, sustainable system
  MCLB: Management, Convince, Long-Term, Buy-in
• Getting Scrum to both sides - developers and users - gives users a real strong lever over the scope of the final delivery
  PSLB: User, Sell, Long-Term, Buy-in
• If all the effort that goes into upfront specs went into a Scrum-like collaboration the results would be closer aligned to the needs
  PCLB: User, Convince, Long-Term, Buy-in
• Scrum is a set of techniques that generates transparency and makes projects predictable and controllable again.
  MSSB: Management, Sell, Short term, Buy-in
• With scrum both parties of product development lay out rules that ensure - but also requires - mutual commitment and engagement
  MCSB: Management, Convince, Short term, Buy-in
• With Scrum you get the opportunity to set the direction of the development at least once a month.
  PSSB: User, Sell, Short term, Buy-in
• If you want to gain a real and direct influence over the priorities in the development team you might want to have a look at scrum.
  PCSB: User, Convince, Short term, Buy-in
  

Explanation of the Dimensions: Audience, Goal, Timeframe, Required Action
Audience: [Management=M, user representative or possible Product owner=P]
Goal: [Sell=S, Convince=C]
Timeframe: [Long term=L, Short term=S]
Required Action: [allocate Money or resources=M, Buy in=B]

Disclaimer

These are examples of pitches for generic situations - don't use them! Forge your own given your specific situation and requirements.
In my opinion there is no such thing as one right elevator pitch for anything - it's all about the context.

How many Backlogs do you need?

Hmm... there used to be two backlogs in scrum IIRC:
the product backlog, owned by the Product Owner and the sprint backlog owned by the team.

Nowadays, scanning through contemporary tweets and blog entries, there are at least (in various amounts)

• Product Backlog
• Sprint Backlog
• Impediment Backlog
• Technical Debt Backlog

So I wondered: Do we really need them?
Right now my answer would be "Yes" and actually I think most of us use them already - albeit more or less secluded.

Of course the Product Backlog and the Sprint Backlog are completely visible all the time.

The Impediment Backlog and the Technical Debt Backlog OTOH are not quite as popular - mostly because we "should not have them" in the first place. If all "impediments are resolved within 24 hours" and "technical debt is paid back before a task is completed (aka Done)" and we "leave everything cleaner than we found it" both "Backlogs" are more like personal lists with a lifespan of less than a day.

Unfortunately reality is slightly different in lots of places and so we should recognize this fact and install corresponding backlogs with a fitting set of attributes.

So, what could these attributes be?

For the Impediment Backlog I'll try:

The usual stuff:

• ID (Yes, I need an ID - but YMMV )
• Synopsis (An understandable but very short description of the impediment that can be scribbled during the standup meeting )
• Description (A longer description, that explains the impediment to the non-initiated)
• Date created (well...)

The specific stuff for the impediment backlog:
(All of these should be considered optional and used as growing lists - just to make sure the impediment gets the attention it deserves)

• Number of Mentions (A counter - implemented e.g. as a tally chart on index cards - to determine if the impediment is really such an impediment as it first seemed)
• People affected
• Tasks affected
• Stories affected
• area(s) affected (e.g. Specs, Tests, Coding, Deployment, Design etc.)

For the Technical Debt Backlog I'll go with…

The usual stuff (what did you expect?):

• ID (Yes, I still need an ID - but YMMV still )
• Synopsis (An understandable but very short description of the dept imposed than can be scribbled during coding or the standup meeting without much of an interruption)
• Description (A longer description, that explains the debt and its effects to the non-initiated, probably written later)
• Date created (well...)

The specific stuff for the technical debt backlog:

• Area affected (e.g. Architecture, Design, Delivery, Deployment, Stability etc.)

Hmm.. that's not so much - I wonder if the list will grow over time.
I'd expect some of the TDB (technical debt backlog) to turn into tasks eventually, but they might also vanish simply because of DoD (definition of done), "no broken windows", "leave everything cleaner than we found it" and other related practices.
I wonder if it would be possible to derive the interest rate of technical debt... but that's quite another story.