My Agile story started reasonably recently, less than two years ago. I joined OptimalBI as a Data Vault developer. They were already using Agile and the Data Vault development process is nicely aligned with an Agile methodology, so my transformation into Agile went smoothly. Agile was a paradigm shift in software development. Business Intelligence projects have their own nuances and the Data Vault methodology easily fits it.
This project is slightly different. We are building an extension to the Data Warehouse automation tool and wanted to use Agile. Our project specifics are:
- a small development team – only two developers are working on the project
- business users are only interested in the final product delivery, not the intermediate steps – “Do your techy magic, so I’ll be getting my reports faster” or “I want this tool to generate a Data Warehouse object for me”
- tools and problems are completely new to the team and are complete unknowns
The project has tested my Agile skills. In this blog I want to share some ideas with you, speaking right from the eye of the storm.
Agile is not about skipping the documentation
Most developers don’t like to write documentation. Most developers don’t like to read documentation written by someone else. These people tend to read the whole Agile Manifesto as “No documentation required” and skip “interaction” to just do what they believe they are best at; full-time coding. This results in a project with no clear understanding of the product’s functionality, its roadmap and no documentation.
Ideally, a project’s delivery should not be delayed (too much) if a key developer is hit by a bus or, more prosaically, resigns. But how can that be achieved? I believe the Agile environment has the means and the Manifesto has some tips to put it into practice; most importantly, “individuals and interactions”.
There’s always a story
In the beginning, we struggled to write good user stories. Our first stories were too big or changed during the course of a Sprint because, as I mentioned above, the tools and problems were new to us. I believe it’s important to break up monstrous tasks into chewable chunks, and research stories are good when there are too many unknowns. Research stories are used to define a group of development stories with criteria which won’t change because everyone knows what they want to achieve and how to achieve this already. Research stories should be time-boxed with clear acceptance criteria to ensure they don’t over-run.
Over time, we became more confident writing stories. Our backlog started to fill in with different types of cards: tasks, stories, epics, time-boxed stories and bugs. Writing a story becomes easier with practice. The difference between a task-list and stories is that stories get communicated within the team, acceptance criteria are written together with the Product Owner and stories are get prioritised and selected for development together, again, working together as a team.
Dividing work into stories also helps in building a good development culture. A story the size of a piece of code is a good size for a unit test, a single version control commit or as a piece of code for review. Also having a backlog of stories ready to be picked up makes it easier for developers to work together. A new developer has good visibility of the next stage of development; they don’t feel they’ve inherited Frankenstein’s monster where their task is just to revive it. With reasonably sized stories, the overall task seems not so daunting.
But what about documentation?
In a project as small as ours was, it is reasonable to have just a physical Agile board on the wall with stories on sticky notes. But using a software tool like Trello, Jira or Rally, has its benefits. As an online tool and you can make it available to a dispersed team; and most importantly it stores the history of your project development. At the end of the project, the stories show the journey of the project. Just reading the story titles gives an overview of product’s functionality. The list of stories you’ve finished over the period of time also helps with reporting.
Don’t skip code review
Imagine a developer has written a story-sized piece of code that does exactly what it supposed to do, meets all the acceptance criteria, is fully tested, and proven not to introduce new bugs. Moreover, the developer has formatted their code to make it pretty and easy to read, and also they’ve used all the coding tricks and made sure they’ve checked it with a fresh eye. Why would they disturb another developer to review it? A code review is not (only) about double checking that things are being done efficiently; it is also a great way to share knowledge. The reviewing developer becomes familiar with the product’s functionality and code, enabling algorithms and functions to be reused in the future. That keeps the product consistent.
My final word about Agile
My first impression of Agile was it looked like a methodology focused on aggressive delivery; maximising the effectiveness of teamwork. Because of this, it looked to benefit the employer but looked scarily exhausting for employees. I think some old-school developers may still see Agile as a methodology that only suits ambitious rock-stars. They see it as putting their jobs at risk because having a full delivery and process transparency exposes the difference in their work speed. Now I’ve been in the Agile world for a while and can say that Agile makes everyone equal. Everyone has to follow the same routine and meet the same criteria. Stories get written and prioritised by the whole team; all ideas are shared and tasks become clear to everyone equally. This results in consistent story delivery, but it puts a lot more discipline on people. And trust me, ambitious rock-stars don’t like discipline. So actually, there are no pedestals in an Agile team.
Agile is a “from each according to their ability, to each according to their needs” kind of thing.
Data Masseuse – Kate