Blog

Is The Tesla Model 3 A Lean Mean Driving Machine?

By: Agile Velocity | Apr 11, 2016 |  Article,  Kanban,  Lean

Tesla unveiled the next addition to its premium electric vehicle family, the Model 3, last week. At $35,000, Elon Musk made good on his promise for an “affordable” EV option and the public has responded by exceeded expectations for the slow rollout. According to Bloomberg, there are more than 325,000 reservations giving Tesla Motors Inc a nice $325M cash asset infusion. Implied future sales make it the “single biggest one-week launch of any product ever,” according to the company’s blog.

Even though the EV will not be available until late 2017, buyers reserved their very own Model 3 for $1,000 pre-test drive.

Is this Lean in action?

It’s an interesting situation that we’ve analyzed as outsiders** and Lean advocates. In Lean Startup, you eliminate uncertainty around your product by testing your hypotheses. The product becomes an experiment that is tested instead of something that is slaved upon, tweezed, tweaked, and perfected. Deliver value, get feedback, adjust, deliver.

We’re not saying that Tesla is a startup but looking at how it’s launched its latest product, it has similarities. Instead of creating 400,000 cars at a very high cost (one battery is about $10,000), they created a few for the launch and then began to take orders and therefore gauged interest.  

Does Tesla now have $375M in revenue? Car and Driver explains that each reservation is completely refundable and it’s not counted as revenue until the car is delivered. Tesla will use the deposit money for launch and operating expenses but all of that cash is technically considered a debt.

With Tesla knowing that there is sufficient interest in the Model 3 and money to help with the rollout, it’s a safe bet to say the next two years looks pretty good for the company. In Lean Startup terms, they conducted an experiment, learned that their consumers are interested, and at the same time managed to bankroll their launch. Not too shabby!

Blog

Shorten Feedback Cycles

By: David Hawks | Aug 13, 2015 |  Article,  Lean

Shorten feedback cycle through Execution and Product DiscoveryPart 3 of 6 in the “Double the Value in Half the Time” series based on David Hawks’ presentation from Keep Austin Agile 2015. Stay tuned for subsequent posts…

The third problem holding teams back is long feedback loops. Some of us have long feedback loops, while others have no feedback loops at all! And therefore we’re not learning. We’re not getting new information.

Eric Ries’ “The Lean Startup” challenges the way we think about developing products.

Picture two loops happening at the same time. Most of the time we’re focused on the execution loop:  How do we execute? How do we deliver software faster? How do we do it with higher quality? How do we shorten feedback cycles? How do we increase productivity?

But there’s another loop we haven’t talked about enough – the product discovery loop. Are we building the right product? What product should we be building? What features should we be building? While both of these are happening at the same time, many times it seems the Product Owner is off on an island and is supposed to just guess what product to build and then the developers iterate on building it over here in the execution loop.

Eric Ries says to think about everything we build as a science experiment, not a requirement. We hear the word requirement and we assume it’s a fixed factual thing. It’s a requirement! But really, a requirement is nothing more than a hypothesis. If we build this thing, we expect that outcome. We got really good at coming up with an idea and building it, delivering the product, going to the next idea. That was our loop. But are we building the right product and features? We should be measuring and learning from it. I like to think of it backwards – What do we need to learn? How are we going to measure that we’re learning? What’s the needle we’re trying to move? What’s the smallest thing we can build or test?

Shorten feedback look through validated learning
There’s a story about a debate at Amazon where a group is discussing features and initiatives and what’s going to make the most money. Part of the conversation went like this:

     "Let's just put a link to the website on the homepage."
     "But we haven't build the website yet!"
     "I don't care."
     "What's it going to do?"
     "Go to a 404 error."

They did just that and… nobody clicked the link. Do they need to build that feature? No! If people started clicking it, they could take the link down and go build the website. They built a minimal feature, measured its use, and learned that it was not worth investing the time and money to continue building on it.

Indeed has a lot of stories around product discovery in their blog. Last year they recorded a bunch of videos around how they’re doing experiment-driven development. Data-driven development is what they’re calling it. They’re running over 100 experiments at any given time, things are always changing. They’re trying to discover what’s the smallest thing we can build to experiment with and learn from, to validate or invalidate our hypothesis?

