I have been running systems & software engineering projects for some years now, the topic of "ringencing" teams seems to be quite a recurring one. It often comes up during the early stages of startup/initiation, or later into the project when stakeholders get quite nervous and edgy when the project begins to show signs of being in distress (i.e. the launch or completion trajectory doesn't look so good). One of the natural instincts for such management teams is to tighten up control, for example to ringfence all people with central command control within one single delivery team.
So what does it mean to ringfence anyway?
So what does it mean to ringfence anyway?
According to Google, enter "define ringfence" gives you:
ring fence
noun
noun: ringfence
- 1.a fence completely enclosing a farm or piece of land.
verb
verb: ringfence
- 1.enclose (a piece of land) with a ring fence.
- 2.BRITISHguarantee that (funds allocated for a particular purpose) will not be spent on anything else."the government failed to ring-fence the money provided to schools"
I have been on both camps: first as an engineer being assigned to support a project/customer; and later as the manager driving ringfencing agreements with vendors. As a software engineer, I didn't fully appreciate being assigned to a customer "You will work on only Customer A and nothing else. If you don't have work to do, speak to the customer project manager. We are getting paid exclusively to support this customer, so when you need to fill in your timesheets, we need to know in detail the tasks being billed for. Any item not having direct relevance or is not a direct requirement for the customer will not be billed for". In the product services development business (which is where I spent the bulk of my software engineering career in), this isn't strange at all. Teams get assigned to customer, we work at the behest of the customer, taking work requests in via the customer delivery manager. It does get a bit more challenging though, when your product on offer is actually designed in such a way to be generic with some customisation, such that you only need just one core development team to satisfy, simultaneously, the requests from multiple customers (at the same time), in which case, a ringfenced team makes less sense...but hey, we're being paid to do the work, without the customer, our product is not going to sell, so if customers wants a ringfenced team, we'll give 'em ringfenced teams ;-)
Later on in my career, I started managing software product development, as a team of product development managers, we were often faced with the requirements from customers to guarantee "resources" to their projects. So during the initial start-up, planning & contractual negotiations, we would roughly estimate the project's backlog, and the impact on resource headcount, guaranteeing the customer will have X number of heads ringfenced for the entire duration of the project. The customer would have first right of refusal if and when a situation arose that we'd need to support new customers, or share development work amongst other projects, at the risk of reusing some of the people originally ringfenced and committed.
As a team responsible for product development, the whole point of having a common core product, is that we can easily reuse the same product, with minimal customisation required to deliver on multiple customer projects. Take for example, the business of set-top-box (STB) middleware or the STB application that we sold to many a Pay-TV operator. Using a common product development team, one team would support multiple customers, via one product release. In the case of STB application, if designed correctly, the major differences lay in the look and feel, and custom business logic workflows, the engine components were essentially the same. So we, as a product development team, could with reasonable confidence, guarantee to customers A/B/C, that from a development perspective, the need for a ringfenced team is really undesirable, causing us too much pain - which I will go into later.
However, on the other side of the fence, more recently, I now sit as the customer! When donning the hat of the customer, I am just more comfortable when I have better control, ideally all control! If I'm guaranteed a ringfenced team, the "resources" are totally under my control, focused and dedicated to my delivery. After-all I am paying the vendor to deliver, and I want total control of the delivery team. The better control I have, the better chances of delivery....plain and simple, accepting the challenges being placed on the development teams. What helps is that although I can be the hard customer, I do have a pretty good idea that the development vendors can overcome their perceived challenges and difficulties with the ringfenced approach, because, I myself was in the trenches and made it work. So I often find myself explaining component-architecture and single trunk-codebase management, multiple release streams management, to the technical teams.
And really, when you pause for a moment, and think about the big picture - you just have to appreciate both sides of the argument. The customer wants more control as this will help him/her sleep better at night, the development vendors would like to be left alone, trusted to deliver their product, as they know best how to run their development streams. Trust, however, has to be earned, and I as the customer, need to have a very good relationship with the vendor, as well as the vendor must have proven itself on more than one occasion, that they can come to the party and deliver...If there's been some turbulence in the past with non-delivery, you can be sure that I, as the customer will insist on the ringfenced team (the voice of the software engineer inside me head is silenced by reality of business needs)...In the end though, Delivery always wins!!
Let us look at an illustration the essentially captures how I approach this subject of ringfenced teams:
In the above picture I have shown the software architectures that I've worked on most of my professional life, having been involved in almost every layer of the software stack. In my view, the classic tiered-software architecture, whether applied to Enterprise stacks or Embedded Stacks, whether a Centralised versus Distributed architecture, essentially implements similar principles, like: Separation of Interfaces, Top-Down-Dependencies, Component-based design, divide and conquer. In so doing, component teams evolve as a natural part of the implementation pattern. Generally, such architectures involve a core service that is generic and can be applied to many customer implementations or instances. The applications layer too, if designed with scalability and reusability in mind, can be abstracted to a level of detail where common core application components are re-used, remain common and thus only a very thin layer (View/Controller) warrant customisation. Understanding this architecture helps steer the discussion away from
 |
| Key is understanding Architecture IMHO |
"I am the delivery manager, do as I say"
to
"You have clearly designed the system with multiple customers in mind. Please talk me through how you actually do this in practice, and how me, as an additional delivery will impact your team. How do you, as development owner contributing to my project delivery, see Ringfencing working for us, and what commitments can you make to guarantee my project has the necessary priority, given you will now have at least two customers to support simultaneously??"To find out more about the challenges of shared product development, and the challenges a development team faces with shared codebases, co-located teams V distributed teams, etc. - you can read the following related posts:
No comments:
Post a Comment