The need of good software quality, project approach, team composition and more
Lets make software!
And there we go. We’re ready to start our new software development project. The creation of a new app, website or back office system. In a corporate or a small start-up. No matter how big the project, you’ll always have some roles involved, like the budget holder, the business owner of the product, some geeks in a development team and a guy or a girl who does some coordination, the Scrum Master or Agile Coach.
What can happen if there is to less focus on code quality from the start?
Customers love new stuff, a lot of it! We’re all customers in some kind of way, so with a bit of empathy we’ll all understand the customers’ need of new stuff. Meet the Product Owner. The guy or girl who is mandated by the budget holder and other (business) stakeholders to make decisions about the software product.
Green field software development is great! Software developers really love green field development. Deliver new stuff, a lot of it. No legacy. No workarounds. Choose the latest tooling, libraries and development language. Create stuff from scratch. And last but not least.. no bugs. NONE! …well, at least for a while.
And we’re off. The software development environment is in place. Installed the latest real handy chat tool. Trail versions of the latest sexy services installed. And yes, start with a crispy new backlog. A backlog without those distracting bugs. No bugs on the backlog!
Lets start to make the Product Owner happy. Very happy. Deliver new stuff, a lot of it. “Can’t you add this, please add that”. Yes sir! “I like new stuff”. We like new stuff you mighty owner, so your wish is our command. Deliver this, deliver that. Happy coding!
“Can’t you deliver more during one sprint? Faster? More? More!!” Yes we can dear Product Owner! Bring in more developers and we can deliver more and make you happier. “Mmmm, not enough budget for more developers.. But wait. This test dude or how you call it, the QA guy or whatever. Lets replace this guy with a new developer. Problem solved!”
And look at all those new features, they where not on the backlog, but so easy to implement and fun to use!
Never seen a happier Product Owner and development team together. BFF!
Go live is heaven
Ladies and Gentleman… We. Are. Live! 🎉👻💃🍾
Well, not really live, some kind of semi-live. We know the theory of the Minimum Viable Product aka MVP, so we share our first product to a closed user group of course. We don’t want to fail for the big audience via the App and Play Stores, because you’ll never get a second change for a first impression.
The first users take their job seriously. Family and friends, thus critical. That’s what we like!
Besides the good feedback the closed user group gives, they find some bugs, just some small ones.
“Lets kill them all”, the team responds!
Developers like to develop new stuff, they love it. Product Owners like new stuff, a lot of it. So a match made in heaven, isn’t it?
Now we’re really live and more and more users like to use our app. Those Facebook and Google campaigns really work!
More users comes in hand with more bugs. More bugs and even more bugs. The top of the backlog is filled up with it. We have enough bugs for at least five weeks of bug fixing. And again more and more bugs are found. Where do they come from?!?
From heaven to hell
The team needs to focus on bug fixing and can’t deliver new stuff. For the Product Owner it’s pretty hard to accept this. She loves new stuff, a lot of it!
But ok, the first and second week she accepts the situation. “Lets kill the bugs. …and can you please deliver two new features? Please?”.
At the start of the third bugfix-sprint the Product Owner goes bananas. Still an enormous list of bugs and no room for new stuff..
“I HATE BUGS, I LIKE NEW STUFF!”, she cries out loud.
After a short meeting between the budget holder and the Product Owner they decide to replace the team. “What a bunch of development cowboys, we need a new team. A team with real pros!”
The new team is in place. This bunch of geeks are real, real pros! The team took a quick look at the smelly bunch of old legacy code and came to the joint conclusion to start from scratch. No more bugs. Lets focus on new stuff.
They are pros and pros want to create stuff, they love it.
The Product Owner accepts the delay, because she likes new stuff, a lot of it.
And there we go again…
What went wrong?
A couple of things can go wrong during a software development project. Let’s focus on the most important ones.
- No focus on code quality from the start
- Inexperienced and/or incompetent individuals
- Imperfect team
- Incorrect understanding of a MVP
- Developers paradise
Let’s explain them in more detail.
1. No focus on code quality from the start
Product Owner got a huge need of new stuff. Software developers got a huge need of new stuff. One and one make two. If they only focus on delivering new stuff and no focus on testing and bug fixing from the start, they will pay the price when the product goes live. The users will find bugs and probably a lot of them. You can’t ignore the bugs, because you can’t ignore your valuable users. Fixing those bugs will cost a lot of time and during that time you can’t deliver new stuff, well at least not a lot. And by introducing new stuff, you’ll introduce new bugs…
Always focus on good code quality even if this holds back the velocity to deliver new stuff. Otherwise you’ll have to pay the price when you go live. Always execute unit tests, regression tests, cross browser tests, peer reviews, what ever it take to build and implement solid software. Add this to your Definition of Done (DoD) and stick to it. Everything that not passed the DoD, can’t go to production!
2. Inexperienced and / or incompetent individuals
The Product Owner and the development team had to much focus on delivering new features and to less focus on good code quality.
How could this happen?
Easy; put an inexperienced Product Owner in one room with a bunch of well-meaning geeks without an experienced Scrum Master.
How to solve this?
Dear Scrum Master, first of all visit a good Scrum course. Then, coach the product owner, budget holders, stakeholders and development team. Indoctrinate, brainwash, and explain till they drop. No matter which method you choose, as long as they start to understand -as soon as possible- the impact of choosing new functionality from the start above good code quality. If they ignore quality from the start they’ll get a pretty bad trip after going live in the real world, with real users.
Secondly, from the start, make a reservation for quality assurance and refactoring.
Last, understand that Product Owners, developers, budget holders wants to have new stuff, a lot of it!
3. The imperfect team
A hustler, a hipster and one or more hackers in one room doesn’t make a perfect (start-up) team automatically. As Bruce Tuckman already explain in the mid 60’s, it’s about forming, storming, norming, and performing.
The team reaches the performing stage, when hard work leads, without friction, to the achievement of the team’s goal. The team is aligned and autonomous.
Popcorn time! Sit back and relax, see two entertaining video’s about Spotify’s engineering culture.
4. Incorrect understanding of a Minimum Viable Product
Nope, a MVP is not the 1.0 version that you share with the world via the App and Play stores. “Obvious!” you think of course. Not so obvious as you think. A lot of product owners, budget holders, newbies and AINO-lovers are convinced about this.
A MVP isn’t a 1.0 version you’ve developed safely in your nice isolated crispy fresh quasi-industrial hipster joint, thinking you’ll exactly know what your users wants. First of all, who are your first users? Secondly, gather what they really like, ask them in real live, get out of your building!
Take a break, get your favo half-frozen-triple-soja-decaf-frappuccino and read this great blog called “Your Startup’s First Thousand Decisions Don’t Matter (But These Two Do)”. Followed by another blog post called “Minimum Viable Product #MVP isn’t quite what it claims to be”.
5. Last but not least: avoid developers paradise
First of all, an optimal performing software development team is in charge of HOW stuff will be created. The Product Owner, on the other hand, is responsible for WHAT need to be created and in which sequence.
Software developers love to develop software. They get a real kick when they can create this microseconds-responding microservice-based architecture, scalable for at least 900 million monthly active users -just like Facebook- system. From scratch. Huh? I thought we’re creating a MVP? Yes, but you’ll never know, you know. We’re creating the new Facebook, right? And by the way, we’ve implemented this crispy new service in just two days and I’ve added some stuff, which looks really nice, but we have really no idea if the users will love it. And we’ve created even more nice stuff, which was not on the backlog.
Software developers really love to develop stuff, a lot of it, even when you can buy a service with the same functionality and more for a small bargain. Do check on a frequent bases the availability and matureness of the services you’ll need.
Dear Product Owner; keep focused on the stuff the development team delivers. If they do more than asked, explain that in the same time some of your items on top of the backlog could have been burned. Secondly, manage your stakeholders. No backlog item can have the same priority and be aware that nine mothers can’t deliver a baby in one month.
Dear Scrum Master / Agile Coach; coach the Product Owner and the team. Let them focus on the top of the backlog..
Read more about SaaS Integration: Build, Buy, or Subscribe.