Eric Huddleston runs TrendKite. He is a smart dude who says our job is to figure how dumb we are as fast as possible. Because everything we’ve convinced ourselves is right, our “perfect” requirements? Most of those things are wrong and it’s a lot cheaper to figure that out before we’ve written all the code, integrated, tested, and released it. And that’s usually when we find out if we’re wrong… if we ever do.

Next topic in the Double the Value in Half the Time series: Focus!

If you’re still not seeing the value from your Agile investment, you might benefit from an Agile assessment. One of the benefits of an Agile assessment is understanding where teams are now, in terms of key capabilities, so that you can create a backlog (next steps) for your transformation. Go here to learn more about Agile assessments.

Blog

Building Shared Understanding: The Document Revolution in Product and Software Development

By: Agile Velocity | Mar 19, 2015 |  Article,  Lean

Three people think they all agree, but don't - Product and Software DevelopmentThere is no doubt that the in-vogue tool today in product and software development is the “canvas”. Everywhere you look a new version appears touting new value and insights: Business Models, Opportunities Assessments, Organizational Visioning, and Sales Strategy. It seems like anything can be made into a canvas!

Canvases are the consequence of new innovative practices challenging the status quo of established organizations and social rules of how to run a business. It is a sign of the transition from traditional document driven product development to innovative and collaborative product development.

Organizations are challenged by what it means to get an agreement and ultimately shared understanding. In traditional product development organizations, shared understanding is created through charters, documents, lists, plans, charts and other formalized and signed documentation which tried to create a sense of tangible shared understanding.

“If we write it down, email it around, have a meeting and sign off, then we are in agreement!” Sound familiar?

No surprise that agreement is later fraught with misunderstandings and confusion about how the “agreement” translated into the real product itself. Let alone the lack of ability to deal with new information along the way that doesn’t fit into the signed off documentation, which quickly becomes not a document about shared understanding but a weapon in the war of who’s fault is it this time.

Today, it’s not about having a document proving an agreement. It’s about whether we actually have created a shared understanding of what we want to accomplish and how.

The collaborative act of building a canvas as a team (this is not an individual activity owned by one person) builds shared understanding leveraging ALL types of learning styles, (Visual, Audible, Reading/Writing, Kinesthetic), thereby maximizing collaboration, understanding, and innovation. Now, our “documents” are “vacation photos” representing the journey a team takes together with an idea.

Canvases have become a new standard replacing the traditional agreement document. A quick, easy and collaborative tool used with a team to create a solution together leaving them with some visual history of where they ended up and where they need to go next.

Basics of a Canvas

The idea is pretty simple; there is no magic to creating your own canvas. Take an old approach to find agreement (document passed around) and find a way to build it visually. Check out a canvas below for a way to lay it out. Visually solve the problem together as a team on a white board (can fit on a picture or a smaller one-page document later). Use it as a team DURING a meeting to get closure on circling discussions. Come to agreements and action visually–organized in a visual layout (not a list). Leverage all four types of engagement. (Visual, Audio, Reading/Writing, Kinesthetic)

Stop trying to collaborate with only words.  Visualize it.  Canvases can help meet the challenge of documentation that fits the fast paced and innovative product environments of today.

 

Here are a few of the original and most popular ones that started the movement.

http://www.businessmodelgeneration.com/downloads/business_model_canvas_poster.pdf

http://www.businessmodelgeneration.com/downloads/value_proposition_canvas.pdf

https://leanstack.com/LeanCanvas.pdf

 

Join me in the upcoming Lean Product Discovery workshop.

Blog

Lean: Purity vs. Pragmatism

By: Agile Velocity | May 19, 2014 |  Article,  Kanban,  Lean

Leaning water tower - agile and lean “That’s not Agile and Lean!”

“We’re not being lean enough.”

“We’re not supposed to make deliverables!”

Sound familiar?

Agile and LeanI hear these statements all the time from teams moving towards a more evidence-based approach to product discovery, conception, and production. Somewhere, someone made a decision for the teams to now “do Agile & Lean” and so, books were bought, conferences attended and index cards purchased. The teams set off with a healthy mix of trepidation and optimism and began practicing the newly learned processes – visions of stand-ups, post-it notes, IPM’s and validated learning in their heads.

Except it’s never that clean.

