Wish your software development process flowed smoothly and your team loved their work?
Looking for a way to win with smaller IT investments that get better software?
Want to get more control of what IT delivers, without micromanaging or massive investments in IT overhead and digital transformation efforts?
Sounds too good to be true, right? A great idea alone isn’t enough to build great software. Add in the lean practices shared in this article, however, and you will be able to say “yes” to all three of these questions.
All too often tech start-ups build a product from an inspiring vision and launch the MVP, only to find themselves struggling through pivot after pivot, scrambling as their revenue doesn’t reach their goals. Burnout sets in quickly for these teams, and bankruptcy is far too common an outcome. Even if the MVP goes well – there’s a huge risk growth will stagnate as the team struggles to manage priorities across maintenance work, new features, and scaling up system infrastructure to support customer growth.
Meanwhile many enterprise IT programs have long cycle times on delivering new features to production – often discovering far too late the delivered software doesn’t meet the need. IT leaders have to fight for needed funding to build new features the business demands while also maintaining legacy systems. Teams become disengaged and demotivated, perhaps occasionally, begrudgingly, mustering courage for a heroic push to meet a deadline or solve an emergent production issue.
Getting from concept to cash, with software that delights customers is… challenging at best. One Stripe study found developers spend over half their time on maintenance issues and bad code, rather than enjoyably and efficiently building valuable features. This translates to a loss of approximately $300 billion in developer productivity every year. Along with the economic losses, the amount of wasteful work is discouraging – turning software work into drudgery.
At Integral, we know it doesn’t have to be that way. Our lean agile software development practices are designed to solve complex problems, build great teams, and deliver exceptional products – all while putting people (customers and team members) first.
Practices that deliver outcomes, for customers and your team, at any scale
We love our practices because they deliver the results our clients and teams need most: high-quality valuable software for customers and enjoyable, purposeful, motivating work for IT teams.
At Integral, we use discovery & framing tools to explore a client’s desired outcome, map the opportunity space within it (i.e., what opportunities are there to delight customers?), identify potentially valuable solutions, and gather evidence about what will and won’t work. From there, we use inception to hand off solution development to delivery teams. Our inception tools give teams clarity on the solution they’re developing, and the opportunity it aims to capture. They also set a clear roadmap of lean-slice features for the engagement, building up highly valuable working software that achieves the client’s desired outcome.
Our roadmap strategy prioritizes experiments that derisk our most important hypotheses about which solutions will help customers most. With small adjustments for different contexts, we’ve found these practices work just as well for our clients’ in global-scale enterprise platforms as they do in early-stage start-ups.
This means we can deliver to clients (and their customers) the first real working software features within a few weeks of starting work – and these first features address the most important aspects of the desired outcome.
By putting production software in front of customers within weeks of launching work, you get market feedback on if you’ve truly identified a customer migraine and how well your solution gives relief from it. At the same time, the delivery team enjoys clarity and motivation. The roadmap makes clear to them the product vision. Every day they see their decisions and work delivering the vision. Week-by-week the team sees their work get meaningful stakeholder feedback, create valuable learnings, and have a positive impact on production customers.
Speed-to-market enables speed-to-value. Each feature delivered allows stakeholders to make decisions about upcoming features based on their own (and customers’) experience of working software. This tightens the feedback loop between customer experience / willingness to pay and the work of the delivery team.
Because of this, rather than waiting months (or longer) to revisit strategy and design decisions, we’re able to pivot with clients as soon as we receive customer feedback. We can immediately apply customer feedback into designs and acceptance criteria of upcoming features. Where new needs are discovered, we can quickly design, prioritize, and deliver new features.
Our approach results in reaping customer value within weeks of inception. Each week, the team and stakeholders can also make evidence-driven decisions that optimize the value being delivered. The delivery team no longer feels like an order-taking feature factory on a death march to a goal that someone set months (or worse yet, years) back. Instead, each person becomes a strategic business partner. Everyone is derisking assumptions, gathering learnings, looking to see the impact of the most recently delivered work, and accountable for helping decide how to apply learnings to deliver even better results in the next features.
At the root of a lot of awful software out there is the process used to create it. A longer trudge from idea to software in front of customers doesn’t just decrease the likelihood of delivering high-quality software; it also increases costs and therefore lowers ROI on IT investments. Speed-to-market and speed-to-value cut through this slog – allowing teams to have more fun and clearer purpose because they’re seeing customer-facing production results every week.
By consistently repeating these practices, the business can achieve outsized results from its IT investments. IT and the business circle up every week and make meaningful decisions about new features and/or system improvements. Lean practices enable clients to fine tune the return on their software investment – actively managing how much is invested and the desired outcomes the investment is directed toward. The development team is focused on building software that helps the business win now and in the long-term. Because they have weekly visibility into business priorities, the delivery team is able to be accountable to designing and delivering software that customers love and that makes money for the business, not mindless just order-taking. Lather, rinse, repeat… profit.
Making lean practices serve your context and constraints
Leveraging lean practices to get more from traditional scaled agile
Lean development practices are a subset and evolution of core agile. It’s easy to pit lean against the “evils” of waterfall delivery, but I increasingly find this is an unhelpful strawman and cheap punching bag. Large organizations need ways to manage multiple products – or even platforms of products – and dozens of delivery teams. Complex integrations & dependencies, marketing pushes for new features, and foundational infrastructure work all need to be planned for success. Even smaller orgs and start-ups need at least some level of near- and far-horizon coordination.
Traditional agile and scaled agile approaches help do exactly that. The lampooning of the waterfall approaches they result in isn’t without merit though. Lengthening feedback loops make it hard to focus on the desired outcome, much less being mindful of how each feature builds toward it. When software takes months (or years!), to get from idea to production customers, it’s hard for the IT team or the business to be responsive about what they build, much less stay motivated and engaged in how they work. And so sets in the drudgery for teams, and the awful software for customers.
However, lean software development is not incompatible with traditional agile and scaled agile. Our teams regularly win in these kinds of IT programs by infusing our practices into the larger management system. We recognize our role in a broader program that is delivering multiple complex features and products over a long period of time. We work with stakeholders to clearly define which thin slices of value we are delivering and how they help build up the bigger vision. We then demo the results every week or two, getting feedback and working with stakeholders to refine upcoming requirements. Often using these lean practices also helps with coordination and integration work because other teams can see and respond to real software features as we demo them.
The key, if you find yourself in a larger IT program, is building tools into your agile system that hold teams accountable to incremental speed-to-market, speed-to-value, and ROI optimization throughout a longer delivery cycle. These tools ensure each team and product still functions with accountability to lean practices. You might enjoy this webinar on writing better requirements or this one on backlog practices if you’re looking for more ideas here.
Lean makes outsourcing software delivery more effective
In today’s world, almost everyone needs software to run their business – perhaps it’s a modernization of your digital commerce site, building middleware to manage your customer data, setting up an operations dashboard to help you make data-driven decisions, or integrating your CRM and project management tools. The reality, though, may be that you simply don’t want to be in the business of optimizing IT management. You’re not alone. Outsourcing software delivery efforts provides the promise that none of the challenges described in this article are your problem anymore, right? To an extent this is true, but caveat emptor. Putting a third party on the hook for delivering valuable software doesn’t erase the risk that you might not end up with the software your business needs. You can easily waste a lot of time and money wrangling with sub-par results from IT service providers. Even if you reject what they build and find a way to not pay them a thing for it, you’re still months or more behind on getting valuable software in front of customers and/or team.
Applying lean practices to software outsourcing means writing thinner contracts and keeping tight feedback loops with service providers. We often take on scoped delivery for clients. We aim to start with a contract for a highly valuable chunk of software that we can deliver in a few months or less. Within those few months, we’re meeting weekly or daily with the client, coordinating asynchronously, demoing working software as it’s built, and gathering feedback. Clients also regularly help us refine requirements for upcoming features and stories. This increases everyone’s confidence that we understand the needs, and allows us to adapt based on what we’re learning as we build the software. We keep this lean by only using a few hours of the client’s time each week.
When you outsource software development, protect your investment. By using a lean process with your IT service provider you get the benefits of speed-to-market, speed-to-value, and ROI optimization in your delivered software – while still having your IT service provider take significant IT management weight off you.
Next steps for leaning out your IT practices
Looking to get more traction by applying lean practices to your dev work? There’s a lot of great resources out there to help you develop your lean thinking and practices: Lean Start-up (Ries) has become a canonical read. Inspired (Cagan) provides even more specific wisdom and tools for IT teams. Continuous Discovery Habits (Torres) is a newer favorite of mine.
Want a thought partner on how you might infuse lean practices into your IT delivery and/or identify and run lean experiments to find out how to turn your concept into cash? Shoot me an email (email@example.com) or sign up for a FREE Integral Product Success Lab. We’d be honored to help you discover how lean practices can turn your ideas into highly valuable working software.