Editorial
First there was waterfall. Then came agile. Agile begat lean. Now design thinking is having its moment in the sun.
Software development has changed tremendously in the last 15 years. So how do product managers and developers collaborate today to produce enterprise software?
The Apple Way
When I worked at Apple from 2000 to 2004, Mac OS X was built using the waterfall methodology. Product managers would collect input from customers and develop a marketing requirements document (MRD). Engineering would produce an engineering response document, which estimated how long each feature would take to develop. Then we’d meet to negotiate what would go into the software we intended to release 12 to 18 months later.
Product managers would meet face-to-face with the engineering managers on a regular basis. However, communication between product marketing and engineering was primarily via email, even though the teams were in adjacent buildings.
Each major component of the operating system had a separate development team. Each team had one quality assurance engineer who would test the code before it was committed to the release. A separate engineering team developed the user interface. And the engineering management organization kept the schedule, built and integrated the software for each release.
That’s the way software had been developed for decades. Not anymore.
Becoming Lean and Agile
Coincidentally, in February of 2001, a group of seventeen software development professionals got together at a ski resort in Utah. They wanted to create an alternative to “documentation-driven, heavyweight software development processes” like the ones described above. The result was the Manifesto for Agile Software Development.
Lean software development arrived in 2003. It combines agile principles with the Japanese concepts of kanban (with a scrum board instead of parts bins) and kaizen, or continuous improvement.
Lean and agile software development can be summarized as “empower[ing] a development team to think, plan, develop, ask and iterate as quickly and efficiently as they can.”
Ironically, the think and plan stages are not that different from the waterfall method. There’s still a lot of (too much?) process around gathering customer requirements and building a business case, which can take a long time. So “quickly” doesn’t really kick in until the develop stage.
Agile development (lean or otherwise) is done in sprints, with each sprint typically lasting two weeks. At the end of each sprint, the goal is to have a “shippable product.” That’s right, functional software — developed, tested and released in 14 days, not 18 months. Of course, each “release” won’t be incredibly feature-rich, but that’s the point. The goal is to develop only the features customers actually want, not what the product managers or developers think the customers want.
Customer Requirements
So how do software vendors know what customers want? Well, honestly, most don’t.
In the waterfall days, we asked customers what they thought they wanted. We’d develop software against those “requirements,” and then we’d come back a year or so later and ask if we’d developed what they used to think they wanted. We were usually about half right.
When agile came on the scene, we’d (still) ask customers what they thought they wanted, and then we’d develop a few features, deliver the software and get feedback. We’d still be half wrong, but at least we learned that sooner.
The problem with asking customers what they want is that they never know what they want until they see it. (You might think I’m joking or jaded, but that’s a scientific fact.) That begets a process of elimination — you develop what they don’t want until you finally develop what they (mostly) do want.
Rethinking Thinking
With design thinking, instead of defining requirements by asking the customer what they think they want, you observe the current situation and see what people actually do versus what they tell you they do to uncover the underlying want or need. You ask “Why?” enough times until you get to the root problem.
Learning Opportunities
Webinar
May
30
ChatGPT and the Future of Conversational AI
This discussion explores various aspects of AI implementation, ethical considerations, and challenges for your organization.
Webinar
May
31
The Evolution of Employee Listening - 2023 Trends & Best Practices
Learn proven effective methods and solutions to supporting an inspirational future of Employee Voice
Webinar
Jun
1
How organizations can design, build and run Generative AI into the Customer Experience
Discover how to drive enhanced CX through Generative AI
Webinar
Jun
6
The Future of Social Media: Emerging Trends and How to Stay Ahead of the Curve
The impact of emerging technologies like AI on social media
Webinar
Jun
7
The Building Blocks of Personalization
This webinar will explore how personalization can create powerful ecommerce shopping experience.
Webinar
Jun
13
The Future of Contact Centers with AI at the Helm
Learn how to balance human intuition and interaction with the potential uses of AI to create delightful and lasting CX
Webinar
May
30
ChatGPT and the Future of Conversational AI
This discussion explores various aspects of AI implementation, ethical considerations, and challenges for your organization.
Webinar
May
31
The Evolution of Employee Listening - 2023 Trends & Best Practices
Learn proven effective methods and solutions to supporting an inspirational future of Employee Voice
As Fast Company put it, “The goal of the definition stage is to target the right problem to solve, and then to frame the problem in a way that invites creative solutions.” Once you have defined the problem, you develop and consider a few alternative solutions, pick one, implement that and get customer feedback.
However, even with design thinking, the customer feedback still comes at the end, after you’ve invested valuable time and treasure to develop and deliver something. That’s still a “bassackwards” way of developing software.
There's Another Way
My company's not perfect, but we have been around for 35 years. And with age comes experience. With experience comes wisdom and the willingness to share what we’ve learned with others.
We did waterfall development for a quarter century. Then, we got lean and agile. Then along came some people and tools that allowed us to take our development to a whole new level. And here’s where I bring this story back to collaboration.
Collaborating with customers
We are about to make a(nother) major change to how we develop software. We’ve already done a lot of thinking about the root problems our customers deal with (that’s time-consuming, but we have a few ideas). Instead of waiting until after we’ve released software to get input from customers, we’re going to take a page from Google’s book to make sure we get the look and feel of the user interface (UI) right before we write any code. That’s right, function will follow form.
We’ve been working with an external user experience (UX) firm to help us ideate and iterate a new user interface (I highly recommend getting that external perspective). We’re about to get customer feedback on the new UI/UX. We plan to iterate the UI/UX until the customers are happy (i.e., a UI “release”). Then we’ll write code.
Once we code a feature related to the “released” UI, we will reengage our customer focus group to do usability testing, to make sure the UX of the product “flows” well. We will be using some software and surveys to gather, aggregate and validate the customer feedback.
Collaborating as a team
We use a number of tools to collaborate on just about everything. We use Slack instead of email to communicate internally among teams and with external resources. We use Google Apps for Work to collaboratively develop and share content. Our UX, sprint and other meetings are conducted in Google Hangouts (we have team members in multiple time zones).
We conduct asynchronous stand-up meetings using Tatsu (integrated with Slack). We use JIRA to manage our sprints and backlog. And we’re about to try out a new tool that we think can provide a single view of — and highlight the dependencies between — our marketing and development projects, enabling better collaboration, increased speed and greater efficiency. We’re always looking for new ways to increase our speed, efficiency and effectiveness.
Will these methods and tools work for you? Some might, even if you don’t develop software. Consider this an ideation exercise, the goal of which is continuous improvement. Think about your people, processes and technologies. Why are you doing what you’re doing, or using what you’re using? How might you improve how you collaborate with your customers and colleagues?
If you think long and hard enough, I bet you’ll come up with all sorts of ideas.
Learn how you can join our contributor community.
