Bruce Chalupsky

Since 2010 I have been the Scrum Master for 3 organizations,  the most current assignment beginning in 2014, working on 6 separate products, working with co-located and offshore teams.  I led the effort to introduce tasking as a standard practice, and coached new product owners on our TC4C product.  My efforts helped teams achieve high accuracy and tight consistency with estimating.  Our department underwent a Digital Transformation to become a pure agile shop and training the staff to become certified by Scrum Alliance.  I also completed training for Professional Scrum Master with Scrum.org.

Prior to TIS my exposure to Agile and the underlying Scrum methodology working as the role for two mobile development offices, the first of which ran a version of Kanban, the second was beginning a Digital Transformation.  While the first group was in a constant state of emergency, the second wrestled with the larger organization that only saw the development process in terms of manufacturing.  These two experiences helped me to understand the reason to apply a clean Scrum, and the antipatterns that develop when it isn't.  This helped me to develop of focus on protecting and coaching my team, to identify antipatterns such as heroics and hour-measured story points.  As well as the importance of dedicated teams and focus for the SM role. In these roles I saw the demonstration of the truism that Waterfall is only successful in less than 33% of the projects where it is implemented.

I am especially dedicated to root out heroics, as this is unsustainable for the individual and organization alike.  The team falters under high-pressure and the organization gets reductions in quality.  Keeping stakeholders and Product Owners disciplined under the inverted triangle of fixed time and budget balances the need for the organization to produce quality product and the team to manage the balance of work / life / quality.  Seeing two contrasting examples where the Scrum Master was used as a task manager, being expected to drive a team to completion with after-hours efforts, vs another team that was defended by a resource manager that repeatedly pushed the leadership to see the pitfalls of heroics.  The second team consistently produced more and better code, as well as had far less turnover.  Turnover also produces the negative effect that it slows the team down as a whole, even when the position has been replaced.  The new resource demands time from the rest of the team to get up to speed, further impacting velocity, accuracy and consistency.

To maintain this balance for the team, I get to know the personal workload each resource can commit to reasonably.  Keeping in mind the complexity and risk behind each story.  This involves working with the team members to break down their story into tasks that it would take to complete the story, and to ask the question if the story meets the Definition of Ready.  This has had the added benefit of discovering missing use cases and edge cases that were not originally accounted for.  Many of my teams found this refreshing to be able to either reject or negotiate a story around a story’s requirements.