In this article, we will completely ignore the coding technicalities and syntax for a change. We’ll focus on time and work management, which represents a significant portion of a skillset of well-rounded and successful companies and individuals.
Disclaimer: A clear distinction between project and product management might be blurred in some organizations, and could be a topic for another short blog. Therefore, without further ado, we shall be using “project management” terminology for this blog.
Software engineering consists of creative problem solving and innovation. Almost daily, coders and developers face new challenges or problems that they’ve never solved before.
Software engineering as a filed involves minimal routine and, therefore, a higher degree of uncertainty or variety not only towards HOW to solve a specific problem but often also about WHAT exactly needs to be solved.
To be successful, good time and work management are essential. Let’s begin with a few statements which we will expand on as we go along:
- Time and work management is a skill. And, as with any other skill, you can learn it.
- Even the world’s best coder is useless without good work or time management—regardless whether they’re working as a freelancer or an employee in a development team).
- Management is a highly transferable skill: you can apply it in almost any field.
Overview
You can use and take advantage of several project management frameworks, approaches, and concrete techniques. Their advantages and disadvantages are a common topic for debate, which we’ll try and avoid addressing in this blog. The topic quickly becomes highly complex, and very rarely is there an ultimate right answer as to which approaches, techniques, or methods are the best. In reality, it depends on a wide variety of factors such as type of the project, spectrum of personalities of people involved, management skills, company policies, etc.
There are three ultimate truths to keep in mind:
- Each method possesses certain elements that are suitable to adopt or use in a particular project.
- No plan and no structure leads to anarchy.
- If you have to apply any method because the framework you’ve chosen tells you so, you’re doing it wrong! Every management method you choose to implement should be at your service and help you optimize your workflow.
Many would argue that project management approaches are “brand-named common sense”: recently, names were put to processes that happened naturally.
In this sense, we mostly speak of three approaches:
- Traditional or “waterfall” model,
- Agile methodologies, and
- Lean software development methods.
Related: You can read more about the most common methodologies in this article, which includes summaries and also links to external resources.
Traditional Waterfall Methodology
Waterfall is the most traditional approach and is mainly plan-driven, meaning that a substantial amount of time is spent on planning at first.
Once all requirements are well-defined, there comes a design phase. There, all requirements are translated into technical language, meaning how they would be implemented or accomplished.
This is followed by an implementation phase, where all functionalities are actually implemented according to what’s been outlined so far.
Once all is implemented, there is a verification and testing phase takes place where all functionalities are double-checked and verified.
Upon completion, the product is deployed, which is followed by a maintenance phase. This approach is very well established, repeatedly proving itself as the most useful in projects where the goal is apparent, and the team knows how to get there.
Agile Methodologies
A whole family of agile methodologies and frameworks are all designed around the same baseline, challenging the high rigidity (or lack of flexibility) of the waterfall model. Agile approaches are designed to accommodate changes that inevitably happen as we learn new things during development. Agile approaches allow for re-planning and strongly rely on people’s communication, transparency, commitment, common goals, and values over a fixed plan.
Agile methodologies mostly apply in projects where the degree of uncertainty and complexity are high.
To this category, we can attach projects that are on the high end of innovation, where we don’t know what they will become, what impact they will have, and we might need to re-direct or focus as we go along so we can match the audience’s expectations.
On the other hand, we have highly complex projects that are out of our scope of skills. We are attempting to develop something we’ve never done before, which makes our early planning highly inaccurate.
Source: https://www.agile-minds.com/when-to-use-waterfall-when-agile/
Scrum
According to Google trends, the term “Scrum framework” has undergone an increasing interest over the past decade.
Scrum is a variant of an agile approach that puts the development team on its front page. It assumes that the most efficient way of working is having small, “self-officiating” and self-organizing teams (up to 9 people) with a few key roles. The development process relies on incremental work of short periods (“sprints”), where the goal of each period (sprint) is to come up with a concluded deliverable (“increment”) that maximizes the final product’s value.
Source: The basic principles of Scrum are published in the scrum guide (https://www.scrumguides.org/scrum-guide.html).
Scrum Team
Scrum is people-oriented and assumes small groups working together. It is purposefully defined in a lightweight way, and it highly relies on people’s character. The values that are promoted are values of commitment, courage, focus, openness, and respect. It is assumed that people in organizations that practice scrum framework would in time adopt those values and live by them: commit to a common goal, always do the right thing and maintain transparent and respectful relationships with their fellow team members. It is also assumed that a scrum team consists of people with all necessary relevant skills to complete the work.
Following this principle, the size of the scrum team is strictly limited to between 3 and 9 people. Fewer than three would increase the probability of lacking skills to complete the work, whereas having more than nine people makes the communication too complicated.
The main roles defined in a scrum team are:
- The product owner is responsible for maximizing the product’s value under development, managing the product backlog, and ensuring the development team understands it. The product owner is NOT a part of the development team.
- The Scrum master: facilitates the scrum principles among the scrum team by promoting the rules, values, and practices of Scrum. Scrum master is also a part of the development team.
- The development team: professionals who deliver a potentially releasable increment at the end of each sprint (what those can be read in the next section)
No member of the Scrum team is superior on inferior to another in this core definition.
Scrum Events
Scrum frameworks have clearly defined events during work execution. All product features are kept and prioritized in a product backlog (managed by the product owner).
Activities are executed through sprints, a max. 4 weeks long periods during which an increment is designed, developed, tested, and delivered. In this case, the increment represents a small enough feature or development step that can be completed and declared as “done” in one sprint. Bigger chunks of work are sensibly broken down into smaller pieces.
Every sprint begins with a sprint planning session where a sprint backlog is created. The development team then performs daily scrum/stand-up where they plan the work for the next 24h. When the sprint comes to an end, and an increment is developed, the sprint review session is held. There, all stakeholders (also external ones) review what was done and together refine the product backlog. The development team on their own finally hold a sprint retrospective where the point of debate is to answer questions like “how can we function better as a team?” or “what would make our work more enjoyable?”. It’s more work-oriented rather than product-oriented.
Source: https://www.scrum.org/resources/scrum-framework-poster.
Scrum Earning Potential
How formal are these roles, and how much are they worth? According to Glassdoor, a Scrum product owner’s annual salary is between 90k and 120k USD, whereas the Scrum Master’s salary is between 90k and 100k USD (source).
Conclusion
Any organization you will be involved with will practice a different methodology. Mastering the skill of using the values, structures, or disciplines promoted in any of these frameworks is highly transferable. Values promoted in Scrum can be useful in any other environment, even in your private life.
There are much doubt and debate about whether scrum principles are too vague. It is being argued that they have to be so vastly modified to be implemented in a work environment among different organizations, that they are often largely decoupled from the “rulebook” of Scrum. Secondly, some organizations had trouble translating principles of scrum framework into reality, arguing that it took a very long time. It can be hard to make it work with the people who are not open to changes. Many people don’t want to alter their well-functioning ways of working just to fit the model.
In reality, scrum practice is as challenging to master as any other. Clearly, lack of understanding or competence in this field can adversely affect your business. To function properly, Scrum must be adopted corporate-wide.
All of these models put the messiness of reality into a model or framework of actions and relationships that might fit your business. It is up to you to decide whether to adopt them or not and to what extent. Adhering to the principles of one is the most useful step to make at a certain point. The ultimate goal is to tweak and tune your project management to make it the most compatible with your technical skills, marketing, and all other skills that complete you as a freelancer, business owner, or team member in general.
About the Author
Luka BanoviΔ is a full-time engineering project manager at IRNAS LTD in Slovenia (and also a Finxter). A line of experience in engineering project leading has taught him many perks of this job, and he is happy to share some ideas with the Finxter community.