4

...is not able to help the remaining member of the team with his tasks since he is not suitable for it?

Currently, in this scenario I allocate a new item from the backlog that my scrum member is more suited to doing and leave the remaining item for the colleague who is still behind. This is with the full consent of the development team.

Is this the correct approach?

  • 2
    "Is not able to help". I smell BS. More like "is unwilling to learn what is needed in order to be able to help". – RubberDuck Feb 15 '17 at 17:34
  • 5
    RubberDuck to add I know that there is a trend towards full stack developers, but I honestly believe at a certain point you can't be a jack of all trades. Learning back end development is more than just writing code in a back end language, it branches towards dev ops which moves towards server optimisation/scalability. On the other side, a highly trained front end developer knows how different front end frameworks work at a deeper level - angularJS, React, NodeJS etc and is more User experience oriented. – bobo2000 Feb 15 '17 at 20:23
  • 1
    I'm sure work gets done, my team are full stack, but what I have found is that the quality of work is not always great if work is completed by somebody who is a back end specialist but has average front end skills (and vice versa). It's similar to playing a footballer out of position. Sure a striker can play in midfield but would he be as amazing as Zidane? Anyway, in this instance, I don't think it would have helped since the final story is dependent on an earlier story being completed by the back end Dev. – bobo2000 Feb 16 '17 at 8:20
  • 1
    As a developer, give me a day to investigate a new bit of technology I haven't had time to look at before, and maybe train a few of my co-workers in it, and I will reward you with a more efficient development team. Developers don't usually get enough training days, and the ability to concentrate for 8 hours on a new bit of technology is much more efficient than trying to learn it in the evening. – Guy Schalnat Feb 16 '17 at 13:40
  • 1
    I'd add that it's perfectly reasonable to be "not able to help" on the other tasks simply because any task is only sub-dividable up to a point. If everyone else has their tasks/stories in hand and looks like delivering then there's little point in shoehorning another developer in to help one of them. Just give them more work, that's what you do when someone finishes what they're doing. – Grimm The Opiner Feb 16 '17 at 13:40
11

This is an excellent question and you will see a spectrum of answers which demonstrate the polar opposites of the Scrum community attitudes.

There is an official answer which is supported by the Scrum Guide and will help you pass any number of Scrum exams but has little applicability in the real world of software development.

Let me break your points down one at a time.

  1. Your closing question.

Is this the correct approach?

Always remember that doing Scrum is not the thing. Scrum is the thing that gets you to the thing. It is a framework designed to help you deliver software, it is not an end in itself. Unless you work for Scrum.

If your approach is helping to deliver working software then it is not wrong, it could just be improved slightly.

Don't approach Agility with a sense of right and wrong, it will just divide your stakeholders/customers/co-workers.

It's simply a spectrum of effectiveness.

Effective short term, effective long term.

Getting stories done now in mini silos does not mean the team are building resilience to get stories done in the future if one of the development team leaves / goes sick etc.


  1. Your underlying issue

Team member is unable to help another team member

This could be many things and is worthy of a question in it's own right.

The default response of the Scrum Community will be that cross-functional people are king but that is not always viable in practice, especially in Enterprise organisations or those with strict regulatory frameworks that need sign off. It could be that the developer has en employment contract which states his/her specific role and skillset.

The aim is a cross-functional team as much as possible but a COBOL developer does not magically become a Jenkins expert and a QA Tester does not instantly become a Java developer etc. We have to be sensible.

As a Scrum Master you should spend time with the Developer and probe their motivations. Are they opposed to learning new skills? Do they feel uncomfortable? Does the organisation and the project allow punish failure? Do they feel pressured to work on new tasks? Do they have a line manager they report to discouraging a new skillset? Are they incentivised by user story completion?

You will need to spin a few plates but you are paid to manage relationships. They are paid to manage the code pipeline.

Ask the Product Owner if they see the value in cross-functional working and can they devote some Sprint time to the Development Team to train/coach/mentor the developer? Is there capacity to have them do self-guided learning with online resources?

