In 2014, I went to Berlin to attend “Digital Analytics Hub”, probably the best “conference” in our business. DA Hub evolved out of Gary Angel‘s Xchange. You sit in small groups of people with one discussion leader, and you speak about interesting subjects.
Those “discussions” can be anything between good and outstanding, depending on the other people in your group, the discussion leader, and the topic, of course.
In Berlin, I attended a discussion about “agile”, led by Anna Denejnaja. We had interesting people, and a good, seasoned leader. Yet we all came away thinking “hm…” — the topic wasn’t good.
Or, as I think now, we weren’t ready for the topic.
We kept going round the table, trying to define what “agile” meant to each of us. The excercise was frustrating, because whatever we came up with, it had no real connection with our daily business as analysts or consultants.
We were asking the wrong question, I think.
Not agile …
Today, partly influenced by the fact that I am in Basel, and I see how my AEM colleagues run large projects, I think that “our side of the business” is not the best fit for agile methodologies.
We go into new deployments using the good old “talk – think – define – deploy” approach, but mostly, we err on the side of small steps, ad-hoc, chaotic changes.
I’m convinced “agile” would help in the long run, don’t get me wrong, but I really cannot see any of us sitting down and writing stories — “As an analyst, I want to see which products generate the most revenue on my site”. It’s almost faster to log into your tag management system and just track it!
Part of that is because, really, the stories would need to come from the business. But we are guilty, too, if only because we let the business get away with not giving us any.
So are we doomed, always to stay in the dark chaos? Far from the light of agile, the cleansing power of scrum[tm]?
… but “agile-aware”
I know you’re sick of me talking about testing by now, but hear me out on this one:
Testing the interface between the site and our chaotic land is where we already come into contact with agile, even today! The development team (you!) is likely going to be on some form of agile.
This is were and why we need to be aware of what agile is (for you, not for us!), why we need to know how it works.
Just like testing is one way for us to speak the language of our developers, if we want to participate in what you guys do, we need to feel comfortable with your process, swim in it like a dolphin.
We have a much better chance of getting our important requests through, if we know how to play the game!
So if you (the developer) could spend a little bit of time, why not sit down with your friendly marketer and tell her how you work? Show her your sprint planning, discuss it. Find out at which point you need something from her, or she needs something from you.
Make sure she understands what drives you!
TDD
A different aspect, close to my heart, mostly because this is what kicked off my journey down into testing:
I like the idea of test-driven development a lot.
The really big thing about it, especially when we have two teams involved, two different worlds, is that TDD forces everyone to “document” what they are doing. The “documentation” in the form of tests gives us 2 things:
a) a sort of specification for dev to work against
b) the possibility to spot regressions in the future
I’m still dreaming of being able to TDD analytics/target/etc., but there is currently no tool that allows me to do that.
I can, however, TDD the foundation. If my site development team follows a TDD approach, I can give you tests!
And even if you don’t, by giving you tests for the things that I need, I’m essentially using a TDD-like approach, and you can follow. You can work to make my tests pass. Peace of mind for you and for me.
The tests help making things explicit that formerly were implicitly communicated, if at all.
Using “sort-of TDD” like this is a good way to dive into “agile” right now. My hope is that we do that, and that the next discussion on the subject will be more productive!
Providing tests to site development is likely our best shot at fitting in with the cool, agile crowd.
Web Analytics for Developers 
Hi Jan
I think this is a poor excuse!
If you only have one simple Business Requirement with a simple Implementation, I agree, it might be faster to just implement it. But in the other cases, and as soon as you have more than one task, it is very important to write the story down and it is also important to write it down with all the details required.
If you have a project, with 20 Business Requirements, it makes sense to write them all as a story (also the very simple ones!) before you begin to implement, because there might be some dependencies between the different stories. Also, you need to be sure, what is expected by the business (development and business should talk about the same thing!), because otherwise, you work on the same task more than once, that’s not efficient.
Agile forces you to write the story down and to think about the story before you begin doing anything. But also the detail level is important, here is why:
Writing:
“As a buyer, I want to see the 10 most successful products in my company in June”
is a big difference to:
“As a buyer, I want to see the 10 most successful products in my company in June, to identify my Key products. Successful in this case means, a product has more than x product Views, more than y Units sold and more Revenue (Gross Sales) than 80% of the products. Sort the result list by Revenue, then Units and then product Views.”
Cheers
Marisa
LikeLike