Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
This place is easy, friendly, a safe environment and an informative place to support the work of those agilists from all around the world!
Create an account and Give and Get Help!
Don’t you just love it when your team uses your words against you?
So I hear two things - some people in the team are playing power politics - some of the team see a longer daily Scrum as being high value - you are being drawn into a "competitive" conflict resolution style These are two quite distinct issues, however they are both really symptoms of some underlyingRead more
So I hear two things
– some people in the team are playing power politics
– some of the team see a longer daily Scrum as being high value
– you are being drawn into a “competitive” conflict resolution style
These are two quite distinct issues, however they are both really symptoms of some underlying core stuff. So – Scrum is serving (as frameworks do) like a diagnostic tool and exposing symptoms. The retrospective is where those get unpacked.
I guess my key questions would be:
– how is the team measuring it’s performance?
– how is the team measuring the value of the 90-minute daily Scrum?
– what do the other people in the team think about the long daily Scrum?
– is this the biggest issue you need to address?
– is there the psychological safety to discuss it in your retro?
Change, learning and experimentation is a good thing, but it needs to have both pressure to improve (from within the team, intrinsically, or from outside) and psychological safety.
So overall my counsel would be to reflect a little, and start to guide the team towards evidence-based empiricism and continuous improvement…
See lessHow do you handle unplanned work throughout the sprint when there is so much unplanned work?
The best thing to do is to plan for the unplanned work... That can take a few forms; one route is to leave a "buffer" for that unplanned work; in practice a buffer is *usually* a good idea anyway in a Scrum context. if you aim for the mean (average) velocity then half the time you will do more, andRead more
The best thing to do is to plan for the unplanned work…
That can take a few forms; one route is to leave a “buffer” for that unplanned work; in practice a buffer is *usually* a good idea anyway in a Scrum context. if you aim for the mean (average) velocity then half the time you will do more, and half the time you will do less.
Having a buffer might also give you enough breathing space to be able to actually set a Sprint Goal, and start working towards the Product Goal step by step, doing Scrum “for real”
In a Scrum sense you’d not usually ingest work that might imperil the Sprint Goal, and so a buffer allows you to pick up service tickets and still make progress.
If you don’t want to do that, then maybe look at the Kanban Method; there you just pull work from the backlog. In the Kanban Method you have “classes of service”, one of which is Expidite; that’s pretty much where urgent work goes.
However, there’s some deeper stuff to maybe unpack…
– do you triage the production support tickets? Classifying them as “now”, “next Sprint” and “backlog” might be useful. Remember the Product Owner’s role is often about saying no to things, not saying yes to everything.
– what generates the production support tickets? Can you do anything to eliminate or automate them?
See lessHow do you formulate sprint goals when you are working on 3-4 different products?
The short answer is "you don't" The basic principle of out-of-the-box Scrum is that the team works on a single product. That's largely about focus and context switching. Check out Gloria Mark's work (for example) on the impact of working on 2+ projects at the same time, but a rough summary is that (Read more
The short answer is “you don’t”
The basic principle of out-of-the-box Scrum is that the team works on a single product. That’s largely about focus and context switching.
Check out Gloria Mark’s work (for example) on the impact of working on 2+ projects at the same time, but a rough summary is that (a) it will add 20-40% overhead to both projects and (b) it will increase employee stress.
Increased stress isn’t just a fluffy bunny thing; stressed people communicate less well and make more errors, before they burn out and quit.
Still – if that’s your reality, my suggestion would be not to use Scrum, and focus on the Kanban Method instead. You won’t need to worry about Sprint Goals (or indeed when you have enough data estimation) and you will be able to actively track the cycle time (and hence customer facing performance) for each customer.
If you limit Work-in-progress effectively you might also be able to do something about that context switching….
See lessHow much empathy is too much for the role of a scrum master?
I think there's a couple of things here. Firstly, there's a difference between empathy and sympathy. There's lots of definitions out there but as part of my ICF-accredited coaching course, the ones we used were: - empathy is being able to understand something from another person's perspective - sympRead more
I think there’s a couple of things here.
Firstly, there’s a difference between empathy and sympathy.
There’s lots of definitions out there but as part of my ICF-accredited coaching course, the ones we used were:
– empathy is being able to understand something from another person’s perspective
– sympathy is when you agree with that position, and become emotionally invested
So in that context, you are both empathic – in that you can see their perspective – and sympathetic – in that you become emotionally invested, to the extent that you lose objectivity.
The second thing is what happens when we get emotionally invested.
No matter what the emotion, the brain tends to withdraw resources (things like glucose) from the cognitive centre of the brain (the prefrontal context) towards the emotional centre, where we “pattern match” and act on instinct more. As a result, our IQ actually drops a bit. We are less creative, and therefore less able to support other effectively.
So – at a point. “climbing inside the bottle” with those we aim to serve as leaders can be a bit of a problem, and we do need to keep an eye on our own emotional state, and how we regulate that.
Some key things I find are
– a walk-and-talk is usually better for challenging subjects; we can’t get overly emotional, walk, and talk at the same time. (try it!)
– think HALT – am I hungry, angry, late or tired; if you are under going these stressors – or other stressors – then its harder to stay “out of the bottle”
– doing an ICF-accredited transformative coaching course really helped; we did months of practice coaching “in the coaching dojo” that helped to separate the context of the conversation from how someone relates to that context. Your brain retrains accordingly.
That’s not saying sympathy is a bad trait, just that it can start to limit your professional effectiveness as a coach if it starts to dominate, and that doesn’t serve your teams or organisations well….
See lessIs it ok to not set Sprint Goals since the Team is performing?
Well, Sprint Goals are not about team performance. The Sprint Goal is how you communicate to the customers, users, stakeholders just why this Sprint adds value. The Sprint Goal is also a stepping stone towards your overall Product Goal. At the Sprint Review, you are looking at Product-market fit reaRead more
Well, Sprint Goals are not about team performance.
The Sprint Goal is how you communicate to the customers, users, stakeholders just why this Sprint adds value. The Sprint Goal is also a stepping stone towards your overall Product Goal.
At the Sprint Review, you are looking at Product-market fit really carefully, using the Sprint and Product Goals as lenses, and working out – with the customers and stakeholders – if the market has changed, so the direction of the Product needs to change too.
So – perhaps you could think of those Goals as being about *product* performance, not team performance.
If that doesn’t make sense in your context, then it’s okay – just there’s not a lot of point in using Scrum. You might want to look at the Kanban Method (where there are metrics to help continuous improvement, or even do something else.
That won’t be Scrum, but that’s okay. If your customers don’t care about your Sprint and Product Goals, they don’t care if you do Scrum, either….
See lessWhat are some great ways to convince a team to swarm on stories instead of working on single tickets per member?
Maybe take two steps back. - why do you need to "convince" your team of anything? - what is the problem that you, as a team, are trying to solve? At a point, you are part of a team; you might have some specialist knowledge and specific accountabilities, but you are not the boss. Servant leadership dRead more
Maybe take two steps back.
– why do you need to “convince” your team of anything?
– what is the problem that you, as a team, are trying to solve?
At a point, you are part of a team; you might have some specialist knowledge and specific accountabilities, but you are not the boss. Servant leadership doesn’t mean trying to force your team in a given direction.
Scrum, Kanban and Lean ways of working are empirical. We are data-driven, not opinion based. In fact we want to shift the whole organisation away from the “highest-paid-person’s opinion” (HIPPO) model and towards an environment where people are curious, open, and want to experiment.
And that starts with us. Exhibit the behaviors we want to see in others, is my counsel.
You have a solution “the team should swarm on tickets”, and yet what we are trying to move towards is the business bringing the team problems to solve, not solutions to be implemented.
Rather than convince the team of any given agile practice or process, I would suggest
– surface issue ideally in a data-driven way with your team in the retrospective
– work with the team to evolve a problem statement
– take that problem statement into an Ishikawa fishbone analysis with the team
– get to a revised problem statement from what they think is the biggest root cause
– brain-storm solutions together, which is where you can add your opinion
– determine what solution you want to try, as a team
– develop a hypothesis – what you will measure to determine success or failure
– do the experiment
– if the original problem still exists or resurfaces, redo the Ishikawa analysis
In doing this you give the team agency and autonomy, teach them problem solving techniques and have an opportunity to bring your knowledge to bare as part of the solution, without acting to control or steer them too much.
Giving a team solutions all the time, or forcing them in a direction you believe to be correct creates a dependency on you. That’s robbing them of an opportunity to grow..
See lessWhat would be the best way to visualize dependencies between 3 different teams in the same project?
At a point you can use any whiteboard tool, create a grid of teams (swim lanes) against sprints, and place the stories on it as post-its with connecting lines. Keep it simple! AzureDevOps can do this in the Planning Views, and even supports teams with different Sprint or Iteration cadences which isRead more
At a point you can use any whiteboard tool, create a grid of teams (swim lanes) against sprints, and place the stories on it as post-its with connecting lines. Keep it simple!
AzureDevOps can do this in the Planning Views, and even supports teams with different Sprint or Iteration cadences which is nice…
BUT…
at a point I’d suggest that making it super simple and super easy to display and talk about dependencies is addressing the surface issue.
The underlying problem is how we can really get to the point where we don’t have dependencies, rather than apply technology to managing them.
Perhaps try:
– getting all three teams together in a room
– run an Ishikawa Fishbone analysis with “Dependencies slow us down” as a core problem
– see where you get to as the likely root cause and restated problem
– design an experiment to try and address that root cause
– measure the outcomes, and repeat…
Every dependency represents a risk of an error in communication, a delay, or both.
See lessTry and eliminate that risk!