Just curious...

ivy29gm

I am wondering what you all do, before you start designing a COMPLEX workflow/macro/app in Alteryx. Do you:

a. Just open Alteryx and get going

b. You gather requirements first

c. Blackboard / sketch a high level flow before you open Alteryx?

c. Visio?

d. PM software?

e. Agile dev?

f. other?

Common Use Cases

Accepted answers

PaulT

I thought I would weigh in here as well, because I agree with Mark, this is an excellent question!

I agree largely with Mark, so this post may end up broadly mirroring what he said. The key for me is getting as much of an understanding of the process that needs to be built up front. In essence, building out the Scope of Work (SOW for those consulting buffs out there), and mentally building out a rough framework of steps that I would need to get from the current state to the desired state.

Depending on the complexity of the project, I will often hand sketch out my workflow. Literally drawing out the tools and steps I think I will need to get to my desired state. However, after working in Alteryx for as long as I have, and worked with as many workflows of other people's design as I have, I have developed something of an "Alteryx Whisperer" sense. What I mean is that I can generally look at a workflow and within a few moments tell what it is doing, and where possible pain points are. Conversely, I am able to take on many basic to intermediate builds mentally without needing the sketch phase. Just like learning a musical instrument, Alteryx becomes both easier and yet more complex the more you work with it and learn more about how deep its (and your) technical capabilities are.

I completely agree with Mark that when developing, especially when the requiremnts aren't completely clear, or the desired state hasn't been completely defined, working in sprints and closely coordinating with the stakeholders is a great practice. It's easy to go down the rabbit hole of development and start to veer away from the desired state. Sticking close to stakeholders is the best way to keep yourself on course.

I also tend to go back and revise processes periodically to weed out any bad habits I may have gotten over, or otherwise streamline existing processes. I find that this tinkering helps keep my skills sharp. Through this I have learned a lot about making my workflows more dynamic and simple, while still accomplishing a reasonably complex task.

Anyway, I thought I'd throw in my perspective. Cheers, and happy developing!

Paul

All comments

MarqueeCrew

What an EXCELLENT question!

Ready! --- FIRE! --- Aim.

The easy part of the answer is to build a workflow before converting it to a macro or an app. If it looks like it's going to be a macro calling another macro, I'll likely build some very limited functioning workflows and prototype nominal data flowing through the modules before I add any complexity to the work. I'd build a K.I.S.S. (keep it simple) prototype before diving into complexity.

I like to understand the need and value of the workflow first and don't always need requirements to do that. What features are needed (agile methodology) to deliver value comes first. After understanding the concept I like to start at the beginning of the process and understand the data being accessed. The building of the workflow is usually very linear. In that way, yes I will gather minimum requirements first, sketch (mental or physical) a flow and go forward. I work in small sprints within an agile framework. It is important (if requirements are not fully vetted) to have reviews with your product sponsor at the end of each sprint. Some of the complexities you'll know up-front, some will appear as you code, and some will appear as testers find your 'bugs'. Some of the complexity will disappear as your knowledge grows and you realize that the complexity is quickly solved with Alteryx.

I try to simplify the complex by breaking it down to logical components. If you can use peer-programming techniques and walk others through your design/code this will force you to simplify your workflow. My mentor would ask me to explain the process as though I was talking to my Mom. Granted, my Mom would likely be yawning throughout the explanation but it would help me to make sure that the modules could be maintained by others in the future.

When I look at other people's workflows I try to resist having them do it "my way", but rather look to understand their approach to the problem. Problem one is to get the right result. Once you achieve that, you can always improve on the performance and the simplicity of the solution. Don't worry about having the elegant solution to the complex problem in your first iteration. Looking back at work I did months ago, I'll scratch my head wondering why I ever approached the problem that way. The bottom line is to set aside time to improve performance and to simplify the workflow in a later phase.

In summary, get enough of an understanding to start the work. Where you need help for the complexity look for help online or through resources like this community. Open up Alteryx and build a simple prototype. Share your findings and where you see the complexity see if someone else might have a different approach to assist you. Avoid waiting to know everything. The people writing the requirements will only write what they know to be the requirements. Once you're involved and looking at the data, you'll be asking some very intelligent questions. For project management, do estimate the effort in small units of work and measure yourself (better or worse) against the estimates. Ask for help when you need it. Do your best work and keep your commitments. Agile frameworks value people over processes and working products over documentation.

Leverage your insight into asking a question like this by applying that consciensousness into your work and I'm certain that you'll be delivering value.

Much thanks for the question. I hope that this helps.

Mark

ivy29gm

Hi Mark,

Some good feedback - I appreciate it!

PaulT

I thought I would weigh in here as well, because I agree with Mark, this is an excellent question!

Anyway, I thought I'd throw in my perspective. Cheers, and happy developing!

Paul

mbarone

First I get a business understanding of what the goal is. In my company, this could mean a half-dozen meetings over the course of two weeks or more with anywhere from a few people to a dozen or more.

Once I have a basic understanding of what's needed, I write down (pencil/paper) a rough sketch of the "base" data needed and were it comes from. Then I sketch out how to blend all the base data and write down thoughts on how to blend it to get the needed output.

Once I have that down, I open a blank canvas and go from there. Although most often, I have done something similar in the past, so I take an already existing module, save it as a a new module, and adjust it from there.

ivy29gm

Hi Paul,

Great feedback and I couldn't agree with you more. It's helpful knowing we have similar approaches with slightly different nuances.

I especially like your last paragraph - I go back and make revisions as well because I'm always looking for speed & efficiency while maintaining accuracy.

How do you handle scope creep in a Sprint setting, esp when the stakeholders didn't have clear requirements to begin with or req's changed significantly?

Thanks!

Quick Links

This months top contributors

atcodedog05 19458

Qiu 15866

binu_acs 15708

MarqueeCrew 13708

apathetichell 13703