Scala | Ansible | Angular | SBT | ScalaCheck | Scrum ScrumMaster++ February 18, 2017

Neil Chaudhuri (He/Him)

LinkedIn

Anyone with a basic knowledge of Scrum knows the role of the ScrumMaster—to be a servant leader, to act as guardian of the Scrum process, to remove obstacles for the delivery team, to negotiate any tension between the Product Owner and the delivery team, to encourage the team to self-organize and be cross-functional, and so on. These are so well understood they’re almost clichés. The difficulty is learning how these abstract ideas apply to day-to-day software engineering.

For example, a common question is “Does Scrum permit a ScrumMaster with a technical background to help deliver features for the team he or she leads?” While this is a common practice and some teams have made it work, the general consensus answer is “No” or at least “Not ideally.” The primary reason is that a ScrumMaster can’t be an honest broker when resolving disagreements between the Product Owner and delivery team if he or she is writing code as a member of that delivery team. No one likes a conflict of interest, right?

However, there are other ways that a ScrumMaster with technical skills can apply them to provide significant value to the project and dramatically increase velocity without compromising credibility or the Scrum process.

Pay Down Technical Debt

Technical debt might be the biggest obstacle to productivity. Every development team remembers when either a lack of time or experience produced suboptimal design. In my own experience, I’ve known exactly where the biggest debt is, and it nags at me that I don’t have the time to tackle it. A technical ScrumMaster can branch off trunk and begin to address technical debt. For example, address all those TODOs in the code. Turn all those repeated code blocks into functions to stay DRY. Extract hardcoded values into configuration. Address all those compiler warnings and significant static analysis errors.

Particularly savvy ScrumMasters can do even more. If the code base uses an object-oriented language, look for opportunities for abstractions that can be expressed through design patterns or cleaner code utilizing concepts like encapsulation and the SOLID principles. If the language is functional, make sure functions are as pure as possible by limiting side effects. Utilize structures like monads and techniques like currying and type classing to maximize composability and reusability.

In the end, your team will thank you if you’ve promoted loose coupling by paying enough technical debt that the next big change doesn’t force everyone to work the weekend.

Speed Things Up

In their seminal book Lean Software Development, authors Mary and Tom Poppendieck describe seven principles—the first of which is Eliminate Waste. There are many forms of waste, but none is more frustrating for developers than waiting. Any good ScrumMaster will work to eliminate bureaucratic waste and will make sure the development team gets the answers it needs quickly, but a technically skilled ScrumMaster can do even more.

In particular, speed up the build. There are a lot of ways to do this. First, maximize the value from your build tool. For example, Gradle features a Daemon (enabled by default in version 3.x) that offers tremendous performance improvements. Gradle also lets you run tests and, as an incubating feature, even subprojects in parallel. Meanwhile, SBT was built from the ground up to run tasks in parallel.

Of course, these enhancements can only take you so far if the tasks executed by the build tool are inherently slow and/or unparallelizable. The biggest culprit is typically the test bed. Speed up the tests by applying the xUnit Test Patterns defined by Gerard Meszaros. Make sure unit tests really are unit tests where every dependency is ”doubled” (i.e mocked, stubbed, dummied, or faked). Also make sure that all tests, especially the integration tests where setup is expensive, share test fixtures by using the test framework to group tests into suites and/or using the facilities of the language—like with superclasses in Ruby or Java or traits or the Loan Pattern in Scala.

Then separate unit tests from integration tests so that only the former run with each commit while the latter run less frequently. Remember that only a representative subset of the tests—rather than all of them—needs to be run with each commit as long as all of them run regularly and often in continuous integration (CI). Every testing framework from RSpec to JUnit to ScalaTest to Go’s testing package provides ways to organize and categorize your tests. This adds a lot of value and fits perfectly in the skill set of a technically savvy ScrumMaster.

You can also speed up the build by removing tasks like documentation generation and static analysis from developer and per-commit builds. Static analysis should only run daily in CI; documentation weekly.

Beyond the build, look for ways to automate any manual tasks that are part of the development team’s workflow. Consult with the software engineers to identify where these opportunities for automation may reside.

Improve the Process

A technically skilled ScrumMaster can also improve the software engineering process. For example, you can use Angular or React to make REST calls to the APIs for your project management, source control, CI, and systems monitoring tools to produce a dashboard that presents all their data individually and mashed up to help identify the root causes of events. After all, a time series on this dashboard could show that a surge in bugs coincides with the absence of the Product Owner or a spike in technical debt when new engineers joined the team. That’s valuable information.

New development tools can also improve the process. A savvy ScrumMaster on a Scala project could introduce ScalaCheck to improve the robustness of the tests and to enable developers to write more tests faster.

Developers hate writing documentation, and as a result documentation is almost never current. That same ScrumMaster could also improve documentation by introducing tut so the Scala developers can write documentation that is compiled—thus always current—and run as part of CI. The fact it’s code makes writing tut documentation almost fun. Similarly Swagger, a tool that generates REST API documentation, runs off the existing REST endpoints in the code so that the documentation stays current. Introducing automation like tut and Swagger—along with manually editing the source code to keep the method-level documentation in, for example, Javadoc, RDoc, or Scaladoc current—will make developers much happier and more productive; and the documentation much better.

Another area where a technical ScrumMaster can really help the delivery team is with IDE integration. Most software engineers don’t enjoy context switching away from their IDEs to other tools, especially to perform tasks that they—right or wrong—don’t enjoy or consider meaningless to their work like updating the project management tool with their hours or updating the status of an issue in the bug tracker. I think any ScrumMaster should shoulder as much of that administrative burden as possible, but a ScrumMaster with development experience can do even more to fill that gap by leveraging integrations with leading software engineering tools most IDEs offer out of the box. If you enable developers to view the project management tool, source control, the CI dashboard, the bug tracker, the continuous monitoring dashboard, and other tools without having to context switch away from their IDEs, you will ease their administrative burden and maintain the productivity that context switching always compromises.

One last really important area where a technically skilled ScrumMaster can dramatically improve the process is in DevOps. It demands a lot of work and an organizational commitment to build a mature DevOps practice, but you can still take incremental steps to lead your team there. Augment your CI pipeline with infrastructure as code to create a continuous delivery (CD) pipeline. Learn how tools like Vagrant, Ansible, Docker, and Kubernetes can dramatically increase your velocity. It will likely take more than the efforts of one ambitious ScrumMaster to build a robust CD pipeline for the team, but you will be surprised at how much more productive everyone will be with just a little hard work applying your skills to DevOps. You will also likely impress the Product Owner, who will be happy to devote sprint capacity towards continuous delivery in the future.

This is a long post, but these are just a few of the ways a technical ScrumMaster can add significant value to the team, the product, and the process. Of course discipline is critical to make sure that changes to the code don’t break the tests and that they seamlessly merge with the new features built by the developers on the more conventional Scrum path, but never doubt that a ScrumMaster can apply technicals skills in a manner entirely consistent with the Scrum process.