DFW Scrum’s July MeetUp

We are going to try and get better at blogging about our meeting and some key take-aways to help improve the conversation for those who could not have joined us (or are not even in Dallas). I am sure as we progress these will get better, but here is our first try.

We met on TUE 7/17 6:30PM at Improving Enterprises to discuss how to handle changes to the sprint (within the sprint itself). It turns out that there were even more granular discussions that needed to happen, so we decided to break-out into to groups and discuss the various topics at hand related to the main topic we all came to learn about.

Our meeting started with Charles Bradley sharing his decision tree diagrams on how to handle sprint changes (bugs or scope), while these are certainly not all-encompassing, they are a good starting point/framework to help teams through that process (thanks Charles!). The question really is how can we embrace late breaking change in our sprints, isn’t the point of Scrum to harness change for the customer and embrace it? It turns out however, that there is a point where too much change can happen and you can’t get anything done.

Production support issues were usually the most common reasons. We don’t want those, but in reality, we all have them. Scrum is just exposing the problem on our software, so what we really need to do is determine why are there so many production support issues and solve the root problem, while in the mean time determining the best process to expose them and manage the work. Gary posed a good point as well in that “What’s the affect of your sprint length in your ability to respond to change?” If you have a month long sprint, it is really difficult to ask people to wait 1 month before you can enact their change. We had great discussions about this and the perfect sprint length, the reality is that it depends on your organization and context. 2 weeks seemed to get the most votes for the best sprint length.

We then decided to pick a few topics that were in the air and have break-out sessions on them. So here are the topics:

Sprint Length and Change: Gary McCants

  • Tendency is to pick long sprints because the business is used to long implementation times. No one really believes they can accomplish anything in short iterations.
  • One week is can be too short to be effective, this can sometimes deflate your ability to deliver
  • There is value to change control, determine how robust it should be. Change control is embodied in the Scrum process itself (rapid feedback).
  • Many organizations are challenged with regulatory compliance and state they can’t be Agile. We discussed how this is not true, you need to determine the requirements of regulation and build that into the process.
  • How do you handle Architectural changes in Scrum? Should we count velocity for large changes or simply allow it to be 0 and naturally reflect our ability to deliver new features. A big debate ensued on this one and everyone had great points (one way or the other).

Last Responsible Moment for Change: Mike Abugow

  • This is a challenge when maintaining a legacy system in business, as usually the system is older without many of the automated scenarios that newer systems can present
  • Perhaps your organization is better at being a 60/40 split (60% new development, 40% legacy support).
  • Split your commitment up on the team for a % of their time on new product and fire fighting. The first 4 hours of the day will be on new product, the last part will be the fire fighting.
  • Scrum and Kanban are work management systems, you still need engineering processes and systems (continuous integration etc…).
  • An interesting statistic was explored for those who are in legacy situations and struggle with changes in the sprint. 1/3 of your folks will be on board with Scrum, 1/3 will come around to it, and the last 1/3 will never embrace it. It’s the latter 1/3 that we have to find ways to support/manage in the adoption process.
  • In the end, Scrum is there to expose the problems, so if you are constantly changing your sprint, there are likely pointers to product planning or poor system engineering. Either one can be improved.

User Story Refinement During a Sprint (Sprint/Scope Change): Ty Crockett

  • We didn’t get everything at the beginning of the sprint, but that’s ok, we don’t expect everything will be perfect and known (that is really the point of Scrum).
  • Organizations have to be able to let the team make those changes in the sprint as design emerges
  • There is a certain amount of risk and ambiguity in taking on a user story. We understand that, and inside the sprint, the team has to address those issues as they arise
  • Capture the big picture for the business, but there is minuscule things that are not understood and are addressed within the sprint.
  • Co-located teams have a much better time dealing with this kind of thing
  • Having a Product Owner with you at all times helps in driving those conversations more often
  • Scope changes should be embraced as both engineering and product owners discover more as we start working on the user stories. We don’t want big sweeping changes, but better refinements are great.
  • Small stories are very valuable, there is less risk (less ambiguity), and the act of breaking the stories down actually helps in breaking those unknowns down.
  • Also remember that if story refinement causes problems acutely, it is probably ok, if it is chronic, then there is something likely broken.

The Team is Not Finishing the Sprint: Jay Packlick

There is a gap from what we committed to completing vs. what we are actually getting done. This is exposed on our burn-down chart, so what is our play? Jay wrote a blog post on this subject, 25 plays that help us decide what to actually do when we know we aren’t going to finish. Great stuff Jay!

Production Support and Changes During a Sprint: Charles Bradley

  • Let’s determine the cause of shifting priority, each new bug is an emergency.
  • Go through Charles’ flow chart to help deduce what actions we might take for each bug (or scope change).
  • A decision tree helps prioritize the bug.
  • Assess the size of the impact / change the business is requesting.
  • Try to make sure you are working on one thing at a time, then you can give people options to pull something out when they want to put something in (Limit WIP).

A big thanks for those who participate and especially the ones who facilitated the break-out groups. I think most of us had a great time!

About these ads
This entry was posted in Meetings, Scrum by Lance Dacy. Bookmark the permalink.

About Lance Dacy

I am currently the Director, Program Management for Active Network. Fellowship Technologies was acquired by Active in Feb 2011. I am adapting our adoption of Scrum to the larger Active. I needed an outlet to bounce ideas, gain development knowledge, and learn from the wisdom of the crowd. I decided to start the DFW Scrum User Group in January 2009.

2 thoughts on “DFW Scrum’s July MeetUp

  1. Charles here — one other really great takeaway from our break out group that I liked was something I think Joshua said. It was along the lines of remembering that a seemingly simple change in code (for instance, a one liner) can cost the company quite a bit in costs and risk in terms of delivering that one liner to production. While Agile organizations should always strive to reduce said “delivery costs”, the current *total* delivery cost of a seemingly small change should always be considered when making a change due to a production support issue. Said another way, the cost to fix is almost always much greater than when a programmer says “It’ll take me 10 seconds to fix this one line of code”. There are interruption costs to the development team as well as all other affected teams, testing costs, documentation costs, signoff costs, dev ops costs, code repository costs(branching/merging), etc etc etc. In summary, when deciding to classify a production support issue as “critical” (drop what you’re doing and deliver it now!), we should strive to more precisely portray the *total* cost and make it visible to the decision makers. The decision makers can then weigh what they know about the delivery costs against the business value costs/benefits and make a better decision.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s