The agile weblog of Sebastian Schürmann

The hen and egg problem

Imagine, you do a project with a UX guy. He is building the UI and expects an api while doing so.

The Problem

The API will change and new methods will be required as well as changes to “old” parts of the API. You are creative, right? Not everything is laid out in a User-Story, right? New features lead to new Ideas, right?

This leads to a slow down in the cycle. A Server is a different thing. If you want to release, you need a working server component and the client. In order to build a stable one, a defined interface in terms of a restful API would be a good start.

However, this Ping-Pong has a price: time.

Fake it, until you make it

A good Idea would be a API prototype, kinda easy to create and change. In a very short amount of time. Save the time for the concrete implementation of the API by using a mock System.

Interfake is a tool which allows developers of client-side applications of any platform to easily create dummy HTTP APIs to develop against. Let’s get started with a simple example.

Interfake on Github

Playing Ping-Pong with the UX guy just got faster.

Finding out (learning) the requirements of an API is part of the building process (Hello no estimates folks). The cycle time here, goes down (Hello Kanban Community).

Optional: You could create a bunch of tests for the mock API to code the real API against. This is not implemented (yet?). This would be a nice Artifact for a TDD process, right? Estimating a User-Story in a agile context that already has a bunch of ready made Unit-Tests is easy? I would think so.






How to reduce scope

So, you have the problem that you can’t meet the deadline? You added people and circulate ideas about cutting on quality in order to meet the deadline? What to do as a product owner in this situation? Your Backlog is big and  full of shiny stories, but you can’t build them all? It’s sounds a little receipish, but bare with me for a moment. Here is a genuine idea: Use a relative weight backlog! What you need:

  • A set of user-stories organized as a relative weight backlog
  • Stakeholders and Management
  • A room and time (up to 3 hrs)
  • Explanation of Value+Benefit, Storypoints and Risk
  • Some techies around to answer stakeholder question
  • A general estimation by the stakeholders, how much value in % they want to give up, in order to meet the deadline. It’s a estimate ;)
  • A empty list of stuff to remove

What are you looking for?

1. Stories that have Zero Benefit and Zero Penalty. 

These should not be in the backlog anyways. If there are no dependencies to other stories, there should be questions about how the feature landed in the backlog in the first place. If you find dependencies, see if you can resolve them. Put all the items on a list.

2. Stories with low penalty or low benefit. 

These can  be discussed. piece by piece. Document every decision when you start closing the stories. You got the stakeholders in a room. They can make it happen. They can remove stuff from the backlog. Add stuff to “the list” while you have the discussion. Check on the dependencies.

3. Stories with high risk. 

Depending on how risk was defined  by the team, choose items with a lot of risk involved. Remove carefully. Risk often is related to security/scalability etc.: discuss carefully, be nice to developers.  On the other hand: There can be gems. Maybe a little value created is covered by a big technical risk.

4. Others

You got your own ideas about what should be in or not? Good: After a team already created a relative weight backlog in the first place every stakeholder and developer should have the right infos already. Add stuff to “the list” The work begins!

  1. Check if all Stories are rightly in the list. If there is to much objection: remove it from the list, back into the backlog.
  2. Sum Up the Value removed. Try to stay below the value that was initially agreed on.
  3. Make a decision about “the list”: “If technically possible remove this stories.

Meeting ends here Now the Product Owner works through the list and makes all this sad calls to People who will not receive their feature. Sad Panda day. The team works through “the list” gives it a shot to kill the stories. There were those dependencies: you might have to write new stories. Be nice and give it an estimate. If you are not estimating … ok … you just have to be sure you are removing more than you add. The “agreement” Meeting  Back to the meeting room with team, management and maybe some stakeholders. The rest of the list is presented. This is what will be removed. The Team and PO present the changes that have to be made and the consequences that arise out of this. This is what will be added to the backlog. Let people ask questions. End the meeting (everybody agreed already to what will be removed) Remarks

  • Don’t mix this up with a discussion about deadlines. It’s about removing scope. Have this discussion with a smaller group. You removed stuff, come up with an idea how much time that saved. So easy then.
  • Yes, you have to have a relative weight backlog. The process of estimating it in the first place speeds up the sessions about removing scope.
  • Doing this is a serious effort. Prepare the sessions, make everyone aware that removing stuff from a already filled backlog requires effort in the first place.
  • I would estimate 3hrs for a 60 item backlog in the first meeting, the effort for the re-planning
  • If you have your qualitiy requirements in the DOD or DOR, there is a lower chance for cutting of quality (win).
  • Everyone took part on the decision, lower chance for bad feedback on the big project retro.

Social Human Architecture for Beginners – The Booklist

While giving the Talk about “all those soft skills”, I referred to a lot of Books and Papers that someone could read. I will list all of them now

Introversion / Extraversion




Conway’s Law


Daniel Pink



I hope those are of value for everyone who participated in the talk.

The most import…

The most important thing I’ve accomplished, other than building the compiler, is training young people. They come to me, you know, and say, “Do you think we can do this?” I say, “Try it.” And I back ‘em up. They need that. I keep track of them as they get older and I stir ‘em up at intervals so they don’t forget to take chances.”[25]

