As an Agile coach and software engineer at Software Design Solutions (SDS), I had the opportunity to attend the deliver:Agile 2018 Technical Conference in Austin, Texas from April 30 – May 2. It was an incredible experience, and I thought I should share my top takeaways from this outstanding event.
The Agile Alliance holds two conferences each year. The main Agile Conference focuses on the big picture of Agile development and the processes involved. The deliver:Agile Technical Conference was started a few years ago with a focus on the more technical side of Agile. Attention is given to the doing, building, and creating side of the Agile methodology.
At SDS, we are working with many clients who are interested in moving towards Agile development, but most want to test the waters with a small team before committing too much money to a larger organizational transition. This event provided a lot of information about deploying the Agile process across small teams, making it an ideal learning experience for me to bring to our clients.
Here are four topics with the most valuable information I can bring back to our clients:
Home DevOps: Doing all the right things on a small scale
This was my favorite session in the conference, as I think it will help me bring the biggest return to our customers. The key lesson from this session was methods we can use to build prototypes quickly, and in such a way that they can easily be turned into full-sized projects as needed. With effective rapid prototyping, no prep work is required to begin large-scale development. In this session, I learned how to incorporate larger DevOps ideas and strategies into small projects. Continuous Integration (CI), Continuous Deployment (CD), and automated testing and builds can all be used on a smaller scale. With smart planning, we can reap the benefits of a DevOps approach even if we are working alone, or in small groups.
Unit testing and test-driven development
Several sessions over the course of the conference covered unit testing. Before these sessions, I had considered unit tests to be about assuring code functionality and quality. I learned to look at them differently—they’re about more than code function. Good unit tests need to communicate how a given piece of code is supposed to work, and viewed as documentation for future developers. Six months or even two years from now, a developer who has never touched the software should be able to read through the unit test and understand what the code is supposed to do—it’s about planning for the future. There are even tools that can transform unit tests into actual API documentation.
The first session on this topic was entitled “Unit Tests as Specifications.” I learned effective techniques for test-driven development (TDD) to support building useful tests and quality code. This session focused on the communication side of unit tests and how they need to tell future developers about the code.
Another session on unit tests was “Communicating with Code: Writing Tests that Don’t Suck.” The discussion focused on how to write tests that go beyond verifying behavior to sharing information about the program interface and how it is used.
The final session I attended on this topic was “Test-Driven Development with Cucumber.” The speaker discussed how Cucumber tests can be used as a unit-testing framework as an alternative to JUnit. This approach allows you to separate the test structure from test implementation for maintainability.
Unit tests can be written in such a way that our customers (the business side) can understand them. If a customer has a feature requirement, they can write it up using business language, after which it can be translated into technical unit tests that can be used for development. This approach closes the communication gap between development and the business side. Customers with specific needs—especially ones that are necessary to generate profit—can easily communicate with their developers, using language and terms they understand. The result? A much better end product that will earn revenue rather than sink costs.
Everyday beliefs come true—creating greatness through the stories we tell
A big part of Agile coaching is communicating with teams and understanding how to build a team. This presentation dove into the dynamics of communication within a team and the traditional roles people often fall into when working in a team environment.
I learned how to step back and shift my mindset to overcome these traditional roles and foster better communication and teamwork. In the past, I may have been quick to step in and tell a team member how to solve a problem (or solve it for them), but now I know how to empower that individual to advocate for themselves. This builds a stronger team, and a stronger team yields better results.
Unlocking Blockchain adoption—unchain your company’s brain
The SDS team has been exploring new ways to use Blockchain, so this session was interesting for me. The focus was mostly on what the technology really is and how it can be incorporated into an Agile environment. The technology lets organizations share data securely, establish a collaborative environment, and create solutions through small, iterative changes—approaches that line up well with the Agile methodology. Two interactive simulations were used to convey this information, making it a fun and enjoyable session.
The deliver:Agile 2018 Technical Conference provided me with a new perspective and new techniques that I can bring back to SDS and our clients as an Agile coach. I look forward to attending the event again next year, or taking a step back to focus on the larger process at the main Agile Conference. The team at SDS is focused on constantly gaining knowledge so we can continually provide better service to you, our clients.
