1

I run a team of 6 back-end developers and I've recently implemented the Agile & Scrum methodology in the company, starting with the back-end team (which later will apply to other departments, when the process is proven successful and refined).

The process proved a success in different areas (quality, productivity and happier environment in the room). However, we've hit a roadblock in terms of productivity for the past 3 weeks (I measure KPIs for each individual and for the team).

My reaction to this was to get scheduling more efficient in prioritising tasks, applying a mandatory Briefing Meeting for every major project (where the Project Manager, myself and a Lead Developer will be present) and clear communication between all parties. Me and the Managing Director (both of us are technical) make sure to provide technical support, clear any road-blocks the team may have and constantly test anything that goes in the "Testing" column, to keep quality and standards high.

I feel I've done all I could, management-wise. I've also got the support of all the Directors in the company and we've all got a great working relationship, which means I don't have any constraints to implement changes. My only concern is that, from a commercial standpoint, we don't go through enough work to make us profitable. Me and the MD believe that the problem might be in the individual productivity of each member of the team.

TLDR - What other techniques/processes, besides the ones mentioned above, have you used to further increase productivity, when managing a back-end team using Agile & Scrum?

Improve this question
9
  • Is the productivity better or worse than before changing methodology? How long is it since the change?
    – Patricia Shanahan
    Commented Nov 26, 2017 at 14:45
  • Productivity doubled since I implemented the methodology. This was 7 weeks ago
    – user932132
    Commented Nov 26, 2017 at 14:56
  • Does your team spend a lot of time doing "nothing", eg. tasks not defined in the sprint planning, and do you compare the estimated times to actual times during sprint retrospectives? Is there a big difference in them? And how much time is allocated for them team? Eg. if they estimate a ticket to take 6 days, and it took 6 days, are they also assigned tickets to fill up the rest of the sprint with some overhead? Eg. 2 week sprint should result in eg. 8 days of estimated work done. If it is closer to 5-6 with correct estimates, then just assign one or two small tickets.
    – Juha Untinen
    Commented Nov 26, 2017 at 16:48
  • 4
    If you've truly "doubled productivity in 7 weeks" (4 weeks with a 3 week plateau) and the team is still not considered "profitable"... it makes me think that there's a serious problem with measurement methodology and expectations. A few weeks is rarely enough time to see substantive performance turnarounds in complex activities simply by virtue of project management techniques. Moreover, sprints are typically 1-2 weeks each, so are you just reacting to the team falling short on the last 2-3 sprints?
    – teego1967
    Commented Nov 26, 2017 at 18:57
  • The overwhelming answer is to change tools. It's very likely you could eliminate all six jobs by just moving to Firebase or Outsystems. The days of people being paid for laboriously building custom backends, is history. Dicking around with things like "agile" (lol) which might bring you a 5 or maybe 6 percent efficiency gain is - insanity.
    – Fattie
    Commented Nov 27, 2017 at 1:11

1 Answer 1

Reset to default
2

I see two questions baked in here: How do we improve team productivity? and How can we help a team be profitable?

Profitability

This is a massive topic, so I'll only touch on it enough to explain why productivity is not the same thing as profitability. For a simple example, if I make widgets I sell for $10 and it costs me $100/day to operate, I need to make more than 10. Let's say I make 8. I can solve this by finding a way to make to, or by charging $13 instead. Both of these options make me profitable.

Changing productivity is a long-term investment. The 100% increase in productivity you've seen in such a short time is practically unheard of. I'm delighted for you and your team that you saw it, but it's not the norm and I wouldn't bank on seeing another turnaround like that. If you need a short-term fix, you need to be generating more value, which might mean charging more or prioritizing more valuable work.

Productivity

Retrospectives

I'd look at what kinds of improvements are coming out of your retrospectives. This is your primary vehicle for team improvement. Take a look at https://plans-for-retrospectives.com/en/ for ideas on more effective retrospectives. Try their more structured 5-stage approach to see if it generates more powerful insights. I don't know your team, but most teams I've worked with do not get full value from their retros.

Lean Wastes (3 M's)

There's a great exercise I've done with teams around the 3 M's in lean (Mura, Muda, Muri). Create 3 columns or sections on a board and explain the 3M's (quick description below) and ask them to write down sticky notes with wastes they encounter in their work day and put them in the right column. I usually get at least 20 - 30 out of a group. You can't solve them all at once and many can only be improved instead of removed, but this will give you a great list of things that slow your team down that you may be able to help with.

Couldn't find a link with descriptions I was happy with, so here are brief definitions:

Muri (Overburden): There is a maximum amount of work I can handle at once and after that, I just get bogged down in managing and prioritizing the work and it takes away from my time actually doing it. For more information and math proofs, take a look at Little's Law from queuing theory. Hint: the number of things is usually less than 5, in some cases, it's 1.

Mura (Variation): In knowledge work I see three common types of Mura waste. Context switching where I'm trying to multitask or split time on different projects. Task type variation that requires me to work in very different ways (grouping tasks types together can help with this). And finally, flow variation - for example, all stories moving to testing at the end of a sprint and the testers go from bored to overloaded.

Muda (Non-value-add activities): This is sort of self-explanatory. What activities take up time in the day that don't move your application features forward. You can also take a look at the lean 7 wastes for more on this, though it's mostly written from the manufacturing perspective and you need to do a bit of translation to knowledge work. (for example, items sitting in inventory translate to unreleased code)

Improve this answer

Not the answer you're looking for? Browse other questions tagged .