Large portions of the productivity gains from agile methods come not from doing things better, but from not doing them at all
Dear friend,
This week, my 2-month-long leave of absence started. During this period, I will spend time on various “projects”. For instance, I will go on vacation with my girlfriend, visit friends and family, learn about supply chain management to identify problems worth to be solving, expand my network, refurbish and renovate parts of my apartment, and create additional content for my social media channels.
As always, I aim to make the most out of my time. I want to waste as little time as possible. So, I contemplated how I can plan the next 2 months.
A typical planning method is to estimate what can be achieved in a certain period of time and to set milestones for each sub-period. Activities are broken down into linear sequential phases, where each phase depends on the “deliverables” of the previous one. A typical representation of this method is a “GANTT”-chart.
I wanted to try something else though. In my previous 2 consulting projects, I made use of agile planning and working methods, particularly Scrum. These methods differ from conventional methods. Instead of creating highly detailed working plans, which typically are inaccurate and subject to a lack of knowledge, a (dynamic) backlog of activities is created and work is planned and performed in multiple short sprints. Each sprint starts with a sprint planning session (like conventional planning just for a short period of time) and ends with a retrospective session (reflecting on the experiences gained within the sprints to reprioritize efforts for the next sprint).
As I’m strongly convinced of its superior effectiveness and have a great variety of tasks, I will use Scrum (an agile method) for this 2-month-long period.
But why is agile working so effective, when should you (not) apply it, and how does it actually work? That’s what today’s blog article is about.
Summary:
- Scrum is applied when faced with complex multi-disciplinary not-well-known problems, to solve them efficiently and creatively
- Projects with a clear goal, enough time, a high degree of external dependencies, and a low degree of complexity are better solved via conventional, linear planning and working methods
- Agile working methods greatly focus on delivering solutions as fast as possible
Practical advice:
- First, decide on roles and responsibilities and further framework conditions, such as sprint duration and reflection format
- Second, create your initial backlog. The backlog is a collection of all the tasks you assume to be accomplished to solve your problem/finish your project
- Third, perform your first sprint
When to (not) apply agile working methods
Scrum is applied when faced with complex multi-disciplinary not-well-known problems, to solve them efficiently and creatively.
Typically, Scrum is applied in software development. Each Scrum sprint (ranging from 1 to a few weeks) defines certain product features to be developed and ends with a testable product. At the end of each sprint, the Scrum team reflects on (user) feedback on the testable product and finetunes its efforts and priorities for the next sprint. Thereby, no substantial time is wasted on the development of product features users don’t want and, eventually, the product becomes more and more marketable.
Scrum is applied also in organizations that want to innovate their products, incl. conceptualizing business models, go-to-market approaches, and enabling IT. Particularly in mature organizations, there are various highly valuable experts for almost any topic. Forming a well-functioning, multidisciplinary team from them to solve these kinds of complex not-well-known problems usually fails using conventional methods. Project managers just cannot accurately predict which expert has to be part of which discussion for the next 3 months. Using Scrum, though, these multi-disciplinary teams can plan their efforts in short sprints. Each team member can plan how much time s/he has to spend on which task. In case the sprint planning was inaccurate, not the whole project is in danger, but efforts are to be re-prioritized in the sprint retrospective.
However, Scrum and agile working aren’t the solutions for all problems and projects. Projects with a clear goal, enough time, a high degree of external dependencies, and a low degree of complexity are better solved via conventional, linear planning and working methods.
Here are some projects hardly suitable for agile working methods:
- building houses
- constructing roads
- preparing for exams
- creating TV campaigns
- negotiating collaboration agreements
Benefits of agile working methods
Agile working methods greatly focus on delivering solutions as fast as possible. The amount of time wasted on planning and creating unwanted solutions is minimized while customer/stakeholder satisfaction is maximized.
An example is building a website for a corporate customer. Instead of planning out each sub-page, its content, and its functionalities, agile methods aim to create a minimum viable product (MVP) as fast as possible, e.g., the landing (home) page. Based on the feedback, the MVP is fine-tuned and further sub-pages, content, and functionalities are created.
In my case, I could spend hours and hours planning the next 2 months. Most likely, though, this plan will turn out inaccurate and make me do things that are rather inefficient. Thus, working in 1-week sprints allows me to work on all the different projects as fast as possible and use the learnings gained in this time frame to optimize my efforts in the next sprint.
How to harness agile working methods (Scrum)
First, decide on the planning and working method. Will you work on a project with a clear goal, enough time, a high degree of external dependencies, and a low degree of complexity? Then, you should go for linear planning and working methods, using e.g. a GANTT chart. Otherwise, you should give Scrum a try. Thereby, you need to decide on roles and responsibilities (depending on the personnel setting, in my case it’s just me) and further framework conditions, such as sprint duration (1 week) and reflection format (end of week 30-minute retro).
Second, create your initial backlog. The backlog is a collection of all the tasks you assume to be accomplished to solve your problem/finish your project. I did so in Notion by creating a page containing all the different projects I want to accomplish in the next 2 months, and for each project, I contemplated tasks necessary for each project.
Third, perform your first sprint. At the beginning of your (first) sprint, you note down all the backlog items you want to accomplish in your sprint period (sprint planning). Then, you start working, ideally creating a daily to-do list (daily check-in). At the end of your sprint, you take sufficient time, e.g., 30 minutes in my case, to think about all the things that worked well, that could be improved, and the priorities of the next sprint. Further, you add further tasks to your backlog, so that you can do your next sprint planning based on your new learnings.
