Our Agency Tested A Developer-Led Client Collaboration — Here’s What Happened
Managing any large project is complex, full of risks — and faced with a natural reluctance toward team-client collaboration. As a project manager, you cannot mitigate everything: you need to put the expertise of your team front-and-center to navigate each challenge.
This requires a team-focused and agile mindset where you place your focus on impromptu coaching and relationship building between your team and client. If orchestrated well, your client relationship will be rewarding, your team will be celebrated and your project will enjoy the best outcomes.
But, as a PM, how do you pull off a client-facing development team?
I’ll show you how we did it, and why.
Why We Opted For Developer-Led Collaboration
Just a few years ago, my team was much smaller than it is today. We wanted to grow, which meant we needed to find larger, more complex projects.
For us, we knew this would bring a new set of challenges, with the most important being changing the way our developers collaborate with our clients. We understood there was value in connecting our developers directly with our clients, given their expertise. Yet we also wanted to be able to stay true to ourselves and our clients, producing quality work.
One day…
An opportunity came knocking from a startup in the staffing industry.
Unforeseen to us at the time, it would allow us to experiment with this new approach to developer-led client collaboration.
We started with an on-site, 3-day consulting session to help the staffing startup refine their product vision and market.
They loved working with our team and asked us to put together a contract for developing the initial release of their platform. It included a web app, marketing site, iOS app, and Android app.
Our client wanted to move fast and was ready to build.
Great, right? Not so much.
The problem was, our client was ready — and we weren’t.
First off, our team only had 3 days of exposure to understand the product.
With a scope this large, we knew we couldn’t confidently deliver a contract that detailed every feature and edge case, as it required months of multi-platform development.
Not only that, but it also wouldn’t be fair to our client or team to engage this way.
Our client was building a new product, which would require significant learning and trust from our developers, not to mention frequent testing and gathering of user feedback to ensure success.
So, we created an agile contract.
Due to external timeline pressures to get to market, we couldn’t pursue our traditional discovery route at the time. Our team needed to come up with a solution that empowered our developers to create the best solutions. The scale and timeline couldn’t afford detailed scope negotiations and addendums.
After much internal debate, we created our flavor of an agile contract, or what we now call, “Duration & Price.”
This contract was informed by a list of user stories our product strategist created during the 3-day consulting session. Most critically, it set up a collaborative framework for our developers to lead our client partner.
The focus of the contract was a product team that we felt could deliver on the challenge.
Our team included a cross-functional web developer, backend developer, and a mobile developer. We also included a product designer, product strategist, and myself as a project manager. Each team member was set to various capacity allocations that made sense for the project, generally at half or full-time capacity.
The contract wasn’t hourly either, it was fixed-duration, and committed our team to complete specific project goals, without focusing on specific features.
We felt this approach put our best foot forward, provided autonomy for our developers, and made the most sense for the client team’s priorities.
Here’s What Happened With Our Client-Facing Development Team
After the contract was approved, we began work.
Coming into this without detailed technical or product discovery meant, as the project manager, I needed to rely on the team to collaboratively define the approach with the client. We had dabbled with Scrum before, but this became our first true scrum project as an agency, daily stand-ups and all.
We relied on our ability to break down user stories.
Starting development was a large undertaking that involved a lot of upfront risk management with our client. Since our contract was not based on a fixed set of deliverables, we had to show that our work, team, and process could be trusted within our first few sprints.
To do this, we referred to our initial, high-level list of user stories. We reviewed them as a team and identified where they could be further broken down and refined.
During this user story mapping process, we also determined technical discovery tasks for setting up our environments and identifying how we were going to build out the API data model. In turn, these would inform the estimation of user stories we were unable to estimate upfront.
We created design tasks separately and we managed their dependencies on our user stories for development. Throughout the development of this platform, the design would work ahead of development.
We saw that transparent communication with the client during the first few sprints would be key.
We consistently walked through the process of what we were doing and illustrated that we would begin to define a reliable velocity metric within a few sprints’ time. This would then allow us to collaborate together on a refined release plan as initial development stabilized.
Scrum gave us a framework to effectively and transparently collaborate with the client team.
We started our sprints with “Wednesday Kickoffs” with our team and client.
We set up 2-week sprints and invited our client to what we call “Wednesday Kickoffs”, a combined retrospective, team product backlog review and sprint planning meeting.
As the project manager, I facilitated these meetings. However, I intentionally did not choose the outcomes of these meetings. Rather, the client would speak to priorities, and the development team would directly consult with the client from their technical or design expertise.
For example:
The client would suggest that a loosely defined feature be prioritized for development in the following sprint. I would then ask questions of the developers in the room for the feasibility of it, like:
- What do you think?
- Is this possible?
- Do you think working on this would affect our current plan?
- Are there are development libraries or other efficiencies we can explore?
Asking these high-level discovery questions often jump-started a dialog between the developers and the client.
As a result, the client would lean into the expertise of the developers and we would quickly come to a consensus for a direction to pursue. Our developers served as expert guides and technical consultants during these meetings to help optimize outcomes for the client.
We prepared for “Wednesday Kickoffs” with a smaller client meeting.
Prior to the Wednesday Kickoffs, our product strategist and I would consult with the client in what we called a Bi-Weekly Product Backlog Review meeting.
The client would typically come in with a set of desired priorities for each sprint, and we framed the discussion around the context of our team velocity and the client’s market learnings.
See below an example of what we covered in our Bi-Weekly Product Backlog Review (with PM, product strategist, and client in attendance), versus what we’d cover in the larger Wednesday Kickoff meetings (with the development team added to the mix).
Together in this Bi-Weekly Reviews, we would refine the backlog priorities. This helped set up our full-team and client collaborations to run effectively during Wednesday Kickoffs.
We took advantage of a few useful tools…
Managing a complex set of multi-platform apps required the use of collaborative tools.
We used Asana as our project management tool. This allowed us to manage each app’s development individually. Asana is really great at transparent communication via its commenting system, which allowed cross-functional team members and the client team to communicate with each other directly.
We later employed the use of Screenful alongside Asana to have transparent and automated velocity reporting. This was available to both our team and the client.
Alongside Asana, we used a handful of supportive tools, all of which the client and team had direct access to:
- We had our own Slack channels for asynchronous discussions
- We used Zoom for recurring meetings and impromptu collaboration sessions
- We used GitHub to manage our code repositories and provide transparency for the work being done.
…but that still didn’t solve our biggest challenges.
We faced significant challenges as a team but were able to navigate them with Scrum as a framework and our contract as a foundation.
However, Scrum by itself didn’t solve our product development challenges.
When it came to our mobile apps, my team and client had to rely heavily on the guidance of one of our mobile developers.
For example, developing and managing separate iOS and Android apps was challenging.
Due to the platform differences, it was easy for the two apps to fall out of step.
Fast-forward to the end of the year, our client and team were discussing adding major new functionality to the mobile apps. This would be incredibly important for the future of the product. However, due to the way the mobile apps were built, our development team highlighted that this process would take a significant amount of time.
One of our mobile developers began to experiment with a new development language, React Native. It promised to empower developers to build and deploy native iOS and Android apps with one codebase.
Our developer rebuilt the initial view of the mobile app in React Native and shared it around the team as a proof-of-concept.
The value was clear:
At this pivotal moment in the platform’s development, we could continue to build at a slow pace, or we could rebuild the mobile apps from the ground up, with the new features in mind. Our client could have their cake — and eat it, too.
Rather than take this to the client myself, I worked with the developer to flesh out some high-level aspects of this proposed mobile app solution. I then facilitated a meeting between the developer and the client to propose this pivot.
In the end, the client agreed with the developer and we moved to pivot the development of the mobile app.
Read full article here: https://thedigitalprojectmanager.com/agency-tested-developer-led-client-collaboration/
Originally published at www.thedigitalprojectmanager.com on January 21, 2020.
