A conversation between an analyst and developer normally takes one of two directions.
The first, and unfortunately much less common, goes along the lines of “Hi Mr. Developer, I’d like to run some of the changes business would like to implement by you.” To which the response is “Oh hey, Mr. Analyst, sure. Let’s hear them” An exchange of productive challenging, probing, and questioning is then entered into, after which the analyst returns back to business with a few – previously unidentified – challenges to solve, or with a timeline, and complexity rating from the developer. The features just discussed will then be added to the product backlog, and everyone is happy.
The second, and unfortunately much too common, can take the form of any of the following:
- “What does business want now?”
- “You’re kidding?! We’ve just spent x days doing y”
- “I don’t have time for this right now”
- “This will never work”
- “This is daft”
The challenge with the above is multi-faceted. It can result from business changing their minds too frequently, from developers who are not fully invested in the business, from lack of relationships between developers and analysts, or from incompetence – either on the part of the analyst or the developer.
The list above may not be comprehensive, and one or two key root causes may be absent from this analysis, however the message – it appears – is consistent. The desired feature will not work, or not very easily, that is. The main problem here is not the technical faults or challenges of the feature in question, but the problem that faces many businesses today.
Developers and analysts alike are becoming (if they have not already become) a commodity.
Good, great, and amazing analysts and developers can be found in all corners of the globe, and too often businesses are quick to hire these practitioners based purely on technical ability, and to fill an urgent capacity shortfall. Team fit, and buy-in into the business vision, is not probed sufficiently during the interview process.
In contrast, only after this area is examined in detail, and only those who are a solid fit for the team and business are entertained as candidates, should technical ability be assessed. Strong, positive, and productive conversation is a vital ingredient for business growth. Where key resources are not fully invested in realising business goals, failure is more often then not a sure outcome. The conversations need not be easy, nor do they need to result in a solution, however they need to be focused on the same goal and conducted between individuals with mutual respect for each other and the business.
Businesses needs to stop thinking of their employees (in this case, developers and analysts) as commodities. Developers are not there to simply implement logic and business rules, and analysts do not exist to document features.
Another consideration is that the burden does not fall squarely on the shoulders of the business stakeholders. IT project teams also play a part here. It’s important to realise that business often does not – and should not – have a concrete idea regarding how a product, feature, or process should look when complete. If they do, they are going down the path of the widely condemned Waterfall methodology. As Eric Reis describes in his book, the Lean Startup, constant roll out of small batches of features is the most effective way of delivering a product people want to use. Developers need to therefore understand that business does not always get things right first time around, and that change to work already delivered is, in most cases, a sure bet.
In conclusion, the dynamic between developers, analysts, and business should always be a careful consideration when building a project team and a successful organisation Careful consideration should be given to the placement of humans in the various roles – not only to how the human will deliver on their job spec, but also how they will engage with their co-workers.