Software development comes in many forms, and has become a major commodity in our modern marketplace. What I find so baffling is how inefficiently upper management tends to implement that development, especially in larger corporations.
Way too often these companies will not invest in the proper tools to get the job done believing that it costs too much money. According to Paul Vallely, Business Development Director at Compuware, using the wrong tools can hinder the success of your DevOps transformation. He quotes a Compuware-commissioned Forrester report from 2016 that found 22 percent of respondents struggle to accelerate mainframe application development and delivery because of “programming software that is unable to meet performance expectations,” and 21 percent struggle due to a “lack of tools to understand business rules and program logic.” 1 Vallely goes on to describe the best way to choose DevOps tools:
[T]he developers are the ones using the tools; empowering them to choose what DevOps tools they feel are best-of-breed correlates to their success. It also flies in the face of monolithic mainframe software vendors like IBM and CA, both of which follow outdated, procurement-led tool acquisition practices that result in developers being told which tools they can use based on price, licensing and budgets. If those force-fed tools are not easy-to-use and lack the necessary DevOps functionality, developers will resort to manual processes, which, almost by definition, prevent DevOps success. 2Vallely, Paul
I don’t think that it is a large leap to take this concept beyond just DevOps. Especially in software development, the tools and tech evolve extremely quickly. For developers, and everyone involved with the development process, to do their jobs properly, they must have the proper tools. Without those tools, the quality of the software the developers are able to output drops, and it shows. In 2018, the US spent $800 billion on poor quality software due to internal failures and deficiencies. According to BitBar, one of the best ways to resolve this issue is to “Commit to measuring your organization’s CPSQ, so you can make an informed business case for investing in new software quality processes and tools.” 3
A really frustrating issue that I see all of the time is Accountability issues within the team. So often I see companies that have separate product and engineering departments. The product owner and product manager often knows very little about the implementation of the product. They simply pass information down from above. Often, these companies seem to appoint product owners as “overseers” in a scrum team which completely upsets the balance. Fabio Panzavolta shows us four accountability imbalances that can seriously affect our scrum teams.
Product Owner is KingThe Product Owner dictates the law, not compromising with the Development Team and forcing to deliver Increments with fixed scope at the end of each Sprint.The Development Team DictatorshipIn this configuration the balance is all on the Development Team side inhibiting the possibility of creating a Self-Organizing Scrum Team.Scrum Master is Project ManagerIn this case, the team isn’t self-organizing because of the Scrum Master misunderstanding of his role of Servant Leader.The Organization is BossThe Scrum Team is victim of the fragmented responsibilities in the Organization and the complexity of the hierarchical chain of command.In this case, company culture and Scrum misunderstanding may be the impediments to self-organizing teams.Panzavolta, Fabio 4
Along with accountability issues, UX developers and testers are often separated from the general development teams. This system slows down development and creates issues that should never exist. Along with keeping the proper accountability balance within scrum teams, a UX developer needs to be a part of the team so the user experience components are developed along side everything else. My personal opinion is that each team should have a QA tester, as well. That would save time and money in the long run, but most companies are not really concerned with the “long run”.
Now, there are a lot guides and consultants who like to recommend that developers give management the “benefit of the doubt” and try to make suggestions for improvement. They say to show management figures that show how much money the company could save by upgrading their tools, or adding more testers. The problem I have with this approach is that companies tend to be very resistant to evidence. The figures showing that remote workers are more productive than in office workers has been out for years, but it took a global pandemic to push companies into adopting remote policies. Even now, many companies are trying to figure out ways to get people back into the office. Therefore, what makes people think that companies will accept evidence that spending large amounts of money on development technology will save them money in the long run?
Another issue I have is, how much influence do developers really have in large or mid-sized companies? Will C-suite executives really listen to the expertise of the developers on the floor, or will they smile, nod, then toss it aside and do whatever they want? It’s times like these that I am reminded of an old Steve Jobs quote: “I don’t hire smart people to tell them what to do. I hire smart people to tell me what to do.” If only most CEOs were as smart as Steve Jobs was…
Comments