Something gets in the way. Something gets in the way – reality. Reality consists of:

  • The client (or stakeholder) who doesn’t really understand what being agile actually means demanding roadmaps, and sitemaps, and journey maps and story maps.
  • The project budget, which is allocated not just for discovery but also for actual production of a software application.
  • Distributed teams who struggle to maintain transparency and real-time conversation.
  • Experiment results that don’t give a clear indication of next steps.
  • Technological constraints that won’t allow production-level scaling of the optimal solution.
  • A corporate culture that frowns on failure and makes collaboration difficult

And so much more…

What is the newly minted Agile/Lean team to do when faced with these harsh realities?

Do you push through, sticking only to the fundamentals in the books and tutorials hoping things will work out? Or do you take the pragmatic approach and adjust as needed to accommodate the realities on the ground?

The answer, of course, is the pragmatic route. Each project, team, product, company, industry and market brings with it its own context. These contexts demand a unique approach that can’t be predicted in a book or manifesto. The frameworks articulated in those books are starting points. Once they get wrapped in these contexts they will inevitably morph.

And that’s OK.

Ultimately, what you really need is to ship product. Lean and Agile will help you gather evidence, determine more successful paths, produce working software faster and build a shared understanding between your teammates, clients and stakeholders. Start with these philosophies. Use them to build evidence, insight, direction, learning and value. But keep this in mind – there is no scale for agility or lean-ness. There is no such thing as not being “lean enough” or “agile enough.”

Jeff Gothelf author of Lean UX - Agile and LeanThis blog article is reprinted with permission by Lean UX author, Jeff Gothelf.

Jeff Gothelf is an agile product designer, teacher, writer and team leader. He is one of the leading voices on the topic of Agile UX and Lean UX. In addition, Jeff is the author of the O’Reilly book (2013), Lean UX: Applying lean principles to improve the user experience. He is a highly sought-after international keynote speaker, workshop leader and trainer. Currently, Jeff is a Principal at Neo Innovation in New York City.

Blog

Building In-House Agile Innovation Teams: Transparency

By: Agile Velocity | Apr 29, 2014 |  Article,  Lean,  Team

Transparent bubble - Teams transparencyIn the first post of the series, I discussed the basic building blocks of a successful in-house innovation team: small, dedicated, collocated, and self-sufficient. In this post, I’m going to talk about a key philosophy for these teams: transparency. It’s not in our nature to be transparent in the business world (or in the personal world for that matter). From the baseball diamonds of little league to the lecture halls of business school, we’re taught to be competitive and to push ahead of our colleagues. After all, it is our individual ideas and skillsets that define the quality of our work and our discipline and set us apart from our colleagues. How can being transparent – with our thoughts, our tools, techniques, and ideas – possibly help us excel as individuals, as a team, and as a company?

Transparency at the individual level

Lean UX by Jeff Gothelf - Discusses Teams Transparency

The first place to start, as with all of life’s improvements, is with you. Regardless of your core competency – design, engineering, management – sharing your ideas and techniques with your team early and continuously brings a whole host of benefits.

Validation of your ideas – making your ideas public early gives the team a chance to weigh in and provide their insight into the feasibility, relevancy, and validity of your thinking. This, in turn, saves you time by keeping you from exploring ideas that don’t align with the team’s vision or scope.

Collaboration – the act of sharing by itself begins a dialogue with at least one other person on your team. As that conversation, and that technique, spread beyond that initial action a spirit of collaboration takes root. In addition, you are seen as someone to whom others can seek out for feedback and further collaboration.
Thought leadership – transparency shows you’re actually getting work done (we all knew that, but it can’t hurt to show it). If you’re working on the project then you’ve likely generated ideas on how to approach it or solve the current problem. This paints you as the “idea person” and someone who has put in the time figuring the challenge out.

Source of inspiration – Your ideas, now visible to everyone on the team, serve as a starting point for feedback and discussion as well as inspiration. Teams react to initial ideas, even if they’re straw men, rather than blank whiteboards. In addition, your efforts at being transparent may inspire others on your team to be more forthcoming with their early thoughts.

Transparency at the team level

Teams, especially those trying out new ways of working, benefit greatly from open-sourcing their processes. In many ways, without even trying, transparent teams become mini-R&D units for new thinking, processes, and products. This recognition would be far more difficult to come by if the team closely guarded their internal IP. In addition, team transparency brings:

