Holacracy Community of Practice Archive, 2015-2019 Community Holacracy Web Site

Projects, Next-Actions, and Sprint/Product Backlog (Scrum)

Hello guys. We have a circle that runs an entire business, including software development, marketing, sales, etc. It is a business unit. We are having trouble in identifying ways to record Projects, since we use Scrum (and a Product/Sprint Backlog for all the work of the development team). 

For example, partners fill different roles, like Feature Developer and Social Media. The work done by the first one is included in the Sprint Backlog (and expressed as an User Story), whereas the second role does not perform development work and its projects can be recorded elsewhere.  My questions:

  1. Is it legal to have two different "work repos", a Sprint Backlog and a projects database? I guess not, because that would reduce clarity about prioritization. If not, do I drop the Sprint Backlog and start recording everything as projects? BTW, should I stop using Scrum? :S
  2. Can I treat my product backlog items (stories, fixes, bugs) as projects? In this case, it seems to make sense to allow the Product Owner to prioritize backlog items, but let the role-filler decide whether he/she will perform Sprint Backlog work or other projects, as soon as he/she respects the backlog prioritization. 

How do you handle this at HolacracyOne?

10 Replies
Davi Gabriel da Silva
11/11/2015
Any thoughts about this?
Christel Hofman
11/12/2015
Originally Posted by Davi Gabriel da Silva:

Hello guys. We have a circle that runs an entire business, including software development, marketing, sales, etc. It is a business unit. We are having trouble in identifying ways to record Projects, since we use Scrum (and a Product/Sprint Backlog for all the work of the development team). 

For example, partners fill different roles, like Feature Developer and Social Media. The work done by the first one is included in the Sprint Backlog (and expressed as an User Story), whereas the second role does not perform development work and its projects can be recorded elsewhere.  My questions:

  1. Is it legal to have two different "work repos", a Sprint Backlog and a projects database? I guess not, because that would reduce clarity about prioritization. If not, do I drop the Sprint Backlog and start recording everything as projects? BTW, should I stop using Scrum? :S
  2. Can I treat my product backlog items (stories, fixes, bugs) as projects? In this case, it seems to make sense to allow the Product Owner to prioritize backlog items, but let the role-filler decide whether he/she will perform Sprint Backlog work or other projects, as soon as he/she respects the backlog prioritization. 

How do you handle this at HolacracyOne?

I don't know if I understand everything but maybe you can try to put your project data in the metrics. Thinks like if you manage to deliver the results of your project at the date you promised a client, something like that. You can simply make a link to your project dashboard. Does this help you?

Davi Gabriel da Silva
11/12/2015

I don't understand... It seems that you are suggesting to capture all of the work of the development team in a single project. Is that right? 

Christel Hofman
11/12/2015
Originally Posted by Davi Gabriel da Silva:

I don't understand... It seems that you are suggesting to capture all of the work of the development team in a single project. Is that right? 

Not really, although that can also be a good idea :-). I try to suggest that you make a chart / overview with all the important projects and the data you need from these projects, so you can review them together during the 'metrics' in the tactical meeting.

Dien Kwik
11/20/2015
Hi, Davi:

We also have a circle which is somewhat cross functional (marketing, r&d,sales, production,
distribution) and we are applying Scrum principles with this circle.

We use only one sprint backlog for the entire circle, and all of the stories are user stories or spikes. Sometimes the stories feel a little forced because we put them in user story format. However, I would argue that everything we do has to improve something for the customer and none of the roles should just do something for the sake of its own role.

The Sprint backlog also mixes things that are more "marketing" in nature, or more "distribution", along with things that are "development".

Now, we may be cheating a little or not doing it right . The development itself is actually outsourced to a different circle, a development circle and this circle focuses only in development.
The "development" role in the first circle is a customer of the development circle.

(Disclaimer: We are not a software development company - we have RnD folks, but not software developers , so maybe the challenges are a bit different)

Looking at your question, perhaps you can do something similar, or have a Scrum in Scrum type of arrangement, where you create a "development" sub circle under your business unit circle, so that the development work gets separated out from all the other types of work at the business unit circle.

Then again, if you do use this arrangement, your business unit circle does not need to use scrum. It can use whatever project tracking and prioritization method it likes.

We just chose to implement (or experiment maybe the better word) scrum principles to an entire business unit circle.

Hope this reply is in line with your question.

Regards,

Dien.
Karilen Mays
12/02/2015

Are you using GlassFrog?

1. I think it is perfectly "legal" to have different repos; if there is no policy against it, you can use whatever you like. Further, you could create a policy constraining types of work to be recorded in different places.

Such as 

Project work not included in the backlog must be listed in GlassFrog (or wherever).

[This may be a borderline valid policy...so you may need some accountabilities as well, not sure.]

2. In Holacracy, if something has a discrete endpoint, or is a result/outcome and takes more than one next action then it is a project, so yeah in those cases! Our dev team and others will list certain types of dev work in progress updates to share during tactical, but not every chore or story if that makes sense.

Project definition: http://www.holacracy.org/constitution#122

Brianb
12/03/2015

This is a fascinating question David! I'd love to hear more about your experience staying true to Agile while integrating it within the Holacracy construct. The tools you are using expose these overlaps and competing processes - are there any other challenges besides the one you listed here that you have run into? 

Davi Gabriel da Silva
12/03/2015

Yes, too many challenges

Thank you for all your responses. I think we have a solution now.

We started working with a continuous flow (Kanban) in order to provide greater flexibility for role-fillers to prioritize their own work.

We have a policy that all product development work is placed in the Product Backlog and is prioritized by a Product Owner role.

Let's say Bob fills two roles: a Feature Developer and a Social Media one. We added an accountability to the Feature Developer that tells that this role must consume items from the Product Backlog. On the other hand, the Social Media stores his projects elsewhere (Asana, Glassfrog, Trello, etc). This can also be standardized via policy. 

When Bob wants to work, he has the flexibility to choose whether is most helpful to work as a Feature Developer or Social Media, since the Sprint timebox does not exist anymore (Kanban now). Before this policy, role-fillers would prioritize Product work in order to meet the Sprint Goal. 

Summarizing, we still have two work repos. Product Development work is prioritized by the Product Owner, and the rest is prioritized by the role-fillers in alignment with the Lead Link strategy.

Karilen Mays
12/04/2015

Davi - sounds like you are aware that accountabilities don't limit.

Meaning just because Feature Developer is accountable for Selecting stories from the backlog (or whatever) that doesn't limit them or other roles from doing development work based on their best judgment. In other words roles can go above and beyond accountabilities which you want. Without some constraints the developers could still just develop what they want if it serves their role's purpose.

Since with software development you do want a centralized iteration planning, either a domain for development priorities on a role - Product Owner - or the circle policy you mentioned would complete the workflow. 

Makes complete sense to evolve your process and have two separate repos and even prioritizations at play. Keep us posted!

Brianb
12/04/2015

Davi- really like how you moved to Kanban as the timboxed Sprint process was limiting!