Lean-Agile Meets the Enterprise Data Group

September 19, 2006 — Posted by Jim Trott

Listen to the podcastLean-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 Agile way, though most groups would have a hard time with that.

For the time being, it may be best just to treat them as a separate work cell with their own approach and let them watch the Agile teams, until they are ready to try it on their own – perhaps in a small way.

A series of conversations with Rod Claar

This show begins a series of conversations with Rod Claar, a Senior Consultant with Net Objectives. Rod is a Lean-Agile coach and a trainer in design patterns and test-driven design. He has worked with many clients as they begin their journey into Lean-Agile approaches. In this podcast, we will cover:

  • Lean-Agile Meets the Enterprise Data Group
  • Lean-Agile, the Senior Developer, and Progressing toward Maturity
  • Estimating through Stories

(Do those sound like the titles to a cheesy sitcom from the 60’s? Oh well…)

Recommendations - Training by Net Objectives

Recommendations - Reading

Music used in this podcast:

For more information, contact info@netobjectives.com or visit us at https://www.netobjectives.com

Blog Type: 
Podcast
Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Jim Trott

Jim Trott is a senior consultant for Net Objectives. He has used object-oriented and pattern-based analysis techniques throughout his 20 year career in knowledge management and knowledge engineering. He is the co-author of Design Patterns Explained: A New Perspective on Object-Oriented Design, Lean-Agile Software Development: Achieving Enterprise Agility, and the Lean-Agile Pocket Guide for Scrum Teams.



        

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban