I gave one of six lightning talks at Cambridge Agile Exchange last night. Here's a quick summary of the others and, up top, my sketchnotes.
Brian Beckett spoke about three major problems of engineering management: goal-setting for individuals, metrics for teams, and people. People are worst, he said, but also people are the best, and in fact are the only thing. For Brian, software development is an art and its practitioners will artfully game quantification, so engineering managers must be art critics, and favour qualitative assessments.
Dani Oliver described how following his passion for agile approaches has led him from development through Scrum Mastery and into a role as a Release Train Engineer in the SAFe framework. And what is an RTE? He gave us his take on it: the keeper of (weird) practices, a breaker of the status quo, an uber Scrum Master, someone who cares.
Mariapaola Sorrentino described joining a Scrum team where commitment was low relative to delivery (in story points), velocity was all over the place, and cycle time was both high and highly variable. She visualised this for them, and dug into the cause: a PO who didn't insulate the team from outside interruption, and then made the current interruption the most important thing, and consequently built up a massive backlog of half-complete work. Forcing prioritisation, refusing interruptions, and heavily grooming the backlog lead very quickly to a major throughput improvement.
Kasiviswanathan Ramanathan described burndown charts and presented three styles of chart that typically indicate some kind of team anti-pattern. The team whose chart flatlines might not be breaking their work down enough, the team whose chart spikes frequently might be poor at prioritisation, and the team who finish their tasks before the end of the sprint is likely undercommitting.
Pete Gibbins finished things off by promoting the use of Alan Kelly's dialogue sheets for retrospectives. A self-declared lazy Scrum Master, Pete reckons that the sheets allow teams to essentially facilitate themselves through the stages of a good retro from setting the context, gathering and interpreting data, and deciding what to do. Quote of the night: "you read what's on the sheet and do it".
My own talk was People Problems.
Brian Beckett spoke about three major problems of engineering management: goal-setting for individuals, metrics for teams, and people. People are worst, he said, but also people are the best, and in fact are the only thing. For Brian, software development is an art and its practitioners will artfully game quantification, so engineering managers must be art critics, and favour qualitative assessments.
Dani Oliver described how following his passion for agile approaches has led him from development through Scrum Mastery and into a role as a Release Train Engineer in the SAFe framework. And what is an RTE? He gave us his take on it: the keeper of (weird) practices, a breaker of the status quo, an uber Scrum Master, someone who cares.
Mariapaola Sorrentino described joining a Scrum team where commitment was low relative to delivery (in story points), velocity was all over the place, and cycle time was both high and highly variable. She visualised this for them, and dug into the cause: a PO who didn't insulate the team from outside interruption, and then made the current interruption the most important thing, and consequently built up a massive backlog of half-complete work. Forcing prioritisation, refusing interruptions, and heavily grooming the backlog lead very quickly to a major throughput improvement.
Kasiviswanathan Ramanathan described burndown charts and presented three styles of chart that typically indicate some kind of team anti-pattern. The team whose chart flatlines might not be breaking their work down enough, the team whose chart spikes frequently might be poor at prioritisation, and the team who finish their tasks before the end of the sprint is likely undercommitting.
Pete Gibbins finished things off by promoting the use of Alan Kelly's dialogue sheets for retrospectives. A self-declared lazy Scrum Master, Pete reckons that the sheets allow teams to essentially facilitate themselves through the stages of a good retro from setting the context, gathering and interpreting data, and deciding what to do. Quote of the night: "you read what's on the sheet and do it".
My own talk was People Problems.
Comments
Post a Comment