Highly productive individuals, teams, and organisations don’t get to that level merely by accident. It happens through hard work on process which, in turn, leads to consistently-great outcomes. Doug Belshaw ‘Trello Kanban’

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:

  1.  Show respect for all team members
  2.  Communicate openly and clearly
  3. Look for ways to innovate
  4. Actively improve your skills
  5. Your work doesn’t have to be perfect
  6. 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.

Agile Methodology and the Push and Pull of Work by Aaron Davis is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

One thought on “Agile Methodology and the Push and Pull of Work

  1. Doug, I have really enjoyed your current learning out loud with your Masters in Systems Thinking. This piece really stuck with me. I have been grappling a bit with project management and the agile methodology since been asked to complete a course as a part of my change of roles where I work. I think I had thought that I was being agile (maybe little a agile), but was left struck by the rigidity required in actually sticking to the process. (I am guess this is where your focus on being deliberate fits in?) The thing that has struck me is the conflicted nature of the push and pull. I agree with the intent, but unless everyone is onboard and clear about expectations, it all becomes a bit of agile-washing.
    The other thing that has really struct me is the world of project management and the lived reality. It feels like a lot of people want to do project management, without actually doing the hard work. Lines are drawn, positions set, but when the game starts and chaos ensues, they are lost at sea. I have been left wondering if project management really exists and if so, what does it look like? I hear the successes and achievements, this pie chart and that bar graph, but the reality feels like something different. I am therefore intrigued by your discussion of system inquiry. It reminded me of Dave Cormier’s discussion of ‘complex’ versus ‘complicated’:

    We are confronted by the complicated/complex division everyday in education. Do I want to know if a medical students has remembered the nine steps of a process of inquiry to work with a patient or do I want to know if they built a good raport? How often do we choose the thing that is easier to measure… simply because we can verify that our grading is ‘fair’. How often do we get caught in conversations around how ‘rigourous’ an assessment is when what we really mean is ‘how easy is it to defend to a parent who’s going to complain about a child’s grade’.

    Source: Making Change in Education II – Complexity vs. Lean Six Sigma (learning isn’t like money)

    Might be something I need to dive into further.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.