John Cutler sent out a tweet late lat week with the idea to get some people to write in some responses to some ideas he had for a post. If you are not sure who this is, and you are a product/team/dev nerd, you are in for a treat. He writes on Medium and has some interesting ideas that you will enjoy learning about, check him out. This is simply a place to stash the text, for now, in case I need to edit something — this will primarily live in the thread on Twitter. A fun learning experiment on my part.
Disclaimer: There were some assumptions made, future edits are subject to clarification 🙂
Let’s crowdsource a post. I’ll curate. Tips for a developer writing Epics/Stories for initial validation of new arch? #agile #devops #design pic.twitter.com/ObHQCcyyd2
— John Cutler (@johncutlefish) July 14, 2017
How formal?
Formality could be driven off audience and should be driven off outcome. It can start on the back of a napkin for a few people trying to solve something, but should be formalized to increase shared understanding as much as possible for the ultimate intended audience.
How do I frame big experiments?
Framing experiments should be relatively straightforward; start with a hypothesis, 10x some potential solutions, triage those to top 3–5, list steps for each, note any overlaps, then execute and document while tracking where improvements can be made.
Start with a smaller sample size for both speed and work the kinks out as you move forward. Map those overlaps that have improvements to the next experiment so you are not reinventing the wheel. Once error corrections feel mitigated open experiment at a larger scale while always checking against the hypothesis.
Attack big risks first or breadth?
There might be good arguments for one over the other but by solving the big ones first, you could be giving life to the wider, smaller more manageable risks (which is good, other wise the whole product could be in jeopardy).
Big risks could scuttle your endeavors much sooner so ensure you have solutions for those first.
How big?
As big as you can manage, or as much value you can provide, if successful. Be cautious of clustering big risks into something unapproachable.
When is a spike not a spike?
Spikes are used to validate that the team and product are on the right track and they can become less useful if too much effort goes towards looking for answers and it gets overly complicated. Spikes should be used as anchors and if they are not “singular and pointed” their efficacy can be depleted.
They should be quick, so if they go on for too long it becomes some deeper definition of research and would probably not be considered a spike.
Do arch diagrams matter?
Any tool that is used to convey, teach, and explain relationships. Learning can be done in a number of different ways and diagrams are just as important as anything else.
How do I build support from team?
In most cases, support comes from trust. Building and maintaining trust is key and while it takes consistency, should come pretty easy. Be genuinely transparent, do what you say you will do and admit when you are wrong. The social transactions of credit and recognition are important even when not obviously large. Managing teams when you have responsibility but no authority can be a challenge when its time to lead but if you have a foundation of trust, those higher gears can come pretty readily.
How do I handle push for convergence?
Teams that work separately but will end up in production together at the end need to be plugged in together on a regular basis. There needs to be a lot of transparency and shared understanding so that both are represented well and not a hindrance to the other. This is complicated but if done well, can be a game changer. That push needs to make sense and be thoroughly validated though.
*- Originally referenced as: “Tips For a Developer Writing Stories For Initial Validation of New Arch?”
Seems pretty simple, surprised it hasn’t popped up sooner and I suspect this will get scooped up into the core of mobile 