It's important to consider that the needs of the Scrum Team may not be in line with the career aspirations of the Developer, especially in large organisations with entrenched employees and HR. HR is on their side, no ifs, no buts. Not every Scrum Team works in a start-up environment.

My approach is to simply tell a Developer

"We will be no worse off if you simply try. Does that sound like something we can work with?"

If the answer is no then you have some tough choices to make for your recommendations.


  1. Your current approach

I allocate a new item from the backlog that my scrum member is more suited to doing and leave the remaining item for the colleague who is still behind. This is with the full consent of the development team.

Firstly, you have gained consensus from the team which is fantastic. Your direction of travel towards a self-organizing team in underway. Maintain that.

Do you feel you should allocate work though? Do it feel to you that that is the role of the Scrum Master? If you are a former Project Manager then maybe this behavior comes easily.

Ideally, the Product Owner should be continually ordering and prioritizing the backlog so that development team members can see the highest value stories at the top. If a situation arises where the team have more capacity then they can simply call a quick meeting, review the backlog and select the stories they feel are most appropriate for the Sprint taking account of the Product Owners prioritization.

Typically you will find a healthy tension between engineering stories (best practice, refactoring etc) that the Development Team wish to implement and Feature stories which the PO pushes to have done. Not always, but it's common.

Having capacity in a Sprint is an excellent chance to let the Development Team focus on those engineering tasks without disrupting the Sprint Goal.

In summary, you shouldn't assign work but encourage the team to pull from the backlog in a considered manner.

Lastly, no Scrum Team member is ever behind. They are a team. It is a team delivery.

Reinforce this. Like a relay team, the clock stops when the last man crosses the line not the first; they are not behind; they are simply demonstrating to the business more realistic expectations of what can be achieved. Timelines move, developers don't work longer hours. That's the sustainable part of Scrum.


Build a team, not a collection of individuals...and don't throw the Scrum Guide at them. It's just a PDF written by a couple of guys no smarter than yourself.

  • 1
    I don't see anything in here that contradicts the Scrum Guide, either in spirit or practice. Have you met a lot of people that are interpreting it incorrectly? – MrHinsh - Martin Hinshelwood Feb 16 '17 at 3:03
  • 5
    I have met a lot of people that forget it's a framework and approach it with zealotry. – Venture2099 Feb 16 '17 at 9:53
  • 4
    Cross-functional individual may be impractical, but cross-functional teams are never impractical. That does not mean that the team can take any task, but that all the tasks they get they can do. – MrHinsh - Martin Hinshelwood Feb 16 '17 at 14:14
  • 2
    +1 one for the relentless focus on the Development Team as a role. This is one of the pivotal changes Scrum relies on to function and be effective. – jason.t.knight Mar 3 '17 at 15:47
  • 1
    The whole notion of "scrumbut" indicates that orthodoxy in scrum is paramount. The religious zeal with which scrum proponents uphold their cause is frankly repugnant. This is a fantastic answer with more pragmatism than zeal. Thank you. – Mark C. Wallace Jun 4 '18 at 12:00
8

This is an internal problem for the Development Team and you should allow them to solve it themselves. It is absolutely not the job of the Scrum Master to allocate work, create tasks, or decide on who is best to complete work.

You should refer to the Scrum Guide for how this works, but here are some relevant points:

Development Teams have the following characteristics:

  • They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;
  • Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment;
  • Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;
  • Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis; there are no exceptions to this rule; and,
  • Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.

As long as the Development Team has the skills available within the team to do the work then you can step back and let them get on with building Working Software in the way that makes the most sense based on their composition.

If they don't have the skills it is the Scrum Masters job to facilitate providing them.

The Scrum Master serves the Development Team in several ways, including:

  • Coaching the Development Team in self-organization and cross-functionality;
  • Helping the Development Team to create high-value products;
  • Removing impediments to the Development Team’s progress;
  • Facilitating Scrum events as requested or needed; and,
  • Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.

