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.
What good advice for a new Scrum Master looking for job and interviewing tips?
So my basic advice is 1) keep learning at the same pace; there's no end point. Spend at least 20% of your time learning and reflecting. Books, videos, articles, discussions, pod casts 2) join some MeetUp groups, plenty are now virtual; get to know people in your agile community 3) extend beyond ScruRead more
So my basic advice is
1) keep learning at the same pace; there’s no end point. Spend at least 20% of your time learning and reflecting. Books, videos, articles, discussions, pod casts
2) join some MeetUp groups, plenty are now virtual; get to know people in your agile community
3) extend beyond Scrum; there’s a huge amount of stuff that adds value, mainly
– agile, and lean approaches, Kanban, XP, Theory-of-Constraints,
– leadership, communication, negotiation, conflict resolution, coaching
– business; finance, product development, marketing, operations, change, strategy
– software development practices
4) At interview, if you don’t get the job then either the panel was right, and it is the wrong job for you, or they are wrong, and idiots. Don’t work for idiots.
5) Recast your whole CV to stress agile, Scrum and lean concepts…
See lessIs Kanban Agile?
Kind of what you mean by "Kanban" The Kanban Method is pushed as an alternative to Scrum; it's agile in the sense that you should be meeting all of the things in The Manifesto For Agile Software Development, but it doesn't really address value at all; it's assumed that's someone else's problem. KanbRead more
Kind of what you mean by “Kanban”
The Kanban Method is pushed as an alternative to Scrum; it’s agile in the sense that you should be meeting all of the things in The Manifesto For Agile Software Development, but it doesn’t really address value at all; it’s assumed that’s someone else’s problem.
Kanban strictly speaking is just the signal that says the team should pull more work; so on that sense most teams have some form of visual indicator for this.
I’d tend to classify Kanban as more Lean than Agile, in the sense of the Poppendieck’s book “Lean Software Development”
They are similar, but on the whole lean approaches don’t really deal with the innovation / R+D space very well. Innovation is often lumpy, and doesn’t flow….
See lessHow can I improved a process where the team is stuggeling with accuracy of commitments?
Hmm - sounds like a bit to unpack. Few things to think about, but there's a lot of ground" a) Sprint Goals The Sprint Goal is a stepping stone towards the Product Goal; that's usually an outcome rather than a bunch of functionality. Ideally it's a measurable benefit for the users. There's only one gRead more
Hmm – sounds like a bit to unpack.
Few things to think about, but there’s a lot of ground”
a) Sprint Goals
The Sprint Goal is a stepping stone towards the Product Goal; that’s usually an outcome rather than a bunch of functionality. Ideally it’s a measurable benefit for the users. There’s only one goal, not a check list. You can’t half do a goal – the benefit is obtained, or it isn’t. Scrum Guide is pretty good on this.
b) Sprint Planning
If you are using points, then I’d suggest plan for the mean number of points you have done, minus the standard deviation. Leave a buffer. You can always pull more work, but until that is happening consistently, you are taking on too much.
Be ruthless about splitting stories; the scope for errors, delays and rework is always higher on larger stories A couple of people swarming on the work for a day is a good size. One person for a week is not. Remember the INVEST criteria.
c) Daily Scrum
You are inspecting and adapting your plan to reach the Sprint Goal daily; maybe shift the stand-up to a “fist of five” vote on if the goal can be met. If you get less than a 4 or 5, then what is the team going to do, right now, to change that. That might include renegotiating some of the stories with the PO, or even rejecting them entirely. The Sprint Goal matters, not the PBIs.
Be ruthless on work-in-progress; stop starting new stuff and start finishing things. If it’s blocked, then swarm on the issue until it’s not.
d) Sprint Review
This is figuring out with the customers what will be next, to shape the upcoming Sprint Goal. Maybe incomplete stories/features are still relevant. Maybe they are not. They go back to the backlog, to be considered next time around.
e) Retrospective
Perhaps focus on what slows the team down for a retro?
You could run a sailboat, or do an Ishikawa fishbone to try and identify the biggest constraint.
You can support that by collecting data – cycle time, story count throughput per Sprint, velocity, average story size. What are the patterns telling you?
Hope that helps…
See lessAgile Health Check meeting, what should be at the agenda?
I'd suggest the (only) item on the agenda for the first meeting is to form a working agreement or charter for the group. That or run it as a Lean Coffee type session.
I’d suggest the (only) item on the agenda for the first meeting is to form a working agreement or charter for the group.
That or run it as a Lean Coffee type session.
See lessIs it important to have a deep understanding of the software development life cycle?
I'd suggest there's some core areas where an SM brings value - knowledge of Scrum, lean, Kanban, theory of constraints, project management, and all that stuff about how work flows is delivered, - knowledge of the software development lifecycle in terms of a waterfall process, and agile practices/appRead more
I’d suggest there’s some core areas where an SM brings value
– knowledge of Scrum, lean, Kanban, theory of constraints, project management, and all that stuff about how work flows is delivered,
– knowledge of the software development lifecycle in terms of a waterfall process, and agile practices/approaches such as Extreme Programming, emergent design, security and so on
– marketing knowledge, in the sense of what people value, how to communicate it to the organisation, and how to measure it, product and product adoption lifecycles, customers and all of that stuff
– business knowledge; finance, legal. sale, marketing, procurement, operations, strategy and all of that
– leadership; coaching, conflict resolution, problem solving, negotiation, psychology of teams and individuals, culture and so on
The more of these you know stuff about, the more likely it is you are going to bring value to any given team or organisation. So broadly, keep learning!
I’ve been around software development for 25+ years, and working an an agile/lean space for the last 14 years. And I’m learning new stuff in one of these areas pretty much every week.
So – my current team is in Data Warehousing, where I have never worked. Two weeks ago I discovered “DataOps” is a thing, so that’s my current study!
See lessTesting generate a lot of bugs and the sprint never ends, what can I do?
A Sprint is a time box. Anything that doesn't meet the definition of done at the end of that time box goes back into the backlog. If it aligns with the next Sprint Goal (after the Sprint Review) then it might get pulled into the next Sprint. "Done" should really mean "released into production so weRead more
A Sprint is a time box.
Anything that doesn’t meet the definition of done at the end of that time box goes back into the backlog. If it aligns with the next Sprint Goal (after the Sprint Review) then it might get pulled into the next Sprint.
“Done” should really mean “released into production so we get feedback”
Now, that’s going to make for a fair amount of discomfort, if the team is struggling, maybe even some conflict. It might be challenging and tough.
“Commitment, Focus, Openness, Respect, and Courage”
As a Scrum Master, you are going to have to walk the talk on these things, which means leaning into that discomfort, and asking in a positive way what’s one thing the team can work on and change to get closer to being able to deliver valuable, working software at least every Sprint.
Yes, we do have to allow for human error, but we can also work on things we can do to reduce the likelihood of an error happening in the first place. The practices that people tend to use here come from eXtreme Programming (XP).
How well do you and the team understand these practices?
See lessPerhaps start there?
A book, podcast, YouTube channel to learn as a new Scrum Master
"Coaching Agile Teams : A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition"
“Coaching Agile Teams : A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition”
See lessHow to approach any team level problem using coaching mindset versus a delivery mindset?
I think it's not unusual to find senior developers with great technical skills, but who lack the competencies' needed to be effective leaders within a team. I'd suggest what you are looking at is more about local optimisation - what the individual needs in order to feel effective Vs what the team neRead more
I think it’s not unusual to find senior developers with great technical skills, but who lack the competencies’ needed to be effective leaders within a team.
I’d suggest what you are looking at is more about local optimisation – what the individual needs in order to feel effective Vs what the team needs to feel effective.
Chances are this is driven by the systems you have in place around individual performance reviews, promotion and so on., as well as what behaviours get rewarded with praise, positive feedback and so on.
That creates three areas of stress:
– people who lack the skills to be able to team effectively
– people who feel that teaming is a threat to their status
– people who feel helping others will impact in a negative way n their performance
Does your team have the psychological safety and skills to be able to discuss the behaviours in a retrospective without relationships being damaged?
If not, that might be a place to start.
See lessScrum Masters, what books have you read lately (agile or otherwise) that you’ve enjoyed and found valuable to your role?
My last 5 books have been: Corkscrew Solutions - Clark Ching (who does great small books about ToC) The Icarus Paradox - Danny Miller (how the success of businesses doom them to failure) Practical DataOps - Harvinder Atwal, which is also a great agile/lean/ToC primer The Fifth Discipline - Peter M.Read more
My last 5 books have been:
Corkscrew Solutions – Clark Ching (who does great small books about ToC)
The Icarus Paradox – Danny Miller (how the success of businesses doom them to failure)
Practical DataOps – Harvinder Atwal, which is also a great agile/lean/ToC primer
The Fifth Discipline – Peter M. Senge, on building learning organisations
Lean Software Development from Concept to Cash – The Poppendiecks
Outside of that, 5 recommends would be
Out of the Crisis! – W Edwards Deming
See lessAccelerate! – Forsgren, Humble and Kim
Wardley Mapping – Simon Wardley
Coaching Agile Teams – Lyssa Adkins
Team Topologies – Mathew Skelton, Manuel Pais
4 POs, 1 giant team, tons of collaboration issues, Please what can I do ?
I think experiments are a good thing We want teams to experiment with ways of working - that's basically how we uncover new stuff and challenge dogma. It's also how we break the mould of opinion-based win-lose debates on issues and HIPPOs (Highest Paid Person's Opinions) carry all the weight, and shRead more
I think experiments are a good thing We want teams to experiment with ways of working – that’s basically how we uncover new stuff and challenge dogma.
It’s also how we break the mould of opinion-based win-lose debates on issues and HIPPOs (Highest Paid Person’s Opinions) carry all the weight, and shift towards evidence-based win-win dialogues.
That said, when we experiment it needs to be based on empiricism; as W Edwards Deming said, we don’t collect data for “museum purposes” – we do it to guide business improvement.
It’s okay to challenge conventional wisdom on things, but do so on an evidence basis:
Key questions become:
What is the hypothesis we are testing?
What does success look like?
What does failure look like?
What will we measure?
How much data do we need to test the hypothesis?
This starts to get into how you want to measure performance as a team; there’s things like the DORA metrics, Kanban metrics and so on, but there’s also how your collective group of product owners are choosing to measure value, story-by-story or Sprint-by-Sprint.
That’s a whole different can of worms, but if they cannot define how they are measuring value delivered, then no-one can tell if this is helping or hindering your business…
See less