In the Belly of the Beast: ScrumMastering for Team Hydra

In October of last year, I became the ScrumMaster for what is one of the best Agile development teams with which I have been privileged to work. That may sound like fluff to you but when you put together a team of five very senior developers­ who are dedicated to creating the best software using regimented Agile practices—you have to expect great things. I was brought on as ScrumMaster, only part-time for various reasons. The client was very familiar with the Agile process and technical practices and chose a technical Product Owner to act as the voice of the customer and the software architect.

The team, who called themselves Team Hydra, met the client for the first time in October and spent an entire day going over the high-level application architecture and product vision, from which an initial product backlog of stories was created. The initial backlog was dedicated to creating the development environment for the application as well as choosing the software languages, tools and database to be used in development. The Product Owner was especially helpful because he had a clear vision of the end product and the features the user would want, even down to which tools he wanted the team to use. This is quite a departure from most Scrum teams, where the Product Owner isn’t very technical minded and simply isn’t capable of providing guidance in such details as the language and database to use, what application to use for version control, etc.

One of my most memorable experiences ScrumMastering for Team Hydra was facilitating a session where they hammered out their team working agreement. This agreement made explicit such things as core working hours, coding and check-in practices, as well as the time for standups, sprint length and retrospectives frequency. Because the team was entirely comprised of mature Agile developers, Hydra decided to experiment with more advanced Scrum practices, including variable sprint length and even no story estimations. It helped that everyone in the team had worked with SolutionsIQ for quite some time and that they were familiar with each other and the Agile software development process. It was fun for me to facilitate the creation of the team working agreement.

IMG_1960Here’s a photo of what it looks like, in case you want to be inspired. Some things of interest to you may be:

  • Alternate standing while coding
  • Using the same developer VM
  • Using Vagrant to deploy development and Jenkins Nodes
  • Mob programming
  • ATDD (automated test-driven development), testing pyramid
  • Have fun

We started building out the infrastructure and were soon coding with bi-weekly check-ins with the client where the application’s progress was reviewed. The nature of the application is unusual in that there is a minimal user interface with most of the work being done on server-to-server communications. A Jenkins Continuous Integration (CI) server was set up with automated builds on code check-in to Github. All unit and integration tests are run on the build server and then automatically deployed to demo and QA servers. This followed what is standard procedure at SolutionsIQ for delivering high-quality code.

My experience as ScrumMaster has been very positive with Team Hydra. The name choice may strike fear in the hearts of those who remember Hercules’ challenges, but I think the team likes it because it sounds fearless. And that’s what they are: fearless. The whole team is mature in all the Agile practices and get along with each other well, showing respect for their colleagues and ready to tackle any challenge. I’m proud to be able to work with them. Because they’re so advanced and collaborative in Agile and XP practices, they don’t often need a ScrumMaster—but then again the best Agile teams never really do.