14

Sprint In the Scrum Framework all activities needed for the implementation of entries from the Scrum Product Backlog are performed within Sprints (also called 'Iterations'). Sprints are always short: normally about 2-4 weeks. Each Sprint follows a defined process as shown below: The heart of Scrum is a Sprint, a time-box of two weeks or one month during ...


14

If you are following Scrum as defined in the Scrum Guide, the Product Owner cannot simply add stories to the Sprint Backlog. The Sprint Backlog, which is created as Sprint Planning as a negotiation between the Product Owner and Development Team while considering past performance and forecast capacity, is owned exclusively by the Development Team. If work ...


14

The key to team improvement is good retrospectives. When I started running retrospectives, I found they often just degenerated into whingeing sessions that didn't achieve much, other than giving the team an opportunity to vent our frustrations. Now I go into the retrospective with a clear goal, stated at the beginning of each one: We're here to find ...


10

This is a common question. One helpful resource as a starting point is the Scrummaster Checklist. It's not meant to be literally a checklist of things to do each day, but rather a list of things that a Scrummaster could be doing that can give you ideas of where to fill things in. You didn't happen to mention working with the PO or stakeholders in your ...


9

TL;DR A coach is not a manager, and is not even formally a member of the team in any agile framework that I'm familiar with. Your job is to help the team be self-actualizing, empower them through knowledge of their chosen framework, and then let them learn through experience. Do not attempt to manage them! That is a role failure, and will result in lost ...


9

This may seem pedantic, but you don't solve this. They can solve it, but you can't make them. There are two approaches that come to mind on working through this: actual conflict mediation team building Conflict Mediation There are books and certifications on this - far more than fits in a Stack Exchange answer, but a starting point is to talk to them ...


8

In the talk "The land that Scrum forgot" of Robert C. Martin (one of founders of the Agile Manifesto) says: A Scrum Master was a coach. A Scrum Master was not a manager. The Scrum Master was responsible for defending the process, but nothing else. He/she did not defend the schedule, not the budget, not the stories, not the backlog. Only the process ...


8

I have been in a similar situation (in a retail bank), with consultants offering what they call 'enterprise Agile'. The result was waterfall and highly problematic. The consultancies are typically very good at lobbying support (especially with the executive). So it can be a challenge to call them out. I would recommend to your Agile coach that they do the ...


8

The skillsets are exactly the same. It's the focus that is different. The Scrum master is a coaching and facilitating role. However, the scrum master is usually focused on and around their team. The agile coach takes a higher and more outside view. For new teams, a scrum master will be much more hands-on guiding them, but in time that part of their job ...


8

I think I can provide a better answer if I rephrase your questions a bit. Q. First, is it necessary or beneficial to have rules that apply across multiple (or all) teams? A. Yes. While consistency across all rules and practices is not necessary, there will be plenty of rules that work best if there is a common agreement. The work hours is a common example. ...


8

When “taking it to the team” should we seek consensus? The simple answer is "yes". When people all agree on a decision or an action, they will stand behind that decision or will make efforts to realize that action. The more detailed answer would be that it's not that simple. Sometimes people all agree on something, in which case you have the best outcome ...


7

I think the different levels can relate to the Agile Onion as described by Simon Powers. Entry level: Can implement the tools and processes, but doesnt have a good understanding why the processes, practises, principles and value's exist. Could lead to cargo-cult Agile. Intermediate: Can work on a team level, but does not yet have the experience to change ...


7

Helping a team to be more autonomous is one of the most difficult things to do because you achieve it by doing less rather than doing more. As a Scrum Master, I sometimes: Attend a ceremony/meeting and say nothing. There is often some initial confusion but after an awkward silence typically somebody steps up and starts to drive the meeting. Hold back, even ...


6

I've worked as a project manager for 15 years and have been working as a scrum master part-time (of the 15 years of PM work) for 3 years and full-time as a scrum master for 3 years. Here is what I typically do, but in the end my job is to help teams be as productive, effective and efficient as possible to deliver the highest business value as they possibly ...


6

One of the approaches I've used in the past that works pretty well, especially with multiple teams: Set up a flip chart for each team and put a dotted line about 1/3 of the way up (so the top section is 2/3 of the chart). Explain definition of done (I also provide examples like "X% test coverage with all tests passing" and "merged to trunk") and ask them to ...