An awareness of new techniques – if some of your colleagues could benefit from a new customer interviewing technique you’ve used or a way to measure the impact of certain architectural changes, hold a brown bag lunch, and demo your new technique. Letting others see what your team is doing and how it’s working (good, bad, or otherwise) saves them the time it would take to learn those things on their own.

Consistent status updates for managers and above – nothing makes managers more anxious than not knowing what their team is currently up to. Using techniques like daily standups, weekly status updates, information radiators reporting back on the team’s success metrics, and weekly demos your managers will always be ready to answer their boss’s questions about your progress – which will keep them out of your way. Nice.

Comfort with a team’s progress (especially if measured differently) – I talk a lot about lean teams and how they should be measured against business outcomes, not a specific output. This new way of measuring is difficult for managers since it is not binary (e.g., did the feature launch or not?). By ensuring your team is consistently communicating their progress against their targets (even if the progress is not good) it gives your manager a sense of how you’re progressing. In addition, it’s important to let your manager know what you’re working on this week, what the backlog holds for the next iterations, what you’ve learned in your recent experiments and what you hope to test next.

Reduction in roadblocks for colleagues and other departments – the marketing department wants to know when you’re launching new features. The customer service folks need to know when workflow updates are going live. These folks are not trying to get in your way. They’re trying to do their job. Make it easy for them (and for you) by always communicating to them what you plan on releasing, when, and how it will affect their day-to-day work. This holds true for any department that’s dependent on the product you’re developing.

Greater sense of pride and accomplishment – if your team succeeds and has been transparent about how they succeeded, they can continually point to those successes as proud accomplishments. That sense of pride is contagious. Other teams will want it and will reach out to your team to understand how you did it and perhaps even ask you to help train their crew.

Transparency at the department level

The word department is often synonymous with the word silo – especially a discipline-specific silo. There are other types of departments though – usually product lines or industry verticals serviced by the organization. Transparency at this level – regardless of the type of department you work in – can have a dramatic impact on the way the organization perceives your department as well as the impact you can have on the organization itself. By making the company aware of the processes your teams follow, sharing insights into the specific tactics those teams use, and broadly posting the various teams’ progress towards specific business objectives your department can become a vision of what the future holds for the rest of the company. Let’s take a look at some specific impacts.

Hiring brand – every department wants to hire the best practitioners. Being transparent about how you achieve great results, what kind of empowerment employees have, and how everyone is measured and rewarded indicates a level of trust that many A-players value. It clearly indicates that your department does not micromanage and allows employees to push boundaries without fear of retribution.

Thought leadership – as the organization learns more about what your department does and how it’s faring in its business efforts the perception grows that this is the department that is leading the organization both on domain expertise as well as process.

Greater effect on company/product strategy – the mythical “seat at the table” becomes a far more realistic achievement for your department when your leadership understands what it is you do and how you do it. In addition, there is a greater confidence in the strategic suggestions your department makes to the organization because it is based on widely-available learnings you’ve socialized internally.

Transparency at the company level

Transparency at the organization level works in two directions – internally to your employees and externally to your customers. For the purposes of this article, I’m going to briefly focus on internal transparency. For external transparency and other insight into how to build successful companies you should read Dave Gray’s The Connected Company.

Internal transparency gives your employees a clear sense of how the business is doing and how their work is impacting that success. It motivates them to fix problems they can clearly see impacting revenues, customer satisfaction and other success metrics. It demystifies the “executive layer” and shows the rationale behind the decisions that come down from the C-suite. Finally, it encourages employees to be good corporate citizens and to dig into business intelligence data to find opportunities for improvement or to diagnose the root causes of problems they are tasked with fixing. Ultimately, it shows your teams that the company’s leadership trusts them.

Successful innovative teams and companies share their learnings. They share their successes and their failures. They’re honest about what they’ve tried and what they’ll try next. They build collaborative eco-systems that feed fast learning cycles and cross-pollinate innovative insights across the organization. It’s this transparency – at the individual, team, department, and company levels – that empowers innovation teams to succeed.

This blog article is reprinted with permission by Lean UX author, Jeff Gothelf.

