2

I am SM/PM on an internal project. Internal project X is technically and architecturally complex and demands high skill developers to work on. It has huge backlog.

However the project considered to be low priority comparing to external projects, and serves as a temporary shelter for developers waiting for assignment to other projects. Team changes during a sprint is a common problem. Team size varies from 1 to 20 near every day.

When i came to a project it was SCRUM based. Now we switched to Kanban board as sprint backlog and velocity becomes totally non-sense.

There is no possibility to change the company approach to X, i have tried. There can be no "core team" that remains constant except PO and me.

Problems encountered so far:

  1. Developer can leave a team any time dropping the story undone.
  2. Each developer has his own understanding of how to do things depending on a skill set and level which leading to a mess.
  3. There is a huge technical debt because of constant switching.
  4. Nobody can predict release date.
  5. You can have 3 QA no Dev's or vise versa. Or FE only or BE only.
  6. Management understands problem, however demands fixed release dates.
  7. There is no fresh stable version on demand.
  8. Story points of yesterdays team are not story points of today's team. Well at least when comparing issues.
  9. Dev can spend few weeks for getting into and than moved to another project.
  10. There is no good user documentation. You can check only comments on git, story's on Jira and wiki full of tech staff. There is no resources to create good documentation for it.

Action's taken so far:

  1. Fathers of a project making a code review of a critical components from time to time.
  2. Developers documenting what's done, what's need to be done for each dropped issue.
  3. Story's atomized to a level where no business value added but at least it could be done.
  4. We have automated where possible staging and local environment deploys.

Any advice's on how to make it less deteriorating?

Improve this question

2 Answers 2

Reset to default
1

Management understands problem, however demands fixed release dates.

This is fine as long you do not have a fixed scope. :)

Some ideas to make your situation easier:

  • Split up stories in to small doable tasks that can be finished in one or two days
  • Do pair programming: As people can leave the team at any time this form of knowledge sharing is very important. When one developers leaves the other can find a new pair to keep again two people in sync. Also this way developers can learn from each other. Let them watch the Pair Programming Show to become effective quickly :)
  • Use a branching strategy in order to prevent unfinished work to be pushed to the release version. Make sure the main branch is always in a releasable state. Now other developers can pick up where others left, or start over.
  • Try to create an architectural standard. The kind that forces people to work in a similar way and that make components in-depended of each other so they are loosely coupled. This way developers will break code from others less often and can focus on a smaller understandable domain hopefully. Maybe have a look at a Micro Services Architecture.
Improve this answer
5
  • 1. Split up stories in to small doable tasks - Check 2. Do pair programming - That's a good idea, we used PP for improving quality in exchange for costs and schedule. But it might also help with knowledge sharing. Thanks for idea! 3. Use a branching strategy - Check. Master always contains current stable prod version with fixes. But development branch is unstable and we can't merge it. 4. Micro Services Architecture - Good idea, developers tried to sell it to management but suffered terrible defeat.
    – Alexander Averchenko
    Commented Jan 28, 2016 at 10:15
  • How come the development branch is unstable? use feature branches and only merge stable features to development. The development branch should always be releasable also.
    – Niels van Reijmersdal
    Commented Jan 28, 2016 at 10:27
  • 1
    The micro services is just an idea, but the point is to get a consistent architecture in the project so its easier to switch people in and out. Also why do you need to sell it, just do it. The responsibility of an Agile developer is building it right. Product owners and managers are just for building the right things, they should not worry about the how. That is part of the idea of self organizing teams, your agile coach should teach management to let go of command-and-control. It is holding the teams back! :) Goodluck
    – Niels van Reijmersdal
    Commented Jan 28, 2016 at 10:28
  • Easy, if we will use feature branches we will have dead wood consisting of 100 of them all unstable. We have moved from it and leave only one dev branch. Yep, it's always in unready state Well we have an architecture design and documentation. But it is very complex. It takes month's to dive in it. But anyhow thanks for the answers!
    – Alexander Averchenko
    Commented Jan 28, 2016 at 10:51
  • Hi there. Reading this Alexander and really feeling sorry for you. I think you need to get your project charter, milestones and sponsor (or management) and present a fresh risk analysis to them that is updated daly. I don't think management here really understand the problem. The idea of scrum is that each person on the team switches roles every day so one person tests one day, one person develops the next day but the daily meetings they are meant to help one another with any blockers. Are you holding these daily meetings.
    – Treasa
    Commented Jan 28, 2016 at 20:26
1

I was on a very similar team as the TPM and just your description evokes stressful memories. The company I worked for at the time cared so little about customer service and satisfaction that they would deprioritize all break-fix work for new development and considered my team as basically a pool of free developers. I discovered however, that there was one thing I could do that would make the biggest impact on the problem:

Negotiate with the business to require the developers who are being poached to finish the User Story they are currently working on before they leave the team for whatever their new assignment is. At least then you will have more ship-ability come release time and less work will have to be redone.

Good luck. You deserve better, btw. Never forget that :)

Improve this answer
1
  • Great idea! I should try to add it to ground rules of a project.
    – Alexander Averchenko
    Commented Jan 28, 2016 at 16:37

Your Answer

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

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