I am just back from the CA World 2015 in Las Vegas, where everything was cool: from the weather, with unexpected but welcomed temperatures in the low 50s; to the event theme, with a strong focus on Agile, DevOps, APIs, and security; to Fall Out Boys and Sheryl Crow’s concerts.
As digital pervades all industries, and software becomes the brand, CA Technologies, which has traditionally had a stronger focus in the IT operations or “Ops” world, is making huge efforts to conquer the hearts and minds of the developers of large-scale development shops, or the “Dev”world. No doubt CA has been building a stronger DevOps in the last few years. Its goal is to partner in a larger industry ecosystem and be better positioned to serve the many organizations that are struggling to scale Agile and consistently build better applications faster. To make a stronger play in the Agile and Dev side of DevOps, CA made two brilliant acquisitions in 2015 which CEO Mike Gregoire highlighted in opening session of CA World: Rally Software, a leader in Agile project management at Scale, and Grid-Tools, a leader in Agile test data management and test optimization and automation.
With its revamped Dev strategy, CA aims to enter the Olympus of those large software and enterprise companies that have moved thousands of internal developers, testers, operations pros, and even managers to Agile and DevOps. With this transformation, CA will position itself to better serve current and future clients’ new needs to develop more software at speed. While CA started this transition much later than its competitors like IBM, Microsoft, HP, and other large software players (and even traditional end user enterprises), we recognize it’s still in time!
When computers were invented 60 years ago, nobody would have thought that gazillions of 0 and 1s would soon rule the world. After all, that’s all there is in any computer memory, be it a laptop, a mobile phone, or a supercomputer like Watson; if you could open memory up and visualize the smallest elementary unit, you would “see” only an infinite sequence of 0s and 1s, something that would look like this:
Interestingly, that has not changed. Computers are still processing 1s and 0s. What has changed is that we live in an age of digital disruption, an age where software applications run and rule our business more and more. To be successful, those applications need to be engaging and entertaining so that consumers enjoy and are delighted by them; they also have to be mobile and accessible anywhere and at anytime, and they have to leverage tons of information, no matter if it comes from a database, a tweet, or Facebook.
I hear people talking about Agile 2.0 a lot. But when I look at what’s happening in the application development and delivery space, I see that many organizations are just now starting to experience Agile’s true benefits, and they’re not yet leveraging those benefits completely or consistently. So let’s stop talking about Agile 2.0 for a moment and instead digest and operationalize what’ve learned so far. There’s plenty to improve upon without getting into inventing new practices and acronyms to add to the Agile transformation backlog!
What I see is that app-dev leaders want to understand how they can optimize existing use of AD&D Agile practices like Scrum, XP, Kanban, improve the practices around the more advanced ones like TDD, continuous testing, CI and CD and leverage all with what they’ve learned over the years (including waterfall). Scaling the whole thing up in their organization in order to have a bigger and more consistent impact on the business is what their next key goal is. We fielded the 2013 version of our Global Agile Software Application Development Online Survey to find out how. I present and analyze this data in my latest report. The survey addressed common questions that clients ask me frequently get in inquiries and advisory, such as:
How can we test in a fast-paced environment while maintaining or improving quality?
How can we improve our Agile sourcing patterns to work effectively with partners?
In theory, the agile Product Owner is a simple yet compelling solution to a tough problem: the development team needs, and often does not get, clear direction from the business. The ability to eliminate the confusion caused by the cacophony of voices of multiple stakeholders, and the ability to have continuous engagement with the business, certainly make the Product Owner attractive to the development team. And the business benefits, too: they, in theory, get continuous visibility into project health and status. Buried in that last sentence is the phrase that often sinks good ideas: "in theory", and therein lies a problem.
When we are developing software and find components that have responsibilities too broad for one component to encompass, we "refactor" it, breaking it down into a set of components with more manageable and cohesive sets of responsibilities. We have an analogous problem with the Product Owner, whose responsibilities are so broad as to be nearly impossible for one person to fulfill. In brief, the Product Owner is expected to:
Understand the needs and desired outcomes of the business
Negotiate consensus among stakeholders
Represent the interests of all stakeholders to the development team
Define the characteristics of solutions that meet the desired outcomes
Be a change agent in the organization to support the solution
Communicate and promote the vision to all interested parties
Define and prioritize items on the Product Backlog