Find experts and specialist service providers.
It all started with a desire to change the way we supported a Commercial Marketing application deployed in over 50 markets. The Commercial Marketing IT Center of Excellence had a lot of talented associates with deep knowledge and institutional history, but change had been slow to come, and we were still busy rolling out the application to the remaining handful of markets.
“Find a better way to support the application. At the end of the day, you will be judged not by how you delivered change, how you delivered better business value, but by your ability to satisfy the needs of your customers – that is the best strategy of all.”
The end of the 8-year rollout was near. However, with 9 discrete code bases, long lead times to deliver upgrades, plus the high cost of support and maintenance, the future did not seem bright for an application that ultimately generated over $8 billion in annual sales and revenue.
Significant effort had been made to control out-sourced development and testing costs. This included enforcing vendor penalties for delivering code that did not meet agreed KPIs. But that was not enough.
What mattered most were the needs of our customers. The business was getting impatient and several key markets had not seen an upgrade for years. Multiple enhancements had been made to support financial reconciliation, for example, but the landscape had turned one region’s demands against another.
Would Europe continue to steal the show and get their business critical enhancements prioritized over Latin America? Would key markets in Asia Pacific get a version of the code that they would be stuck with for years to come?
As the business grew impatient and users got accustomed to workarounds, we knew there had to be a different way of working; there had to be a different way to deliver evolving business requirements in a timely and affordable manner.
Also, we had to create a climate where business owners in each region would not panic every time the upgrade train did roll by and throw every possible enhancement our way, whether it made business sense or not – and don’t even ask about Return on Investment.
The business needed to feel empowered, they needed to be engaged, and they needed to know that enhancements would be iterative and part of a highly visible product road map with a consistent release schedule.
It was clear – a Waterfall delivery approach had worked well for new market implementations, but it would not work to support the demands of 50 plus markets running on 9 code bases. We needed to consolidate the code bases into 1 and implement a regular release schedule (we targeted every quarter). How were we going to accomplish this?
Agile was the answer. From white papers to case studies, everything we read pointed us in the direction of Agile. Scrum seemed like a good choice, especially when you are first starting out – and it worked, but not without quite a bit of initial pain and frustration.
How were we going to convince the overall team and stakeholders that Scrum was the right approach?
“This is the way we have always worked and we don’t need change.”
Change is challenging no matter your position, no matter your experience. There was resistance to a new way of working from executives down to junior developers.
Here is how we succeeded in turning skeptics into believers and disgruntled business stakeholders into satisfied customers – our 10 step approach.
(1) Hire an Agile Scrum coach.
We interviewed many candidates. It took weeks to find the right one but it was well worth the search. We needed a coach that acted like a coach and not like a Scrum Master or Product Owner. We needed a coach to bring out the best in every team member – to understand from the start that resistance to change can breed contempt, but dialogue and communication can eventually shatter obstacles and roadblocks, and lead to dedication and commitment.
The coach spent time every day talking to individual team members and to the team as a whole, and patiently walked through the key components of Scrum, from Sprint Planning to Retrospectives, from User Stories to Estimating, and from to Daily Stand-Ups to Product Backlogs and Burndown Charts.
Make sure you know in advance what characteristics you are looking for in a coach including skills, experience and personality type. Do not settle until you find the right match for your company, for your team and most importantly, a coach with the right cultural fit.
(2) Co-locate and in-source the core Scrum team.
Co-location is a luxury – no doubt about that. When it’s possible and you are starting out with Agile, don’t underestimate the advantages of co-location. Members of the team may not be best friends, but at the end of the day, you are not looking to foster friendships.
You are looking to develop a team that works well together, that has the time and consistency to understand how to work well together, and that trusts each other. Proximity and face-to-face contact greatly facilitates this.
Distributed teams can work well and there are multiple studies on how to scale Agile. Visual and verbal communication is paramount to any successful Agile organization and investment in the right tools to facilitate communication is critical.
We in-sourced the core team. Many companies work with distributed and out-sourced teams. The model does work and very well in many cases. We found that when an application is custom built and supports multiple unique business processes, building a Scrum team with full time associates can help minimize turnover, build credible trust more quickly, and lower application Total Cost of Ownership.
(3) Start with a White Board and Post-Its.
There are many excellent cloud based Agile collaboration tools. Where to start? We looked at several, assessed strengths and weaknesses, and tried a few free versions. Our coach had other ideas.
We wanted to walk before we ran and it felt like old school, but a White Board with Post-Its worked wonders. It got every one comfortable working together, it facilitated Daily Stand-Ups, and we had fun gathering around one large board with progress markers that we could physically move.
(4) Get designated associates certified as Scrum Masters.
There is nothing more satisfying than to have a team member complete training and feel inspired by Agile – not just as a methodology, but also as a mindset.
There is nothing worse than to have a team member complete training and state, “that was a complete waste of time,” and “I could have learned in one hour what the course covered in 2 days.” I have seen this first hand and there are many trainers who inspire through style, exercises, anecdotes and games. Don’t settle for anything less than inspirational.
(5) Identify key application owners in each region and train them as Product Owners, and formalize the role of Uber Product Owner (if applicable).
Product ownership is not a part time job. A product owner may not have the formal title, but you can never underestimate the value of “ownership.” The Product Owner is ultimately responsible for what is being built – from vision to value creation. There are times when you have to settle for empowered proxy product owners but the real thing works best.
I highly recommend Product Owner training for all key business stakeholders. This can have a positive ripple effect on the organization as a whole and solidify the importance of Product Owner engagement.
If the business wants a product that delivers the value they want and demand, then the Product Owner must remain engaged throughout – individuals may come and go but the role is critical to realizing the best of Agile.
In many cases, we had to work with multiple Product Owners. Here, look for a an Uber Product Owner – one who can influence and has final say as to what gets prioritized in the Product Backlog and in each Sprint.
I once assigned a Product Owner for maintenance work and one for new features, but that didn’t work very well. When the team is co-located and you are working with one market, for example, stick with one Product Owner.
(6) Give yourself time to learn Agile (we took 6 months).
No one ever seems to have enough time, and time to market is of the essence. How do you transition to Agile when the “project” is already underway?
If you can start with a blank slate, then take it – and you will need a few months to get up and running. The first sprints will offer great learning experiences, and will, at times, delve into skits right out of the Three Stooges. Trial and error!
We had the Agile Scrum engine up and running smoothly after several months, but we knew we needed time to make a lot of mistakes, and we made sure that we made this clear to senior stakeholders up front.
And if you are transitioning from Waterfall to Agile, for example, mid flight, find a way to draw a line in the sand. One way is to carve out a project or program deliverable that can be isolated and deployed separately, and give Agile a try.
Remember, projects have a specific start date and end date. Agile by definition never ends – you continually iterate on the product.
(7) Work closely with all members of the team and help associates find other roles if the situation warrants it.
You can be on the right bus (organization), but just in the wrong seat (role). Finding the right seat is important. Or you can just be on the wrong bus. There is nothing wrong with that, but you need to find the right bus and move on.
Sometimes, you have to have the courage to remove people from the bus – it’s a metaphor I have heard often and a difficult topic to broach, but it is not an uncommon situation. Treat the situation with diplomacy and work with your HR partners. Do what is best for the team.
All of the training, coaching and incentives in the world may not be sufficient to convert determined Agile skeptics; the longer the person stays on the team, the more harmful it can be.
(8) Have the courage to de-scope priority Epics (and/or User Stories) if time constraints prevent value from being delivered.
The end of each Sprint is supposed to bring releasable production code. This does not mean that the code will be released. This will depend on the decision of the Product Owner. If code is not released to production, then in reality, no value has been delivered to the business from that Sprint.
We were fast approaching the end of year code freeze and we needed to consolidate the first 3 code bases (2 in Europe and 1 in Latin America). One week into the last Sprint, we knew that one Epic high up on the Product Backlog would not be delivered. We had a working front end prototype but the backend was several Sprints away from delivery.
We worked closely with the regional Product Owner responsible for the one Epic and made the smart decision to de-scope it for the year. We agreed to pick up the Epic early in the following year. The debates were tough, but we knew that we would put consolidation of the first 3 codes bases at risk if we kept on going with the one Epic.
We would have risked not delivering anything to production for the year, which could have had a devastating impact on the organization’s view of Agile.
The Scrum team, Scrum Master and the Product Owner had the courage to make the right decision, even in the face of initial criticism from senior stakeholders – criticism that turned into understanding and acceptance several months later.
(9) Test out various cloud based Agile Scrum tools and don’t hesitate to select a free version to start with if necessary.
Once we had matured with the White Board and Post-Its approach, and had developed a consistent velocity and throughput in each sprint, it was time to look at Cloud Based tools.
We did start out with a free version and made sure we were comfortable working with the tool before investigating paying versions. Choose carefully. The cost of change is often high and once the team is used to one tool, they may not want to change tools again (and again).
With large organizations, I find that several Agile silos can develop, with each team using their own tool, leading to enterprise wide inefficiencies and duplicate spend.
Where possible, I highly recommend that organizations invest in enterprise wide Agile tools (Cloud, SaaS or on-premise). In this way, Agile can be formally incorporated into the company’s delivery DNA, including resource allocation tools.
(10) Make sure that Agile is formally incorporated into the organization’s SDLC and PMLC IT PMO framework.
Enterprise PMO methodologies and standards, even when it comes to Agile, cannot be overlooked. There are often formal templates, governance structures, and policies and procedures.
Agile has less chance of enterprise wide adoption and success if it is kept outside of an organization’s formal PMO framework. Ultimately, Agile must become an integral part of an organization’s development and release methodology.
This will help validate Agile as an accepted company wide standard. Agile is not right for all software delivery, but the option must be there. The value of iterative development cannot be understated.
And finally… just do it!
The time is now. Most organizations will have applications that are ripe for an Agile delivery approach. The only way you will discover the benefits of Agile is to try it for yourself – and I guarantee you that in most cases, you will see the benefit.
Some Lessons Learned
- I thought from the start that Agile would be fairly straightforward to understand, more of a challenge to implement, and easy to screw up. I was right.
- When there is dissent, and Sprints deliver little quality and releasable code, and team members get bogged down in resisting change rather than seeing the big picture – then patience, dedication and commitment to seeing Agile through can be challenging, but is well worth the effort!
- All members of the Scrum team must generally believe that Agile is the right approach and accept that the team will continuously learn.
- If the team is not convinced that Agile is the right approach, do what it takes to convince them through words and actions.
- Organize in-person training (both internal and external).
- Hold group and individual discussions.
- Review case studies from other companies.
- Make it clear that success takes time and that daily stand-ups, sprint planning meetings, reviews and retrospectives, burn down charts and user stories (to name but a few), take time to get right.
- Practice, practice, practice – which may not always make perfect but moves the team in the right direction.
- Ensure that senior stakeholders back up the team and support the Agile approach.
- Webcasts and webinars are ok substitutes when in person training is not possible, but don’t underestimate the value of face-to-face interaction to excite people’s passions.
- Even one member of the Scrum team can bring the whole team down and create negativity that significantly impacts development velocity and team cohesion – make sure you see the signs in advance.
- I mistakenly thought that the positive will of the overall team would raise the performance and attitude of weaker players, but just the opposite occurred.
- Continuous investment in software and applications is critical to maintaining the health of the Scrum team and keep them focused – without the mandate to generate iterative value, the justification behind supporting a dedicated Agile Scrum team comes under question.
- Keep IT stakeholders engaged throughout, especially those funding your Agile Scrum team budget, but beware of signs of micromanagement – keep the RACI in mind and inform key stakeholders in advance of progress and impediments.
- Make sure that business stakeholders understand the value Agile Scrum is bringing to the organization – is the Agile delivery approach impacting the P&L, is additional revenue being generated, costs saved or costs avoided?
Less than 16 months after launching Agile Scrum, we completed the consolidation of all 9 code bases into 1, and set in motion a standard release schedule the business could rely upon.
Let me know how your Agile journey is going.
Article by channel:
Everything you need to know about Digital Transformation
The best articles, news and events direct to your inbox