Focusing on your staff and production methods can help you meet the challenges of releasing a product quickly and on time. I’m not talking “we’re going to use the Agile method because it’s ‘better’ and faster.” I’m talking about looking at your teams – both as individual players and cohesive units – and understanding how they can work more efficiently.
Expert after expert has said that a methodology is only good if it works for you – you shouldn’t adhere strictly to a method simply for namesake. That same sentiment can be applied to maximizing the efficiency of your teams. Don’t throw work at a team simply so they’re always busy. Pay attention to the time they need to complete a task well and set the flow that way. Overloading a team will bog them down and force them to rush through work to keep up. Rushed work is poorly done work and can cost you down the line when you need to release a patch for an issue that made it through to production.
Derek Huether, of Leading Agile, says that like the original Ford Motor plants, it’s about maximizing the flow of work, not the amount of work.
Henry Ford did not have everyone working at 100% utilization. If everyone worked at 100%, the result would have been congestion — bottlenecks within his (assembly) system and the production of excessive parts inventory. Instead, one of the many things he did was focus on limiting lead times. That’s the time something waits before an activity happens. By understanding his system, he was able to have the right amount of people, working at the right pace, in the right sequence, in order to maximize flow (delivery through the system).
He recommends understanding four key factors to help maximize the flow:
- Understand Current and Potential Capability and Capacity
- Understand the Delivery System and Establish Goals
- Balance Capacity and Capability with delivery throughput
- Monitor Performance
You can read more about each point at Leading Agile.
The key here is figuring out what works for your teams. Don’t flood them for the sake of keeping them busy, but don’t let them have so much down time that they get bored and lose their focus.
Creating a truly efficient environment needs to spread beyond the QA department. Waiting until the end of the SDLC to address quality and testing is only going to slow down the process. Simple problems need to be addressed or avoided earlier in the process. Have QA professionals review the product’s purpose, features, early designs and any potential road maps – they may be able to spot problems before anything is coded.
Jeff “Cheezy” Morgan spoke about preventing bugs before they’re ever created at STAReast. Taking up this topic, Eric Jacobson (of Test this Blog) discussed writing basic unit tests before any product code exists. This gives developers something to aim for, essentially. They had to write code that would pass these tests. Creating tests before coding begins means developers are aware of and avoid potentially buggy situations. From Test this Blog:
- Per Cheezy’s rough estimate 8/10 bugs involve the UI. There is tremendous benefit to the programmer knowing about these UI bugs while the programmer is writing the UI initially. Thus, why not have our testers begin performing exploratory testing before the Story is code complete?
- Programmers are often incentivized to get something code completed so the testers can have it (and so the programmers can work on the next thing). What if we could convince programmers it’s not code complete until it’s tested?
Keeping departments separate will always cause friction and slow down the process. Having teams work together promotes a more amicable work environment and makes everyone’s job easier. Everyone at the company is working toward a common goal – to release a good product. Don’t lose sight of that fact during the daily grind.
The best way to have a more efficient SDLC is to know your staff and to work together. Don’t get hung up on methodology rules or department divisions. Following someone else’s rules won’t necessary work for your team, so create your own rules.