TrAgIc software development
I was having a conversation the other day about how agile / scrum can look so different in different companies. I think most people haven’t experienced an extreme opposite of corporate agile environment. So let me introduce you to a real team workflow that I experienced at some point. It was used in a startup developing a web app. In this post I will name it “Truly Agile Icarus”, or “TrAgIc”, for short.
In TrAgIc, there is only one recurring meeting with a fixed schedule: the retrospective.
There is also only one recurring meeting without a fixed schedule: feature introduction.
How did it work at all? With one golden rule:
Whenever you are doing some work, you make sure you empower whoever comes after you to also get their job done. When in doubt, go talk to people.
Let’s go a bit more concrete on how a feature might go:
Product Owner presents it at the feature introduction meeting. This includes a document describing things from a user point of view, that people can refer back to. Frontend and backend team ask questions and create tickets on the issue tracker of choice, which dependencies between them.
Backend dev picks up backend ticket. Things are implemented in a backwards compatible manner, so backend will have a code review and be merged before any frontend work starts. As part of doing the ticket, they also provide all the required documentation such that the frontend dev can do their work.
Frontend dev picks up frontend ticket. Code is reviewed and merged.
Product owner tests the feature.
At some point, product owner thinks there are enough new features to make a production release and asks someone to do so.
This all looks really simple and radically optimistic, but I have seen it work first-hand. As long as the golden rule is respected. Because if you look at each of those points, a long of things can go outside of the happy path. And you’re responsible for communicating so. Some examples might also help here:
Feature introduction meeting
After questions from the devs, Product Owner realises they need to re-work the feature. There will be later in time another Feature introduction meeting for the same feature.
Backend devs believe they should discuss how the new feature should be approached, because it impacts the architecture. They schedule a meeting to do so. Somebody is appointed to prepare and run that meeting.
Frontend devs notice that the feature is not testable unless some non-user-facing work is done is done in the backend. It goes into the backend ticket(s) to do that work.
Backend work
Backend dev is not sure what would be the correct API changes to make frontend implementation easier. They go talk to one or more frontend devs.
Frontend work
The documentation provided by backend was insufficient for the feature implementation. They request for what is missing to be added.
Testing
Found a bug but not sure if it’s a backend or frontend issue? Get a developer to look at it with you and help determine the root cause.
At any stage: is this same problem happening a lot of times? Discuss it in the retrospective meeting!
Does this mean this way of working is purely a feature factory without time for refactors? It might surprise you, but it does not. If it’s a small refactor, you just do it. If it’s a bigger one, you discuss with others how to tackle it and create the tickets. Because refactors are a part of normal work and you trust people to be reasonable about their split between feature work and other necessary work, things will be picked up accordingly. And if you think the current split is unbalanced?
I hope you guessed it by now…
You talk to people!