Lynn Winterboer

Always learning; always growing

Video: Test Automation Agile Enablement for DW/BI Teams

by

Testing drives Agile analytics. It’s so important that I taught a full-day class on this topic for several years, and still frequently present on this topic. Since every small increment of code needs to be potentially shippable, it must be tested. With testing on such a frequent basis, it becomes imperative to automate testing.

In this video, I answer the following questions:

  • Why is test automation important for Agile data teams?
  • Why aren’t all data teams aren’t automating their tests today?
  • What is the path to test automation?
  • What does simple DW test automation look like?

This video is from a presentation to SQL Saturday in Colorado Springs. Don’t forget to share your thoughts in the comments.

The Value of an Agile Coach – Or Football Coach

by

I’d like to share a piece written Wendy Avery. Wendy is a SAFe Enterprise Agile Coach, Engagement Manager, and instructor with 20 years of IT Project Management experience in the Healthcare insurance industry. In spite of her being a Patriots fan, I liked her post so much that I asked if I could share it with my readers!

As I sit here today, three days from Super Bowl LIII, I’m thinking of two things.  First, will the Patriots win the Super Bowl this year? And second, why do companies not understand the value of an agile coach?

It made me think about the Patriot’s coach, Bill Belichick, and his job as coach to, arguably, one of the best all-time football teams.  In comparison, an Agile coach for an organization that is shifting its culture.  What are the parallels?  What are the differences?   Why do we call both of them a “coach”?

Bill Belichick doesn’t actually play football.  He’s not on the field, catching passes or blocking the opponent.  But, he’s considered the foremost guide on how the team actually should play on the field. Why?  Is it because he used to play football? Well, he actually did play football, during high school and college, but not professionally.  He just “gets it”, and is able to articulate that into guiding principles that the team can use to win games. 

He doesn’t tell the team what to do, he works with them on plays and strategies, and acknowledges that once they’re on the field, they’re going to have to think for themselves when things go sideways.  He helps them remember the goals, strategies and principles of football so that they can use them as needed in those situations.

How difficult would it be to coach that team if he was also a player?  Why can’t the quarterback, who is the leader/coach during the play do both? I bet none of the NFL would ever consider that. 

Let’s consider the agile coach in the same light.  She’s not on the team.  She doesn’t necessarily know how to code but she’s probably pretty familiar with the strategies that agile teams need to adopt to make their job work better.  She “gets it” and is able to articulate that into guiding principles that the team can use to be successful. 

She doesn’t tell the team what to do, she works with them on strategies and acknowledges that once they’re working, they’re going to have to think for themselves when things go sideways.  She helps them remember the goals, strategies and principles so that they can use them as needed in those situations.

How difficult would it be to coach that team if she was also a coder and busy working instead of seeing the whole of the team and how they work together?  Why can’t the scrum master, who is the leader/coach during the day to day operations of the team do both? 

Hmm.  I just realized that I repeated those two paragraphs, just about word for word, except for the type of coach.

I bet if we were to ask the NFL to quantify the value of their coaches in ROI and dollars, they’d be hard pressed to actually say how much BETTER the team is in comparison to if they had no coach at all.  They’d just say it’s impossible to NOT have a coach, let alone employ one just for the beginning of the season.  Early in the season, the Patriots were only winning 50% of the time.  If you were to measure Belichick’s value 4 games into the season, Robert Kraft would certainly be justified in firing him.  Who wants a coach with a 50% win-loss ratio? They would have fired possibly the coach of the next Super Bowl LIII Champions! (Or at least the second best depending on this weekend’s outcome).

All I know is that if Belichick were pulled from the Patriots right now, three days before the Super Bowl, the Patriots would lose.  So why would you stop paying for agile coaches while your teams are working toward achieving the goals of your organization? Do you still expect to win?  I wouldn’t bet on that game.

Agile Transformation Mistake #10: Expecting Change to Be Smooth

by

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.

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

by

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

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

by

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

Agile Transformation Mistake #7: Ignoring Agile Feedback Loops

by

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