Re: [Pulp-dev] Roadmap Challenges

[Dana Walker]

I agree with Ina regarding some form of deadline to keep issues from
falling by the wayside.  I know we're not *really* doing Agile, but both
Kanban and Scrum have points or "pull from the top of the stack" features
to ensure that less appealing issues are not passed up repeatedly.  I see
it kind of like our "priority" dropdown but instead of "High, Medium, Low"
it's more like "age" with "Needs attention, Average, Newly Added" or
something.  Not sure how best to track that.  Perhaps when doing a sprint
review, anything that carries over to the next sprint gets moved up a level
in this way, even if only in the description if there's no useful dropdown
available in Redmine.  Maybe there's a time like with grooming/triage,
where midsprint we re-assess tickets we've committed to?

We do a good job of prioritizing severity, but I saw someone on IRC mention
recently that they wondered how to get attention brought to a less severe
issue that just lingers over time.  This might be a way to improve our
backlog handling.

--Dana

Dana Walker

Associate Software Engineer

Red Hat




On Tue, Apr 10, 2018 at 7:39 PM, Ina Panova  wrote:

> W/r to stakeholders needs. We have dedicated people on our team who
> closely work with the stakeholders, therefore both of the parties are in
> agreement on:
>
> 1) what needs to get done
> 2) by when #1 needs to get done
>
> In my understanding if there are some uncertainties about some work then
> 1) it was not prioritized 2) it was not brought to the both parties
> attention.
>
> I agree with Jeff that with Redmine Story we were successfully being able
> to describe, design and plan.
> In addition to the sub-tasks for commits tracking we have the associated
> revisions.
>
> What i agree with is what brought up Robin - it is not efficient to put on
> the sprint work and then let it be there for months.
> Maybe would be a good idea for every work that is groomed to set a
> deadline - we can speak in terms of time, sprints, releases, whatever we
> are comfortable with.
> This way, when we promise to commit to something as a team, we make sure
> that it gets picked up and worked on, and we do not leave/pospone it be
> there for X amount of time because maybe it does not really not look
> appealing.
>
>
>
>
> 
> Regards,
>
> Ina Panova
> Software Engineer| Pulp| Red Hat Inc.
>
> "Do not go where the path may lead,
>  go instead where there is no path and leave a trail."
>
> On Tue, Apr 10, 2018 at 9:40 PM, Jeff Ortel  wrote:
>
>> From a tooling perspective:
>>
>> we have had good success in the past with fully defining and designing a
>> feature in a Redmine Story.  The story (description) provides a good way to
>> capture (and edit) the overall design and (comments) support a discussion
>> history.  Then, the implementation can be broken down and tracked by
>> related sub-tasks which are aligned to sprints and cross core/plugin
>> boundaries.  The feature is complete when all the implementation tasks are
>> complete.
>>
>>
>> On 04/06/2018 02:00 PM, Robin Chan wrote:
>>
>> Brian,
>>
>> To bring this back to your original question, here are some comments in
>> line.
>>
>> Agree w/#1 - I have observed a few different ways that this problems has
>> been solved by developers. The requirement here is "I need a way to
>> understand all the work and deliverables associated with a feature." This
>> question comes down to how do we track of deliverables. This is I think
>> secondary and not as much of a problem as the next question.
>>
>> #2 - This is essentially a question of planning deliverables. Your
>> descriptions is "how will someone know if a feature is committed to"? I
>> think full planning is not necessary for commitment. I believe that "full
>> planning" part could go in #1 in terms of tracking status. I think the
>> question is actually "how will someone know if a feature is committed to
>> and when it is committed by" - addition of a time or time frame.
>>
>> In my experience, feature work generally went like this:
>> 1. Define feature/problem to be solved.
>> 2. Investigate:
>> - refine requirements/problem definition
>> - do enough design or planning of tasks to come up with estimate of
>> work
>> 3. Commit to work or not
>> 4. execute along list of tasks, refine list as you learn.
>>
>> Steps 1-3 is part of roadmap planning (higher level planning) and #3-4 is
>> sprint planning.
>>
>>
>> I think the problem with using the sprint field as we have used it, is
>> that if you add something to a sprint, the Scrum definition would lead
>> people to assume that the team is committing to it at the end of a defined
>> sprint period. We do not. This major departure from industry standard does
>> not serve us well in my opinion. We have kept items on sprints for many
>> months and then removed it. Even if we were able to convince folks that our
>> definition of sprint was "our next few 

