Summary: Lean-Agile Meets the Enterprise Data Group Enterprise data is an extremely valuable asset that must be protected. Data stewards work very hard to avoid damaging the data and writing high performance code that won’t bog down the data systems or the code that is accessing it. “To protect and to serve” would be the motto of the data steward, and that is sometimes a hard balance to achieve. Especially when it comes to Agile projects whose designs tend to emerge over time. When it comes to working well with enterprise data, what kinds of things should the Lean-Agile coach think about? Acknowledge that data stewards have legitimate concerns Break down the barriers between data stewards and developers Allow the data stewards to follow their own processes At the same time, management must encourage data stewards to see themselves as part of the team, with a duty to support the development project Decoupling application development from the data system One of the issues that comes up in larger organizations is that they try to isolate the database team from every application development team. Then, they end up with dozens of database access routines, each one doing the same job. They end up with lots of redundancy, which exposes them to the likelihood of errors. This is a problem of code quality. This is something that the technical owner, with a lean perspective, should look out for. Perhaps think of it as a decoupling of development teams or processes into work cells. The database team then is responsible for ensuring code quality for routines accessing the database. Decoupling allows both teams can work independently. So that the database team can do whatever they need to – normalize, stored procedures, etc. – they can. You want to avoid redundant accesses to the database. This requires design patterns and a relentless focus on code quality across all of your processes A “Work Cell Approach” to Involving Specialty Areas on Agile Projects Ideally, the data steward is part of the Agile development team. This ensures the highest bandwidth communication between developers and DBA. However, data stewards are usually in short supply. Organizations cannot staff every project with its own DBA. One approach from Lean is to make a senior developer the “Agile DBA” for the team, someone whose job it is to look out for the interests of the data, doing simple things, and serving as the liaison with the data steward team. The Agile team treats the data steward team as a separate “work cell”. They flow requirements to the data steward work cell queue, which then pulls the work from the queue in the normal, lean way. Within the data steward work cell, they use whatever methods and techniques make sense for them, interacting with the Agile team’s liaison as needed. This approach recognizes that they have special work requirements, longer lead times, performance issues, etc. and allows them to enough autonomy. This work cell approach works well for many situations in which highly specialized work is required, such as user interface or data security. This approach requires discipline and lean thinking and must be accounted for in work iteration planning, so that the components are pulled in at the right time. The Technical Owner and ScrumMaster will want to be in regular communication with their counterparts in the work cell. To increase communication with the work cell, invite a representative of the work cell to the initial Define activity so that they can give their input. And then, invite them to the Planning Games for each iteration that will involve them. These work cells should be explicit parts of your Value Stream Mapping effort. You can even do DBA in an Agile way… The reason we use an agile process is that we do not understand the domain and the world changes. Agile processes allow more points of change in a very disciplined way. DBAs face this same challenge of change. It is reasonable to think you could even run a database group in an Agi
