Help with Development Team problems

Hi Graham,

Don't stress it, you mention that ten sprints have passed, but don't say if you are seeing any improvements.
Have you seen a velocity occur and is it improving or getting worse ?
Scrum just doesn't happen on its own, it doesn't go from 0-200 in a few sprints.
There are external contractors on the contract, that are all senior and have been gelled for six months but none have experience in scrum, with a 30% success rate and want to take on new work.

This sounds like a coaching improvement could be made on a few fronts
SM to the team on scrum as they want to take on new work and only hitting 30%, the retrospectives if effective should
be able to work out a way forward (overestimating, problems not being resolved, non buy in, etc)
As external contractors and being part of the team should they not seek to gain more knowledge on Scrum?

SM to the management to educate on what it is that Scrum really is about, the org signed off to it.
It isn't a case of today its scrum and 60 minutes later its optimised, it takes time.
A big part of a good SM is coaching at all levels, is this being currently done?
look at the services of a SM and you can see it is a much wider scope to get the understanding.
http://www.scrumguides.org/scrum-guide.html#team-sm


Michael

What does the PO think about the quality of the product, and the technical debt that is being incurred?
- Is he or she in agreement with the team, during Planning, about what the Sprint Backlog and Goal should be?
- What does the PO have to say about product and process improvement during the Review and Retrospective?

Start making sure everybody inside and outside the team understands the basics of scrum. It's hard working if people don't understand why we need a new way of working. Your next step probably needs to be that the team starts feeling responsible and realistic about the amount of work the commit. They probably need to learn to accept their own realistic velocity.

To know the problem domain issues may be more important than to know solution domain options in your case.

Do the DT teammates trust you?
Do you focus on measuring the value delivered or velocity when management department performs performance reviews to external contractors?

Do you think the low-performing team is an attitude issue or a skill issue?

If it were attitude issue, as a ScrumMaster, as a Scrum team coach, would work with teammates to help them be a more effective team relation.

If it were a skill issue, let PO know this issue and co-work with PO to work out the issue.

If coaching doesn't work, the situation would escalate out of the Scrum team to manager. You DO NOT have "firing" or "forming" authority. Although Scrum Team is self-organization, managers have the obligation to improve the overall health and performance of the team.

In your case, understanding the problem is more important than find a solution.

Just for your reference.

Many thanks for the prompt and helpful feedback. I do have some further details clarifying some of the questions and statements received above.

1. The management has totally bought into Scrum and from the highest level i.e. the CIO and CEO. The CIO has officially defined those taking the roles within the Scrum Team and their expectations on the conduct of all members.
2. The external consultancy insists on placing people within the team with little or no Scrum experience.
3. The PO is 100% involved and executes almost all the requirements expected of him (from time to time he must work on other items outside the Sprint). He is also attending the advanced PO courses.
4. The team's velocity has increased slightly but due to the unfinished US the PO and I are reviewing a decrease in our output expectations. However, the DT have asked to increase it.
5. The PO feels that he is not being taken seriously by the DT as well as to the seriousness of a deteriorating of stakeholder trust. He feels the DT are not responding to the agile development process as well as Scrum.
6. There are currently no performance appraisals made of the external consultants either of their work or Scrum adherence.
7. The team seems to expand the work to fit the Sprint, e.g. they would have difficulty delivering 50 or 100 SP. i.e. output is time-based and on SP based.
8. We conducted Retros at the beginning where I directed and coached and have finally implemented a totally hands-off format where the team is given time to prepare their successes and improvements items. However, within a few days of committing to their own improvements they renege and fall back into previous non-agile practices.
9. Although the importance of the burn down chart has been made know to the DT none of the members consult it and therefore the daily becomes a set of fuzzy statements and statements "We will have it finished today" etc.
10 There is no feeling of items impeding the DT progress. This week we had a burn down chart that had stayed constant from the first day. When asked about this the DT did not find the situation risky as the were about to deliver a considerable amount of new work.
11. We also had a production outage in our software and the team added new story points and items to the current sprint without informing the PO or the SM. When questioned what they would like to do based on flat burn down chart and the increased story point risk the team decided on increasing the risk even though they understood the extra risk involved. They would rather risk non-delivery than balancing the original expected story point delivery. The PO was against the idea but the DT decided to do it anyway.

In short the PO and the SM have provided guidance, proposed training, provided incentives, provided sessions where the stakeholders have explained their business domains and what they would like to achieve. We have also intervened taking over testing responsibilities and also rolled up the sleeves to help with the development tasks.

Ultimately, as you all seem to say above, the responsibility lies with the Scrum Team but most importantly with the DT. However questions are arising as to whether an new approach within Scrum should be taken or the whole process dropped and either Kanban or waterfall should be reintroduced. Would a Scrum consultant/trainer be appropriate? Is there a Scrum assessment or measuring stack to see if a DT are really capable of performing Scrum or should we just give up?

