Agile training classes will teach you the elements of what it is to ‘do agile’, but to ‘be agile’ is to change the mindset of yourself, your team, and your organization, and put the focus on the core tenets of the Agile Manifesto.

Business value

Everything you do, every key you press, spec you write, email you send, meeting you attend, code you build, etc., should have an underlying connection to the business value it provides. All levels of the organization should be comfortable asking why they are doing something and connecting business value to the work. Business value can be direct (e.g. the work will result in better service for the customer) or indirect (e.g. the work is needed for regulatory reporting to prevent fines that would result in increased costs to the customer).

I once spent weeks trying to get the details correct for a specification for a new field that my manager was convinced the business would want us to build. When I went to the business manager to ask her for clarification on it, she told me that nobody in the business would ever use that field because it didn’t meet their marketing needs. The DW team was convinced that if we built it she would use it: so we built it, and it never got used.

Continuous process improvement

When I was a consultant and a client told me that they had tried agile before and it failed, I would often suggest they rebrand it as continuous process improvement (CPI) when they tried the second time. Even those who are tired of the word ‘agile’ will get on board with the idea that you need to be always improving.

As with business value, CPI must be ingrained in your culture. This takes time and it is harder in organizations that strongly silo roles and responsibilities. The sprint retrospective is one way scrum encourages CPI, but there are other things you can do to encourage CPI behaviours so that, over time and with encouragement, people become more proactive and empowered.

We have all been in meetings or hallway conversations where something was suggested and the respondents agreed it would be great. Two weeks later the idea comes up again, and we agree that it would be great and we assume someone else will follow up on it. A week later we start getting grumpy because it hasn’t been implemented. Those conversations continue until the idea either dies out or someone who feels empowered picks the idea up and actions it.

In my last scrum team, we added a team agreement that said “We will not ignore things; we all take responsibility and ownership for remembering and acting on issues and ideas.” When something was suggested and we agreed it would be a good idea, we didn’t move on to the next subject until one of us volunteered to follow up. This applied to big things, such as improvements to our architecture, and smaller things, such as adding a step to our definition of done.

Maximize the amount of work not done

This is one of the key agile principles, but in data warehousing in particular we tend to ‘future proof’ and ‘what if’ ourselves into delivering things that the customer does not need, because we are worried that one day they might.

The most glaring example of this is with slowly changing dimensions (SCDs). In data warehousing, we love history. I’ve been told that a DW isn’t a DW if it doesn’t have SCDs. But I have also helped build two DWs that didn’t have a single SCD, and still delivered huge business value. In both cases, SCD scenarios were in our backlog but never got high priority.

Two of the largest DWs that I worked on started their journey with a decision to treat all fields as Type II (track changes to the field over time), unless there was a good reason to set the field to Type I (overwrite the changed field). In both cases, after months and months of spider-web code, slow builds, and training chaos, they both reversed the decision and decided to go with Type I unless there was a good reason to set the field to Type II, thus maximizing the amount of work not done.

Rework is a fact of life

With waterfall, requirements and design are done up front, whereas with scrum they are more fluid. It is harder to plan ahead and there is always the possibility that you’ll make a mistake in your design or requirements that will force rework. It’s a very uncomfortable feeling to build something that you know could need to be redone at a future point if requirements change or evolve.

It took one of my most experienced developers months to adapt to the idea. He took great pride in his work and worried about the reputation hit if someone thought his code wouldn’t stand the test of time, and the wasted cost spent reworking the code later. But I argue that reworking code later (if needed) is not nearly as arduous as we make it out to be, and while we are waiting for the possibility that this needs to happen, the business users are reaping the benefit of what we initially delivered.