linaro-project-management team mailing list archive

[Zach Pfeffer <zach.pfeffer@xxxxxxxxxx>]

On 4 May 2012 01:56, Ilias Biris <ilias.biris@xxxxxxxxxx> wrote:
> Hi
>
> Thanks for the feedback! Some clarifications inline, mind you the
> recurring work issue deserves a separate thread.
>
> On 03/05/12 19:31, Zach Pfeffer wrote:
>> Feedback:
>>
>> 1. The Linaro information model needs to be simplified or it needs a
>> different visualization.
>
> What part of it was too complex? As information models go [1] this is
> the simplest form I could draw. Perhaps remove the top/bottom parts and
> just leave the JIRA/Launchpad halves to the model - is that what you had
> in mind?

Maybe "too complex" is not the right critique. Some specifics:

1. What does the line between Epic and Blueprint mean?
2. Do the colors of the boxes mean something?
3. Why list Launchpad and Jira?
4. If the goal is an Epic, it seems more intuitive to have it listed
at the top and have everything else "underneath it."

>>
>> 2. Wouldn't it be simpler to just ditch Launchpad, and run everything
>> out of Jira?
>>
>
> Perhaps I will echo what Ricardo replied but add a bit more of my
> thinking here:
>
> I agree that fewer tools is better. However, before we can answer the
> question you ask we should understand all the requirements we have for
>
> - Card lifecycle management and Kanban
> - Work breakdown and Planning releases
> - Reports, monitoring, estimates
>
> LP is used not only for work breakdown and planning releases - it is
> also used to handle bugs and code and PPAs.
>
> So for the long term I believe consolidating into 1 tool is the way to
> go, but we need to approach this in phases to make sure we do not lose
> in terms of support to do our work. We are just coming through the first
> phase, making sure Jira can replace papyrs and kanbantool and that it
> hooks to our custom reports like through s.l.o. After some practical
> experience with JIRA we will look into requirements of LP and status and
> see if we can incorporate them into JIRA. At the moment I do not see
> that we could deprecate LP or status.
>
>
>> 3. This is inflexible and inaccurate:
>>
>> "Which component a card belongs to. The components reflect the Linaro
>> Engineering organisation structure - each component is an engineering
>> Working Group"
>>
>> The Android team is not a WG yet it owns cards and most of the cards
>> it would own would be composed of cross team efforts. With this we're
>> just reinforcing the Silo system we have in place.
>>
>
> A JIRA component reflect the owner of a requirement. Even if we have
> requirements shared amongst teams, we should have clear ownership. That
> is what the component in JIRA stands for.

Sure, but the point is you only use the term WG when platform and
landing teams also own epics.

So this:

Which component a card belongs to. The components reflect the Linaro
Engineering organisation structure - each component is an engineering
Working Group

Could read:

Which component a card belongs to. The components reflect the Linaro
Engineering organisation structure - each component is an engineering
Working Group, Landing Team or Platform Team.

> We could have silos with or without JIRA components. What JIRA supports
> does not dictate how we communicate and agree at blueprint or work item
> level about work-splits across teams.
>
> I can change the wording to make this point clear, though in my mind it
> is obvious.

Actually, to support non-silod development I wouldn't even list a WG,
LT or Platform. I would simply list a champion and project. Look at
big.LITTLE.

