Are you frustrated that other software developers often belittle each other or have a hard time coming to agreement on seemingly trivial issues? Today I’d like to talk with you about why software developers disagree – and what to do about it! The Fear of Being Misunderstood The first reason I often disagree myself, or see others do so – is due to a fear of being misunderstood. We strive to have others respect us and understand where we’re coming from, and sometimes this results in us disagreeing simply to clarify our stance. An Inflated Sense Of Experience Another reason we can disagree is an inflated sense of experience. When we’ve worked on a particularly wide variety of technologies and at many companies, we can think we “know everything”. I personally struggle with this and have to constantly strive to keep myself in check, being realistic about what I do and don’t know. A Byproduct Of Detail Needed To Be Successful We can also disagree simply as a byproduct of the detail needed to be successful. The interview process, and the fragile nature of software development tasks can cause us to become nit picky or too particular with each other. Though we should always strive to have a better understanding of what we mean, I try to leave it alone when I feel someone has “got it” even if their explanation may be different than mine. Projecting Prior Frustrations Onto Others Sometimes we have a bad experience on a project or with a person, and when we feel our self in proximity of a similar situation – we fall prey to projecting prior frustrations to others. This survival instinct can be helpful, but it can also damage our ability to see people for who they truly are and not cast an unfair perspective of them through the lens with which we’ve been hurt before. Focus On Mechanics At Expense Of “The Big Picture” I also experience disagreement if I or others focus on mechanics at the expense of the “big picture”. When we split hairs on the “how” without agreement on the “why”, it’s very easy to get distracted and spend unnecessary time working out the details of detailed tasks without having consensus around purpose. How Can We Handle Disagreements Better? What can we do about these easy ways with which we disagree? Get To Know Others Authentically The first one would be to simply get to know each other more authentically. When we have real relationships with people and not just “fake” work relationships, people will be less likely to feel misunderstood. Assume Good Intent And Reason For Disagreeing We also come to agreement easier if we approach others and assume their good intent and reason for disagreeing with us. Though it’s tempting to rely on our prior experience to control and color our perspective of another’s stance, learning to be more patient and understand their unique situation can quickly get us back to agreement. Try Not To Take Disagreement Personally Putting explicit effort into trying not to take disagreement personally is hard, but opens up the ability for others to feel safe with us and to not feel like they must “walk on eggshells” any time they communicate. This fosters the relationship needed for creativity and consensus to flow naturally. Be Selective With What To Disagree About You’ve heard the expression “pick your battles” and this certainly helps with disagreements. By being more selective about what we must get agreement on, we trust the major outcomes of a project and don’t have to be so anxious about every little detail going our way. Get Consensus On “Why” vs “How” If we can get consensus on “why” vs “how”, disagreements are less common since few will argue a high level business or project goal. This gives everyone the fresh perspective needed to look at their own stance more objectively in light of the overall goals being targeted. Appreciate When Others Learn What You Know Lastly, appreciating when others learn what you already know will diffuse many disagreements. Many of us learn best by sharing, so our ability to be patient and hear someone explain what we know helps them learn, and be committed to the work we know they will need to do to take on the tasks at hand. 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

Are you looking for a way to get people with different disciplines to work together better when developing software? Today I'd like to talk about the journey to cross functional development teams and some of the considerations on your way to integration. What Is Cross-Functional Teamwork? Cross-functional teamwork is simply taking people who used to be in separate teams or departments and putting them on the same team. To get there people go through a series of phases or stages. Phase 1: Ad-Hoc The first phase is what I call “ad-hoc”. Someone at the company has done some work that would typically be thought of as associated with a discipline (Operations, QA, Support, UX as examples), but they don’t think about how all the things associated with that discipline should be handled. Phase 2: As-A-Service The second phase is “as a service”, or what most people in medium to large companies often experience. This is where there is a dedicated department that does Support, Operations, UX, or QA; as examples. When a product team needs help with one of the skills of these separate teams, they use their expertise as a service. But these teams are still independently managed and measured. Phase 3: Embedded The third phase is “embedded”, and what most people think of when they hear terms like DevOps, Embedded QA, or Embedded UX as examples. Folks who were on a separate team are now integrated with the product team itself. They are dedicated to using their skills to achieve a single outcome for the business such as a product or deliverable. Embedding Sometimes Uses An Office / Center Of Excellence During the embedding phase, it’s common to see companies create a center of excellence, or office, who’s purpose it is to help make sure good practices are followed by those embedded in the teams. A “Project Management Office” is a common example of these. An important consideration is, does the person leading this new office have the skill with coaching, documentation, patience, and establishing measurable outcomes necessary? Leading Center Of Excellence Requires Additional Skills Also during the embedding phase, it’s important that all of the people working together on a cross functional team now share in the risks and rewards. If we’re going to expect people to work together towards a shared outcome, and not look out only for themselves and do work in silos, we need to spread the results of everyone’s actions across the team members. Phase 4: Infused / Integrated The final phase of cross-functional development teams is when the skills that used to be primarily sought by a dedicated member of the team around a discipline (again, Operations, QA, UX, Support as examples) are disseminated across team members. This is hugely beneficial since multiple team members can now provide help with more than one discipline, and it avoids bottlenecks due to individuals who are thought of as “the person” for a particular skill being unavailable. 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

