3

I'm running a team that takes care of 3 products that are distinct in language/product type so that 2 out of 6 developers I manage are only ever locked to coding on 2 of the products (thick client applications). The other 4, are the web developers and look after a very rich/complicated web application.

The process the team are used to doing is story pointing based entirely on complexity alone, but the web team and other 2 dev's point their own user stories for their products. So 4 dev's point their web stories, and the 2 point their other product stories. The team then total those up, and the velocity calculation is based on all 6 of those developers. Further to this, there are 3 QA's who bounce between being able to test either web and the other products, so don't strictly belong to the web developers alone, or the 2 other devs.

I'm really struggling to grasp that this is the 'Agile' way and what I want to do is split the two groups, lock 1 QA to the 2 thick client developers, and then lock 2 other QA to the web team. This way, I can get independent velocity and manage the time of both groups better.

Another problem I'm having is having no visibility of when a release is QA heavy or development heavy and light on QA. Thus having developers and/or QA running out of work. It's driving me a little crazy that I can't see any estimation of QA efforts along side development effort.

Can someone tell me where I'm going wrong in my thinking, or this teams process flawed? I just feel the 'Agile' scrum process here has such lack of clarity behind the individuals skills/time management.

Improve this question
3
  • Do you get complaints/comments (either during planning or during a sprint) from developers and/or QA that they are low on work? Are there other indications that this might be happening (such as additional stories being pulled into the sprint)? Or is it mostly that you don't know everyone's workload and are uncomfortable with that?
    – Bart van Ingen Schenau
    Sep 17, 2014 at 18:50
  • One release QA run out, another release dev's run out, and other releases the 2 dev's on the client apps run out. When I tell people the release is over budget, then resource run out of things to do, its really hard to explain given the current metrics over the team how that happened. It's very frustrating.
    – Martin Blore
    Sep 17, 2014 at 18:54
  • And yes, stories are pulled from the backlog that were dropped because the start of the release it looked over budget.
    – Martin Blore
    Sep 17, 2014 at 18:56

1 Answer 1

Reset to default
3

The core idea of Agile is that you can adapt quickly. Adapt your products quickly to changing requirements, but also adapt your processes to your unique situation.
Another core idea of Agile is that management shouldn't be laying down the law, but that the teams are quite capable of deciding for themselves what works and what doesn't. So, whatever you do, try to get the team to buy into it.

The fact that the web-dev stories have a different base for their story points from the thick-client stories indicates that the developers have already split themselves effectively into two teams.

There are several things that can be done to get more clarity:

  • For each story, estimate how much development effort and how much testing effort goes into it. This can be done by estimating twice, with different viewpoints, or by splitting the stories into tasks and estimating those. (Commonly, task estimation is done the traditional way in hours of effort. Tasks should be small enough that this can be done without too much uncertainty.)
    When planning a sprint, this will give an idea not only if the planned stories fit within the velocity, but also if it can be done with the available resources (and their skill sets).
  • I would start to maintain different burndown charts and velocities for the web project and the thick-client projects. That way you see faster if a sub-team is under- or overcommitting for a sprint.
  • If you find there is a strong dis-balance in the planned workload for one particular skill set (for example, there is a boatload of work for the web developers, but less testing to be done), see if the others can help out. Possibilities are, for example, that the QA's/other devs help with unit testing, or that developers do some QA work (on code that they didn't write).

Ultimately, the team as a whole is responsible for delivering the complete set of stories they committed to and everyone should be prepared to do whatever is needed to realize that. Even if that means your job for the day is to fetch coffee for the others.

Improve this answer
4
  • That's exactly along the lines of what I was planning to do. I wasn't feeling confident enough in what that means to be Agile and breaking the process. Now, about the doing anything to get the release out even if it means making tea/coffee, that would be difficult to stand when it's not covered in their job description or the positions in the team are not sold like that when they are hired ;)
    – Martin Blore
    Sep 17, 2014 at 20:16
  • agreed, but also recommend discussing this with the team and coming up with a solution together
    – Steven A. Lowe
    Sep 18, 2014 at 2:04
  • 1
    @MartinBlore: It should be extremely rare that making tea/coffee is the most useful one can be for the team. Usually there is something more useful to do, but it helps to illustrate that the team commitment should be more important than an individual's job description.
    – Bart van Ingen Schenau
    Sep 18, 2014 at 6:42
  • Very well put Bart. Thanks for your advice, very much appreciated.
    – Martin Blore
    Sep 18, 2014 at 8:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.