Although there are many flavors of agile development that all emphasize slightly different concerns, in this article I'd like to discuss three things that I consistently see done by the top software teams. I believe that any engineering team not already practicing these three things can get an immediate productivity boost by implementing them well.
So without further ado, let's get into it!
1. Leverage Automated Tests
Notice, though, that I say leverage automated tests. A few times I've seen test automation get out of control to be the point where they become unwieldy, too many tests checking the same things, etc. Don't let this happen to your team! Teach your team members to appreciate testing as a tool for them to leverage rather than a new goal of chasing green 100's on the code coverage reports.
2. Work In Pairs
Solo work is a cute derogatory term we invented for the traditional scrum "divy up the work and have everyone go their separate ways" methodology for developing software. The solo work model is just objectively slow, painful, and incredibly inefficient.
When one developer has to figure everything out on his or her own it can take a very long time before any working code gets written. Possibly the developer goes down a path that the team doesn't particularly like, but in this model the feedback isn't given until a week later when a pull request is opened, and then people start ripping it apart asking for it to be almost completely rewritten...
Indeed, pair programming is basically constant, continuous code review throughout the entire development of the code. Naive non-technical managers sometimes think that because the engineers can write half as many lines of code then in turn it will take twice as long to ship the feature.
Ha! To me, this is obviously complete foolishness since lines of code is hardly ever the bottleneck in software development- rather, the real cost of software is in the ongoing maintenance of the code- how quickly and easily it can be understood and updated with new features and patches.
Some engineers are afraid to try pair programming at first, but I have found that even the most introverted coders can be more efficient and more helpful to the team when pairing.
Also, when everyone is pair programming I know they are truly engaged in the work and so as a manager and team lead I have no negative feelings when people take breaks or leave early because I know that they are working hard.
3. Keep It Simple
In the great talk by Rich Hickey, "Simple Made Easy", he argues that as a programmer you should try to use tools that are simple and that will allow you to build simple solutions for your problems. All too often I see teams creating giant, monstrously complex systems when it's just unnecessary.
-> Keep things simple in your infrastructure by hosting both your front-ends and back-ends with a serverless architecture.
-> Keep things simple in your database by choosing a db that represents and stores data in the same form that your front-ends want to consume it (these days, probably JSON).
Of course, simplicity is a pretty subjective topic as what's simple to one person may not seem so simple to another, but still- striving to keep your systems simple is a great rule of thumb.
Another engineer might say TypeScript is the most simple because in code written with it you can clearly see the shape of the data that's being passed around between functions.
Then yet another engineer may argue that ClojureScript is the most simple because of its succinctness and expression-based nature.
Personally, I think they can all be correct and as with any subjective discussion it's all a matter of perspective. My advice would be to have opinions of your own but also stay open-minded, don't push people too far outside of their comfort zones, and just keep it simple.
Are You Convinced Yet?
I have been fortunate enough to have worked with and learned from some incredibly talented engineers, and I truly believe that incorporating these three tips into your team's workflow will have a profound effect on the team's efficiency and the overall quality of the code.
If your team is struggling to adopt these practices, we can help! At Evaluates2 we provide group workshops, full-time on-site consultants, and impartial expert opinions to help you and your team(s) build better software, faster. Don't hesitate to contact us today!