Where to start? When I look back at my blogs, I see they focus on problems! I guess that must be my mind set. With this blog on agile I wish it didn’t fall into the same category but unfortunately it does.
I love the idea of agile, I encourage my customers, PMs and sponsors to adopt it, after all in the words of Winston Churchill:
“No one pretends that democracy agile is perfect or all-wise.
Indeed, it has been said that democracy agile is the worst form of government delivery
except all those other forms that have been tried from time to time.”
Apologies for the liberties taken Mr Churchill!
So hopefully you now know I like the idea, so why doesn’t it always pay off? Well these are my experiences in delivering projects in the Data and Analytics space:
- Some members of the project team have not worked on agile before and therefore the first few sprints are spent in education on agile principles. Even though the agile manifesto has been in existence since 2001, it is still surprising how few data engineers are familiar with core concepts.
- The team has several people in it who have all done agile before, however, they all do it differently. These agile aficionados all maintain that their way of doing agile is the way the right way. It adds so much confusion and meetings are spent discussing the nuances of agile instead of planning and sprinting.
- The team member that attends the scrum of scrums, and ultimately manages the expectations of the executive, commits to precise delivery dates that are not accurate.
- We focus on story points and whilst this tool for abstracting the process of estimation can be useful, it adds confusion to those new to agile.
- The scrum master has not delivered a project that involves data. Data projects don’t ‘flow’ the same way.
- To create a story that has any business value and can be delivered in a sprint is really hard. Story splitting can help, but the team and scrum master needs to be really careful to keep the stories small and the product owner needs to be taken on the journey.
- The Product Owner doesn’t exist or doesn’t have the mandate to prioritise or decide on features.
- The client insist on agile whilst having a fixed price/scope mentality!! Yep I know, and I still have the scars.
- The project successfully delivers and there is a residual backlog that is passed on to BAU however, they don’t have the skillset, resources, or inclination to accept it.
So, what do we do to set ourselves up for success?
- Why use agile? Have a conversation up front as a group to so that the rationale is understood by all.
- Set up simple rules about
- What ceremonies will be used (e.g. Sprint Pre-Planning, Sprint Planning, Standups, Showcases, Retrospectives and who will be involved in each)
- What tools & technologies will be used (e.g. storyboarding tool, collaboration tools, videoconferencing / chat tools)
- When to use a Story, Task, Sub Task, etc.
- What a good ticket looks like.
- Not over committing, even if they are being pressured.
- How to use story points and most importantly what not to do with them.
- Make sure the scrum master has the mandate. Any conversation about how to ‘do’ agile needs to be done away from the scrum. Bring any proposed changes to the retrospective to get feedback.
- The message given to execs at the scrum of scrums must be bought into by the team.
- The scrum master needs to read up on agile projects that are data related, they are not the same as application development.
- A common agile approach needs to be taught to all people associated with the project. This is from the new grad developer to the exec who signs the cheque.
- The Product Owner needs to be educated on the expectations of the role if they haven’t done it before.
- The BAU dept needs to be structured so that they can manage a prioritised backlog resulting from projects.
I still believe in agile and will continue to support it, after Churchill was a smart guy!!
