Red Flag – There is no customer


In agile development we value customer collaboration. That requires a customer to collaborate with, agree? The first principle of the agile manifesto is:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Let’s focus on the first sentence of this principle. This clearly states that we want to satisfy “the customer”.

Who is “the customer”? Very often teams only deal with a project leader. The project leader’s role is to play the role of the customer. To me that is a clear smell. Yet, it is reality for many teams.

Everyone who’s ever been to a decent agile introduction training has been told that we work in close collaboration with the customer.

Now why do we consider real user access important? Well, we want to make sure we actually build software that our users love and are happy about. The answer is actually in the last part of the above principle: “delivery of valuable software”.  By talking to a real user you avoid building stuff they actually don’t need. You are not wasting your or someone else’s money and time and you avoid damaging your reputation.

So what are your options if you don’t have access to a real customer at the moment?

  • Keep things small. Small teams have a better chance to get closer to a real customer.
  • Use other ways to get access to real user feedback. Dropbox allows users to post feature requests and have other users vote on features they want. The advantage of such a strategy is that you even get a prioritized backlog.
  • Collect usage data from your application. Monitor what parts of your application are used most. Try to monitor how users use the software and when. You can maybe ask for in-app feedback. Make sure your users know and have an option to participate in this though. People may dislike it when they find out and did not know you where collecting data.

Even these options may be hard to implement for you. Eventually, it boils down to if your organization is able to understand the value of real customer feedback. That requires a humble attitude. An attitude where we don’t assume that we know what the user wants. We often confuse what we want ourselves with what the user of your software product might want.

 

Agile Dysfuctions


Agile development has been around for maybe close to 15 years now. Tim Ottinger and I started talking about “Take Back Agile“. My incentive for this was frustration and shame with what we have achieved in all those years.

The success stories about agile development often seem exaggerated. Most implementations of agile do not come close to what the stories tells us.

Joshua Kerievsky moved to Anzen. With Anzen we are looking at software development from a safety perspective. Safetely for customers, users, investors, developers, basically anyone who deals with software.

The advantage of being in the agile development professional for so many years is that it is easy to see patterns of success and failure. Unfortunately the latter still prospers despite agile development.

This post is the first in a serie that I am about to write.

I will start posting about red flags, problems, failure modes and defenses we have come to know over the years. My intention is to share this knowledge so you can use it to practice safer software development.

I once was an agilist


Agile is hot. Hotter than ever. I have been an agilist for over ten years. Last year I got the privilege to start working with Joshua Kerievsky founder of Industrial Logic.

Last year Joshua found the overarching principle that we all at Industrial Logic believe is the one key element that has not received a lot of the attention, but has always implicitly been build in in most of the agile practices. That key element is safety. In Japanse this word translates to anzen.

Our job has changed from teaching and coaching people agile practices to protecting peopleWe are now anzeneers.

You can find Joshua’s blog about anzeneering here.