Given this new information I would really appreciate your feedback.

Sorry to be really cynical and play devils advocate on this one, but I'm wondering, how significant do you think the fact that all the developers are contractors is playing? If they are hourly paid for the duration of the project, is there any incentive for them to become more efficient and reduce technical debt?

I've worked with some contractors who did want to do a good job, but others who simply wanted the hours and were in no rush to improve efficiency and see themselves out of work.

Have you sprung agile on them and expected them to just fit in or did they know that the environment was agile when the took the contract? In effect, have you changed the rules of engagement on them and they're rebelling?

Regarding the technical debt, do you know how this has come about? Were all PBIs completed according to the acceptance criteria ? Is the debt in architecture?

Is there some weakness in one of the pillars? Transparency Inspection Adaption, without one, the others are of limited value.

Could you start to build an internal team of full time employees and build an agile friendly culture from the outset?

Tony

Do you have strong enough agile sponsorship to revise the supplier engagement model? Perhaps it would not be unreasonable for your organization...one that is expecting agile delivery...to fund development on an incremental and evidence-based footing.

If you fall back, you will have some exposure to pitfalls and problems and some of this is outside of Scrum.
The PO is going the extra mile to study that;s excellent, the Org has signed off on it, a SM is available.
There sounds like there is room for improvement getting the retrospectives back on track etc as they started and then just dropped off, so its a weak area. A good consultant can adapt to many things and will be prepared to
have the tools and understanding they need at their own expense, as that's the name of the game.
Premium cost, premium service and doing what a company hired them to do.

If Scrum is definitely for the Org, has the full backing and the commitment of a good SM and PO, this is outside of Scrum. Consultants would be a capex, if the capex isn't being met then is an Org issue.
They had budget for hiring, a good consultant should be able to adapt more so as its in their interests to, that's the premium you pay for, you hire what skills you need that you have a shortfall of, until that gap is closed.
Here it sounds like the DT do what they want, which defeats the purpose of the investment.

Scrum cant resolve that issue, and if the DT wont get on board as they are all external and the Org wants to go Scrum should have dialogue with them around what's expected from the staff they hired.
Even if that is a certification that is required now as part of that new change to the business.
Its been said many times here, you need full commitment and a team of people who are willing to embrace the
push to scrum and Agile (say and do), if you don't simply wont succeed in that jump.
Here your paying a premium rate for what could be an impediment to your transition to Scrum deployment.
Certainly food for thought at an Org level.

Michael

This is most probably going to take place at the end of August.

Sorry, renegotiation will probably take place in August was what I meant to say.

Please believe me when I give you some more information - all of this is really happening! It is unfolding day by day...

1. The supplier was the side forcing Scrum on the Client.
2. I am the SM but have come from the supplier.
3. Our DT have proposed that they would like to start working remote, i.e. from home for at least 2 days of the Sprint and as soon as possible.

Should we force the supplier to train his consultants in Scrum (at the supplier's cost)?

Many thanks for the help you have all given me so far.

Hi Graham,

You could even specify which certification you want, so everyone is on the same song sheet.
This happens with some contracts that if you don't have the ticket they want for governance wont get the slot.
Even though most bodies use the guide, you could specify that your approved consultants MUST have cert (x) to be considered for the positions and you choose the cert, your paying the premium for it, chances are you may see a swift mind set change from as is, with people that do want to be aboard your train having no problems with the request if its explained why, and those that don't want to be on the train jumping the bus home.

If they are all certified by the same Org/body then the same understanding will apply and one less variable to play with.
I would air on the side of caution on remote working at this point, (that might just be me) as this may just cause another impediment, due to current problems could be shooting yourself in the foot with a team that isn't committed.
If you see the value being added and the products are not suffering, then why not, your sprint events should be able to tell you if that's occurring, it must be visible though. This could also be discussed on an "inspect and adapt" basis on the sit down and would hope that the Org is also playing a key part in that discussion.

This as you know is outside of scrum, but may help in looking at it from a Capex perspective, while also bringing Opex staff into the workings with the same training early enough as its a new transition, even the Capex staff don't have those skills as yet so no reason you cant get people in at grass roots.

Regards and hope this helps

Michael

Thanks for sharing your experience. If I read the whole story, this all is about culture and commitment. From a distance it's impossible to know what will work for this specific team and in this specific situation. One thing is sure, it's about people and you must shift discussions away from the content level and talk about attitude, co-operation, a common view of how the work should be done and explicit commitment. A possible outcome is, that it simply will not work with this team or part of the team members. It's hard, but if that's the case, act according to what you see. Bottom line is the obligation for the devteam to deliver business value. If they can't and improvement is not an option, there is no justification for its existence.

Many thanks for all the positive suggestions and support that you all have given me over the last few weeks. The information has been extracted and will hopefully result in the positive development of the Scrum team. I hope to keep you all informed on any resulting outcome and developments.

Graham