Agile and Scrum classic

Hi Nicholas,

It is the duty of the Scrum Master to lead, train, and coach the organization Scrum adoption and all that has to do with it. In my own opinion to avoid further upcoming issues with Jira, the frustration expressed by the team members on the use of Jira should be addressed. Maybe a training should be organized to get them back on their feet on the use of Jira, train team members on using the updated version of Jira and educate them on the implication it could cost the organization if not done or used rightly. I feel that is the first thing that needs to be addressed. Thanks.

Was the defect managed by means of a test case which initially failed and which was then satisfied, and was the Definition of Done improved to stop this and similar bugs from recurring?

Does the fix affect the sprint goal? The sprint scope is owned by the developers, the product backlog by the PO. 

Based on that, the next question is if this bug was directly caused by writing the code or was it additional found by writing the code? 

In the first scenario, it is part of the sprint scope as a part of the story/requirement and it should have been detected anyway by creating automated tests, by review, tests or whatever you do to meet the DoD.

The second case could be a bit tricky. If in your team detected bugs are handled via the product backlog, the PO has a stake because of the prioritization. 

In a discussion, it should be clarified what is the value of creating a ticket. Is there a need for that from an organizational perspective (e.g. compliance rules, security risks)? Also, what is the benefit of fixing the issue immediately and what is the benefit for the organization (e.g. if the ticket would have been discussed than in 5 meetings, what organizational time has been saved by fixing it instead of discussing it.  

All this above are puzzle pieces of "Individuals and interactions over processes and tools".

I would commend Developers for self-managing and working together to pair program and move past the development challenge.

This could be a good training and/or coaching opportunity with the PO. As an example, would be curious to know why PO or stakeholders would be concerned with how Developers solve for their complex problems and why they wouldn’t be more concerned about value delivery. How does the PO view the PO accountability and what gaps could the SM fill through training or guidance?

From this scenario it appears that this is a low trust environment. Would want spend some time exploring this to find opportunities to improve the relationships within the Scrum Team.

+++

If someone was making me a sandwich and they discovered a defect with the tomatoes and they fixed that defect by throwing those out and using fresh tomatoes, and I as the stakeholder/customer received a quality sandwich...I do not need the identification of the defective tomatoes written on my receipt. I only care about the quality sandwich.

At retrospective, PO demanded some sort action and sanctions to ensure that discipline, "for a sake of stakeholders" would be established in the team.

Sanctions?  Sounds like that PO would make a great politician. 

The Developers handled it correctly.  Regardless of Scrum or waterfall.  They encountered an impediment and removed it which allowed them to complete their work.   

Was the defect managed by means of a test case which initially failed and which was then satisfied, and was the Definition of Done improved to stop this and similar bugs from recurring?

Yes this is what's happened 

Yes this is what's happened 

Then I'd wonder about that with the PO, and the higher-ups if necessary, because it sounds like the discipline is there to me. It's nice when members of a Scrum Team set a good example to others of how accountabilities should be met.

As long as a solution is not yet in the hands of users, there is no value (not that I see anyhow) in tracking "bugs". The solution just is not yet finished, and as such the team is expected to focus on getting to Done. Great job developers!

A product owner that is focussed on this type of things typically is not focussed on what really matters: getting value in the hands of users. A strong product owner is outward-facing: go listen to what the market needs, what it is expecting. Bring that back to the team(s) and let them take up the challenges.

If the developers do not like Jira, then consider dropping it altogether.


Some teaching, coaching, mentoring would be useful here. A workshop about the different accountabilities, and the mandates that go with these seems in place.

It is worth noticing that the PO might be trying to fulfill some obligation, which the organization has put on him. The Scrum Master needs to discover the bigger picture and the motives behind the PO's actions. Also, the Scrum Master should build an understanding among the Developers about the bigger picture as well. So, yes, prize the developers for taking prompt action, but also get the PO and the Scrum Team on the same page in regards to the bigger picture. Meanwhile, work on the organization level to correct faulty practices.

Thanks for the answers. Yes in the ideal Agile and Scrum universe the developers team did a perfect job, and even in this particular situation this was supported.

But...

Yes, as Jacek said, PO was right at his own end.

Firm where it happened has really pedantic stakeholders(those in the top management) ;the type of people who would demand the sandwich store to account for thrown away tomatoes, if they were replaced in clients' sandwiches, using the analogy above.

Additionally to to that PO is really into Evidence based management, ironically introduced to him by Scrum master

 EBM matrix of Current value, Unrealised, Value, Time to the Market, and Ability to Innovate was constantly monetised and used at Sprint reviews to get often frustrated stakeholders on team's side, particularly to display that value is more important than productivity and quality is more important than quantity. For this reason PO was using each KVA to the precise metrics, like revenue per employee, time spent context switching, lead time for changes, time to remove impediment, production incident count, and technical debt, which developers helped to avoid in that case.

So by doing perfect work(indeed) but putting administration aside in true Agile fashion(working software above comprehensive documentation) they sort of tackled PO's work...

So Scrum master had to take this in the account too while facilitating discussion

Besides please don't forget that the whole team expressed frustration with the use of Jira(something many of you, those who are practicing Scrum masters often witnessed in your teams , I am sure).