Do we really need it right now?

So, I’ve noticed you’re working on…

Imagine a scenario - you’re surrounded by passionate people who love what they do, they are eager to try cool stuff and they quickly turn their visions into outcomes.

Similar scenario - a development team that had been recently enabled and is taking an ownership of more things. They’re excited about doing things differently Not only in development but infrastructure, automation, process changes and everything else that they can put their hands on.

People around you keep trying new stuff, configuring more tools and working on improvements with happy faces

Awesome! Right? Well, it depends. The question worth asking is: do we really need that improvement right now?

Example:

- Hey, I’ve noticed you’re were working last 3 days on our new release tool…

- Sure! We are doing most of the stuff in the old way that holds us back. Thanks to what I’m after we will help us to have better control on our release frequency. It covers builds, deployments, automated testing with a single push of a button

- That’s cool, but it looks like we’re far away from our sprint goal and we made commitments. You’ve been there with us when we planned the sprint… BTW - Are you sure we need all of these now?

- So, you don’t want me to work on improvements?! We need to improve things! Sooner or later we’ll need them!

- You’re right and I like your commitment, there will be no value of having any improvement when we fail in delivering features…

- So, should I drop what I’m doing?

- Let me think… How much it takes to have proper builds? Our current setup is painful…

- I already got it covered

- Awesome! Let’s use this part for now and make sure you put rest of your ideas to the backlog. We’ll talk to the team, hopefully we will find some space to work on them in the next sprint

Improvements and technical procrastination

- Have you done your homework? Not yet, I have to check on something in the Internet first

Working on a new stuff is exciting. It keeps us motivated. The problem is - sometimes it keeps us distracted from our main commitments. The bigger problem is - sometimes these activities are hidden from a product owner, and sometimes they are even hidden from a team. Lurking in a shadow of secrets till our internal change agent finishes its work and we show our new baby to the team…

Guns still blazing, eyes full of passion, ready to show the latest improvement but… there is no one to listen… The rest of the team is busy with working on features, and they had more to do because one of their team members didn’t communicate about his ideas and plans.

Sometimes working on features is not the most exciting things we do given all new tools and practices around us. However, we can’t use an improvement as an excuse from doing a work that the rest of the team committed to deliver. Also we can’t hide our commitments from the team.

Improvements as user stories

So, no improvements then? No! Improvements are one of the most important things in our work. We should keep questioning our status quo and look for opportunities to reduce waste and make things going smoother. However, we have to remember working on them adds up to team commitments.

How to manage them efficiently? We can try a similar way we manage other commitments. We can put them as requirements with an expected outcome and preferably, an estimated value. They can be also expressed as user stories

A very naive example could be:

-As a product owner I want to release daily to get users feedback more frequently

We can manage improvements with a backlog. Ideally it should be the same backlog that team uses for a product or their work stream. It will help with keeping things transparent and trigger discussions about a hypothetical value of each improvement. Also, they should go through refinements, prioritisation and planning - in the same way as other user stories.

Improvements should have an owner and be prioritised. Once again, having a Product Owner who understands how technical improvements can glue with concepts like time to market would be awesome. Improvements’ owner should be capable of explaining a hypothetical value of implementing them to the rest of an organisation.

Don’t be a cowboy change agent

  • Have a vision
  • Keep pushing limits
  • Prioritise work
  • Don’t overthink your problems
  • Keep changes small and lightweight - smaller, simpler pieces will be adapted faster
  • Limit your improvement WIP - don’t overwhelm everyone with number of changes
  • Be patient, you’ll get there
  • Get things done

- to blog -

blog built using modified cayman-theme by Jason Long. LICENSE