Are you Doing agile or Being agile?

There seems to be wide acceptance that Agile development methodologies are more effective than either the chaotic or Waterfall methods. Even the guy that first described Waterfall, Winston W. Royce, described it as "risky and invites failure" because of the absence of iteration. If only people had read that far.

Scrum is an iterative methodology that importantly includes an element of continuous improvement by way of the Retrospective. There's a wide variety of on-line training around scrum, the roles that people play and the ceremonies, but what of the culture? How does embracing Scrum change a development team and the wider organisation.

The changes to the development team are thorough. The expectation is that each feature will initially be delivered to an MVP, and that over time, as the product matures, some requirements will evolve while others will emerge. To be agile, you have to have CI, and you have to have tests. You rely on your tests because as requirements evolve, you will have to change the code that you wrote yesterday. In fact if it's code you wrote yesterday, that's easy. What you need to worry about is changing code that someone else wrote 6 months ago. If you have good test coverage, you can make changes with confidence, if you don't you're in trouble and the chances that you'll introduce a bug or break a feature that was previously working become sky high. Teams that are agile write code that is easy to read, giving the next developer confidence that they know what's going on, and teams that are agile maintain high test coverage to prevent regression.

If you don't read your code to yourself and fix up the naming so that it's clear and reads well, you're not being agile.

It takes discipline to reject stories that aren't correctly specified, it takes discipline to write just the code that implements and tests the User Story. It takes discipline to write a solution that is no more complex than the problem it's solving.

Outside of the Development team, probably the largest change is with product, but I'm not talking about their day-to-day behaviors,the JIRA gardening, the acceptance criteria. those things are doing agile. Being agile is aligning the developers with product. Making a product team that is funded on the understanding that they'll create the right product for the market because the product-oriented members of the team have an innate understanding of the customer's needs. Delivering a long lived product means long lived delivery, which brings us back full circle to code craftsmanship because a team that doesn't invest in refactoring, naming, test coverage, or design that supports change without fluff is not going to deliver at a sustainable, constant rate through the life of the product. As a matter of fact, I'd love to hear from Product people about this. If you were given the choice would you rather development teams delivered code without tests, craftsmanship or good design, so that they can deliver quickly at the start of a product, in the knowledge that delivery will inevitably slow down? Or would you rather have code delivered that was crafted well, was well tested, and supported a constant speed of delivery throughout the (5? 10? year) life of the product?

Ceremonies, JIRA tickets and scrum roles don't make you Agile. That's doing it, but it's not getting it.

Being agile means a having a real relationship with your customers, a desire to provide a solution that addresses their real requirements, and aligning your business and funding around products and the cross-functional teams that deliver those products. It means changing the way you deliver code so that you can support a product with a 5 or 10 year lifespan without getting into such a mess that at some point someone cries "REWRITE!".

A familiar example of loose coupling from within your organisation

We know that loose coupling is a good thing, Whether you're building SOA services or microservices, you know that tight coupling between components leads to problems, not least in production, and especially as load increases. If we can reduce coupling we can reduce those problems or even resolve them completely, but how do we do it? How do you design components that work together to form a system, but yet don't depend on each other?

The first of the "Four tenets of service orientation" might help here. As Microsoft describes it:

"Service boundaries are explicit. Services are discrete units of operation. They perform one task and that task alone. Each service should be able to stand alone with no external dependencies on other services. This is what is meant by "loose coupling." "

But for me the explanation of this tenet is a bit extreme. If we create services that stand alone and share nothing, how do we expect them to combine to form a system that delivers business value? Our services need some level of coupling in order to function as a system, That's why we discuss loose coupled components rather than decoupled components.

At a recent Dublin Microservices Meetup, @Farmar presented a tale of SOA experience and wisdom that he feels we can't  afford forget. At the same meetup, @Stilkov presented a view that microservices must be useful and the UI must be a first class citizen in any architectural plan. Both talks contained versions of the same slide. Something like this:

Services as vertical slices through the tiers of the traditional architectural diagram.

But why does this help and how does it help achieve lose coupling? How does having encapsulated verticals result in loose coupling?

Stepping back to the real world, you (probably) work in a technical team for a company that has an HR department. Both Tech and HR have a contract with the business. The Tech teams' contract is that they'll deliver quality software to provide technical solutions to their customers. The HR department's contract is (let's say) that they'll recruit quality people to the business, deal with contracts, salaries and performance reviews.

Now consider the qualities of those teams. They are separate, they operate independently, capturing and storing their data separately, yet together, they form two elements of a system (the company). They are loosely coupled.

For example, if the Tech team is outsourced to Kiev, the operation of HR is not affected. Similarly,
if  HR changes their working hours to an overnight-shift, or they even go on vacation en-masse, the Tech team can still function.

At this level of systems design, the behaviours found in the business are a good match to the system behaviours that we're trying to create. Aligning our technical boundaries with the boundaries and behaviours found in the business can enable us to achieve the loose coupling that we've been chasing for the last decade.

@Farmar at Microservices Dublin

@Stilkov at Microservices Dublin

Four tenets of service orientation