The Adventure Begins

 

You might recall previous posts where I stated that making the transition to Agile can be challenging?  Well, this is where I give a personal example of my experience as the company I work for makes an agile transformation.

I was recently asked to be ScrumMaster over a mobile project.  Okay, it would probably be more accurate to call the project a program, and to call myself an agile coach, but that is not how it was presented.  Our framework is Scrum-like, but given the following conditions, I can't really call it by-the-book Scrum.  However, that does not mean we're not going to make it as Agile as possible.

• Six developers; two local, four off-shore.
• 4 product owners
• iOS and Android versions of each product.  Would that be four products, or eight?
• These are ongoing maintenance efforts

I joined the project team on the last day of the Sprint.  It was a 45 minute meeting where three different sprint backlogs were reviewed and two features were demoed (is that a word?).  A sprint retrospective was not held.

I know, some of you are probably ready to tell me how agile we're not and how I need to fix things, quickly, but would that be in the spirit of agile?

Currently, we are meeting 3 days a week for 30 minutes to an hour, on a video call with developers in three different locations.  Sprint planning is on the fly, and sprint retrospectives have not been done in a while.  Among the areas where I have identified that we can make improvements are:

• A consolidated story board and sprint backlog
• Potential changes to the meeting schedule
• A unified workflow across all products
• Product roadmaps
• Standard definitions for the following, across all products, since the developers all work on more than one product
  • Definition of Ready
  • Completion Criteria
  • Definition of Done

I've created a consolidated story board and sprint backlog, and we've started talking about the other items.  I intend to have a more formal discussion about these items during the retrospective, next week.  I could try to force changes in all of these areas, at once, but I think that would do more damage than good, not to mention that the team would spend more time on process improvement than development.  The team was getting work done before I became the scrum master agile coach.  Some people might have thought things were a little rough before, but change doesn't guarantee they won't continue to be rough; they'll just be different.

I am aware that there are times when it is best to just rip off the bandage, but my intent is to treat my team like a high performing team.  There are changes that can be made, sure.  Scrum has a process for fine tuning team processes, called the retrospective.  I will use this tool to make recommendations to the team, as well as encouraging them to identify areas where we can improve, and then let them decide the changes they want to make, determine the priority of the changes, and establish their own cadence in making those changes.  The collective team may have better solutions than I could come up with on my own.

I'm ready for this adventure and look forward to working with my team.  I'll share more as they become the high performing team that I know they can be.