Healthy Developer

To release software to your customers, you'll probably need several development environments. To allow a team to make changes to software without disrupting paying customers, we need a way to isolate them.

Software developers and engineers working on an agile software development team need an environment where they can make changes under development. The development environment might be a copy of a website, database, or API on their computer. This is sufficient for a product with a minimal footprint. In a larger and more complex software product, cloud or server resources in a datacenter may be needed to support development environments.

In addition to a development environment, most teams need somewhere separate from development and production to do additional testing. This can be known as the "test", "user acceptance" (UAT), or "staging" environment and allows the team to more closely inspect a version of the software slated to release.

The final environment that is always required is production itself - or the place where your paying customers use the software.

In addition to a development, test, and production environment - there are two other environments that can be fairly common.

One of these is a demo environment, who's purpose is to provide a playground or sandbox where a limited audience can "kick the tires" of the software without disrupting the development team.

The other common environment is a capacity test environment, who's purpose is to determine whether a potential release of the software will stand up to a real load. Capacity test environments should have the same hardware or cloud processing power as production, to provide testing results that are representative of real traffic on the same computing power.

Regardless of which environments your company or team uses to release software, you'll need configuration management to automate releases through these environments. I'll talk about configuration management tomorrow, and how you can use it to make sure releases of the software in a given environment don't accidentally point to the wrong environment's resources.

Join my Patreon: https://thrivingtechnologist.com/patreon

Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching

TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles

The Thriving Technologist career guide: https://thrivingtechnologist.com/guide

You can also watch this episode on YouTube.

Visit me at thrivingtechnologist.com

You probably know you need to use Continuous Delivery to release software to your customers.

There's much confusion in the market around Continuous Delivery. How does it relate to Agile Development? How does it relate to DevOps?

In this video, I'll demystify Continuous Delivery by helping you understand the big picture. It's a capability - not a technology.

The key innovation is reducing your cycle time. This is the length of time from when the business or customer has an idea, until it's available to users. To reduce cycle time, we often need to use automation technologies so less manual work is done between releases of our products.

Operations personnel, in a traditional software company, are the keepers of production and have the keys to that environment. These folks are typically motivated by keeping the system stable, since they are measured on uptime and performance as examples.

Developers are often measured on their ability to introduce change, and so their motivations are often at odds with operations.

DevOps is about bringing these two disciplines together to overcome this psychological barrier so companies can truly be more agile. In a lean company, that's delivering software frequently to its customer for feedback - automation may not be necessary however.

You can achieve continuous delivery for a small product or project through manual deployment - assuming the appropriate quality checks and process are in place. The most important thing about continuous delivery is reducing cycle time, so whatever you need to do to achieve that is getting you closer to that capability.

Try not to get caught up too much in whether your team is using the right technologies to achieve continuous delivery. It's about cycle time - period.

If you are in software product management, understand that this capability is what will help your team deliver software in a lean fashion. This capability is a necessary practice if you wish to get feedback from your customers in a fast enough time to take action on it.

One of the most common aspects of releasing a software product that increases cycle time is automated testing. You don't need to do test driven development (write the tests before the code), but you absolutely must have whatever tests /are/ written be AUTOMATED.

Join my Patreon: https://thrivingtechnologist.com/patreon

Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching

TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles

The Thriving Technologist career guide: https://thrivingtechnologist.com/guide

You can also watch this episode on YouTube.

Visit me at thrivingtechnologist.com

Why are some companies able to engage in creative software development, while others treat it like manufacturing?

Since the work we do to develop software is "knowledge work", it benefits from the ideas and experiences individuals bring to each problem.

Many companies look at the envisioning phase of an idea that's developed with software as the primary process that benefits from creativity.

Selecting the solution used to develop a feature or idea, equally benefits from creativity. So how can we maximize this?

Inspiration is the spark that someone gets when exposed to something created by someone else. A piece of music, a fine painting, a software technology etc.

Creativity is the work we do to form and shape that inspiration into something tangible in the real world.

Being creative takes energy, so many of the things we can do to maximize energy, will also maximize creativity.

People are less creative when constraints are placed on what they can change. Freedom allows for more creativity.

We can provide technologists with more freedom by encouraging them to make healthy lifestyle choices.

We can also provide technologists with more freedom by not allocating them to high levels of utilization.

More free time = more opportunities to explore different solutions. These different solutions can have explosive impacts on efficiency.

When teams are free to think outside the box and bring their full intuition to bear, problems once slated to take months can be solved in days or even hours.

When making decisions about how we plan work, or what the culture at our companies is like – are we optimizing for creative work?

Are we focusing on the illusion of predictability and control, using mathematical equations to feed our ego so we can feel like we're getting the most out of people?

Or are we creating an environment for software development that breeds creative ideas, treating people as sources of creativity and not just productivity units?

Management and companies historically do a poor job motivating individuals to make better lifestyle decisions to have more energy so they can cultivate higher levels of creativity.

You as an individual on a team must decide how important being innovative in your problem solving in your career is, and possibly make some lifestyle choices if you wish to reach your maximum potential.

