I’d like to share a simple and short case study about pragmatic approach to delivering new features to existing, very big software product.

Let’s start with some background. There is an existing product, working nicely on production. We want to extend it with new features, fix bugs and experiment in A/B environment. This sounds very typical and I have already been working in such projects more that dozen times. Even though it is so typical and ever-present, I would say that I’ve rarely seen it working well. However, this case study is about one example that worked extremely good and resulted in fast, top quality and relevant deliverables.

Without further ado, how was everything working?

Business requirements elicitation step

Firstly, bunch of business stakeholders and Product Owners gathered and discussed desired new feature. The result of this discussion was a Google Doc. Nothing fancy, nothing nicely formatted or standardized. By keeping it simple and in convenient platform such as Google Doc, this document was surprisingly full of information and business justifications. The very important word: justifications… meaning why do we want to implement the feature, why do we care. How do we want to monetize it… or maybe is there another reason, for example attracting more users or different kind of users?

Software architecture update step

Then these documents were analysed by software architects. Or just one architect. It was also shared with development team so anyone could familiarize with it and post any questions or ideas. The most important thing about architects here is that they must be the ones who know the whole system. Architects mapped business requirements to architectural and design changes to the system. They provided detailed description of what needs to change and where. The result of this analysis ended up on Confluence and contained UML diagrams, some technical descriptions and of course original business Google Docs were attached. There were high level estimations as well. All in all this formed complete description of requirements, stating what we were doing, why, what outcomes are expected, what will be visible output, what is financial impact and how will we monitor and validate it. All grounded in and attached with current software product by forecast and detailed architectural and design changes. They became de facto documentation and history timeline, and turned out to be very valuable even when looking at features implemented a couple of years back.

Let's deliver!

Click and enter your email to get access to the useful resources and get notified whenever we publish a new blog post on our website.

Subscribe me

All-hands refinement step

When this part was ready it was time for all hands meeting. The participants were business stakeholders, architects and the whole development team that was expected to implement it. The feature was presented to the team, architects explained their design. Developers could ask all the remaining or new questions. Such meeting was very important and it ended with everyone understanding what needs to be done. It was time to start estimating and then implementing it.

Development, deployment and maintenance step

Now it was time for the team to take over. At this point everyone must had an understanding about what is expected of her/him. By having full support of architects and business stakeholders/POs, this resulted with very high team motivation and morale. It helped that the same team was responsible for QA and DevOps and ultimately delivering and maintaining on production. The team was happy, because they were doing most of these things. I don’t need to add that this resulted with fast delivery with top quality. Very important here was that everyone was working inside constant feedback loop. If developers found something that architects did not anticipate, they talked, updated design and continued without any hassle. The same with rare need to go back to business requirements update.

Processes supporting this flow

Did you notice that I did not mention anything about any methodology or process? Nothing about Agile or Scrum. The thing is that it didn’t matter. The most important aspect of this was that at the point of starting work, everyone was on the same page and with proper level of motivation. Team(s) could then decide whether they want to proceed with Scrum or something entirely different. My opinion and advice was to always choose something that does not go into way. So using Kanban or Scrumban. But once in a while, for big features requiring many months of development we chose Scrum. The need however was always the same - deliver as fast as possible so this is why I opted for Lean techniques.

Are we back in the water(fall)?

One could say that all of this is like going back to waterfall. First there is requirements gathering, then architects design changes and finally team implements. Maybe there is some little truth in this, however as I mentioned all phases were visible to everyone and anybody could participate and modify at will. What changed were groups accountable for particular phase/outcome: stakeholders, architects and developers. But they were working close together and there were no ‘throw docs over the wall’ anti pattern. So maybe it was like some modern, small scale waterfall… well it worked like a charm so I don’t care. Unfortunately I’ve seen too many failed Agile environments that I’m starting to believe we need to step back a bit.

The importance of software architect role

At the end I would like to emphasize the role of software architect. It should not be neglected. Quite the opposite - identify your most experienced and open minded people and push to make them architects. From developers point of view, it is so good to have some initial analysis done by someone who knows the whole system and predicts the impact of changes… but maybe even more important is to have someone available to talk, because when developers start coding, some unexpected things will be revealed and design often must change. This is why I always prefer architect role to be someone who is working with the team, maybe even codes or at least participates in code review.

Hire pragmatic software architects

We are working on every stage of software product development. Partner with our experienced and pragmatic architects that help you innovate and move quickly.

Schedule a call with our expert