1

Background

I'm a junior project manager in a small software house with not much experience on our market. My aim is to organise work teams work in most efficient way, work out sustainable processes, boost team productivity and prepare our company for scaling up. I would like to discuss the situation with you guys to find out about your points of view and maybe figure out a solution to problems with which we struggle.

Description of company:

Small software house, developing websites and mobile apps

Team:

  • 5 developers (fullstack, so involved in mobile and websites projects)
  • PM

  • UI/UX Designer

    Tools:

  • Confluence for wiki and files storage

  • JIRA for task management & timetracking

We are busy with:

  • Development for new customers
  • Ongoing development for existing customers
  • Ongoing maintenance for developed solutions

Project management:

  • Each project for every customer is organised into its own separate project on JIRA, with its own scrum Board, own backlog etc. If we develop a mobile app, a web app and a website for one customer, that means we have 3 ongoing JIRA projects, 3 scrum boards etc.

  • We have 30-min weekly standup sessions with the entire team to share our work progress and to update each other on what's going to happen next. We also meet up at 5pm everyday for a quick summary of what we managed to do and what we are planning to do tomorrow and then we call it a day.

  • Almost all developers are assigned to all projects (with different capacity). We have also few small projects with only one developer
    assigned.

  • After each sprint there is a retrospective session organised during which we go through the work done and try to make it better next
    time.

Problems we face

  • We have many scrum boards, but we don't have a main one. It's not clear for developers, who is working on what etc. To make myself clear, I assign tasks to them in JIRA. I myself lose the big picture from time to time managing so many boards and projects.

  • It's not clear for each developer, what he should do next after completing a task.

  • A lot of delays because of emerging, unexpected tasks from maintenance part. It's not an unusual situation to drop the current work and go fight the fire with everyone we got on deck.

Questions:

  • How does one manage scrum projects in a situation, where you have all the team involved in every project?
  • Is there a way to have one main scrum board? Is it a good approach? Or there is other better way?
  • Our customers have access to their projects on our JIRA to be able to track progress on scrum boards. What are your thoughts on this approach?
  • Do you have maybe some good tips/tricks? From my point of view it is crystal clear how to use agile and scrum for one project and one team, but it's getting nasty when you have a lot to do with very limited human resources.
Improve this question
3
  • How fast are you going to scale up? This setup scales ok once you bring in people, but it does a poor job if you stay at 5 to 10. In addition, you use "Scrum" a lot, but you call yourself a PM. How does that work out?
    – nvoigt
    Commented Jan 2, 2017 at 13:09
  • 1
    Might not be an exact duplicate, but still check out pm.stackexchange.com/questions/11083/…
    – Sarov
    Commented Jan 2, 2017 at 14:11
  • @nvoigt I'm a PM-slash-scrum-master myself. My feeling is that this is fairly common in departments that are traditionally (if at all) structured but trying to adopt an agile methodology. That hybrid role is not pure scrum, but if it helps them make the transition, I wouldn't make a big deal out of it.
    – Pedro
    Commented Jan 2, 2017 at 19:14

2 Answers 2

Reset to default
2

TLDR

Don't multi-task. If that is not possible, use JIRA features to both combine the boards and keep them separate.

How does one manage scrum projects in a situation, where you have all the team involved in every project?

First off, multi-tasking is bad. Task-switching is incredibly expensive, especially in software deelopment. Working on two (or more) projects at once will just cause them both (or all) to suffer. It is a better idea to work on one, finish the work for it (whether that means finish the project or finish the sprint), and then work on another. Or, alternately, get more developers and have them assigned to different projects. Avoiding multi-tasking would solve your first two stated problems and first question.

Is there a way to have one main scrum board? Is it a good approach? Or there is other better way?

If the above is not, for some reason, possible (ie. mandated by CEO), then I see two possible solutions for this. Either you can create only a single JIRA project (which is much simpler but harms customer visibility, see below), or you can keep the projects separate but create a new board which has a filter including all projects. In JIRA, a board is just an issue filter. As such, you could, for example, create a new, empty, 'All Projects' JIRA project. By default, its board filter would be "Project = 'AP'", but it would be simple enough to change that to "Project = 'ABC' OR Project = 'DCE' ..." Or even just all issues in your entire system. At that point, you just need to create issues on their own, separate projects, but work with them in the All Projects project. This is more work, but in my opinion the better solution, because:

Our customers have access to their projects on our JIRA to be able to track progress on scrum boards. What are your thoughts on this approach?

This seems like a pretty good approach, to me. Allowing the customer as much (non-secret/sensitive) information about your business with them is the best way to improve the feedback cycle. As such, this is a valid reasoning for splitting each project into its own JIRA project. Though you could also, in theory, keep a 'Requester' custom field and make new Projects/Boards based on the Requester field, that is more or less just a different approach to what I suggested above, just even more work.

Do you have maybe some good tips/tricks?

A very vague question that I cannot answer, beyond what I have already provided above.

[We face] A lot of delays because of emerging, unexpected tasks from maintenance part. It's not an unusual situation to drop the current work and go fight the fire with everyone we got on deck.

First, unless these are absolutely critical, stuff is on fire maintenance tasks, they should be vetted and prioritized by the Product Owner, rather than just stuffing them immediately into the Sprint. Second, if they do need to go into the Sprint immediately, then something else needs to be taken out. If you can take something out for the same customer, that's ideal. If you cannot and thus a different customer's work needs to be sacrificed, there is already an existing question on PMSE that deals with this issue. (Which I cannot find at the moment, so if someone could find it and add a link in a comment, that would be great)

Improve this answer
0

I work in a similar environment. The best approach we have come up with is the following:

  • Have people attend one, absolute max two, stand-up meetings per day. You might need to shuffle developers between projects to achieve this. It's easy for them to become frustrated with agile if they perceive that it's all about useless meetings.
  • Group into a single kanban board all the applications that have a very low volume of work and/or are in maintenance mode, and hold a single daily stand-up for all the developers on those projects. Holding all of the scrum meetings is not effective with many tiny, slow-moving projects.
  • As much as you can (and this is not always possible), "drum up" work for the remaining projects so that the developers have enough in the pipeline to be able to loosely plan a few sprints ahead. You might do this by meeting with your customers to discuss new features or fixes, or internal improvement initiatives like refactoring, adding unit tests, or upgrading the frameworks you use.
  • As far as licensing permits, give everyone in the company and all your stakeholders at least read access to your issue tracking system. (Whether you use Jira, Agile Central, or something else is secondary.) This will increase transparency both internally and externally, and decrease onboarding time for anyone in your company who wants to join one of your projects.
  • Empower developers to decide what projects they want to work on, how they want to run the meetings, which tasks should be done and which are not valuable enough, etc. If the team is young or inexperienced in agile, you might need to make most decisions yourself while team learns to self-organize, but it is much better for all involved (including you; it will make your job a lot easier!) if they take more ownership of their work. Once they own the work, hold them accountable; if they do not formally report to you, talk with your manager so he/she holds them accountable.

Good luck!

Improve this answer

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.