When I started at Potato in 2018, I was given the opportunity to take on a project which at the time was excluded from any business strategy or future vision, including limitations to management frameworks. Fast forward 2 years and we have a successful, self-organised team using Scrumban.
It was my first time working for a digital product studio. It soon became clear to me that I needed to adapt my management style, not because I felt a lack of knowledge but because I noticed the ways of working were different to a traditional software house. We were delivering software for a client and not for ourselves.
“The key to successful leadership today is influence not authority.” - Kenneth Blachard
With framework aside, this has always been the very focus of my role in delivery.
Foot in the door
Well, you got the job, congrats!
Coming in on your first day can certainly be daunting, so many thoughts about what others are thinking;
Who’s this new guy? What opinions will he have? What’s he looking to change?
My favoured approach in this scenario was to take a step back and understand the inner workings of the project before making any overwhelming changes. There’s already been a process in place before you’ve turned up and many mindsets which will need the willingness to flex and change. After all, being agile means to be ‘flexible’, right?
Assess and understand clearly what the current process is. Start raising questions for yourself to dig deeper, so you can dial into exactly what is happening.
If it’s not Agile, why not? If it’s scrum, why scrum? Are the team stressed? Are the stakeholders happy? Are we delivering on time?
Respect
This will be where the journey of transition will begin and perhaps the most important factor in order to get people on board and on your side.. The truth is, people aren’t up for changing things unless it’s been backed up by close peers or colleagues. Nobody likes a new guy coming in and telling you what to do.
Get to know your team, whether that’s through 1-2-1s or an informal chat at your local coffee shop. Start building rapport early on, it’ll go a long way.
Understand the project as a client or user understands it, the different workflows of the product, the complications of it, the areas of the product which cause stress to the developers. You don’t need to be a technical expert on the product, that’s what your devs are here for.
Get to know your client, both formally and informally. A mixture of what they like to do outside of working hours coupled with any pain points they’ve had whilst being on this project. We often focus too much on formal conversations, I've found the most important problems can be solved efficiently by a more casual relationship.
Strive to be a servant leader and not a micromanager. Prioritising the needs of others ahead of your own, empowering your employees and keeping them happy.
Transparency is key
The heart of successful delivery always circles us back to the Software Development Lifecycle, no matter what framework you decide upon.
Transparency is undervalued and often not given the attention it deserves. In fact, it’s hardly spoken about. Being transparent both internally and externally will strengthen your relationship and trust.
Tools. Look at the current tools you are using. Can these be fully transparent to your client? Can we have the client raise a ticket directly into the backlog? Can we have the client build rapport with the development team through the tickets? Protecting the development team can still remain at the forefront of these decisions. The goal here is to find a fine medium.
Processes. Do the processes in our lifecycle allow the client to check progress of a deliverable without raising too many obvious questions? Does the development team get sufficient information from the client on a given issue? Are the channels available to open communication where required?
Coaching. Coach your client on exactly which framework the team is using and how it works. Explain to your client what the do’s and don'ts are, put forward the team’s expectations. You will likely have a teething period during this process however you can often use the tools to aid you. For example, if you have issues with the way a client is raising a story, you could have a template within your tool that automatically gives them a guideline of what’s expected.
If you can nail this with your client it will remove the ‘us’ and ‘them’ mentality within your project. There will be less questions asked around the progress of delivery, because they can monitor it themselves.
Execution
Substantial changes can always be overwhelming. The key to executing changes within delivery is to take small steps to your end state. Just as you’d break down an epic into smaller stories to deliver software, we can apply the same methodology for changes in a delivery framework. In fact, there’s no reason why you couldn’t run this on a Kanban or Scrum board yourself, to help track your progress. You could even run this through your own delivery lifecycle.
Start with your first change and introduce it to your audience, this could be classed as a backlog refinement session. Have them engage and understand the change. Once on board, we can move to a state of ‘in progress’ and begin rolling out the change. We then move onto the other stages of our lifecycle, ‘testing’. Test the change with your client, come up with a plan of when you feel that the change is satisfactory. Once complete, we can move this to done and revisit our backlog for the next item. Rinse and repeat.
Continuous improvements
Revisit previous changes to your delivery framework and check to see if there are further improvements that can be made. You can also gather feedback specifically on tooling and processes through retrospectives or scheduled meetings to measure your success.
Often in an agency model you will have clients that are external to the day-to-day running of the team. You should also check in with your clients regularly to address any pain points or bottlenecks with any change in process. I often use a weekly client catchup which is outside of the traditional Agile ceremonies to capture this.
Moving forward
My goal by writing this article was to give some extra insight into Agile Project Management that’s often overlooked in books or courses. There’s often a lack of focus on a delivery cycle itself and how you can adapt or optimise it, depending on the needs of your stakeholder.
What challenges have you found working in product delivery? I’ll be sharing more in due course but in the meantime if there’s anything specific you would like to hear more about, please reach out via mail@p.ota.to!
About me: I’ve worked in tech for a little over 10 years, starting my career as developer. I’ve since got more involved in project management, combining my developer mindset with delivery tools and processes. I’m fascinated by different management styles, tools, frameworks and learning that can be applied in different projects.