Want to work agile? Deliver on time!

How often does this train leave the station? It is obvious that it is too seldom. I think this is the best picture to show how feature creep looks like. We have all seen it in software development:

The less frequent the train leaves, the more important it becomes to get on it! All features "needs" to get on the train, because they are so few and far between.



And this train will be delayed. That is for sure!
It becomes a negative self-fulfilment: the releases are happening too seldom, and consequently we need to pack them with features. The result is delayed releases, and because of this there will be even longer to the next release, and therefore it becomes even more important to get all on-board before the train leaves the station.


This is the tram close to where I live. It leaves every 7th minute. It started departing with this frequency last year (down from 15 minutes), and it resulted in several changes:

1) I do not look at the time before I leave my house: I am ready when I am, and there is no need to rush or worry that I wait too long

2) The driver does not wait for passengers that are too late and who is running the last 50 meters to make it. The driver just closes the doors and drive away on the scheduled time.


How do we get to this beautiful state when delivering software?

1: Create awareness, acknowledge the problem
I used to work in a team where the stability of our software decreased between releases. This was not a happy state. We saw that it could be rectified by increasing the release frequency.

Other good reasons for having more frequent releases could be: delivering value sooner, time to marked, need to respond to change, as a means to reduce work in progress and produce finished stuff

2: Build up the urge to change the situation
Change can be difficult, and it is hard to convince others. Therefore, I have usually worked with those that agre this is a good idea in the first place. Working with people that share the idea together identified the bare minimum to get started.

3: Just do it
It has sometimes felt like being a bit irresponsible to release without a big fat release process. It is important not to underestimate the power of habit and learned behaviour. Just make sure to have a new behaviour to replace it with, and that the team itself develops this, so all have the right ownership.

We also tried to release early to a few customers in the beginning, and I was suprised to see the enthusiasm and willingness to receive software before we "officially" had released it.

I have also fought (and won) against internal release-departments accusing us for being irresponsible. Fortunately, we flew under the radar for some time so that our practice of releasing often was well developed before the other departments attacked us.

4: Be aware that it is no free lunch
I learned this: there are lots of reasons we do have this long release cycles today. In order to get to short release cycles, those reasons need to be dealt with. And this is not so fun. Just hard work. You need to be patient and remember your goal and the pain you had with your long relase cycles. Someone in the team should have the role to keep the goal sparkling in front of the team, and remind them of the pain and gain relevant to your team's efforts.


Good Luck and good summer :)

I am looking forward to my tram is back on a normal 7 minute schedule, currently they run on reduced summer time tables, waiting for late running passengers, getting delayed, and making me stress getting on time in the morning.

How to master the power of «No»

It is easier to say yes than to say no. But remember:

Saying "No" is not having a bad attitude. Saying "No" is making a choice.  

Every good software project has some people that are great at making choices

This is how to do it:

 

I often find myself talking with business people. And usually they want everything in the whole world (at once): they want all the functionality you can think of, there should of course be no bugs or downtime in the system, and they want it all as soon as possible! This is especially true at the start of any project, or early in the release cycle.

Delivering software boils down to the ability to say no to some really appealing features. These features will not make it into the next release –a harsh truth. And we leave this out in order to secure and deliver what is even more important.

 Sounds simple, but it is hard in real life!

Why is it hard to say no?

• You feel better if you say yes –in the short term. In the long term you will need to handle to much, and you will see some of your things slip
• You make the requester happy –in the short term

What is the art of saying no?

Ignore the instinct to get the rush of reward when you say yes. Think of the implications:

• Reprioritization is always possible :) It is all about doing the right stuff first, and not fall into the trap of scope creep
• What stuff will need to slip?
• What will be the implications for the customers, the organization, the employees, the short term and the longer term?
• What is most important?
• Do not bluntly say “no”. Start with your purpose (your shared goal), what options you have and implications.
• Ask back: what is more important?
• And a really helpful question: is this a showstopper?

After this exercise, you are back on the same page on what is most important and how to move on. You are helping each other to focus on the right stuff and you have the right amount of work to keep the flow. This is a great place to be!

"No" means "Yes" to something else!

·         No to random interruptions scope creep

·         Yes to the right focus

·         Yes to flow

·         Yes to shorter releases

·         Yes to fewer bugs

·         Yes to reprioritization

·         Yes to take something else out

photo attribution