Grace Murray Hopper (December 9, 1906 – January 1, 1992) was an American computer scientist and United States Navy Rear Admiral. A pioneer in the field, she was one of the first programmers of the Harvard Mark Icomputer, and developed the firstcompiler for a computer programming language.[1][2][3][4][5] She conceptualized the idea of machine-independent programming languages, which led to the development of COBOL, one of the first modern programming languages. She is credited with popularizing the term “debugging” for fixing computer glitches (inspired by an actual mothremoved from the computer). Owing to the breadth of her accomplishments and her naval rank, she is sometimes referred to as “Amazing Grace”.[6][7] The U.S. Navy destroyer USS Hopper (DDG-70) is named for her, as was the Cray XE6 “Hopper” supercomputer atNERSC.


Miško Hevery about Pair-Programming

Miško Hevery about Pair-Programming

Over my dead body!

Ever since I started with XP and especially Testing, there is a pattern evolving that works like this

“The Agency”

When I worked in a “Agency” and wanted to do Unittesting, TDD, Application Testing in order to achieve what you can achieve with it, my Bosses and Senior-Colleagues told me:

  • Too much Time to invest
  • Will slow down development cycles
  • Not working in our specific environment
  • But over there, in “The Big Enterprise”, they do it, the have the Use-Case for High Quality

I kept on babbling my TDD, Refactoring, fowlerish crazytalk and finally applied for a position with “The Big Enterprise”

The Big Enterprise

When I worked in “The Big Enterprise” and wanted to do Unittesting, TDD, Application Testing in order to achieve what you can achieve with it, my Bosses told me

  • Too much Time to invest
  • Will slow down development cycles
  • Not working in our specific environment
  • But over there, in “The Startup”, they do it, the have the Use-Case for High Quality

I kept on babbling my TDD, Refactoring, fowlerish crazytalk and our Team applied it (Kudos to my Boss who simply let us do it – Tank you Stefan!) and finally went to work in a startup

The Startup

When I worked in “The Startup” and wanted the Teams to do Unittesting, TDD, Application Testing  in order to achieve what you can achieve with it, my Bosses and Colleagues told me:

  • Too much Time to invest
  • Will slow down development cycles
  • Not working in our specific environment
  • But over there, in “The Agency”, they do it, they have the Use-Case for High Quality

I kept on babbling my TDD, Refactoring, fowlerish crazytalk and wrote this Blogpost ;)

The cycleThere is NO alternative to high Quality

Over the last 13 years, the time I create Sourcecode in a professional environment, I have heard the same argument all over again and again. And I saw all of them failing with quality: Big Enterprise, The Agency, The Startup. They all told me the same Story. They ALL were WRONG. I realized one thing: High quality is nothing you ask your boss for, you do it, you don’t even get into the discussion if it pays off or not. Either the company is committed to high quality code, that steadily improves or it is doomed. Either the company knows science or it doesn’t . If it does, it will go for quality. If it does not, it is doomed. Like a cancer patient using Globuli and Crystals for healing.
Crappy code will fail your customers, your Business, your Shareholders, your Investors and it will fail YOU. Miserably, every day. And dear Developers and people around them: This is all your Responsibility. Every day and you can change it. Every day you can decide for Quality or somethings else. I realized this:

As a person, taking pride in my craft, using the tools that the modern development lifecycle provides, I have the sole Responsibility to work with these tools or walk away. This way or: Over my dead body.

A “Scrum Lego City” Relative Weight Workshop

A Relative Weight Backlog is one of the key artifacts in scrum. I always had a hard time to explain it to people. Since we are doing regular workshops in our company we had an excellent opportunity to let our product owners experience building a relative weight backlog in a safe environment. The whole exercise is based on the User Stories from Agile 42′s Scrum Lego City game.


  • Product Owners
  • Product Managers
  • Managers

Read the rest of this entry »

Choose Scrum

In a retro, a team asked me, after a period of self chosen “Scrum-But” to reinforce the rules that we all agreed to. So I came up with this little meme that resides on the sprint backlog now.

Bildschirmfoto 2013-11-08 um 17.46.06

So you are Post-Scrum?

I hear a lot of teams are “POST-SCRUM”. That is not a bad thing, given one of the basic mechanics is “Inspect and Adapt”. This is constantly changing the process and it’s properties from sprint to sprint. So, basically you go “POST-SCRUM” after Sprint One (most times it’s the third in practice).

However, you want to take the principles in the agile manifesto into consideration and check if your changes collide with them For further reference, I added them here

  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  • Business people and developers must work together daily throughout the project.
  • Build projects around motivated individuals. 
  • Give them the environment and support they need, and trust them to get the job done.
  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  • Working software is the primary measure of progress.
  • Agile processes promote sustainable development. 
  • The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  • Continuous attention to technical excellence and good design enhances agility.
  • Simplicity–the art of maximizing the amount of work not done–is essential.
  • The best architectures, requirements, and designs emerge from self-organizing teams.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

I don’t really care what you do. Really. No matter if you go for Scrum-Ban, Pure Kanban or join the #noestimates movement. These principles can help you to check your “POST-SCRUM” setup. Don’t go post beyond them without serious reasoning.

p.s. Don’t fall for marketing people. Scrum bashed waterfall for marketing reasons (and Crystal Clear, RUP for that matter) and was very successful with it. Yes, I am guilty as charged as well. We could get out of this cycle of adversative memes, out there to sell you the next method (and certificates, workshops that come with the new hot shit).

Agile Coach Camp Barcelona #accbcn13

I was asked if I could publish some photos from “Agile Coach Camp Barcelona” .. so here you go. It was a blast. Maybe there is time to write something about it.


Get every new post delivered to your Inbox.