Agile Isn't Enough to Deliver Exceptional Software: An Interview with Sven Peters

Josiah Renaudin: Welcome back to another TechWell interview. Today I’m joined by Sven Peters, the lead evangelist for Atlassian and a keynote speaker at our upcoming Better Software West Conference. Sven, thank you very much for joining us. First, could you tell us a bit about your experience in the industry?

Sven Peters: In my twenty years of experience in the software development business, I've worked with a lot of technologies. Some don't exist anymore, but most are still out there—from embedded systems (what we now call IoT) to React for building web apps. Technology has changed a lot, but working with other people has been a constant in all of my projects.

Josiah Renaudin: Has software development gotten harder, or has it always been difficult to keep everyone in sync?

Sven Peters: Keeping everyone in sync has always been challenging, but it's gotten increasingly more complicated over the years as more people have been added to the process. For example, because software is now used by nearly everyone, UI/UX plays a much bigger role. That requires more designers. Additionally, software now runs on servers and users expect updates frequently. That requires software development teams to work more closely with IT and operations teams, support, marketing and many more.

Software today is a very collaborative effort between many teams, so it's incredibly important to keep everyone in sync and find a common language for getting work done across technical and non-technical teams

Josiah Renaudin: How tricky is it to deliver high-quality code at the breakneck speed people expect things to be developed in today? Are we sacrificing quality for the sake of speed?

Sven Peters: These days, we have much better tools to help with quality control. I remember times when manual testing was the only quality check of new software. Nowadays we write automated tests, do asynchronous code reviews, use pair programming, implement static code analysis, constantly monitor our services, roll out new software to a small subset of customers first and much more to prevent bugs reaching end users.

Is software less buggy now? I don't think so, but we find and fix problems much faster because we don't have such a long quality check phase anymore. Last month, for example, I had problems with an application from a large cloud app vendor. I contacted support and within just one hour the problem was fixed.

Importantly, I think we need to understand and carefully weigh the risks and benefits of shipping for speed. Not all issues can be fixed quickly. Security is incredibly important and needs to come first.

Josiah Renaudin: You argue that just being agile isn’t enough. Can you explain why that is, and what else teams need to do to succeed?

Sven Peters: Being agile is important. But often people mix doing Scrum, Kanban, or even daily stand-ups with being agile. Agile is a mindset that everyone involved in software development needs to understand.

The biggest problem is that it's quite an abstract concept. What do the principles and values mean for the day-to-day job of a developer? Doing things others haven't tried, coming up with new concepts for better engineering collaboration, or taking time to work on automating parts of QA helps software development teams be more effective. Every team, organization, and software product is different, and so should be your development.

Josiah Renaudin: How can you avoid meetings in order to speed things up? Does avoiding meetings hurt teamwork and collaboration at all?

Sven Peters: We all attend too many meetings. The first step in fixing this issue is considering whether every person on the invite list really needs to be part of a meeting. The second step is applying certain techniques to make meetings more effective, such as requiring an agenda, making sure people are properly prepared, encouraging a culture of staying focused and so on.

There are also a number of software products that can help eliminate some meetings by enabling people to discuss problems asynchronously, such as chat and collaboration platforms. In the end, we need to get things done; meetings are one way to achieve that, but they're certainly not the only or always the most effective way. We have to find a good balance between face-to-face communication and virtual collaboration.

Josiah Renaudin: What are the benefits of failing faster?

Sven Peters: Failing faster lets us fix things earlier in the process. It means both finding bugs earlier and fixing them, and running experiments to improve your software, internal processes, development pipeline, and final output along the way, as well as the decision to proceed, improve, or cancel it. The days of big planning phases are over, as are long-implementation phases and rolling results out to everyone at the same time. Small changes and improvements help you fail faster, inevitably helping you improve faster.

Josiah Renaudin : It’s become such a global industry, but we’re still adapting to working with people who are stationed all over the world. What are a few tips that you would give for team members who are trying to collaborate from different continents?

Sven Peters: There are a lot of tools available now that facilitate remote working: chat platforms, content collaborations software, code reviews tools, free video conferencing, etc. These work very well when working in similar time zones, but can become more challenging when working across time zones greater than six hours apart. I've worked in such a team for many years, so here are my tips:

• Meet frequently in person (when you can).
• Have feature buddies on the remote team to bond you together when thinking and working on the same problem.
• Share work progress consistently.
• Use collaboration tools that support mobile apps.
• Do state-of-the-development demos once a week with the whole team.
• Alternate regular remote meetings so it's not always a stretch for the same people.

Josiah Renaudin: Can you give one example from when Atlassian failed, tried a new concept, and kicked ass?

Sven Peters: We have a long-standing tradition of fostering innovation. In addition to our quarterly ShipIt Days, every employee gets “20 percent time” to work on their own projects to improve our products. That doesn't always work well for every team. We saw that some people who didn't use their time often ended up picking up the slack for others on their team who focused on their pet-projects. So instead we tried having regular innovation weeks for the whole team. That worked much better and made our developers much happier. The first team to implement this new approach shipped twelve features and improvements in two innovation weeks alone.

Josiah Renaudin: What central message do you want to leave with your keynote audience?

Sven Peters: Don't just try to copy all of the successful concepts from other companies or thought leaders. Look at your own development problems and focus on how to fix those. Kick-ass software development is all about constantly improving, so focus on the things that will make the biggest difference for your team and your end users first. 

Lead evangelist for Atlassian, Sven Peters has twenty years of experience writing code, leading teams, and sharing his experience with thousands of developers in more than twenty-five countries. For the past four years, Sven has studied software development trends inside and outside Atlassian, discovering the most important attributes that help teams effectively scale and drive innovation. Sven is a regular contributor to Atlassian’s quarterly ShipIt Days—twenty-four hours during which developers are free to work on a passion project (designing a dream feature, working with a team not their own, or replacing all the hot light bulbs in Atlassian’s phone booths with energy efficient bulbs).