0

As a common practice followed by agile team members using agile methods(scrum, kanban etc), they volunteers/sign-up/pick-up/self-select tasks from the backlog using Jira/Trello/etc.

What I am interested in is knowing is that what are the challenges associated with this approach of self-selection.

I'm sure agile practitioners encountering situations where multiple people wanting same tasks, all tasks looking repetitive, similarly, if some critical issue comes up, then you see a task assigned to you directly. I'm sure in a real world there would be many cases.

Can you please share some of your experiences to support or against this?

closed as too broad by gnat, Robbie Dee, Thomas Owens Jan 24 '17 at 13:59

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • I think you're missing out that most teams have a manager/lead that oversees everything and makes sure that everything is actually picked up & followed through on. – Sean McSomething Jan 25 '17 at 19:33
  • True, thinking of teams which are more self-directed with no leads and not necessarily following scrum practices, could be some hybrid methods. – user2822707 Jan 26 '17 at 9:13
3

Since you are asking for experiences, mine is that it has never been an issue. I've worked on half a dozen different scrum teams over the past decade and in the each case there were simply never any problems.

We never just assigned a task to someone else without their input, so no one ever "[saw] a task assigned to you directly". At least, not that I can recall. That's simply not how things are done when following scrum principles.

  • Thank you Bryan for your reply. Would you mind sharing some details of the teams your referring here, I mean were they all cross-functional people? – user2822707 Jan 25 '17 at 9:50
  • @user2822707: none were truly cross-functional. They were all composed of both testers and developers, with a mix of senior and junior level people. – Bryan Oakley Jan 25 '17 at 12:42
  • Thanks for your reply on this.This brings another question.For such teams where we have mix of testers and developers , is it a common practice that tasks like bug-fixes or testing related work will only be picked by testers only or developers[juniors+seniors] pick them too. – user2822707 Jan 26 '17 at 9:01
  • I'm sorry if these are very common questions, but I have no experience of agile so either it's readings or what I hear randomly hear from people which help me to perceive how this is practiced actually in industry and secondly wat's the team size and the variety of work with your projects is something which remains same more or less or varies quite often so in other words product based or diff projects. – user2822707 Jan 26 '17 at 9:01
3

The retrospective system is relatively efficient at sorting any challenges out. People tend to specialize a little on topics you are better at or more interested in, and sometimes you still end up with tasks you don't really like just because you're the least busy when it comes in, but if that's happening too often, you bring it up in the next retrospective, the team comes up with good solutions, and you move on with your life.

Also, experienced agile teams will recognize potential problems early and take preemptive steps to correct them before they become issues that need addressing in retrospectives. For example, we recently started migrating to a new technology that I had done most of the early research and recommendation on. I started out volunteering for most of the tasks, but recognized I was starting a self-perpetuating cycle where the longer I did most of the tasks, the more I would be the best one qualified to do the tasks, so I started pair programming instead, and soon the entire team was up to the same speed.

I don't want to paint too rosy a picture, I know not every team naturally has experiences as good as mine has been, but it can be with some coaching.

  • Thank you Karl, knowing that is really useful.Feel welcome to share experiences relative to this self-selecting practice, exploring it for my research topic. – user2822707 Jan 25 '17 at 9:46
0

I suggest reading the book: The Year Without Pants WordPress.com and the Future of Work

Word Press is described as being open source, agile, having a flat corporate structure (The author is the first middle manager.), and allowing developers to select features to work on and bugs to fix. It has worked for them for the most part, but there are some holes.

These are the shortcomings the author found:

  1. Some tasks get avoided for many reasons and stay on the list forever.
  2. It's difficult to put together a team and have them coordinate their efforts to work on very large and complex projects with many parts.
  3. Users can have a different/inconsistent experience in different parts of the application, if there isn't any over site, coordination or someone going out of their way to make them the same.

You have to out-weigh these with the hopeful benefits of employee satisfaction through having some control over what they do on a given day. Get them to organize as a team, take on a large project and still manage themselves.

For the little things no one wants to do, someone has to step in place and try to get someone to volunteer or at least be willing to be persuaded.

Get teams and members to agree on someone being in charge with keeping things consistent, not repeating things, etc. They need to be more of a referee than having any kind of absolute power with no input from everyone else.

Good luck, it's difficult to keep things under control without everyone thinking they're being controlled.

  • I haven't read the book. How can tasks "stay on the list forever"? You can't finish a sprint unless all the tasks are done, so do they never finish sprints? – Bryan Oakley Jan 24 '17 at 13:54
  • @BryanOakley - Although the OP mentioned Agile, Kanban was included. I don't think they always have a sprint, but a backlog was mentioned. I guess this applies to things that never make it to the backlog? – JeffO Jan 24 '17 at 14:13
  • @BryanOakley How so? The sprint ends, and remaining tasks are rescheduled (if they are still important). Or perhaps they never get planned as part of a sprint. – Jacob Raihle Jan 24 '17 at 15:49
  • @JacobRaihle: Scrum is designed such that you should complete all the tasks within a sprint. While it's normal to carry over a task or two once in a while if you underestimated the amount of work, if you carry a task beyond one additional sprint, you're doing something wrong. There's no good scenario in scrum where a task stays on the board more than two sprints. If nothing else, you need to realize that the task clearly isn't important, and nott include the task in further sprints. – Bryan Oakley Jan 24 '17 at 15:54
  • 1
    @BryanOakley then "the list" probably refers to their backlog, and it stays there forever because no one wants to work on it. – Jacob Raihle Jan 24 '17 at 15:56
0

There can be occasional glitches with the system, but the beauty of the methodology is that the issues get ironed out in fairly short order with stand ups, retrospectives and the like.

Some issues I've seen:

Over-committing

If there is a sequence of tasks that naturally lead into each other, it can be tempting for a developer to block them all out to reduce overhead in handing over tasks.

Solved by: Limiting allocated tasks to work in progress

Blocked work

Some developers may pick work within their skill area but this has a dependency on other tasks in the sprint so they are held up from the start or can only make minimal progress.

Solved by: Proper grooming of tasks so that priorities are clear from the outset

Skill shortage

There may be tasks remaining that developers aren't skilled to do

Solved by: Absorbing the time with the understanding that this will benefit later sprints. Spreading the knowledge ahead of time can also help with this.

Poorly defined

Some tasks may need further grooming or other work to get started so although they need doing, developers are reluctant to pick them as it will take time to get traction.

Solved by: Proper grooming of tasks

  • Thank you Robbie, this is really helpful.But can you plz share your experiences with handling such situations, may be what exactly was done to overcome the issues you listed. – user2822707 Jan 25 '17 at 10:21
  • @user2822707 I've added some solutions from my past experiences - hope this helps – Robbie Dee Jan 25 '17 at 15:46
  • So nice of you to share the solutions,Thanks a lot. – user2822707 Jan 26 '17 at 9:02

Not the answer you're looking for? Browse other questions tagged or ask your own question.