We all love star wars. But when it comes to software and agile development, the entertainment value of star wars is not its only redeeming value. star wars also teaches us a lot about leadership styles and software management for Agile and gives us many valuable lessons that we can use and practice today.
As an aspiring Jedi and expert with five years of QA experience and three years of QA management experience, I find that star wars and its culture are subjects that continue to appear in the various forums in which I participate. In honor of Star Wars Day (May 4), here are five software management lessons we can learn from star warsto help you be better prepared and organized in a fast-paced, agile world.
1. Testing is essential
The Death Star was designed to be the galaxy’s ultimate weapon. Investment and maintenance were costly; In reality, Lehigh University students recently completed that the cost to build the Death Star would be $8.1 quadrillion, or 13,000 times the Earth’s GDP.
In the end, there was a heavy investment in the Death Star, but apparently there wasn’t enough testing, as the Rebels were able to find and exploit a single point of failure that blew up the Death Star into small pieces. In a DevOps world, the lesson here is to use continuous testing to deliver great software at all times and to test not just the functional aspects of your application, but the entire 360° quality view, including including performance, usability and security. If Darth Vader had invested a bit more in testing and less in smothering his commanders, perhaps this flaw could have been avoided.
2. Potential is just the beginning
One thing that star wars teaches us is that potential can only take you so far. Anakin Skywalker was created to be the chosen one, and throughout his career he has proven 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 from agile development is that potential can only take you so far; it is more important to apply it correctly. The software developers you hire ultimately have this same responsibility; they may interview well and seem incredibly talented, but at the end of the day, they must deliver and produce effective and measurable software results. One of the main challenges When it comes to DevOps, the onus is on the developers not only to build the new feature, but also to ensure that it has the quality and robustness it needs to support the end user. Their responsibility does not stop at the QA phase; it goes all the way to the end user.
3. Learn from your failures
In a first 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 Lightspeed fleet too close to the Hoth system, the Rebel Alliance was able to detect the Imperial approach and quickly put their defense in place. Enraged by this mistake, Darth Vader used the Force to choke Admiral Ozzel to death. Captain Piett, Ozzel’s second-in-command, was later promoted to Admiral and given command of the Imperial fleet.
This quick and decisive punishment for failure is today a huge management error. Darth Vader created a culture of fear, where people were afraid to offer feedback or suggestions, choosing instead to follow orders for fear of failure. Nothing, however, stops innovation, motivation, and collaboration faster than a fear-based culture. Failure is often the engine of success. Mistakes happen, but the key is to learn from those mistakes and get back on track. As John Maxwell once said, “Sometimes you win, sometimes you learn.”
This also applies to agile QA organizations. When your testers miss bugs (which we call “escaped flaws”), they may be found and reported by the end user. This shouldn’t be a cause for panic, but rather an opportunity to learn, improve, and prevent them from happening again. Agile organizations must be flexible and able to adapt quickly to changing conditions. It means allowing initiative and decisive action 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, revealed the truth. This concept of delivering bad news rather than surprises also applies to agile effort estimation and exceptions. In the end, it cost Luke his hand.
Before talking about agile estimation, it is important to put in place good development practices. If the software is a constant source of unpleasant surprises, no estimation method, agile or not, will succeed.
Implementing the MVP (minimum viable product) concept on the features you release will help you take a more progressive approach. Instead of trying to release a big feature, you can always break up its release into a few rounds while taking advantage of the phased approach to getting feedback. This powerful concept allows you to test your ideas by exposing a first version of your product to target users and customers, collecting relevant data and learning. Comments generated by MVPs can bring bad news to developers, but they can also guide them forward. In this case, the truth may be better, even if it hurts. I hope you don’t lose a hand like Luke did.
5. To do or not to do
As the smartest and most experienced Jedi, Yoda once said, “Don’t try. Do or don’t. There is no try.” It’s a valuable lesson to learn. When you do something, go all out with no excuses.
The greatest risk of a release is finding and fixing flaws late in the process. This puts product stakeholders in the uncertain position of having to deploy known defects in order to meet a deadline. However, planning or even implementing tests early in a sprint increases predictability and reduces the chance that defects will constrain timely deployment.
The well-known “what’s done is done” principle of agility also applies here; features developed in an iteration must be 100% complete by the end of the sprint. Features must be fully developed, tested, and accepted by the product owner before they are rated as complete, so that they can be deployed to production at the end of the sprint and delivered to customers.
Become a Jedi Master in Agile
Luckily, 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 your organization. Agile organizations must be flexible and able to react 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.