Nowhere on here will you find that the Scrum Master assigned work to the Development Team, and indeed their job is to protect the Development Team from people trying to assign them work directly.

It sounds like you don't have a self organising team, and that each person is held individually accountable for work. This is the biggest killer to self-organisation and a blocker to gaining high performing teams.

Update:

On reflection it sounds like your Product Owner is not ordering the backlog, and that your Sprint does not have a Sprint Goal.

After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment.

You need a Sprint Goal to give the team both focus and some wiggle room in what is selected for the current Sprint. Always the Development Team selects the work that it is to complete, and the Sprint Goal gives them the direction they need if the Product Owner is unavailable.

Questions to ask in this situation:

  1. Why don't you coach the Development Team go to the Product Owner and ask them whats next?
  2. Why is the Product Backlog in such poor shape that "whats next" is not very obvious?
  3. Do you have a Sprint Goal that can guide the Development Team in making these sorts of decisions?
  4. Is the Scrum Master and the de facto Product Owner the same person?
  • 2
    Then the impediment to solve is not "assigning work" but figuring out why the team don't know what the Product Owner wants next. – MrHinsh - Martin Hinshelwood Feb 15 '17 at 17:12
  • 1
    I don't know your team, so I don't know. But "Phrased differently, same outcome" implies a cavalier attitude to the values of Scrum and a disinterest in how different ways of doing things, while achieving the same outcome, has a dramatically different long term impact on value delivery. – MrHinsh - Martin Hinshelwood Feb 15 '17 at 17:28
  • 1
    Why don't you coach the Development Team go to the Product Owner and ask them whats next? Why is the Product Backlog in such poor shape that "whats next" is not very obvious? Do you have a Sprint Goal that can guide the Development Team in making these sorts of decisions? – MrHinsh - Martin Hinshelwood Feb 15 '17 at 17:29
  • 1
    @bobo2000 it sounds like you are the Product Owner and the other guy is just an influential stakeholder. If so, then you should relinquish control of the Scrum Master role as it is a conflict of interest for both to be the same person... – MrHinsh - Martin Hinshelwood Feb 15 '17 at 18:38
  • 1
    Usually you have many Stakeholders... an important customer, the development team, an important guy from the sales field... but you only have one Product Owner who is accountable for value delivery. While ideally they have profit and loss accountability, that is not always the case. – MrHinsh - Martin Hinshelwood Feb 16 '17 at 14:16
5

When teaching and coaching new teams I work with them to make a "Decision Tree" as part of the working agreements. I teach them the basics of Kanban first and over the years I've found most teams settle on a similar decision tree.

So as I write my Agile Coach's Cookbook, this is what I'm offering as an example of a Good Practice.

In Scrum, I am done with my current task, what do I do next?

  1. We trust you, do the right thing.
  2. Is there some way I can help someone with a current task?
  3. Can I fix a bottleneck in the workflow (someplace where WIP or Cycle Time is high)?
  4. Can I work on an unstarted task on an in-progress, user story (that I can finish in the time remaining in this sprint)?
  5. Can I fix some outstanding technical debt, or make the system better?
  6. Can I start a new story in this sprint's backlog (that I can finish in the time remaining in this sprint)?
  7. Can I learn something new or improve my skills?
  8. When in doubt, see #1.

As you can see, starting something new, from the backlog, is well down the list and there should always be the caveat of "in this sprint". Slack is vital to a successful organization. Tom Demarco, management consultant and author of Slack, states "Innovation is what happens when there is slack."

  • This is a brilliant idea! – onedaywhen Jun 7 '18 at 15:42
4

... I allocate a new item ...

Please be careful with doing this. Scrum (and most Agile in general) works best as a Pull system, not as a Push system.

Additionally, be careful of accepting new work into an ongoing Sprint - doing so threatens to make the entire purpose of the Sprint estimation pointless. Any new work added to the Sprint should generally be agreed upon by the entire Development Team, as adding work to the Sprint is essentially the same as having the Dev Team commit to that work.

