June 29, 2022

5 software management lessons to learn from Star Wars

We all love Star wars. But when it comes to software and agile development, the entertainment value of Star wars is not its only redemptive 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 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 wars, to help you be better prepared and organized in an agile and rapidly changing world.

1. Testing is everything

The Death Star was designed to be the ultimate weapon in the galaxy. The investment and maintenance were expensive; In reality, Lehigh University students recently concluded that the cost of building the Death Star would be $ 8.1 quadrillion, or 13,000 times the Earth’s GDP.

In the end, the investment was heavy in the Death Star, but apparently not enough testing was done on it, as the Rebels were able to find and exploit a single point of failure that caused the star to explode. of death in 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 only the functional aspects of your application, but the entire 360 ​​quality view, including performance, usability and security. If Darth Vader had invested a little more in testing and less in choking his commanders, this flaw could perhaps have been avoided.

2. Potential is just the beginning

One thing that Star wars teaches us is that potential can only take you to a certain point. Anakin Skywalker was created to be the Chosen One, and throughout his career he has proven his combat potential and 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 is more important to apply it correctly. The software developers you hire ultimately have this same responsibility; they can interview well and appear incredibly talented, but at the end of the day, they have to deliver and produce effective and measurable software results. One of the main challenges When it comes to DevOps, it’s up to the developers not only to create the new functionality, but also to ensure that it has the quality and robustness it needs to support the end user. Their responsibility does not end with the QA phase; it goes 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 during the Battle of Hoth. However, because Admiral Ozzel pulled the Imperial Fleet out of the speed of light too close to the Hoth system, the Rebel Alliance was able to detect the Imperial approach and quickly set up its defense. Enraged by this mistake, Darth Vader used the Force to suffocate Admiral Ozzel to death. Captain Piett, Ozzel’s second in command, was then promoted to admiral and given command of the Imperial fleet.

This swift and decisive punishment for failure is a huge mismanagement today. Darth Vader created a culture of fear, where people were afraid to make comments or suggestions, choosing instead to follow orders for fear of failure. Nothing, however, blocks innovation, motivation, and collaboration faster than a fear-based culture. Failure is often the engine of success. Mistakes do 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 agility-driven QA organizations. When your testers miss bugs (which we call “escaped faults”), they could possibly be found and reported by the end user. It 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. This means allowing initiative and decisive action at all levels, even if it leads to some mistakes.

4. It is better to deliver bad news than surprises.

With the famous line “Luke, I am your father”, Darth Vader, the essence of evil, came straight out with 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 discussing agile estimation, it’s important to have good development practices in place. If software is a constant source of unpleasant surprises, no estimation method, agile or otherwise, will succeed.

Implementing the MVP (Minimum Viable Product) concept on the features you release will help you think in a more phased approach. Instead of trying to post an important feature, you can always split its post 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 from it. Comments created by MVPs can bring bad news to developers, but it can also guide them forward. In this case, the truth may be better, even if it hurts. Hope you don’t lose a hand like Luke did.

5. To do or not

As the smartest and most experienced Jedi, Yoda once said, “Don’t try. Do or don’t. There is no trying.” It is a valuable lesson to learn. When you do something, go all out, with no excuses.

The biggest risk with a release is finding and fixing defects late in the process. This puts product stakeholders in the uncertain position of having to deploy known flaws in order to meet a deadline. However, planning or even implementing testing at the start of a sprint increases predictability and reduces the chances that faults will be a constraint for rapid deployment.

The well-known principle of agile “what gets done gets done” also applies here; features developed during 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 evaluating them 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

Fortunately, not all projects are the Death Star. When you have a project that looks like life or death, it can be demoralizing for your team members and your organization. Agile organizations need to be flexible and able to react to change, making adjustments based on valuable customer feedback.

The best approach is to line up 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, developing software in an agile world requires dedication, patience, and determination.

May the force be with you.

Keep learning