A survey of 3,220 software development professionals published this week found that among the 80% of respondents that embraced Agile practices for building software, just under half are tracking on-time delivery (47%) and business objectives achieved (44%).
The survey, conducted by Regina Corso Consulting on behalf of Digital.ai, a provider of a value stream management (VSM) platform. The survey also found a total of 19% of respondents were not sure what metrics were used to track software development progress.
At the same time, 40% of respondents noted they are dissatisfied with Agile at their organization; a clash with company culture was listed as the leading cause (41%) of unsuccessful delivery. Half of respondents use a combination of Agile, waterfall and/or iterative processes, but 27% noted this combination of frameworks was a struggle for them.
The survey also noted that just over a third of product and application owners (36%) that participated in the survey have adopted Agile.
Derek Holt, general manager of Agile and DevOps at Digital.ai, said that percentage suggests that Agile principles are now being adopted beyond the engineering teams that construct software. As that appreciation for Agile principles continues to grow, the organizations these individuals work for also tend to start tracking value stream metrics, he added. That transition typically begins with a few pragmatic metrics before the organization matures enough to justify the adoption of a VSM platform, Holt noted.
In time, however, that VSM platform not only helps organizations identify bottlenecks but also identifies potential quality issues and risks to the business, Holt added.
Overall, the top three top Agile development priorities identified by respondents are to accelerate time-to-market (52%), delivery predictability (44%) and lower risk (31%). However, from a business perspective, the top three priorities are company goals (54%) and end customer satisfaction (43%) followed by time-to-deliver (35%).
More than half (51%) of respondents, however, also noted that DevOps teams are not incorporating business feedback regularly. Well over half (58%) said the most valuable improvements to DevOps teams would be end-to-end visibility and traceability from business initiative through development, test and deployment to end users, while 55% said the ability to measure cycle time, wait time and bottlenecks would be an important improvement.
Regarding Agile tools used, Scrum led the pack at 87%, followed by Kanban at 56% and Scrumban at 27%. The Scaled Agile Framework (SAFe) framework has been adopted by more than half of respondents (53%), while Scrum@Scale/Scrum of Scrums was adopted by 28% of respondents followed by Lean Management at 8%, according to survey respondents.
The top benefit of Agile is increased collaboration (69%) followed by better alignment with the business (54%) and better work environment and increased visibility in the application development life cycle at 39% each.
The debate over the merits of Agile frameworks, of course, remains fierce and no two organizations may ever have the same level of adoption. However, as the pressure to deliver quality software faster in the age of digital business transformation continues to mount, the more crucial it will become to align Agile and DevOps best practices.
In the world of technology, there are few things as dramatic and impactful as enterprise IT’s recent ascent from an enabler to a strategic business driver. Tasked with powering next-gen digital business models, IT teams today are fast realizing the harsh truth that they must make a pervasive strategic shift from traditional project-based operating model to a product-centric one.
Traditional project-based operating models focus resources on a specific application or project, leading to fragmented experiences and a disconnect with the rest of the IT organization or company. For instance, in many cases, one team may be working on a back-end system, while entirely different teams work on the front-end application or updating databases. A product-based operating model takes a more holistic approach to ensure projects are integrated and teams work concurrently toward a uniform goal.
The days of plan/build/run are numbered as digitization forces IT leaders to act fast, think outside the norm and embrace the blurring boundaries between the digital and physical worlds. A product-centric operating model, sometimes also referred to as a DevOps operating model, accelerates organization-wide digital transformation and consolidates a business’ competitive standing. Companies must transition to a product-centric model to scale-up their agile programs to support end-to-end innovation and reduce siloed operations and projects.
The companies that have embraced a product-centric operating model are quickly realizing the benefits, but for many IT departments, they have yet to experience or fully understand why the shift is imperative.
What’s Driving the Shift to Product IT Operating Model?
As digitization takes hold and becomes more and more pervasive, CIOs are realizing that intertwining IT and business objectives is quintessential to respond to market changes quickly and remain competitive. Since 2018, volatility has returned to global equity markets in a big way. With the economy in a constant state of flux, coupled with rapid globalization and unprecedented disruption from technology, the average lifespan of a company is 20 years, compared to 60 years in the 1950s, according to Credit Suisse. Overall, the changing business environment makes few things as abundantly clear as this–agility, an appetite for new markets, new products, bias for action and a fail-fast approach will be the new mandates for IT leaders going forward.
To this end, most CIOs are replacing portfolios of discrete, siloed projects with product lines that enable a specific business capability. The key factors driving the shift toward a product IT operating model include:
Need for Holistic Transformation: Siloed functions have no place in the digital business world that thrives on integration of data and information across structure, culture, processes and technologies. To enable holistic transformation, organizations must draw a balance and establish cross-collaboration between organizational guidelines versus autonomy of teams for process, architecture, technology, tools, etc.
Lack of Alignment in Traditional IT Operating Models: Lack of alignment across large teams and multiple organizational groups (such as IT, finance and business) prevents organizations from executing an end-to-end digital strategy. Shifting to a product IT operating model can help steer organizational units toward a common goal. It can facilitate greater collaboration between different DevOps teams that support different products and domains. Recognizing the failure of existing IT governance and the pressing need for a shared digital transformation vision, IDC predicts 40% of CIOs will adopt new digital governance models.
Need for Speed: Most companies cited that their digitization efforts were hindered by inflexible or slow processes with a traditional IT operating model. Adopting a product-oriented management approach for IT can help organizations define and agree on a pace of change congruent with their readiness and appetite. According to IDC, 65% of CIOs will expand Agile/DevOps practices into the wider business to achieve the velocity necessary for innovation, execution and change by 2021.
Lack of Integration Between Old and New Technologies: Lack of integration between new and existing technologies is a key factor that keeps organizations from realizing the full potential of digitization. Modern companies need to balance innovation, experimentation, adoption of new technologies and tools with the enterprise’s need for business results, cooperation, risk management and compliance. Because a product-centric model takes a holistic, end-to-end approach, it is ideal for integrating technologies, processes and teams at scale.
Embracing a Next-Gen Operating Model
To compete with newer, nimbler companies such as Facebook, Uber, Spotify and others, traditional companies that are serious about continued growth are leaving no stone unturned and embracing a product IT operating model. From being providers of reliable IT services, CIOs have emerged as strategic partners in driving business transformation. Modern day CIOs are driving business innovation and identifying opportunities for competitive differentiation, not delivering ad-hoc, siloed services. As cloud-first and AI-first become the new mandates for organizations, re-engineering the IT operating model is quickly becoming central to creating value, competitive advantage and growth.
Product managers live in a high-speed world and are always focused on releasing the most impactful features in the shortest amount of time. Since users have grown accustomed to regular UI updates and bug fixes completed in near real time, this frenetic pace at which product managers work will only increase.
The process of pushing out new features or software fixes can be very stressful on product managers, and the one thing they crave to keep their sanity and ensure a successful release is control. Luckily, that’s exactly what feature flags provide.
Dialing Up Feature Flags
At their core, feature flags give development teams the ability to turn features on and off without deploying new code. Think of them as dials in the cloud. When the dial is attached to any feature in a product–whether a new one or an old one–it controls who sees it, who has access to it and how quickly it is delivered to an entire customer base.
Feature flags let organizations break the tyranny of the Thursday night release by segmenting it into smaller bits to control exposure and enable a continuous release motion. You might start by turning on a feature to only internal users or beta testers so you can test in production to make sure nothing has been missed. From there, you have the freedom to ramp up the feature to your customers gradually before going to 100% availability.
With this controlled exposure, development teams can lessen the panic and anxiety around the weekly release schedule. Having the ability to completely turn off features means feature flags also increase application stability and remove the need for hotfixes. It’s less often necessary to assemble a war room if there is a problem when you can simply turn off the feature in seconds. By working feature flags into the release process, teams take control of the who, what and when in terms of releases. They can also dictate types of users, demographics, locations and scale the release of the new feature.
Feature Flags and Product Managers
Outside of the DevOps team, feature flags can also be really powerful for product managers. Historically, the release of a new feature meant product managers had to coordinate with cross-functional teams to ensure the release was executed successfully. This meant making sure marketing was ready to publish a blog post about the feature, the sales team knew how to use and sell the new feature, and the product marketing team had documentation prepared for how the feature set works. Of course, all of this had to be perfectly synchronized with the engineers’ timeline for releasing the feature.
With feature flags, product managers now essentially have the keys to the kingdom. It gives them the power to turn the feature on for some or all of their customers without waiting for engineers to complete their next deploy. Not having to coordinate that extra piece of the schedule gives a lot of power and time back to the product manager.
A Deeper Look at Customer Feedback
Another aspect of a product manager’s job is collecting feedback. They need to be able to answer questions related to business KPIs, such as “How is this feature performing for my customers?,” “Are customers able to do the action the feature is intended to perform?” and “Are we generating more revenue from the feature?” Feature flags can also help in this area.
As product managers ramp up a feature, they are simultaneously shortening the feedback cycle. Since feature flags allow for segmentation, where one customer group sees one set of features and another customer group sees a different set of features, and since key metrics can be captured into separate buckets for each group, product managers can now run controlled experiments as part of the release cycle. Seeing KPIs aligned with the different customer groups helps them understand which features are performing the most successfully.
Creating the Ideal Product Roadmap
As product managers embrace usage measurement tied to feature rollouts, entire teams can better align with agile best practices to continuously push out the smallest incremental set of new features. By understanding the performance of every feature, you’ll be better equipped to iterate and refine your ideal product roadmap.
Enterprises are embracing DevOps underpinned by automation to ensure the quality of software across all digital touchpoints. In fact, automation has become the crux of continuous integration and delivery, the vital DevOps testing goals. Without automation, DevOps would become a distant dream, and businesses would struggle to keep pace with seamless delivery and integration. However, DevOps entails more than the implementation of the latest automation tool and demands a more holistic approach. It does so by bringing together processes, people and technologies under a shared vision. As defined by Microsoft, DevOps is the coalition of products, people and processes to facilitate the seamless delivery of value to the end customers.
DevOps is considered to be the latest advancement of the agile movement. It includes a greater number of stakeholders in the process of delivering value by linking the silo-based teams. It may not be the best practice, but it’s a discipline of people-centric management. Continuous delivery is the technical foundation of DevOps automation, which extends to the agile foundation as well. The close collaboration between the operations and development teams is known as DevOps, which is used to automate the delivery pipeline.
Role of Automation in DevOps to Increase Productivity
Since digital transformation has taken over the current business model, more and more companies are embracing the DevOps practice to drive the automated deployment of software. We are shifting toward an organizational culture in which development and testing take place simultaneously, quickly and more often. This helps maintain consistently high ratings on the quality of software with faster turnaround time. The main agenda of DevOps testing is to derive quality outcomes all along the software development life cycle (SDLC) and beyond. So, with the help of DevOps culture, a new code of development, testing and delivery is introduced in the overall SDLC.
The automation in DevOps empowers companies to:
Enhance the reliability, re-usability and quality of all components.
Save costs of upgrades and maintenance.
Improve the rate of success for standardized processes to ensure the rapid delivery of applications.
Automate Everything — Is It Even Possible?
With the help of the DevOps approach, developers automate and accommodate operational activities, from the source code commit to operational productivity. The primary goal of DevOps automation is to remove bottlenecks in the pipeline by implementing automation in a single level of development. However, DevOps is not a fully automated process and is not operational without human intervention. It is the DevOps testing specialists who are responsible for the process to run flawlessly. Governance at every stage of DevOps testing is still indispensable in various processes undergoing automation. Importantly, human administration is still crucial in handling exceptions to complete the tasks of automation.
The Strategic Role of Humans in DevOps to Ensure a Continuous Pipeline
Remove the Boundaries of Roles
The primary feature of DevOps automation culture is about an enhanced collaboration between the operations and development teams. It has led to a cultural transformation at the organization’s level and inside the teams as well, to encourage continuous delivery. Since shared collaboration is an important aspect of the DevOps culture, it strengthens the collaboration within teams. Before the DevOps approach, the perceived lack of interest by the development team regarding maintenance and operations used to affect DevOps testing and business goals. However, this scenario has since changed due to an organizational shift toward automation and DevOps testing.
The gap between the silos of operations and development no longer exists with the arrival of DevOps. It has removed the boundaries of several organizational roles. Teams are required to focus on the shared goals of DevOps to enhance the end user experience, so the team members need to rethink every investment and decision around this shared goal, which requires human intervention. Automation cannot substitute the decision-making process of humans, for the latter has become vital across the organizational ecosystem as, and when, needed.
Omit One-Size-Fits-All Approach in DevOps Testing
Automation cannot be viewed as the eliminator of roles. The organization still requires expert knowledge and skill set inside your team. The focus should be on developing agile and cross-functional teams that are recognized for removing long-established stumbling blocks between the operations and development teams, and for facilitating collaboration. Developing efficient and functional teams would ensure the delivery of superior quality products.
Continuous Monitoring, Testing and Improvement
One of the key agendas of DevOps testing is to carry out a deeper level of monitoring. Since rigorous monitoring is needed at every layer of the testing process, from integration to infrastructure and transactions to components, it has become a crucial part of the road map of the DevOps approach. In this digitally connected world, monitoring and testing are no longer distinguishable. Continuous monitoring by testers offers a positive response to the user experience while eradicating pre- and post-production obstacles.
Conclusion
With the impetus in the growth of DevOps and agile practices in the past few years, testing has taken a new structure and form. It has evolved into a crucial discipline, and it’s not restricted to a phase of the development cycle anymore. It has become an essential part of the operational activities of production. So, is the role of a tester transformed radically from only a checkpoint to a crucial active participant in the DevOps testing? Teams need to cooperate based on the shared vision of enhancing augmented user experience. We need to understand the fact that automation is not an elixir to deliver on DevOps goals, but merely a part of the DevOps strategy.
The spotlight currently may be firmly trained on agile and DevOps techniques, but large banks around the world still maintain core systems where traditional waterfall development techniques are used to upgrade and maintain software.
So, which development techniques work best in an environment dominated by legacy systems but where innovation is fundamental to future success? How can banks combine the best of agile, waterfall and DevOps methodologies to deliver new products and services to customers at pace, without compromising mission-critical operations?
Time is of the Essence
One of the drivers for migrating from waterfall to agile is the need to deliver new features in shorter time frames to better satisfy the rapidly evolving needs of a business. This can be a challenge if, for example, an organization is reliant on a legacy platform that is updated using a waterfall methodology.
In such a scenario, upgrades might be delivered every six to 12 months, which means long lead times associated with implementing change. This also creates issues around transparency in the upgrade process, because it is difficult to provide clarity on the changes that will be introduced in the next version of the software.
One possible solution to this problem is to evolve the platform so that it can run in the cloud as a service-oriented architecture-based platform, which enables the adoption of agile and DevOps techniques when delivering updates to the software.
This will allow the organization to deliver changes in response to clients’ needs in shorter iterative cycles, mitigating risk and enabling them to plan work in a more iterative fashion. While there is still a need to look ahead, the scope of work is not so fixed as it was in the past and can change along with new and different priorities.
A Quicker Journey to Value
This is important as businesses don’t always know what they will want in the future and need to be able to adapt different systems as the business and technology landscape evolves. Not only does the new approach accelerate the time taken to deliver value to customers, it also means features can be delivered incrementally at the point of need.
Once implemented, this type of platform can support ongoing development of new features. Clients can collaborate with the developers of the software vendor to deliver features incrementally, allowing them to understand timing and to request the delivery of features for testing ahead of a full project completion.
Feedback allows the development team to improve specific features reviewed and to apply what is learned to features yet to be developed. Clients can review the product through mini-demos early in the process to understand functionality, user experience and other areas of interest. They also can have input into the prioritization of features, so there is transparency of project progression.
Changes in Working Practices
Naturally, this implies changes in working methods within the client’s business to allow for greater collaboration. It also requires more diligent and efficient testing and version control practices, particularly for those firms working in a regulated environment where changes to one element of a system can impact other areas.
However, it’s important to remember that moving in-house developers from one environment to another will not happen overnight. Most traditional banks, for example, need to retain waterfall development skills to maintain and upgrade core systems while building agile and DevOps techniques alongside to build out the new customer-facing apps and services.
In fact, abandoning waterfall and adopting agile for all development could introduce unnecessary risks to a process that previously has worked well and doesn’t require short cycle times. Often there can be merit in having two streams of development: one for existing back-office core systems and one for satisfying the rapidly evolving front-office needs of the business.
Whichever blend of development skills, core systems and subscription services organizations choose to maintain, having a platform approach that brings data from core and new applications together will be increasingly important.
Contrary to what the massive articles around digital transformation suggest, your business lines’ primary concern isn’t the amazing technology innovations that pop up every day but how well they’re going to deal with your industry’s disruption. Something is sure, your IT organization’s digital transformation cannot be narrowed to technology changes; that’s a simplistic vision which ignores the disruptive impacts on businesses, particularly on the IT function.
Howard King, writing in “What is Digital Transformation?” published in The Guardian, makes it clear, “Transformation is a whole scale change to the foundational components of a business: from its operating model to its infrastructure. What it sells, to whom and how it goes to market.” He’s right, the business-oriented vision of IT demands a transformation of your IT organization including its infrastructure, applications delivery approach and operating model, and DevOps increasingly is cited as the foundation of the new IT.
This article shares my experience and lessons learned implementing DevOps as the foundation of digital IT organizations.
Top Priority: Dealing with Your Industry Disruption
The belief that implementing a continuous delivery infrastructure is all your business need to survive digital disruptions is a marketing hype DevOps practitioners have grown accustomed to. It’s a myth that prevents you from making informed digital transformation decisions. Emphasizing the technology at the expense of your industry’s disruption forces you to make technology change prematurely; your priority actually should be to figure out how to deal with the disruptions hitting your industry.
Ask yourself this: What’s the interest in investing in scattered continuous delivery infrastructure implementations, when your favorite vendors and consultants aren’t able to clearly address these concerns:
How can you restructure your business value stream to make it lean and agile so that the right services are timely delivered to the right market segments?
How can you integrate DevOps, IT as a service, cloud, Internet of Things and big data into a coherent and consistent business capability so that the right services are timely delivered to the right market segments?
What’s the architecture of your future information system, including your virtual data center and application delivery infrastructure?
What will your role be as the CIO? How will the relationships with your business lines and vendors be managed?
Make no mistake about it, these are your business line concerns of the moment. Unless you address them, Chef, Puppet, CodeDeploy or any other software application alone won’t help to keep up the pace imposed by Uber, Apple, Google and the like. You’ll need to bring together your business and IT staff in a lean and agile capability, which demands a re-engineering of your IT structure, processes, practices and governance.
DevOps is the Foundation of Your Digital IT Organization
Let’s remove the ambiguity: Infrastructure as code isn’t DevOps. The increasing confusion of DevOps with continuous delivery infrastructure is slowly but surely killing it—it’s even disqualifying it as a competitive advantage. That vision focused on tools has nothing to do with the logic underneath DevOps.
As I’ve been making clients happy with it, DevOps is primarily an application delivery model that seeks to make businesses responsive to market opportunities through accelerating added-value applications delivery and with the goal of continuously generating value. It’s based on three principles helping businesses survive digital disruptions, then grow and prosper:
Using continuous delivering infrastructure to speed application delivery doesn’t make sense unless tangible business benefits are generated.
Applications are the means by which value is brought to customers and business benefits are brought in.
Agile principles across your software development life cycle makes your value stream lean and agile which in turn results in continuous value.
The delivery model uses three levers to implement the above principles and establish DevOps as the foundation of your digital IT, they include:
The rules of the game, which are agreed-upon principles, practices, roles and responsibilities and tools institutionalized to ensure agility and accelerated applications delivery;
The operating model, which is the lean and agile work environment resulting from the application of the rules of the game; and
The continuous delivery infrastructure, which is a platform that leverages infrastructure-as-code solutions to accelerate applications development and deployment.
The Digital IT Organization: Approach, Principles, Tools
Success in IT organization transformations often come more from a stream of small wins than from a one-time flood. That’s what I call incremental transformation, illustrated in the following digital five-stage transformation journey:
The following recommendations definitely will make you instrumental to your IT transformation and help your business meet the digital economy’s competitive challenges.
Strategize
A CIO who’s expected to help business lines survive their industry’s disruption, grow and prosper first must clarify their business objectives; estimate potential gains, losses, and risks; and create a consensus on the DevOps delivery model to implement in terms of high-level architecture and implementation timing. That’s the purpose of the Strategize stage.
Never skip this stage—it’s where the executive buy-in is obtained and the vision of the future IT capability is developed. Make sure the following is accomplished:
Creating an executive task force co-led by the CIO and a business representative;
Scheduling one to three workshops addressing your transformation business case, transformation road map, high-level blueprint of the future IT capability and the DevOps adoption plan;
Designating a project manager; and
Communication by task force members regarding the whys and wherefores of the transformation initiative.
Plan
Digital transformation involves many functions within your business in the form of a cross-functional team: the concerned business and IT staff. Your responsibility as the CIO is to bring the voice of the business across the transformation journey, from business objectives clarification, to design and implementation, to pilot experiment, to deployment.
Again, do not overlook this stage—it’s about translating the effort into team structure, implementation schedules and operational and strategic reviews. It’s where the risks likely to hamper projected objectives are anticipated. Make sure workshops involving the business and IT are set up to address the following:
Team structure and roles and responsibilities;
Transformation road map steps translated into operational timelines associated along with expected outcomes; and
The project’s operational and strategic reviews, including a risk management plan.
Design and Implementation
The third stage is when the three dimensions of the digital IT organization are designed and implemented. They include the DevOps rules of the game, the operating model and the continuous delivery infrastructure.
Never improvise this stage—use a proven approach to address the dimensions. Favor a collaborative approach that includes workshops or brainstorming sessions with the concerned business and IT staff.
In the rules of the game brainstorming sessions, make sure the following is addressed:
Organization and operational dysfunctions preventing cross-functional collaboration, rapid problem-solving and decision-making;
Recommendations to the dysfunctions in terms of agile processes, practices, roles and responsibilities and tools;
Recommendations mapping to the appropriate DevOps principles, practices, roles and responsibilities and governance structure; and
The IT organization’s DevOps charter, thought to accelerate the rules of the game and the operating model adoption.
In the continuous delivery infrastructure workshops make sure the following is addressed:
A delivery pipeline, including steps and for each of them what follows:
Required staff, skills and background
Implementation, testing and deployment agile processes and practices
Implementation, testing and deployment tools, such as Chef, Jenkins or CodePipeline
Experiment
For this stage, set up a pilot experiment involving, in a small-scale real-business setting, a panel of business and IT staff to evaluate the likelihood of the project benefits.
Neither skip nor overlook that step, it’s where improvements are identified. Throughout the pilot project, make sure the following is in place:
Executive task force monitoring the pilot project through bi-weekly reviews;
Concerned business lines and IT business lines are involved;
Training campaigns are organized around the DevOps charter, the operating model and the continuous delivery infrastructure;
Strategic management tools, such as balanced scorecards to monitor progress, risks and achievements; and
Measurement of the impacts of the operating model and the continuous delivery infrastructure against the projected benefits.
Deploy
This final stage is a Go-No-Go milestone in which your task force, based on the pilot’s outcome, decides whether to deploy your digital IT capability at the scale of the company. Throughout the deployment:
Capitalize on the benefits generated by the pilot experiment to launch an information campaign emphasizing the benefits for the company and for the staff; and
Train business and IT staff on the DevOps charter, the operating model and the continuous delivery infrastructure.
Wrapping up
Today’s DevOps practices focused on continuous delivery infrastructure aren’t likely to help businesses grow and prosper in the digital economy. Thought leader Joe McKendrick in, “The road to digital bliss is paved with service thinking and DevOps,” confirms that fact.
The approach discussed in this article are detailed in my recent book, written to help make IT leaders instrumental to their business digital transformation:
If you’re considering a DevOps-focused IT transformation, what will be your first steps? I’d love to hear your thoughts, let’s meet @TheFutureOfYourIT.
This is the third blog in the DevOps – Scaled Agile series. In the previous blogs, we discussed the characteristics of a successful enterprise agile transformation and provided specific guidance on applying lean and agile practices at an enterprise level. We covered the “why” and a bit of the “how” at a high level, making the case for the need to address all aspects of a scaled agile transformation –people, process, and tools – to achieve success.
By now you should be asking “where’s the beef?!” You get it… now you want to do it. Great! Because we have tooling that can help. Yes, tools are just one aspect of the transformation to a continuous delivery model, but man, wouldn’t it be nice to have tools that just support enterprise scaled agile methodology out of the box so you don’t have to think about that part and get on with the hard stuff – like the cultural aspects of this transformation?
The Scaled Agile Framework® (SAFe®) provides the “rules” for scaling lean and agile across the enterprise; the tools support those rules to get you up and running quickly.
Let’s start by breaking down the organizational structure: SAFe v3.0 describes a methodology for scaling agile and lean across three organizational layers:
Portfolio: Where investment decisions are made. This is the heart of economic planning, where programs are aligned with the enterprise strategy. There may be multiple portfolios in an enterprise, even within a line-of-business. The decision hinges on strategy and funding; a Portfolio has its own strategy and its own bucket of money.
Program: Where funding and strategy meet planning and execution. The Program has the resources allocated to deliver on the strategy. Programs are long-lived and require a persistent structure and mission, so they are not exactly equivalent to business-driven “projects”, which might typically have start and end dates. That said, Programs deliver capabilities in support of “projects” through their contribution to Portfolio Epics. And we will discuss more on this later.
Team: Where the real work gets done! Teams are solely responsible for defining, building and testing their own user stories that contribute to value delivery for a Program. They are independent and self-governing, but they do operate in lock-step with other teams to deliver software aligned with the Program vision and the Portfolio strategy.
With me so far? The tooling that supports SAFe encapsulates this organizational structure, giving you places to capture things like budget, strategy and roadmaps at a Portfolio level along with the “change” artifacts – the work items that identify what will be delivered by the Programs and how it will be delivered by the Teams. By providing a system to hold the data, we can also then provide visibility into status and health of executing Programs and the means to report on trends to demonstrate measured improvement – or not! – as your transformation evolves.
Let’s explore the tooling bottom up, as that is typically how most organizations get started with SAFe.
SAFe Program/ Teams
SAFe Programs and Teams are supported in IBM Rational Team Concert. A process template is provided that you can use to create a Program project area with Teams as team areas within the Program. Alternative topologies, such as Teams in their own project areas or even using third-party tooling, can also be supported.
The process template provides:
Project Area Initialization
Work Items & Attributes
Plans (Roadmap, Kanban, WSJF Ranked List)
Reports
Process Guidance
Everything you need to quickly initiate a new program and kick off program increment planning, is available and ready for your team to get started.
SAFe Portfolio
In the next release of the Rational Collaborative Lifecycle Management (CLM) solution, IBM will provide support for the SAFe Portfolio, rounding out our SAFe V3.0 support. As with the Program process template, the CLM Lifecycle Project Area template will provide a Portfolio tooling infrastructure that joins change management with requirements and quality management to fully support the execution of the Portfolio. Through a set of template, we provide you with:
Portfolio Artifacts & Attributes
Plans (Roadmap, Kanban)
Reports
Process Guidance
As a starting point, the Portfolio includes a set of Programs as team areas, allowing you to easily identify the resources involved in each Program.
SAFe Key Concepts
In the last blog, we discussed three key SAFe concepts that we believe are required to achieve success: Kanban, WSJF for relative ranking, and PI Objective to capture and assess value delivery. Each of these concepts is supported by the tooling.
Kanban System
At both the Portfolio and Program levels, the tooling provides a Kanban plan view to enable your team to drive relative ranking and prioritization discussions based on the Kanban System.
WSJF
To help your Program drive backlog planning, the WSJF Ranked List view is provided with the capability to actively lead a planning session making changes in-line to create a ranked list of Features.
PI Objective
The PI Objective is a work item artifact provided by the Program process template, allowing you to capture planned and actual value delivery consistent with SAFe guidelines. In the next release, we will also provide a new calculated attribute that captures the percentage of value (actual / planned) so that we can provide trending reports that demonstrate the Program’s ability to deliver value over time.
To learn more about our ongoing SAFe support, visit the SAFe Landing Page: http://ibm.biz/safesupport. We look forward to your feedback! And please join IBM at AgileDC, October 26, 2015, Washington D.C. Submit a proposal through August 15, 2015. URL: http://agiledc.org/2015-call-for-proposals/
About the Author/ Amy Silberbauer
Amy is a Solution Architect charged with the definition and delivery of the Enterprise Scaled Agile and IBM DevOps Plan solutions and strategy for the IBM Systems – Application Platform line of business. She is a recognized subject matter expert on scaled agile and software development lifecycle solutions, including enterprise modernization, SOA and collaborative DevOps. She has been with IBM for 28 years and has two decades of software development experience as an engineer, architect and manager. She is a certified SAFe® Program Consultant experienced in leading and consulting on multiple internal and external SAFe (Scaled Agile Framework®) transformations.
This is the second blog in the DevOps – Scaled Agile series. In the first blog, Scaling Lean and Agile for the enterprise: All hands on keyboard!!!, we discussed the characteristics of a successful enterprise agile transformation and described why engagement and commitment across all disciplines in the organization is not just optional, but required, to ensure you deliver differentiated value. Business and IT must be in sync because, as we have learned through experience, successful agile team-based development does not by itself guarantee organizational success.
What does it mean to “be in sync”? How do we do it? Well, you Steer SAFely, of course. I know, a cute play on words, but just think about it for a moment. Consider a typical “day in your life”. From the time you wake up, you navigate through your day crossing paths with others along the way and continually adjusting in response. Your husband beats you to the shower, so you go get another cup of coffee. A guy crosses three lanes of freeway traffic (in front of you!) to get off at an exit he’s nearly missed, so you slow down a bit. You get a last-minute request to do something by the end of the day, so you engage with a colleague to get it done. Some of this is more reaction than collaboration, but nonetheless it is a simple analogy for Steer SAFely: Steer, which implies a series of continual adjustments to enable you to maintain course, and SAFely, which applies guidance and best practices as you Steer. The notion mirrors some of the basic concepts embraced by the IBM DevOps framework:
Being aware of your surroundings (understanding dependencies)
Recognizing and avoiding risks and roadblocks (monitoring and adjusting based on feedback)
Working with others (collaborating)
Clear as mud? In a nutshell, to Steer SAFely means, as an enterprise, you are applying lean and agile principles to accelerate value delivery. To be successful requires collaboration of multiple disciplines across business and IT, continuously, from planning to development to deployment to delivery and then back to planning in response to feedback.
Let’s explore how you do this.
Step 1: Shift how you act and make decisions:
Focus on delighting the customer instead of making money. Making money is the result, it should not be the goal. This notion is specifically enforced in the SAFe Portfolio layer, which requires the organization to take an economic view to help guide business priorities based on an understanding of the value of something versus its cost.
Reconsider the role of bosses. Management’s role is to enable those doing the real work to be as efficient as possible by recognizing and removing impediments quickly, end-to-end. Agile used to mean “no management”, but enterprise agile is not the same. You need managers but their role is different. The SAFe tiered approach clearly describes the responsibilities and activities of managers at each level so that there is no confusion.
Avoid steering top-down or bottom-up. Neither of these methods leads to success. Instead, drive collaboration horizontally across the organization and involve all disciplines early and often in the decision-making process. SAFe explicitly addresses this notion through a set of well-defined events and activities that are designed to engage the entire multi-disciplinary team.
Step 2: Ensure the transformation completely addresses all aspects of the environment:
People: Establish an organization-wide culture with the right set of skills to embrace lean and agile values – everywhere, across all teams, every day
Process: Apply lean and agile principles in the planning, development, deployment and delivery of value and then monitoring feedback to improve – continuously
Tools: Provide a framework that enables the implementation of lean and agile practices – easily
The trick is to balance efficiency and effectiveness so that you can answer these questions in a positive way:
Are we moving as fast as possible? Efficiency in execution is achieved through lean practices to minimize waste and maximize time in value added work.
Are we driving in the right direction? Effectiveness in execution is the result of smarter steering by quantifying value and cost tradeoffs through continuous feedback and better delivery analytics.
Step 3: Adopt (at least) these three SAFe concepts:
Kanban System: Kanban embraces lean principles to ensure that you invest just enough at the appropriate phase of your lifecycle within your capacity to do so. SAFe describes a phased analysis approach bounded by Work in Progress (WIP) limits and grounded in economic thinking to quickly rank work based on not only value but also cost.
WSJF: Weighted-Shortest-Job-First is a value assigned to each of the key SAFe artifacts: Portfolio Epic, Program Epic and Feature. This value essentially defines an estimated return on investment and enables your team to consistently and relatively rank work across the Portfolio to drive priorities down to the Teams. Use of WSJF enforces the economic view in planning because it ensures that both value and cost are considered as you prioritize work.
PI Objective: SAFe describes a Program Increment (PI) Objective artifact at both the Program and Team levels as a way to document expected and realized value in a relative way. Here, as with WSJF, consistency and relativity are most important, not precision. PI Objectives are also a way to capture the notion of acceptance criteria, which could guide solution-level validation.
Amy is a Solution Architect charged with the definition and delivery of the Enterprise Scaled Agile and IBM DevOps Plan solutions and strategy for the IBM Systems – Application Platform line of business. She is a recognized subject matter expert on scaled agile and software development lifecycle solutions, including enterprise modernization, SOA and collaborative DevOps. She has been with IBM for 28 years and has two decades of software development experience as an engineer, architect and manager. She is a certified SAFe® Program Consultant experienced in leading and consulting on multiple internal and external SAFe (Scaled Agile Framework®) transformations.
The headline made her yelp for joy. A year into the future of D-Chip, on a crisp August morning, Phoebe opened the newspaper and swiped to the technology section on her iPad. What she saw was riveting: D-Chip reborn as a star in wearable computing.
She immediately thought of the article Marc Andreessen wrote on how software transformed the enterprise. It’s true of our company’s story, she mused. The credit for making the headline a reality was due to the stressful events of the last months. Who said stress couldn’t be a game changer? As she picked absently on a plate of fruit and relished the article for the second time, she recalled the events of the past year.
Flashback a year ago at D-Chip
Remember how Rachel pitched her enthusiastic idea to Chandler? She wanted to engage six engineers in six months to build an in-house solution. A solution that would integrate D-Chip and Enogo’s systems by letting them deploy in both OpenStack and AWS and manage wearable chip code from a single deployment platform.
Chandler agreed in theory with the need for a single management platform but didn’t see the sense of doing it in-house. Why side-track from your business goals and spend months building a solution yourself when there are specialists solving this exact problem for many companies facing the same issues? After much debate, they came to a consensus. They decided to evaluate solutions from the best-of-breed products out there and transform their software development lifecycle to reflect the best agile practices. Thus was born the iTransform project.
The iTransform project
The name itself was a reminder that transforming was as much a matter of people internalizing and accepting a new way of doing things as much as it was about aligning and unifying D-Chip and Enogo systems. The first order of priority was to understand the pain-points that assailed the company. After a lot of meetings and detailed analysis, they identified key use cases from internal stakeholders, namely the engineering and IT operation teams:
Engineering personas, developers, QA, architects, all said the same things. They didn’t have access to the latest tech because it took weeks or months for approval processes to travel up the chain. Then they waited on builds and environments from IT operation teams. Most of the time, the environments in the private datacenter OpenStack cloud didn’t work properly, and deployments never succeeded the first time. It’s no wonder they took weeks or months to release anything decent.
Self-service and continuous delivery were, therefore, the most important criteria for developers, QA, and architects. Without waiting for IT admins or operations teams, they wanted to spin up build environments in test, staging, even production on their choice of pre-configured infrastructure. They wanted to consume in an on-demand fashion the latest technologies on multiple clouds. Today they were using AWS cloud and OpenStack, but tomorrow they wanted any cloud that matched their workload configuration needs best.
IT operations and system admins brought up their set of challenges. Their primary goal was to configure environments for repeatability; safeguard builds from failures and structure stable workflows. Not an easy job come to think of it. On top of this demands from the engineering teams dictated that they learn and implement new technologies in a very short time. Technologies ranged from configuration management tools, cloud platforms, storage, networking, load balancing services, monitoring services, and more. Besides when engineers wrote configuration templates as Enogo did for AWS, it was hard to figure out who owned the deployment stack. In the case of problems, it resulted in pointless blame games. So they desired a clear level of separation between code, deployment automation, and infrastructure. Technologies and cloud platforms could come and go, but IT operations remained responsible to maintain smooth workflows, stable builds, and error-free deployments.
A service catalog also met the needs of the IT operations teams. They wanted to build and manage specific platforms, runtimes and version configuration changes. Collaboration was a key factor. Many IT operations team members and engineers were experts in some but not all technologies and tools. But together in a collaborative platform, experts could contribute at their skill level and share knowledge with others. Automating configuration changes in bulk saved a ton of time. Therefore, API support for automation was high on their wish-list.
The IT managers were important though indirect stakeholders. They often approved and handled audits, compliance, and budgetary aspects. Policies and cost management were paramount to them. IT managers needed control and oversight to implement compliant deployment policies that gave the right level of access to the right set of infrastructure on pre-approved cloud providers. They needed to set and monitor quotas and track IT spend on cloud deployments against approved budget.
Transformed enterprise
After three months of evaluating proof-of-concept solutions with vendors, they zeroed in on a solution that met all of their uses cases and helped set up their current builds. Because of this, the teams were able to ship code ten times faster. It was only a matter of time before D-Chip stood out as a market leader. It was clear to the company executives what was driving this transformation.
They retired the semiconductor business and switched their business focus entirely to SDK builds of software for wearable computing. The software services for wearable chips was now way more valuable than any piece of hardware. Their customers in wearable computing now consumed D-Chip technology as a service in the cloud. A faster and efficient software development lifecycle enabled them to carve a new market niche and become the de facto leader.
The transforming story of D-Chip is a reminder for us all. When there are problems in software development, by aligning goals and helping people in different roles work together and participate in the development lifecycle, you increase the pace of innovation dramatically. It can be so powerful that it can transform the company’s core products or services.
Disruptive change doesn’t happen one step at a time. It happens with mavericks and innovators like Rachel and Chandler leading radical changes in a focused group effort. You want innovation to transform your business? Get a dedicated group of mavericks together and make it happen.
Just like mankind advanced their understanding through each cycle of civilization from the stone age up to the Renaissance and the Industrial Revolution, the future is heralded by the IT age of our times.