While adding more work to the Sprint is sometimes a valid approach (again, assuming everyone on the Development Team agrees), other options are available as well. There are many ways to make use of slack time. Pair programming (even if he is not 'suitable' for some other work, he may be able to learn by pairing up on it). Code review. Writing documentation. Independent learning/research. Performing spikes/low-priority side-projects. Et cetera.

  • New work is only taken on if the development team agrees. Actually in this instance the dev team member suggested to work on a backlog item. – bobo2000 Feb 15 '17 at 17:12
  • You should never allocate a new Item to the Development Team. The Development Team selects the work it does. – MrHinsh - Martin Hinshelwood Feb 15 '17 at 17:20
  • And they do have the final say with any work that is selected. With that said, there is a discussion otherwise they may end up going off on a tangent by implementing useless features from the backlog. – bobo2000 Feb 15 '17 at 17:27
1

You need to build a plan / road-map for this friend so he / she can, at least to some extent, contribute to other stories. In order for said plan to be successful you should align with other roles: Product Owners / Managers etc.

Just start with some small Proof of Concept / spikes and research tasks in the domain of other colleagues. Then organize some pair programming and soon you will see first results.

There are various reasons for which such a strategy might not work. If this is the case, figure out which tasks outside the backlog which are beneficial.

0

Having idle team members work on bug prevention steps such as tweaking automation tools, reviewing tests, doing root cause analysis of recently resolved defects, and revising documentation would be more effective in the long run.

For future sprints, backlog estimates may need to be revised in a different way:

For a two-week Sprint, five percent of the duration implies that each Sprint there is a half-day Product Backlog Refinement workshop. This refinement activity is not for items selected for the current Sprint; it is for items for the future, most likely in the next one or two Sprints. With this practice, Sprint Planning becomes relatively simple because the Product Owner and Scrum Team start the planning with a clear, well-analyzed and carefully estimated set of items. A sign that this refinement workshop is not being done (or not being done well) is that Sprint Planning involves 24 significant questions, discovery, or confusion and feels incomplete; planning work then often spills over into the Sprint itself, which is typically not desirable. Ending the Sprint One of the core tenets of Scrum is that the duration of the Sprint is never extended – it ends on the assigned date regardless of whether the Team has completed the work it committed to.

Establishing a baseline for commitments based off of past experience is key:

A Team typically over-commits in its first few Sprints and fails to accomplish its commitments. Sometimes it then overcompensates and under-commits, and finishes early (in which case it can ask the Product Owner for more Product Backlog items to work on). But by the third or fourth Sprint a Team has typically figured out what it is capable of delivering (most of the time), and they will meet their Sprint goals more reliably after that. Teams are encouraged to pick one duration for their Sprints (say, two weeks) and not change it. This helps the Team learn how much it can accomplish, which helps in both estimation and longer-term release planning. It also helps the Team achieve a rhythm for their work; this is often referred to as the “heartbeat” of the Team in Scrum.

Standardizing the definition of done to include code that can be measured and visualized can also help. For example:

  • Documentation - attach an image of the generated documentation to the story
  • Performance - attach benchmark results to the story
  • Accessibility - attach an accessibility report to the story
  • Usability - attach a design review commentary to the story
  • Testing - attach test reports to the story

In addition, spending time to update APIs and code that use deprecated data is always a good use of time.

References

0

I would have simply switched him to pair programming or pair him in any other task.

I think you should check out the Wikipedia article on pair programming. The Question asked is not unique but happens in many teams... two people working together will not only be more efficient but also gives an opportunity to brain storm.

  • I think you should checkout .. en.wikipedia.org/wiki/Pair_programming ..the question asked is not unique but happens in many team ..two people working together will not only be more efficient but also gives an opportunity to brain storm .. – user666 Jun 5 '18 at 12:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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