This curated post is by Cauri, Instructor at Rhubarb Studios, Los Angeles
Framework madness! Alongside the plethora of new tech startups created over the last 20 years, there’s been an abundance of pundits promoting different methods to develop products, ideas and companies. I see entrepreneurs struggle with these choices all the time, and I even developed Startup School to guide them through these choices in the early stages.
Enterprise product managers and startup entrepreneurs alike struggle to keep up with the latest trends. Which method is best? And why? Many people — overwhelmed — ignore the trends altogether and use the same practices that they have used for years, even if outdated. Some people become dogmatic about one method; and some pick and choose from bits of each.
I’ve worked with them all. Here, I outline what’s involved with each framework and philosophy, and make suggestions for which to use.
We see the same underlying two ideas in all of these:
Iterative software development
How to create technology that we can build, test and release in small parts rather than building the whole thing and releasing it all at once.
User centered design (UCD)
UCD looks at designing all products (not just technology) to make it easiest for human use. This may seem obvious, but we build a lot of software by making it easy for the computer, the browser, the infrastructure, the engineer or the sales team — UCD looks to focus on the end user and do what works best for them at all stages of the product process.
So — let’s look at these frameworks (as jargon free as I can manage).
Multi-disciplinary, design thinking teams use a suite of tools to approach users, analyse needs and discover opportunities. Traditionally, design thinking can be a long process leaving lots of time for guided exploration and brainstorming.
Key design thinking tools
- interview for empathy
- empathy map
- why-how learning
- prototype to test
Benefits of design thinking
- demystifying innovation
- team cohesion
- highly creative outcomes
Common fears of design thinking
- long discovery timeline
- unexpected results
- talking (a lot) to current users
Companies using design thinking
Lean product development focuses on gradually evolving a product based on continuous empirical market feedback — testing every new idea and every assumption with users daily.
The Lean mindset starts by creating a small initial set of features (Minimum Viable Product: MVP) and getting end-user validation early on. It then continues to iterate on the product in tight build-measure-learn cycles. The product team prioritises features and direction as user feedback comes in.
The Lean startup process, adapted by Eric Ries for tech startups from Toyota’s lean manufacturing, has grown into the defacto way of developing early-stage startups, products and technologies. Many people, such as Ash Maurya, have added tools to the original process. On the other hand, many business managers debate its effectiveness.
Lean connects metrics directly to product development. This means that teams can directly see the effect of a new feature on the bottom line of the business finances.
Lean startup process does not suit every team and every situation, although the base principal of getting your end user to drive your product roadmap fits any project. Lean provides a methodology for achieving this.
Key Lean tools
- innovation accounting
- lean model canvas
- rapid prototyping
- user testing
- build-measure-learn cycles
Benefits of Lean
- products more aligned with market needs
- faster validation of products/services/features
- reduced risk
- better prioritisation of work
- features closely ties to business model
Common fears of Lean
- no product roadmap
- product and business model not predefined as it adapts to user needs
- trusting the process, no preset plan
- letting go of assumptions
- lack of rigour in business analysis
Companies using Lean
Agile refers to a philosophy of how to organise your company and team to be hyper-productive in serving your users. The founders of Agile wrote four principles in their manifesto:
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer [user] collaboration over contract negotiation
• Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.”
These principles have spawned a number of different methodologies to apply them, the best known is Scrum. These methods represent a starting point for an Agile organisation. By the very nature of Agile, the team continuously reflects on their processes to find ways to improve them. This means that the process changes over time and so whichever methodology they start with (Scrum, XP, Kanban etc) will look different over time.
An Agile team’s ability to continuously improve forms the nexus of their hyper-productivity. They measure their velocity on an ongoing basis so they have a benchmark for success. Increasing that velocity increases productivity.
A lot of debate exists around how to scale Agile. First one has to understand that an Agile team has to exist in an Agile organisation, incorporating Agile governance and Agile budgeting. Once this environment exists, scaling Agile becomes easy.
Key Agile tools and practices
- test driven development (TDD)
- pair programming
- backlog prioritisation
- user stories
Benefits of Agile
- highly motivated teams, better company culture
- faster, iterative development
- (almost) bug free code with minimal to no QA
- higher productivity from fewer people
- works for more than just software teams (eg hardware, marketing)
Common fears of Agile
- less certain timelines
- impacts whole organisation, not just tech/product
- no traditional product roadmaps
- embracing uncertainty
- being led from the bottom up
- having to let go of project managers
Companies using Agile
Continuous delivery (CD) makes iterative software release easy. It aims to build, test, and release software faster and more frequently.
It relies on a developers and operations IT team (DevOps) to set up hosting servers as code with increasing automated management. Ideally DevOps leads to NoOps — completely automated infrastructure with no operational staff at all.
When software engineers write new code for websites and services, it traditionally has taken a whole other team of quality assurance (QA) and IT staff to release those features to customers. In a continuous delivery environment, the entire release process becomes automated, meaning when a feature gets approved, a product owner can deliver it directly to users with one click — as many times a day as needed. Some companies release new features and fixes more than 70 times per day!
Key continuous delivery tools and practices
- automated testing
- continuous integration server
- configuration management
- auto-load testing
Benefits of continuous delivery
- on demand feature releases
- reduced tech team
- automated load-balancing, diagnostics and repair
- less human error
Common fears of continuous delivery
- cloud computing
- trusting the computer to manage hosting environment
- steep learning curve during transition
- initially expensive to transition
Companies using continuous delivery
These frameworks, approaches, tools and techniques all have different benefits and challenges. Do not think of them as mutually exclusive as together they can create a strong culture, a mature business and a household brand.
Before you decide on an approach for your team, department, division or company — spend time exploring the possibilities. Know that any process is only as good as the people practicing it. Choose your team wisely and make strong choices with them about which of these frameworks you all want to use. Then commit. I often hear people describing themselves as ‘a bit Agile’ or ‘kind of Lean’. This is usually the quickest way to a waste of time and money. The benefits are endless if you do it right — make it part of your practice, your culture, your DNA.
This is a curated post. The statements, opinions and data contained in these publications are solely those of the individual authors and contributors and not of iamwire or its editor(s). This article was originally published by the author here.