Jeff Gothelf is an agile product designer, teacher, writer, and team leader. He is one of the leading voices on the topic of Agile UX and Lean UX. In addition, Jeff is the author of the O’Reilly book (2013), Lean UX: Applying lean principles to improve user experience. He is a highly sought-after international keynote speaker, workshop leader, and trainer. Currently, Jeff is a Principal at Neo Innovation in New York City.

Blog

7 Principles of Lean Software Development

By: David Hawks | Apr 19, 2010 |  Agile,  Article,  Lean

I recommend reading Implementing Lean Software Development by Tom and Mary Poppendieck. They do a good job of breaking down the 7 Principles of Lean Software Development into some very easy to understand concepts. Here is a taste of what this book will open your mind to:

Principle 1: Eliminate Waste

  • Waste is anything that interferes with giving customers what they really value at the time and place where it will provide the most value.
  • Inventory is waste – In software that is partially done work
  • Churn – Requirement Churn, Repeating test/fix cycles
  • Many times caused by large inventories of partially done work
  • When requirements are specified long before coding
  • When testing occurs long after coding
  • Delayed integration
  • Overproduction – Extra Features
  • Only about 20 percent of features in custom software are regularly used (66% are rarely used)

Principle 2: Build Quality In

  • You don’t focus on putting defects into a tracking system; you avoid creating defects in the first place.
  • Defect tracking systems are queues of partially done work
  • TDD and Continuous Integration
  • Write Less Code – Keep the Code Base Simple
  • Expect to change existing code
  • Refactor often

Principle 3: Create Knowledge

  • Software is a knowledge creating process
  • Validation of architecture comes as the code is being written
  • An early design cannot fully anticipate the complexity encountered during implementation
  • Expect the design to evolve
  • Early release of minimum feature set to customers for evaluation and feedback
  • Daily builds and rapid feedback from integration tests
  • A modular architecture that supports the ability to easily add new features
  • Encourage systematic learning throughout the development cycle
  • Stop acting as if our predictions of the future are fact rather than forecast. Instead, we need to reduce our response time so we can respond correctly to events as they unfold

If you want to begin implementing Lean and Agile principles, learn about your adoption options with our infographic, Implementing Agile.

Principle 4: Defer Commitment

  • Schedule irreversible decisions for the last responsible moment
  • We should try to make most decisions reversible
  • We should avoid making decisions that will lock in a critical design decision that will be difficult to change
  • “In preparing for battles I have always found that plans are useless, but planning is indispensable” Dwight Eisenhower

Principle 5: Deliver Fast

  • We need to figure out how to deliver software so fast that our customers don’t have time to change their minds
  • Companies that compete on the basis of time often have a significant cost advantage
  • Eliminated a huge amount of waste
  • Low defect rates
  • Repeatable and reliable speed is impossible without superb quality
  • In fast-moving organizations, the work is structured so that the people doing the work know what to do without being told and are expected to solve problems and adapt to changes without permission

Principle 6: Respect People

  • Entrepreneurial Leader
  • A company that respects its people develops good leaders and makes sure that teams have the kind of leadership that fosters engaged, thinking people focused on creating a great product
  • Expert Technical Workforce
  • Appropriate technical expertise is nurtured
  • Teams are staffed with needed expertise to accomplish their goals
  • Responsibility-Based Planning and Control
  • Teams are given general plans and reasonable goals and are trusted to self-organize to meet the goals

Principle 7: Optimize the Whole

  • A lean organization optimizes the whole value stream
  • Vicious Circle #1
  • A customer wants some new features, “yesterday.”
  • Developers hear: Get it done fast, at all costs!
  • Result: Sloppy changes are made to the code base.
  • Result: Complexity of the code base increase
  • Result: Number of defects in the code base increases
  • Result: There is an exponential increase in time to add features
  • Vicious Circle #2
  • Testing is overloaded with work
  • Result: Testing occurs long after coding
  • Result: Developers don’t get immediate feedback
  • Result: Developers create more defects
  • Result: Testing has more work. Systems have more defects
  • Result: Feedback to developers is delayed further. Repeat cycle.

If you are looking for a basic introduction to Lean Concepts I would recommend reading the Goal.

 

 

What’s Your Organizational Agility Score?

In less than an hour, you’ll get valuable insights into your organization so you can improve team performance and achieve your business goals faster.

Learn more