_edited.png){kind=logo}
A common issue I’ve seen in the trenches with teams is an unwillingness to cross over lines to do work outside of their specific specialty.
Management refuses to let team members cross skill boundaries because “We’re not paying for you to test, we’re paying you to write software…”
Business analysts and developers struggle with why they would be asked to develop test cases for THEIR (quality assurance’s) work.
Developers push back against anything outside of writing code because obviously that’s the most important aspect of building software right?
Quality assurance people want to write their test cases without the “trouble” of having to work with the development team to create them.
These walls that have been erected around the different skillsets of the team do nothing but hinder getting software out the door. Building software is not about the individual and it’s not about the specific skill you provide.
Every step in your software development factory is there because the organization or your team values it enough to have placed it on the delivery line. Before that software will be released to the customer, these steps must be done. We could argue all day about which is the most important but at the end of the day, the customer wants quality-working software. They simply don’t care about what is the most important in this equation. They care about results.
Developers – if you write the best most perfect widgets all day long and pass them off to quality assurance but they aren’t moving them down the line to release, then the customer is getting no value from those widgets. If you take that a step further, consider that it is likely costing the customer even more money in maintaining those widgets on the shelf.
Business Analysts – if you gather the best requirements months out ahead of the development team because they’re bogged down building other software features, then the customer is getting no value from those artifacts. And again, it is likely costing the customer money to maintain those artifacts on the shelf.
This is a hard thing for us developers right…I mean, “Without me, there would be no software at all.”
And you quality assurance folks, I can hear your voices calling, ”Without me, those developers would be delivering crap.”
Business analysts are crying, “You want developers talking to the business…oh yeah, that’s a good idea! Most healthy 5 year olds have better social skills”
And to all of you, I say yes, you are right. As a rule, developers AREN’T as good at talking to the business as an analyst and quality assurance IS best done by specialists and developers time IS best spent developing but that’s in a perfect world and in a team without exceptions.
Remember though, we are in the business of delivering software and that involves all of these pieces, not just what you are good at. If we believe that software delivery is the most important thing to the customer, then we do what needs to be done to make that happen…period.
That might mean slogging around in an area where our efficiencies are cut in half and while I am calling for us to wade in, I am not calling for us to do it under the radar. If this is occurring, build signals into your system that will fire off to those who can help solve these issues. Don’t do it silently and have inefficiencies reign but do it out of necessity and make the team and those who can work to solve these problems aware.
Swarming would not be necessary in a perfect world but just as in manufacturing, parts of the system will break down periodically. At that time, the line doesn’t keep producing causing even more havoc, but individual’s swarm around the issue so they can get the line moving again. When our software development factory breaks down, swarm around those issues and get the line moving for your customer again. In the end, that is what we do.