As a reminder, last week we covered: Starting with Why, Defining Roles, Breaking Things Down, Drawing Pictures and Writing Words and Not Starting with the Small Stuff. These steps should provide a pretty solid foundation for a team to build on. So without further ado, mute your notifications for 10 minutes and let’s dive in to the remaining “Do’s and Don’ts” of our software development guideline.
DO
Set Deadlines
There are a few different schools of thought on this one. Under promise, over deliver? Yes, this can promote short-term satisfaction among your stakeholders but when mismanaged can directly lead to sand-bagging. Aim for the stars, land on the moon? You still ended up on the moon and are closer to the stars than you were before. However, this approach can also lead to lower team self-esteem created by always falling short. Don’t rely on crystal balls or coin-flipping. Deadlines should be set in consultation with the team, protected against the team’s optimism and boosted from the team’s conservatism. Strongly encourage the practice of estimation and reflection, thereby continually refining the team’s accuracy. But the most important part of a deadline is its existence. It’s a guardrail, and a mile-marker rolled into one.
Constantly Communicate
By now, something most likely has changed. Maybe some of the how, maybe the what, possibly even the why. Regardless of the reason it’s of paramount importance to let everyone know. Communication is the lifeblood of all good development teams. A Project Management Institute study claims that 1 in 5 projects fail due to ineffective communication. When done well however, it can have the opposite effect, clearing up confusion, removing barriers, preventing surprises, thereby enhancing quality while also being an accelerant. I think most of us know how much rework can be caused by a misunderstanding planted far upstream or have seen how a last-minute change can wreak havoc on Quality Assurance.
Follow-Up
Say what you’re going to do and then do what you said. Manage the schedule with the mindset that its creation was for good reasons, not arbitrary ones. Let the schedule spur the team forward. Let the schedule force a decision. Let the schedule remind everyone to what they have committed. Do not let the schedule drive fear, exhaustion, waste or launch before an agreeable standard of quality is met.
Avoid Testing in Production
Test everywhere else. Locally, in Dev, in QA, in Staging, all the way through. All the things and all the environments. Unit, Service Contract, Integration, Service Performance, System Performance. We’ve all heard the reasons before.
But Prod and QA have different configurations!
Put your config and environment variables under version control like everything else.
But the data to test this scenario doesn’t exist in any of our QA environments!
Then create it as part of your fix. But the service didn’t have this performance problem locally! Create service performance tests as part of your unit test suite.
DON’T
Don’t Deploy on Fridays Until You’re Ready
While this is a cliché and a meme that can be pretty amusing, what this really should say is don’t deploy if you aren’t ready to support the consequences, regardless of the time of day, day of week or week of the month. Accompany every deploy with vigilance toward its impact on your environment, transaction times, stability and usability. While more modern deployment techniques like canaries, feature flags, and green/blue deploys can mitigate the impact or enhance discovery of problems, there is no substitute for someone simply caring about what happens to your app, product or service after their code is done and their pull request is approved and merged. “Keep your hands on the wheel at all times.”
IN CONCLUSION
I’m curious if those of you inclined to read this post, or the prior one, agree with my positions or if you’d add to my list. Prior to moving to Unosquare, I worked with many different team compositions, near-shore, off-shore, 100% in-office and a mixture of several approaches. Some of my insights come from those experiences with a mix of internal and external team members. Whether you own your product and are using a near-shore or off-shore team or are part of a distributed team developing for a client, I believe what I’ve laid out applies to productive software development on a broad scale. If you have comments, I’d love to hear them.
