When Agile and Scrum first disrupted the IT industry, they were thought of as something that changed how we managed software development projects. Over the years it has continued impacting the other teams that work in technology based companies – implementation teams and operations teams. Albeit at times in a blended fashion, where some agile concepts are adopted or morphed variations have emerged. Such as the emergence of DevOps, an Agile practice that focuses on collaboration and cooperation between development and service operations teams. Still, I find it ironic that the origins were in development, while in truth the other teams are probably better suited to an Agile philosophy.
It’s one of those things that happen when something disruptive comes along. Being customer-centric in their nature, implementation and operations teams didn’t have as great a need to move towards Agile as development teams. The old development teams were often closeted away for months, creating what they thought was best for the customer; it is no small surprise that a large percentage of development projects failed when released to the market. There was a pressing need to change things in order to improve that win/loss rate. So the change occurred first where it was most needed – in the development teams.
But a discussion on why Agile came to be is an aside to what I want to talk about today. What I believe is that these other customer-facing technology teams have actually been Agile teams all along.
To me, a customer facing implementation team already has the soft skills that are required for a team to adopt an Agile methodology. What they might be missing is the hard skills or the how-tos of changing to Agile or Scrum. So adopting the mechanisms of Agile and Scrum is actually not that big a reach. In my humble opinion, hard skills are much easier to adopt. It’s the soft skills that are hard to develop. It just, shall I use the terms… all in the implementation or ongoing execution.
Firstly, what do I mean by an implementation team. These teams are the people that take the product, the output of the development team, and do whatever is required to make it go live. So in addition to product-fit, implementation projects can include customizations, migration or transition of data and users from one system to another, operational handover and user onboarding. They are concerned with insuring things like capacity and availability. Things that sometimes seem more like managed tasks to be scheduled rather than features to be built.
So what are the Agile soft skills that have always been an integral part of these teams?
Collaborative Cross-functional teams
Not only are these teams cross-functional, drawing on different disciplines, they are often cross organizational. Often an implementation project is a collaborative venture consisting of team members from both customer and vendor, even multiple vendors or partners. As well, I’ve led projects, where the deliverables span a company and the representatives reporting into the project are the actual functional managers of teams impacted. All of these types of teams do not work if you impose a hierarchy, but function because of shared focus on the project goals. Though they may appoint a leader that manages progress, they are in truth self-organizing.
Focused on Customer value
While Agile methodologies and Scrum user stories bring a more succinct clear definition of benefits, traditional implementation projects have always focused on delivering on customer value. Being so closely connected to the customer has meant that it is easier to understand what the customer’s definition of success means. As a vendor, managing acceptance and managing payment are hand and hand. For most implementation teams that are measured on service revenue targets, focusing on customer value is not only a philosophy it is a necessity.
A shared definition of Done
Speaking of acceptance, implementation projects always include a definition of acceptance criteria. Even to the point of this often being a schedule in the contract. Done is defined up front and is clear to everyone.
Iterative, time-boxed deployments
The industry has always had some version of iterative deployment. Whether that’s a managed pilot, rapid development, or staged rollouts. More often than not, implementation projects have been agreed fixed-price contracts, with penalties for slippage. What Agile has brought to the table, is that this is not a tighter time-box, and scope can be reviewed and changed easier between time-boxes. It is a better way of managing the scope of what is agreed to be delivered in the time-box.
Team leadership is focused on removing obstacles
I strongly believe that one of the key mandates of any project manager is to enable the team to work. This is often about removing impediments, providing them with the right tools and knowledge they need, and protecting them from external politics and interruptions. Like a Scrum Master, the best implementation project managers hone this ability.
Measurement of progress
Every project methodology or framework has some means of being able to measure how close to “done” you are at any point in time. Whether that’s the old school waterfall project “earned-value” or a Scrum sprint burn-down chart. The point is that measuring completeness should be in terms of how much of the value is delivered whether than consumed day units.
Finally,
So for all those non-development IT managers, who have been looking from the outside-in at what Agile and concerned about whether or not to adopt it into their teams, take heart. As I said in the beginning, I think that you are Agile already. It’s just that you need to consider some of the hard-skill practices in terms of the best ways to incorporate it into how you work today.
