Subscribe to ...considered harmful
4 Comments
I work on a small team - three people - mostly focused on maintaining and improving the user portal for a large non-profit startup accelerator. It's an interesting codebase, with some interesting problems issues opportunities, and it keeps us pretty busy. One of the many things I like about my team is a fairly compulsive commitment to the Scrum way of working. I'm not going to try to explain Scrum here - people make a lot of money writing books about that - but among other things, it means we work in short sprints, and at the end of each sprint we get together and talk about how we did and what we should focus on to do better the in the next sprint. This item of focus is written up as a ticket for the next sprint, and is called the "kaizen" for that sprint. Over the course of the sprint, we try to apply this, and then we keep it around for the future. The kaizen can be anything we choose, but it should be about improving our velocity in some way. Since "work faster" isn't really a useful meditation, and "work longer hours" doesn't really scale well, we usually find ourselves addressing issues that impeded our progress in the previous sprint or occasionally introducing new ideas that we think might make things faster, easier, or more fun.
I recently had reason to review some of my team's old kaizen tickets, and it occurred to me that what I was reading was the history of the fine-tuning of a team, and that this could be interesting and useful reading for other developers and people in the pipeline to become developers. There's a lot of talk about what sorts of things constitute "best practice" and how people ought to work together, but it's harder to see this sort of biography of a team in regular snapshots. So over the next few weeks, I'm going to offer up exactly that: I'm going to discuss the ideas for "good improvement" of our process and velocity: what they were, what motivated them, and how they worked out.
As a preview, I've exported the list of Kaizen tickets going back to Sprint 6, which is the first one I've found. Here's the list:
I recently had reason to review some of my team's old kaizen tickets, and it occurred to me that what I was reading was the history of the fine-tuning of a team, and that this could be interesting and useful reading for other developers and people in the pipeline to become developers. There's a lot of talk about what sorts of things constitute "best practice" and how people ought to work together, but it's harder to see this sort of biography of a team in regular snapshots. So over the next few weeks, I'm going to offer up exactly that: I'm going to discuss the ideas for "good improvement" of our process and velocity: what they were, what motivated them, and how they worked out.
As a preview, I've exported the list of Kaizen tickets going back to Sprint 6, which is the first one I've found. Here's the list:
- Kaizen: Tickets For All Work
- Kaizen: More Demonstrative Sprint Review
- Kaizen: Automate rather than repeat
- Kaizen: The Cave and the Fishbowl
- Kaizen: Fewer Boulders More Pebbles
- Kaizen: Two heads are better than one
- Kaizen: Testing, testing, 1, 2, 3...
- Kaizen: New Scrum Master!
- Kaizen: Tidy
- Kaizen: Get Some Rest
- Kaizen: Manage The <oink> Interrupts
- Kaizen: Cerberus - Guarding the Gates of the Interrupt Bucket
- Sprint 18 Kaizen: Zen Kaizen.
- Kaizen: Synchronize with Stakeholders
- Kaizen: Bug-Backlog Balance
- Kaizen: Smoothing the Estimation Meeting
- Kaizen: Improving the Code Review
Categories: Uncategorized
Share This Entry:
4 Comments On This Entry
Page 1 of 1
modi123_1
15 October 2015 - 06:59 AM
So a slightly re-purposed six-sigma sans all the nasty lay off bits? 
CTphpnwb
18 October 2015 - 06:13 PM
We do sprints/scrum where I am. I'm not a fan, but I don't dislike it either. I just see the whole thing as a management tool that really has little to do with actual coding, other than as a starting point. As with most management tools, it can be helpful or harmful to the process depending on the participants (management included) and the job at hand.
jon.kiparsky
26 November 2015 - 08:30 PMQuote
I just see the whole thing as a management tool that really has little to do with actual coding, other than as a starting point.
I guess I can agree that scrum doesn't have much to do with actual coding, in the sense that it can be applied to a variety of processes with equally good effect. Basically, if you have a small team of people who are largely cross-functional in their work, and you really do scrum - not just pick and choose the bits you like - then you're likely to get a good improvement in your velocity. Of course, it's also important that the people on the team care about the work and actually want to improve their velocity. I'm not sure if it would be very useful for people who didn't find their work motivating, but I don't really see why you'd want to work with those people - or be one, I suppose.
The important thing is that you do the whole thing. Scrum isn't just sprints and standups. It's the estimation meetings, it's the post-sprint retrospective, and to a large extent it's the kaizen. The whole point of scrum is to get better at what you do, and this doesn't happen unless you sit down with your team and think about how things have just gone and what you can do to make them go better. This is where the improvement happens - without it, yeah, you're kind of wasting your time.
jon.kiparsky
26 November 2015 - 08:34 PMQuote
So a slightly re-purposed six-sigma sans all the nasty lay off bits?
Wouldn't say so, honestly. I'm not sure what six-sigma amounts to in your world, but I've always had the impression that it's a system based on imposing metrics on a team from above, while scrum is about teams agreeing on metrics internally and using them to reduce friction and improve their effectiveness.
Page 1 of 1
Trackbacks for this entry [ Trackback URL ]
Tags
My Blog Links
Recent Entries
Recent Comments
Search My Blog
0 user(s) viewing
0 Guests
0 member(s)
0 anonymous member(s)
0 member(s)
0 anonymous member(s)
| 