How can I track quality attributes on my team's Kanban?

Question

My team uses a Kanban system for tracking day-to-day progress and it's worked out really well for understanding progress on features (captured as user stories). We have largely allowed our system design to emerge as we develop features which worked out well until recently. In the last two week we've had several discussions about architectural trade-offs specifically related to performance and modifiability quality attributes.

I think what's happening is as we implement features and design the system, we're implicitly making decisions about the architecture but not considering those decisions in terms of our known quality attribute requirements. It would be really great if I could track/capture/visually depict how these important design decisions are being made so team members have a better chance to not create additional tension with in the system's architecture as it is being implemented. And of course, to complicate things more, features on our board aren't exclusively functional and sometimes hide architectural complexity!

How can I track progress on quality attributes (or other architecturally relevant decisions) visually on my team's kanban?

Answer 1

we're implicitly making decisions about the architecture but not considering those decisions in terms of our known quality attribute requirements.

I think you can visualize this by creating a "architectural review" step in your workflow. The step would be represented by a Kanbad board column with its own WIP limit. The WIP limit will depend on how many architects/designers you have to participate in these reviews.

The development team is responsible for the horizontal, left-to-right flow of user stories. The architect(s) will, in most cases, touch the stories only when they are in the architectural/technical review column. The intersection of the column with a horizontal swimlane visualizes the meeting of developer(s) and architect(s).

One of the teams where I work has a similar step where they do a database schema review with the chief data architect. They don't use Kanban, but if they did, they would be very likely to have this column on their board.

The known quality attributes could then be represented as:

• the definition of done for the architectural review step.
• acceptance tests around the already-done user stories representing non-functional requirements. Then the definition of done for a new user story would include not breaking those tests.

ADDED: The "architectural review" workflow step may be suspect to a problem called tragedy of the commons. Here is a great blog post about how Kanban visualization can help deal with it and possible solutions.

Answer 2

There are really two parts to this question. One part is: How do we know when the architecture gets changed. The second part is: How do we know that the architecture is still good.

For this first part: How do you know when the architecture gets changed?

The goal here is to take something that is being done implicitly and make it explicit

• Alexei's suggestion is a one option. Create a column on the board for architecture review. Then move a card there if it will require architectural decisions
• Another option is to create an explicit policy on how to handle this: "If we need to change architecture then we must pair with someone else" is an example of one such policy. In one project, we had a policy that code changes to certain specialised modules had to be done by pairing with specific people. When someone wanted to change code there, they would call for a pair and team up. The rest of the work was done solo. You can do something similar with the architecture.

You would probably go with the former, if many cards require review, or if the architect is not a part of the team and a handoff is required, or the review is going to be detailed enough to take some time which you want to track on the board. The latter is an option if only few cards touch the architecture, and its easy to find a pair on demand.

Now coming to the second question: How do we know that the architecture is still good?

I'm a big fan of visualisation. You could have a chart on the whiteboard with post-it notes describing the components and architecture.

There are also static analysers that will analyse the code base and generate an image with dependency graph of various components. You could run it, take a print out and stick it up on a wall once a week or so. Maybe the latest two printouts could be on the wall, so you can see if anything has changed in the last week.

What these allow you to do is to make your architecture and design visible. Team members will glance at it once in a while and comment on it if something could be changed or refactored or done in a better way.

Answer 3

I have seen this problem too. Implicit decision making! If the implicitness is the issue, will making it as explicit as possible solve the issue? What I suggest is to tweak the architecture process a little bit to 'start expliciting' out the implicit thoughts that progress to become decisions. The purpose of the additional step in the process is to make team members understand that everyone is prone to making implicit architectural decisions. This step will just keep the implicit decisioning off the track.

Keeping the "Expliciting out Implicit decisions" as a part of kanban for each of the scenarios might help.

What I am going to suggest might be cumbersome. But if the process is mapped to a set of kanban items and if this is brought on the board for each arch scenario, will it not help you track it. I suggest you can also map them to the six part scenario template and improvise the kanban board to accommodate the findings, the QAs can be tracked.

Vikram.

Answer 4

It is one of the risks of delaying architectural decisions on Agile teams. Obviously the most responsible thing for being agile is to delay architectural decisions until the last responsible moment. But chances are the last responsible moment can (or must) happen early on.

One thing that helps is to clearly delineate early on your key driving requirements; things that you clearly know you must have (but don't have to necessarily implement right now.) Your evolving architecture (which attempts to be minimalistic and flexible) should accommodate existing or future support for such requirements.

More importantly, however, your evolving architecture MUST NOT implement artifacts that get (or can get) in the way of supporting such key driving requirements, even if those artifacts are meant for resolving current requirements. We can refer to such artifacts as interfering artifacts, artifacts that deliver a real value (as they implement a solution to existing requirements) but whose presence makes it difficult/costly to implement a future key driving requirement.

In cases when you must implement an interfering artifact, your task would be to plan for its removal at some point (so that you can implement the key driving requirement that is being interfered.)

Obviously this is all esoteric without an actual, tangible context (like a real project). But more or less your development process model and your evolving architecture must take these considerations into account.

Implicit requirements are the dead of architectures.Everything must be made explicit, both the key driving requirements and those that are ancillary. You don't need to implement a requirement early on. You only need to be able to account for it.

PS. By requirement, I mean system-level architectural requirements and not necessarily the ephemeral application-level requirements that can be accommodated without substantial changes to the architecture. Hope it helps.