Today a manager asked what kind off scope and effort the Accelerated Delivery Platform could handle on a project expressed in function points. I find this a very odd question and I have always been resilient to function point analyses as an estimation technique which tries to best guess the end state of a software solution based on and determine by the number of interfaces, screens, reports etcetera. Often this happens upfront at a point in time there is only a vague idea for a perceived solution for specific problem which still needs to be analyzed in detail. Very old school thinking if you would ask me, which is not helpful for providing agile ICT support for business development and transformation.
Asking for the ADP platform’s project delivery capabilities expressed in scope and effort is a weird measure for suitability for a software development platform. Given infinite time any scope and effort can be handled by any approach. But then again every project is always about time and scope, even when a Product Owner says it is not. His manager most certainly does want to get some added business value in the near future.
A focus on a potential optimal scope is also the wrong mindset for ADP, which stands for fast and disciplined agile software delivery in accordance with the collaborative business experience: we now start to develop the functionality the client/product owner needs most in two weeks’ time. The size or scope of this package of functionality is equal to the capacity the team can handle comfortably and maintain.
So what counts is the productivity or delivery speed of the software development team, since you can scale the size of a project team in principle to any size. And this delivery speed itself can be expressed in hours per function point. And if you are now wondering what kind of productivity can be established with ADP, I can’t share because of company confidentiality. What I can tell is the people are really astonished and in disbelieve when I am allowed to disclose and it is a loooong way below the industry average.
For this reason ADP is best done justice in a long running software delivery program, like for example in the actual case in which for a long period of time a client is provided with an ADP software delivery factory for the initial solution development and following application management. There are however a few constrains to keep the factory agile and responsive for the client: The initial development and deployment to production of a new solution has a standardized project delivery cycle of 100 days and every 2 week sprint delivers working software, fit to be made available to the business. And every new project the users of the new solution are amazed they actually can see and test the initial results after a few days and have a finished piece of functionality after two weeks.
If you are still interested in the optimal scope, we have to go through some numbers. There do exist constrains on the span of control for a project team and the available capacity at the client/product owner required for requirement & test workshops. In ADP projects we actually do elaborate with the ambassador users on requirements and they do need to test and signoff for a successful end result for a Smart Use Case at the end of the sprint.
For development work required on a Smart Use Case you need a dedicated cross-functional team consisting out of 3 engineers responsible for requirements, design, code, test & deployment. Besides we need an assumption for the overhead (-for project management, engagement management, configuration management, tool support, framework engineering, town hall meetings, community of practice meetings, etcetera-), especially required because remember we do want to run this project at scale. For now let’s put the overhead at a constant 0,5 FTE per team.
And mind me this overhead is not wasted time, because teams do need time and effort to align their team’s individual contribution with the rest of the project. And if you want to do this at large, like we intend to do here, this does require more effort compared to a single team approach with on average only 7 team members.
The complexity of a use case is also a relevant factor. For a matter of fact this determines the effort required by the team. Higher complexity requires more effort. Fortunately for us our team is using ADP’s Smart Use Cases. Smart Use Cases deliver smaller and equally granular use cases to software development. As a result the average complexity of this kind of use cases in a project is “Average”, which by definition in ADP is equal to 4 Smart Use Case Points.
If your project’s average is way above this mark, my experience is you have to look into your use case model and determine the cause. There might be a perfectly good explanation due to project specific characteristics. Otherwise you might have overestimated some use cases or created a lot of complex use cases, which you might want to try and split into sub functional use cases. these contribute a specific part of originally considered functional scope, often identified when you look for intermediate results.
Are you still with me? We are half way through setting some of the numbers in place. You might want to consider to reflect a bit on the preceding, before you proceed and consider the effort required by the product owners team. And this is actually key to make the agile collaborative business experience successful for an ADP project engagement with a client.
So what do we need and expect from the client/product owner? We do need his input, business knowledge, support and commitment. This implies he needs to make staff members, the ambassador users, available for collaboration with the software development team and this comes at a cost. The staff members will not be available for their business during the time they support the engineers. This has impact on the capacity available to execute the regular business tasks.
On average the development team requires about 8 hours of contact a week with the ambassador users a week to elaborate on the details of the Smart Use Cases and discuss and test the results provided by the engineers, which are in scope of the current sprint. The elaboration is done during intensive facilitated workshops.
The question which arises is: how many ambassador users are required to attend the workshop? And this can be a though question. I have had my fair share of workshops which more resembled a bedlam than a professional meeting, due to more than a dozen stakeholders in a workshop, who all wanted to get their point across and get recognition for their personal needs. I think you can imaging and see the three men engineering team struggling to get them all aligned for a suitable solution for the problem at hand? I can tell you those were not very productive meetings at all.
Having gone through the ropes my personal experience is ideally you have three ambassador users in a workshop, each providing and focusing on a specific aspect of and viewpoint on the Smart Uses Cases, which are the subject for the workshop. As a result you have a total of 6 participants in the workshop. This provides the ideal setting for focused elaboration, given all participants sufficient room to actively participate in the session.
There is however a condition which must be met to make the workshops a success. All participants, the ambassador users as well the the engineers, must have a mandate from both the product owner as well as the project manager to make the required functional design decisions about the Smart Use Cases which are in scope of the workshop and execute them without consultation.
But you have to be on your toes with regard to the mandate. During a workshop one might discover an issue, which is beyond the functional scope of the meeting and has wider impact. This can be an impact on the technical solution as a whole. But it might as well be an issue at the business side. And again, please remember we are running this project at scale and as a result not all concerned parties are in the workshop. This requires all the project participants to be on their guard and escalate these impediments through the proper channels in the project’s organization.
So what is the take on the specific aspects and viewpoints for the ambassador users you wonder? Ideally each ambassador user has a specific stake in the problem. First in line is the representative for end users. The end users will work on daily basis for years to come with the solution, which is being developed. As a result their opinion is key with regard to the acceptance of the solution and their voice must be heard and most certainly be taken into consideration. The implication is that ideally the end user representative is someone who actually will work with the Smart Use Cases at hand in the future. My advice is to assign this type of Ambassador user to the project for the time the functionality he is actually going to use is within the scope of current sprint. On a large project this might result in a very dynamic group of participants.
So with the end user representative in place, my observation is we have actually placed a kid in a candy store with a mandate to pick all the sweets he can handle, basically having a blank cheque with the capability to burn more project budget than required or expected. We need a counterbalance to prevent this from happening.
The engineers are not the suitable persons to act as the counterweight. They basically do not have a great interest in how the available budget for the project is spend as long as the end user representative is happy to signoff the realized solution for the Smart Use Cases.
The Product Owner is accountable for the project’s budget, so he should make sure his voice is represented in the workshop. The Product Owner has to assure himself the requested solution is aligned with the business vision for the project and fits in the available budget. For this reason and because we are running a large operation and as a result the Product Owner can’t attend all workshops, he needs to delegate a representative to the workshop.
The third type of ambassador user I need aboard a workshop is the domain expert, commonly holding the title Business Analyst. He is the subject matter expert with the bigger picture about the business model the solution needs to support and is aware of the interdependencies between individual user tasks that need to be support by the solution. He also possesses the detailed business knowledge the solution has to support. He is the business rule guy who needs to make sure the solution underpins and supports the Client’s business governance model.
So on average we need 3 ambassador users for 8 hours a week to collaborate with the engineers in workshops. The ambassadors also require some time to prepare for workshops and look into matters. Because we are running at scale we also need to anticipate some overhead for elaboration between the different user teams who are each collaborating with an engineering team. Let’s say this requires an extra day in the week on average.
We end up with the following equation: for each engineering team on the project, requiring 3.5 FTE, we require 1.6 FTE from client. If for example the client is able to spare 16 FTE on the project, an engineering team of 35 FTE can be assigned, having a total of 51 FTE elaborating on the solution.
In my opinion with 51 FTE we have also reached the other constrain I mentioned earlier: span of control. On an agile project you do want to have those involved knowing what is going on. In my experience a group of people knows what is going on if they all can fit in one bus. It a group needs to travel in more than one bus, it’s hard to get a clear picture on what is going on in the other bus. As a result my conclusion is you should not have more than 35 engineers on a project if you want to keep every body involved, informed and committed.
Having identified the 35 engineers constraint, I am able to answer the manager’s original question and I am sure he will be really astonished and in disbelieve. But then again that is what happens all the time ADP’s productivity is revealed.
Reacties