Determining the right software development life cycle at a young consultancy can be a challenging process. Searching my toolbox for a process that fits the team’s size, varying product owner involvement and rapidly evolving product offerings is an everyday challenge.
Increasing my reading and rereading of project management texts, I am reminded that the majority of them focus on building a company’s products using an internal team. While offering tidbits that help boost a consultancy’s productivity, most leave the specific challenges faced by consultancies unanswered. Largely, consultancies are left to cobble an approach together on their own. In researching various methodologies in my development of an Agile approach for stable/kernel, I found Consultancy Scrum.
Developed by Four Kitchens to fill the gaps of Scrum in their consulting projects, Consultancy Scrum is built around tenets – similar to the Agile Manifesto.
The five tenets of Consultancy Scrum
- You’re working on a project, not building a product.
- The client should provide an empowered Project Owner. If this isn’t possible, assign a PO from the consultancy.
- Always assume the budget is inflexible. Flexibility should come from timeline and functionality.
- Clients have needs and concerns that should be addressed by someone outside of the project team.
- Consultancy Scrum itself should be adaptable.
Here’s why I like this methodology:
Working on projects instead of products empowers a team to narrow its focus during planning. The first tenant, You’re working on a project, not building a product, reminds us that in instances where the team is not engaged in the entire project, planning efforts should focus on the specific features the team will develop. This focus allows for quicker identification of dependencies which is key to success when communicating with outside stakeholders.
The second tenant, The client should provide an empowered Project Owner. If this isn’t possible, assign a PO from the consultancy, is crucial to the consultancy/client relationship. Clients are increasingly comfortable providing a Project Owner to consultancies, but the client PO may not have experience in or be available for Scrum rituals. Appointing an internal PO from the consultancy allows the consultancy to train the client in writing and accepting stories while keeping a steady velocity on the project. stable/kernel often designates our Project Manager as a representative PO during this process, but decisions made by stable/kernel are always verified with the client.
The third tenant, Always assume the budget is inflexible. Flexibility should come from timeline and functionality, takes into account the many changes that arise during development. Closely monitoring a client’s budget is an important responsibility of a PO. Assuming the budget is inflexible and managing a project to that budget is one of the signs of a good project caretaker. While in development, things will often slide in and out of the scope of the original contract and the team should make sure to communicate with the client what can be delivered within the given budget. Continuous backlog grooming with the client allows the PO to see the impact of scope changes on budget and delivery date.
The fourth tenant, Clients have needs and concerns that should be addressed by someone outside of the project team, is my favorite part. Issues that can easily be resolved outside the project should never be the cause of consultancy/client relationship deterioration. For a PM, managing a client relationship while keeping the project moving often fails because it creates competing priorities for the PM. Providing the client with a path outside of the project to resolve issues keeps the project team functioning and provides the client needed support to address concerns. An experienced client relationship manager can mitigate issues on behalf of both parties.
The fifth framework, Consultancy Scrum itself should be adaptable, while not my favorite, is the most important. It creates a fantastic framework to pair with Agile techniques but adapting it to fit stable/kernel has been a challenging and evolving process that has created some deviations. The biggest deviation being, we don’t primarily use Scrum. I’ll expand on the pros and cons of not using Scrum in our software development life cycle approach in my next post.
