When you work with Kingsmen Software you aren’t just getting a source code file at the end of the project. We work with you to refine your process and workflow in a way that has a lasting impact on your organization.
That starts with a well-defined program of work comprising five key concepts for long-term success.
A Partnership Working Agreement
The next step in the program is drawing up a partnership working agreement. This clarifies what we expect from our clients as well as what they expect from us. There’s a reason we call it a partnership working agreement rather than a working agreement; we truly partner with our customers. Clearly defined expectations make for a smoother process and a shared investment in outcomes.
Specifically, we’ll outline how much time we need from key members of a customer’s team and what they are responsible for. While we want to get coding as quickly as possible, it’s important we make time to step back and set these expectations and build a shared vocabulary.
We understand what’s underlying the desire to start immediately. Typically businesses will have hit roadblocks before they request outside help, which means they’re under pressure internally to deliver. But it is important to have this agreement in place. Without it, there’s a risk that one party won’t understand their role or the time commitment needed to succeed.
The agreement also acts as an insurance policy if things start going wrong six months into a project. It’s not uncommon to panic when deadlines aren’t met. We can refer back to what we’ve agreed upon (during saner times), and what we’d planned for if such a scenario arose.
Routines and Agendas
Next, we establish routines and agendas. An agile process is all about mitigating risk. “Risk mitigation is achieved through: cross-functional teams, sustainable and predictable delivery pace, continuous feedback, and good engineering practices,” writes Robert Sfeir, an enterprise agile coach.
Those elements need to be established in routines and agendas that we commit to upfront. Doing so helps manage expectations and sets a schedule of work that everyone agrees to adhere to.
These routines may seem strict, but it’s all for the good of the project. “When teams regroup on a frequent (even daily) basis, they are better equipped to react to scope and schedule changes and adjust as necessary,” explains Christopher Yang, vice president of engineering at Corporate Travel Management US. “Such adjustments align the project continuously and provide teams with general guidance on value-based prioritization. For software development companies, this results in high-quality products and a quick trajectory to market.”
Portfolio Management
The problem with thinking about development in terms of projects is that projects have a beginning and an end. Instead, we like to take a portfolio perspective and treat development as an ongoing product within the organization’s wider portfolio of products.
So, instead of committing to an end date, we commit to an ongoing process; the best products evolve. Every project becomes a part of a dynamic, efficient portfolio.
Requirements Management
Start a project by gathering key requirements from major stakeholders. Consult with all relevant individuals across the hierarchy of the organization and query end-users in order to understand needs and wants. This process also allows us to gather enough information to identify highest priority items, collaborating with stakeholders to make prioritization decisions.
There are a number of reasons why identifying project requirements is difficult, writes Kelechi Udoagwu at collaborative work management platform Wrike. Stakeholders usually don’t know exactly what they want and often change requirements in the run-up to and during the engagement. Difficulties also may stem from a lack of cross-departmental communication and the fact that the software development team is typically sheltered from the politics and business goals of the company.
By taking a third-party perspective and asking questions backed by our decades of experience, we’re able to give organizations a better understanding of their processes and project requirements, sometimes even better than what they might develop on their own.
Metrics and Reporting
Finally, we establish how we will track and report on the success (and failures) of the project. We establish these metrics before starting work to form a framework we can use to analyze how a project is doing at any given time. In particular, we want to know when things aren’t going well and why that’s so.
Once metrics have been agreed to, we’ll consult them every single day and at the end of every iteration to see how the team is doing. We look at whether we’re on track and what issues, if any, we’re having so we can address them before they become larger problems. For example, at our daily stand-up meeting, we look at the burndown chart so we can see if we’re burning down the right amount of work to hit our goal at the end of two weeks’ time.
The transparency isn’t always appreciated by clients, because it means that everyone knows when things aren’t going to plan. But transparency is a good thing, even if it lets management see behind the curtain. When we show management hurdles, they can collaborate in clearing them. The first step in fixing a problem is knowing what it is.
Transparency also helps to build long-term trust and cooperation between stakeholders and project managers, writes Jessica Everitt at work management platform Wrike. “Experienced stakeholders don’t expect every campaign to go off without a hitch. But, if they don’t find out about issues until well after they arise, it will reduce their faith in you. They may also worry about what else you could be hiding.”
It may take a few weeks before we actually start to code, but the value of having a well-defined program of work can’t be understated. The time we spend at this stage is more than recouped when development begins.
Images by: Tool., Inc, Leon, ThisisEngineering