Early Notes for an Enterprise Agile Manifesto

Tasktop Chief Product Officer Dave West puts on his old analyst hat and talks about overcoming Agile challenges in large organizations.

By Brian McDonough
September 16, 2015

In the first part of our Q&A with Tasktop Chief Product Officer Dave West, we asked the former Forrester Analyst to lay out the challenges large businesses face in making Agile work at scale. In this second half, we tackle the idea of writing an Enterprise Agile Manifesto. While we couldn’t quite get West to flat-out draft a declaration, we managed to identify three key points that anyone wrestling with this challenge would have to address.

iRise: So if you were tackling the first draft, what’s missing from the team-level Agile Manifesto that an enterprise manifesto would have to address?

Dave West: First, what do we need to do at an enterprise level? We need to plan, and SAFe [the Scaled Agile Framework] provides us some really good things. Planning isn’t about the details of what takes so long on what screen and such. It’s about managing the tradeoff between value and cost and risk—investment-level planning. At Tasktop, we consider at any time how to prioritize burning down tech debt versus adding new connectors, versus new enterprise features or deeper partnerships, etc.

“Another key tenet of an enterprise agility manifesto … is the concept of architectural platform. Some ultimate level of flexibility is just beyond us, so we have to think of our platforms and products as collections of capabilities that solve particular situations or problems.

So investment planning is one key thing. How do you make that more agile? You do it more frequently. That would mean that you’d need to be able to quickly gather the information to make those decisions and provide it in a much simpler way. But some things don’t lend themselves to that. You can’t plan less if you’ve got a big project like, “We’re going to Mars.” Or even releasing the next version of, say, Bank of America dot com. At a certain point, the size isn’t malleable, and you can’t just break it down into smaller chunks. That certain size implies a certain level of complexity, which implies a level of cadence.

That’s the sort of challenge you have to solve here: how planning affects agility. What information we need for effective planning, how we can gather than information faster and cheaper and of higher quality, on what cadence we execute that plan, etc.

Another key tenet of an enterprise agility manifesto, if there were such a thing—and I’m increasingly thinking this is a nice idea—is the concept of architectural platform. Some ultimate level of flexibility is just beyond us, so we have to think of our platforms and products as collections of capabilities that solve particular situations or problems.  We have to become better at defining and structuring platforms and architecture.

Now, you would think that was really simple because companies like Google and Facebook are continuously delivering new class libraries and new frameworks to be used. Things like AngularJS are incredibly good, but they’re not enough. Ultimately, I think the only way to get agility into enterprise of any scale is to recast your applications in the context of platform services. I know this sort of service-oriented architecture was popular in the ’90s and the early 2000s and sort of died a death, but I still think it’s incredibly valuable, and if you can do that effectively, then you do get a lot more agility around your software.

And then the third area, I think, is around dependencies, and I guess you could think of the first part of that as reporting status, managing status across your enterprise. It’s about how you communicate effectively across teams, and I’m afraid my experience is that the only way you can do that is to get rid of email and spreadsheets and, dare I say, SharePoint. Having your teams all conform to that, with a consistent set of tools or using integration technology to connect various tools, is crucial.

The other side of dependencies is analytics. You need to establish measures that let you effectively understand status, which feeds back into the planning process to ultimately improve your approach.

Q:  Not a bad start …

West: Yeah, I suppose those would be my three core areas: Planning stuff, platform architectures, and the effective use of tools and reporting. There are probably other things as well, but those three things stick out.

Dave West is chief product officer at Tasktop. Follow him on Twitter @davidjwest. For more on how Tasktop Sync unifies disparate tools (including iRise) across the software development lifecycle, visit Tasktop.com.