Show all posts
6 years ago

Faster. Faster. Faster.

I've been thinking about  the influences that might affect the team's velocity recently. Every single product owner wants to have features delivered as soon as possible. It may seem that this race for a better velocity is the wrong goal and can lead to the ugly "Work faster, basterds!" solution. But that's not the case in a good and healthy environment .

Here is the diagram I've sketched in half an hour to generate some ideas. Bubbles are activities, practices and other entities that can make an impact on the development speed. They can have either positive or negative effect. For example, it seems that only two things improve velocity directly: fast feedback and experienced developers. While there are many other things that slow us down, such us unplanned work, interruptions, multi-tasking, rework, high coupling and technical debt.

Velocity diagram. What influences velocity?

The cool thing about this diagram is that it asks very specific questions:

  • How to deal with customer requests and reduce unplanned work?
  • What to do with urgent bugs?
  • How to do more training?
  • How to have smaller batches?
  • What to do about noise and interruptions?

When you ask such questions on a retrospective meeting, you can expect quite many good ideas. If you just ask:  "How can we work faster?",  the answer would be silence and confusion.

  • Denis Romanovsky

    I think you miss leadership. Leader chooses focus for engineers: understand scope, create features, fix bugs, refactor, proceed  meetings and so on. Good leadership helps to avoid uproductive activities and focus on the main, bad leadership makes thing going completely wrong and slowly. If you want to speed up the development, help the leader and the team make the right decisions as soon as possible! Tell them when they are wrong as soon as possible too.

  • Kate Bukatina

    I think sometimes previous experience also influences the speed. The more good releases you have – the more self-confident developers are. If there are several fails in a row – they start to be overcautious, checking and testing everything too many times and therefore delaying release.

  • Ralf Westphal

    I agree with “faster feedback”. In fact I agree so much with it that I recommend: get feedback on a daily basis.

    Shortening iterations to just 1 day has many advantages, I think (see here for a detailed explanation:

    * Feedback is generated very fast. Mental state from development is still in your head when the customer gives feedback. (With Scrum it takes weeks until the PO is accepting your work.)

    * The course of development can be changed as needed on a daily basis. This factually does away with most urgent request that usually interrupt teams. Interruptions – so to speak – become the norm. The team interrupts itself every day and asks: What is the most important thing we should do now?

    * The customer can halt development on features at any time. Features need not be completed to realize only 70% are needed (and 30% are a waste of money). At any time the customer can adjourn further work on a feature in favor of another feature or bug.

    * Multi-tasking can be done as needed like a single CPU does multi-tasking. An iteration length of 1 day effectively puts a team in a “preemptive multi-tasking” mode like operating systems – without the negative effects of unintended interruptions.

    * By possibly changing the course of development every day the code base is under constant pressure to evolve. This helps to actually make and keep it evolvable in the first place. A team cannot possibly sustain the pace of daily delivery (which I call Spinning) without producing clean code.

  • Michael Dubakov

    @facebook-765658293:disqus Nothing is possible without Leadership. So to me it is a pre-requisite 🙂

  • Michael Dubakov

    @facebook-575141546:disqus Yes, you are right. Success generates success.

  • Michael Dubakov

    @Ralf I read that post in fact and I like several ideas from it. For example, I am willing to try 1-day user stories and personally I think it is a very good way to move forward. Now I need to sell this to the team 🙂

    We do Kanban, so iterations are not for us.

  • Ralf Westphal

    You mean user stories sized in a way so their implementation takes just 1 day?

    I doubt you´ll be able to come up with such user stories. Keep the user stories as they are. Cut them up into features. A feature representing some value to some user – but being linked to a specific interaction with the system, e.g. a mouse click or menu item. (User stories are usually made up of many such interactions.)

    Features are of very different size. Some take several days to implement, some several weeks, well, only a few will require just a day. So here comes the challenge: Cut a feature into even thinner slices; but those feature slices are of the same size. Each feature slice can be implemented in just 1 day of team work.

    With a whole feature before you maybe you´re just able to cut off a couple of slices and leave the rest as a chunk to be cut up further at a later time – if the user requests more feature slices of it to be implemented. That´s ok. That´s agile, too 🙂

    Each feature slice delivers value to the customer/user. Sometimes it´s hard to imagine how to be able to cut a feature into such thin day long slices. But in my experience it´s possible in 95% of all cases. And it´s worth the effort. The point is: Any way the customer can give feedback on a feature slice is ok. If a feature slice is burried somewhere deep in the heart of some server side code, you can nevertheless make it tangible for the user. Just build a test bench for it.

    Think of a TicTacToe game. The first feature to implement could be “check for winning constellation”. There need not be any user interface where a player places tokens on a game board. Just device a test bend for the checking code, which can be encapsulated in some library. Make the test bench available for the user and ask for feedback on just this single feature. Although this might be strange at first for the user, he´ll understand what to do and see the benefit of it.

  • PM Hut

    Hi Kate,

    If there are several fails in a row, then the situation needs to be addressed in order to return things back to normal. Allowing the project to reach a point where developers are walking over egg shells is not acceptable.

  • Agile Training Courses

    Interruptions are the killer to any project. I like what 37 signals do with their staff.

    While half the staff are coding the other half of the programmers are working on the support desk. After 3 months it changes round and those who were on support desk are now coding. 

    I think it allow the programmers first hand find out what the customer wants and needs are. They get to understand what their customers were trying to do and how they want to do it. 

    It also gives them a period of time to think about the software and how they can go about moving it forward from an outside perspective.

    Again its alright if you can afford to pay developer prices for support teams. On the other hand can you afford not too?

    Nice post 🙂

  • Ralf Westphal

    This sounds as if support was a virtue. Keep up a support desk so devs can learn? Hm… strange. I always thought support was waste to eliminate. As a user I prefer software which does not require me to contact support. High usability, low number of defects.

    As necessary as support at a given point in time might be – it should always be the goal of management as well as developers to eliminate the need for support. Zero support should be the goal.

  • Agile Master

    I have found the doing multi tasking has proved to be a really big evil. Some mangers thought developer can spend 40% of their time on one project and rest on other. That does nothing but leaving developer confused what is priority and when to do switch over and also a mental context switch needs to occur before you really get into one project to another.

    BTW if you dont mind can you please put this in a typed text diagram instead of handwritten …some bubbles are really difficult to read 😉

  • Matthew Skelton

    Ralf, if ‘support’ is construed as ‘low-value ticket-chasing’, then I can almost agree (although there will always be a need for cross-service incident coordination). However, with our systems increasing in complexity, not reducing, the need for skilled & experienced people to sense/diagnose problems and resolve incidents is arguably increasing. Learning from real Production incidents is surely one of the most valuable things a developer can do in the context of writing good software – would you agree?