Moving From a Waterfall to an Agile Approach: Advice to Team Members
For those who suddenly find themselves on a working team where the leader is getting excited about “agile”, “SCRUM” or some related word, take heed. Perhaps a class has been instrumental in this excitement or perhaps it’s a mandate (or implied mandate) and now it’s time for the business intelligence team to take it up. Either way, here come the changes.
I’ve brought this change to our teams and clients, learned some bumps along the way and gained some perspective I’ll share here. I won’t focus on what agile/SCRUM is for business intelligence, but instead today I’ll focus on the implications on your work.
To be sure, I am referring to the agile approach to business intelligence delivery, not to the buzzwords “agile business intelligence” which refers to an end result of empowered end users with unabated access to their information. That’s a worthy goal. You can get there different ways, but I suggest an agile approach is best.
First, be aware that this is a good, career-enhancing position you have found yourself in. This is true because increasingly projects are going to utilize agile and companies will desire experience in agile. This is true also because your project (provided you take care of the implications I’ll list here) is better poised to deliver on-time – also an experience companies find desirable. So, start by being open to the idea. Otherwise, you become the horse that is led to water, but will not drink.
The primary implications of the move from a waterfall to an agile approach to business intelligence for the team members are:
- Delivering to Production More Frequently
Going to production will become a normal part of near-daily life, not the light at the end of the tunnel. Like a lot of things, once you begin to do something regularly, it becomes comfortable. Going to production will become like this.
- Less Documentation/Regular Communication Meetings
Actually, for many shops, agile is a veneer for a lack of documentation so agile doesn’t necessarily mean less documentation. However, in the place of documentation is more meetings and verbal communications.
- More variety of work
Since 2/3 week sprints are planned right around their inception, there is a focus on a key deliverable and a direction to avoid multi-tasking, your remote talents may be called on to deliver a sprint. You may be an ETL professional who needs to work on the business intelligence side of things for a sprint or two for example.
- More shoot first, aim later
It’s no more marathon where there are serious periods of coasting. It’s now all short sprints. Get used to delivering more – as well as correcting more as a result. It’s the best way to arrive at the same destination, only faster.
- Sizing Your Own Work
Work group members are supposed to size their own work efforts in the sprint planning meeting. This is different from being given a deadline. However, honest assessments are vital to overall planning and if you seriously under- or over-estimate your tasks, it’s likely to be viewed poorly by your team.
- Immediate Quality Assurance
QA is still usually a different environment and still requires code migration. However, as with going to production more frequently with less code, the same will be true of QA. End-to-end and regression testing will have to be in place and exercised at discretion, not with every change.
- Less Pretense of Long-Term Foresight
This is a deficiency in many agile teams, which is the lack of that long-term plan (i.e., “the analytic system will be in production in the fall”). While I advocate having a flexible long-term map of anticipated sprints, many agile teams continue sprint-to-sprint without one. At the same time, get used to much more frequent planning meetings.
- Multiple Leaders
The centralization of the leadership roles on an agile project gives way to a distribution of the responsibilities to people with roles of Project Owner and Scrum Master. The Scrum Master, in particular, may not be a business intelligence domain expert, yet plays a crucial role on the project by owning the development process.
- New Terminology
The new forms and lines of communication in agile come with new terminology that must be used often and very specifically.
- More Teamwork
Most of the team is suddenly thrust into an “equal” position – a team member. Senior leaders are mixed with junior developers and performance is based moreso on delivery than seniority. Replanning of work efforts can be done very frequently and with the variety of work comes a commitment to teamwork.
Overall, I’ve found that people new to agile approaches in business intelligence find that things are moving “too fast” and “too out of control” at first. The newfound sense of freedom can be overwhelming as well. Many find that not enough emphasis is placed on planning. Some will not adopt and will not assist the leader in adopting agile to the situation. However, most will ultimately thrive. You will get used to it and hopefully come to believe it is improving your abilities and your contribution.
Remember, with anything new, there will be stumbles and this is definitely true for the leader hard-charging into agile. Hang in there. The agile approach says “fail fast” and this is true not just for the projects, but for the adoption of the agile approach.