This content originally appeared in TDWI. TDWI members can see the original here.

With so many teams “going agile,” it’s important for your BI team to keep a few things in mind that will help your agile transformation go more smoothly. This series, “10 Mistakes to Avoid In an Agile BI Transformation”, will show you how to prevent the most common pitfalls I’ve encountered in my experience as an Agile Coach.

We do our best to plan for changes and mitigate risks. However, the very nature of change is that it creates disruption. When we start a transformation from our traditional way of working to an agile approach, it may behoove the team to make the transition in such a way that each change can be absorbed before the next small change. Kanban in particular is an agile framework that takes this approach.

Virginia Satir was a 20th century psychotherapist who is often referred to as the pioneer of family therapy. She created the Satir Change Process Model, which she developed through clinical studies. Satir says change starts from the status quo, into which you introduce a foreign element. At the beginning, you typically get a period of resistance where people avoid the new element or pretend it hasn’t been introduced because it’s disruptive. As the foreign element takes hold, the group will fall into chaos where the old way doesn’t serve them anymore and the new way has yet
to appear useful. Even people experiencing a joyful change (such as graduating from school or having a new baby) will go through the resistance and chaos phases in the change cycle.

If the chaos stage lasts too long, teams lose people to other teams or other companies. If they physically stay, they might lose interest in doing anything other than just surviving. Keep this in mind because smaller changes mean less chaos.

When those who’ve persevered through chaos start to see how the foreign element benefits them, it’s called the transforming idea. Then they have something to hold onto as they start integrating the new idea into their workflow. That’s when you get a new status quo which is better than the old one.

Agile actually introduces a little change, lets you shift out of chaos and into a new status quo, and then adds a little change and then another new status quo that’s better than the one before. These are incremental improvements. You’ll be ahead of the game in your agile transformation when you embrace the fact that change is disruptive, plan time and space to allow the participants to adjust to it, and provide support for teams coming out of chaos toward their new status quo.

This content originally appeared in TDWI. TDWI members can see the original here.

With so many teams “going agile,” it’s important for your BI team to keep a few things in mind that will help your agile transformation go more smoothly. This series, “10 Mistakes to Avoid In an Agile BI Transformation”, will show you how to prevent the most common pitfalls I’ve encountered in my experience as an Agile Coach.

Many BI teams have infrastructures designed years ago when all projects followed a predictable, slow set of steps from inception through delivery. BI teams wanting to work in an agile approach will often find their existing infrastructures are not conducive to rapid, evolutionary progress on small pieces of value. Although you don’t have to completely replace your infrastructure before you start your agile transformation, you should identify key areas for improvement and include them in your team backlog to tackle alongside customer deliverables.

Where to start? One option is to learn from software teams in your organization who have improved their infrastructure to support agility. Find out how they did it and what tools they use. Explore whether those approaches could work for your BI environment.

Another option is to do some time-boxed experiments (often called spikes in agile) to challenge your team and discover your capabilities around automated builds, code version control, and test automation.

At the very least, start writing repeatable tests and identifying test data sets so you can be ready for automation when you next have a chance to embrace it!

Read the final common mistake I see teams making all the time. Mistake #10: Expecting Change to Be Smooth

This content originally appeared in TDWI. TDWI members can see the original here.

With so many teams “going agile,” it’s important for your BI team to keep a few things in mind that will help your agile transformation go more smoothly. This series, “10 Mistakes to Avoid In an Agile BI Transformation”, will show you how to prevent the most common pitfalls I’ve encountered in my experience as an Agile Coach.

Once your feedback loops have identified the challenges and bottlenecks you face as a team, it’s time to prioritize them and get them into your team’s work backlog alongside customer-facing deliverables. The backlog is an agile term for your team’s prioritized list of small pieces of value to deliver.

An easy example most teams discover early on is the inevitable bottleneck that occurs when a lot of work needs to be tested all at once. Options to reduce the bottleneck going forward could include automation, enhanced agile testing skills, or applying agile practices that pull quality forward in the delivery cycle.

One team might decide the first step is to try pair programming to reduce defects and make a plan to begin that practice with the next item in the backlog. They might be also ready for test automation and decide to “slow down to speed up” by implementing an automation tool before working on the next backlog item. Another team might decide they want to address this issue at the beginning of their next project because it would be too disruptive to make these improvements for the current one. Either way, each team has created a plan and made improvements a priority within the backlog.

Don’t leave improvements to your free time. Decide where they fit best in your upcoming backlog and make a commitment to address them at the right time.

Read Mistake #9: Working on an Infrastructure Designed to Support Long, Waterfall-Style Projects

This content originally appeared in TDWI. TDWI members can see the original here.

With so many teams “going agile,” it’s important for your BI team to keep a few things in mind that will help your agile transformation go more smoothly. This series, “10 Mistakes to Avoid In an Agile BI Transformation”, will show you how to prevent the most common pitfalls I’ve encountered in my experience as an Agile Coach.