Today I’ll share what I’ve learned over 10 years of first being a developer working directly for software companies, and then 10 years working as a software consultant. I hope this helps anyone evaluating the trade offs of a software developer vs consultant, and figuring out what’s better for your career. Influence The first consideration is influence. As an employee, your influence can sometimes be restricted by the position you hold. As a consultant, it tends to lend itself to you having whatever influence is necessary to solve the problem you were brought in for – at least at first. Business Perception Of Value Another thing to consider is how the business will perceive your value. As an employee, you can be looked at as a cost center, or a profit center depending on the business model of the company. As a consultant, your value to the business is typically a solution provider – you’re there to solve a problem, and ultimately to leave. Perception By Peers How will you be perceived by peers? As an employee, you should be treated as one of the family since you share the same benefits and struggles as the rest of the company’s people. As a consultant, peers will often look at you very skeptically at first – you must learn to be comfortable with this to fit into their culture. Key Traits and Skills What are some of the key traits and skills needed? As an employee the focus is often on your technical skills. Though soft skills and process understanding will help, most hiring managers focus heavily on technology above all else. Additionally, you’ll be considered for “culture fit” – which can be a real thing, or a wild card used to reject candidates in my experience. As a consultant, there are very different skills that will tend to help you be successful in the position. First, likability – people must like you to enable you to get the influence necessary to become a trusted advisor. You also need to be above average at communicating clearly, and tailoring information to different audiences. Lastly, an appreciation for and desire to understand the business in which the software development is done will help tremendously. Rewards Next think about rewards. As an employee, you’re usually going to make some adjusted version of the market rate for your skills, and optionally some options or equity. As a consultant, you’re either billing your clients at an hourly rate, or can charge a percentage of the opportunity you’re enabling. Growth As an employee growth will happen when the company needs it. So you need to grow on the side if things aren’t moving as fast as you’d like. A consultant has the potential to grow with each contract, but it can be stressful and fast paced. An employee can get recognition whenever they work on a successful product effort. A consultant gets less recognition that turns into a reward short term, since they depend on their firm rewarding them and they don’t always directly see the work. Ability To Change Work Processes Employees can change whatever work processes they want within the realm of their responsibility with reasonable ease. Consultants must prove themselves before they are allowed to change processes, but once proven it can be easier than an employee. 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

Are you asking team members or maybe your entire company to change the way some aspect of software development is done? Today I'd like to share why software development change initiatives fail all too often. The first thing people are most familiar with around a change is the communication. This can often happen in a meeting where leadership or a project manager states “what” the change is. Though this is a necessary part of the process, it’s bare minimum. The second thing people are familiar with is “how” the change occurs. What training, documentation, and other materials are needed to equip people with the tools or assets they need to make the process change? Next, you’re probably familiar with how interested most teams and companies are in governance. That is, how do we know how many people are making the change, and how successfully? Though it’s important when doing software development that change initiatives are accompanies by measurable goals or metrics, the biggest piece of the puzzle still needs to be tackled. To have the highest chance of a successful change, we must answer the question “what’s in it for me”? But from the perspective of each INDIVIDUAL we’re asking to make a process change or a tool or technology change. Before we can do that, we need to know people on a personal level. And to do that requires spending TIME with people and getting to know their unique circumstances, history, and life struggles and goals. When asking someone to make a change that in no way benefits them, often the best chance of success is to motivate them with some sort of reward. It’s a companies way of saying “we’re sorry you need to do extra work or work differently, so here’s something we want to share to show how we take into consideration to burden this adds to your workload”. In all other cases, understanding each person’s motivation, and what outcomes they might want to be supportive of a software development change initiative, is most often the key, CRITICAL factor in the success or failure of widespread adoption. People change most successfully when the reason for the change is not just communicated, not just understood, but aligned with their own goals! 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

