True Agile: Not only Scrum

Developing new features in software is always a hard process: Too many steps, too many people involved, too many teams, requires a lot of communication. It's hard to get it right in a short time and predict when it will be ready.

To solve this problem, many companies have used Scrum to try to be efficient, predictable, and fast at the same time, but contrary to what was expected, Scrum only makes teams slow and over-worried with unimportant things.

What I want to present to you in this article is the right way to develop software, from finding out the user needs up to publishing it into production.

The beginning: Let's set up our teams

Every company needs multiple teams and people to work together to build any solution. This applies to any sector of the economy: Agriculture, construction, metallurgy, and of course, software development.

To start developing our product, we first need to build a couple of teams. I tried to make an example that is suitable for mid-size companies: It splits the responsibility into multiple teams, but not too granularly at the point that the company would need a lot more middle management to be able to manage all the teams.

In your case, you may need to have fewer (combining the product+design teams and the architecture+development teams) or more teams (splitting the architecture team into software architecture and database architecture, splitting the development team into their specific areas), but this is something that changes from company to company.

Here is a little spoiler of how our teams will look like:

Product

For small to mid-size companies, usually one person with some experience is enough to compose this team.

The product team is responsible for:

• Understanding the user's needs
• Finding solutions to these needs
• Converting these solutions to features in the product
• Communicate and guide all other teams about the feature, how it works, and the business rules behind it
• Be the "Scrum Master": Control the estimations and expectations of when the features will be ready

This role usually requires:

• Experience working with User Experience (UX), user opinion surveys, and other ways to discover user needs
• Knowledge about your product and your company's market
• Know how to think like your users
• Basic UI knowledge to be able to explain the features and ideas to the other teams

Design

For small to mid-size companies, usually one person with some experience is enough to compose this team, but if you have both a website and mobile app, would be nice to have at least one more UI Designer, so you can work faster in parallel.

The design team is responsible for:

• Creating the UI to guide the developers about how to present that feature to the users
• Ensure that the UIs are updated with the current design trends (do not let your product look like Windows XP, which was beautiful back in the day, but very outdated today)

This role usually requires experience with:

• Mockups
• UI
• Design Systems
• Color Schemas
• Accessibility

Architecture

For mid-size companies, the ideal is to have both an Architect and a DBA (Database Administrator), so each one can focus on what they are best at and ensure that your product is reliable. If your company has the budget, I would recommend also adding a Cloud Architect to this team, and then you will have the Holy Grail of architecture.

The architecture team is responsible for:

• Technically design your features to ensure that they will be maintainable and will bear the load of your users using your product
• Be the technical reference to the development team
• Give the initial estimate of the amount of time that it will take for the feature to be ready
• Perform benchmarks and performance tests
• Ensure that the system is being correctly observed and has all the necessary alarms to know when something goes wrong

This role usually requires a lot of experience with:

• Development
• Cloud
• System Architecture
• Design Patterns
• System Reliability
• Observability
• Database Design
• People Skills

It's also very important that this team has a little time-to-market experience, this way they can architect the best solution for the current need: Something short-lived that will be built very fast or something long-lived that will take some time to create.

Development

This is the biggest team in your company because they will do the manual work, and it takes the most amount of time. To reduce the time that you need to deliver well-built features, you have more people in this team and split the work into multiple parts.

The development team is responsible for:

• Coding the features
• Creating unit tests
• Creating e2e tests
• Creating automated tests
• Make sure that the code that they write is performative and maintainable

This role usually requires some experience with:

• Coding in the language that you choose
• Undestandment of Code Diagrams
• Undestandment of Database Diagrams
• Undestandment of "complex" system concepts: Caching, Queues, Concurrency, SQL, and things like these

How to develop features

Ok, now that we have our teams, how do we develop a new feature?

We follow the flow below:

Amazing tool btw: OnlineGrant

Since the image is too big to be uploaded with readable quality, here is a zoom of the steps:

But remember: all the time estimations are examples for a relatively complex feature, something like changing the color of a button can be done in a day.

To know how much time each step will take you MUST ask your teams and the time/necessity of each step WILL change from feature to feature.

First step: Discovering a new need

This happens BEFORE the "Sprint" starts:

• The Product team detects a new user need (it can be done by surveys, suggestions, or by any other means)
• They analyze it to see how to transform it into a feature of your product
• They think about the implications of this feature existing and how it will affect the other features
• They create a presentation to show to the other teams:
  • What does the user need and why do we need this feature
  • How the feature works

This happens WHEN the "Sprint" starts (or you can say that this is what starts the "Sprint"):

• They schedule a call with the other teams to present the feature to them, answer questions, make questions, understand a little more of the technical impact of the feature, and decide if the feature is worth being created
• At the end of the presentation we schedule another call with all the teams to talk again about the feature and the expectation to finish the development. Usually, a good interval between this call and the next call is 1~3 days depending on the complexity of the feature