Re: [Pulp-dev] Roadmap Challenges

[Ina Panova]

W/r to stakeholders needs. We have dedicated people on our team who closely
work with the stakeholders, therefore both of the parties are in agreement
on:

1) what needs to get done
2) by when #1 needs to get done

In my understanding if there are some uncertainties about some work then 1)
it was not prioritized 2) it was not brought to the both parties attention.

I agree with Jeff that with Redmine Story we were successfully being able
to describe, design and plan.
In addition to the sub-tasks for commits tracking we have the associated
revisions.

What i agree with is what brought up Robin - it is not efficient to put on
the sprint work and then let it be there for months.
Maybe would be a good idea for every work that is groomed to set a deadline
- we can speak in terms of time, sprints, releases, whatever we are
comfortable with.
This way, when we promise to commit to something as a team, we make sure
that it gets picked up and worked on, and we do not leave/pospone it be
there for X amount of time because maybe it does not really not look
appealing.





Regards,

Ina Panova
Software Engineer| Pulp| Red Hat Inc.

"Do not go where the path may lead,
 go instead where there is no path and leave a trail."

On Tue, Apr 10, 2018 at 9:40 PM, Jeff Ortel  wrote:

> From a tooling perspective:
>
> we have had good success in the past with fully defining and designing a
> feature in a Redmine Story.  The story (description) provides a good way to
> capture (and edit) the overall design and (comments) support a discussion
> history.  Then, the implementation can be broken down and tracked by
> related sub-tasks which are aligned to sprints and cross core/plugin
> boundaries.  The feature is complete when all the implementation tasks are
> complete.
>
>
> On 04/06/2018 02:00 PM, Robin Chan wrote:
>
> Brian,
>
> To bring this back to your original question, here are some comments in
> line.
>
> Agree w/#1 - I have observed a few different ways that this problems has
> been solved by developers. The requirement here is "I need a way to
> understand all the work and deliverables associated with a feature." This
> question comes down to how do we track of deliverables. This is I think
> secondary and not as much of a problem as the next question.
>
> #2 - This is essentially a question of planning deliverables. Your
> descriptions is "how will someone know if a feature is committed to"? I
> think full planning is not necessary for commitment. I believe that "full
> planning" part could go in #1 in terms of tracking status. I think the
> question is actually "how will someone know if a feature is committed to
> and when it is committed by" - addition of a time or time frame.
>
> In my experience, feature work generally went like this:
> 1. Define feature/problem to be solved.
> 2. Investigate:
> - refine requirements/problem definition
> - do enough design or planning of tasks to come up with estimate of
> work
> 3. Commit to work or not
> 4. execute along list of tasks, refine list as you learn.
>
> Steps 1-3 is part of roadmap planning (higher level planning) and #3-4 is
> sprint planning.
>
>
> I think the problem with using the sprint field as we have used it, is
> that if you add something to a sprint, the Scrum definition would lead
> people to assume that the team is committing to it at the end of a defined
> sprint period. We do not. This major departure from industry standard does
> not serve us well in my opinion. We have kept items on sprints for many
> months and then removed it. Even if we were able to convince folks that our
> definition of sprint was "our next few sprints" of work, we don't have any
> accountability that we are actually keeping our commitment here and the
> folks wanting something on the sprint don't have any idea if something
> added to a sprint will be there in 3 weeks or 12 weeks. I think others in
> software are reasonable in understanding that software deliveries aren't
> going to be there until they are, but I think our immediate focus on what
> is in process (impending delivery/next build) and on some of the larger
> deliveries.
>
> Robin
>
> On Thu, Mar 29, 2018 at 3:13 PM, Brian Bouterse 
> wrote:
>
>> I want to start a discussion around how Pulp does roadmap planning and
>> some of our current challenges. This is the pre-discussion part of a future
>> PUP. I want to collaborate on characterizing the problems first before we
>> discuss solutions.
>>
>> # The surface problem statement
>>
>> It very difficult for external stakeholders to answer some simple
>> questions about any given feature:
>>
>> * How would a user use this feature exactly?
>> * Is it completed? If not, how much is left to do?
>> * Which release is this going in?
>> * Has this feature been fully planned and accepted as a committed to
>> piece of work?
>>
>> # deeper problems
>>
>> I believe there are two deeper problems contributing to the problem 

