It takes a village to make an Agile transformation successful in any company. Leaders who’ve decided to implement Agile often find they need data and success stories they can offer their peers so the entire leadership team understands, supports, and feels confident in the decision to transform. The following are talking points for you to share with your colleagues.
So, will Agile deliver? Yes!
In 2017, VersionOne’s 12th Annual State of Agility Report reveals that organizationsare seeing positive results in the areas they set out to improve when they decided to undergo an Agile transformation. In fact, “four of the top five reported reasons for adopting agile” are also reported to be the areas most-improved by adopting agile. These include:
Alignment between business leaders and departments
Agile organizations put heavy emphasis on transparency and communication between all levels of the business, allowing for clear alignment on goals and the quick removal of impediments.
Management of changing priorities within the business
The iterative nature of Agile accommodates for a business’ ever-changing priorities, giving leaders the time to reevaluate often and pivot in response to market changes as opposed to falling behind competitors.
Productivity
Agile principles and practices increase productivity by limiting waste in the production system complexities, such as handoffs, dependencies, late integrations, etc. This results in the reduction of repeat work, defect costs, and failed initiatives because issues are uncovered earlier in the process.
Delivery speed/Time-to-market
An iterative release cycle also allows teams to release smaller, bite-sized chunks of a product more often. Instead of getting tied up in (incredibly) long-term plans, teams typically release products every 2-4 weeks. Once an organization becomes predictable like this, feedback loops are tighter, giving the organization the ability to give customers higher quality, more valuable products.
Agile has proven time and time again to bring benefits to every level of an organization. Thanks to these benefits, it has rapidly taken over software development and is now spreading to other departments from marketing to human resources and beyond. Today, results of an Agile transformation are branching out to include things like more leads, higher employee engagement, and more recruits.
How do you ensure a successful Agile transformation in your organization?
As with any aspect of business, when you understand and utilize best practices, you see more impactful results at a quicker rate. But don’t take our word for it–take it from others just like you.
For their 2017 report, VersionOne surveyed 1,492 people in Agile organizations from around the world and put together a list of their top 5 tips for success in Agile. These tips included:
1. Developing internal Agile coaches
2. Using consistent practices and process across all teams
3. Implementing a common tool across teams
4. Investing in external Agile consultants and trainers
5. Protecting your Agile transformation with an Executive Sponsor
Over time, we found leaders are more often than not looking for a way to make informed business decisions with confidence. Without a predictable cadence of delivery, organizations are usually flying blind when it comes to making decisions about sequencing work and planning for how those decisions will impact their market and the forecast of all initiatives in flight. Agile is helping companies across many industries solve these problems.
We hope this article provides you with a few key points to bring up to coworkers when chatting about Agile. If you’re interested in learning more about how we help organizations build lasting agility, check out our Agile Transformation Services page. We’ve incorporated these top 5 tips coupled with a focus on producing desired business outcomes into our approach to ensure lasting organizational change.
Agile Velocity’s Path To Agility® describes the activities and outcomes of implementing Agile and their impact on culture and business goals. We have taken repeatable patterns we have seen with our clients and combined them with organizational change models as seen in the Path to Agility® video below.
Summary:
Align – A critical first step, alignment occurs when leaders in an organization understand the business objectives that will be achieved with the transformation and communicates those objectives to the entire organization in a clear way.
Learn – Through training and guided practice via Agile transformation coaching, teams and leadership are equipped with new techniques and an understanding of how Agile works. Ownership of processes are transferred to an empowered team, and a culture of continuous improvement is put in place.
Predict – Teams solidify these newly learned practices and become more disciplined in applying them. This allows them to begin working in a predictable and iterative manner, enabling leaders to better forecast and to make informed business decisions.
Accelerate – Once the teams become disciplined and predictable, focus is shifted to organizational improvements to optimize across the full delivery cycle and shorten time-to-market.
Adapt – Agile begins to permeate throughout the organization. Teams are empowered, and leadership is able to respond to ever-changing market demands. During this stage, the organization achieves true business agility.
Getting Started On Your Organization’s Path to Agility®
Before embarking on an Agile transformation, it’s often helpful for leadership and sponsors to meet with experts to assess their “readiness” for an Agile transformation. For example, before any engagement, an Agile Velocity Coach meets with leaders within an organization to answer the following questions:
1. What is the organization struggling with specifically?
2. What business outcomes does the organization hope to achieve?
3. Do you have the talent and knowledge to implement Agile successfully?
4. How will you measure the success of the transformation?
You can learn more about the Path to Agility®and our approach to Agile transformation on our Transformation Services page.
In this webinar, Mike and Bryan discussed different tactics and practices that organizations can take as they begin to scale agility across the organization. You can find the webinar summary and Q&A transcription below.
Summary
Start Simple
There are a number of really good Agile scaling frameworks out there–SAFe, DAD, LeSS, Enterprise Scrum, etc. Some can appear overly complex and scary at first glance.
Start simple. Don’t immediately align with any specific framework. There are some common best practices that most of the scaling frameworks out there recommend, so just start there. Then evolve and grow over time by adding a bit more here and there as your organization’s needs dictate it.
5 Practices to Start Scaling Agile
Scrum of Scrums
Chances are you are familiar with the Daily Scrum that is held every day within the Agile Team, to synchronize efforts around the plan for today. Scrum of Scrums is a scaled version of the Daily Scrum – to ensure that the cross-team work is synchronized.
Product Owner Sync
The purpose of the PO Sync is to ensure alignment of the product vision and work-related content across all involved teams. SAFe and Scrum @ Scale scaling frameworks recommend this scaling event.
Program Backlog
When multiple teams are working on the same program, it is important to establish the Program Backlog. The Program Backlog is created and maintained by the Program Manager role or perhaps even a Product Owner from one of the teams. The Program Backlog consists of features in priority order.
Dependency Identification and Scheduling
One of the biggest risks when scaling Agile is inter-team dependencies. To mitigate these risks, teams working on the same program should plan together (iteration planning and/or release planning) to identify the dependencies between teams.
Dependencies are bi-directional in that there is both a giver and a getter. To ensure visibility, each dependency should be tracked within the Team Backlogs as either a “Give” or a “Get” as shown in the diagram.
A “Give” is where one team provides a specific deliverable to another team on or before a specified date or iteration. A “Get” is where a team receives a specific deliverable from another team by the specified date or iteration. A “Get” user story will typically involve integration activities across teams.
Common Integration Environment
You will need to establish a common integration environment for multi-team programs. Ideally, this is done prior to iteration 1 to ensure demonstration of working software from the integration environment each and every iteration.
Typical activities in establishing a common integration environment include:
Server setup
Network access
Continuous Integration (CI) tooling
Source code repository program mainline branch establishment
Test case automation
Automatic deployment migration from local to integration/staging environment
Questions from 5 Practices to Begin Scaling Agility Webinar
Where does the security testing occur on slide 14? Is it assumed to be part of the unit & validation tests?
Yes. In an Agile organization, security concerns need to be considered as we go within each iteration. This leads to unit testing and functional testing for the security requirements.
What is your recommended “planning” approach for a given development timeline (e.g. 6 weeks or 1 qtr)? Specifically, getting ahead of cross-team dependencies.
I recommend quarterly release planning with an emphasis on identifying dependencies and making them visible. SAFe has an excellent technique for this called the Program Board.
Are the % usage of SAFe vs LeSS vs others just in the US or across the world? I have heard the LeSS is more commonly used in Europe and possibly Asia.
The cPrime survey referenced received responses from all over the world.
Understanding there is a Scrum of Scrums (S2), what are your thoughts on scaling that further to a “Scrum of Scrum of Scrums” (i.e. – S3) or even an S4? We’ve seen this implemented to create sync points across multiple trains (S3) and value streams (S4). Thoughts on this?
Scrum of Scrums is definitely fractal and can be scaled up as needed. Specifically, a “Scrum of Scrums of Scrums” is useful in coordination of large solutions involving multiple programs (or Agile release trains) as you mention. I personally have never seen it beyond 3 levels (S3), but it is theoretically scalable to the nth degree.
What works best for Scaling, Scrum or Kanban?
Both can be scaled. Many Kanban teams take a “Scrumban” approach by including some best practices of Scrum–in particular, the Daily Scrum. Thus, scaling up to a “Scrum of Scrums” is a natural extension to the daily planning event.
If you’re looking to start a SAFe® implementation, we recommend starting with Leading SAFe® training. You can explore our public and private training options on our Leading SAFe® training page by clicking here.
Agile Roles are well defined in any foundational training for Scrum or Kanban. However, it’s not always clear who will be filling those roles as an organization begins using its chosen framework. Organizations are already fully staffed to their current way of developing software, and it stands to reason that most of the folks who will be working in the new paradigm will be transitioning from an old role to a new one.
At Keep Austin Agile 2018, I presented a talk called “So You Made Your Project Managers into ScrumMasters: Roles Transitions When Becoming Agile”. This talk went over common role transitions that occur during an Agile transformation and some of the challenges that come with these transitions.
The audience and I then thought through the various activities that happen during software development in traditional development frameworks, and who was responsible for those activities. Next, we migrated those same activities over to the new Scrum roles. We looked for patterns, noting where people in those role transitions picked up and lost activities and noted times where these activities might get lost in the shuffle. Finally, we looked at the skills that people in these role transitions might need to acquire.
Here is the collective output from these sessions, along with some of my own observations. Enjoy!
Team
The “Development Team” groups really keyed in on the need to become more self-directed. Becoming an empowered team is a bold step, and the power to create and execute your own plan comes with an equal dose of accountability. People crave this kind of autonomy, but it can take a while to adjust.
There are some keen insights in the skills area. As cross-functional teams are created, the clear code base ownership of component teams becomes more diffused. Also, there was good focus on the skills needed to become a productive member of a more independent team.
Start Doing:
Self-motivation
Be more accountable
Relative estimation
Meet Daily
Be a facilitator
Be responsible for a solution without approval from the Dev Manager
Learn Agile
Make Decisions
Being accountable
Committing to completing work
Take ownership of tasks
Take more accountability
Incremental/Iterative process
Commit to complete
Stop Doing:
Waterfall process
Skills That May Get Lost in Translation:
Enterprise Architects
Platform Ownership
Skills That Individuals May Have to Acquire:
Proactive communication
Becoming cross-functional (while being less focused on personal velocity)
Adopting practices that reduce technical debt
ScrumMasters
The ScrumMasters in our workshop had a commendable focus on supporting their teams and promoting the Scrum process, and on acquiring the soft skills needed to help the people involved. Amongst the activities they anticipated they would stop doing, the ScrumMasters focused on managing to a plan and being the person in control.
Interestingly, the ScrumMasters were concerned about the loss of focus on budgeting, dates, and documentation. I encourage them to find the opportunity to team up with their Product Owners and learn portfolio planning practices to understand dates and budgets in their new world.
Start Doing:
Creating and defending a sustainable pace
Protecting the sprint
Motivate EMPs
Making Process Decisions
Motivation Skills
Start coaching
Learning about ScrumMaster
Servant leadership/Facilitation/Coaching
Manage teams at a micro-level
Forward planning or “micro-planning”
Set clear expectations up to stakeholders
Manage teams at a micro level
Coaching devs on sizing
Serve your team–remove roadblocks, etc
Facilitation skills
Motivation skills
Be a cheerleader
Mentoring new dev members
Motivating team
Stop Doing:
Load balancing
Controlling the work being done
Micro-managing
Budgets
Stop being a “ScrumNanny”
Controlling everything
Robust schedules
Updating project plan
Creating a project plan
Knowing everything
Skills That May Get Lost in Translation:
People management
Proactive
Documentation
Managing budget
Making delivery dates
Making giant, meaningless documents
Tracing accountability
Scope Definitions
Powerpoint
Skills That Individuals May Have to Acquire:
Stakeholder management
Soft leading teams
Collaboration
Coaching
Coaching
People skills
Learn to be a servant leaders
Influencing
Get comfy with ambiguity
Leading by influence
Product Owners
The Product Owners understood their market and felt the weight of their new responsibilities to set the direction for the team. There were great mentions of gathering up incoming requests, handling external communications, and negotiating priorities. As for their interactions with the team, there was a focus on creating stability. There were a few puzzling comments. Market research was called out as something that might get lost. That is certainly not the intent here. Feedback loops with the market are especially important now that the teams will be releasing more frequently. This might reflect a concern about time management. New Product Owners often feel slammed when new responsibilities are put on their plates and the old responsibilities are slow to disappear.
Start Doing:
Business expertise in the product
Manage expectations to leadership
Breaking down complex projects
Communicate status externally
Keeping stakeholders informed
Convey product vision & goals
Relentless prioritization
Negotiating trades
Stop Doing:
Stop weekly status meetings
Stop increasing and decreasing burn rates on a dime
Status meetings
Dictating timelines
Interruptions
Stop schedule builds
Status reports
Skills That May Get Lost in Translation:
Market research
Skills That Individuals May Have to Acquire:
Planning skills
When is the product “Done”
When will the product be delivered
Agile training
Cross-functional mindset
Coaching skills
Managers
We were fortunate to have great representation from managers at the workshop. Their focus is clearly on setting up the ecosystem that will allow Scrum to thrive. This was demonstrated by things they were going to actively do, like pay attention to technical debt or be catalysts for change, and the things they were going to stop doing to create space for the teams to self-organize, like stop micromanaging tasks, plans, and development approaches.
More so than any other group, managers had many items they feared might get lost. Managers felt a lot of ownership for delivery, and they voiced concerns that this new process might not adequately fill the void if they stepped out.
Potential gaps were identified at almost every step of the process, from initial estimation to planning, execution, and ultimate delivery. Dependency and risk management were mentioned more than once. To clarify, managers often times have great abilities in these areas, and they have much to teach to their individual engineers, ScrumMasters, and Product Owners. But the emphasis should be on teaching, not taking control. Indeed, the one item called out as a new skill to be learned was “coaching and support”.
Many managers find that as they step out of the day-to-day execution management, they finally have time to mentor and develop their people and to set high-level departmental direction.
Start Doing:
Negotiating for tech debt, refactoring
Removing systemic impediments
Start managing scope instead of attempting to keep it fixed
Start being flexible with time frames
Move to Agile Test
Start creating an environment for self-directing teams
Be a catalyst leader
More training on how to operate as a self-managed team
Facilitation
More fully empowering team
Stop Doing:
Financials responsibilities
Stop scheduling every task to an end date move to sprints
Managing business objectives
Financial reporting
Stop managing team at a micro level
Stop using “middle-men” for decision-making
Stop managing the team at a micro level
Production validation process
UAT Testing
Creating detailed project plans
Being an expert leader
Ability to control development practices
Managing tasks
Stop directing
Stop managing to a date
Skills That May Get Lost in Translation:
Process driven
Vendor Management
Setting scope
Communication planning
Identify interdependencies
Help people get better
Scope changes
Estimating work
Be accountable to the organizations for completing work
Inter-project dependencies
Risk Management
Risk Management
Communication planning and execution
Skills That Individuals May Have to Acquire:
Improve coaching and support
Sometimes, Agile training just isn’t enough to help employees fully transition into their new roles. Schedule a free, 2-hour Agility Roadmap Workshop with an expert to help you understand the best next steps for your organization and how Agile Velocity can help your people feel better in their new roles.
According to the Bureau of Labor Statistics, the projected growth of employment opportunities for Software Developers from 2016 to 2026 is 24 percent. When you consider that the average growth rate for all occupations is 7 percent, you begin to realize that software development as an industry is growing much faster than other industries—meaning developers have a lot of options when it comes to where they can work. So how can organizations improve employee retention and keep good developers from running away to one of their competitors?
It’s time to face the truth: We have to consider the needs and desires of this new generation of talent if we expect to attract and keep the best of them in our organizations. A 2015 survey by Boston College identifies the top reasons why Millennials consider leaving their jobs:
To make more money
To move forward in their careers
To pursue work that is more aligned with their passions
To have more flexibility/better work-life balance.
Seems pretty reasonable, right? So why does employee retention seem so difficult to maintain when it comes to keeping Millennial employees?
Unfortunately, the secret to employee retention among developers is about more than simply increasing their pay—that isn’t great for your company and likely won’t be enough to stop your developers from accepting a shiny, new job offer. A better approach is to begin shifting your company towards a Millennial-friendly culture. This sounds simple on paper, but the implementation of these ideas can be challenging.
How Agile Can Help Shift Company Culture To A More Millennial-Friendly Environment
When companies set out to adopt Agile, they often find that a culture shift is necessary if they truly want to reap the full benefits of an Agile transformation. Inadvertently, they also end up creating a setting for Millennials to thrive, a place that puts their priorities of work-life balance, autonomy, and a chance to get ahead in their careers first. Here are a few ways Agile helps impact a company’s culture for the better:
1. Alignment and Collaboration
An important factor in employee satisfaction is an understanding of the organization’s endgame. When leaders clearly communicate their values, goals, and strategies, it gives employees a lens through which to view their work, and by extension, to make decisions regarding their work. When leaders fail to articulate these things, employees lack a framework to build expectations around. Beyond that, they lose sight of how their work contributes to larger company goals.
One of the twelve principles of Agile is “Collaboration between the business stakeholders and developers throughout the project”. All parties involved in the creation of a product should be aligned around a central vision and goal. To truly reach alignment, this communication has to go beyond a one-and-done kick-off meeting. Leaders and developers need to have an open line of communication and should constantly check in with one another to ensure that they are still on the same page.
In Scrum (one of several Agile frameworks), that level of alignment is achieved through a regular cadence of events that can help to build positive communication habits and instill collaboration into the culture of teams and organizations. Gone are the days of loyal employees who were content with following orders and “doing their job”. Today’s Millennial employees are looking for a greater sense of their role in the organization’s larger goals, giving them a better chance at finding that drive and passion for their job.
Developers—and employees in general—crave some level of autonomy, an opportunity to flex their skills without micromanagement from supervisors. Giving your developers the space to make decisions about their work within the scope of their organization’s goals allows them to feel more connected to the team and the larger organization.
This doesn’t mean that employees are running wild. It means that managers are now playing more of a supporting role to developers, providing feedback and aid when asked, as opposed to simply assigning tasks and evaluating performance. A little trust goes a long way when it comes to keeping your employees!
When companies invest in their people, they’re investing in their future as an organization. Employees who feel they are continuously improving and that there is a path for growth in place within their company are more likely to stay loyal to their employers.
Snack Nation recently released their 2017 State of Workplace Culture Report, which shows that employees with a lot of growth opportunity report being happier at work. In fact, 61% of respondents say they feel more engaged at work when they’re being positively challenged. It makes sense: No one likes to feel stuck. People want room to grow and the support to do so. In order to improve employee retention long-term, organizations need to encourage and provide the space for personal growth.
Continuous improvement is highly valued in an Agile culture. While this certainly applies to the software being built, it also applies to organizational structure and individual growth. When the focus is learning and growing from mistakes, rather than hard repercussions, employees are less timid when it comes to speaking their minds or offering new ideas. They’re also more likely to report a feeling a personal growth from their role.
Conclusion
The cost of disengagement is very real. Disengagement costs in America are estimated to be upwards of $450 billion throughout various industries. The good news is there’s a lot of opportunity to decrease that number.
As Gallup points out, highly engaged business units realize a 41% reduction in absenteeism and a 17% increase in productivity. Engaged employees are showing up and producing higher quality work as a direct result of their environment. High turnover organizations are also seeing a dramatic decrease in turnover rates—a full 24% lower.
A shift in organizational culture is largely to thank for this. Every day, more companies are beginning to realize the value of investing in their employees and improving employee retention as opposed to simply trying to find new ones.
“Individuals and interactions over processes and tools;
“Working software over comprehensive documentation;
“Customer collaboration over contract negotiation;
“Responding to change over following a plan.”
For those of us in the Agile community, the Agile Manifesto is a wonderful expression of the True North of Agile software development – empowered teams, swarming to solve customer problems by collaborating closely with people who will actually use the things we’re creating.
But for many, especially those who deliver software in highly regulated environments, the Agile Manifesto can seem downright hostile. When dealing with audit requirements and compliance, the thought of Working software over comprehensive documentation can result in Agile processes being dismissed out of hand.
With the pace of change happening in the world, that would not only be a shame, but organizations working in highly regulated environments would miss the opportunity to get ahead of competitors by leveraging Agile processes and principles.
Regulations – Prescriptive vs. Descriptive
When working in a highly regulated environment like healthcare, financial services, or dealing with reporting and regulatory audits for the US Federal government – I find it incredibly important to use a quick mental filter to understand the types of regulation my teams are working with. Broadly, I’ve found that regulations and their associated reporting requirements roughly fall into one of two types: Descriptive rules and Prescriptive rules.
Descriptive, Using Scrum
Descriptive rules seek to provide a definition of a system or process as it is so that it can increase the repeatability of that system or process. I’ve found the most frequent examples of these Descriptive rules used in internal auditing processes and also emerge in quality processes such as the ISO 9001 Quality Management standards.
A key factor in adopting Agile in regulated environments where Descriptive rules are in play is to make sure you work closely with whatever auditors you have, internal or external, who understand your documented processes. When I’ve introduced Agile processes into ISO 9001-compliant organizations, I quickly began close collaborative conversations with our auditors to make sure they understood the interactive and incremental processes we were introducing. Once we identified the gaps and differences in the documented process, I worked with our auditors to make sure our new processes were properly documented. Descriptive rules are made to be changed to meet the work, not to prescribe solutions! (SPOILER ALERT: We’ll cover those in a second.)
Working with clients who primarily deal with these descriptive rules, I frequently look at the artifacts we can provide while using Scrum. The controls provided by a strict SDLC, especially around documentation, audit-ability, and traceability, can nearly always be met through well-written Acceptance Criteria and a light hierarchy of Epics to User Stories to Tasks. Further, most Agile software tools like JIRA, VersionOne, and Rally can provide for and automate the traceability documentation from Epic to production.
Prescriptive, Using Kanban
While Descriptive rules are designed to document a system as-is or as-it-should-be to provide a reference for a repeatable, quality system, Prescriptive rules are designed to create contracts and govern behavior. In organizations and teams ruled by Prescriptive rules, the sea-change in process and procedures introduced by Scrum can seem insurmountable.
As Agilists, it’s important to remember that while Scrum may have emerged as the most popular of the Agile frameworks – to the point where most people mentally equate “Agile” and “Scrum” – it’s far from the only Agile methodology or framework. When working with teams dealing with Prescriptive rules – such as those legally mandated by Federal agencies like the Food and Drug Administration or Securities and Exchange Commission – I nearly always fall back to Kanban.
Many of us conflate Kanban with the task board our Scrum teams use to make our daily work transparent. Kanban is a powerful Agile framework designed around documenting existing processes and applying rigorous focus toward maximizing flow. Using Kanban, we can find opportunities to incrementally improve our existing teams and processes.
By applying the principles behind Kanban, teams working under the constraints of Prescriptive rules can quickly adopt the principles of Agile.
Start with what you do now;
understanding current processes, as actually practiced
respecting existing roles, responsibilities and job titles
Agree to pursue improvement through evolutionary change;
Encourage acts of leadership at every level;
from individual contributor to senior management
While this isn’t an article about applying the Kanban principles and practices to your work, the practices themselves require embracing the Agile principles we know and love while also respecting the reality of the environment your teams exist within. Kanban’s practice of Visualizing the Workflow aligns perfectly with Agile’s embrace of transparency and openness; Limiting Work-In-Progress (WIP) closely aligns with the principles of simplicity and frequent delivery; Improving Collaboratively directly maps to the principle of regular reflection and improvement.
By using Kanban to map out your process, and then collaboratively look for opportunities to reduce bottlenecks and increase flow while also making and keeping process policies transparent and explicit, you can leverage Kanban to bring agility to your team and still meet Prescriptive rules and regulations.
Conclusion
When done well, Agile practices provide the means to create engaged and empowered teams who understand and embrace the need for regulations – both prescriptive and descriptive – and the means for those teams to own and optimize how their work is done while still meeting audit-ability, traceability, and regulatory requirements.
For more on our approach to building lasting business agility, you can check out our Transformation Servicespage.
A supplier of point of sale systems for the retail and commercial fueling industry faced an immovable deadline from a major client. While their teams were said to be practicing Agile, getting a working, shippable product was a constant struggle.
Agile Velocity was asked to assess their current practice and find ways for Teams to truly become Agile.
Unique Team Challenges
The assessment uncovered way process, culture, and organization structure prevented true agility. Big challenges included:
Poor backlog management
Continuous drip of new features into the backlog led to project scope creep.
Distributed Teams
Teams were distributed across four continents and multiple time zones.
Priorities Thrash
Key team members were asked to move to different priorities at critical times.
Limited User Feedback
Lack of understanding for users’ needs led to faulty product vision and waste.
Lack of dedicated Product Owners
Lack of alignment between business stakeholders and teams.
Led to resource waste and mismanaged expectations.
Struggling Agile Technical Practices
Integration threat due to individual teams working on separate branches of code and lLack of testing during Sprints
Our Solution
Agile Velocity Scrum coaches worked on location and implemented the Scrum framework with the team. At the completion of the assessment period, coaches worked with all levels of the organization to accomplish the following:
Product Owner Training and Coaching
Worked alongside Product Owners to define the scope of the release and groom product backlog to only items needed to deliver a minimum viable product (MVP).
Fostered collaboration between home base and distributed teams
Led Release Planning Workshops
Led a release planning workshop to educate teams, gain alignment across all levels, and create buy-in for the release scope of MVP.
Staffed Product Owners & ScrumMasters
Supplemented current system with tools that increased visibility
Provided technical coaching for improved integration and test strategy
Key Takeaways from the Client
Release management is intended to involve all of the teams contributing to the release and starts with a shared understanding of the goals. Visibility and frequent communication through Scrum of Scrums and better tools supported decision making and resulted in a quicker resolution of issues. In addition, Continuous Integration, a good branching strategy, and a well-planned testing strategy are important when working with multiple teams who may be distributed across different locations.
Measurable business outcomes include:
Tighter product vision
Measurable business outcomes to help set expectations and measure activity
Improved trust between business stakeholders and development teams
Better decision-making and improved expectations
Decreased Scope Creep
Predictable and accelerated Release Cycles
Sustained Agile technical practices
Want to see what Agile can do for your company?
Learn details about this particular engagement with a product company and other examples of our work.
The amazing thing about the human spirit is that we think we can do anything we set our mind to. The problem is that we don’t always follow up with, “but should we?” Let me tell you a tale of our deck.
Last spring my husband and I set a deadline to redo the deck that leads out to our back yard and subsequently our pool. The deadline: our baby becoming mobile. You see, a deck with unfettered access to a pool is not safe for a tiny human. Unfortunately, the deck we had led right into the pool without barrier, so my husband got to work.
He ordered a few books on deck building from Amazon, read them cover-to-cover, drew up plans in Google Sketch-up, and bam, we were ready to go. We put a project plan together, “hired” a few friends to come help us, and during one insanely hot June week, we built a deck. Sorta.
In organization after organization Agile adoptions fail because “Agile” is seen as something only technology teams do. They see getting to market faster and delivering more value as something that happens solely within the delivery team. Marketing, design, sales, and business development are seen as inputs or outputs to the delivery process rather than part of the delivery team.
An Agile transformation often requires a full shift in the culture and mindset of an organization, and that’s not an easy feat. Even if executives have a clear understanding of their goals, communicating these goals and aligning the company around them isn’t usually second nature. In fact, an article in Harvard Business Review on organizational alignment argues that one of the four reasons for a misaligned enterprise is that most organizations do not have enterprise alignment as a core function.
Signs Organizational Alignment Is Missing
Lack of camaraderie between the business side and Technology side
When there is a big divide between business and tech, each side is seen as the enemy of the other. The Business views Technology as “bad suppliers” and Technology sees the Business as a department without clear direction. According to the Scrum Alliance 2015 State of Scrum Report, 71% of survey respondents reported tension between their teams and the rest of the organization.
Lack of customer value-centric goals
A lack of customer value-centric goals ultimately leads to a company losing sight of their product’s grand vision. The value a product brings to the customer should be the North Star the entire organization aligns goals towards.
Tribalism
When things get siloed, weirdness happens. I like to refer to this issue as Tribalism. This occurs when tribes, or groups, begin to develop within an organization. Communication between teams is blocked, and productivity is limited. Inevitably, this leads to weird things happening and the formation of opposing goals.
Promises of Agile go unfulfilled or the transformation has stalled
Whether it’s six months into a transformation or two years, in our experience, a stalled and/or unfruitful transformation is one of the top reasons to invite an organizational coach. Getting predictable is one of the main promises of Agile so it may be time to call if spotty delivery continues to be an issue.
Coaching & Alignment
When we kick off a transformation engagement, the first thing we ask our clients is “why?” During the discovery process, we gain an understanding of why an organization needs our help so that we can help establish, articulate, and install the broad alignment needed for a transformation’s long-term success.
We meet with leadership to determine the root desires for the adoption and transformation. The goal for the transformation cannot be to “do Agile”; transformation goals must be grounded in measurable, strategic outcomes. Without empirical measures of success, how do organizations know when you’ve gotten to “Agile enough”?
Transformation goals can be tied to the business or be adoption-based. We help leadership fully articulate these goals and find a sure way to measure them. “What does success look like for you? What’s different a month, two months, six months from now? How can we measure this?” Defining the metrics they would use to track the goals they’ve created helps create accountability and direction. Example metrics include:
Improving product quality
Improving employee morale
Faster time-to-market
These typically vary from organization to organization, based on the unique business goals each may have. This gives our coaches a place to start when helping organizations to build their transformation backlog.
Broadening Alignment
It is important to note that having clear, measurable goals is only half the battle. These goals go to waste if only the high-level executives understand their significance. For an Agile transformation to successfully take root, there must be transparency and buy-in throughout the organization. Everyone, from executives to Technology, needs to see how each of their individual roles play into the larger picture.
Without this level of transparency, we begin to see a breakdown, and a greater divide between the executives and the Technology department begins to form. Next thing we know, everyone is playing the blame game. Executives are upset with Technology, and Technology is feeling underappreciated for their hard work. This, of course, all results in a storm of even more work for everyone.
In the latest State of Agile report, 19% of participants say a major challenge they face while adopting Agile is ineffective collaboration. Traditionally initiatives are broken down into individual components that are assigned out to individuals or departments to complete their portion. Dependencies are identified and everything is integrated into the end. The flow of information tends to be hierarchical, and collaboration is generally just meeting to manage dependencies. Typically, it all falls apart, in the end, little fits together correctly, deadlines are missed and frustration abounds. This is why an organization needs alignment from top to bottom— and back up again.
Visibility and Transparency
When we initially begin to experience transparency, there tends to be an element of horror on both sides. The business side assumes the tech side is always tinkering away on their products and is shocked when they find out what Technology is actually working on. Things like technical debt and infrastructure work seem like nonsense to the business side. However, these processes need to be kept in place to keep technology organization efficient.
Technology is horrified because business doesn’t understand the importance of their work. Even worse, they may not believe the outlined plans because priorities thrashing has given them whiplash one too many times.
With effective alignment and coaching support, this only lasts a little while. Coaches help discover all the work being done and make it visible to everyone. This allows the Business and Technology to have a much better understanding of how time and talent is being used currently so that programs are able to be prioritized in the future. Leadership is also able to see impediments slowing or blocking value delivery giving them the opportunity to address those impediments and set the organization up for future success.
Transparency can be scary at first, but it pays off in the long run. Having this richer understanding of what everyone is doing and how their roles and work fit together will allow a company to successfully follow their transformation roadmap and reach their goals.
Agile transformations aren’t easy. Often time, we see the transformation begin to fall apart when leadership fails to provide their teams with the direction and support needed to be successful and a system for maintaining alignment once the transformation is complete. We connect leadership to their teams and the rest of the organization to ensure that their goals are universally understood and achieved. The goal is for executives and management teams to build the foundation that will help them continue to be agile long after the push for transformation ends.
For more on our approach to building lasting business agility, you can check out our Transformation Servicespage.
Many organizations we work with are very budget-driven. Many organizations do up front funding and budget management. This process feels good, as having a plan provides clarity and accountability. However, this type of process leads to very bad behavior because of a few huge, and often, bad assumptions:
It takes a village to make an 
