Becoming part of a continuous delivery team can seem daunting. Being tasked with creating one, even more so. But it doesn’t have to be that way. Taking a step-by-step approach and having your end goal in mind can get you and your team there intact. Here are some tips that I follow as we move toward continuous delivery in a way that is sustainable for my business partners and my team, and that minimizes risk to delivery.
1. Start with Business Capabilities
I know this sounds prosaic if not a bit overused, but it is a great guiding principle. When I understand how my clients view what they deliver, it helps me understand how to best align my team to enable them. For example, my portfolio contains a tool that manages third-party logistics. Considering that some parts of my portfolio have 24 tools in them, this one tool doesn’t seem very important. When I spoke to my clients, however, they explained that third-party logistics is a separate capability. Even though it is one tool on my end, there is a whole team aligned to this capability on the business side and millions of dollars in business that passes through it. Understanding the clients’ priorities and what they deliver to whom helped me build a solid foundation for my plan.
2. Understand Processes, Group Your Portfolio
Once you understand what is being delivered to whom and the relative importance of each area within your portfolio, get to know your clients’ processes. What does their work flow look like? How does what you deliver help them be successful? Start groupings within your area by assets (also known as tools). Know which assets support each process and capability and group them accordingly. I am fortunate to have a business process architect that has done extensive mapping of capabilities to processes, and an IT architect with experience in mapping processes to the assets. If you are in a situation where none of this work has been done, start small. One capability at a time. Map capabilities to processes then processes to assets. Set goals for yourself along the way – one capability mapped per week – and you’ll get there before you know it.
3. Decide on Who and Where
After you determine how your portfolio will be aligned in a continuous delivery model (how your portfolio’s assets will be grouped), decisions need to be made about who will work where. This approach is different than our current pay-to-play model where teams start and stop based on projects. In this model, our teams are aligned to capabilities.
They wholly own them, so we need to plan for some of the finer details that will enable the teams to work together effectively:
Location: I am building my teams so that no more than two locations are engaged together on a portfolio at a time. In practical use, this means that I could set up a team in North Carolina / Bangalore or San Jose / Jerusalem but would not set up a team in North Carolina / Bangalore / Jerusalem. Why? In a distributed Agile model, each location puts additional caveats on the availability of the team, along with an added layer of complexity. To KEEP IT SIMPLE, stick with two locations for the actively assigned, deliverable-owning team members.
Vendor / full-time employee mix: I am building my teams from a starting position of having many vendors in my mix. One of my main needs in moving to a continuous delivery model is for knowledge to be retained longer term because massive amounts of documentation are not usually done in this model. As such, I need the following: 1) vendors who stay on the account for longer periods of time, retaining knowledge (this also reduces turnover and scrum collapse); 2) additional full-time team members so that at least one full-time member is present on each portfolio team, retaining knowledge; and 3) a minimal amount of key documentation that is completed for every asset, so that teams have collective knowledge in case key team members leave or rotate to new positions. Ensuring that you communicate these needs to your vendor partners is critical during this transition, as is leveraging their knowledge. Most of our partners have entire organizations dedicated to things like DevOps or Design Thinking or Value Stream Mapping or Agile or Kanban or SAFe. Take advantage of industry knowledge and leverage vendor partners’ skills to help your full-time team make this transition as well.
Training: I cannot emphasize enough how important it is that EVERYONE at ALL LEVELS in the company take training for this transition. My entire team is getting certified as Scrum Masters, and not because I’m running a team of Scrum Masters. Some people will take on this role, yes, but I deeply believe that you cannot do something that you do not understand. As a leader, you certainly can’t lead something you don’t understand. Learn the different methodologies out there – Agile, Kanban, SAFe – see what makes the most sense for your team. Or better yet, let them decide. Having truly empowered teams is what this is all about. Make sure that training is a regular part of your team’s work, built in to schedules and budgets. And get a coach. For each team, I’m serious. It’s an investment up front, but having someone there with you to help work through whatever continuous delivery methodology you choose can make all of the difference in the world. Be the SME that you are, and let a coach help you make the transition to a new way of working.
4. Decide on When and How
Now that you know your playing field and the players, it’s time to play. But when and how do you start? Determining timing and approach is critical, but the real determiner of success is partnering well with the business. Continuous delivery is a joint transformation, so just having IT move toward it is not enough. What good is delivering something your clients are not ready to use? What good is having an Agile team without a product owner?
Tools: Ditto. Don’t stress about which tool to use. There are a ton out there. Having a whiteboard with “In Progress,” “Completed,” and “Blocked” columns is often the best tool to use.
Methodology: Determine how you want to work. No single methodology is a silver bullet. None are one size fits all. Collaborate with your clients to determine what work style makes sense for your joint teams and best suits your portfolio and assets. Try it out, throw it out, try again until you find the way that works. This is where a coach can come in handy, to help you weather the first few storms. The most important thing is to pick one and get started. It gets much easier from there. Just jump in.
Phased versus one-and-done: My team is taking a phased approach to continuous delivery, moving chunks of our portfolio as the clients are ready to go with us. I believe that there are situations where a “one-and-done” approach – everything going continuous delivery simultaneously – may work just as well. In either case, it’s important to involve your clients. Prepare a plan together, then communicate, communicate, communicate.
5. Focus on Change Management and Keep on Talking
Staying in touch with one other and allowing for some margin of error is critical as we move down this road. We are all doing something that most of us haven’t done before. It’s important to be kind when things go wrong, because they will. But that’s OK. We’re learning faster than we’ve had to in a long time, and risk taking is a huge part of our journey together. Keep talking to each other. Challenge assumptions, be curious, ask questions. Approach each problem with “How might we . . .” instead of “We can’t, so . . . .” Have a plan in place for how your team will move to a new delivery methodology. Then talk about it. A lot. Provide input on what will and won’t work, test it out, throw it out, try something new. Cisco has great collaboration tools, and we use them. Our remote team members have a DX-70/80 to enable more real-life communications and integration with the Cisco Virtual Whiteboard. Distributed Agile teams use Cisco Spark to share ideas and keep their important information in one place, not lost in email.
In my team’s journey toward continuous delivery, there have been, and I’m sure will continue to be, bumps in the road. By building a team focused on sharing information and ideas, however, we work collaboratively to create the environment that we want, where IT is truly one team, working in concert to deliver excellent results in a timely fashion to our clients.
CD is a very exciting tool for IT! Your article reminded me of two clear lessons that make for better products, alongside the speed that comes from CD:
– continuous interaction with the customer, who guides development with frequent updates and course corrections, rather than “taking or leaving” it at the end; and
– continuous collaboration among a team of app developers, who work closely together despite global distances.
Thank you for sharing this!
Great content !!!