6

There is nothing agile about the consultant's approach and certainly not use of the Scrum framework. That is waterfall with some modern software development terms being misused. Allowing an internal team to learn through controlled experimentation is a good mentality; permitting a consultant to waste money for any length of time is ludicrous.


6

There are many things you can do, but the first thing I would start with is a coaching agreement. I've seen very simple and very complex coaching agreements, but all of them hit a few key points: How will the coach work with those being coached? What do those being coached want to improve on? Do we understand and acknowledge that the coach can't improve for ...


5

Just making sure I understand your situation... Once your full-time Scrum Masters feel that they are 'done/ready', they want to graduate to 'Agile Coach', and nominate a developer as a part-time Scrum Master called 'Scrum Guard', yes? The problem is that good Scrum Masters are supposed to work themselves out of their jobs. As servant/leaders, they perform, ...


5

Here are some suggestions. Using retrospectives which cause the team to call out the lack of acceptance criteria The behaviours you have mentioned are all valid topics for retrospectives, not just the lack of acceptance criteria. Also, the idea of retrospectives is not just to raise issues, but also to monitor progress towards their resolution. If the ...


5

I would add one step to your process. Just to make sure we are thinking about the same, these are the 3 steps I have in mind: Do the internal retro with your team Agree on a process with the managers to approach members of the team Speak to each manager individually about the importance of addressing this situation and the process you create


5

I guess what I am trying to figure out is how can a team be autonomous if you are telling them where to work and when to work. Autonomous always means "autonomous within constraints". Agile doesn't mean "developers get to do whatever they want." "Let[ting] developers work wherever and whenever as long as they deliver" sounds more like Wild West ...


5

Regardless of what kind of effort is missing, I'd talk with the team member first. You need to figure out his motivation. Why is he non-committing? A fishbone-diagram or the Five-Whys-technique are perfectly suited for this. I always try to dig deeper. Did his behavior change in the last weeks? Is he facing personal issues? Is he tired and overworked? How is ...


5

You can define the topics to be discussed up front, based on data collected and affinity diagrams as you suggest. That would make it easier for participants to prepare. But you can also have the participants suggest topics at the beginning of the meeting, and do a dot voting and prioritization. Or use open space technology to have people organize themselves ...


5

As long as the PO is responsible enough to take the blame if the product fails, it should not be a concern. The project team will be concerned if the PO shoves all the blame on the development and the design teams for a product failure. There will be differences in opinions. When the PO requires something to be done in a certain way, the only way to prevent ...


4

An Agile coach should be a proactive person. If there is not enough work on the current project I would expect the coach to find gaps and work with the company on other Agile improvements. The coach could also be an extra hand on the team. I have seen coaches do: (Pair) Programming Testing Writing requirements Writing user documentation If their focus is ...


4

TL;DR: Maybe a bit harsh, but get rid of him/her. Most companies have a defined culture or core values. Suggested is to use your core values in the hiring process. I think the same goes for the firing process, fire to protect your core values. Introducing Agile is a team culture shift according to the Agile Fluency Model. People blocking this culture shift ...


4

As a Scrum Master I totally sympathise with your question. The Scrum Master role is very peaky and troughy. The worst thing you can do is create meetings or other distractions for the team just to keep yourself busy. There will inevitably be times when you should slip in to the background and let the team get on with things. How to best fill your time? ...


4

Now, it could be that you have worked to create a hyper-performing team and there is no further room for improvement. A measure of this is that velocity (or similar metric) has increased by an order of magnitude in the last year. However, the most likely scenario is that you and your team have become 'comfortable' and velocity has not increased ...


4

I'm the Scrum Master on a cross-functional team that initially had little to no experience with Agile. I think Barnaby's answer is great and definitely something to strive for. From what I've observed, though, if the team doesn't have a certain level of maturity (Agile-wise), they won't necessarily learn if you leave them to their own devices. If in their ...


4

Should [the organization] be setting rules? Of course they should be setting rules. "Don't embezzle" and "Don't punch clients in the face" are both rules. You're not really asking if organizations should set rules (I hope). You're asking where the line should lie. Is there a better way of setting these boundaries for the team? [...] Should [the team] ...


Only top voted, non community-wiki answers of a minimum length are eligible