Re: [Pulp-dev] Roadmap Challenges

[Jeff Ortel]

From a tooling perspective:

we have had good success in the past with fully defining and designing a 
feature in a Redmine Story.  The story (description) provides a good way 
to capture (and edit) the overall design and (comments) support a 
discussion history.  Then, the implementation can be broken down and 
tracked by related sub-tasks which are aligned to sprints and cross 
core/plugin boundaries.  The feature is complete when all the 
implementation tasks are complete.


On 04/06/2018 02:00 PM, Robin Chan wrote:

Brian,

To bring this back to your original question, here are some comments 
in line.


Agree w/#1 - I have observed a few different ways that this problems 
has been solved by developers. The requirement here is "I need a way 
to understand all the work and deliverables associated with a 
feature." This question comes down to how do we track of deliverables. 
This is I think secondary and not as much of a problem as the next 
question.


#2 - This is essentially a question of planning deliverables. Your 
descriptions is "how will someone know if a feature is committed to"? 
I think full planning is not necessary for commitment. I believe that 
"full planning" part could go in #1 in terms of tracking status. I 
think the question is actually "how will someone know if a feature is 
committed to and when it is committed by" - addition of a time or time 
frame.


In my experience, feature work generally went like this:
1. Define feature/problem to be solved.
2. Investigate:
    - refine requirements/problem definition
    - do enough design or planning of tasks to come up with estimate 
of work

3. Commit to work or not
4. execute along list of tasks, refine list as you learn.

Steps 1-3 is part of roadmap planning (higher level planning) and #3-4 
is sprint planning.



I think the problem with using the sprint field as we have used it, is 
that if you add something to a sprint, the Scrum definition would lead 
people to assume that the team is committing to it at the end of a 
defined sprint period. We do not. This major departure from industry 
standard does not serve us well in my opinion. We have kept items on 
sprints for many months and then removed it. Even if we were able to 
convince folks that our definition of sprint was "our next few 
sprints" of work, we don't have any accountability that we are 
actually keeping our commitment here and the folks wanting something 
on the sprint don't have any idea if something added to a sprint will 
be there in 3 weeks or 12 weeks. I think others in software are 
reasonable in understanding that software deliveries aren't going to 
be there until they are, but I think our immediate focus on what is in 
process (impending delivery/next build) and on some of the larger 
deliveries.


Robin

On Thu, Mar 29, 2018 at 3:13 PM, Brian Bouterse > wrote:


I want to start a discussion around how Pulp does roadmap planning
and some of our current challenges. This is the pre-discussion
part of a future PUP. I want to collaborate on characterizing the
problems first before we discuss solutions.

# The surface problem statement

It very difficult for external stakeholders to answer some simple
questions about any given feature:

* How would a user use this feature exactly?
* Is it completed? If not, how much is left to do?
* Which release is this going in?
* Has this feature been fully planned and accepted as a committed
to piece of work?

# deeper problems

I believe there are two deeper problems contributing to the
problem above.

1. Any given feature is typically spread across multiple Redmine
tickets. There may be the first implementation, followup changes,
adjustments, bugfixes, reworks, docs followups, etc. This makes it
practically hard to have the information necessary to answer the
first 3 questions ^.

2. Devs of core or a plugin have no clear way to clearly signal
that a feature has been fully planned and is committed to. The
'sprint' field has been used heretofore, but the recent feedback
suggests that mechanism may not be the best way to indicate that
work has been fully planned and accepted. We need a clear way to
answer the last question ^.

Do you agree or disagree with these problem statements? Do you
have anything to add about the problem statements?

Thanks!
Brian

___
Pulp-dev mailing list
Pulp-dev@redhat.com 
https://www.redhat.com/mailman/listinfo/pulp-dev





___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev


___
Pulp-dev mailing list
Pulp-dev@redhat.com

Re: [Pulp-dev] Roadmap Challenges

[Milan Kovacik]

I'd also like to propose formal Project Technical Lead and a formal
Project Community Lead roles to be able to decide in case of competing
(technical) ideas or planning priorities.
These would have to be time-boxed (half a year) and folks would elect
the leader for a period based on leader's program, such as focus on
particular goals for instance testing or refactoring.
Any single person would be able to perform either the Community or the
Technical Lead role in any given period but not both at the same time.
The Community Lead role would take care for organizing the Technical
Lead elections and vice versa, the Technical Lead would take care
about organizing the Community Lead elections.
The electorate would be the active contributors for both the roles.
The candidates would be the active contributors too.

