Jayme Edwards https://jaymeedwards.com Software Development Coach Tue, 17 Oct 2017 22:25:37 +0000 en-US hourly 1 https://wordpress.org/?v=4.8.2 Overcome Attachment: Discover Lean Software Development https://jaymeedwards.com/2017/10/17/overcome-attachment-discover-lean-software-development/ https://jaymeedwards.com/2017/10/17/overcome-attachment-discover-lean-software-development/#comments Tue, 17 Oct 2017 18:28:08 +0000 https://jaymeedwards.com/?p=5393 Today I'd like to offer some strategies to overcome attachment so you can get others to use agile and lean software development methods.

The post Overcome Attachment: Discover Lean Software Development appeared first on Jayme Edwards.

]]>

Are you trying to get other people to use agile or lean software development methods, but they can’t seem to break out of the mindset they’re stuck in? Today I’d like to offer some strategies to overcome attachment.

📺 Watch on YouTube

🎧 Listen to the podcast on iTunes or Soundcloud

OR Read a summary below:

Building What Customers Want Takes Failure And Learning

Traditional management styles want predictability. They want to know how long things will take, and how much they will cost. Unfortunately companies that want to be innovative can’t measure performance this way to deliver truly disruptive and valuable ideas to their customers.

Establishing the Mindset for Failure and Learning

Assume for a moment you’ve already convinced people of the benefits of lean software development methods like DevOps, Continuous Delivery, or any of the other concepts I talk about frequently on my YouTube channel and podcast. Though others may understand the mechanics of these approaches, it can be frustrating at first to get people to be comfortable with learning, because this often requires failure.

The Uncertainty of Innovation Can Cause Anxiety

If we’re going to let the customer decide what’s in our product, and release multiple times per day – we’re going to have an increased set of feedback. Also subject matter experts like Product Managers can find out their ideas aren’t as valuable as they’d hoped when trying new things.

Overcoming Attachment to Enable Learning

If you celebrate Christmas or your Birthday, you’ve probably experienced being attached to a gift or outcome you wanted as a child. We need to overcome these feelings of attachment in companies that are attempting to use lean and agile methods for developing software.

We Must Be Comfortable With Uncertainty to Take Risks

The more comfortable we can be with trying things and not being able to guarantee that the outcome is something that we want, the more we can take risks. This is exactly the mindset needed to be more innovative with software development.

Get Your FREE Software Development Coaching Session

Strategies for Practicing Detachment

If we know people need to be more comfortable with uncertainty, and they need to be less attached to outcomes – what are some strategies we can use to help cope with this?

Thinking About the Possibility of Other Outcomes

Most people in corporate American don’t want to do this. Typical work structures are all about certainty and planning for outcomes we expect. Instead, thinking about the possibility that what we’ve planned might not work out ahead of time primes us for a healty mindset for taking risk.

Beware of Catastrophizing

Once you begin to allow yourself to think about the possibility of uncertain outcomes, it’s tempting to think of the worst case scenario. This is known as catastrophizing, and creates anxity by focusing your thoughts on negative situations that haven’t even happened yet!

Overcoming Resentment to Past Failures

If we hold on to negative feelings about what may have happened in the past, we won’t have the open mind necessary to try new things. Resentment is another form of attachment.

Challenging Limiting Beliefs

If someone told you something about yourself as a child, or perhaps a co-worker made a statement about your skills – you may be walking around carrying an innacurate picture of yourself. Challenge your thoughts about what is really true in your perspective so you don’t stay attached to lies about yourself.

Separating Our Identity From Outcomes

In most companies if someone makes a “bad” decision, they are held accountable. What this can do though is cause us to place our self-worth in our decisions and their outcomes. To have the courage to innovate, we need to separate these two.

Practicing Delayed Gratification

Waiting longer to get something you want might sound silly, but you’d be surprised how many people are still attached to immediacy and this often is the reason why others don’t support you. Practice this yourself, and with your team, to relax your expectations so you can take risks.

Permitting Others to be Frustrated with Uncertainty

It’s natural that when trying to do something new, such as to not be as attached to outcomes, you and others will make mistakes. It’s crucial that everyone be willing to forgive each other when unpredictable negative outcomes occur.

Related Videos

Watch my Scrum vs Kanban video.
Watch my Lean Software Development video.
Watch my A/B Software Development video.
Watch my Uncertainty of Software Development video.
Watch my Anxiety of Software Development video.

The post Overcome Attachment: Discover Lean Software Development appeared first on Jayme Edwards.

]]>
https://jaymeedwards.com/2017/10/17/overcome-attachment-discover-lean-software-development/feed/ 1
How To Build Consensus For Software Decisions https://jaymeedwards.com/2017/10/13/build-consensus-software-decisions/ https://jaymeedwards.com/2017/10/13/build-consensus-software-decisions/#comments Fri, 13 Oct 2017 14:03:32 +0000 https://jaymeedwards.com/?p=5375 Do you need to get people to agree and come to consensus so you can grow on your software project, or in your career?