Don’t let the idea of being flexible and fast distract you from your highest priority. Make sure you leverage the feedback loops inherent in your agile framework to maintain focus on your goal.

The scrum framework requires several feedback loops, from daily stand-ups where teammates can request help and communicate to stay on track to a product review with the customer and a retrospective at the end of each short sprint to reflect on what got in the way of meeting this goal.

The kanban framework provides good data on how long each piece of value took to complete, where the bottlenecks are in the delivery process, when the team violates its WIP limits, and the overall lead time from customer request to delivery of value.

A key aspect of all agile approaches is to focus on delivering high-quality work that does not have to come back to the delivery team to be fixed once it’s in production. Therefore, standard quality metrics on test failures as well as production bugs and their severity are also important to agile teams.

This practice is all about the data, which is something BI teams can really get behind! Agile teams should build data collection into their processes so they can understand how often a problem happens, how long it takes to resolve it, and how much of an impact it has on the flow of value to customers.

Read Mistake #8: Not Including Process Improvements in the Team’s Work Backlog

This content originally appeared in TDWI. TDWI members can see the original here.

With so many teams “going agile,” it’s important for your BI team to keep a few things in mind that will help your agile transformation go more smoothly. This series, “10 Mistakes to Avoid In an Agile BI Transformation”, will show you how to prevent the most common pitfalls I’ve encountered in my experience as an Agile Coach.

When we run more than one project at a time, our customers experience long delays between when they request a project and when they get the value of it. Somehow, though, it’s common for BI leaders to think the way to keep customers happy is to start each project as soon as possible. Sure, it feels good to tell an executive sponsor, “We’ll get right on that!” However, does that good feeling last through months of status reports and business frustration? Sure, it feels good to tell all five executive sponsors their projects have started, but how does it feel when each consistently pressures the BI team to make his or her project the top priority?

The benefit of a team working one, and only one, project to completion before taking up the next project is not only a reduction in task switching (as mentioned in the previous post) but also a reduction in project lead time. Lead time represents the customer’s experience between when they request a project and when they receive the finished value. With a reduction in task switching and waste, each project completes sooner.

For example, let’s say you have four projects to deliver in a year, and based on your traditional estimates you believe the team can complete all four this year if they run in parallel. Three of the projects are expected to go live by the end of Q3, and the fourth will deliver by the end of the year. Rather than starting them all at once, why not start the highest priority project and complete it in Q1, thereby delivering its value much sooner. Move on to the second priority and deliver that in Q2, a quarter early. Then tackle the third project in Q3 and finish with the fourth project in Q4—both right on time. If you believe you can complete all four in parallel, and you understand that task switching reduces effectiveness, then logically, working projects one at a time will reduce risk and deliver many of the projects sooner than the parallel approach.

Read Mistake #7: Ignoring Agile Feedback Loops

This content originally appeared in TDWI. TDWI members can see the original here.

With so many teams “going agile,” it’s important for your BI team to keep a few things in mind that will help your agile transformation go more smoothly. This series, “10 Mistakes to Avoid In an Agile BI Transformation”, will show you how to prevent the most common pitfalls I’ve encountered in my experience as an Agile Coach.

Asking skilled individuals to work on multiple projects at the same time leads to waste in the form of task switching. In order to fully utilize our employees, we often put them on numerous projects. However, according to the American Psychological Association, when we move from one project to the next, called task switching, we lose up to 40 percent of our effectiveness in delivering value. That means if your employee is on two projects, he may be only 60 percent as effective as he would be on one. Another employee on three projects could be even worse off. An employee can report she’s busy 100 percent of the time, but if she’s only 20 percent as effective as she could be, she isn’t contributing much to organizational goals.

As mentioned above, agile BI managers keep teams together and ask them to focus on a single project until it’s complete.

Another method used by agile teams to reduce task switching is to limit the work in process (WIP) for the team as a whole as well as for each individual. Scrum, a popular agile framework, limits WIP by asking the team to only focus on what they can accomplish in a short time frame, called a sprint. Scrum teams pick a sprint length of one to four weeks and stick with that length sprint after sprint. This allows the team to learn how much work it can actually accomplish in that time. Going forward, the team only pulls into each sprint what the team members can commit to delivering. The time box in scrum effectively limits the team’s WIP for each sprint.

Another effective agile approach for controlling WIP is the lean-derived kanban framework, which identifies a limit on the number of things the team agrees to focus on at any point in time. For example, a kanban team might agree to only focus on three things at a time. One of those might be a long-running effort over many weeks, and the other two could be smaller tasks that, once completed, make “room” for other items to be pulled into WIP. Over the course of several weeks, the kanban team might complete 10 things, one of which took the whole time while the others were shorter in duration and moved through the process more quickly.

All successful agile BI teams I’ve worked with limit WIP in some form or another. Limiting work in process reduces task switching, which in turn increases effectiveness per hour of work.

Read Mistake #6: Thinking Parallel Projects Keep Customers Happy