We all love Star Wars. But when it comes to software development and agile, the entertainment value of Star Wars is not its only redeeming value. Star Wars teaches us a lot about leadership styles and software management for agile as well and offers us many valuable lessons that we can use and practice today.
As a Jedi in the making and an expert with five years of QA and three years of QA management experience, I find that Star Wars and its culture are topics that continue to pop up in the various forums I attend. In honor of Star Wars Day (May the Fourth), here are five software management lessons that we can learn from Star Wars, to help you be more prepared and organized in a quickly evolving, agile world.
1. Testing is everything
The Death Star was designed to be the ultimate weapon in the galaxy. The investment and upkeep was costly; in fact, students at Lehigh University recently concluded that the cost to build the Death Star would be $8.1 quadrillion, or 13,000 times Earth's GDP.
In the end, investment was heavy in the Death Star, but apparently not enough testing was made on it, since the rebels were able to find and exploit a single point of failure that caused the Death Star to explode into tiny pieces. In a DevOps world, the lesson here is to employ continuous testing to deliver great software all the time and to test not only the functional aspects of your application but the entire 360 quality view, including performance, usability, and security. If Darth Vader had invested a bit more in testing and less on choking his commanders, perhaps this defect could have been prevented.
2. Potential is only the beginning
One thing that Star Wars teaches us is that potential can only take you so far. Anakin Skywalker was set up to be the chosen one, and throughout his career, he proved his potential in battle and his mastery of the Force. But he also made the wrong career choice and ended up—as we all know—on the Dark Side.
The takeaway for agile development is that potential can only take you so far; it’s more important to apply it correctly. The software developers you hire ultimately have this same accountability; they may interview well and seem amazingly talented, but in the end, they need to deliver and produce effective and measurable software results. One of the major challenges when it comes to DevOps is the accountability of the developers not only to create the new feature but to also make sure it has the quality and robustness it needs to support the end user. Their responsibility doesn’t end at the QA phase; it goes all the way to the end user.
3. Learn from your failures
In an early scene of The Empire Strikes Back, the Empire attempted to wipe out the Rebel Alliance once and for all in the Battle of Hoth. However, because Admiral Ozzel took the Imperial Fleet out of light-speed too close to the Hoth system, the Rebel Alliance was able to detect the Imperial approach and quickly set its defense. Enraged by this error, Darth Vader used the Force to choke Admiral Ozzel to death. Captain Piett, Ozzel’s second-in-command, was then promoted to admiral and given command of the Imperial Fleet.
This quick and decisive punishment of failure is a huge error of management today. Darth Vader created a culture of fear, where people were afraid to offer feedback or suggestions, choosing instead to follow orders out of fear of failure. Nothing, however, shuts down innovation, motivation, and collaboration faster than a fear-based culture. Failure is often the engine that drives success. Mistakes happen, but the key is to learn from these mistakes and get back on track. As John Maxwell once said, "Sometimes you win, sometimes you learn."
This applies to agile-driven QA organizations as well. When your testers miss bugs (which we call "escaped defects"), they could eventually be found and reported by the end user. This should not be a cause for panic—rather, it should be an opportunity to learn, improve, and prevent them from recurring. Agile organizations must be flexible and capable of quickly adapting to changing conditions. This means allowing for initiative and decisive actions at all levels, even if it leads to some mistakes.
4. It’s better to deliver bad news than surprises
With the famous line, "Luke, I am your father," Darth Vader, the essence of evil, came right out with the truth. This concept of delivering bad news rather than surprises applies to agile effort estimation and exceptions as well. In the end, it cost Luke his hand.
Before discussing agile estimation, it’s important to have good development practices in place. If the software is a constant source of unpleasant surprises, no method of estimation, agile or otherwise, will succeed.
Implementing the MVP (minimum viable product) concept on features you release will help you think in a more phased approach. Instead of trying to release a significant feature, you can always split its release into a few rounds while leveraging the phased approach to get feedback. This powerful concept lets you test your ideas by exposing an early version of your product to target users and customers, collecting relevant data, and learning from it. The feedback that MVPs create may deliver some bad news for developers, but it can also help guide them forward. In this case, the truth may be better, even if it hurts. I hope you won’t lose a hand as Luke did.
5. Do or do not
As the smartest and most experienced Jedi, Yoda once said, "Try not. Do or do not. There is no try." This is a valuable lesson to be learned When you do something, go all out with it, without excuses.
The biggest risk of a release is the discovery and resolution of defects late in the process. This puts product stakeholders in the uncertain position of having to deploy known defects in order to hit a deadline. However, planning or even implementing tests early within a sprint increases predictability and reduces the chances that defects will be a constraint to a timely deployment.
The well-known "what’s done is done" principle of agile applies here as well; features developed within an iteration should be 100 percent complete by the end of the sprint. Features should be fully developed, tested, and accepted by the product owner before assessing them as done—so that they can be deployed to production at the end of the sprint and delivered to customers.
Becoming a Jedi master in agile
Thankfully, not every project is the Death Star. When you have a project that feels like life or death, it can be demoralizing for your team members and organization. Agile organizations should be flexible and able to respond to change, making adjustments based on valuable customer feedback.
The best approach is to align the steps mentioned above, with everyone on board looking to work together to get the job done. Just as becoming a Jedi master takes time and practice, software development in an agile world requires dedication, patience, and determination.
May the Force be with you.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
