Scrum – Observations from Sutherland’s book

Alisha Parry recently read Jeff Sutherland’s book, “Scrum: The art of doing twice work in half the time.” Here are some of her observations that she shared with a work colleague.

1. Bugs take 24x as long after you wait to work on them. We have seen this even on Kronos, as we have previously discussed.

2. A new hire on the team dramatically slows down velocity due to needing to train them up and spend time working with them, [time] that would otherwise be spent on other sprint work.

3. Scrum for educators! I loved this section, especially coming from teaching previously. When I started reading the book I kept thinking how cool it would be to implement this in the classroom and then, lo and behold, they had a whole section dedicated to talking about this in the book. I think it’s great!

4. Happiness rating. We’ve already touched on this a bit too. It seems very important to have a true happiness rating and an idea of where employees lie on that rating scale to have a successful company.

5. Comparing scrum numbers [story points] to dog sizes. With switching over to a new ticketing process, hearing this really helped me understand how pointing our tickets should work. In addition, people are awful at estimating time!

6. (Discussion Point) To piggy back off of that, during our sprint plannings I feel there is a lot of time wasted on discussing pointing. Let’s say we throw 3, 3, 3, 5, 5. We then have a discussion, sometimes for a few minutes, about whether it should be 3 or 5. The book says anything within 2 steps (Ex. 2, 3, 5 or 3, 5, 8) should just be averaged. Our 3, 3, 3, 5, 5, would then turn into a story point at 4 points and discussion time would be at a minimum. It does say if it’s more than 2 Fibonacci steps (1, 3, 5 or 3, 5, 13), then the outliers (people) need to explain why they [voted that way] and discussion should be had around this before determining true points for a story. Averaging points seems way more efficient though, than the way we are doing it right now.

7. (Discussion Point) The section about Value was very interesting to me in its entirety, but it gave me an idea I wanted to present. I’m speaking mostly for my team when I say this, as I don’t know how other teams work, but we regularly have ideas for how to make things better, but no time to implement them during a sprint. For example, microservice consolidation, creating our new tracer bullets, etc. rarely have a place in our sprints. Product dictates what we do. I think teams would greatly benefit from a “Teams Choice” sprint once per quarter. This would even help in the long run with efficiency and teams would feel like they own what happens more often than we do now. We can definitely talk about this more if you’d like to, this is kind of a brief overview.

8. People are awful at multitasking and interruptions greatly slow down progress. This is coming from a team that has “data lag red flags” pretty regularly. When others are looking in not fully understanding what is going on. This happens to us a lot, because those looking in are seeking clarification or misunderstanding how severe the lag really is. There is definitely a lot of “interference” from others (Product, QA Managers, Support through QA Managers) that slow down our sprint progress hugely.

9. Piggy backing off of this, I found it interesting that the car building would have all bugs planned in the next sprint, not thrown into the current sprint. If it isn’t a dire need, it is held off and planned instead of interrupting the current work being done.

10 Observe, orient, decide, act. [OODA loop] Just in general, I liked this.

11. (Discussion Point) Kind of building off the happiness rating, I think it would be beneficial to have monthly/bi-monthly peer reviews. This stemmed as an idea from Valve as well. I don’t know exactly how it would be implemented, maybe through a similar survey to the pulse survey and the reviews get sent to managers? Not sure, but I think raw feedback from team members on other team members would give great insight to managers in areas they may not see and if it’s in a survey format it would give those who are on the quieter, more reserved side a chance to speak up.

13. Change or Die. Again, just like it in general.

14. Shu, ha, ri. Great concept for learning, implementing, and mastering.

15. Focusing on team productivity not on individual productivity. The worst team was 2000x slower than the best team. That’s crazy!

16. Keeping teams [within] 5-9 people. Connections are n(n-1)/2 which becomes way too much for our brains to handle.

17. When we talk about ourselves, we talk situationally, but when we talk about others, we talk about who they are personally. I know for sure I do this, but never actually thought of it this way before. It was eye opening.

18. People only have a set number of sound decisions they can make in a day!

 

 

« « Info for SurveyMonkey Survey || Agile Transformation – 2 » »