I've been building software at an enterprise software company for the past 8 years as a Product Manager. I have built features using the old 'Waterfall' approach and, of course, with Agile. As a Director now, I get to watch and mentor as others do it. We made our transition to Agile about the same time most software companies did, and have been working with it now for over 5 years. I completely and utterly support the Agile methodology and the value it can add. But, depending on whom you ask, you’ll get different opinions about what that value truly is.
I believe it really comes down to one, and only one, thing: rapid iteration. Agile encourages us to build smaller increments of software, get market validation or guidance, adjust and keep charging forward.
Iteration is rapid, and thus success or failure is more quickly determined. Period. If you aren't able to achieve this basic goal, you're not Agile—regardless of the myriad of other metrics captured. Yes, things like better collaboration and better corporate visibility and team morale are important, but I'd argue they are available in about any development methodology. It's the rapid iteration that’s unique. But how well are we actually achieving that?
Believe it or not, this idea of rapid 'market validation' is often the first thing that gets dropped, goes unmeasured or is just ignored.
“But wait!” You might say. "We are doing 2 week sprints and bi-weekly releases! We are iterating rapidly. Our burndown chart is beautiful!" There is an inherent assumption that rapid engineering iteration translates to rapid market feedback and product iteration. But, sadly, this just isn't true.
The reality at any enterprise software company is there is a considerable lag between release and usage of new features.
For some products at our company, if we work on new feature development, it's likely going to be close to a year from release before we can get substantial feedback from the market. Clients using those products just don't upgrade more than once a year at best. Our client-service organization assist with upgrades but they only have a certain amount of bandwidth. Additionally, getting in front of new sales is not always easy. Existing sales campaigns and priorities compete for sales person bandwidth making it challenging to properly empowering them with the right training and demo scripts. This can ultimately limit new-client adoption of the latest features.
So what can be done about this? Here are 5 tips all enterprise software development companies should follow to help ensure they truly reap the benefits of the Agile methodology:
1.) Stop thinking about release cycles, and start thinking about 'Feature Ramp Up' or 'Launch'
We recently added a new step into our release cycle called Ramp-Up, where product managers follow features into the field. In a nutshell, we are extending our Product Management engagement to include post-release follow-up. Product Managers must identify clients who want the feature, work with client service to get them upgraded and the new feature implemented, and then evaluate the success with the client.
This is where the rubber meets the road. If you can't find clients, shame on you as a PM—maybe your market evidence wasn’t as solid as you thought. A situation we’d like to avoid, but learning about missed expectations is best done as early as possible.
We now ask PMs to identify a handful of clients who want the feature and log their interactions and overall success. I've seen all kinds of things fall out of this - from the identification of insufficient documentation to misunderstanding of features, to a realization that the client only 'kinda' wanted it, but isn't prepared to upgrade. All of these things are EXACTLY what Agile is supposed to identify, but absolutely won't be found at the end of a 2-week sprint, guaranteed.
2.) Empower Scrum Masters to challenge Product Managers as well as engineers.
Scrum masters have no problem asking engineers why they didn’t finish a task or questioning the logic behind a work estimate. But would they ever ask a product manager why clients aren't using a feature they built six months ago? Doubtful.
Agile is all about execution. There is an inherent assumption baked into this that Product Managers are doing their job because at the end of the day the engineering team is always executing. The problem is that PM effectiveness is really, really, hard to measure. The quality of the story (following a 'definition of ready') might be good, but it doesn't necessarily translate into market success.
Additionally, product development at enterprise software companies is far more subjective in nature than other higher volume businesses. Unless the product is cloud based, we generally don't have access to click counts, conversion rates or usage patterns. While we try hard to quantify as much as we can, it's a very different algebra. 'I spoke with 10 clients who have a certain problem, and I also talked to our #5 revenue client who agrees' is a solid gold statement in the enterprise space. Most mid-size enterprise clients will attack whatever market problem is being justified with the previous quote.
Scrum masters should be comfortable questioning these assumptions and making sure Product Managers are validating and adjusting – not chasing their most recent piece of customer input. Empower Scrum Masters to ask questions like 'How many clients have you talked to about this story?' and 'What did you learn during our last sprint demo from your stakeholders that you are now adjusting?' and 'Looks like a good requirement - which clients have you run it by?'
3.) Product Managers must write something resembling a 'Requirements Document'
I know that using the 'Requirements Documents' reference will likely get me a summons from the Agile Police—but I'm going to do it anyway. I've seen teams where there are literally no artifacts of what they are working on beyond stories and epics in Jira. All too often, Product managers only write stories 2 weeks at a time under the pretense that this is Agile, and the requirements may change. But as we've just discussed, the idea that requirements are changing for a feature after 2 weeks of development is a bit ridiculous in Enterprise Software. Why did it change in a matter of 2 weeks? Probably because the PM didn't understand it when they wrote the stories 2 weeks ago. Is that iteration? Or just bad product management?
Asking Product Managers to write out the broader vision for a feature set in some sort of document—call it a ‘Usage Scenario’, '2-pager' or 'Detailed Epic'—forces PMs to understand the problem in its entirety. It forces PMs to go out into the market and get the complete picture up front. It also gives Engineering an opportunity to challenge assumptions and propose different solutions.
Requirements docs also serve an auxiliary purpose: ramping up new team members. Which of these 2 methods do you think would help someone come up to speed faster:
- Option 1: "Log into Jira and read the last 30 stories we completed and their corresponding Epic."
- Option 2: "Here's a doc explaining at a high level what we're working on."
The reality is Jira lacks any cohesive narrative and has only a vague chronology of events. If you add in the interruption that teams experiences and the myriad of creative ways companies use Jira (i.e. 'Buffer Story!'), it's fairly impossible for an outsider to understand what’s going on. There is of course value in keeping Jira as your ‘single source of the truth’ – so it probably makes sense to tuck these documents into an Epic or Initiative instead clogging up some shared drive.
4.) Stop following up MVP releases with 'MVP Part 2' in the subsequent release.
If there is a delay in the market validation, as I described above, why should we immediately work on additional features? We do it because we have momentum and we have a vision and because, secretly, we miss Waterfall.
We also do it because metrics and executives would be utterly confused if we wait an entire year after the release of 'New Feature X' before following up with 'More on New Feature X.' If you're lucky, people would say, 'Strange… I thought we already did this? Why is this back?' But more likely, you'd hear, 'No, sorry, that's not a priority anymore.' Thus, Product Managers are incentivized to keep work alive when there is organizational momentum—it's far easier than re-pitching strategies.
In most cases, what I see outlined in 'MVP Part 2' epics is not new stuff learned from market validation. It's scope that got kicked out of the MVP that we want to work on without further market evidence. To drive this point home - I would prefer to shut down work on new features after the MVP release for 3-6 months to gather proper market evidence (at the risk of losing a competitive edge) versus diving further into a feature that isn’t going to be impactful. Let your clients use that MVP in the field and see what you learn. In fact, I no longer allow the usage of the term 'Part 2' in any epic. This additional feature needs to be solving a new market problem, with new validation. The connection to the original scope of work is largely irrelevant.
5.) Make your sprint demos about the stakeholder audience – not the team.
Remember the pigs and chickens? (Pigs have skin in the game, Chickens gain but don't contribute.) Here's what I've seen happen: the Chickens slowly stop coming to Agile ceremonies. I could count in my inbox the number of times we have tried to "restart" involvement in our Agile process from others in the organization. It always goes the same way: we get a couple support managers, some sales reps, etc., to join for about 2 sprint cycles. We slowly bore them to death with endless talk of burndown metrics, technical spikes, dependencies, environmental issues, etc. We cut off their questions and ask them to take it 'offline.' And guess what? They stop coming.
Don't forget: their interaction is actually the most important part of the process. But instead, overzealous scrum masters make it about the metrics and the methodology. Change your sprint demo and focus it on your stakeholders. Build a presentation where you are thinking of them as the audience. Do they want to see Jira numbers? What about replication of bugs? Probably not. Show them the progress you are making and set its context in business terms, leaving time to capture their feedback.