Photo by Moritz Mentges on Unsplash
I have come across many development team members that are put off by agile methodologies. When I dig into what they are hesitant about, it almost always boils down to the abstract agile hammer that they have been beaten by.
Regardless of the agile methodology implementation, if it is being used as a hammer it will always bruise the people that find themselves under it.
This doesn’t mean that the agile method being used, was being used improperly or maliciously. They could be following the “book” on how to do agile development. The results could even look great, but is the team actually happy? Are you going to retain your great people?
I truly believe that everyone can enjoy their work and simply performing well does not mean that people are happy and their “Agile” implementation is working.
From an individual and team perspective, there are many signs that show a team might be hurting. If team members aren’t speaking up or listening to each other, something is wrong.
Agile is all the rage, and as such, everyone says they do agile development. However, I have found this not true on a couple of fronts. First are places that are forcing their waterfall cycle into some agile methods. Waterfall has its place, but it is not needed in most software development. Waterfall is comfortable though, here is everything you need to do, go do it. There is a level of control that is hard to give up.
The second fake agile that people say they are doing is when agile becomes “Agile”. Agile, by its very word, should be flexible. But some implementations end up extremely dogmatic in its rules and practices. A rigid set of processes can't be agile by definition.
Let's say for the sake of this example that the best agile method is Scrum. Does that mean Scrum is what will work in all situations with all teams? I mean, I guess you could force that, then every team member must conform.
When a team's operation is dictated from on high, it could work, but could it work better in a different way? We would never know. What works for one team might not for another. Locking everyone into a standard may help operationally, but could be detrimental to the happiness and performance of some teams and their members.
Agile tools are another way of turning glee into gloom. No tool is going to be perfect, unless it is something home grown, but those have their own limitations (like time to build, or limited visibility). The problem arises when tools aren’t perfect. Two ways of handling imperfections is to either, force your processes onto the tool, or to change your processes to meet the tools abilities.
Trying to force fit a process over an existing tool can have detrimental effects. It can make the tool less effective and have effects that spill over to other users. On the flip side, just accepting what is there could do the same. I have leaned towards using the tool how it is meant to be used, and dealing with any fallout.
Also forcing a single tool/process across all team members goes back to a sign that one size doesn’t fit all.
At the root of these warning signs are usually two core issues. Both of which create weaknesses in process, people, and results.
When trust is lost or worst yet never given, all different kinds of symptoms start popping up. The two-way street of trust must be the most important thing between the individuals involved. If the management team feels like they can’t trust the development team to execute the company needs, then forceful constrictions are put in place. If the development team can’t trust the direction of the management team the care of their work will suffer.
Every single company should be putting an emphasis on technology. While most don’t need their own development teams, most will be using technology to interact with their customer base.
Now, if a company does have a development team (internal or contracted), they should see themselves first as a technology company. Failure to do this can put an emphasis on sales or marketing over the product. Sales and marketing are extremely important, but the product is what keeps customers. You could have the best sales and marketing teams, but with a buggy inferior product, your customers will only be so loyal. The best companies I have done work for see themselves as technology companies first.
The root issues must be addressed before finding a way to improve the software agile implementation.
The most important way forward is to instill care in everyone’s work.
The more ownership and responsibility the further down the hierarchy tree the more empowered the people will feel. The more direct control someone has over their daily life the more care they can take in it.
While siloed work can create experts for the given area, it can also create walls. The more open communication and collaboration that happens between all those involved the more they can care for each other's efforts. This isn’t just limited to front-end, back-end, quality assurance team members. It can include getting participation from key stakeholders and subject matter experts.
This could have the reverse effect by adding too many cooks. There is a balance that needs to happen in order to create true cross-functional care. That is handled by making sure that each individual is given as much ownership of their pieces as possible.
Allowing each team and team member to determine what is best for them will permit them to care for their choices. Of course, they may not have enough knowledge to know what will work best for them. Giving them the room to explore, ask questions, make mistakes, and grow will create a much stronger team than one being dictated to.
This may create a logistical nightmare if every team decides to do something different. This can be overcome by having a cross-functional team that all work together on the same platform. This could include tools, processes, methodologies, etc. There may be someone that needs to normalize the data between teams to be able to report on status, but that work is a small cost to pay if the teams are happy and their work fulfilling.
Even a team that is performing well, can improve their working environment. Locking people into a rigid “Agile'' methodology can suffocate and eventually lead to unhappy team members and possibly turn-over. While there are no perfect agile solutions, dealing with deep rooted issues and adding care can help resolve these “Agile” blues.
Are you ready to build something brilliant? We're ready to help.
.jpg)
