In talking with people that are new to the idea of iterative and incremental development, this is often the most common thing I hear.
"We can't deploy anything until we have everything done"
Of course, this raises the stakes, because you don't get an opportunity to learn about what your customers want. You can easily gold-plate something that doesn't fit the need in the market, ending up months or possibly even years behind your competition. Even in a regulatory environment where you feel everything is spelled out for you, there's often quite a bit of room to be innovative or deliver incrementally.
There seems to be this belief that people don't want products unless they have all of the possible bells and whistles, especially in an established market or product. But I think there's an amazing case study to evaluate the veracity of this claim, and it's hiding in plain sight.
Tesla has been developing the Model 3 software in a very iterative and incremental way since they rolled it out. The first group of cars delivered to their owners didn't even have FM radio enabled! If you wanted to listen to music in your shiny new $50K+ car, you had to do it through your phone's Bluetooth connection. The next thing was that didn't exist was an intermittent wiper setting, you could only use the auto wiper feature, low, medium, or high. In true learning organization fashion, they received a tweet from a customer informing them that when they open the door in the rain, the wipers kicked on, soaking them, and the door of the car. The next software update addressed that problem. They've even made it incredibly simple for you to provide feedback, no going to the website, sending an email, or anything that droll; simply say, 'bug report' and articulate the nature of the problem, and it's logged. Simple, easy, real-time. The car has been steadily improving since the day it rolled off the assembly line, and guess what? People love it.
People are in love with the idea that the product they paid for is continuing to get better and better. And Tesla has shown with the Model S and X that they will continue to update the platform as they think up more things that the cars can or should do. It's no wonder that Tesla is valued so highly, they're doing something that no other automaker is capable of doing right now, and that's making the product you buy, get better over time, instead of being stagnant.
I think that Tesla has demonstrated, in an existing, highly competitive, and regulated market, they're able to innovate and deliver in an iterative and incremental fashion. The question you have to start asking yourself when you say it can't be done for you, "What's keeping me from doing that?" and then take a very hard look at the answer. Are those reasons really real? Have you tested them to see if they're actually valid? What's the actual likelihood that any of them will come to bear? If they're not real, then try it out! Figure out what the minimum work you have to do is, then give it to your customers and see how they are using it, learn from that, then build the next version to improve it.
One thing that we learned from Google’s Project Aristotle is that the highest performing teams have a single thing in common. What is that thing, you ask? Safety. Not safety as in they are in physical danger, but a far more difficult to measure safety, psychological safety. This is the safety to speak up without fear of retaliation, the knowledge that we can disagree and it’ll be ok, that the truth is not just welcome, but expected.
When joining a new team, creating safety is imperative to ensuring a great working environment, but how do you do that with a bunch of strangers you’ve never worked with? How do you create an environment where you know how to argue effectively with each other? And most importantly, how do you create a space where you aren’t just the other resources on the team, but you’re a human being with aspirations, goals, desires, hurts, and all that goes with it?
The quickest way to create that connection, is to help people understand who you are, and you to understand who they are. Where did they come from? What are they proud of? What are they not so proud of? What made them happy? Are they happy now? This is all incredibly valuable information that helps you create a bond that’ll allow constructive disagreement. To get to this, there’s an incredibly powerful tool, Journey Mapping (it may have also been called empathy mapping).
The idea is this, draw a graph with the x-axis being time and the y-axis being happiness. Draw a line across indicating that it’s not happy, not sad, more like, ‘meh’. Now each person independently starts at whatever point they choose, it could be early childhood, it could be their first job. It’s up to the facilitator to set the rules, but the more open you are here, the better everyone will know you. From here, you put a dot on the graph for each event that you can think of, be it happy or sad. Once you’ve caught up with today, connect the dots, and add any kind of embellishment you choose, draw pictures, make frowny faces for the unhappy incidents, get creative! This is your opportunity to show your personality, so go bananas!
After the drawing period is over, each team member takes the whole team through their graph, telling them about why there’s that three your trough after your second job, and why you left the job that had you at the peak of happiness. How did you arrive here, at this very moment, in this room, at this company? The team can ask questions as they learn about you, and before you know it, you’ll find lots of laughter in the room. This is the first step in creating team safety.
With this grounding in a shared understanding of where you come from, the team will more quickly start to gel and work together more easily. It’ll open up the team, accelerating the transition through the Tuckman stages from forming through storming and into norming.
Try it out with your team and let me know how it goes!
It's said that the best teams can perform up to 20 times better than the average team. How can that be? Is it people? Process? Tools? What are they doing that hasn't already been learned and exploited by everyone else.
Join us for a lively, interactive discussion where we share stories from our teams' experiences both good and bad and reveal what we've learned about team performance and lessons you can take back and share with your organization.
Complimentary lunch will be provided.
Mon, June 4 11:30 AM - 1:00 PM Downer's Grove, IL REGISTER NOW!
Both Amazon and Windows Azure now offer dozens of services upon which to build amazing technology solutions. Navigating this array of code named, ever evolving capabilities can be dizzying. And what about the promises they made to us? Reduce your data center footprint. Lower your costs. Get more resiliency. Be more secure. Solve bigger problems. Do they live up to these promises? Do both vendors have equal parity at this point?
Bring your questions and join us for a lively, interactive session where we separate fact from fiction and share our hard learned lessons about what's working and what's not in cloud computing.
Complimentary lunch will be provided.
Tue, May 22 11:30 AM - 1:00 PM St. Louis, MO REGISTER NOW!
Microsoft is working Polaris and other partners around the central US region to put together free workshops focused on App Modernization and are designed to help developers get hands-on with Azure. These events will focus on the most popular Azure PaaS and DevOps offerings. Each technical session will be followed by a whiteboard design exercise to encourage attendees to take what they’ve learned and design solutions in Azure.
This 1-Day workshop will focus on most popular Azure PaaS and DevOps services. Each technical session will be followed by a hands-on Azure lab and a whiteboard design exercise. This workshop will help you gain a thorough understanding of the components of Azure and how you can take advantage of them as a developer.
Page 1 of 10