Having tried out the Scrum framework during the first rapid ideation session and concluding that while aspects of it are useful, it is more compatible with small group projects, as opposed to working solo. In my sprint retrospective, I mentioned that I would take aspects of the Scrum framework I found useful and apply them to future solo projects, without fully implementing Scrum. However, I have since decided that for this second rapid ideation session, I would instead try a different form of Agile framework for managing the project. I primarily searched to find out if there is a framework that is particularly good for solo projects.
During the first rapid ideation session, I use Trello to create what is known as a kanban board for the purpose of managing my sprint and product backlogs according to the Scrum framework. I eventually abandoned this Trello board as I found it did not fit within the workflow I had set up. I did not rule out using Trello/kanban boards for future projects but for this particular one, it just did not fit.
While searching for alternative Agile frameworks, I found out that there is in fact an Agile framework that is called Kanban (Radigan, D., n.d) and is named as such because it is orientated around the use of a kanban board to manage the assets and tasks within a project. The Kanban framework is focused on visualising the progress of a project, which is something that I have found very beneficial in the past.
To learn more about the Kanban workflow, I watched this video on how it is done.
While the video demonstrates that a Kanban board generally divides up tasks into lists based on its status, this is not the only aspect of the Kanban framework.
There is a key component of Kanban, which is setting limits on work in progress. While all Agile frameworks seek to counteract the rigid approach of the Waterfall method by acknowledging that there is overlap in several tasks and leadership roles can be assumed by different members of a team at different times, the Kanban framework seeks to ensure that there are never too many tasks being carried out at a time. This is done by setting a maximum upper limit on tasks that are in progress.
This ensures that those involved in a project can carry out the tasks they do have as quickly and effectively as possible before taking on new tasks. The visual nature of Kanban allows those involved in a project to visualise how many tasks are being carried out at a given time, through the use of lists.
Like Scrum, Kanban is dependent on a backlog of tasks which builds up (Rehkopf, M., n.d) as the requirements of a project build up. However, a Kanban project is not split into individual sprints in the same way that Scrum is and instead is treated as a continuous flow of work. Therefore, Kanban only has one backlog and not two separate ones, as Scrum does.
With Scrum, the commitments and objectives established within a given sprint are locked in and cannot change once a sprint has commenced without exceptional circumstances. As Kanban uses a less rigid structure, there is more room to change priorities and reassign work depending on any obstacles that arise. This would have been useful during the first rapid ideation session, as I was essentially building a game as I was designing it in order to develop my skills and I frequently ran into technical issues that I needed to rectify.
The tasks in a Kanban backlog are developed through the use of user stories, much as they are in a Scrum backlog, but focuses on reducing the time it takes to fulfil the needs of each project or task. Carrying out work quickly and in a way that facilitates improvement through evolutionary change is an integral part of Kanban, as well as an important aspect of rapid ideation.
Through reading up on Kanban, most of it is written with the assumption that the reader intends to implement it in a team situation. However, there are aspects of Kanban which indicate that it may be more conducive to solo projects than Scrum. For example, while Scrum is non-hierarchical, it is organised according to the various roles and abilities of the team and it mandates that there should be a designated Scrum master and Product owner to oversee the project. The Kanban framework does not have any such requirement which indicate that it is also suited for project management on a solo basis.
I have therefore decided that for the second rapid ideation session, I will implement the Kanban framework. I will create a Kanban board onTrello that will consist of lists according to the status of each asset or task within the project and I will also decide on what the limit should be on the number of WIP tasks at a given time. I will then start populating my kanban board with tasks according to what the goals and requirements are for the project. While I have decided on Kanban over Scrum, I may consider taking elements of Scrum that I found particularly useful during the first session, such as the ‘Stand-up’ blog posts where I reflect on my progress each day.
I will assess how much progress I make using the Kanban framework duriing the second rapid ideation and I will compare it with the progress I made during the first rapid ideation session where I used Scrum. I will not only need to consider which is the easiest to use or most practical for a two week project, but I will also need to consider how much Kanban allows critical reflection, compare to Scrum.
References
Radigan, D., n.d. Kanban – A brief introduction | Atlassian. [online] Atlassian. Available at: <https://www.atlassian.com/agile/kanban> [Accessed 4 March 2021].
Rehkopf, M., n.d. Kanban vs. scrum: which agile are you? | Atlassian. [online] Atlassian. Available at: <https://www.atlassian.com/agile/kanban/kanban-vs-scrum> [Accessed 4 March 2021].
4 Replies to “Kanban: a new Agile framework”