Showing posts from April, 2017

Strategyzer webinar learnings: Designing experiments that matter

Strategyzer put on a free webinar to discuss how to design business experiments that matter, with David Bland & Alex Osterwalder providing the discussion.  I stumbled on these guys after being recommended the book 'Business Model Generation' (, and subsequently reading the follow-up book 'Value Proposition Design' ( my present CTO is encouraging VPD practices ) - plus using many of their resources. (Will add a link to the recording here when it arrives...) Big lessons When companies start seeing failure as success, culture is moving. e.g. I am so glad we learned there was nothing in this idea; we saved millions of investment dollars The ramifications of incentivizing output instead of outcome Current software development methods reward output (deliver by a certain date, deliver a feature or product) instead of rewarding the outcome This leads to focusing on building instead of learning Learn / Build / Measure loop Sta

Rambletron - Patterns for software development orgs?

Lessons I have learned so far; the naivete of youth allows me to write this down...the wisdom of hindsight allows future me to laugh.  :) Building portfolio vs. delivering value This is first because it's ultimately the most important, and hardest, part to get right. Suspect that things like this are part of it: Business Model Generation/Value Proposition Design concepts being applied i.e. think hard  about what you are doing and why Continuous improvement as a cultural centerpiece Senior leadership defines the big picture, explicitly calling out continuous improvement as a necessary fact of life is key Teaching all levels to apply BMG/VPD concepts to projects Really just the act of thinking about something vs. just doing it because you're sure it's the best idea I cannot comment on how you actually solve/execute on this, but I feel very strongly that this is core to sustainable success & innovation. Systems thinking Books like 'Thinking in Sys

So what would you say you do here? Release management?

I recently was asked to give a presentation on 'release' - audience: entire company.  Putting that together gave me much time to ruminate on 'what value are you delivering?'. Note:  I'm writing this as a mental exercise; working on clarifying my purpose.  Much of this is naive (and rambling) philosophy. While part of the operations department, I have been unofficially tasked with 'release management' for our dev/qa teams.  What 'release management' constitutes, I would posit, depends on your perspective of 'people, process, tools'.  Personally I fall under the 'people, process, tools - in that order' camp, so a good chunk of my focus has been on helping teams 'level up'.  Delivering value to customers (vs. products/features) and product ownership are also high on my priority list. Fundamentals Help teams grow by addressing/highlighting risk gaps (e.g. missing non-functional requirements) Help teams understand by facil

Mobile performance testing using Jmeter & Terraform - getting started

Everyone has performance and scalability on their minds these days, so I am working on a project to bring more visibility to our bottlenecks.  The project will center around simple 'user scenarios': We send a huge batch of push notifications, and a subset of users will open the app.  That simple action actually does a bunch of stuff, like authentication, refreshing feeds, and so on. We make a change that dumps auth, and every user has to log in fresh. We add an endpoint as part of a marketing effort ( say, a news page ), and a push notification lets users know this new thing is a thing.  The endpoint gets 100k hits in 5m.  Does it survive? In all these scenarios you are dealing with read-only traffic, and nothing super fancy to put together. Nobody here really knows much about performance testing ( aside from previous experiences discovering that mass effort was not worth it, which I agree with ), so I wanted to make a point of not turning this into a behemoth.  Wha