Are you getting ready to redesign a new version of a digital product with software? Avoid the top 5 software redesign mistakes by software companies I see made all too often. #5 – Focusing On Current Customers It’s tempting to focus on what current customers of the product have wanted at the expense of NEW customers. If the goal of a redesign is growth, it makes sense to do market research and look at the product with an open mind. Do new customers have completely different needs than current customers do? #4 – Trying To Include All Features Of Prior Version Many companies spend too much budget and time trying to design a product that does everything the prior product did. A redesign is the perfect point in a product’s life cycle to look at it with a fresh set of eyes before making a reinvestment. Throwing off the shackles of the existing product’s feature set might be exactly what your team needs to envision a dramatically more compelling, simpler, and BETTER product for the market. #3 – Budgeting Too Little For Marketing As a digital software product becomes more established, many teams focus too much on the engineering side of the product. Is it possible that you might be better off budgeting a larger percentage of the investment in the redesign towards marketing? If you’re not doing Facebook advertising, Google Adwords, or Instagram posting to reach today’s audience you could be missing out on an extremely effective way to reach customers that you used to via a different source. #2 – Failing To Consider A Rebrand Though the benefit of an existing brand name and marketing message can be an advantage, depending on the age of your product and the needs of new customers, it may make sense to rebrand. This allows a team psychologically to detach from the prior product more wholly and look at the new version through a completely different lens. Might this be a strategy your company could use to bring life back to a product that’s no longer as compelling and exciting for the market as it once was? #1 – Failure To Establish Measurable Outcomes The biggest and most common of the software redesign mistakes I see made is unfortunately the failure to truly establish easily measurable outcomes for success. As a project gets underway, unless design decisions were made to accomplish easily measurable goals, it’s easy for the team and management to lose sight of the purpose and simply look at the redesign as a “project” to be completed. It’s a huge opportunity to reach some exciting goals for everyone, and it provides cause for celebration to all those who were involved as they discover what the market wants! You can also watch this episode on YouTube.  Related resources: How To A/B Software Development To Find What Customers Value   Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

Are you making decisions about what technologies and patterns are used in your software product? Today I’d like to talk about some considerations you may wish to entertain when you select technology for use on a product being delivered to customers with software. Evolving software architecture to adapt to product growth can help your team deliver faster and accommodate refactoring needs easier as the project progresses. We should determine how mature our product is in the market first. Geoffrey Moore’s famous book “Crossing the Chasm” describes how a product goes through segments of customers along the maturity of a product’s timeline in the market. In this video I talk about how to change the software architecture depending on where you are along that timeline as you chase market fit. Are you selecting technologies that are appropriate for how mature the product is? If you have team members who’s only work experience was on more mature products, they may need help with making technology decisions that are simpler and support the speed of change necessary for a less-established, exploratory product. If we select a comprehensive, full stack set of technologies for our minimum viable product (MVP), we can be susceptible to over-architecting. We can never make perfect decisions, but I recommend considering the maturity of your product in the market, and if choosing simpler architectural patterns and technologies might be better. Once a product has growth needs, the business should be profitable enough, with enough additional revenue, that updating the architecture to meet the new growth needs can be afforded. This takes pressure off the team early on as they are able to product changes for early customers to validate business ideas quicker. We should also consider the skill level of our team members, and whether they’ve mastered the foundational technologies upon which pattern and stack decisions are based. If a team is especially proficient choosing a more comprehensive stack may be appropriate. If not, it may make more sense to select the minimum viable set of components needed to simply produce changes to get that market feedback as you’re still crossing the chasm. It’s worth considering whether to innovate with our own frameworks or libraries when we select technologies for a project and how their patterns might benefit the software architecture. If we go this route, we should consider whether we really have the time and support from the business to train people on it, document it appropriately, and provide support for it. We might consider spending more time fully researching all available options for existing components and frameworks that meet the needs of the product first before innovating ourselves. Whether using nodejs, C#, Java, python, ruby – or any other core language, there are a huge number of available packages on the community to implement most concerns of a modern architecture. The exceptions to this are the “secret sauce” where your product provides its core value – but this is what you should probably spend the bulk of your time building – NOT architectural building blocks. You might consider resisting the temptation to select patterns and technologies that allow for future flexibility until you actually need them if ANY additional complexity is necessary to do so. Though this leaves you up to the chance to need to refactor at a later date, it also eliminates any waste spent supporting possible needs down the road that aren’t capitalized on. Emotionally detaching from having to think the architecture is “right” and will “never change” helps us have the mindset necessary to be more lean in how we develop software. I’d encourage you to educate stakeholders whenever possible on the realities of the architecture’s suitability for the product at any point along it’s market adoption curve. When businesses understand the implications, they are often very supportive, and will feel less frustrated when changes to the architecture are recommended by the team at a future time. Simple Strategies For Identifying When To Evolve So if we know evolving software architecture allows us to gain efficiency by being deliberate about it, how do we know when to actually make changes? The first thing I’d recommend is to bake monitoring of components and infrastructure into the development process. Whenever a change or feature is being designed, think about how to monitor its performance and anything else about it that might indicate a need to change the architecture. The second thing I’d recommend is to monitor the throughput of the team, and watch for any fluctuations. Though a team delivering slower than they had before can be for a variety of reasons (most often technical debt), it can also signal a need to make revisions to the architecture. 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

