Is that title a wee bit too clickbaity?
Perhaps, but there’s a lot of truth there as well.
When organizations whose main product or service is something other than software want to improve their software development process, they often undertake an “Agile Transformation.”
The problem is that these Agile Transformations tend to focus on Agile Theater (do teams do standups, do we have scrum masters, what does your burn down chart look like) and don’t address the key behaviors that exist throughout the organization and that are very hard to change.
Behaviors such as lack of trust, poor communication, ineffective decision making, and passive-aggressive micromanagement.
At their best, these transformations equip teams with better ways to develop software, from the perspective of how people on a team work with each other and the engineering practices that they use.
But even at their best, these agile transformations do not address the more pervasive issues that happen outside the teams. The inability to make the hard decisions about what you’re not going to do. The over-reliance on forecasts that you know are wrong but are still enticed by the false sense of security that the forecasts provide. The false expectation that you can get twice the work done in half the time…
Those are all challenges that product people face on a regular basis. And they are things that many of the people who guide agile transformations don’t have a good answer for, because they are too far removed from trying to address those issues, or they never have.
Agile transformations are not the answer because they make being Agile the goal.
There is no one answer to improving your approach to product development. Many organizations have similar issues, but different contexts in which those issues exist, so you need different solutions.
You can’t buy a framework to solve them. You can’t expect newly certified consultants from a big five consulting firm to solve them.
You have to take a look at what other people have done, understand the context in which they’ve done those things, and think about what might work in your organization.
To provide some insight on places you can start, here are some of the things that people have shared about how they’ve shaped their product development process.
Yes, I’ll admit that these examples are not from enterprise companies with IT departments improving their process. If you’ve been part of an effort to improve software product development where the goal was an actual business-relevant outcome, and not just to “be agile” I’d love to hear about it.
How to Build an Amazing Product in 2019
Rob Volk has spent the last 10 years helping organizations develop products with his design agency. He put together this guide to give you an idea of how enterprises can adopt an agile mentality when it comes to building and deploying products.
Ryan Singer, recently wrote the book Shape Up: Stop Running in circles and Ship Work that Matters to describe how Basecamp evolved their approach to product development. Ryan appeared on a couple episodes of the Rework podcast to discuss the book. In one, Ryan discussed Shape Up. In the second Ryan was joined by designer Conor Muirhead, and programmer Jeff Hardy to go deep into Shape Up principles.
Lessons learned from scaling a product team
In the last 12-18 months, over dozens of releases from incremental improvements to huge redesigns, Intercom has learned a lot about scaling a product building team, and the nitty gritty involved in getting valuable product out the door as fast as possible. Paul Adams describes Intercom’s product development process, which can be broken into these main areas:
- A set of guidelines for making decisions
- Clear accountability
- A lightweight, transparent, comprehensive roadmap
- A culture of goal setting
It’s important to note that this process is not right for every company. It is heavily influenced by our culture. Your culture is different, so what you do should be different.
Purpose over product requirements
A Product Manager’s job is to get everyone aligned around what needs to be accomplished — and create a plan to make it happen. Yet, it’s actually impossible to lay out *every* single requirement. However, teams can create a product with purpose, even without every single requirement. Jen Dante discussed at INDUSTRY The Product Conference how you can manage your goal and the framework to help your team achieve it.
Product Managers, product owners and the need for real end user validation
Rich Mironov took some time away from his Greek vacation to talk to the Agile Greece Summit about why you should focus on product management instead of product ownership, why you want to make sure you’re doing user validation, and why you want to talk to your customers about their problems, but not their solution ideas.