As we move to what Forrester calls ‘The Age Of The Customer,’ enterprises will need to reinvent themselves to systematically understand and serve increasingly powerful customers, we are seeing a notable shift in what the business expects from IT. IT requirements are increasingly being influenced by the business leader who wants technology to not just enable efficiencies but to also provide an edge over competition by helping to develop things like new marketing and sales channels, and applications that provide greater insights on buyer behavior and what influences them.
By 2020, we anticipate that evolving customer expectations will open up tremendous opportunities for businesses, but at the same time, they will evolve so rapidly that businesses that are unable to keep pace will face the threat of extinction. Therefore, the need of the hour is for speed. Getting software products and services to market quickly, cutting product development costs, while continuing to maintain high standards for flexibility, nimbleness, and time-to-market – this is leading to a tremendous increase in interest around Agile development.
Many organizations have already adopted Agile to some extent within their organizations. According to Forrester’s Forrsights Developer Survey Q1, 2013, 19% of developers stated they use Agile (Kanban, Scrum, TDD, XP). However, most of these initiatives are primarily in-house – Forrester’s Agile Survey Q3 2013 showed that the majority of organizations continue to use Agile more widely in-house, than with systems integrators.
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?
Agile software development practices have been transforming AD organizations for more than a decade. With more rapid development cycles has come a bottleneck at the deployment boundary - at the frontier between Development and Operations. The DevOps movement is working to remove this bottleneck, and in the process is transforming both Dev and Ops for the better. In many respects it is a logical evolution of the agile movement, but practices like continuous deployment are deeply transformative of the way that organizations think about customer engagement, business engagement, testing, development and requirements - in fact, nearly every aspect of agile development is subtly but powerfully affected. The implication of a check-in resulting in code being deployed to production gives a whole new emphasis to the word "commit"!
At the OpenStack Summit in Portland last week, the open-source cloud platform got real, to echo Forrester’s cloud team predictions for 2013. At the busy gathering attended by over 2,400, suits mingled effortlessly with hoodies and deep-tech design committee meetings were sandwiched between marquee-name customers sharing success stories. Three core themes drove the show, as outlined by Jonathan Bryce in the opening keynote: the OpenStack technology platform has matured, the ecosystem is vibrant, and the global user footprint now includes enterprise customers doing real business.
The show followed on the heels of the Grizzly release, the 7th release of the OpenStack platform. Along with stronger support for VMware and Microsoft hypervisors, Grizzly widens block storage options and includes 10+ new enterprise storage platform drivers and workload-based scheduling. A wide range of new network plugins expand the platform’s software-defined networking options and a sexier Dashboard to access, provision and automate resources.
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