Let me share some stories today that will present at least 5 ways pride kills a software project. At the end of the video I'll share three strategies I've used to fight pride. The first way pride can kill a software project is when we become too proud of an opportunity to lead. At the beginning of my career, I had an amazing opportunity to lead a team to build a software product using a new technology. I was inexperienced, and my pride caused me to be resistant to work with more senior people. It didn't take long, but half my team was resistant to my changes and they wanted to see me fail. Ultimately I was given the opportunity to work on a different project but it was really because I was so difficult to work with. The second way pride can kill a software project is when we become too proud of a select group of people. On a project where I was able to work at a new company with many people I'd worked with before, we created a clique and didn't respect and work with the existing teams at the company very well. In short time our project's success was at risk because we didn't get buy-in from the others on the team. We were too proud of those we trusted, and didn't work hard enough to get the others we should collaborate with to understand that we respected their value. The third way pride can kill a software project is when we become too proud of past successes and efforts. I was helping a client at the consultancy I worked for, and there was a person there who was very senior and experienced, but he wouldn't change. Everyone in the company respected him - and they wanted to see him rise to the occasion, but he just wouldn't budge. When we become too proud of the work we've done to gain skills, we can start to get resistant to doing the work it takes to stay relevant and GROW. Eventually this individual did come along to his senses, but it was painful and wasteful for a long time and caused work to be difficult for many others until that happened. The fourth way pride can kill a software project is when we become too attached to our ideas and their potential value. I was helping another client where they had asked our consultancy to build a product. We warned this client that what they wanted to build was too risky, and that the budget they had allocated put too much risk in all of their ideas being good. Though we tried hard to convince the client of the importance of our approach, and how software development is different from manufacturing, ultimately we did the work the way they asked. The end result was that the business folded, because they didn't profit enough off their ideas to pay back the investment in the development. The fifth and final way I've seen pride kill a software project is when people have too much pride in the way a process was done before. At a company I worked with, the process that was used for selling needed a change. Many of us at the company had seen a shift in the industry, but key people in the sales department refused to entertain our ideas. Though it was understandable that as not being in sales outside "technologists" trying to influence their process may have felt off-putting, it was out of our genuine concern for them. We wanted them to see that customers now wanted lean software development, and our company culture had to change to continue to deliver what the market wanted. There are a few ways we can also fight pride. The first thing we can do to help fight pride getting in the way of our career growth and successful software projects is to simply cultivate gratitude. By being more grateful of what we have, we have less attachment in being right, rewarded, or having certain outcomes - and this gives us the courage we need to try new things. The second thing we can do to help fight pride is to see the potential in other people and the value of their ideas. If we always look to others to do things how we do, and we only evaluate others based on how often they are supporting our ideas, we miss out on the ability to benefit from what they might bring to the table. It helps us be more humble when we keep an open mind to the value of others at all times. The last thing we can do to help fight pride is to encourage risk taking at our company and with our people. With risk comes reward, and working at companies that only take small, calculated risks only produces minimal improvements. It also creates a culture where people are unable to be as creative, and produce the innovation and efficiency breakthroughs necessary to really move to the next level. A leader of a team who knows the importance of this will harvest the best ideas from their people. 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

