How do we plan and manage larger creative app development projects?
The brief
Write a 250-300 word post noting your progress so far. Identify one challenge and / or an obstacle and one SMART action to resolve the issue.
My experience in week eleven
The source material this week was focused on project management strategies and some of the workflows and pipelines associated with creative app development. The introductory material touched on two approaches to the System Development Life Cycle (SDLC), the first being the traditional (and now much less common) Waterfall approach and the second being the more modern Scrum approach which is one of the various methodologies that sits under the Agile umbrella term.
Both Waterfall and Agile terms are not new to me, though being my career in enterprise software development began post 2000 my experience has almost entirely been within Agile methods and my understanding of Waterfall is based purely on the negative opinions I’ve read or heard that stand to discredit this for one reason or another, most notably that Waterfall has no allowance for change over time and is considered high risk due to the development of the system happening very late in the lifecycle. In my opinion considering the Waterfall approach for any large scale app development today after having adopted Agile methods seems nonsensical but in reality experience has taught me that there are facets of the Waterfall approach still found in a lot of projects, especially in agency work, I think that the main reason for this is that clients generally like an end-to-end plan of how long a project will take and how much it will cost and this is easier done using a traditional bottom-up technique of detailing all requirements and estimating each task based on this which is unfortunately more Waterfall than Agile. Saying this I’ve had some good experiences at agency working on pure Agile projects. The My Perfect Volkswagen app I architected at Tribal Worldwide was built entirely using Agile practices; we stuck quite rigidly to the Scrum methodology with some small influences from Kanban to help visualise and improve the flow of work (see here for comparisons between Kanban and Scrum and how the two can compliment each other). This project taught me a lot about project management, it turned me onto the benefits of Agile methods and influenced how I approach project management today. The most notable benefit I saw from working in this fashion was how the regular deployment and preview in the sprint review meeting at the end of each sprint, aside from being confidence building for the client, near removed the risk of time wastage in the development cycle and how this promoted positive change and ultimately resulted in a better overall application.
Though I have years of experience with Scrum and I regularly practice parts of this method in my day-to-day management of active projects at Antiblanks, I found the Scrum focused content this week to be a welcome refreshment of this method and of Agile in general and this has prompted me to analyse how I am currently managing my projects and whether I am using Agile methodologies to their full potential. I realise that being most of the projects I manage are client projects they are often polluted by facets of the Waterfall approach in having to satisfy the need for more accurate estimates up-front and being used to working in this manor has led me to tailor an approach that works within these parameters but is not true Scrum and is not my preferred method of delivery. I realise also that there are areas where I’ve become a bit lazy with my practice of the Scrum method, in some projects we are sticking to the sprint planning and the sprint itself but we are not conducting formal sprint reviews or sprint retrospectives which (referencing the My Perfect Volkswagen app from above) is where I saw the most notable value.
Tying this to my project
Looking at my Trello board for the ‘Escape Room’ application I can see that this has been polluted by facets of the Waterfall approach in order to obtain an end-to-end estimate for the duration of the SDLC and this is actually violating some of the key Agile principals (namely not welcoming changing requirements) and this in turn is likely to have a negative impact on the quality of the resulting application. Given what I’ve been reminded this week about the benefits of sticking more rigidly to the Scrum method, I think that I need to start being more strict with my board management; I should lose the predefined sprints, put all the tickets into the backlog and despite there only being me on the project, I should start exercising my own sprint planning, review and reflection sessions.
I’ve created a SMART action to maintain a more rigid Scrum focused approach to managing my ‘Escape Room’ project:
- Making it Specific: The goal is to apply and maintain a more rigid Scrum focused approach to managing my ‘Escape Room’ project.
- Making it Measurable: For each two week long sprint I will have a thirty minute planning session at the beginning, a deployment, review and a two hour reflection session at the end.
- Making it Attainable: This action will not add to the amount of hours I am already dedicating to a sprint as I will trade development time to make way for the structured planning, review and reflection sessions.
- Making it Relevant: Following a more rigid Scrum approach should promote positive change to my application’s development and likely result in a better end result.
- Making it Time-Based: I will stick to this approach for six months (twelve sprints).
Summary
In the above post I’ve noted some of my experiences with the Agile approach to the SDLC. I’ve drawn attention to one project where the parameters allowed us to act in a pure Agile fashion and I’ve highlighted some of the benefits that I found in adopting this approach. I’ve mentioned how this weeks source material refreshed my knowledge of Scrum and prompted me to analyse how well I’m using this method. I’ve acknowledged that my practice of the Scrum method in my day-to-day management of projects has become a bit lazy and has suffered from some Waterfall pollution and I’ve gone on to demonstrate how these bad habits have bled into my ‘Escape Room’ project. Finally I’ve created a SMART action to maintain a more rigid Scrum focused approach to managing this project moving forward.