Project management before SCRUM
Before the Agile software development, companies used Waterfall, a linear and sequential approach where a project is divided into phases:
A client came to a development team and told them about a project. The client’s requirements turned into detailed project specifications. Then designers outlined the layout of the product, and developers started coding it. The team could test the product only when it was completed. Sounds pretty yet the approach doesn’t work like that in practice.
The Waterfall approach is considered to slow down the work on a project — as a development team would never switch over to the next phase before they finished off the previous tasks. Plus, you cannot go back or jump over a phase. Plus, the product can be tested only when all tasks are completed and features developed.
When a product is developed according to Agile, QA assurance is carried out at the end of every sprint. A QA engineer works in parallel with developers, which speeds up the development.
Let me give you an example: on one of the projects we faced an issue when integrating the product with Stripe Payments. We decided to look for alternatives and adapt the project to the situation rather than trying to implement this particular payment system by any means. As a result, we integrated the product with another payment solution — Braintree. If we had worked on Waterfall — we would have exceeded the deadlines. Synchronizing with the client and changing the documentation helped to avoid such a headache.
It’s hard to predict all problems. Especially in the digital world. Especially, when it’s about a large and technically complicated project. The Waterfall approach ignores changes. A project is done once and for all — you cannot change what was planned. As soon as you have specifications and requirements, it’s hard to scale up the functionality. Any change required has to be discussed with the client and approved by them.
Boost of project management: how to efficiently launch startups
The Waterfall approach snowballs unnecessary red tapes, difficult communication with a client, and broken deadlines. Companies had problems yet no one complained because there were no alternatives until Agile popped up in 1995.
Agile methodology started replacing traditional methods. Detailed specifications passed away, while communication with clients and deadlines came in the first place. After several years, Agile evolved into a Manifesto of Agile software development that contains all the principles of the methodology.
Companies had already been using the methodology yet it got mainstreamed only after the Manifesto. With time, Agile got its own frameworks: Lean, XP, Scrum, Kanban. We tried working based on Scrum and Kanban — so here go our thoughts.
Kanban is about task visualization, time limitation, and continuous work process. Board is an obligatory element of Kanban — it’s used to capture the current tasks. Each board has columns representing stages of the development; each card in the columns embodies a task. When it gets a new status, it is moved sequentially from one column to another (in Kanban, this is called a stream). If you don’t follow this rule, the approach doesn’t work.
We base our work on the SCRUM methodology anyway. However, when it’s about design processes, we use Kanban as a way to organize a task manager. We use Jira for development projects and Trello for design ones. In a nutshell, we like Kanban as an organizational style of the task manager but don’t like Trello as a tool. Gonna replace it soon.
According to Scrum, the workflow is separated into short stages (called sprints) with strict timelines: usually, 1 sprint lasts 2-4 weeks. During a sprint, the team meets on a daily basis — to evaluate the process and ‘compare notes’ about a project. At the end of the sprint, the team tests a ready-designed-or-coded part of the product and demonstrates it to the client.
Here is a list of the main framework principles that help team in their work:
- Flexible backlog
- Daily meetings
- Readiness for changes
- Splitting a project into sprints
- Communication
These principles allow us to stay inside budget and time limits. At the same time, it’s also easier for the team to develop and release products.
Project team
Usually, a Scrum team consists of up to 9 developers. Plus, a Product Owner and a Scrum Master. However, it’s OK, if there are more participants in your team, but you’ll struggle to coordinate the process. You need to be skilled to manage it properly. If a team includes less than 3 people — it isn’t considered productive as such a team lacks communication. Scrum-based teams are capable of self-organizing: team members choose how to complete a task by themselves. This is how it works in theory. Read on to know how it works in practice.
The Product Owner is responsible for generating the idea and the result. In most cases, this role is taken up by a client: they give an idea, find money and write specifications. Nonetheless, not every client knows how their product should look. Together with other participants of the team, they guide the product in the right direction.
The Scrum Master initiates and upholds communication inside the team. They help to overcome problems and communicate the core principles of the methodology. Yep, Scrum project management doesn’t work if people don’t believe in it.
The development team generally includes from 5 to 7 people. Everyone has their own area of responsibility yet they work together to reach the goals of a sprint. For those who don’t understand why there are so many people in the dev-team: a ‘developer’ here is not necessarily a person working with code, a developer is any specialist working on a product — be it a QA engineer or a designer.
Scrum team in real life
At Purrweb, we have project managers who combine roles of Scrum Master and Product Owner. It works like this in most projects. Why? Let me give you an example. Right now I’m managing a project — some tasks of the project are explained in a few words, some can take you yonks just to read it. Keeping that in mind, I have more than 1211 tasks. A Product Owner has to understand the product, know how to structure the backlog, describe and prioritize the tasks — there aren't many people willing to take these things on. However, there are always expectations: on another project, we share the responsibilities of the Product Owner with the client: he regularly assigns tasks and adds them into the backlog, specifies and prioritizes them.
We believe that each case is individual — that is why we ‘pack’ the team based on the tasks and goals. A client is interested in getting a product within his/her budget and timelines. We want the same thing but also keep in mind the concept of the cross-functional team that makes it easy for developers to continue working on tasks of each other (if one of them went sick, for example).
Sometimes a client needs to release the project in a month. In this case, when estimating the scope we add up team members: we know our usual team (project management, UI/UX designer, 2 developers, and QA engineer) won’t make it on schedule. We are not bound to a concrete number and ready to involve as many developers as needed.
Our experience says each project has its own ‘perfect’ number of the team members: even if a project seems to be an ordinary task, it may be necessary to bring more people.
We know life is unpredictable: there is always a small chance that someone from the project team may be taken to bed or buzzed off. To be sure everything will be done as scheduled, we reserve a developer who is not busy on other projects or bring a free one. We also can involve manhours if the team is running out of time — be it on the frontend, backend, or design stage. This approach helps us rule out the risk of going over the timeline.
How to organize work in Scrum
Scrum is not a unique solution to problems that guarantees your product will 100% bomb the market. Blindly following the methodology may lead into trouble. We are still learning how to apply Scrum and customizing it to match our ideas. One thing we can say for sure: now it’s easier to control the process, the team is more productive, and there is always room for improvement.
Every day we are studying how to use Scrum project management and looking for ways to make project management and communication with clients even more effective. We want to share with you how we apply it and why following the rules is not always good.
Maintaining project backlog
When a client comes to us with an idea, we ask him/her to tell us the essence of the startup concept and the most desired features. Usually, it’s enough for us to start, if there are no exact #iwanttos. All the important parts of the development can be discussed during the process.
The team discusses the idea, creates a mind map, and chooses a tech stack. The tasks form into a list — known as project backlog. At the top of the backlog, we place the most significant part that must be done first. Step by step, this list will change: there will be new features or won’t be old ones.
At Purrweb, the project backlog is formed by the client’s requests yet driven by the project manager. If the developer understands that a task needs some adjustments (because otherwise a feature will work badly or won’t function at all), the backlog will be altered. It’s how I see flexibility in project management.
All tasks in the backlog are prioritized: the team tosses the project goals around and finds the most optimal way to deliver a high-quality result. Large companies — like Google or Amazon — use prioritization criteria. For instance, Impact/Effort, Feature buckets, User Story Mapping, and MoSCoW.
To prioritize tasks in the backlog, we carefully listen to clients, developers, QA engineers, and the common sense. During planning, a teamlead and I outline the tasks in sprints. Later on, developers decide how to complete these tasks and share them out among themselves. Usually, clients need a completed piece of functionality to present it to investors. When we estimated the project at a 3 months limit, but the client promised the investors that they would see results in 3 weeks, of course, we’ll take the promised features first. This is how clients affect the prioritization.
We use User Story Mapping to prioritize tasks. A business analyst uses it to blueprint the user’s steps in an app: how they will use a product, what they will need to do to reach the goal, and so on. Both approaches, User Story Mapping and MoSCoW, help us prioritize the project backlog.
We have been applying the User Story Mapping method to the development process for a long time. Recently, we’ve started using it in the design process too. How it works: a business analyst creates a document with user stories. We estimate the user stories and hand them over to designers. A designer draws up a mind map that is then presented to a client. When the client says it’s all right, we start designing the product. Generally, when a client comes to us, he/she already has something. For instance, once I managed a project where the client brought a mind map at the very beginning
Splitting a project into sprints
The process of splitting a project into sprints basically means dividing one big task into small pieces that will be put together later. The team takes tasks from the backlog and estimates the scope of work. Developers assign the tasks between themselves, we begin working on them. One sprint is equal to a set of tasks taken up. The team always knows what a client will get by the end of a sprint.
For us, the optimal sprint length in the development process is 2 weeks. One week can be not enough to develop complicated features, and the team won’t have much of the result to present to a client. More than 2 weeks — and the client may get frustrated, it will seem like there is no end. We understand how annoying it may feel.
Organizing daily meetings
At the beginning of each day, the team meets on a ‘daily meeting’. Team members allocate about 15 minutes to discuss:
- what was done over the past day
- what problems were faced
- what tasks will be done today
The team syncs up and exchanges information everyday. Every member knows which tasks everyone did yesterday, who had problems and which tasks are planned for today. Daily meetings are a great tool for monitoring the product development during each sprint or the project in general.
Presenting the result to a client
When one or several sprints end, the team meets the client to present him/her a finished part. Together they discuss how to improve the product and what to do next — continue following the planned scenario or change course.
At Purrweb, we make such presentations every 2 weeks. We deploy the completed part of a product that we’ve been working on for the past 2 weeks on a test server, which allows a client to try it out. The client sees the progress. The client is satisfied.
Never losing the lessons
After the demo presentation, the team gangs up on a retrospective — another meeting yet held without the client. Scrum Master and developers analyze the overpast sprint and learn lessons: they discuss problems and experience.
I remember how I had to drag out a call with a client for half an hour telling him everything we did during the sprint. It turned out that we did not have time to put together a demo version and I had to wait for the developers to prepare everything. In retrospective, we discussed this and made an action step (AS) for the developer: to build a demo version the day before the call with the customer. This one is an isolated case. It took us 1 retrospective to fix the problem.
When we just started using Scrum, we didn’t hold retrospectives. It’s hard for the team to evaluate a pace of work, figure out what each participant is good at and what can become a problem for a project. The team members need time to gain insight into the process. As a result, they might find themselves struggling against ceremonies — retrospectives help the team member to work together more efficiently’.
Retrospectives help us get down to things we’re no slouch on and things that require mastering. The next step is to set AS (action steps) — to convert cons into pros and not make a single mistake in the future. We begin retrospectives by checking what action steps were undertaken and what was learned by each member of the team.
Why SCRUM is great for MVP and startup development
We’ve been developing MVPs and startups since 2014. Over this time, we tried applying different approaches to the project management system. In this article, we shared our thoughts on Scrum project management and told how it works on real projects. One thing we can say for sure — the methodology suits MVP and startup development 100%. Here is why:
- everyone in the team knows the current tasks and problems
- at the end of each sprint the team learns from mistakes
- project backlog can be easily altered
- project priorities may be changed
- a client sees the progress and controls the work
- the team is always ready to scale up if someone falls ill or can’t keep pace with the deadlines
The strict order of the development stages is replaced by sprints. So the team can quickly change the list of tasks: add details to existing ones or throw them out. The project backlog is constantly changing — at the release, the product earns new features and gets rid of unnecessary ones. The client monitors the development from the very first sprint, which helps him/her to decide on the features, continue development as planned, or change the course.
Scrum is not just a set of instructions. It’s a philosophy that is based on 3 main ideas: transparency, evaluation, and adaptation. We believe in transparency — that’s why we hold daily meetings and use Jira & Trello. Evaluation — retrospectives. Adaptation — evolving points of growth that were exposed during a retrospective. This is the heart of Scrum that is beating in our work processes.
We stick to the philosophy yet know that it’s not a universal solution. When we got our first big projects, we began screwing up: broke the budget or time limits. We knew there was a problem — found and fixed it.
Now we have the established approach. Thanks to it, our processes are always transparent. We keep everything under control and can handle even the most complicated project — this is our advice for everyone building a startup.
In the end, I’d love to remind you one conversable quote of Albert Einstein: ‘The definition of insanity is doing the same thing over and over again, but expecting different results.’ Don’t be afraid of making a mistake, try to reach your goal and build your dream.
Feel free to contact us for project management consulting — drop us a line!
