Once I was presenting Scandiweb success story to the students of my alma mater and got a question “What is special about Scandiweb that made you ahead of thousands of similar companies? What is your secret?”
I did not feel we have a secret other than persistence and years of working hard, but after few days I figured out that there is something that contributes to our success and is usually not present in other companies I know.
This special thing is what we call Project Manager or Product Owner, who encompasses much more areas than “management”. This very domination of a wide range of competences such as coding, entrepreneurship,design, and team psychology in one person enables us to guarantee to our customers that we will deliver better, faster and create more value for their business.
Below is an account of how a Scandiweb PM/PO makes difference for Jaguar Land Rover enabling their customers to buy cars on-line.
Customers tell that, while usually we manage and develop projects remotely, they feel that Scandiweb team is closer to them than their colleagues working in the same office.
How does it happen? First, there is transparency on daily and hourly progress, pro-active reporting and demoing. Second, our PM/PO/BAs travel and spend from few days to few weeks on customer location from Canada to China. We observe and understand existing business processes and future goals and suggest tech strategy that enables customer to map existing business onto a digital platform and reach planned business goals faster and with less costs.
In Jaguar Land Rover project our POs did a deep dive in car financing algorithms — PCP, PCH, Conditional Leasing and Hire-Purchase formulas and finance sources. Studied Jaguar factory delivery pipeline, used cars valuation principles for Part Exchange and real-time CAP API. Car-configuration and its effect on pricing for more than 20M of different Jaguar cars you can build using online Car Configurator!
When POs is technically savvy stakeholder interrogation is not one-way process of gathering requirements, but an immediate feedback on how to tweak them to maximise time to market and minimise costs, while reaching key business goals.
How would you estimate delivery date for a project that has more than 1000 tasks and there are updates across hundreds of them? Here is our solution — first, create components that make up entire project like pieces of puzzle. Criteria of success — once all components are done, project is successfully delivered on Live. That is, you include there components such as pre-live testing, textual content creation, stress and security testing, live infrastructure set up and go-live checklist. Everything! Up to DNS change and 301 redirects, if there was a site before.
Second, each component is also planned end-to-end into epics (modules) and for each epic there is at least one task with an estimate that reflect an effort to complete the epic.
What do you have in result? First, you are sure that there are no gaps in planning — that you pre-plan all activities that are necessary for launch. And second — you can track delivery date real time! How? Simply export all issues that are not Done and sum up their remaining estimate! For issues still in New it will equal to their original estimate.
In Jaguar Land Rover project we enabled up to an hour delivery time for the entire project following these simple rules of component-epic-task hierarchy, no-gaps in component creation and estimating and updating work-logs on all tickets. You can see how backlog is consumed every day or how it stays the same or even grows, if stakeholders introduce more features or alter existing tasks.
Large projects have multiple releases, we use Jira Fix Versions to move things in and out of first release that also alters Backlog hourly value.
The larger the project, the more overhead there is. This is what conventional IT wisdom tells us. We did not care — we believe and know that there is a better way to manage. Jaguar Land Rover team achieved unbelievable 8% of overhead in a project with 15 developers split in 3 separate streams each working on its own component e.g. Car Financing or Part Excahnge while being tightly integrated.
Team’s recipe is simple — CLARITY = VELOCITY. Large projects are prone to blurry focus across each stream and individual goals. If project direction is based on high-level value propositions that depend on several streams, developers might find them blocked because there might be 15 people meetings on how to translate high-level goals into actual coding tasks.
How did we solve this? How we enabled clarity in a multi-stream project? It is a subtle difference that makes big change. Scandiweb POs are requested to have hands-on experience in coding and tech solution-delivery in general. In result, instead of delivering high-level stories to the team and calling a large meeting, POs couple story with a suggested tech implementation path that can be either accepted by a team or altered.
Experience in launching more than 400 eCommerce and Startups projects helps to figure out the best architectural decisions instantly and jump on coding right away. In Scandiweb offices solutions are simply flying in the air! Experience in coding also helps to ask questions to a customer and clarify things before the issue hits Sprint planning, the shorter feedback loop — the less overhead and the more joy of delivery we have!
How would it feel, if you know exactly how many tasks are still in specification phase? What tasks need input from a customer, how many are ready for development, what tasks are ready for UAT and what is already done and deployed?
Scandiweb uses 3 custom JIRA boards on Jaguar Land Rover project. First — Backlog board (Kanban) — each idea enters it and then evolves till Backlog status, which means it is ready for sprint planning and has full clarity on what is expected to be delivered. Sometimes, however, ideas are put on hold or moved to version two, but still we can take full account of any idea or insight ever brought to the table. Second board (Scrum) is used to track sprint delivery, and third — Big Picture (Kanban) shows all issues in a Project across all project statuses. Boards are split in swim-lanes based on Epic title and are filterable by Component to ease overview.
Now you can spot issues like dozens of issues still staying in New or Discovery status, while deadline approaches. You can quickly bring up tasks that need input from the customer to define them and make them ready for production. Adjust resourcing, if you see tasks ageing in backlog status or push POs to prepare more issues into Backlog status, if next Sprint approaches, but there are too few items there.
Communication on issue definition is handled either in Jira comments adding necessary Watchers or in Basecamp tasks linked to Jira issues to facilitate e-mail based communication flow.
Projects that start from scratch and last for many months usually start some features as prototype and use dummy data. In result, some teams approach deadline with something that works well, but… it is very far from a product that can go Live — team is caught up in delivering something “abstract” rather than something real and practical!
How to fight dummy data and prototype mentality? How to switch team to a customer-centric delivery approach? Scandiweb calls it a Triangle of Delivery. We bring necessary reality to the project requesting and getting real data from a customer because dummy data creates dummy results that you can not define as “good” or “bad”.
We bring reality by asking teams to skin real designs on wire-frame based functional output — it always raises questions that would be kept for later, if teams would keep working on functional output level.
Another thing is to keep site-wide focus and integrate streams’ work creating tasks that take each stream variables and modules and integrate them. For example custom price journey — from creating it in back-end, seeing it correct in car finder, then in car configurator, eventually in checkout and saving it in back end in customer order.
Clear the teams’ cache of prototype mentality, dummy data output and stream isolation! Inject reality and bring customer-centric tasks as early as possible!
Let’s be honest. Nobody cares about documentation till they need it. The trick is to embed it in the process not just on the level of definition of done, but as a useful step of development. Scandiweb achieves this linking Confluence to Jira project and mapping Component — Epic — Task hierarchy in Confluence Wiki tree. While tasks are being clarified they are discussed in Basecamp or Jira comments and once eventually clear, the task is exported into Confluence and linked to the conversation that led to solution. We make Confluence page a base for solution-delivery and thus we never need to create documentation post factum.
We are as big as are the challenges we are solving for you — get in touch and you might find the people, ho are as enthusiastic about your success as you are! E-mail me at email@example.com and let’s start the dialogue!