Are you joining a good engineering team?
You’re unlikely to read a job spec these days that doesn’t contain the word, Agile (capitalised, of course), scrum, kanban, or possibly the acronym TDD. It’s comforting for developers to know that they won’t be expected to work under the Waterfall software development process; that they’re not writing legacy code from scratch without a build pipeline of hierarchical automated tests; or worse still, they won’t be on the wrong end of undocumented, random, last minute feature changes. The job spec might have little basis in reality though.
Whether or not a company follows an Agile process, either honestly or by Cargo Cult, is not what counts. What really matters is if the team has the following:
- Good programmers
- Focus on delivery
- Mature communication
- Surfacing the truth
Put simply: good teams deliver, bad teams complain.
In large financial service companies, I’ve sat in sprint retrospectives led by Project Managers / Agile Coaches / Business Analysts, where colleagues complained about the same symptoms again and again. Nothing changed. There was no interest in finding the root cause (5 whys), and no power to change anything even if it were known what to fix.
If asking direct questions about software development process will not tell you if you’re joining a good team in which to work, what will?
#1 Good programmers
Bad work environments will always make it hard to ship good code. But not having good programmers makes it impossible. If the salary or anything else about the job says RED FLAG to you, then it probably has to other competent coders. Also ask yourself, was I challenged in my interview? How bad could somebody be and _still_ pass whatever questions or tasks were thrown at them?
#2 Focus on delivery
Beautiful architecture is something we love when we see it. For instance the IoC pattern custom script loader you added to allow other engineers to configure the resources they needed dynamically. You looked at the code for half an hour after submitting the merge request. But nothing beats making decisions and shipping things. If a team can’t describe three features they put live in the last month, ask what the vision is for product. Do they have a plan for making something somebody will use?
#3 Mature communication
No two people will agree about everything all the time. In a team of half a dozen or so, there are going to be disagreements. Every team member will bring a slightly different viewpoint to the business or technical problems being solved. There will be the best way to proceed (with 20/20 hindsight), and there will be the way that things actually get done. Ask who decides what the latter is, and more importantly, how. Is the tech lead autocratic; is the superstar programmer passively overriding everyone else; are all potential solutions enumerated by the whole team with no one prepared to decide on a path to take? And more importantly find out how they resolve disagreements when two or more in the team are at loggerheads about the best way forward.
#4 Surfacing the truth
Productive collaboration, excellent coding and delivering on time is the best way for a team of developers to operate but it’s not always possible. Sometimes what you’re asked to do and what you’re capable of do not intersect, whether individually or collectively. Whether this becomes apparent two months, or two minutes, before a deadline, the best way to proceed is to be upfront and honest. Of course, this is only recommended if you are trusted and have the backing of the business. Software development is an exercise in uncertainty and you can never deliver everything to the specification demanded for the deadline requested. Ask what the response was the last time you had to deliver bad news. Was it disappointment but an opportunity to learn and avoid similar mistakes in future? Or was it denial, misdirection, late nights, tension and animosity?
The approach to #4 above is crucial. Agile at it’s heart is about exposing the truth, and doing so in a timely manner. I have friends to whom the daily standup is anathema. They expect to be left alone for a few months to have the problem solved by themselves. Easy. Unless as well as a good programmer you’re also a business and product expert in the field in which you’re working, it’s likely that, unsupervised, you’ll build a system that almost looks likes something that solves the business problem at hand, but doesn’t quite.
The bureaucracy of Agile is there because, when done properly, it shines a light on the truth and says, “Here. Your problem is right here.” The truth could well be dire news. It could come during a daily standup, in sprint planning, in a retrospective, or demo. Regardless of where it comes, how it’s dealt with is the most important takeaway. Teams that brush an inconvenient truth under the carpet are wasting their time doing Agile in the first place.
Hiding the truth is the antithesis of what Agile is all about. In the next few blog posts I’ll be pointing out more anti-patterns that I’ve seen by teams who claim to be Agile, but are in reality fighting against the system they claim to champion.