This would open up the decision making process for anyone from the
community, would encourage transparency, accountability and
responsibility and would allow us to come to a decision on competing
(technical) ideas or planning issues in case we'd got stuck.

Cheers,
milan

On Mon, Apr 2, 2018 at 8:38 PM, Brian Bouterse  wrote:
> I agree the decision process for core itself needs discussion. For now, I'm
> only able to offer facilitating a convo that focuses on the communication
> aspects not the decision process. I would like to improve the transparency
> into the features that will and won't be in any given release for our
> stakeholders. I hope we do discuss decision process as its own discussion;
> it's certainly deserving of a pup of its own.
>
> For the communication issues, soon I will share a basic outline of one way
> we could use Redmine for release planning. This would be a starter idea
> towards a solution for us to modify together.
>
>
>
> On Mon, Apr 2, 2018 at 9:08 AM, Austin Macdonald  wrote:
>>
>> I agree with the problems that Brian listed, but I hope we can focus on
>> the decision making process itself in addition to how those decisions are
>> communicated.
>
>
>
> ___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>

___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Roadmap Challenges

[Brian Bouterse]

I agree the decision process for core itself needs discussion. For now, I'm
only able to offer facilitating a convo that focuses on the communication
aspects not the decision process. I would like to improve the transparency
into the features that will and won't be in any given release for our
stakeholders. I hope we do discuss decision process as its own discussion;
it's certainly deserving of a pup of its own.

For the communication issues, soon I will share a basic outline of one way
we could use Redmine for release planning. This would be a starter idea
towards a solution for us to modify together.



On Mon, Apr 2, 2018 at 9:08 AM, Austin Macdonald  wrote:

> I agree with the problems that Brian listed, but I hope we can focus on
> the decision making process itself in addition to how those decisions are
> communicated.
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Roadmap Challenges

[Austin Macdonald]

I agree with the problems that Brian listed, but I hope we can focus on the
decision making process itself in addition to how those decisions are
communicated.
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Roadmap Challenges

[Milan Kovacik]

Brian,

thanks for the proposal!
I've been considering a similar one for some time.

On Thu, Mar 29, 2018 at 9:13 PM, Brian Bouterse  wrote:
> I want to start a discussion around how Pulp does roadmap planning and some
> of our current challenges. This is the pre-discussion part of a future PUP.
> I want to collaborate on characterizing the problems first before we discuss
> solutions.
>
> # The surface problem statement
>
> It very difficult for external stakeholders to answer some simple questions
> about any given feature:
>
> * How would a user use this feature exactly?
> * Is it completed? If not, how much is left to do?
> * Which release is this going in?
> * Has this feature been fully planned and accepted as a committed to piece
> of work?
>
> # deeper problems
>
> I believe there are two deeper problems contributing to the problem above.
>
> 1. Any given feature is typically spread across multiple Redmine tickets.
> There may be the first implementation, followup changes, adjustments,
> bugfixes, reworks, docs followups, etc. This makes it practically hard to
> have the information necessary to answer the first 3 questions ^.
>
> 2. Devs of core or a plugin have no clear way to clearly signal that a
> feature has been fully planned and is committed to. The 'sprint' field has
> been used heretofore, but the recent feedback suggests that mechanism may
> not be the best way to indicate that work has been fully planned and
> accepted. We need a clear way to answer the last question ^.
>
> Do you agree or disagree with these problem statements? Do you have anything
> to add about the problem statements?
>

I'd add that many a time, an e-mail based technical discussion gets
messy and unfolds in multiple branches over multiple months.
I'd like to propose we adopt a Technical Specification concept, living
in a separate GitHub repo, similar to the PUP process.
This would take advantage of our review process, preferably requiring
multiple (core) reviewers acks before merging, allowing Redmine to be
used for planning/tracking the (design) work.
I think it's easier to manage the life-cycle of  a larger Technical
Specification in a revision system document than an e-mail thread and
a single Redmine issue.
It also helps (feature) documentation and provides context.


> Thanks!
> Brian
>
> ___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>

Cheers,
milan

___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev