Essay on greenfield software projects
Are the greenfield projects all sunshine and rainbows?
A couple of weeks ago, we left our previous project. We managed to leave it just after a successful go-live. Thanks to our commitment, we delivered it on time. Our company wants to award us for this accomplishment and has decided to allow us to start the new project/product from scratch. We got into a new team. Our new team is made of young and dynamic people with an experienced product owner who understands all the aspects of the agile manifesto. Sounds familiar?
Time luxury of a brand new project
We are super excited about the new idea. We are coming up with the name for the initiative, creating a code repository, writing down the coding standards, and defining done. We’re setting 2 week-long sprints, and we create a long backlog of user stories.
Greenfield software development
In the next weeks, we’re coming up with the abstraction layers to overcome all the issues we faced in the previous application regarding cooperation with the decision-changing customer. We are super proud of the 99% unit test coverage and continuous deployment applied. Every time we merge something to the master branch, it is getting automatically deployed to the environment! Works like magic.
Sprint Review goes smoothly and gets everyone involved
Every two weeks, we do a sprint review for the product owner, and we show all the exciting mechanisms that will allow us to keep the highest quality of the software. Our UK-based product owner is proud of us, and after the sprint review, she says “excellent job, team”.
Common pitfalls of greenfield software
After 3 months, we discovered that we managed to keep committing the code to the repository, but we’re still far from delivering the critical user journey. We were delighted with all the tools that we used and the engineering practices we applied. The codebase grew, and our test environment automatically got the next releases. Still, the sanity testing of the system today takes about 2 minutes because the end-user cannot complete the journey to get any value from the solution. The set of the business features is pretty much - limited.
The new existing code doesn’t deliver much value
Based on the UI designs that we’ve got, we implemented all of the features for 3 pages. We even applied a feature flags engine, allowing our future customers to turn specific features on these pages on and off. The critical user journey still doesn’t work.
A user cannot use the new existing code
Of course, we found a good excuse for showing just the codebase on a screen-sharing session during the sprint reviews. We were not given the necessary implementation from 3rd party software, which was blocking us from getting the data to fill our database with something meaningful so that we couldn’t populate the frontend with any data. The application could not be used.
First appearance of legacy code
The abstraction layers we created required one week of refactoring sprint, but finally… we ended up with limitless extensions when the PO asked for these.
We cannot understand why the boss of our PO asks about going live the next month. It seems impossible. The label “higher degree of risk” is attached to the project. We need to get everyone involved to understand how to rebuild the trust and successfully deliver the solution.
Customer’s top priorities
People who drive the business (e.g. sales, operations, c-levels, account managers) tend to value the elements which directly correspond to one of the following outcomes:
Rising user satisfaction.
Rising customer satisfaction.
Rising employee satisfaction.
These usually lead to increasing revenue in the long term.
Key success factors of brownfield projects and legacy code
If we think about greenfields in the long term, we must shift our mindset and learn from experience. This is where the brownfield projects with good documentation, stable deployment and release strategies, customer support, bug fixing, proper design, and user training usually step in to teach us about the real value.
Usually, people from outside of the scrum team in the customer’s organization tend to value more boring stuff than doing all the greenfield software development activities. Reality shows that the goals and values of the most newly created scrum/development teams strongly differ from the business ones.
Speed is valuable, but the long-term quality is a must
Even at huge companies, business people want to make things happen when a new opportunity appears. If the complex software doesn’t allow them to release the new solution in a matter of days, then in many cases, they see the simple Zapier integration with Google Spreadsheet as more valuable. After they get the lightweight working solution, they will be super happy about continuing this idea by implementing a high-quality system for it.
Building products with no operational experience
Returning to the beginning of this article, we mentioned that our developer managed to leave the project just after going live with it.
The best understanding of the user’s perspective is not from participating in 50 projects during the development phase. As long as real users are not using the project, we are just making guesses on how our implementation meets the needs.
Questions to ask when starting a greenfield software project
When working on a new greenfield initiative, it’s worth asking the questions:
How will our implementation help achieve operational excellence after releasing it to production?
How will we maintain the application, and if all of the applied code-level techniques will enable us to keep implementing the new features, or will the post-live reality require us to focus on maintenance in 100%?
How are we going to release its new versions? Will we be able to deploy every day?
Will the bug fixing become a pain in the ass? Can we assure relevant stability?
Will the users like it?
What would change if we would become end-user-focused instead of code-focused? It is most likely that we would get a better understanding of where the money comes from. The software starts making money once it is released to production. Once we understand it, we will develop the proper perspective on enabling technology.
Purpose of the technology and its maintainability
The purpose of technology is “to enable”.
Applying the best engineering practices and keeping the software quality as high as possible are the best steps to reduce costs in the long term. However, we need to remember that all the practices we apply need to come from the needs. Not from our engineering desires or biases.
We should want to stay with what we created.
If you’re given the opportunity to maintain and develop the legacy system, then this is the best opportunity to learn a lot about real software development, management, and delivery techniques.
Iterations and prioritization to the rescue
All the battles around “real Scrum” and “not-by-the-book Scrum” led us to focus on the wrong thing. Mechanics and practices.
The Agile Manifesto tells us that our ability to respond to constant changes in close collaboration with our customers is the key. What is missing in it is the end-user and proper understanding of the “working software”.
Begin with the end in mind
Even when working on the new software systems before running them live, we may imagine that we already have our end-users, and we want to set our highest priority on satisfying them with early and continuous delivery. That means we may implement the critical journey for the specific user persona by applying the proper prioritisation. Wrap it with the best engineering practices required for a given phase and then iterate.
“Working software” really means the working software. Working software means the end-users may use it to achieve something they need.
Greenfield software projects - What to keep in mind?
Set up a test environment as early as possible and share it with your customer. Use it to practice frequent and stable deployments. Think about delivery.
Focus on defining and delivering the critical user journey first. No bikeshedding.
No big architecture upfront doesn’t mean no architecture at all. Starting with the code and repository is not always the best first step. A workshop may work.
People will not understand something just because we give them an explanation. Give the team questions to answer in the early stages and help them find the answers by themselves, even if you already know them. Quoting (probably) Alberto Brandolini: “It’s not stakeholder knowledge but developers’ ignorance that gets deployed into production”.
Communicate the goals and expectations. Make the team understand the business context, not just the descriptions of the Jira tickets.
Keep codebase quality as high as possible, but do not over-engineer for something you think will be needed. Quality is the key in the long term.
In most cases, iterations are the best tool for reducing the project’s risk when working on a waterfall-kind-of-project. The critical aspect here is remembering the working software after each iteration.
Create software that you will want to maintain.