15

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

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 ...


9

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 ...


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 ...


9

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 ...


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. ...


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 ...


6

When we as Agile Coaches and Scrum Masters servant lead teams and help them make decisions, do we need to seek consensus? Yes... and remember that consensus is not the same as unanimity. This is a pretty good article on various approaches to obtaining consensus. I like the Fists of Five technique myself (slightly different from what's in the article)**, ...


6

It depends on the event. People from outside the Scrum Team should, generally speaking, attend an event when they have something valuable to contribute to the team within the context of the event. The only event that I'd have a strong objection to someone outside the Scrum Team attending is the Sprint Retrospective. In order for the retrospective to be ...


6

I also don’t feel it’s of any benefit for my team. You think there is no benefit in a coach? What are you, perfect? "Inspect and adapt" is the core of Scrum and you are flat out rejecting it. It would be good if you could embrace it instead. Let them do their jobs, think about their suggestions and improve your team. Because let's be clear about ...


6

TL;DR Nope, nope, nope. Just "no." The question is based on the faulty assumption that you can force change on other people (hint: you can't), and is wishing what seems likely to be poor team composition into the cornfield. Why You're Asking the Wrong Question The Product Owner that I am working with has agreed "to try this self-organising ...


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 ...


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