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

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 in the data industry have been trained and staffed for years based on specific skill sets that support specific steps in a waterfall-based approach to delivering projects. For example, it’s not uncommon for an ETL developer who uses Informatica to always work on project tasks that only require Informatica development and never work on anything else. A data modeler might only ever work on data model development and enhancement using a specialized tool such as eRwin. Our traditional project management approach was to staff these individuals on multiple projects at the same time so the person is “100 percent utilized.”

However, remember that a top agile priority should be early and continuous delivery of valuable BI results. In order to achieve this, agile BI teams must be willing to value delivery (speed and quality) over “utilization.” The fastest way to deliver a piece of value is to ensure all skills and minds needed at any step in the delivery process are available and ready to contribute without delay.

To keep a small team 100 percent dedicated to moving a single project forward, most agile teams will focus on developing multiple skills that each person can use beyond her or his primary area of expertise. When an ETL developer also has skills in analysis and testing, there will be little time when that person’s skills aren’t needed.

One thing that’s different between working on various tasks within a single project and working on one type of complex task across multiple projects is the latter can incur serious productivity costs. Imagine you have a primary skill in ETL development, and you’ve also been involved with the analysis leading to what needs to be developed in the ETL. Within that analysis you and your team develop testing goals and test cases that describe the behavior of the resulting BI feature. It’s not a hard switch to move from analyst and test planner to developer; you already know the topic well. Compare that to the effort it takes to be fully engaged in ETL development in Project A and then have to stop that and fix a bug found on Project B. As you will see in the next mistake, that big switch can be expensive in terms of effective productivity.

Read Mistake #5: Task Switching

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.

Scrum, one popular agile framework, defines a neat role, the product owner, who represents the customers. The product owner is responsible for identifying and prioritizing the BI features the organization needs most and must be available daily to support the team by answering questions and providing feedback on results. BI teams think this sounds great! However, many BI teams ask a BI analyst to fill this role because it most closely aligns with the work he or she has been doing all along.

There are two common problems with this. First, a BI analyst usually does not have sufficient authority to prioritize the BI team’s work (i.e., authority from the customers to decide whose request is delivered first). Second, when the BI team supports many areas of the organization (as is common with data-focused teams), a single BI analyst may not have the knowledge or bandwidth to properly represent each of those areas in detail.

You can avoid this mistake by focusing on product ownership as a need to be met, not a role to fill with a single individual. Ask your customers to tell you how they will prioritize BI work and how they will communicate the priorities to your team. You may need to help them devise a process for this, but make sure you are facilitating the creation of an approach they will own—not something they have to comply with. From there, strong BI analysts can support the various areas of the organization by providing the delivery team with sufficient information to get started working on the top
priority items.

Read Mistake #4: Retaining Skill-Based Silos and Multi-Project Staffing