I don’t come from an agile software background. Most of my professional experience has been part of standard waterfall based schedules and planning, where you have everything pre-planned out – a schedule showing “exact” start and stop dates for each task and quantified process to capture earned value against your performed work. Now, at Nebbia, I have been a part of many agile software development projects. Becoming immersed in this different type of work cadence has brought a lot of opportunities and new ideas to how I work. Below are 3 of my personal favorite agile methodologies and how I apply them to my own work and project management in general.
“we reserve the right to get smarter”
This is a phrase I have heard a lot in one of our current projects. It is a key tenent of agile software development to continually groom the backlog, estimate effort, and plan for next sprint. Sometimes this has to be an educated guess, the true scope of an item might not become clear until you’re able to start working on it. As a project manager I like to know what we’re doing, how long it going to take, and track the deliverables to completion. In the fast paced agile development cycle there will be unknowns, additional tasks will be uncovered and some things will take longer – as the project manager it’s not my job to foresee all these potential problems but instead ensure we are tracking and managing the changes appropriately – where has there been added scope, what unknowns have been uncovered, and how does that affect the schedule and deliverables.
“deliver early and often”
Another agile methodology is to deliver software to the end customer often and therefore get an invaluable feedback loop to help direct future effort. This methodology can be leveraged in many other areas and it’s one that I use most often. Sometimes I’ll be asked to put together estimates or projections to plan future effort. Typically, there are a lot of potential variables and ways to put these together. Borrowing from the agile delivery mindset I have found it to be helpful to develop an initial cut and then circulate that with whoever requested the estimates. This feedback loop typically ends up helping shape the future direction I take and greatly reduce the rework and overall time spent.
“looking back helps us move forward faster”
Retrospectives are a key part of an agile software scrum team. During retros the team is able to reflect on the previous iteration of work and call out what went well, what could have been better, and how to avoid the same pitfalls in the future. I have found this practice to be useful in many other areas as well – after a large presentation, thinking critically about how it went and issues that came up – or even providing a status update, checking our assumptions over time – did what we say last time actually happen – if not why, what could I have done to catch this issue faster.