How to Improve Software Organizations
Is your software development organization performing as it should? There is always room for improvement, but some organizations are in more need of help than others. Wherever you are on the continuum, it’s important to identify where you need to go and how to get there, because organizations need a clear vision to help everyone drive in the same direction. We should evaluate our processes, technology, product line, documentation, culture, and our people themselves. But, what do we evaluate them against? How do we measure our progress? I believe there are three key measuring sticks for evaluating a team or organization, and if we keep these things in focus productivity will skyrocket.
Let’s look closely at each one.
Quality is critical to every organization. This word applies to everything we do, not just how many known defects we have in our software. Imagine what you can get done with 40 high quality hours—you might not need to borrow from nights and weekends to get caught up. If you write an automated test, make it a good one that adds value, otherwise why bother?
Collaboration is key to producing a quality deliverable because our peers will see things we don't. If something needs to be done well, particularly if it's customer-facing, it's wise to let extra eyes look at it. When writers want to know if their articles are high quality, they ask for critiques because they understand that there's strength in numbers. Whether it's code reviews, pair-programming, or simply "Hey, can you take a look at this?", leveraging the additional pairs of eyes all around us will help keep us on the rails.
When trying to improve software quality, I believe the most important thing is automated testing. Manual test cases are cheaper to create than automated test cases. However manual tests are much more expensive to execute, particularly if you have to make numerous passes to test everything across multiple browsers, operating systems, and device types. Developers should be doing significant testing with Karma, Spock, or JUnit, but there should also be functional testing with something like Selenium, SOASTA, or Cucumber. What you're really after with all of this is early defect detection, because the further you get from when the developer wrote the code, the more work is required to resolve an issue. It’s much easier to resolve a defect in code I wrote yesterday than code I wrote 3-6 weeks ago.
Focusing on efficiency helps you streamline your organization and minimize the amount of effort required to perform each task. Repeatable processes that have become second nature require much less effort. Automation also plays a major role in efficiency, because you want employees to focus on doing tasks that aren't repetitive and require brainpower (writing, coding, designing, planning, etc.). Once the code is ready, automation should take over so the code is built, tested, and deployed automatically. The same automated deployment process should handle each subsequent environment, including production. Easy deployments allow more frequent deliveries to production so you can be much more responsive to the needs of the business.
It’s important for everyone in the organization to evaluate what kinds of things they do manually. Can those things be streamlined or automated? If you do it a lot, it’s probably a good candidate for automation. In some cases, we just need to redefine our processes to eliminate unnecessary steps. In others, we need to identify better tools that automate or speed up more of what we do every day.
Ticket management tools like Quality Center or Jira should also be evaluated. What metrics do you track? What reports do you generate? Do you spend a lot of time in Excel every week getting the numbers you must send to the leadership team? For agile teams, how do you calculate your team’s velocity? Does your tool handle it for you? Look for tools that save you effort (ex. Version One) rather than just doing what you know.
Balance is a critical part of driving efficiency in your organization. You might think of your organization like a sailboat. If the boat is unbalanced, there will be drag which causes it to be slower in the water. Also, the rudder may not work properly, making it much more difficult to turn the boat. When humans make mistakes, they often compensate by rushing to the “opposite side of the boat.” When software organizations endure pain and suffering because their product went out the door without sufficient testing or planning, they often run fast and furious toward heavyweight processes, approval gates, and analysis paralysis. They run from one problem into the waiting arms of another.
'How much documentation should be required?" Only write what is needed for people to understand what needs to be done. If documentation is being written to satisfy an approval gate or check a box, we should probably pause and consider whether or not it’s necessary. "How much process is required?" Just enough. "How much time should be spent doing architecture and design?" Just enough. While rework is certainly inefficient, it’s sometimes better to postpone the real solution and implement a quick fix in order to be responsive to your customers’ urgent needs. Life is a balancing act. This applies to everything we do as a company. Goldilocks was desperately searching for balance. Maybe we should too.
We all want our lives to be better. We want easier deliveries, smoother transitions, happier teams, and happy customers, with minimal pain and suffering. When we begin to view our organization through these three lenses, it helps us evaluate and prioritize changes. It focuses our attention on the kinds of changes that will actually benefit the organization and help it run smoother. You’ll be leaner and meaner, so over time you’ll see productivity increase while stress and frustration decrease.
Quality, efficiency, and balance ultimate result in something every organization is striving for: speed. We want speed to market, responsiveness to our customers, and the ability to turn on a dime, but actually achieving this isn't intuitive. "Let's just hire more people so we can go really fast!" Adding a lot of people will certainly help you go really fast, unfortunately sometimes they help you go really fast into the ditch. A wise colleague once told me that you have to slow down to go faster, and it's absolutely true. Speed requires up-front thought and effort, particularly in the area of automation. If you take the time to ensure quality, efficiency, and balance, you'll go fast naturally. Roar like a lion, sprint like a gazelle.