The post How To Build Consensus For Software Decisions appeared first on Jayme Edwards.

]]>

Do you need to get people to agree and come to consensus so you can grow on your software project, or in your career? Today I’d like to share a few resources, and some simple concepts to consider, when influencing others to make a decision.

WATCH THE VIDEO ABOVE, LISTEN TO A PODCAST, OR READ A SUMMARY:

When I started out in my career, I was a good software developer and could write code and work with many complicated pieces of technology. But I didn’t become good at influencing people until I began consulting a decade later.

The Circles of Influence

Stephen Covey’s famous book “The 7 Habits of Highly Effective People”, introduces many powerful concepts for better work. I’d like to mention his concept of circles of influence, which is important for thinking about how to build consensus.

The first circle is the circle of control, and typically only includes yourself. If you have children, or subordinates, you may consider them within this circle. In most cases however, there is little you can actually control.

The second circle is the circle of influence, and is comprised usually of people on your software team who you already have good relationships with. These are people who will take your advice seriously, and expect you to influence them.

Get Your FREE Software Development Coaching Session

The last circle is the circle of concern, and includes people that we have no direct control over OR influence with. Influencing these people usually takes indirect influence through another person.

Who Can I Influence Already?

It makes sense, especially within the context of Stephen Covey’s book and recommendations himself, that we focus on those we can influence first. If we already have great relationships, those should be the first people we bring over to our side with a decision.

Identifying Stakeholders of Your Circle of Influence

Because it often takes getting agreement from people outside our circle of influence, we next need to identify who these people are. We can typically influence them indirectly through the relationships we already have. If not, we can look to someone else we know, that knows this person already, to open a door to a conversation.

You May Need to Influence “Up the Ladder”

Many software companies can grow into a structure with multiple levels of people. Even when using agile development methods, communication across people continues to be a challenge. In addition to building consensus across our circle of influence at our level, we may need to get agreement UP the “ladder” of people in the company so we can reach consensus.

Beware of Team Dysfunctions

While attempting to influence others, it’s common that due to past failures or trust issues, you may run into politics. The book by Patrick Lencioni, “The 5 Dysfunctions of a Team”, is a great resource to help you win back the support of difficult people and get everyone talking honestly again.

Related Resources and Videos

Watch/Listen/Read: How To Win Trust For Software Ideas
Buy 7 Habits of Highly Effective People
Buy The 5 Dysfunctions of a Team

The post How To Build Consensus For Software Decisions appeared first on Jayme Edwards.

]]>
https://jaymeedwards.com/2017/10/13/build-consensus-software-decisions/feed/ 1
How To Shut Down Your Feature Factory https://jaymeedwards.com/2017/10/06/shut-feature-factory/ https://jaymeedwards.com/2017/10/06/shut-feature-factory/#comments Fri, 06 Oct 2017 19:24:29 +0000 https://jaymeedwards.com/?p=5161 Are you developing software under pressure like a "feature factory", but there never seems to be any economic benefit to the changes?

The post How To Shut Down Your Feature Factory appeared first on Jayme Edwards.

]]>

Are you developing software under pressure like a “feature factory”, but there never seems to be any economic benefit to the changes? Today I’d like to share some strategies to begin shutting this unhealthy work approach down.

WATCH THE VIDEO ABOVE, LISTEN TO A PODCAST, OR READ A SUMMARY:

The term “feature factory” was coined by John Cutler, a Senior Product Manager currently at ZenDesk. He wrote an article in the Hackernoon publication on Medium here that introduced the concept to the masses.

When you read his article, you may, like me, find yourself nodding your head “YES!” to all of it. Anyone who has worked to produce software on a team that is a feature factory will immediately recognize many of the symptoms.

What is a Feature Factory?

I’d encourage you to read all of John’s articles for more details, but when you really boil it down a feature factory is a team or company that doesn’t know how to measure the business impact of their changes.

Set a Measurable Business Impact Goal for EVERY Change

When we’re in school many of us learn the scientific method. At a high level – you have a theory, you decide how to measure it, you design an experiment, and you record the results. Often our theories are proven wrong.

Unfortunately, when it comes to developing software many of us assume we can’t be wrong and do very little to handle that very real possibility. One of the first things that is necessary to shut down a feature factory, is to only make changes that can be measured as being successful or not in reaching an outcome.

Move Further Towards Cross-Functional Teamwork

When the people who work together to produce software are in separate departments, it often leads to people deferring design decisions to a UX, Product Management, or other design person. A cross-functional team actually strengthens the ability to deliver “the right thing” and NOT be a feature factory, because everyone can contribute to design ideas because they are dedicated to the success of ONE product.

Celebrate Outcomes Instead of Releases

When we start releasing software several times a day using things like DevOps and Continuous Delivery, we often will not hit a positive business outcome with each release. Because of the chance of failure, we should celebrate as a team when we reach a business outcome – not every time we release. John calls this “success theatre”.

Cultivate a Culture Safe for Failure and Learning