Join my Patreon: https://thrivingtechnologist.com/patreon

Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching

TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles

The Thriving Technologist career guide: https://thrivingtechnologist.com/guide

You can also watch this episode on YouTube.

Related resources:

• Principles of Product Development Flow (Amazon)

Visit me at thrivingtechnologist.com

Embarking on the journey to let customers lead YOU to the most profitable solutions?

You'll probably need to decide between the two most popular ways agile teams work, and I'm here to help you make that decision.

Scrum is a great process when your team needs a scheduled checkpoint for how well they are doing. It is also great when the customer can only respond to change every couple of weeks.

Kanban is superior when trying to use your resources to their fullest capacity. It's also superior when your team needs to adapt to change without time wasted waiting on each other.

My vote: Kanban! BOTH processes can be used in a lean fashion, but I just find Kanban supports adapting to uncertainty more fluidly.

​Kanban also lets team members work at their own pace, and do the work they enjoy most – not forcing people to attempt to work at the same speed and rely heavily on estimates being so accurate.

Caveat: If you're going to use Kanban, schedule a regular checkpoint to continuously improve processes by having a retrospective.

REGARDLESS of which process you use, the same rigor you'd use on a waterfall project must be followed before any kind of estimate should be communicated.

Requirements (or user stories), ACCEPTANCE CRITERIA, infrastructure changes, user interface assets, technical documentation, support & monitoring needs – figure it all out first!

If this seems like a lot to figure out for one story – it is! That's why stories must be small…

A team that is learning to truly "continuously deliver" value to their customer in small batches must reduce the business' expectation of the RATE of product change.

There will be less released at once, but what is released will be HIGH QUALITY and ready to go to production immediately!

So how does a team prevent changes that aren't ready for production from going out with those that are?

Feature Branching! *BZZZT* JUST KIDDING! Use /Feature Hiding/…

Use configuration settings to hide work underway so it doesn't block releases to production.

When a feature is ready to go, just switch the configuration change on the next release!

This forces everyone to continuously integrate changes into the trunk (or "master" branch) which is a key principle of *cough* continuous integration (yes, the name means what it says).

Join my Patreon: https://thrivingtechnologist.com/patreon

Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching

TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles

The Thriving Technologist career guide: https://thrivingtechnologist.com/guide

You can also watch this episode on YouTube.

Related resources:

• Continuous Delivery (Amazon)
• Introduction to Scrum - 7 Minutes
• Kanban 101 - What is Kanban?

Visit me at thrivingtechnologist.com

It's human nature that businesses have a desire for software estimation.

For projects with a fixed scope, typical estimating methods can be off by as much as 70%. And that's a product that doesn't adapt to user needs.

If you desire the economic growth that comes from building winning products for customers, the numbers will be even worse.

The short of it? Don't bother! Pick a budget for what you can afford each month, and let a qualified development team or consultancy tell you if they can build a minimum viable product (MVP) in 1/6th to 1/12th of that budget.

This will produce your core theory of value and two delighting features early, with monthly budget left over to adapt to changes.

If you find that the product needs to change spend some budget on those changes.

If you find that the product needs to improve in quality, spend some budget on beefing up testing.

Software projects don't fail because the product couldn't get built in time – they fail because they DON'T DELIVER VALUE high enough to justify the investment.

To reach this high level of value means spending less time envisioning, and more time ADAPTING.

The only way to do this is with a laser focus on the core theory of value, and a budget that will last through several feedback cycles.

Any time a product owner/manager or non-technical person of any sort asks for an estimate, they create anxiety in those doing the work.

Experienced technologists know the number of variables in software development is ridiculous, and systems that have been created so far to account for all possible outcomes fall far short of being helpful.

Though we may need to estimate whether we can deliver the core theory of value within a time frame short enough to get feedback, ongoing estimation should be unnecessary if budgeting of software is done on a subscription-based, value-focused basis.

Software businesses must ensure that insights about how the product is being used are recorded with every release of the product.

Minimal change must be introduced each release, to allow for A/B testing to determine whether a change had the desired impact on business outcomes.

How business outcomes are measured is specific to each business, but these must be determined and agreed upon BEFORE development of any feature that will impact them starts.

The effort of a successful software project focuses on measuring whether each release is getting the business CLOSER TO AN OUTCOME, not closer to completing a FIXED SCOPE OF WORK!

This paradox can be hard to wrap your head around, but it must be fully appreciated to operate in a truly lean fashion.

Determine what you can spend per month, get started, and adapt…

TRUST THE MARKET, not your ego!

Join my Patreon: https://thrivingtechnologist.com/patreon

Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching

TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles

The Thriving Technologist career guide: https://thrivingtechnologist.com/guide

You can also watch this episode on YouTube.

Related resources:

• Principles of Product Development Flow (Amazon)

Visit me at thrivingtechnologist.com

Whether producing a software product for a new market in a startup, or introducing a major change in an enterprise - planning a minimum viable product is a good idea.

