Register NowConsultingProfessional Training

Videos

I was asked this question in a thread at LinkedIn

The answer: “Yes, …IF…¨

  • 00:20 Yes, tasks can be modified throughout the Sprint. *IF...*
  • 00:45 Scenario 1
  • 01:20 Sprint Planning
  • 01:45 Decompose the Sprint Goal into Tasks
  • 02:24 Mid-Sprint Adaptation of the Sprint Backlog
  • 03:11 Discontinuous Improvement
  • 03:38 Scenario 2: An Analogy
  • 03:46 Product Vision
  • 04:40 Product Goal
  • 05:30 Sprint Goal
  • 06:06 Product Backlog Items Selection
  • 06:46 Sprint Backlog Tasks
  • 07:12 The Original Question: Return
  • 07:56 Developers change/update the tasks
  • 08:20 Sprint Goal and PBI selection has not changed
  • 08:49 Common pitfall! (Don't change the Sprint Goal)
  • 09:30 Conclusion 1: Product Backlog is different than Sprint Backlog
  • 10:23 Conclusion 2: Developers *own* the Sprint Backlog
  • 10:52 Outro

I was asked "What Do You Think About Story Points?"

I went for a walk with my dog and recorded a few thoughts about the concept.

  • 00:47 What is a User Story?
  • 01:28 The Product Manager's Dilemma
  • 01:46 Time-based estimation
  • 02:10 Estimating creative work
  • 03:00 Relative/Points estimation
  • 04:04 Break the habit of time-based estimation
  • 04:29 Jira ¯\_(ツ)_/¯
  • 04:45 Avoid using Story Points to calculate "Velocity"
  • 05:05 Think in terms of SEQUENCE
  • 08:07 Story about a team and their stakeholders
  • 11:00 The lesson learned

The role of the Scrum Master is often misunderstood. It’s helpful to consider WHO were the early adopters? What was their interest in Scrum? What did they bring to the role of Scrum Master?

Try to imagine 1995 through ~2005. It was common they had a well-established career. They had been a manager of teams for many years. They were likely to have founded a company of their own. They were likely to have had 10 to 20 years of software engineering experience. And, with significant in-the-trenches experience, they developed an interest in mentoring others.

If your Scrum Master (or if you're a Scrum Master who) has limited experience, limited scope, limited authority, and limited influence regarding organizational design…it will help you to consider the historical context of Scrum and the role of the Scrum Master.

Let's go for a walk…

  • 0:47 People have a skewed perspective of the role of the Scrum Master
  • 1:38 Job descriptions call for 2 or 3 years experience
  • 2:04 Maybe they've been a developer, or experienced project manager
  • 2:43 Systemic misunderstanding
  • 2:52 The early adopters
  • 3:40 The early majority adopters were…
  • 4:48 The late majority adopters believe…
  • 5:31 I was introduced to Scrum in 2007
  • 6:10 I saw in it a way to mitigate risk and minimize waste
  • 6:36 Imagine a Scrum Master between 1995 and 2005
  • 9:54 Scrum Masters are were able to negotiate org change
  • 10:19 Embody the values of Scrum
  • 10:35 If you find Scrum Masters have limited authority…

People often reach out to me - they're trying to decide whether to take a Scrum course or a Kanban course.

  • 0:23 Teams struggle to deliver frequently
  • 1:10 They're doing 100 things simultaneously and everything takes 100 times as long
  • 1:38 Scrum might be a great starting point
  • 2:16 Kanban might be a great starting point
  • 2:58 Test whether you're meeting customer's needs
  • 3:20 That's what Kanban looks like
  • 3:28 It's very pragmatic and can be implemented immediately
  • 4:00 How does the team evolve how do we adapt our working agreements
  • 5:21 There are at least two ways to achieve greater agility
  • 6:31 Kanban is perhaps a gentler change
  • 7:18 Call me, let's talk about it

“Scrum is not working in today’s software engineering industry.”

That is a little like saying: there are high rates of obesity in society, so that must mean healthy foods aren’t working. But clearly there are counter-signals that are causing obesity and preventing people from eating a healthy diet.

If Scrum isn‘t “working” in today’s software engineering industry, then perhaps there are counter-signals in the industry that are preventing teams from employing Scrum effectively.

Let's talk about 3 common counter-signals:

  • 00:00 "Scrum doesn't work here." (Common Complaint)
  • 00:20 Counter-signals
  • 00:30 Common pitfalls
  • 00:44 "Open Office" floorplans
  • 01:35 "Shared Service" groups instead of cross-functional teams
  • 02:09 Financial gates that reinforce the waterfall
  • 02:37 Learn to release funds for business outcomes
  • 03:12 Scrum is not a Silver Bullet 03:43 How to achieve the intended results of Scrum
Back to All Videos