It’s no secret that successful products generally come from having a good understanding of the needs of customers and developing products that match those needs. This blog describes the approach that we took to increase the domain knowledge of the DLM Automation team with a view to helping them develop better software for our customers.
I’m the Project Manager for the DLM Automation team who develop Redgate’s DLM Automation Suite (DLM: Database Lifecycle Management). They’re a talented bunch. However, as with many other software teams, we find it something of an irony that our customers almost always know more than we do about the product’s domain. This is because the team’s expertise is in developing software, and people work on many different types of software over the course of their career.
For example, I’ve worked on software for hospice management, fund management, bingo halls, energy management, and database development, to name just a few. As a result it can be hard to develop a really deep domain knowledge.
In the case of the DLM Automation team, we’re developing tools that help our customers to automate the deployment of their database changes. Our customer domain isn’t a million miles from our core development skills. We’re experienced at automating our own application lifecycle; we do this on a daily basis. However, we don’t develop many database applications and so we don’t have exposure to the same problems as our customers.
To help fill this gap, we decided that the team should spend some time learning about scenarios that stop our customers fully implementing Redgate DLM.
How might we tackle this problem?
Before deciding how to go about improving our knowledge, we looked around our own organisation. Other teams in Redgate have faced similar challenges. The SQL Monitor team and the Migrations team both ran a “day in the life” workshop, where they were presented with a problem to solve using their respective products. Redgate also hold DLM workshops, which we could have booked team members onto.
However, we didn’t think either of these approaches would provide the depth and range of knowledge that we were hoping for. Instead, we decided on a three-step approach:
Create a test application
Use the application to explore the kind of real-world problems that we needed to learn about
Create a number of articles that would help end users solve these problems
How did we get started?
Once we had decided on the approach, the next step was to work out what the common problems in DLM are, and then create a product scenario that would allow us to explore these problems. This is where our product manager, Richard, came in. He has 15 years’ experience as an IT Manager designing, developing and maintaining business applications and data. He came up with a list of common problems customers might face:
Cross-database dependencies using synonyms
Cross-server dependencies using linked servers and synonyms
Multi-component deployments – apps/services with multiple-database dependencies
Different architectures in each environment
Different features in each environment, such as encryption only being switched on in production
Different AD groups for different environments
Transactional replication
Richard and the team then created a scenario for a fictional web application, LightningWorks.com. This consisted of a web front end, several web services and two underlying databases. They introduced various constraints to the system to expose some of the challenges listed above.
The next step was to decide on an appropriate delivery pipeline. We chose:
GitHub for source control
SQL Source Control for the database source control
TeamCity and SQL CI (part of the DLM Automation Suite) as the build server
Octopus Deploy and SQL Release (also in the DLM Automation Suite) to deploy to QA and production
We could have completely ignored the application side of things. However, we wanted to create a scenario that was as close as possible to real-life development, so we decided to include a basic UI.
Another consideration was that the team are not writers. Our technical author, Will, created a short writing guide, giving the team guidance on article structure, language and tone, and how to avoid common clichés. We also decided he would help them with copy editing the articles.
What happened once we started?
Once started, we spent about a week getting things in place – requisitioning servers, and creating the UI, services, and databases.
Week two was when things got interesting. This was when we started introducing some of the real-life problems. For each problem, the team researched possible solutions. They then picked the most appropriate solution and implemented it, all the time making notes and taking screen shots. Then team members (often working in pairs) drafted an article that explained what the problem was, how they’d solved it, and what they’d learnt.
The team wrote four articles in total:
Deploying cross-database dependencies to different environments
Dealing with production drift
Using database roles in DLM to improve security
Using replication with automated database deployments
How did we produce the articles?
Once the team members had written a first draft of their article, it was passed to Will who reviewed it and gave feedback on style, content and readability. Once Will’s feedback had been incorporated, the second draft was given to the wider team for review and further amendments. Then Will did a final check before sending the article off to the Redgate publishing team.
We wanted to reach the largest audience we could. But we also wanted to reach the right audience. So we aimed to get all the articles published on Simple-Talk, Redgate’s technical journal and community hub. Quite rightly, the editorial process for Simple-Talk is thorough. The site receives around 700,000 visits a month so the editors need to make sure that content will be both relevant and engaging. We wanted to get the right balance between keeping the “original voice” of the authors, who were justifiably proud of the work they’d done, whilst ensuring the style of the articles would be suitably engaging for Simple-Talk readers.
We decided in the end to publish two versions of each article. One version, that will be published on Simple-Talk, uses a narrative style and incorporates characters working in a fictional database development team who discuss the problem and the various solutions. The other version, that will be published on the Redgate blog, is written in the more traditional style for a technical article.
What worked well? And what didn’t?
One thing that worked well was introducing new concepts, one at a time, so team members could learn something, write about it, and then move on while the first article was being reviewed. If we’d saved all the writing to the last week, we would have been bottlenecked. However, the editing process took longer than we expected. With hindsight, I should have managed the tail-end of the project more proactively.
Was it a worthwhile use of our time?
Working on this project proved to be a good use of time for our team. I saw a number of benefits, which included:
An increase in the team’s knowledge
A sense of enjoyment in the team at having learnt new things
An increase in the team’s writing experience
The actual articles, which are a useful resource for end-users
What pleased me most was how much the team threw themselves into this project, especially given they had little experience of writing. The team also released two major bug-fixes during this period which was great.
So while we didn’t stop working on development tasks altogether, we certainly benefited from setting aside dedicated time to learn and gain firsthand experience of issues our customers face in their day-to-day tasks. We hope that the articles themselves also prove useful to our customers – look out for them on Simple-Talk and the Redgate blog over the next few weeks.
How have you solved this problem?
I’d be interested to hear how other people have tackled this same problem of increasing domain knowledge in a development team. Please share your thoughts below.
The post Helping development teams better understand the needs of their customers appeared first on Redgate Software.