This year I was seconded to help in the technical team. In some ways, I am doing much of the same work as before in responding to issues pushed to us, whether it be debugging problems and supporting schools. One change though has been a focus on the technical changes and enhancements. As a part of this, I was asked to complete Atlassian’s online courses associated with the use of Jira and the agile methodology.
In 2001, a group of developers published the Manifesto for Agile Software Development. The manifesto outlines four key values associated with the agile mindset:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Source: Manifesto for Agile Software Development
In unpacking these values, Atlassian provide six tips to build an agile mindset:
- Show respect for all team members
- Communicate openly and clearly
- Look for ways to innovate
- Actively improve your skills
- Your work doesn’t have to be perfect
- Have a plan, but always be ready to pivot
Although there are many agile frameworks, Atlassian focuses on two in particular: Kanban and Scrum.
The Kanban framework allows teams to visualise workflows associated with work and improvement. It focuses on columns of cards, which allows all involved to easily see the progression of various tasks. (For example, Doug Belshaw introduces Kanban with three columns: To do, Doing, and Done.) Associated with each card, there are details, checklists, attachments, labels, work in progress (WIP) and collaboration through comments. I have discussed the use of Kanban boards in the past in regards to Trello.
Scrum is about iterative delivery of batched improvements. Groups of issues are organised into sprints with a clear focus and a set number of WIP points. Unlike Kanban boards, sprints are time-based, with future work added to a backlog. In addition to the boards, there are certain structures and processes. This includes regular meetings focusing on what has been completed, what needs to be completed and any obstacles, a review of accomplishments, and a retrospective that focuses on what the learnings from the sprint. Associated with the boards and meetings, there are roles central to the cycle, including the product owner and the scrum master. The product owner is in charge of recording requirements and identifying priorities for the business, while the scrum master acts as a coach, responsible for the performance of the team.
Personally, I had dabbled with using Kanban in my work before. I had also explored the idea of agile management in education through Richard Olsen’s Modern Learning Canvas and Simon Breakspeare’s Teaching Sprints. However, I had never dived into the world of scrum and sprints as a part of my current work. One of the reasons has been that it has not been the methodology of the teams I have worked in.
One of the interesting challenges I find with any agile approach is how it works in practice. According to Atlassian, best practice is to make the habit front and centre. This involves using Confluence for documentation and communicating everything by using the @name from the various cards. This then allows the use of various reports to improve processes and outcomes. The problem with this is that it often places other things in the periphery. If all I did was project work, it would be perfect. However, I feel like I work in a dual operating system. I manage my time between the push for enhancements and improvements, and the pull associated with everyday support. The problem is that it feels that both sides are often oblivious of the other. In regards to agile, this often creates scope creep where things are often added that occur outside of project planning.
In addition to this, it would be nice if Jira (or Atlassian) was the only place where I worked. The project I am a part of has many different signals, including email, Google Drive, OneDrive, Microsoft Teams, Google Chat and Ivanti’s HEAT. There are often times when I am not sure where I am meant to look. For me, I think that the various cross-messaging is often akin to football and a team defense where everyone plays their role producing an outcome where the whole is greater the sum of the individuals. However, when there is not buy in across the board, then the system fails.
Another interesting consideration is the structures of something like scrum. In their introduction to the topic, Chris Sims and Hillary Louise Johnson talk about the optimal size of teams:
So, how many team members should a scrum team have? The common rule of thumb is seven, plus or minus two. That is, from five to nine. Fewer team members and the team may not have enough variety of skills to do all of the work needed to complete user stories. More team members and the communication overhead starts to get excessive.
Source: Scrum: a Breathtakingly Brief and Agile Introduction by Chris Sims and Hillary Louise Johnson
I am in a team of four and this creates some confusion at times about who exactly is doing what roll.
In the end, my biggest takeaway was that agile was a mindset, a way of thinking about continual improvement and development. I was subsequently left wondering if the best methodology is one devised based on the requirements of the particular context. With this in mind, I found Eric Ries’ The Lean Startup interesting in that it offers mindsets as much as approaches.
If you enjoy what you read here, feel free to sign up for my monthly newsletter to catch up on all things learning, edtech and storytelling.