My organization has been using Agile/Scrum in one way or another for several years now, and much of the class felt like a review. But, as the class went on, I realized just how much we had modified “textbook” Scrum to fit our needs, and it gave me some interesting moments of introspection relating to what that tells me about our organization and the way we do business. That may not be the value most people expect in taking a class, but I tend to find that the biggest wins from formal training aren’t usually in direct addition of knowledge (“I know Kung Fu“), but rather in being forced to think about things in new ways, or in the side conversations you have the luxury of having since you aren’t at your desk focusing on getting something done.
I gathered a few notes during the two day course, and figured I’d write them up here.
- The slide on project success/failure predictors was excellent (source). There are managers out there who like to think if they just had harder-working or more creative engineers their projects would magically improve, but the truth seems to be that you can’t tell much about success or failure of a project by the competence of the staff. A project with clear requirements and executive buy-in is likely to succeed, regardless of the staff.
- Scrum is not predictive. As someone who has been in conversations about the benefits of using team velocity to accurately predict future release schedules, it’s a useful reminder of what problems scrum is intended to solve and how.
- Having planning on Mondays and demos on Fridays is actually an anti-pattern, as most absences are on those days. Well, oops.
- The idea of a “story time” meeting (as opposed to pre-planning) appealed to me, and I think I’m going to try to figure a way to work it into my flow. In general, I know I need to invest more in backlog grooming for the good of my team.
- Some of the discussion around how Scrum can scale were interesting to me, especially the discussions about Product Owner Working Group, Chief Product Owners, and other types of working groups. It’s an interesting segregation of meetings relating to roles which I would like to see explored more.