Who assigns tasks to your developers after sprint planning?

I would recommend your team utilize pair programming. Otherwise you are enabling the knowledge/skill gap to continue to grow and you will always face this problem.

You want to share the skill and knowledge across the team, not cut it off.

Pair a 'senior' with a 'junior' and have them work together. This has many benefits.

The senior will have the knowledge and experience and the junior will have a fresh perspective and ask 'why' a lot, which will help the senior understand and learn from their own decisions.

Check out Pair Programming from XP - http://www.extremeprogramming.org/rules/pair.html

I don't think that put tasks to In Progress is a good idea. DevTeam might be confused about such manipulations. For example, you have a special column for QA on your board. Once task is developed it goes to this particular column. Imagine now that QA found an issue and they want to deliver this task back to the DevTeam. Anyway it will end up in the TODO list.

So it's better to leave assigned during sprint planning tasks in the TODO column.

Anyway, DevTeam has to be self-organised, even if some of the team members have no experience (e.g. with architecture) — accountability belongs to the DevTeam as a whole. If team understands this, people will do their best to spread tasks accordingly.

Hello Klaus,

Such developers, as far as I am concerned, should not be working on tickets that require architecturally sound design regardless of how small.

What does the development team think about this? Who is responsible for ensuring the quality of what is developed?

This is what I am planning

What is the development team planning?

An alternative approach for your problem can be to limit your ToDo column. Put all your tickets in a ‘Ready For Sprint’ column and let the team decide on maximum 2 tickets in the ToDo column. Any one junior/senior finished with his tasks helps other team member with their work. Or if that is not possible picks up one of the 2 tickets. This way tasks are worked by multiple team members and have a mix of junior and senior, work in progress is limited and juniors can learn from seniors.

I believe the above have touched on some key points.

My main area of concern is the need to maintain control and believing the manager knows who is best at a given job, allow the team to self organise.

Ensure in the DoD that code is reviewed by a suitable member, allow a member to grow and pick up what he feels capable of picking up and not what you believe he should. If a story goes back and forth between review then this should be picked up during the Retro and suitable (inspect and adapt) changes should be discussed. This may lead to pair programming or other suitable practices.

Ensure a culture is in place where issues can be called out (transparency), this is not a weakness this is a strength (having the ability to know when you need help).

Allow the mistakes to happen and learn do not put in place historic management processes.

> Where we are today, any dev can pick up any ticket. 

That's good, because work should be owned by the team and not reserved by individual developers. Moreover, team members should not have work assigned to them.

The important point is that there are responsible behaviors to be encouraged with this practice.

For example: team members should resolve impeded or blocked work before actioning another item. If nothing is impeded or blocked, then they should help other team members complete work that is currently in progress. Only if no other work is in progress should new work be brought into play from the Sprint Backlog as per the Sprint plan.

As others have indicated, limiting the amount of work in progress will encourage cross-training, and will help disseminate skills in the above manner.

The developers. The Development Team as a whole is responsible for all work items.The sprint goal is a TEAM goal, NOT a collection of individual goals. The point is to foster COlaboration, SHARED understanding and GROUP-learning. Avoid building silos. A bunch of high-performing individuals is NOT the same as a high performing team. Specialisation creates bottlenecks. Bottlenecks limit throughput. Avoid local(individual) over global(team) optimisation.

You are looking to have the right balance between keeping the self-managing spirit of the team, ensuring code quality, and helping the junior developers improving organically. There are several ways to do it, one is as follows:
1) rank the tasks in two-three categories of difficulty - if you cannot add a custom attribute for that in Jira, consider using an existing one that is not used (maybe the priority field?)
2) let the developers pick their tasks, knowing that touching the "red" ones comes with a higher challenge
3) set the expectations with the team that for the junior developers who took the challenge there will be a code review done by the seniors, and make sure they are ready to accept the kudos and also the lessons learned
4) Based on the quality of the code too, but mostly on the capacity of the juniors to accept advice and improve, the team should decide if a particular developer should be temporarily banned to tackle tasks over a particular level until he/she proves he/she can handle the learning process, or he/she can continue to try on challenging tasks, as a self-improvement benefit and ultimately for the team's. Create a spirit of "if you're nice, we will help you grow and become great, if you're arrogant you'll have to leave the island". Agile is not for people who don't want to collaborate and are not humble enough. If the team is unsuccessful in "converting" those black sheep, they will have to be assigned to different places in the organization where they fit better. An example or two of "skills redirection" would be enough for a small Scrum program (4-5 teams) to drive the behavior in the right direction.

