What We Think Is the Best Approach to Project Management
This is the fourth and final part of my Project Management series Tech Startup Projects: What’s different, what works, what doesn’t. Here are the other posts in this series:
FURTHER READING
> Why project management for startups is different?
> What to consider among project management tools for startups
> Why we prefer a mix of project management methodologies
Recap
In the previous post, you read why we don’t use two of the most popular Agile frameworks for startup project management in isolation, but bring them together as the hybrid ‘Scrumban’ approach.
We really like Scrumban and we think that with our tweaks to it, it is the answer to tech startup project management. Before we move to Scrumban and all the good things it has to offer, let me take a few minutes on talking (write :P) about ‘how we work’ – and how this relates to our tweaks to Scrumban.
Our Process
While building our method, we have taken some cues from ‘goals-driven development’. Many times, we just start with an idea and a vision from a founder. We have experienced, time and again, that there is a good chance that the idea will change over time, but what rarely changes is the core vision.
So that is where we start!: Getting absolute clarity on the vision. We ask ‘what if’ questions. We suggest alternatives ways of implementation. We present hypothetical scenarios. The idea is to get the picture as clear as possible for us – as well as the founder(s). Then we work with the founders and Product Owner(s) of a startup to identify the goals that are derived from their vision. (This is also where we introduce Design Thinking and pay great attention to developing empathy, in order to get to more clarity on vision – but this is a topic for a separate, forthcoming blog post.)
Once the goals are identified, it becomes easy to set priorities and zero-in on a delivery schedule or milestones. With a prioritised list of goals, the Project Manager can work with the Product Owner to distill individual features (Stories) that make up the highest priority goals. Our Milestones are a combination of one or two goals, delivered across an agreed timeframe for what becomes the Minimum Viable Product (MVP).
Minimum Viable Product (MVP)
As you have read a few times in this series of posts – time is THE scarce resource for a startup. From the start, it is a deliberate effort on our part, to land an MVP Milestone as soon as possible. This Milestone has the most important goals and features that are vital to accomplish the vision. This is a practice we brought from Lean Thinking. The MVP is key to success for the startup creating a mobile or Web app-based value proposition. It allows timely interactions with early adopter customers, as real beta users, capturing vital user feedback and supports crucial steps towards different phases of investment funding approvals.
Beta – Improvements, Rinse & Repeat
The MVP Milestone is soon followed by working towards a Beta Release Milestone. Here, we undertake feature enrichment to make the MVP more useful. If everything goes well and users start liking the MVP, with good feedback, it turns into a timely flow of new product releases, with prioritised features and functions constantly added in every Sprint.
Each Milestone also includes bug-fixing and regular product maintenance from a ‘DevOps’ perspective. Depending on the goals, products can pass through many Beta Release Milestones until all major goals are complete.
Tools
The term Scrumban, as the legitimate child of Scrum and Kanban was proposed by Corey Ladas in a book titled Scrumban in 2009. Scrumban was originally meant as a transition for teams going from Scrum to Kanban but the idea of the hybrid Scrum and Kanban stuck.
From personal, hands-on project experience, I feel Application Programming Interface (API) integrations are one of the best things to have ever happened to the evolution of software. APIs were especially useful for us in implementing Scrumban at Cliffex. We use Atlassian Jira and Trello for Project Management. We feel Jira’s interface and myriad features are best utilised by developers while Trello’s interface (if managed well) is best suited for commercial users – e.g. startup founders and Product Owners.
At Cliffex, Jira is specialised for the development team and Trello for our Project Managers and customer Product Owners and founders. Both Agile Boards are integrated with each other so any Story that gets ‘groomed’ in Trello, goes straight to Jira for the team to work on. Integrations go both ways. Trello Board also reflect important things from Jira. This is Scrumban, applied.
Trello acts as our ‘pre-grooming’ Board and Jira as the ‘groomed’ Backlog for the team. Product Owners also have full rights to manage Board Stories on Trello. We take full responsibility of managing both Jira and Trello Boards. This mitigates the risk of running projects with outdated Boards.
Communication
Communications are an important aspect of working in a team environment. In order to succeed as a team, one has to seek out help from other team members. One of our crucial learnings is that help can’t wait. If you are working on something and need help with implementation or making a decision about it, it needs to happen immediately.
Thankfully, based on how we work, no matter what time it is, help is always at hand. Our project managers form a deep bond with our customer’s senior commercial people – the founders and Product Owners. They develop an acute understanding of the purpose and vision for the product. They are the key decision-makers to make sure work continues. Senior team members help-out with the implementation.
Picking a set of good communications tools is really important because it removes the clutter and really gets the work done. At Cliffex we love Slack for team communications. It works wonderfully because it supports beautiful integrations with almost any other tool we have. Each Jira story that is added gets communicated to the team via Slack. Each change to the Jira story (Work-In-Progress, Done, Ready for Testing, etc.) is communicated via Slack too.
If you are a team member busy in your work, or you are sleeping (remote team member) you don’t have to look at it but it is all there if you want to catch-up online! Things like clarifying small designs doubts or getting an API key are instant!
Meetings/Calls
Just like Scrum, we do have standups but on Slack and they happen all the time! Rules are simple. Anything urgent? go walk to the person you think can help you. Anything not that urgent? Then ask for help on Slack.
You may be thinking – but does the team meet at all? Yes, they do: at the beginning of every week. It is usually for discussing any estimation updates so that the Board reflects what is getting done in the Sprint. No impediments, but progress, so that if anything needs to be realigned based on revised estimations, it can be done ASAP. As stated above, impediments are dealt with immediately. It is the duty of the Project Manager to make sure everyone is communicated on any delivery related changes to the plan.
Accepting Change
As written in earlier posts in this series, continuous change is integral to startup culture.
We feel that the best approach is to embrace change and find useful ways to salvage the work that has already been done, where appropriate. This is where the Project Managers’ keen understanding of the product vision is vital too.
Every week, the Project Manager has meetings with the Product Owner and founders to discuss new features and changes to the existing ones. Because this is done every week, it gives a very clear understanding of the product to the project manager; sometimes even 3-6 months in advance. With this kind of foresight, another benefit is that now the Project Manager will be able to drive implementation in a resource-efficient way.
In case of a change, what gets done depends on the priority discussed between the Project Manager and the Product Owner. The Project Manager will propose a solution that best handles the change while preserving the hard work that has gone before it. This is a sensitive process between the Project Manager and the Product Owner. A lot depends upon the receptivity, rapport and trust generated between the key people – and at Cliffex, we pay great attention to this important point!
Recycle and Repurpose
A lot of times, I’ve seen a feature changed but the work done for it could be repurposed in another feature. If the team is aware of this, there is no loss of morale!
In one of our key customers – Kroo Sports – we had to implement a new type of Prediction Game that leveraged Team Odds. The API was integrated, the UI was also finalized and implemented. Then we got to know that we had to change the feature and deliver another game – fast. We already knew that we had to create v2 of the existing Prediction Game with similar data in the future. So, we just kept the branch on Git and reused most of the code two months later. It took just a week to deliver Prediction Game v2 because we already had most of the work done!
Build Agile – Act, Learn, & Grow
While building a mobile or Web app for the first time, we suggest not spending resources trying to build it in its entirety. Features always change and get refined after their first release. We try to break the change or Story into multiple releases such that the most important aspects go in first. Hence, focusing on what matters in the Minimum Viable Product (MVP) and with good Design Thinking applied, placing the users at the center of design and development.
We build for the most important requirement, hear its feedback from the Product Owner, and then improve upon the feature as the next version. This is an iterative process of learning and implementation. This also fits with the Agile software development method of evolutionary and continual development and helps us with early delivery as well.
Final Words
That’s all folks! I’ve tried to give my best explanation of ‘why’ and ‘how’ we manage projects at Cliffex. Like any other framework or method, use this as a general guideline. This is a continuously evolving process. A word of caution though. Each project is different and needs its own tweeks.
There are projects here that do not use Jira at all. Some have very frequent meetings between team members. Choose a process that makes project management easier for everyone and stays true to the advocacies of Agile – but the pragmatism of Scrumban.