Usually, it's nice to schedule the initial call for the morning/start of your work day, and the follow-up call to the end of your work day.

Second step: Sketch Architecture and Design

• The Architecture team will review the current architecture and create a technical sketch design for the solution
• The Design team will create an incomplete low fidelity prototyping of the feature
• Each team will create a simple presentation to show to the other teams in the follow-up call
• On the follow-up call, they will present, answer questions, and give an initial estimative of how much time it will take to develop the full feature

These first two steps take from Monday to Wednesday of our first week in this example:

To get the full estimation, we need to get the opinion of multiple teams:

• How much time the Architecture team will take to architect the system and the database (In our example, they estimate that it will take 2 + 5 work days)
• How much time the Design team will take to finish the design (In our example, to make things easier, they estimate that it will take the same amount of time that the Architecture team will need)
• How much time the Development team will take to finish the coding (BackEnd, FrontEnd, and integration with all of them)
• How much time the Development team will take to write all the unit, e2e, and automated tests

After we get all these estimations, we can get to the real-time that the feature will take to be ready. Here are some important points that you need to know:

• The development team depends on both architecture and design teams, but the development team has 3 parts: BackEnd, FrontEnd, and QA, and each one of these parts depends on something specific, but they can work in parallel with each other
• The BackEnd depends on the Architecture team
• The FrontEnd depends on the Design team
• The QA depends on both BackEnd and FrontEnd being finished to finish their work, but they can work on test automation in the meantime with the Architecture documentation

So, now that we know that on what each team depends, we can start to create our estimation using this formula:

architecture + development + testing

• architecture: The highest between the architecture and design team's estimates
• development: The highest between the development of the BackEnd and FrontEnd estimates
• testing: The QA estimative

With this, we finally have our initial estimation, but be aware that we will review it after the architecture is complete.

Third step: Complete Architecture and Design

The Architecture and Design teams will work in parallel to finish their parts, in the meantime the development team can work on technical debt, internal products, or L2/L3 support

Fourth step: Development

• The BackEnd team will have a call with the Architecture team to understand what they will need to develop
• The FrontEnd team will have a call with the Design team to understand what they will need to develop
• The BackEnd and FrontEnd teams will have a call to line up how they will make their parts work together
• The QA team will participate in all calls to understand everything that they need to test
• After all these calls, we will have another call with all teams to review the estimation of how much time it will take to develop the feature and see if the initial expectations are correct
• And finally, the Development team will code everything that they need

Fifth step: Testing

• After development is finished, we reunite all the teams again to show what they have done and review if the feature is working as expected
• If it is (as it should be because we have multiple sync calls), the QA team will start the tests
• If they find any bugs, the Development team will fix them
• After all the bugs are fixed and everything is working, we can finally release the feature

Final step: Release

We increase the version of our product as specified in SemVer and deploy it to production, preferably following good deployment practices to have no downtime.

I REALLY recommend that you do deploys on Monday, this way you still have 5 work days to fix anything that goes wrong or revert the deployment.

Now that we released the feature and everything is working fine, all we need to do is monitor it to ensure that it's working OK and maintain it, but we can stop thinking about this feature so much and go implementing another new shine feature.

Do we need Scrum?

Scrum has a lot of strange, inefficient, unnecessary things:

• Daily meetings to tell the others that you are still working on that thing that you said that you would work on, day after day after day til the end of the Sprint
• Retros to say random stuff like "Yeeay, great teamwork 🥰" and not help in anything
• User Stories (aka the worst way to describe a feature): They don't describe anything for the technical teams, they don't help, they can't be used as a reference for future features
• Story Points: Ambiguous way to estimate how much time something will take to be done. It makes no sense, you can't use the same rule for 2 different features, will ALWAYS be wrong, ALWAYS. No matter how mature your team is, it will NEVER be able to estimate something using "story points" instead of REAL TIME: Hours, Days, and Weeks.

But if Scrum is so terrible, why do we use it? Because we need a way to:

• Predict how much time something will take to deliver
• Organize our workflow in a way that delivers value to the users
• See our flaws and improve ourselves and our processes to be as efficient as possible

For our luck, Scrum isn't the only way to have these things. In this article, you saw an alternative very efficient and allows you to have dynamic "sprints" (due dates) that match the feature that you are working on, and not in ambiguous estimations that have no base in reality.

The workflow presented to you in this article is realistic, market-compatible, and allows developers to create the best solutions for your product without following nonsense trends.

I know that when you look at only one feature sprint, you think: Look at how much time the teams are not working!, but that is not true. Your teams can work on multiple features at the same time if they respect the development process of each one of them.

The most important part of developing anything is documentation. I recommend that you write everything, create diagrams, and record all the calls. Have nice documentation and it will save you a lot of time, a lot of unnecessary calls, and a lot of bug fixing.

Conclusion

I hope that this helps you to optimize your workflow and deliver features with more quality, if you disagree with anything, please, let's discuss in the comments and improve this solution.