Pair-programming and WIP should be the best practices.

In my experiences, when DT break a backlog item into tasks, in addition to the estimating of hours to do, they also evaluated the skill level required and noted to task description.

In one organization I coached, they used colorful sticky note to identify the skill level required, such as Green Level, Yellow Level, Blue Level, Red Level.

That’s a shared understanding of the team. During Daily Scrum, they discuss who and how to make tasks done with optimal velocity.

Dear Klaus,


PLEASE, listen to Aaron!

The team should be self-organizing. Nobody should be assigning tasks to someone else. Nobody should dictate approaches or solutions to them!

I mainly don’t understand why you want to propose a solution to your boss!?!

You should raise the issue at the Retrospective and have the team come up with possible solutions.
There are many ways to deal with your Issue. The team will come up with the one that best works for them.
(Maybe after first trying something that does not work as well, but that's OK!)

If you want to dictate solutions or have your boss dictate solutions. THIS is your actual issue. Your management should encourage self-management and bottom up intelligence.
You need to trust your team first, only then they will start being self-responsible!


If you want to stick to old Management style and only use the iterative incremental idea of Scum. As Tim states, pair programming is a good idea indeed.

Good luck
Sebastian


PS: If employees cannot deal with feedback, this is another issue of your management. It is the way your company deals with feedback and the feedback culture your company lives.

I agree with Sebastian and Aaron. Make sure the dev team can handle this.Accept that sometimes people will make mistakes but make sure this is discussed during the retrospective. Also, give the more junior developers the opportunity to learn and to find help if needed.

Team should pick the stories as per their strengthen i.e. Experience * skills , Agile a cross-functional and cross technical team, its TEAM goal and there is NO hierarchy, team should work together to deliver committed goals, however practically we always see impediments...

Is the Product Owner allowed to assign new tasks to the development team after da Sprint Planning ?

This is from the Scrum Guide's section describing Sprint Planning

Topic Three: How will the chosen work get done?

For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less. How this is done is at the sole discretion of the Developers. No one else tells them how to turn Product Backlog items into Increments of value.

If the Product Owner is assigning tasks, wouldn't that be telling the Developers how to work?  And how would that make the team self-organizing and self-managing?  

If the need for new work is uncovered, the Product Owner should discuss it with the Developers and come to a plan together on how to address it. Introducing new work into a Sprint might require that work already included in the Sprint Backlog will need to be removed.  Again I pull from the Scrum Guide, but this is the section that explains the Sprint.

During the Sprint:

• No changes are made that would endanger the Sprint Goal;

• Quality does not decrease;

• The Product Backlog is refined as needed; and,

• Scope may be clarified and renegotiated with the Product Owner as more is learned.

The Product Owner should not be assigning anything. The Product Owner and Developers should decide together with the understanding that no one is intentionally going to do something that causes harm. 

I am a new joiner to a scrum team as a developer, what are the expectations? Can I take any task right away thats available in the board? Or someone should assign me what’s my first task should be.

Stop starting and start finishing. Help your fellow Developers to finish the work already started, with collective focus, so value is released earlier and risk is better controlled. Then collaboratively decide what to do next so you better achieve your Sprint Goal.

I think @Sebastian (and @Aaron) said it best. Sebastian is the only one who trips over the same word as I do: trust. Trust is the foundation of Scrum. Without Trust there can be no Transparancy, Inspection or Adaptation.

When you say "... since I can trust that they do the job right." You're therefore also saying that you DON'T trust the junior developers to perform any work they might find appropriate, or to decide which items they could safely execute.

Please focus on establishing that trust, and as Aaron mentions focus on how to avoid making a mess of the code, by implementing a solid DoD, way of working and Retrospectives. They need to learn at some point...