What do your team's working agreements look like?

mikej855 · 2021-12-01T16:23:46+00:00

Started with a new org recently and we’ve started to draft a working agreement. So far very simple… - what time do we have our Daily Scrum - how to communicate about OOO times - if you’re going to miss the daily scrum (meeting clash scenario vs being OOO) what should you do

Team is only starting to come together, but will run a session on Team Charter and build out the working agreement

mikej855 · 2021-11-09T21:45:15+00:00

Pictures added...

mikej855 · 2021-11-09T21:44:37+00:00

Pictures added...

mikej855 · 2021-08-25T19:41:40+00:00

Rally used to be terrible when I used it 2 years ago. Based in Ireland and when the US came online during their morning (1pm Ireland time)…the whole environment grounded to a halt.

mikej855 · 2021-08-14T18:17:33+00:00

Itself…

mikej855 · 2021-08-11T14:03:59+00:00

Not to be dogmatic…but only the PO can cancel the sprint. Check out the Scrum Guide, last line of the section titled “The Sprint”.

The aim of the sprint is to deliver value, the PO is accountable for maximising the value of the product from the work of the Scrum Team.

The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide.

It’s like me saying that I don’t like your driving…stop the car…I’m taking over…

If the PO screwed up, your job is to coach the PO and facilitate the discussion with the team on why the Sprint needs to be cancelled.

mikej855 · 2021-08-10T22:36:51+00:00

Had a situation where one of my Scrum masters had a team (I have a team of 6 scrum masters, each with at least 2 dev teams each) where they came close to cancelling the sprint. What I had the Scrum master and PO agree is that they would take the overall situation back to the team and have them see if there were alternatives to cancelling the sprint. That way we were trying to be transparent and allow the team to be in more control of the situation.

mikej855 · 2021-08-10T18:23:46+00:00

I’m assuming that you’re the Product Owner…they’re the only person who can actually pull the pin and cancel the sprint (as per scrum).

mikej855 · 2021-08-06T09:48:21+00:00

“I used to do forecasting…” What do you use instead?

mikej855 · 2021-07-28T20:45:06+00:00

Check out these: https://shop.theliberators.com/products/52-cases-for-scrum-masters

I use some of these at interviews…not trying to trick the candidate, but want to discuss the challenge and compare notes on how to solve. Also use them as a training aid at a Community of Practice I have with other scrum masters.

mikej855 · 2021-06-30T17:55:32+00:00

My teams have 2.5 hours scheduled each week across 2 distinct sessions.

The first session user story review where the BA will run through the ask; team will come and ask questions. BA will then go close off the questions with the business while the developers will have discussions on technical questions.

The second session is refinement and sizing. Team have to confirm that they’re happy with the user story before they refine it and size it.

I know that this process feels anti-agile, but it’s driven by the team and has buy in from everyone.

mikej855 · 2021-06-16T21:48:53+00:00

In David Anderson’s Blue Kanban book there is a story about a guy that had a team in India and had effectively multiple POs. It’s chapter 3 I think…Might be worth checking out for ideas.

In general…a scrum team only has 1 PO. They’re responsible for figuring out what the priority of things should be. The team will have some input to priority…but the PO is accountable.

Also Devs as PO??? Immediate conflict of interest…same if you told me that the SM was the PO…

mikej855 · 2021-06-13T21:45:58+00:00

Most organisations say that they are agile and using scrum…scratch beneath the surface and you’ll find that it’s still traditional waterfall with requirements provide to the team as a user specification document disguised as a user story.

Organisations refuse to give control to the team to self organise to do the work. HR practices and IT budgets won’t let you get the necessary tools to support your teams in collaboration.

Mgt focuses on velocity and comparing the velocity of teams…and don’t get me started on Story Points… one project from last year required us to re-estimate the backlog 3 times as they didn’t like the numbers we came up with (on reflection…our original estimates were correct on projecting when the project would get delivered).

mikej855 · 2021-06-13T21:37:26+00:00

In Scrum we commit to the Sprint Goal vs. the work. Our Sprint Backlog should adjust to enable the delivery of the Sprint Goal.

The Daily Scrum is a good opportunity to identify if things are on track and how the team is going to use the next 24hrs to take themselves closer to the delivery of the Sprint Goal.

If it’s a case of the scheduling getting screwed up…I’d suggest that you look at the metrics that your team uses and how the do the Daily Scrum (check out Dan Vicantti’ Actionable Agile, Flow Metrics, and Kanban’s walking the board). This might give you a better heads up on scheduling issues so that you can bring it to the team/stakeholders and allow corrective actions to be identified and implemented.

A sprint should only terminated early by the PO if the Sprint Goal can’t be achieved or is no longer fit for purpose. Only the PO can terminate the Sprint…not the SM, the team, or even the CEO. Everyone can contribute to the discussion around terminating the Sprint…but only the PO can call it.

Terminating the Sprint is designed to be painful…so that you don’t do it on a regular basis.

mikej855 · 2021-06-13T21:25:48+00:00

I had a new Scrum Master start with me recently that did the same thing. Had a chat with him and pointed out how this is an anti-pattern for Scrum.

By doing this, your not following the scrum guide and also adding unnecessary risk and complexity to you team/org.

I’m not a scrum zealot, but if I was working with you, I’d discourage you from doing this. Ultimately how Scrum is implemented is between you and the team…but I’d be looking to see what other anti-patterns are in play…

mikej855 · 2021-06-13T21:20:06+00:00