When building a minimum viable product (MVP), you should select a feature that shows users your core value proposition, as well as two features that "delight".

The core value proposition is a part of the Business Model Canvas, a visual tool created by Alex Osterwalder that you can use to determine which aspect of the business is being effected by a change.

The "delighting" features provide something sexy for users that attracts potential customers due to it's sleekness, innovation, or ease of use.

When planning what goes into an MVP, don't budget for only the MVP. Budget for enough to build software for 6-12 months that will adapt to feedback.

Spend a small portion of the total budget to release the MVP, and use the majority of the remaining budget to adapt so you can deliver exactly what customers want - and in the way they want to buy it. These other "ways" than the product's features itself are the other aspects of the business model canvas.

If you only budget enough for the MVP, you won't have money left over to adapt. Adaptation is the difference between a product that "meets needs" and one that "exceeds expectations". It is this latter category of products that cause companies to be leaders in their market and cause substantial growth.

When selecting technologies for the MVP, don't box yourself into feeling you need to use technologies already familiar to the development resources you might have. Hiring a specialist in a technology that is faster to build prototypes and minimal products in can save substantial money.

Should the market lead you to find that what you've built is successful, you can always change the technology used down the road to meet scaling challenges, if the original technology can't handle the volume.

This is a GOOD problem to have, and means you've found a large user base - but until this happens, don't spend the time and money planning for it! You need as much budget as possible to simply ADAPT at first, and so your money is better spent with excess funds for adaptation than building out an infrastructure or technology stack that assumes a size of user base you don't yet have.

You can also watch this episode on YouTube.

Join my Patreon: https://thrivingtechnologist.com/patreon

Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching

TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles

The Thriving Technologist career guide: https://thrivingtechnologist.com/guide

Visit me at thrivingtechnologist.com

Companies can miss out if they don't have the right mindset for agile project management.

If your team is pursuing agile practices but doesn't feel that the benefits to the company are delivering on the promised industry hype, this video will explain some of the reasons why that may be the case.

I discuss how traditional project management techniques are often applied to software development projects, and the "agility theater" it can cause for teams.

It's important for teams who are new to using agile development that executives, customers, and all other staff that work on the project understand the implications of the new approach.

The most common misunderstanding I come across is a lack of appreciation for the trade off of agility (a positive effect) for predictability. If a company wishes to adapt to the changing needs of their customer and the market quickly - they must become comfortable with uncertainty, and LET GO of the illusion of control.

Estimation specifically is an activity that can cause a great deal of confusion, wasted time, and unmet expectations when working on products that choose to have some form of Agile Project Management. I'll discuss this in more detail in a later video.

Regardless of how far along the agile journey your company is, beginning to have the tough conversations with stakeholders about WHY we choose agility, and how treating projects like a traditional work effort such as constructing a physical building doesn't apply, can be the breakthrough you might need in becoming a lean organization.

During this video, I also briefly mention a traditional software project management tool known as Gantt charts - which I believe are practically USELESS on agile teams. The number of times a project goes according to the chart is practically zero. I'm sorry to report that over the past 17 years of my career (since agile development was introduced) - teams that are held to Gantt charts can easily fall prey to "faking" deliverables as being done just to make it look like they hit their schedule!

You can also watch this episode on YouTube.

Join my Patreon: https://thrivingtechnologist.com/patreon

Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching

TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles

The Thriving Technologist career guide: https://thrivingtechnologist.com/guide

Visit me at thrivingtechnologist.com

In the first video in my series on Sustainable Software Development, I explain how Lean Software Development avoids a company becoming irrelevant in today's shifting technology market.

If you're looking for the reason why lean software development can be the difference between software projects being fun and innovative, or grueling and underwhelming – this video will provide you with some guidance.

I discuss how the software development industry has focused on agile software development methodologies like Scrum, DevOps, and Continuous Delivery but that these don't get the results companies are looking for if not used with a lean mindset.

I discuss the fact that working in the industry continues to be highly uncertain, and so we need strategies that deal with anxiety and reduce pressure to help us sustain our careers.

I mention how the industry's focus on technologies and process distracts us from value. A business must always be profitable, and without a focus on customer value and a culture of learning – you're dead in the water.

I don't want to see passionate technologists and successful companies fall into the trap of thinking they only need to add features to a technology product or service to sustain profitability and innovation.

​Lean software development will ensure that the way teams work, and the way changes are rolled out to customers, puts the market in the driver's seat to direct us where we're headed.

Developing software is more like steering a ship than building a skyscraper. We chart a direction to go, but we ASSUME that the winds will blow us off course. So we need to use tools and techniques that let us steer quickly.

As I share strategies for sustainable software development on this channel, we will choose tools and techniques that allow us to adapt and respond gracefully as things change.

You can also watch this episode on YouTube.

Join my Patreon: https://thrivingtechnologist.com/patreon

Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching

TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles

The Thriving Technologist career guide: https://thrivingtechnologist.com/guide

Visit me at thrivingtechnologist.com