MBA228: Software Development Pearls

11/30/21 • 25 min

1 Listener

Karl Wiegers shares his lessons on requirements, project management, design, quality and more. Karl’s advice can make you significantly better at what you do.

Show Notes

Karl Wiegers started programming in 1970 and has collected 60 lessons he has learned in several areas of software development including requirements, design, project management, culture, teamwork, quality, and process improvement. Each of these lessons bring insights that can help you to and your organization to become significantly better at creating high quality, valuable solutions to your customers.

The Need to Iterate

Almost everything we do takes more than a single shot and design is a good example. The first lesson in the design category of Karl’s book is “design demands iteration”. There’s always more than one design solution for a software problem and seldom a single best solution.

The first design approach you come up with is unlikely to be the best option. A good rule of thumb is that you’re not done with design until you’ve created at least three designs, discard them, and take the best ideas from those three and build something better.

The same holds true for requirements. It will take a few iterations to get it right. These are cyclical things that you have to plan in your project management approach. You’re going to have to build in some reviews, get some feedback, prototype, and do some modeling to make sure we’re on the right track.

Icebergs are always larger than they first appear; that means that there’s going to be growth in the project. There’s going to be new information and new ideas that come along. You have to build in that growth and include contingency buffers into your plans. The bigger the project, the more unknowns and ambiguity and the more likely it is to change.

Understanding Stakeholders and Customers

Usage-centric development (as opposed to user-centric) is more likely to satisfy customer needs than product or feature-centered development. We shouldn’t care about features as much as you care about knowing what people need to do with the product. That’s the difference between the usage-centric approach and the product-centric approach.

That begins by understanding your stakeholders. Stakeholders are individuals, groups, or even systems who can shape or influence the direction of a project or who are affected by the project. To be successful, you need to identify your various user classes and identify who’s going to be the literal voice of the customer. Keep in mind that the customer isn’t always right, but they always have a point. Many times, the customer may ask for a solution, which may or may not be the right thing. To provide valuable solutions, we need to understand the underlying problem. If the solution they propose is the answer, what is the question?

Listen to the full episode for more lessons and advice on stakeholders, quality, applying what you’ve learned, and more.

YOUR HOMEWORK
Pick two areas you want to get better at and vow to spend some of your time on the project learning about those areas. Look for opportunities to apply that new learning on your project and perform in those areas better than you would have before your commitment to learn and develop your skill in that focus area.

Links Mentioned in this Episode

Karl’s Personal Website – KarlWiegers.com
ProcessImpact.com – Karl’s business and book information
Information on Karl’s book, Software Development Pearls

Karl Wiegers

Karl Wiegers is an independent consultant, author, speaker, and thought leader in the project community. His books on software requirements are considered required reading for Business Analysts and Project Managers. As a consultant and trainer, Karl has worked with more than 100 companies and government organizations of all types, helping them improve the effectiveness and efficiency of their software development activities.

Thank you for listening to the program

To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes.

Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.

Popular Episodes

Karl Wiegers shares his lessons on requirements, project management, design, quality and more. Karl’s advice can make you significantly better at what you do.

Show Notes

The Need to Iterate

Understanding Stakeholders and Customers

Listen to the full episode for more lessons and advice on stakeholders, quality, applying what you’ve learned, and more.

Links Mentioned in this Episode

Karl’s Personal Website – KarlWiegers.com
ProcessImpact.com – Karl’s business and book information
Information on Karl’s book, Software Development Pearls

Karl Wiegers

Thank you for listening to the program

To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes.

Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.

Popular Episodes

Previous Episode

MBA227: The Minimum Viable Business

Ian Reynolds discusses how to discover the right solutions for your customers and then deliver them quickly. Show Notes

Many organizations, especially as people are trying to work in more Lean and Agile ways, work towards producing a minimum viable product (MVP) and move on after achieving it. These organizations aren’t thinking about the value that could be delivered after the MVP.

They believe that if they put a minimum viable products in our customer’s hands, they know whether or not it’s a great product. Instead, people need to be working towards a minimum viable business as opposed to the minimum viable product. You could put a great product out there, but if you haven’t designed it to solve for the customer’s ultimate needs by testing it and getting early feedback

and created a degree of stickiness in a business model that will help you retain and add clients, you have a problem.

You don’t necessarily have a business and you haven’t necessarily solved the problem. Over optimization towards what you believe to be a viable product is not necessarily that MvP. It’s a business model that’s going to have sustainability.

What’s Valuable to Customers

When you’re developing a product, the easiest person to fool is yourself. You may believe that you have a great product, but you need to test it to validate that belief. That could be as simple as using a survey to check the validity of your idea. Building a product (even a scaled-down version of a working product) is a very expensive way to test an idea.

If you build the product first and then try to go out in the market and then make the adjustments, you’re going to have to build it again.

Faster Delivery

There are two major inhibitors to speed to market. One is trying to do everything yourself. The desire to understand exactly how the product is built and have too much control over the process of building that product is not efficient.

When you’re building a product, it’s not reasonable to be so in the weeds that you’re concerned about using a specific technology or growing to an understanding of how everything works. When starting your business or starting your MVP, don’t try to have one person do everything. Have people that are specialized in their given fields and fractionally use their time.

The other big impact to speed to market is if you don’t have a needed skill set in house. Training that skill and building competency can take a long time. You don’t necessarily have to hire for it as that could be much more expensive than using an outside party.

Listen to the full episode to understand how to test and discover the right solution and how approaches such as DevOps can help accelerate both discovery and delivery.

YOUR HOMEWORK
First Tip: Look at what the biggest players in the market are doing in terms of their engineering culture and then figure out what is it that they’re doing efficiently that you can copy. Don’t try to invent things yourself or come up with a new process; figure out what they’re doing and just copy it.
Second Tip: Analyze the opportunity cost of doing something in-house versus using a third party by looking at what an outside party can do for you and what specialization they have. If they could solve the problem for you quickly, maybe they can do it much more cheaply.

IAN Reynolds

Ian is the Chief Solutions Architect at Zibtek and Head of Venture Partners at Golden Section Studios. In his role as Solutions Architect, Ian matches business needs to technical solutions that solves the customer’s problem.

Thank you for listening to the program

To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.

Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.