How UNCERTAINTY Impacts Software Development Processes!




Does it ever seem strange how when talking to other software developers they insist that the processes they use are “the best” but they don’t seem to make any sense as to how they could work in your company? Today I’d like to share how uncertainty impacts software development.

Whether they realize it or not, many people in companies select processes based on their tolerance for uncertainty. The experience they’ve had developing software in the past, and existing beliefs they have about how the rest of the business and the customer will use the product influence decisions.

Technology changes faster today than it did 20 years ago, so being able to respond to change is more important. We need to be careful of fortune telling, and that we aren’t over-confident in our ability to see what’s coming. When we use agile processes for software development, one of the big benefits is that they help us adapt to changes in the market and optimize for handling disruption.

The big question is – how responsive is your company or team willing to be? The more uncertainty people at the company can tolerate, the more adaptable and responsive you’ll be in serving your customer. There are a wide number of decisions that can be made about how you develop software that stem from the tolerance for uncertainty, but in this video I’ll talk about some major attributes of the two extremes.

A company or team with a lower tolerance for uncertainty may use % complete budgeting to track progress on the project. A team with a higher tolerance for uncertainty may set a monthly budget to allow the customer to influence what’s delivered more.

A company or team with a lower tolerance for uncertainty may focus on cost and estimation. A team with a higher tolerance for uncertainty may track learning milestones to measure progress.

A company or team with a lower tolerance for uncertainty may create source control branches for developer changes. A team with a higher tolerance for uncertainty may use feature hiding instead, with everyone collaborating on one branch to follow continuous integration.

A company or team with a lower tolerance for uncertainty may make more investments in the UX up front. A team with a higher tolerance for uncertainty may use lean UX practices that provide a minimum viable experience, and adapt as they go.

A company or team with a lower tolerance for uncertainty may make more up-front architecture decisions. A team with a higher tolerance for uncertainty may simplify the architecture to increase the speed of refactoring, and let the architecture evolve with product growth.

Subscribe for more videos about Healthy Software Development:

Related Videos:

Watch my video on Lean Software Development here:

Watch Jez Humble’s video on Lean Product Management here:

Watch my video on how to A/B Software Development here:

Watch my video on Minimum Viable Products here:

Watch my video on Anxiety in Software Development here:

Watch my video on Agile Project Management here:

Watch my video on Winning Trust For Your Ideas here:

Watch my video on Scrum vs Kanban here:

Watch my video on Cross Functional Teams here:

Watch my video on Evolving Software Architecture here:

Previous 25+ Simple and beauty landscape design ideas for side of house
Next SUCCULENT CARE BASICS FOR NEW AND OVERGROWN PLANTS

2 Comments

  1. Jayme Edwards
    August 15, 2017
    Reply

    I hope this video ties together some of the others I've done on this channel to provide some clarity around how uncertainty impacts your software development process decisions. Let me know any thoughts, feedback, or questions you have below. Thanks!

  2. AKanx47
    August 16, 2017
    Reply

    Great video Jayme. Being in the public sector the software development teams would likely fall under low tolerance for uncertainty. I would say this is just a product of working in an environment where there isn't much focus on the customer or there experience but rather funding (cost cutting for the most part) and they don't let the customer drive the product, as you put it.
    My questions is acutally on your last point in the video, spilling architecture for refactor speed. What flexible, simple software architecture can we use which will allow for incremental change and limit long hours to implement foundational changes to source. Have you used anything in the past or are aware of upcoming agile software architecture?

Leave a reply

Your email address will not be published. Required fields are marked *