Companies need to start to A/B software development to find what customers value. Relying on planning up front based on customer feedback and research just isn't competitive anymore! Software development is not like manufacturing. We don't have to make sure it's perfect before we start to build. In fact, that's not a very agile approach - and we'll too often build things that waste money! When we do lean software development, we look at a lean canvas, or a business model canvas, and figure out which aspect of the business we want to impact through a change. We need to design an experiment to test that change, and part of lean product management is setting up these experiments so we can test whether the experiments we run are pointing us towards the impact to the business we want to make. We need to choose a measurable outcome to impact first, and figure out how to measure it. What will constitute success? Next we need to make sure we know how we will serve both the old (pre-change) version of the product, AND the post-change version to an audience of the same size to see which one "wins". This is known as cohort analysis, and will help us avoid vanity metrics (measurements that don't really represent an improvement). When we serve both versions of a product (with and without a change) to a cohort, we need to determine how long the experiment will run. When the experiment ends, we have a learning milestone where we look at what was gathered, and decide whether to pivot or persevere. Traditional project accounting looks at % complete to determine how efficiently a team is using budget to complete an effort. In lean software development, we need a new approach. This new approach is called innovation accounting, and it instead measures the business on how effectively it is learning about where its assumptions about what's valuable are right and wrong. To use innovation accounting will require getting leaders on board. Unless we change budgeting to account for this, and convince anyone who was involved in the prior software project budgeting approach to use innovation accounting - we'll continue to deal with "change requests" or asking for more budget after we learn, and it looking like a failure on our part. Innovation accounting is a concept introduced by Eric Ries, author of "The Lean Startup". 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: "The Lean Startup" on Amazon Principles of Lean Product Management by Jez Humble Visit me at thrivingtechnologist.com

To release software smoothly, avoiding time wasted troubleshooting infrastructure issues - you might consider automating your infrastructure as code. To achieve continuous delivery requires thinking about how technologies like chef, puppet, ansible, docker and the like might serve this need for your team and organization. The first step is to determine an approach for using images. If on premise, you might create one that can be used when initializing a virtual machine. In the cloud, this image might be used somewhere like docker hub, or in windows azure or amazon web services (an ec2 image). Jez Humble refers to computing resources and environments that have not had their infrastructure controlled as "works of art". I love this term, it accurately describes the confusion around how a node of infrastructure got into a state. To avoid this, we should use infrastructure provisioning tools against the computing nodes we "stand up" from an image. These tools will run a series of steps against a node to put it in a given state. An important thing to consider when embarking on the journey towards infrastructure automation is whether the company has the discipline to not make manual changes. If this is a new concept, a tool like puppet, ansible, chef, or the like can help by checking to see whether a node is in a given state and only applying the necessary changes. These checks come with additional processing power (and hence time) however, so in a company that's more mature in how it uses infrastructure as code and automated deployment, it may make more sense to use something that doesn't perform these checks - instead assuming nodes are already in a state. A common practice is A/B releasing, which can be used to switch between an active and passive set of nodes in production, or any other environment. This makes deployment faster, and also allows rolling back a problematic deployment easier. A/B releasing is different than A/B testing - the former helps with deployment, the latter with validating that changes had the business impact we theorized. I'll talk about A/B testing more in a future video. I recommend in this video to use powershell, bash, or a similar technology as the "trigger" of any automated deployment or infrastructure provisioning process. This avoids vendor lock-in and provides the most future-proof flexibility in combining the many tools modern vendors can use to make changes as the product evolves. Though there are fantastic tools such as terraform that have a wide reach, able to make changes in cloud AND on-premise environments in both amazon web services (AWS) and windows azure - I've yet to find one tool that can do everything. Regardless of the technologies you choose to use, select a language or syntax that will be most comfortable for your team's existing skillset. For example, if those who will automate infrastructure are object-orientated programmers - a tool like C#, ruby, or python may be sufficient. On a team with a more "traditional operations" set of skills - bash or powershell is probably going to be more approachable. 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

As described in the video on isolating customers from your changes, there are typically a minimum of three environments into which software can be deployed. There are configuration settings used by your application, service, or product with software that need to change depending on the environment. These are called environment-specific configuration settings, and this video describes an approach for managing their values. You may have configuration settings in several files like the web.config (.NET), database.yml (rails), or .json files (nodejs) as examples. The settings in these files that are specific to an environment need to be set appropriately whenever your product and its components are deployed. Though there are utilities and tools often available that will set these appropriately for each type of file, this makes deployment more complicated since there is still duplication. The same database connection may exist in multiple files that all need to access the same database, but are for a different technology for example. Rather than using these technology-specific approaches, a more efficient method that will help your team be more agile is to centralize all environment specific configuration in one master file or list. Then you need to use some script or technology that can read those settings and overwrite the values in the source code or configuration files once deployed to an environment to the correct setting. The more configuration settings your application has, the more important it is that you create automated tests to verify that they work properly. One of the most costly ways to deliver software is to have an extremely flexible set of configurations and not have an automated way to test all of the combinations. The time spent manually testing this is much less than the investment necessary to build out the automation - and will pay you back time and again in time to market with future changes. 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

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