When we plan a project that takes a long time to deliver, during that period there are assumptions about the value of what’s being built. There are no ramifications or learning until the end, and on some teams if the product doesn’t deliver on it’s expectations people are FIRED!

Get Your FREE Software Development Coaching Session

To allow teams to be innovative and discover what they truly want, you must release small changes with the expectation that these may be “wrong”. This requires making it safe for Product Managers and others to take risks so they can learn.

Focus on Value NOT Efficiency / Utilization

This one is pretty self explanatory. If a team is constantly pushed to be as efficient as possible, they won’t have the relaxed and creative mindset necessary to make changes that contradict our initial assumptions!

Release Smaller Changes, More Often

To enable failures (learning) to have a smaller impact and cause less waste when it comes to budgeting – designing changes (experiments) that can run as FAST as possible and give us feedback EARLY is crucial.

Additional Links and Related Videos:

Watch my video on Lean Software Development here.

Watch my video on Cross-Functional Teams here.

Watch my video on Continuous Delivery here.

John Cutler’s articles on Medium: https://hackernoon.com/@johnpcutler

Learn more about Psychological Safety by following Ashley Johnson and Tim Ottinger

The post How To Shut Down Your Feature Factory appeared first on Jayme Edwards.

]]>
https://jaymeedwards.com/2017/10/06/shut-feature-factory/feed/ 1
5 Ways Dishonesty HURTS Your Software Development Career! https://jaymeedwards.com/2017/09/11/5-ways-dishonesty-hurts-your-software-development-career/ https://jaymeedwards.com/2017/09/11/5-ways-dishonesty-hurts-your-software-development-career/#comments Mon, 11 Sep 2017 18:33:11 +0000 https://jaymeedwards.com/?p=4376 Today I'd like to share some ways dishonesty hurts your software development career, including past ways I have been dishonest that I now see are common.

The post 5 Ways Dishonesty HURTS Your Software Development Career! appeared first on Jayme Edwards.

]]>

Do you find it hard to be honest with others about some aspect of developing software? Or maybe you find others are withholding truths, and you wonder why? Today I’d like to share some ways I have been dishonest earlier in my career, and I now see are common in our industry.

WATCH THE VIDEO ABOVE, LISTEN TO A PODCAST, OR READ A SUMMARY:

Not Admitting Being Unfamiliar With Something

In short time, we can gain a lot of knowledge about technology and software development processes. If we’re not careful, this leads to a “big head” or inflated ego, and we can feel embarrassed if we haven’t heard about “the new hotness”. If we’re honest with others when we don’t know something, they trust us more to be transparent, and they know they can share things they are excited about without us shutting them down in an attempt to be seen as the expert.

Saying “Yes” To Work You Don’t Understand

It is often that on software projects we are asked to estimate work based on the information another has captured for us. If we don’t fully take the time to understand it, or have a self-inflated sense of our level of skill, it doesn’t take much to agree to work when we shouldn’t. I learned to say “No” more strongly and honestly about 5 years ago, and it has helped me on numerous occasions. When I didn’t do this, I would often put myself under extra pressure, and have to reset expectations with the other party who is now upset that I can’t deliver what they expected.

Not Admitting We’ve Overlooked A Process Step

Software development is inherently complex and often requires many moving parts to be changed in a very specific sequence to accomplish work. As humans, we will inevitably make mistakes. Under pressure, I have failed to be honest with others that I simply forgot a step in my desire to be seen as the expert.

Get Your FREE Software Development Coaching Session

I have become MUCH better about being honest about this now, but it is very common in more junior technologists. When we take responsibility for forgetting something, we build trust with others who know we will hold ourselves accountable for our actions.

Making Generalizations About Others

In our desire to be seen as the expert, we can sometimes have just a few interactions with another person and then paint them as incompetent or lacking in skill to others. This thinly-veiled attempt to make ourselves appear smarter than we are casts doubt in all but the most unsophisticated of people. If the person you made a generalization about meets the person you said this to, they will find out that you are quick to judge and make inaccurate statements on a whim. Just don’t do this!

Not Being Honest About Your Level Of Contribution

We work hard to produce quality deliverables and value for our team and customers on software projects. And few things feel better than a customer or someone else at the company saying “great job”! But I have not always been as forthcoming about the work others did to support me in successes, and since getting better at this my ability to motivate others and build trust has gone up tremendously. When you check yourself when receiving a complement and remember to include others who were part of the success, you build a positive emotional connection between you and them, and deepen the trust and loyalty necessary to keep a strong team together.

#softwaredevelopment #softwareengineer #softwareengineering #softwaredeveloper #softwarearchitect #softwarearchitecture #agile #lean #scrum #kanban #productmanager #productmanagement #digitalproduct #digitalproducts #career #culture #softskills

The post 5 Ways Dishonesty HURTS Your Software Development Career! appeared first on Jayme Edwards.

]]>
https://jaymeedwards.com/2017/09/11/5-ways-dishonesty-hurts-your-software-development-career/feed/ 1
My Software Development Journey (Part 3) https://jaymeedwards.com/2017/09/11/my-software-development-journey-part-3/ https://jaymeedwards.com/2017/09/11/my-software-development-journey-part-3/#comments Mon, 11 Sep 2017 18:25:35 +0000 https://jaymeedwards.com/?p=4372 Would you like to know more about who I am and how I became passionate about lean methods? Let me share part 3 of my software development journey with you.

The post My Software Development Journey (Part 3) appeared first on Jayme Edwards.

]]>

Would you like to know a little more about who I am, and how my successes and setbacks shaped me into someone who is so passionate about doing less at one time, and embracing uncertainty as part of a lean software development mindset? Today I’d like to share part 3 of my software development journey with you.

WATCH THE VIDEO ABOVE, LISTEN TO A PODCAST, OR READ A SUMMARY:

Agile Theater: Alive And Well

What my consulting experience had shown me so far, was that many companies still struggle to do agile development. They use some of the technologies and processes, but they have a difficult time transforming the minds of leadership and key players to support true agility.

First Startup: Social Network / Time Tracking For Home Schoolers

I got the idea for and began building a social network for home schoolers about 6 years ago. The product was built in ruby on rails for speed to market, and being a Father of 3 home schooled children myself, my wife and I knew some of what we thought others would want. Unfortunately, I fell into the classic “Subject Matter Expert” trap! I had a “knowing / doing gap” where I could help OTHERS do lean software development, but when it came to MY ideas, I was just as stubborn! In the end I stopped working on the product as I had built too many things that were not useful to my customer, and market analysis had me wanting to pursue a different market.

Becoming (Unwillingly) A Firefighter

Around this time my day job in consulting began sending me in to help fix issues at projects with our clients that were in trouble. I got good at this, but it began to burn me out as I started seeing the same quality issues from both our consultancy and the client. The root problem was that the way we engaged with our clients did not embrace agility, and so when things changed or we learned we’d failed in some way, it was costly and slow to adapt.

Resistance To The Shift Towards Lean

I began to put together a set of content and team that would have the skills at my consultancy to start delivering in a more lean fashion, but the leadership did not yet have the courage to support me even after numerous presentations, discussions, and wins. By the time they began to invest, it was too late – our competition had a several year lead on us.

Second Startup: Public Health Data Analysis

A friend of mine whom I’d worked with for many years brought an idea to me for a product and was gracious enough to ask me to be involved. There were a number of problems as we began building the company though. First, we both had day jobs and children, and the personal investment was too high to be sustainable for our initial offering. Second, we weren’t clear on our lines of responsibility and so our relationship was taxed.

Get Your FREE Software Development Coaching Session

Third, the technology landscape around the “big data” tools we were using were too immature, and there was too much rework we needed to do to deliver the minimum viable product (MVP). Lastly, we failed to deliver small enough ideas before getting feedback, and fell again into the “Subject Matter Expert” trap by overbuilding.

A Burning Desire To Be Lean

I finally read “The Lean Startup” by Eric Ries and it opened my eyes to some of the things I had been doing wrong. As I began trying to apply these techniques with clients, I came up against confusion created by vendors in the industry who focus on technology that is “lean” or “agile” but don’t help companies truly adopt the lean mindset. Battling this became the current focus of my career.

Using Small Batches To Improve Product Management

I wanted to help the people driving the direction of the product to learn whether they failed or not with less investment, and faster, so they wouldn’t make the same mistakes I did. To do this however requires creating the psychological safety necessary for failure and learning. And to get support for transforming the culture to support this safety, consulting skills are necessary.

Supporting Your Lean Transformation

Eventually, I started a membership program to help mentor software professionals to get the support for consulting and lean skills necessary to help them transform their company’s culture, or use lean techniques for their own startup ideas. I am focused on helping people use the scientific method, as described in the Lean startup; relationship skills and personal development to become a better communicator and persuader; and Continuous Delivery technologies such as the cloud and automation technologies – all in an effort to be more successful.

Referenced Videos

Watch Part 1 here, and Part 2 here.

Watch How To Win Trust here.

Watch How To Fail Faster here.

Watch About Minimum Viable Products here.

Watch How To A/B Software Development here.

#softwaredevelopment #softwareengineer #softwareengineering #softwaredeveloper #softwarearchitect #softwarearchitecture #agile #lean #scrum #kanban #productmanager #productmanagement #digitalproduct #digitalproducts #career #continousdelivery #devops #leanstartup

The post My Software Development Journey (Part 3) appeared first on Jayme Edwards.

]]>
https://jaymeedwards.com/2017/09/11/my-software-development-journey-part-3/feed/ 1
My Software Development Journey! (Part 2) https://jaymeedwards.com/2017/09/11/my-software-development-journey-part-2/ https://jaymeedwards.com/2017/09/11/my-software-development-journey-part-2/#comments Mon, 11 Sep 2017 18:15:48 +0000 https://jaymeedwards.com/?p=4368 Would you like to know more about who I am and how I became passionate about lean methods? Let me share part 2 of my software development journey with you.

The post My Software Development Journey! (Part 2) appeared first on Jayme Edwards.

]]>

Would you like to know a little more about who I am, and how my successes and setbacks shaped me into someone who is so passionate about doing less at one time, and embracing uncertainty as part of a lean software development mindset? Today I’d like to share part 2 of my software development journey with you.

WATCH THE VIDEO ABOVE, LISTEN TO A PODCAST, OR READ A SUMMARY:

Letting Go Of “My Baby”

After my first project that was both a product I designed and an opportunity to lead, I was given the opportunity to start a new one. It was difficult to let go of the success I’d had, and hard work I’d done, of this first project so early in my career.

Release Deadline Sabotage!

Soon the head of the company mandated that all products across the company release on the same day every 6 months. He had no idea what this took, but at the end of the day my team’s project was the only one ready. For political reasons, it was sabotaged by changing the name the last week of the deadline!

Following The Leader To New Opportunities

After our project was sabotaged, my boss was unfortunately fired and took the fall, and he moved on to a new company where I followed shortly thereafter. This new company was in the pharmaceutical space and needed the kind of help my old team at the prior company could provide, so many of us switched over.

Pioneering Agile

We built a simple web portal that let us track our sprints and other artifacts related to agile. This was before tools like Jira, Pivotal Tracker, or Team Foundation Server were available. It was crude, but we learned a lot and through our mistakes and successes became very early proponents of Scrum.

Family Conflicts Of Interest

Unfortunately there was a miscommunication between my boss and his, and my boss took the fall AGAIN due to company politics wrapped up in family ownership.

Get Your FREE Software Development Coaching Session

I was extremely frustrated at this point after seeing my boss, who I considered one of the best leaders I’d worked with, continuing to be sideswiped by politics.

My First Architecture Consulting Experience

I followed my boss again to his next company, and got a chance to provide architecture consulting services. We helped them ship a late product, and created a prototype of a new one in ruby on rails over that year.

Moving To Austin, Texas

Eventually my Wife and I wanted a change, so we moved to Austin, Texas. The lifestyle and career options were more in line with what we wanted at the time, and we’re still here today as of 2017.

Moving Into Consulting

Shortly after arriving in Austin I was contacted about a consulting opportunity. Though it was a little less than I wanted compensation wise, I was excited about the chance to learn a different way of providing IT services and took the offer.

Getting An Ego Check-Up

I frustrated several clients in the first 2 years I was a consultant, and had a reality check. During my performance review I was criticized (rightfully so) for my inability to talk and relate well with clients.

Setting The Intention To Improve My Soft Skills

After the deflating performance review, I emboldened myself to learn what I needed to “get” this consulting thing. I came across the book “Flawless Consulting” by Peter Block after my wife purchased it to help her with Nutritional Health Coaching.

Learning To Be A Trusted Advisor

The first time I applied the info in Flawless Consulting was a game changer. I could win the trust and advisor status with a client almost immediately through these strategies!

Discovering Continuous Delivery

While working for a large international grocer based in Austin, I read the book on Continuous Delivery by Jez Humble. This had a huge impact on me and caused me to focus my career almost solely on mastering it.

Teaching Clients About Continuous Delivery

After creating a framework in Windows PowerShell that helped me implement Continuous Delivery at clients, I began to be frustrated that though we helped them release multiple times per day, their planning and budgeting process still didn’t allow them to BENEFIT from this new capability.

Discovering Lean Startup Product Management

This led me to learn more about Eric Ries, and eventually read his famous book “The Lean Startup“. I’ll talk in Part 3 about how I discovered how important this information was through 2 startups I failed to find market fit for.

#softwaredevelopment #softwareengineer #softwareengineering #softwaredeveloper #softwarearchitect #softwarearchitecture #agile #ux #productmanager #productmanagement #digitalproduct #digitalproducts #career #leader #leaders #leadership #relationship #relationships

The post My Software Development Journey! (Part 2) appeared first on Jayme Edwards.

]]>
https://jaymeedwards.com/2017/09/11/my-software-development-journey-part-2/feed/ 2
My Software Development Journey! (Part 1) https://jaymeedwards.com/2017/09/11/my-software-development-journey-part-1/ https://jaymeedwards.com/2017/09/11/my-software-development-journey-part-1/#comments Mon, 11 Sep 2017 18:05:46 +0000 https://jaymeedwards.com/?p=4364 Would you like to know more about who I am and how I became passionate about lean methods? Let me share part 1 of my software development journey with you.

The post My Software Development Journey! (Part 1) appeared first on Jayme Edwards.

]]>

Would you like to know a little more about who I am, and how my successes and setbacks shaped me into someone who is so passionate about doing less at one time, and embracing uncertainty as part of a lean software development mindset? Today I’d like to share part 1 of my software development journey with you.

WATCH THE VIDEO ABOVE, LISTEN TO A PODCAST, OR READ A SUMMARY:

Leadup To My First Development Position

Though I’d learned some BASIC programming on “old school” Apple computers in middle school, when I attended college to become a “Microcomputer Specialist” *cringe*, I didn’t know exactly what I wanted to do in technology. One of my first teachers had me do some web development sidework in college, and soon my Mother met someone at her church that would give me my first job. I came into the organization with no idea of what to expect but excited to do front end testing of software components using Visual Basic at the time. This was my first professional IT experience.

Finding My First Mentors

I explicitly sought out older, disgruntled software professionals at my company and asked for them to teach me. It gave them something to be excited about (teaching others), and I learned tons! It’s easy to be a skeptic today with all the information previously hidden from the public that’s come out in the past decade or so online. Though we’ve all become more distrustful of the government, corporations, and the news – we should be careful not to let opportunities to learn from other individuals pass us by.

Get Your FREE Software Development Coaching Session

One of the biggest mistakes I’ve made in my career is trying to “shortcut” learning by asking mentors to only describe things I “don’t know”. Often the most revolutionary insights I learned from others were about what I already considered myself an “expert” on.

Envisioning And Prototyping A New Product

A little over a year into my first position, my wife was pregnant with my second son who would go to bed at 7pm. I was around 21 at the time, so I didn’t feel right going out and partying while she was at home. So I would stay home and read books about the latest new technologies. Eventually I created a prototype of a new product that simplified 5 existing products we had acquired from other companies to simplify the user experience. My boss showed it to the CEO and within a short time I was the technical lead (Application Architect) over a team of 12 people.

Inventing an XML Message Protocol For Manufacturing

At the time, web applications were written about but hardly anyone was doing them. SOAP and REST were not out yet, but I recognized that the application needed to use a messaging protocol to talk to applications and manufacturing devices. XML was popular at the time, so I invented and patented a messaging protocol allowing this to happen.

Getting Executive Sponsorship

Somehow my boss showed a prototype of what I was working on in my spare time to the VP (who would eventually become the CEO). He recognized it as “the most strategically important project in our portfolio” and asked us to pick 12 people from anywhere across the company to build a project team. On the surface, it was an amazing opportunity – new technology, a new product, a new team, full sponsorship. What could possibly go wrong? 🙂

Recognizing My Limited Understanding Of Development Process

At the time, there was no agile manifesto, and many companies did “waterfall” but didn’t call it that. I realized quickly that I was unprepared for all of the process nuances related to successfully leading the team. I was good at producing artifacts, but I was horrible at estimating being both new, and working on new technology. Luckily, the company was aware of the need to relax predictability to innovate and take risks so they could grow.

Recognizing My Lack of Relationship Management Skills

I was leading many people who didn’t know me very well and were 10-20 years older than me. I didn’t understand how to setup our relationship with respect for them so we could work together well. Half of my team was inspired by me and loved my passion and ability with the technologies. The other half couldn’t stand me and soon conspired to get rid of me. This was all due to my inexperience with company politics, knowing how to treat people, and relationship management in general.

The IT Industry Needs To Focus More On People

Our industry is driven by gadgets, tech, and whatever helps engineers be intellectually stimulated. But understanding people, how to get concensus, and how to win trust from others is JUST AS important if not moreso to your career. My first job was a great example of how not having these skills led to a lot of friction with my colleagues.

I Hope This Channel Helps You Be Less Anxious

I’ve made a lot of stupid mistakes in my career when I let fear and anxiety get the better of me. As this channel’s videos progress, I hope hearing more of the story of my career, and the tools I’ve used more recently, will help you have less anxiety as your career moves forward.

#softwaredevelopment #softwareengineer #softwareengineering #softwaredeveloper #softwarearchitect #softwarearchitecture #agile #ux #productmanager #productmanagement #digitalproduct #digitalproducts #career #leader #leaders #leadership #relationship #relationships #patents #patent

The post My Software Development Journey! (Part 1) appeared first on Jayme Edwards.

]]>
https://jaymeedwards.com/2017/09/11/my-software-development-journey-part-1/feed/ 2
How Failure Produces BETTER Software Projects! https://jaymeedwards.com/2017/09/10/failure-produces-better-software-projects/ https://jaymeedwards.com/2017/09/10/failure-produces-better-software-projects/#comments Mon, 11 Sep 2017 00:35:40 +0000 https://jaymeedwards.com/?p=4359 Today I'd like to talk about how learning of a team failure produces better software when you plan to exploit this ability.

The post How Failure Produces BETTER Software Projects! appeared first on Jayme Edwards.

]]>

In this video on my YouTube channel, I talk about how learning of a team failure produces better software when you plan to exploit this ability.

WATCH THE VIDEO ABOVE, LISTEN TO A PODCAST, OR READ A SUMMARY:

The overall assumption that most projects operate under is that the project will be successful. However there are several smaller assumptions upon which this one is built. Often these smaller assumptions need to be verified to make decisions that keep the overall state of progress moving in a sustainable direction for the product.

Assumptions About The Skill Of The Team

If the team isn’t as skilled as assumed, projects will take significantly longer and more brittle to change.

Assumptions About The Quality Of The Release

If the team hasn’t put the appropriate quality checks in place, changes assumed to have a certain level of quality that don’t cause rework.

Assumptions About Full Understanding Of Scope

If the team is assuming requirements are complete, they look at scope change as failure.

Assumptions About Value Of Features & Changes

If the team is assuming changes being released are valuable to customers, but there aren’t measurable ways to know whether that’s true, waste could be being released.

Doing Less At One Time Is THE KEY To Learning Through Failure

Overall, the key to learning that we’ve “failed” in some way and need to adjust direction based on what we’ve learned FASTER is to do less at one time!

Doing Less Between Releases Minimizes Risk

If we make a mistake to a small change, the impact of that change should be smaller than releasing a large change. This minimizes the impact of rework or breakages.

Doing Less Between Releases Motivates Realignment

If a team iterates on a backlog that hasn’t been significantly changed since the project starts; the business has low motivation to realign. If a team is taking action on the feedback of rapid releases, the business must be more responsive.

Doing Less Between Releases Improves ROI

For every day that development continues without a release, there’s no return on investment. By releasing more frequently, the team has the opportunity to provide value to the customer with less capital.

Doing Less Between Releases Improves Skill

If we do a production release every 6 months, how good are people going to be at it? Doing less between releases forces the entire team to practice release practices more often.

Get Your FREE Software Development Coaching Session

This results in a team with higher delivery skill.

Fail Faster By Having Artifacts That Provide Feedback

Having tools and processes that give us the state of a change at any time lets people know a failure to some process has occurred early. This enables people to take action on issues as they emerge and catch them before the change makes it out to customers.

Fail Faster By Using Cross Functional Teams

The lag time that occurs between separate departments for disciplines needing something and sub-contracting “as a service” causes releases to take longer. If we want to fail faster, we need to have all the people needed to release the product dedicated to it and working together so there is no lag time to service outside of the immediate group.

Fail Faster By Holding Retrospectives

Have a meeting to talk about what went well and what didn’t over the past release (Scrum) or several releases (Kanban). This is an easy way to learn earlier that the team is failing to follow processes that are working for the project.

Fail Faster By Releasing To A Limited Audience

Rather than learning that there’s an issue with a release from a large number of voices from your customer base, have a system in place to release to only a small subset of total customers. This is known as ring releasing or canary releasing.

Fail Faster By Having a Measurable Pass/Fail

Many projects release a large number of features. If some KPI changes positively, it is difficult then to know which of those features or changes caused the positive change. Use A/B testing to verify that investments actually impacted a KPI.

Fail Faster By Focusing On Valuable Outcomes

Most projects have a large number of features. Rather than keeping everyone busy “burning down” a large list, figure out how much money the business is losing by NOT having each story (cost of delay). Work on the highest cost of delay ideas with FOCUS since those are the most economically viable!

Fail Faster With Justin-In-Time Scoping

If a team does detailed requirements on a large quantity of work, it creates psychological attachment and wastes money. Teams should instead only get the details of the top items on the list periodically.

Fail Faster With Monthly Budgeting

If we assume that we’ll learn we need to change what’s built every release, we need to re-budget every release with project % complete accounting. Rather, budget monthly to provide the capital needed to take action on changes to customer needs with less pain.

Referenced Videos

Watch my video on A/B testing here.

The post How Failure Produces BETTER Software Projects! appeared first on Jayme Edwards.

]]>
https://jaymeedwards.com/2017/09/10/failure-produces-better-software-projects/feed/ 2
How UNCERTAINTY Impacts Software Development Processes https://jaymeedwards.com/2017/08/24/uncertainty-impacts-software-development-processes/ https://jaymeedwards.com/2017/08/24/uncertainty-impacts-software-development-processes/#comments Thu, 24 Aug 2017 21:23:42 +0000 https://jaymeedwards.com/?p=4353 Other software developers often disagree with us about what processes to use due to how uncertainty impacts software development.

The post How UNCERTAINTY Impacts Software Development Processes appeared first on Jayme Edwards.

]]>

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.

WATCH THE VIDEO ABOVE, LISTEN TO A PODCAST, OR READ A SUMMARY:

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.

Changing Market, Customer Needs, and Technologies Require More Adaptability Today

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.

How Responsive Is Your Company Willing To Be?

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.

Get Your FREE Software Development Coaching Session

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.

Uncertainty Of Scope and Budget

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.

Uncertainty Of Cost and Measuring Progress

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.

Uncertainty Of State Of The Code

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.

Uncertainty Of Customer Needs and User Experience

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.

Uncertainty Of Software Architecture

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.

Referenced 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.

#softwaredevelopment #softwareengineer #softwareengineering #softwaredeveloper #softwarearchitect #softwarearchitecture #agile #ux #productmanager #productmanagement #digitalproduct #digitalproducts #ab #abtest #abtesting #budget #budgeting #scrum #kanban

The post How UNCERTAINTY Impacts Software Development Processes appeared first on Jayme Edwards.

]]>
https://jaymeedwards.com/2017/08/24/uncertainty-impacts-software-development-processes/feed/ 2
What MEN Need To Know About Software Developer BRO CULTURE! https://jaymeedwards.com/2017/08/16/what-men-need-to-know-about-software-developer-bro-culture/ https://jaymeedwards.com/2017/08/16/what-men-need-to-know-about-software-developer-bro-culture/#comments Thu, 17 Aug 2017 00:58:38 +0000 https://jaymeedwards.com/?p=4345 I'd like to offer some insights and opinions that might help men make smarter decisions about whether we engage in software developer bro culture.

The post What MEN Need To Know About Software Developer BRO CULTURE! appeared first on Jayme Edwards.

]]>

Are you confused or frustrated by the amount of energy spent discussing sexism in the workplace and how men are to blame? Today I’d like to offer some insights and opinions that might help men make smarter decisions about how we treat people to make sure we’re not damaging our careers and making it difficult for people to work with us.

WATCH THE VIDEO ABOVE, LISTEN TO A PODCAST, OR READ A SUMMARY:

Disclaimer: These Are MY Opinions And Personal Insights

First a disclaimer. I’m a heterosexual man and these are just my opinions after many years working in the industry that I’ve observed and experienced. I’m not qualified to talk about what makes the workplace safe for women, but I can share how my own shortcomings and observations of other men’s behavior makes it hard for everyone.

Purpose: Get You To Think More Seriously About This Issue

The purpose of this video is not to tell you what the solution to all of these issues is, but to get you to think about how software developer bro culture affects all of us. My hope is that this will lead to you spending some time researching the issue to reach your own conclusions with intention.

What’s It Like To Work With “Bros”?

First I’d like to share what it’s like to work with other “bros”. On an all male, or male-dominated team like I’ve been on several times, unchecked aggression, free exchange of ideas regardless of how they make people feel, and shaming are prevalent. The people who do this don’t always intend for this outcome, but as the team grows and these behaviors are left unchecked, it becoming “the norm” is the result.

Men Can Feel Threatened By Women’s Support Of Each Other

I share a story about how a man approached a group of women discussing their lives in the park while my wife was at Yoga teacher training in Boulder. He made the crude joke “what is this the man hater’s group?” which underscores how men feel threatened by women’s support of each other.

Get Your FREE Software Development Coaching Session

Because we can often feel it is a sign of weakness to support each other, we can lash out and say and do stupid things when we are uncomfortable.

Men Fear Losing Relationships If They Show Vulnerability

I also read a brief passage from “Daring Greatly”, a New York Times Best Seller by Brene Brown, speaker, PHD, and researcher on shame and vulnerability in modern culture. In the passage, I describe the real struggle men feel when they don’t have a safe place to express vulnerability. I’ve included a link to the book at the bottom of the page. The conclusion I draw is that men can become afraid of losing relationships that are important to them if they show vulnerability.

Misery Loves Company…

So why do men continue to behave this way? One reason is the concept of “misery loves company”, or the phenomenon where men engage in behaviors and ways of relating that make them feel worse about each other just because it feels good to be part of a social group. Standing up for ourselves to not engage in this behavior and instead hold ourselves to a sustainable, higher standard is the first step in rejecting this attitude.

Domination Focus Will Limit Your Career Progress

We also behave this way because we’re modeled from a very early age to dominate others. However, domination will severely limit career progress as we move from company to company, or team to team, as our “bubble” of acceptable behavior is broken and we’re forced to interact with wider, more diverse groups of people.

Lack Of Empathy Can Cause Others To ABANDON You

A lack of empathy will ultimately cause others to treat us with low respect. When things inevitably go south in any shape or form on a project, and leadership looks for someone to blame, if you treat others like objects of your will and not people you will be at the top of the list to take the fall. This is another form of short-term thinking and it doesn’t take long for your career reputation to catch up with you – making a sustainable plan for growth much more painful than necessary.

Compromising Work/Life Balance Makes You Easier To Replace!

In our quest to advance in our careers, we unfortunately often compromise work/life balance with the expectation that this will help us get ahead. In reality, though it might result in a short term promotion or advantage, we actually make it EASIER to replace us with younger, naive employees that will do the same when we inevitably grow tired. Men can do a better job than this and stand up for a fair balance of work by refusing to contribute to the workaholic mindset.

Industry Veterans Owe It To Future Colleagues To Improve Culture

Since we will be working with the next generation as we progress, we owe it to our younger colleagues, regardless of their gender or ethnicity, to improve the tech culture. If we accept software developer bro culture as the default way teams interact, we are simply destining ourselves and others to a short career filled with disappointment as we’re not prepared with the social skills and empathy needed to progress.

You can find “Daring Greatly” by Brene Brown here.

#softwaredevelopment #softwareengineer #softwareengineering #softwaredeveloper #softwarearchitect #softwarearchitecture #career #tech #vulnerability #shame #domination

The post What MEN Need To Know About Software Developer BRO CULTURE! appeared first on Jayme Edwards.

]]>
https://jaymeedwards.com/2017/08/16/what-men-need-to-know-about-software-developer-bro-culture/feed/ 1