Architech Solutions had the pleasure of sponsoring and attending the Agile Tour Toronto conference this year, which ran on 20th October at the Toronto Board of Trade. The event was fantastic, very well run with lots of great speakers throughout the day.

The keynote was by Martin Fowler who promised us, instead of one long boring presentation, three short borings ones. But they were far from boring! Martin has a way of presenting deeply technical issues in an engaging way, and clearly laying out what the ‘must do’ aspects are of Agile Software development, and why they’re ‘must do’. Here’s a summary of the topics, hopefully hitting some of his main points, though I’m sure not doing justice to Martin’s excellent presentations.

His talks covered three main topics: Semantic Diffusion (around Agile), Continuous Integration and Delivery, and the Value of Software Design.

Semantic Diffusion

Martin’s term for ‘broken telephone’, where an idea has spread throughout of community, but hasn’t stayed true to the original idea (more here). In this case, Martin was talking about the confusion around what planning and process means to an Agile team.

In summary, planning is just as important to Agile teams as it is to the traditional plan up front waterfall groups. The difference is that Agile teams plan throughout the process of software development. An Agile team accepts, and embraces, that requirements change will happen throughout the lifecycle of the development of software and planning is an ongoing exercise for these teams. By constantly taking these changes on board and re-planning after each sprint or iteration, real flexibility can be achieved. Martin calls this ‘adaptive planning’, and any successful project I’ve been on does this constantly regardless of the process or methods they’re following. After all, I don’t think anyone would make the case in today’s fast paced world that the requirements or needs of a business or its customers don’t change.

And as for process, Martin made it clear he feels an Agile team really needs to adopt the process themselves and constantly fine tune it to work for them. The key message is that Agile puts people first, which means the processes they use needs to be adopted and defined by them, and not defined for them as per Frederick Winslow Taylor and his Scientific Management ideas. Agile teams need to be able to work together closely in human terms. Developers (at least good ones) are smart, capable and over all creative people, and telling them exactly how to do something will not just cause friction, it will mean that you’re not getting the best from a group of people who you’re trusting to develop your software. What this means is you can’t force Agile on a team, they have to be willing to adopt it.

Continuous Integration and Delivery

In this section, Martin spoke about the importance of Agile’s demands to deliver a potentially shippable product after every iteration or sprint. Everyone has been on a project where integration all happens at the very end – and this can take a long time on a large project. This might mean integration into backend services, or simply integration back into a ‘main branch’ of code that represents the production system which occurs as a result of something called feature branching.

Integration is hard to do and fraught with complexities, almost always demanding changes in your code to make it happen. If you’re integrating a feature branch into a main code line, even powerful branching and merging tools can only go so far in helping with this, because semantic changes in the base code often aren’t noticed until testing is underway much later after the integration has occured.

Martin argues that if something is hard to do, don’t put it off till the end, do it more often. By integrating all the time, several times a day, we have small problems that are more quickly handled and headed off before they become larger systemic issues. It also means that our build is always working and features are always potentially shippable. Martin spoke about the importance of automated builds and build pipelines to help make this happen more effectively.

This discipline of constant quality and constant integration and delivery is requirement of Agile that can be hard for weak or in-experienced teams to manage.

Value of Software Design

The final part of the keynote was around the importance and value of software design. It cannot be understated how important good internal quality of software is to anyone who intends to continue to grow and build their application, or even operate it successfully over time.

Agile assumes that change is inevitable and embraces that fact. If we are to change software (and almost no application today will stay the same for more than a few months), we need to ensure that it’s internal quality is high enough to allow for this. If we hastily build code and ‘hack’ features into an application, we are building up what Martin calls ‘technical debt’ in the system. This is essentially a reduction in internal quality of the system that at some point will need to be paid off in order to improve, add to, or change the application. If we constantly build on top of badly designed and built software, we will quickly reach the point where the application is so full of defects, complexities and issues that it will not perform or be stable. Changing these kinds of applications costs far more in terms of time and effort than in applications with low technical debt. The cost in terms of operations and outages will also be far higher.

Making choices about going into technical debt is possible, as long as the team is aware that that’s what they’re doing and that there is a plan to pay off this debt at some point. Every team will go into some level of technical debt without planning it – after all, we are always learning as we develop software and always look back on what’s been built and realize there might have been better ways to do something. Weak teams, however, often go into technical debt without even knowing it and without planning to solve it. This is where experience and high quality ‘build it right’ teams really pay off. By building out code well early on and focusing on quality, we’re investing early to avoid the ever increasing costs of change in a low quality system. In fact, studies have shown that focusing on quality will reduce costs and save time in the long term, where as focusing on cost will reduce quality and increase costs.

And how long is ‘long term’ in terms of when technical debt and low quality will become a problem? It turns out that for most software teams, bad quality and bad design will become a problem within weeks rather than months. This means that if your software project is a few months long, before you’ve even completed the project technical debt will be causing you problems in continuing to develop a solution. The investment in quality, therefore, is an extremely short term payoff.

Martin makes the point that you can compromise on features, you can compromise on look and feel, but that internal quality is never worth compromising on. And here at Architech, we agree.

Summary

For me, the way Martin presented the thoughts on technical debt and good development practices really helped put into simple and concrete terms what the best teams I’ve worked on at Architech and in other places do well – and more importantly, why it’s truly so important. The conference had many interesting speakers, and almost too many seminars to attend, but was well worth spending the day there, with lots to learn. As David Suydam, Architech’s president, said, “well run events like this reflect well on the city, and it’s great to bring thought leaders in Toronto together, especially around something like agile”. We hope to see you there next year!