>> 4. Can you remove the stipple marks from the flow diagram?
>>
>
> Yup!
>
>> 5. We still need some way to capture recurring work.
>>
>
> The recurring work elements are part of one's work and they do provide
> value.
>
> Thinking aloud here, please chime in to debug my thinking.
>
> Related to recurring work, we can either
> - use cards and follow the same process OR
> - we could introduce a new issue type,  different than the current
> "roadmap card" in terms of the workflow process it follows. Let's call
> it the "recurring work card" (RWC). An RWC would get still the TSC
> approval at the beginning, but would not necessarily depend on more TSC
> reviews after that, provided that the deliverables are signed off by eg
> OPSCOM.
>
> For example handling the recurring release-related tasks could be an
> RWC, get planned/estimated and presented to the TSC along with the ret
> of a team's scope for the upcoming cycle. The approval needed there is
> over the planned usage of resources - how many folks over how much time
> each month (Estimates). However, once approved at TSC for the cycle, the
> deliverables themselves need not be approved by the TSC - those would be
> the monthly recurring updates to the release, for example, and OPSCOM
> would follow up on those in order to resolve impediments and help with
> correction next time around.
>
> Why bother having the recurring elements linked to RWCs?  Because that
> helps visualize how much a group is doing as recurring work vs
> introducing new functionality. My understanding is that the goal should
> be to kill off out-of-sight-out-of-mind management. It behooves you to
> visualize as much as you can - so it follows that to be successful we
> would need monitoring in place in order to identify the balance of
> resources used for RWCs vs normal Cards.
>
> I cannot claim to have the complete answer for the monitoring part - I'd
> like to think of the RWCs as tags to be associated with blueprints or
> bugs that are done repeatedly.
>
> Any other ideas?

I think  these are good ideas. As long as the recurring work shows up
on some dashboard, in front of the TSC at some point, and they can
just say, yup, still looks good and we can show that we completed the
recurring work then I'm cool with any implementation (though having
everything in Jira would be my vote, as I've noted before)

>> 6. There's nothing about how tracking will be communicated - i.e. how
>> techleads should communicate how a card is going via BP and WIs.
>>
>
> Related to the card status updates there is something mentioned:
>
> https://wiki.linaro.org/OPSCOM/RoadmapProcessWithJIRA#Bi-Weekly_status_update

Sure, but we still don't have the drill down from:

Epic to Card to BP to WI and Bug.

That's what I'm getting at and what I'm suggesting may be easier if
everything moves into Jira.

>
>
>> On 2 May 2012 00:23, Ilias Biris <ilias.biris@xxxxxxxxxx> wrote:
>>> Hello folks
>>>
>>> Since there was no comment on this write-up, I will move it under the
>>> OPSCOM wiki area, today. Feel free to send your feedback if you have any.
>>>
>>> Cheers,
>>> Ilias
>>>
>
>
> [1]
> http://scalingsoftwareagilityblog.com/agile-enterprise-requirements-information-model-subset-for-agile-project-teams/
>
>
>
>>>
>>> On 26/04/12 04:09, Ilias Biris wrote:
>>>> Hello
>>>>
>>>> I have put together a first draft of the roadmap process as implemented
>>>> in JIRA. The draft can be found in
>>>>
>>>> https://wiki.linaro.org/IliasBiris/RoadmapProcessWithJIRA
>>>>
>>>> It describes the Linaro high-level  information model regarding JIRA and
>>>> Launchpad artifacts (eg cards vs blueprints) and also shows how the card
>>>> workflow looks like in JIRA (also showing which user types have access
>>>> to the various transitions available).
>>>>
>>>> If you would like to review this page and give feedback I would be
>>>> grateful. Any questions or issues that you may have are welcome. Once
>>>> this is updated based on comments I receive it will be moved under
>>>> https://wiki.linaro.org/Process/ to serve as more "formal" document.
>>>>
>>>> Note there are some sections at the end of the document which are not
>>>> filled in yet, those are going to be added by the end of the week,
>>>> however their absence does not need to stop this RFC from going out.
>>>>
>>>> Best regards,
>>>>
>>>
>>>
>>> --
>>> Ilias Biris ilias.biris@xxxxxxxxxx
>>> Project Manager, Linaro
>>> M: +358504839608, IRC: ibiris Skype: ilias_biris
>>> Linaro.org│ Open source software for ARM SoCs
>>
>>
>>
>
>
> --
> Ilias Biris ilias.biris@xxxxxxxxxx
> Project Manager, Linaro
> M: +358504839608, IRC: ibiris Skype: ilias_biris
> Linaro.org│ Open source software for ARM SoCs



-- 
Zach Pfeffer
Android Platform Team Lead, Linaro Platform Teams
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog