They say, “change is hard.”
In order to make you and your customers successful, it’s important to make change easy.
Change Barrier #1: The FIXED mindset
One principle that I’ve heard over and over again in agile training and in self-improvement reading is the idea that LEARNING must be a primary goal.
Back in high school a friend of mine and I decided that we were going to make straight ‘A’ in our last semester of high school. We had reasonably hard classes like AP calculus, physics, English literature, drafting III, digital electronics II (at local community college) and perhaps one more that I don’t remember.
If you apply sound reasoning to the problem of getting good grades, you are likely to find that LEARNING is not necessarily the easiest road to tread.
That’s correct, achieving good grades does not require LEARNING, it requires finding the shortcuts to deliver answers on the homework and tests.
Although, I must admit some teachers do a good job of making LEARNING happen even when students are focused on just grades…kudos to you Mr. Ross (my AP Calculus teacher).
Both myself and my friend Kirk both got straight A’s that semester. We worked a little harder and pushed each other to meet the challenge, but I definitely did not spend the time to master the information, I spent the time to dominate the examination.
With software development, we often have a mindset of getting it right rather than LEARNING. In other words, we might come up with what we think is really good idea. It’s inspiring and a fine design.
We DECIDE that we have the right information to build the right product that will make people happy.
If the investment is small, the ‘right product’ will only fail a little bit. If the investment is large making ‘right product’ will be somewhere between 80% failure and total catastrophe.
Use the LEARNING Mindset
The alternative is always to keep your product development cycle focused on LEARNING.
Make LEARNING the goal, especially in development new products. In my own work environment, we’ve development several new products from scratch in the past 2 years.
The feature sets for each of the products has been a tight loop of iterative development that includes minimal working products delivered with minimal investment and minimal functionality and maximal learning.
These products were brand new. The customer often started the conversation with “I really don’t know how this should work.” After a delivery, the customer would say, “I want to change this.” Later in development, as the customer and development team LEARNED more and more the conversation moved to “We need this new item to work like this.”
Where should you be on the LEARNING curve? There is probably a higher focus on LEARNING at the start of a new product. But even with very stable products a focus on LEARNING can enable better value to the customer.
Optimize for LEARNING rather than for product end state.
Change Barrier #2: Enormous Tightly Couple Monolithic Code
For all the software developers out there, I used all the super evil code words in the title of this section. We know these things to be insidious speed limiters on any project.
When I was younger I worked in an auto shop with my dad in the small town of Flagstaff, Arizona. I was only 11 years old at the time when my dad had a contract to service the UPS delivery trucks.
In the course of my dad teaching me about how to maintain a UPS truck, I was shocked to find out that the UPS trucks had a governor on them that kept their top speed under 55 mph. Back in those days, the national speed limit was indeed 55 mph, so that kept the drivers from some amount of speeding on the highways.
I was horrified by this notion that you took a perfectly good vehicle that had a hefty engine and then hamstrung it with a ‘governor.’
This past weekend I took a quick road trip and we drove on an interstate with a 70 mph speed limit. The UPS truck from the 1980’s would probably not be around today, but if it was, it would get run over by just about everyone.
In software development, you do not want to put a governor on your speed. To avoid speed killers such as tight coupling and a monolithic application force yourself to decompose the system into independently architected pieces.
Sounds simple, doesn’t it? In the real world decouple systems can be challenging to build.
Teams love to embrace complex problems with technology and complicated design. As an agile leader, you must insist on simplicity. You must insist on delivery of initial products with the least possible technical complexity. Software developers with years of experience will often be so focused on the complexity of a problem that they cannot find a simple trial solution to test their assumptions. As a leader firmly encourage the team to dig deep and find the simplest approach.
Enforce Simplicity with Time Boxed Iteration
A two-week delivery cycle can be a huge alley because you as a leader will also ask for a working product in 2 weeks. This requires some very creative thinking for highly complex software problems.
When a team is constrained by 2-week cycles and is challenged to make a working system, the creative juices flow and the results will be tremendous LEARNING and often a simplistic solution.
There are probably a dozen counter points to the statement above.
“Doesn’t forcing a team to delivery so quickly create technical debt?”
The answer is yes and no.
The other thing that you need to be willing to do as an agile leader is be willing to pay for things to be REDONE a little.
Teams often tell me, “If I do it that way, I’ll have to rework some of it later.” I respond, “I’m willing to pay to have it redone.”
Why am I willing to pay for some rework? Because a working system gets’s me the LEARNING I need. When I need to test an interface for a customer who doesn’t really know what they want, I need to put aside the complex system and give them a minimal working system.
In Lean Manufacturing, when you have inventory in the warehouse rather than in customers’ hands, it’s considered waste.
I view software in the same terms. If I have half done super optimal software that meets tomorrow’s needs and it’s not released until tomorrow, then I’m wasting today.
Optimize your design by using short cycles and simplicity.
Change Barrier #3: Lengthy Deployment Cycle
When making paper airplanes, how upset are you when you need to change the design?
Probably not too upset. If fact you’ll probably just re-make it from scratch with the new design element.
When you make a scale model airplane, how does a design change affect you?
It’s harder because it could require dismantling the fuselage or rebuilding the tail section.
The model airplane took many man hours to build and it is harder to test changes.
Make it About Development, Not Deployment
I try to keep my teams focused on development instead of deployment so that we can make changes on the timeline of the paper airplane.
Having a change that they can deploy to different environments in 5 minutes makes it easy to introduce change late in the development cycle.
Optimize for deployment right of the bat and always keep it optimized
What is your biggest barrier when a customer asks you to change something?
Leave a comment, I’d love to hear your input.