Apr 30

Functional agility vs. technical solidity

10Scrum is about delivering value to the business right now and being agile when it comes to future wishes. Software architecture is about being prepared for the future. Those two don’t seem to match very well. Well, agile does not mean ignorant, and prepared does not mean ¨cast in concrete¨. So start doing, and never stop thinking!



It don’t think it was ever a conscious decision to not call myself an agile evangelist, but I was really happy with it anyway when I was talking with George last thursday. He said Scrum was both a blessing and and a curse for him. The curse was the fact that many people use it as an excuse to stop thinking about the future. They use Scrum as a religion, rather than as a tool.

I can relate to George’s frustration, but I personally have more experience with the opposite end of the spectrum: people who are unwilling (or unable) to build anything unless they are convinced it is the best solution, considering all current and future wishes they are aware of.

Both attitudes are serious problems. But hey, nothing a good retrospective can’t fix, right (or am I being too religious about that)?


But even if you have honest and open communication between both parties: what is the right balance in this apparent trade-off between functional agility and technical solidity? In my opinion there are two problems at hand:

1. Dealing with future wishes.

2. Ensuring good enterprise application integration.

Future wishes

Consider 2 stories: A and B. Story A must be delivered in the current sprint, and the related story B might have to be delivered in a future sprint. The next table shows the estimates for various technical solutions for these stories.

Solution X at first, solution Y later

Solution Y directly

Story A

100 manhours

120 manhours

Story B

200 manhours

120 manhours

As you can see, in the current sprint the team can choose to spend an extra 20 hours and possibly save 80 hours in the future. But if story B never makes it to a sprint, the 20 hours are lost. Simplifying the problem to this example makes it look like a gambling game, where you look at the stake, the likelihood and the prize, and then decide. Real life software development is rarely that simple. There usually also are related stories C, D, E and F, and then a bunch of things that nobody mentioned to the team or even thought of yet. Priorities will change and currently unknown details might require a solution Z that is much more work.

Am I saying that the team should only think about story A and choose the most straightforward solution for that? Not exactly. An important element of delivering high quality software, is building a solution that is likely to be stable. This is why most developers will refer to solution X as ¨quick and dirty¨. In the example of just stories A and B: in 9 out of 10 of the cases, spending the extra 20 hours for solution Y will result in better quality for story A in itself. In those cases it is best to just do that, regardless of the likelihood of story B.

Enterprise application integration

The second area where architecture principles and Scrum might conflict, is enterprise application integration. Scrum explicitly states that no one tells the development team how to turn product backlog into increments of potentially releasable functionality. How does this combine with the role and responsibilities of an enterprise architect, especially in an environment where the product is part of an integrated portfolio of products?

In my opinion, the freedom of the development team fully applies to the internal architecture of the product they’re developing. The team may consult the enterprise architect or other experts (and should do so certainly for expertises that are missing in the team), but in the end the internal ¨how¨ is the responsibility of the team itself.

When it comes to integration, the requirements that the product must comply to, must be imposed through the product backlog. There are three possible ways for this:

  1. As part of the definition of done – I don’t advise this, unless there is an integration requirement that applies to virtually all user stories.

  2. As separate user stories – I only advise this for integration requirements that have explicit business value by itself.

  3. As part of the acceptance criteria for each related user story. – This usually has my preference.

In all cases, the enterprise architect is a stakeholder, and the product owner must work with the enterprise architect to make sure that all integration requirements are taken into account on the product backlog. It’s also wise for the team and the the enterprise architect to have good contact with each other. They have separate responsibilities, but depend on each other to deliver.

Permanente koppeling naar dit artikel: http://agilethings.nl/functional-agility-vs-technical-solidity/