Back to articles list
Welcome! This is my first blog entry. I would like to invite you to explore the world of Scrum and databases. I’m a professional Scrum master. During my work, I’ve frequently encountered difficulties when collaborating with others to model a database. I would like to present crucial elements of applying Scrum. I will prove that Scrum is a perfect solution for plenty of teams.
A Long Time Ago, in a Galaxy Far Far Away – Waterfall
A lot of development teams use waterfall or combine waterfall with iterations. All tasks are precisely distributed between team members on the basis of a project’s phase. Business analysts collected requirements, system architects created a database model during the design phase, programmers worked on implementation, testing & validation and deployment & maintenance. The three groups rarely worked together.
Each phase has to be finished before moving on to another phase. Having finished the phase, its performers usually concentrated on the next project. This happens especially in big companies where analysts work in requirements and design phases. When they finish a project, they start similar phases in another project. See the waterfall model of project phases below:
In waterfall, a product was shown to a client at the testing & validation phase, which is why a product didn’t often meet the client’s expectations. It is difficult to believe, but in the business world just 15% of requirements remain up to date after a year (source: Katarzyna Mrowca lecture at Confitura 2014 Conference in Warsaw). Also, changing the database in a waterfall environment wasn’t easy. Changes occurred once every 2-3 months and called for involving the architects who designed it – people who were often already on a different project; the programmers who needed to modify the code and the testers who had to check it again.
The Right Person in the Right Place
Scrum doesn’t require a strict division of roles. It’s no accident that every team member is called a developer in a Scrum environment. In other words, all team members should be able to perform every task. There is no distinction between an analyst, an architect or a programmer.
Perfect Scrum team members can be compared to a letter “T.” Firstly, they have wide knowledge in plenty of fields (UX, programming, database modeling, gathering and analysing requirements, testing). Secondly, they are experts in their specialisation (for instance, JEE programming). When it comes to database design, every team member should know how to prepare a database model.
Database Model Should Have Many Authors
Don’t you think that a database model should have many authors? It allows a team to understand business better: everyone knows the model because they have worked with it at some point in time. Therefore, they perform their tasks more effectively. It will also facilitate implementing changes.
Still not persuaded? Consider whether your architect and your team would pass the test of the rolled over bus. If you architect were run over by a bus (or simply has fallen ill), would your team be able to continue with database design?
Scrum Principles and Database Development
Let’s see the Agile Manifest – the Basic Law for Scrum teams and how it refers to database development.
People and interactions over processes and tools
This rule reminds me of an outdated scheme of work. Architects used to be based in expensive software, for example Power Designer. The tools like this separated the team from a data model. They reduced collaboration when preparing the data model, they promoted authoritarian solutions: it was always the architect who controlled the database model. They also cost a lot.
Efficient products over compound documentation
The second rule stresses that all team members should be familiar with the design of every application. As I’ve already mentioned, every Scrum team member may design a database. Thanks to this, developers know the data model and understand the logic of an application. Nowadays, the DDD watchword (Domain Driven Design) is becoming a benchmark. Scrum teams ought to implement it in order to create better products. In addition, team cooperation supports synergy which is indispensable for successful application building.
Cooperation with client over contract negotiations
Only by cooperating closely with a client can we achieve mutual success. In my opinion, it is the strongest advantage of Scrum. To advise a customer well, it is crucial to do both of the following: understand the core of a problem and master the technology which will solve it. If you’re creating a database application, the expertise in data models, the ability to create an effective database and then a successful application are a key to win in the business world.
Responding to changes over fixed plans
The last rule means that in our job, change is an ordinary thing. Some people understand the rule at once, others never. Briefly, we should all follow the words of Frank Zappa “The human mind is like a parachute – it doesn’t work when it isn’t open.” In the context of a database, this rule means that you should be ready to modify your database model all the time.
Should Database Design Be Considered User Stories?
In Scrum you collect requirements in User Stories. User stories are an alternative to Use Cases which are often applied in waterfall projects (though they can exist simultaneously to use cases, because the purpose is the same). User stories can help you to satisfy customer’s needs. User stories have a very simple template:
As a .......... (here we put who wants this feature, it adds context) I want to .......... (here we put business action, what should the software do) because I need to .......... (here we put the purpose of the action, the reason why we do it).
As an example:
“As an accountant I would like to have the ability to click on a button next to an invoice and count the VAT tax and profit, because I need it to prepare data for a report.”
So should database model design be considered in User Stories? I suppose the answer is negative. A user is – in most cases – not aware that a database exists. The design itself doesn’t have business value, so it shouldn’t be a part of User Stories. Nonetheless in Scrum you have to take the database into account. During the task planning process, the client ought to be informed that creating features involves a database design. Furthermore, it is a good idea to make design a separate component of User Stories.
The Right Database Modeling Tool for Scrum Development
Scrum requires team co-working. But what can you do if your desktop tool doesn’t support collaboration? Obviously, there are some ways to deal with it. For example, you can use a material “token” handed over between database developers to control which of them is currently working on the model (see: “Give the toys back to your children!”). We did that way at e-point for many years. But as the company providing our clients with online systems, we finally decided to switch over to a tool which also works online and has strong support for team collaboration. We decided to use Vertabelo which seemed to be a perfect solution for Scrum teams. And it was like catching the ball on the fly.
Firstly, if your database modeling tool is available in browsers, you can reach it whenever you want and wherever you are. There is no need to have a dedicated computer where you install a costly desktop modeling app (which only an architect will use). Secondly, it allows all Scrum developers to work on a database model simultaneously. Everyone can view the model when they need to. Everyone can make changes in the model. Everyone can comment on the model. It’s priceless.
Let’s concentrate on people and interactions! So when will you change your tool and give your database designers the real power?