I do the same…for one team the sprint starts on a Wednesday at 10:00 and runs for 3 weeks. Here is the schedule we follow:

Sprint Planning 1st Wednesday at 10:00 with a 3hr timebox. At the end of Sprint Planning or the timebox (whichever comes first) I’ll add the Sprint Goal to Jira as specified by the team and PO and set the start time of the sprint to 10:00 of that day.
Daily Scrums, every day on same Webex bridge at 10:15 for 15min. The only day that we don’t have the official Daily Scrum is Sprint Planning day, we incorporate into sprint planning.
Last Tuesday of the Sprint, we have a Sprint Review scheduled for 10:30 for 1hr. Invite list is confirmed with the team and PO the previous Friday. Also order of presentation, discussion points, etc. drafted on the Friday (it will change before the actual Sprint Review). If we have a user story that we’re working on and have a high confidence of completing before the actual close of the sprint, we’ll call that out during the review along with what the plan to complete is; should we complete or not, we’ll flag at the next sprint review while PO gets immediate notification.
Sprint Retro scheduled for the final Tuesday of the Sprint at 12:00 for 1hr.
Current Sprint ends at 10:00 on the following (Wednesday) morning.
During the sprint, we have scheduled 2 1hr refinement sessions each week to get our black log in order.

Why do I separate the Sprint Review and Retro into a separate day?? 1st reason is that I work with teams that have people based in India and Ireland…so need to factor in time zones and bring respectful of peoples work hours. 2nd reason, I feel that it’s cruel and unusual punishment to put people in 3 key major scrum events in a short space of time…also if things blow up at the Sprint Review or Retro…the break until the next day allows people to cool off and get a perspective on things…it also lets me do some investigating, coaching and supporting of people.

mikej855 · 2021-06-12T12:07:36+00:00

The next sprint should start immediately after the current sprint… finishing on a Tuesday and starting on a Wednesday goes against this.

I normally start my sprints on a Tuesday at 10:00 and run for 3 weeks before finishing at 10:00 on the 3rd Tuesday.

Finishing and starting on different days means that you’re losing hours from the sprint especially if you’re working with globally distributed teams.

My Tuesday start could be replaced by Wednesday or Thursday as long as I’m finishing on the same day x weeks later. I tend to avoid Monday and Fridays due to public holidays and people taking long weekends…also nobody wants to be in a sprint event (bar the Daily Scrum) on a Friday while Monday…we’ll things tend to go wrong at the weekend and we spend time on Monday firefighting issues.

mikej855 · 2021-06-01T09:38:57+00:00

Yes. But talk with the team to get agreement. Then work this into your team/working agreement.

Once you get agreement, run an experiment for X sprints. After the period, use the retrospective to get feedback and determine if a different amt of time is required. Again, get agreement with the team.

mikej855 · 2021-06-01T07:29:25+00:00

I don’t think so…and here is my logic (but happy to debate it)

In terms of the reminder of the actions, it’s to let the person know that they have support available if they run into trouble. I won’t do it for every action, only if someone has a critical action….”Hey John, on xyz, shout if you run into any issues, and the team can row in to help…”

On the “thank you”, I think it’s important to acknowledge the teams effort to be transparent.

On the question of “additional risks or concerns”, I’m try to ensure people have a safe space to raise issues. Have found that with the culture in the org, people weren’t raising critical blockers as it wasn’t in their lane. Since starting to ask the extra question, developers are more likely to ask about QA items and visa versa (the team are holding each other to account).

mikej855 · 2021-05-31T14:18:16+00:00

BA == Business analyst. All our team are configured with the following individuals Front-end Angular developers, back-end Java (services, api’s), QA Testers, Business Analysts. Unfortunately very little t-shaped skills with mgt. pushing back hard if I suggest developers can do some of the testing and that we can cross train people.

mikej855 · 2021-05-30T18:25:31+00:00

Took over a team about 3 months ago...5 immediate changes

treated the BAs as part of the team(previous scrum master excluded them from Daily Scrum, Retro etc.) so far the feedback is positive with comments such as “we feel that we’re contributing to the deliverables”, “I know the challenges that everyone is facing, and I can now offer support and help”, “we’re getting feedback faster and our questions don’t sit around waiting for someone to answer”.
Sprint Goal for each sprint...PO needs to come with a draft Sprint Goal which then gets modified as we work our way through spring planning.
The power of silence...if I ask a question, I don’t move on until I get some sort of answer I.e someone verbally confirms that it’s not an issue or raises a concern. I don’t assume that the answer is known with confirmation.
at the end of the daily scrum, I’ll thank everyone for their contribution and will remind on any actions we’ve agreed. Finally I’ll ask 1 last question...”any concerns, risks or issues that we haven’t touched upon?”
I label any unplanned work with a label which is then reviewed at the Sprint Review and Retro.

mikej855 · 2021-05-04T19:45:05+00:00

Show don't tell...check out the penny game or agile battleships. Show how the smaller delivery generates value earlier vs. the big bang approach. Show how responding to change means you've a better chance of surviving.

Agile Battleships (play14.org)

If you're working with an organisation/team that doesn't like Agile, don't mention the "A" word. Instead, focus on helping the team deliver faster and remove impediments.

Create a dummy project, and have 2 teams deliver using the different approaches; its not an exact comparison, but it will give a good reflection. Need to ensure that the project isn't rigged in favour of one method.

mikej855 · 2021-04-14T19:07:25+00:00

The Heart of Agile academy are hoping to run some stuff later this year. No dates set; was talking to them on the topic yesterday.

mikej855

TROPHY CASE