Re: [agile-usability] Ownership outside of the SCRUM team
- Hello, Robert. On Saturday, October 25, 2008, at 10:35:21 PM, you
> Interesting. I can see both points as plausible,Yes. We need to observe that when people are shared across projects,
> but the second (full time on the team) seems problematic.
> It depends on the size of the project, of course, but when
> we are talking about all the kind of people involved, not just developers,
> it seems to suggest that small projects would either do without some
> necessary skills, or underutilize some expensive people.
> For example, marketing people and graphic artists: I can see
> many small projects needing some of both such skills, but
> often not enough to justify full time assignment.
both the projects and the persons quite likely may be operating less
effectively than they might. Often, "resource" sharing is undertaken
without a clear understanding of its costs. That's not ideal either.
> I do agree it's a difficult matter, but I don't see an easy answer.I don't think this work would be very interesting if the answers
were easy. However I think the best answers are more simple than the
answers we usually wind up with. :)
I'm not bad, I'm just drawn that way. -- Jessica Rabbit
- Ron Jeffries wrote:
Hello, Robert. On Saturday, October 25, 2008, at 10:35:21 PM, you wrote:
It depends on the size of the project, of course, but when we are talking about all the kind of people involved, not just developers, it seems to suggest that small projects would either do without some necessary skills, or underutilize some expensive people. For example, marketing people and graphic artists: I can see many small projects needing some of both such skills, but often not enough to justify full time assignment.
Yes. We need to observe that when people are shared across projects, both the projects and the persons quite likely may be operating less effectively than they might. Often, "resource" sharing is undertaken without a clear understanding of its costs. That's not ideal either.
I think the best way to deal with this dilemma is to a) fight hard to get every important contributor physically present, and b) make sure that anybody who can't be physically present is well represented.
A team may not have a full-time graphic designer, but they could well have a UI designer, or a front-end engineer who has an appreciation for good visual design. A full-time user researcher is unlikely, but a product manager can learn when more data would help, and what results came out of recent testing. Those present can represent those who can't be, and call them in when necessary.
I do think this proxy relationship should be both explicit and personal. If a designer on a project is also representing the rest of the design department, there should be clear mutual accountability. And although the team as a whole is responsible for a good product, some individual should be the designated contact, or it's too easy for things to fall through the cracks.
Shared resources are definitely not a local optimum, but I will grudgingly concede that they can be a global one. As long as, like Ron says, the full cost of splitting is truly understood.
- Hi everyone (and a particular hello to Robert :)
Oddly, I'm doing usability on an agile team at the moment - and we're using Scrum to do it. The odd thing about the current sprint (and the first sprint of the project) is that there is only 1 item on the product backlog. There are about 5 documents for our funding committee and some infrastructure stuff to prepare for future sprints. While I can't give any feedback on the usability side yet, the documentation side seems to work very well in the environment and lets the backlog owner (who is also the product owner) really focus the resources on the team on what the team needs to do to succeed - be that get the documentation ready so we have funding into 2009, or write code.
(the organization I work for hasn't done agile in the past and has a funding model more suitable for waterfall development projects. However, we're working on helping them understand the approach and working within the constraints of the project).
TimOn Sun, Oct 26, 2008 at 9:32 AM, Ron Jeffries <ronjeffries@...> wrote:
Hello, Robert. On Saturday, October 25, 2008, at 4:19:36 PM, you
wrote:I prefer that the product backlog contain only software items. Teams
> In the approach you describe,
> * is all work done organized as stories/backlog-items, even those which are
> distant from user interaction (e.g. estimate viable market size for
> release 1)?
that put other stuff on the backlog seem to be the ones who can't
ever get any software done.
Using a backlog for other activities seems to me to be in general a
good idea, such as remembering to buy socks. But teams who put
sock-buying on an even par with software get in trouble. Does this
suggest more than one backlog? Could be ...
Kei te kōrero tiki au. Kei te kōrero tiki koe. Ka kōrero tiki tāua. Kōrero ai tiki tāua.
We've used this concept of separate backlogs for different subteams on some projects. For example, a software development backlog and a product design backlog. "Half-baked stories" went into the product design backlog and were turned into "fully baked stories" that ultimately went into the s/w dev't backlog. The PD backlog was worked by the business team, which included the product owner, several other business resources, a BA/UE person and a tester. This seemed to work pretty well as it allowed us to track the velocity of the s/w development team better than when the half-baked stories were in the main backlog. One thing it really helped was reducing the variability in the estimates because the fully baked stories were usually much better understood and much more focused on the high value portions of the half-baked stories. The two subteams were in the same room and collaborated continously so they were still part of the same team, just responsible for different backlogs.
-- Gerard Meszaros Lean/Agile Coach/Mentor/Trainer http://www.gerardmeszaros.com Author of the Jolt Productivity Award winning book "xUnit Test Patterns - Refactoring Test Code". Learn more at http://xunitpatterns.com/index.html
William Pietri wrote:
Hi, Robert. Hope you don't mind me butting in.
For the teams I work with, the main work queue is about released software. Most of the cards in that queue involve at least some amount of UI design, visual design, front-end coding, and back-end coding. Some engineering research ends up in that queue as well, either when it's large enough to have a schedule impact or has a deliverable. That deliverable is usually an estimate on some other set of cards.
Other kinds of thinking, research, and effort tend to be driven by that queue, but not kept in it. That includes engineering work, business work, and design work. A lot of people manage the schedule for that other work intuitively, but I also see separate formal queues kept for individuals or functions. E.g., one team is going to try a visible, card-based queue for product management work, so the product manager's workload is more visible, and so that some of the work can be shared.
Robert Biddle wrote:
Ok, so my next followup is this: In the approach you describe, * is all work done organized as stories/backlog- items, even those which are distant from user interaction (e.g. estimate viable market size for release 1)? * are all team members on the project full time from start to finish? I think it's an interesting idea, if so, but I'm not sure how practical the second point (above) would be. I've never seen a project run like this, by the way. Robt Ron Jeffries wrote:
Hello, Robert. On Saturday, October 25, 2008, at 3:30:42 PM, you wrote:
Just a followup question while I mull this over. Are you suggesting the situation you describe for Scrum or XP or both?
For me, both.
In particular, are you happy with people who do no programming or program testing being on the team? For example, people such as user researchers or market analysts?
Sure. They are part of the customer sub-team I should think. Ron Jeffries www.XProgramming. com www.xprogramming. com/blog Education is the ability to listen to almost anything without losing your temper or your self-confidence. --Robert Frost
------------ --------- --------- ------ Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups. yahoo.com/ group/agile- usability/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups. yahoo.com/ group/agile- usability/ join (Yahoo! ID required) <*> To change settings via email: mailto:agile- usability- digest@yahoogrou ps.com mailto:agile- usability- fullfeatured@ yahoogroups. com <*> To unsubscribe from this group, send an email to: agile-usability- unsubscribe@ yahoogroups. com <*> Your use of Yahoo! Groups is subject to: http://docs. yahoo.com/ info/terms/