You may have noticed (as if anyone is actually reading this) that I've not posted in some time. No, I don't even have a bad excuse, although if you give me a bit I'll come up with something really good, involving pirates and ninjas.
So where have I been? To quote one of my favorite fictional characters, Martin Blank: "I guess you could say I went west. You know, the way of Horatio Alger, Davey Crockett, the Donner Party...".
If you must know, I've been working. I had an opportunity to join a small start-up style team working within a publicly traded company, which I jumped at the chance because it gave me a chance to further test out theories of how to successfully (and unsuccessfully) operate an innovation team within an established organization.
And it has been an excellent learning experience, but as all good things must end it was time for me to move on to a different challenge. I'll be writing more on this experience in future postings but the one thing I did want to highlight first was the deep sense of camaraderie that developed within our team and the business unit we were tasked with supporting by any means necessary.
I saw firsthand what having courage and a selfless lack of ego can do for bringing together a team that had deep experience aligning it's work with known business value.
I also saw firsthand how an attitude of "By any means necessary" coupled with a strong commitment to the team could bootstrap a business unit from nothing to a strategic centerpiece of the growth strategy of a publicly traded company.
The successes of this team I have had the privilege to work with cannot be found in any book or training class - it was the people that made the difference. They certainly made a difference to me. In future postings I'll discuss in greater detail what I saw from these people and how it made the team work, but for now I'm simply going to say that I will miss working with them and thank them for an excellent opportunity to learn and be successful.
Vaya con dios, Saskia and Dwayne. I truly enjoyed working with you.
Thursday, September 8, 2016
Thursday, February 6, 2014
Software Anti-craftsmanship
Today was the February installment of the Salt Lake Agile Roundtable (#slagile). Originally founded by Alistair Cockburn way back in the mists of time, it persist to this day as a place for some of the best conversations surrounding Agile that you can find anywhere.
If you've never been I'd highly recommend taking in at least one of the meetings. In past meetings there has been all sorts of interesting shenanigans, everything from the obliteration of hopeful doctoral dissertations to actual coloring sessions with crayons and everything (no, I'm not making that last one up - you had to be there)
One of the key elements of the meeting structure is that everyone is asked to bring a topic for discussion. Ideally it will be related to a challenge you are facing but with some of us old timers who've heard just about every kind of problem with software teams you can come up with we have a tendency to introduce topics that will provoke (hopefully) interesting discussions.
Or at least interesting arguments.
My topic today was inspired by a comment someone had made in a previous topic. What they said was "Well, yes, but a craftsman (software) would never do that". Waving an absolute like that in front of us has roughly the same effect that catnip does on cats, so of course I had to find out from the group exactly what they thought software craftsman ship was.
Thus I asked the question: "Exactly what does it mean to be a software craftsman? How can you detect the spoor of such an elusive beast?"
OK. Maybe I didn't use the term "spoor", but I should have. Would have given me a good excuse to break out a pith helmet in the middle of the meeting.
Of course it wouldn't be the Salt Lake Agile Roundtable if there wasn't a twist to the conversation. The twist of the day was provided by David Adsit (@davidadsit) of Pluralsight. David decided to take the contrarian view and present his list of really annoying things that those craftsmanship jerks do.
Without further ado, I give you David's list of "Software Anti-craftsmanship" qualities:
1. Wastes far too much time navel gazing
2. Pointlessly delays the deliver of "good enough" code
2. Pointlessly delays the deliver of "good enough" code
3. Constanty renaming everything! Always with the renaming!
4. Fritters away valuable time changing existing code rather than working on new code
5. Treats the rest of us like second-class programmers
6. Constantly taking off for yet more useless training. Don't even get me started about all of these "Retreats"!
7. Imposes their philosophy about why the way they work is better without ever offering any actual evidence.
You know, I think we might have the beginnings of a manifesto on our hands here...
Thursday, January 30, 2014
An agile legacy. Or should that be "An Agile legacy"?
A couple of years ago at Agile Roots I was part of a panel discussion titled "There Is Only Us". The gist of the conversation is whether agile had reached the point where it was considered a best practice for the software industry.
As best I could tell, our consensus answer to that question was "Purple".
There's no question that awareness of this thing called "agile" has permeated the software industry. But the principles behind it? The point of it all? I'm not so sure.
According to a highly scientific survey of a few web sites I decided to google based on my own biases I can prove conclusively that the most common conversation about agile is "Why it didn't work for us".
But this entry is not about agile teen angst. It's about legacy - what we influence, what we pass on.
For many years I taught martial arts as a personal passion. Even tried to make it my career a couple of times. If you're wondering how successful I was just note the fact that I blog about the software industry and not the martial arts industry.
But the one thing I did do well was teach. And the interesting thing I learned about teaching is that sometimes you influence people's lives for the better. Seeing those changes in the lives of my students fed my soul enough to motivate me to keep teaching for over 20 years.
Sorry, was waxing nostalgic for a moment there. No, that's not the legacy I'm writing about.
Last night I was chatting with Daniel Spangler - a long-time friend and co-worker. Daniel is the kind of rock star developer that you build development teams around. I know this because I've done just that multiple times.
Unfortunately our last project terminated rather abruptly, so Daniel moved on to a new position that included...
(insert screeching horror sound track here)
Management responsibilities!
O, the horror of it all!
As luck would have it, the company he joined was just in the initial stages of rolling out Scrum through their development teams. Daniel, still reeling from the shock of becoming management, decided that I'd be a good person to talk to about this whole agile thing. Of course him coming to me for advice was all the evidence I needed that he was still in shock.
Daniel: "So we're doing Scrum, and I don't know anything about it".
Me: (insert spit-take here) "Daniel, you've been practicing agile for years! What do you mean?!?"
Daniel: "Yeah, I know we've been doing it, but I don't know what all this stuff is called."
What's tragic about this is that there's a large contingent of the "Agile" (yes, I used the big "A" intentionally) community that would agree with Daniel's sentiment that he doesn't know "Agile", let alone Scrum. Daniel isn't the only one. I've visited many teams in the guise of an agile mentor. Invariably they would disclaim that they didn't know (or care about the names) of whatever flavor of agile you'd care to name but were shining examples of how agile teams really work.
Once I had wiped the water off of my keyboard Daniel and I got to work translating Scrum terminology into practices we'd been using for years. Then we stepped back and reviewed the principles behind those practices so he'd have a good basis of why Scrum does what it does, and why we diverged in various situations in the past.
The payoff came in the form of a short conversation we had last night:
Daniel: "So I agree that focus is a key element of agile" (referring to our discussion that iterations provide a framework for the team to limit their focus to the work at hand)
Me: "Tell me more"
Daniel: "After drilling the team hard on better story definition at the beginning of the iteration we are seeing better velocity across multiple projects. Team members aren't wallowing around as much on what they should be working on" (their team works on multiple projects simultaneously)
Me: "So is this a focus success story or iteration definition success story?"
Daniel: "Both, but ultimately it is about better focus. More concise stories translates into less interruptions during the iteration. Less interruptions equals more work being done. We're catching up on several chronically late projects"
Me: "Woohoo!"
Of course this conversation begs the question of "Why don't we see this sort of success happening more often when teams shift to various agile methodologies?"
Wait, I know the answer to this!
Experience.
Daniel, who has at least 10 years of experience working with teams practicing different flavors of agile (Scrum, Crystal, XP) can tell immediately when something isn't right, even if he isn't always using using the right names for the dogma.
Contrast that with how agile adoptions typically work - companies hire external experts to provide training and mentoring, but don't invest in installing persistent expertise at the team level where the rubber hits the road. Is it any wonder why we see "We tried Agile but it didn't work for us" so often?
My hat is off to Daniel. Thanks to him, I have a new element of professional legacy that I can point to and admire.
Oh, and I guess I'll have to claim one less "Agile didn't work for us" story too.
Thursday, January 23, 2014
Startup Weekend Anthropology 101
Let's kick things off with a quote:
"I chose cultural anthropology, since it offered the greatest opportunity to write high-minded balderdash" - Kurt Vonnegut
Last month I attended an event up in Ogden called "Startup Weekend". I had heard various things about Startup Weekend through word-of-mouth channels but until this event I had not directly participated in one of these events. Thanks to one of my Agile colleagues Maile Keone and local event organizer Alex Lawrence not only did I have a ticket to the event, but also very nice accommodations next to where the event was hosted.
I didn't walk into the event planning on becoming a Startup Weekend anthropologist, but I certainly walked out as one. Over the next few blog entries I'll be rambling on about what I learned over the course of one weekend in Ogden.
Being a Startup Weekend virgin, I wanted to preserve my opportunity to learn about the event organically so I made the decision to minimize my event pre-res... *snort*
Sorry, couldn't get through that sentence with a straight face. Let's try this instead:
Being a Startup Weekend virgin I did the absolute minimum amount of work necessary to not look like a completely clueless buffoon when I showed up. Or at least I thought I did.
When you look at the outward packaging of Startup Weekend you see the following:
Startup Weekends are weekend-long, hands-on experiences where entrepreneurs and aspiring entrepreneurs can find out if startup ideas are viable.
Reading the above I made two assumptions. One was that a significant number of attendees brought in their business ideas and that there was a significant percentage of startups that launched as a result of Startup Weekend events.
It's a good thing I do clueless buffoon well. I was wrong on both assumptions.
But I'm getting ahead of myself. One of my goals for the event was to engage not as a technical resource but as a business resource - I'd bring in an idea, I'd pitch it, hopefully gather a team and see what happened. I also decided I was going to hack the idea pitch at the beginning of the event by not promoting how cool the business concept was but instead to promote how the team engaged with me would get a better event experience by delivering not one MVP by the end of the weekend - we'd deliver at least 4 or 5.
This great idea of mine lasted maybe 15 minutes into the introductory presentation. What killed it was the admonishment of the event coordinator that you should not pitch your pre-conceived business ideas but instead pitch the problems you are interested in solving that others would also be interested in solving.
It seems I wasn't alone in my mistaken assumptions. There were a number of other first-time attendees I talked to that had made the same assumption. It was interesting to see how many persisted in pitching their concept even after the suggestion to focus on an interesting problem. For the record, I trashed by carefully crafted pitch (after hours of rehearsals and timing practices) and pitched the underlying problem to see what sort of interest it would generate.
None, as it turns out.
But the story doesn't end there. As a matter of fact, that's where the real story begins.
After having my grandiose idea completely ignored I started looking at other ideas that I could jump into and work on. One in particular caught my eye. The idea centered around building some sort of a mobile device multi-player game. This idea was pitched by a 17 year old that had attended 3 prior Startup Weekend events. It wasn't the idea that I found interesting - it was who was pitching it. Honestly - how many 17 year olds do you know that show up at an event like this?
So I wandered over and introduced myself, intending to provide expertise as a business and process expert. I didn't even get to the part where I explained what I was good at before he had handed me an assignment.
It wasn't the assignment that made me walk away from this project. From his perspective I am sure he thought it was the right thing to be doing. But it was clear from that one interaction that I'd have to do a lot more work from a "managing" perspective to get things moving toward a successful presentation at the end of the weekend. And that realization made me question whether it was a good idea for me to be walking into any team there and imposing my experience on them.
I know, the hubris is just dripping from that last paragraph, isn't it? Let's set aside for the moment any discussion of the "value" of my skill set and just focus on personality. My personality is such that I gravitate towards leadership of any group I'm involved in. For better or worse it is how I operate. But I realized in that moment that managing a team to deliver isn't something I really needed or wanted to experience at this event. What I really wanted to experience was how these ad-hoc teams fared over the course of the weekend.
And was I ever glad I did. In that moment I became the Startup Weekend incarnation of Margaret Mead.
Stay tuned for Startup Weekend Anthropology 102: The highest of highs, the lowest of lows
"I chose cultural anthropology, since it offered the greatest opportunity to write high-minded balderdash" - Kurt Vonnegut
Last month I attended an event up in Ogden called "Startup Weekend". I had heard various things about Startup Weekend through word-of-mouth channels but until this event I had not directly participated in one of these events. Thanks to one of my Agile colleagues Maile Keone and local event organizer Alex Lawrence not only did I have a ticket to the event, but also very nice accommodations next to where the event was hosted.
I didn't walk into the event planning on becoming a Startup Weekend anthropologist, but I certainly walked out as one. Over the next few blog entries I'll be rambling on about what I learned over the course of one weekend in Ogden.
Being a Startup Weekend virgin, I wanted to preserve my opportunity to learn about the event organically so I made the decision to minimize my event pre-res... *snort*
Sorry, couldn't get through that sentence with a straight face. Let's try this instead:
Being a Startup Weekend virgin I did the absolute minimum amount of work necessary to not look like a completely clueless buffoon when I showed up. Or at least I thought I did.
When you look at the outward packaging of Startup Weekend you see the following:
Startup Weekends are weekend-long, hands-on experiences where entrepreneurs and aspiring entrepreneurs can find out if startup ideas are viable.
Reading the above I made two assumptions. One was that a significant number of attendees brought in their business ideas and that there was a significant percentage of startups that launched as a result of Startup Weekend events.
It's a good thing I do clueless buffoon well. I was wrong on both assumptions.
But I'm getting ahead of myself. One of my goals for the event was to engage not as a technical resource but as a business resource - I'd bring in an idea, I'd pitch it, hopefully gather a team and see what happened. I also decided I was going to hack the idea pitch at the beginning of the event by not promoting how cool the business concept was but instead to promote how the team engaged with me would get a better event experience by delivering not one MVP by the end of the weekend - we'd deliver at least 4 or 5.
This great idea of mine lasted maybe 15 minutes into the introductory presentation. What killed it was the admonishment of the event coordinator that you should not pitch your pre-conceived business ideas but instead pitch the problems you are interested in solving that others would also be interested in solving.
It seems I wasn't alone in my mistaken assumptions. There were a number of other first-time attendees I talked to that had made the same assumption. It was interesting to see how many persisted in pitching their concept even after the suggestion to focus on an interesting problem. For the record, I trashed by carefully crafted pitch (after hours of rehearsals and timing practices) and pitched the underlying problem to see what sort of interest it would generate.
None, as it turns out.
But the story doesn't end there. As a matter of fact, that's where the real story begins.
After having my grandiose idea completely ignored I started looking at other ideas that I could jump into and work on. One in particular caught my eye. The idea centered around building some sort of a mobile device multi-player game. This idea was pitched by a 17 year old that had attended 3 prior Startup Weekend events. It wasn't the idea that I found interesting - it was who was pitching it. Honestly - how many 17 year olds do you know that show up at an event like this?
So I wandered over and introduced myself, intending to provide expertise as a business and process expert. I didn't even get to the part where I explained what I was good at before he had handed me an assignment.
It wasn't the assignment that made me walk away from this project. From his perspective I am sure he thought it was the right thing to be doing. But it was clear from that one interaction that I'd have to do a lot more work from a "managing" perspective to get things moving toward a successful presentation at the end of the weekend. And that realization made me question whether it was a good idea for me to be walking into any team there and imposing my experience on them.
I know, the hubris is just dripping from that last paragraph, isn't it? Let's set aside for the moment any discussion of the "value" of my skill set and just focus on personality. My personality is such that I gravitate towards leadership of any group I'm involved in. For better or worse it is how I operate. But I realized in that moment that managing a team to deliver isn't something I really needed or wanted to experience at this event. What I really wanted to experience was how these ad-hoc teams fared over the course of the weekend.
And was I ever glad I did. In that moment I became the Startup Weekend incarnation of Margaret Mead.
Stay tuned for Startup Weekend Anthropology 102: The highest of highs, the lowest of lows
Tuesday, December 10, 2013
Learning against my will. Oh, and there was this Lean Startup Conference thing...
Sometimes this learning thing isn't all it is cracked up to be.
Take today's example. I found myself down at the Miller Business Innovation Center to watch their local webcast of the Lean Startup Conference happening this week in San Francisco. I was all set to settle in, have a couple epiphanies, and then I'd be able to knock off for the day with a new "I learned something" badge earned.
Wrong.
I put at least some of the blame on Alistair and the Salt Lake Agile Roundtable gang. It was from them that I picked up the habit of a) always be ready to articulate at least one learning moment from any learning event, and b) actually write down your learning moments so they are reinforced at the moment they are strongest.
I knew I was in trouble about 5 minutes after the first session started. It was Kathryn Minshew - "Getting Users Out of Nowhere". Normally I'd coast through topics like this with my mental cruise control on. Not because they were not interesting or relevant. They are. But that's not an area I've often been at a loss for ideas, so I hadn't pursued learning more.
Well, you know the universe loves moments like this. Or at least the universe that I inhabit certainly does. Since I'm a fan of Norse mythology I can picture with amazing clarity Odin sharpening up Gungnir while Thor is off to the side giving Mjolnir a last bit of polish while glaring in my general direction.
Ok. Maybe it wasn't Gotterdamerung. But what did happen was that a part of my brain that doesn't like the mental cruise control slammed on the brakes and said "Hang on! Did you hear that?!?"
In this particular case it was Kathryn's discussion of how to become your own PR machine. Upon hearing that I dutifully recorded the "aha" moment (yes, it's below if you really want to know). With that aha safely recorded I patted myself on the back and prepared to settle back into cruise control.
Never got there. That same part of my brain that slammed me out of cruise control said "What if she said something else interesting before this?". Muttering vague obscenities under my breath I called up my mental playback department to find out if there had been anything else interesting that I had missed the first time through.
And of course there was. The other tidbit was about making it insanely easy for others to engage in word of mouth advertising for you.
After admitting to myself that I had let a learning moment actually slip by there was no chance that I'd be able to descend back into mental cruise control. I was saddled up for the full ride.
And what a ride it was. I recall actually being irritated by the end of the webcast at the audacity of the conference organizers to schedule that many impactful sessions in a row. What ever happened to tossing a few stiffs in there so you could have time to wander over to the mental dressing room to see how well the new ideas fit?
I'm glad to say my irritation was short-lived. Yes, the learning experience had a lot to do with my mood alteration. So did this parting shot from my mental brake-slammer:
"Gee, you're not getting OLD, are you? Only OLD people stop learning"
In case you thought you were going to get out of this blog entry without having to hear me blather on about the actual things I learned (or re-learned), think again.
I will give you this warning. Context counts in learning moments. If you don't have a shared context for the new idea it will not have the same impact. I'll do my best to convey context but I can promise you that whatever I have to say will be no substitute for you to have your own learning experience from these presentations. Hopefully they will be posted publicly at some point so you can if you missed the conference.
What I learned (or re-learned) today from the Lean Startup Conference:
Kathryn Minshew (The Muse) - Acquiring Your First Users Out of Thin Air
Take today's example. I found myself down at the Miller Business Innovation Center to watch their local webcast of the Lean Startup Conference happening this week in San Francisco. I was all set to settle in, have a couple epiphanies, and then I'd be able to knock off for the day with a new "I learned something" badge earned.
Wrong.
I put at least some of the blame on Alistair and the Salt Lake Agile Roundtable gang. It was from them that I picked up the habit of a) always be ready to articulate at least one learning moment from any learning event, and b) actually write down your learning moments so they are reinforced at the moment they are strongest.
I knew I was in trouble about 5 minutes after the first session started. It was Kathryn Minshew - "Getting Users Out of Nowhere". Normally I'd coast through topics like this with my mental cruise control on. Not because they were not interesting or relevant. They are. But that's not an area I've often been at a loss for ideas, so I hadn't pursued learning more.
Well, you know the universe loves moments like this. Or at least the universe that I inhabit certainly does. Since I'm a fan of Norse mythology I can picture with amazing clarity Odin sharpening up Gungnir while Thor is off to the side giving Mjolnir a last bit of polish while glaring in my general direction.
Ok. Maybe it wasn't Gotterdamerung. But what did happen was that a part of my brain that doesn't like the mental cruise control slammed on the brakes and said "Hang on! Did you hear that?!?"
In this particular case it was Kathryn's discussion of how to become your own PR machine. Upon hearing that I dutifully recorded the "aha" moment (yes, it's below if you really want to know). With that aha safely recorded I patted myself on the back and prepared to settle back into cruise control.
Never got there. That same part of my brain that slammed me out of cruise control said "What if she said something else interesting before this?". Muttering vague obscenities under my breath I called up my mental playback department to find out if there had been anything else interesting that I had missed the first time through.
And of course there was. The other tidbit was about making it insanely easy for others to engage in word of mouth advertising for you.
After admitting to myself that I had let a learning moment actually slip by there was no chance that I'd be able to descend back into mental cruise control. I was saddled up for the full ride.
And what a ride it was. I recall actually being irritated by the end of the webcast at the audacity of the conference organizers to schedule that many impactful sessions in a row. What ever happened to tossing a few stiffs in there so you could have time to wander over to the mental dressing room to see how well the new ideas fit?
I'm glad to say my irritation was short-lived. Yes, the learning experience had a lot to do with my mood alteration. So did this parting shot from my mental brake-slammer:
"Gee, you're not getting OLD, are you? Only OLD people stop learning"
In case you thought you were going to get out of this blog entry without having to hear me blather on about the actual things I learned (or re-learned), think again.
I will give you this warning. Context counts in learning moments. If you don't have a shared context for the new idea it will not have the same impact. I'll do my best to convey context but I can promise you that whatever I have to say will be no substitute for you to have your own learning experience from these presentations. Hopefully they will be posted publicly at some point so you can if you missed the conference.
What I learned (or re-learned) today from the Lean Startup Conference:
Kathryn Minshew (The Muse) - Acquiring Your First Users Out of Thin Air
- "Ask for word of mouth from your customers and make it insanely easy to do". It was the insanely easy part that got me thinking.
- "Tell a good, clear, easy-to-report story". When you're working with bloggers / news outlets to get your message out stories are much more effective than data or marketing statements. Those stories should whenever possible relate to current events / trends
- (Regarding her advice to offer to write posts / articles for blogs and news outlets) "Harvard Law Review rejected my offered stories for a year before they accepted one. Persistence matters.
Alexis Ringwald (LearnUp) - How to Build the Product When You're Not the User
- Her team spent 5 months visiting people in unemployment lines learning what the people there needed.
- Having a "Contact Us" button was not enough - they built a way to stay engaged with their users.
- The whole team recently took a field trip to Mendota, CA (39% unemployment) to continue to learn about what was and was not working.
Daina Linton (Fashion Metric) - Work With Customers Before You Write Any Code
- Initial idea (having a fashion expert available to advise when shopping) wasn't what people needed. By using open-ended questioning they learned what was needed for Men was a way to help them find clothes that actually fit.
- By using a Concierge model (human in the loop) as opposed to building applications they were able to go from validating the new idea to confirming a return rate of 0% on shirts sold via their fitting model.
- Their initial product consisted of a web site that offered a better shirt fitting experience. Only call to action was to ask for permission to have a 10 minute phone conversation about what they needed.
Christie George (New Media Ventures) - Funding for Lean Impact
- Applying the principles of "Fail Fast" and "Fail Forward" to social challenges means that real people are failed. Make sure the failure stays where it has positive value.
- Social change takes a long time (interracial marriage as an example). Social startups can accelerate those feedback loops only so much.
- Social funders (charitable organizations) are very risk adverse. Need to find a way to incentivize risk.
- Create a culture where the truth is incentivized (example given was Unreasonable Institute's practice of reporting their investment decision failures).
Ari Gesher (Palantir) - Preparing for Catastrophic Success
- The hard things to deal with are getting real estate and leadership. Both require at least a 6 month horizon. Only the leadership part is interesting (his words in the presentation).
- Want internal leaders? Pick your leaders, then give them a few people to lead immediately. Support them with a forum that they can discuss their challenges and problems. Then let them lead.
- In the midst of growth is no time to build command and control leadership. Leaders need to be communication nodes, facilitating communication for their teams, coordinating with other teams.
- Culture is an emergent property of the people you hire. Thinking "Will this person fit the culture" is not as important as thinking "How will this person enhance the culture"
- Indoctrinate culture from the day people start. Don't leave it up to chance.
- Final thoughts - "If it hurts, you're doing it right"
Steve Blank (Stanford / Berkley / Columbia) - Evidence-based Entrepreneurship
- Steve scared me a bit. His presentation centered around the fact that there are now actionable metrics around startups, which on the surface seems a good thing. But there's no lack of cautionary tales of metrics gone wrong...
- Startups are not smaller versions of companies. They are temporary organizations that exist to find a scalable business model. Only when they find that model can they become "companies"
- His template for a startup is a Business Model Canvas + Customer Development Lab + Agile Engineering and Dev methodology
- His Lean Startup class at Stanford is experiential - you will talk to at least 100 customers during the 10 week course.
- NSF approached him to put together a class for the NSF. That grew into a metric framework to observe the progress of teams
- Having that metric framework allowed Steve to come up with the "Investment Readiness Measurement" - a means of determining what pre-funding stage a startup was in. Modeled off of the NASA Technology Readiness Scale
Nikhil Arora & Alejandro Velez (Back To The Roots) - Using Kickstarter to Run an MVP
- After starting with a "Grow your own mushroom" home kit they decided to bring an aquaponics idea to market - a system where fish waste was used to grow a small herb garden. Turned to Kickstarter to fund it. Had $248,000 in funding within 30 days.
- They learned along the way the cost of rushing to market (faulty pump, unclear packaging). Their lesson learned that it was less expensive to deal with those things before rushing to market, not after.
Keya Dannenbaum (ElectNext) - Learning to Be and Organization that Pivots
- One of the most common statements about entrepreneurship is "Follow Your Passion". It's wrong. She followed this up with data about the effect of emotional "passion" (it burns out) versus dedicated practice. Out of the two, practice is what matters, not passion.
- Their first MVP took 18 months to develop, and it is no longer in use. Their second took 6, and their third took a few weeks. Only the third has proven a repeatable revenue model, and the only "Product" is Google docs and an email address database.
- But those first two products are not failures. They were vital practice for their team to get better at what matters as a startup. Previously there was a lot of fear associated with pivots. Over time the pivots became something embraced - it meant progress towards a goal.
John Shook (Lean Enterprise Institute) - Lean Startup--From Toyota City to Frement to You
- John started off by following the lead of the MIT research team that spawned the Lean Institute. He wanted to work for a Japanese car manufacturer to learn their management methods. Only one would hire him - Toyota. At the time he was the only westerner working at a Japanese auto plant.
- His statement about Lean to the whole group was powerful. "This (Lean) is a Learn By Doing process. You learn by doing it. With respect to everyone here, attending conferences and reading books will not get you there".
- In 1 year the factory selected for the joint GM/Toyota venture went from last in quality to first (UAW rated)
Brad Smith (Intuit Software) - Lean Leadership Lessons
- This was by far my favorite session. Of course I am defining "favorite" as "The one story I'd most like to find out if they are full of BS or really meant what they said".
- Creating an innovation culture was a deliberate effort and takes buy-in across the whole company. The function of management is most importantly to "Find a way to get to Yes".
- They host an annual incubation week - teams are allowed to work on anything they see fit, company has resources deployed to assist them (legal, etc).
- Their projects are classified into three tiers - Horizon 1 (immediate revenue generators), Horizon 2 (Established business model with actual customers needing to be curated into a full offering), Horizon 3 (The idea/MVP area)
- Their team cultures are different based on their tier of product. And they encourage that to be the case.
- Most interesting to me was the acknowledgement that the Horizon 3 products require a more risk-tolerant environment to thrive, and Intuit delivers it to them.
- Hugh Molosti is their primary idea guy over the years and has a 7 figure incentive package to keep him from going anywhere else. What other company is that proactive in keeping their best idea people?
Monday, November 18, 2013
Of Liaisons, ball bearings, fetzer valves and failures
There's a scene from the movie "Fletch' when Chevy Chase is posing as an aircraft engine mechanic and is being grilled about why he'd need ball bearings. His reply: "Come on guys, it's all ball bearings these days!"
\No, I'm not going to talk about ball bearings or even Fetzer valves (inside joke for the Fletch fans out there).
To paraphrase, "Come on guys! It's all patterns these days!"
But before I do, a bit of history. First, the earth cooled. Then dinosaurs roamed the planet.
Too far back? OK. We'll just set the wayback machine to 1977.
An architect by the name of Christopher Alexander published a book titled "A Pattern Language: Towns, Buildings, Construction". Although reports vary on the influence it had on the Architecture industry, it is commonly cited as the inspiration design patterns in software architecture, interaction design and many other fields.
So what was the big deal? He introduced the concept of a Pattern Language. Pattern languages gave a structure to identifying common problems along with their best practices solution(s) in specific disciplines. This allowed valuable information about common problems and solutions to be communicated much more rapidly and reliably than ever before.
As a software architecture-ish kinda guy, I cut my teeth on the Gang of Four's Design Patterns book. Then as I started looking around at other disciplines I realized that they had their own pattern languages, and if I took the time to understand them I'd have a much better understanding of the problems and problem solving approaches to these other disciplines - think of it as an abstract version of the Rosetta stone
Imagine my delight when I discovered that there were organizational patterns - a pattern language devoted to problem solving challenges in organizational structures, something we have to do from time to time in this business.
Odds are good that you're very familiar with at least one of these, even if you don't know it as an organizational pattern. Ever hear anyone say "We're running a skunk works team"?
Yep. It's an organizational pattern.
During a recent Agile Roots 2014 planning session I was talking with Lory Maddox (RN extraordinaire and mother of Ruby guru and Clean Coder evangelist Pat Maddox) about her current job, which is taking new patient interaction innovations and operationalizing them to work within the highly regulated environment of clinical medicine.
As she was telling a story about how her team averted a logistic nightmare by stopping the release of a new communication solution that had not been adapted by her team for deployment into the highly regulated clinical medicine environment, I realized that her team (whether they realized it or not) were implementing an organization design pattern I like to call "Operationalizing".
Operationalizing: A team with deep experience in a specific (usually highly regulated) environment that has the skills and the responsibility for adapting new solutions (software, process, etc) in such a way that the new solution can be deployed successfully within the target environment.
Note: I have not found definitive literature on the name of this pattern, so I get to call it what I like for now. Comment if you can point me to something authoritative.
I know what you're thinking. No, we haven't gotten to the actual point yet. We're close, I promise! Don't get me wrong, the concept is very interesting, but it isn't the one I wanted to talk about. So why did I even take the time to mention it?
Well, because thinking about how the Operationalizing pattern would play out was the trigger for putting my finger on how I've failed to properly apply the Liaison pattern.
Let's go back to the SkunkWorks pattern for a moment (quietly, we don't want Lockheed suing us).
The SkunkWorks pattern is a very common organizational approach these days to attempt to solve the problem of innovation. Look at any large company you'd care to point to. Odds are very high that they have at least one SkunkWorks team running, maybe more. My former employer Walmart was no exception.
When I was with Walmart this was the organizational pattern that we used to restructure the Mobile Applications group. Or was it?
On the surface, yes. But we broke a few key rules of the SkunkWorks pattern - we did not completely segregate the team from the rest of the organization, nor did we completely decouple our infrastructure from the larger organization. Although I'm of the opinion that we could have done more to segregate the team the same was not true regarding the infrastructure. Because we were building live mobile apps that customers were using to buy real things from Walmart, we didn't have a lot of choices regarding our production infrastructure.
And this is where the Liaison pattern comes into the story. If you were paying attention a few paragraphs back you'll see that I actually used the dreaded "F" word in reference to myself.
One of the first external teams I met with was the InfoSec group - this was the team responsible for insuring that all production code met industry and company security standards. As you'd expect with any large organization, the InfoSec team was a single siloed team that evaluated and validated the output of several teams including our Mobile Applications group.
Here's the sad part. In my first meeting with them I explained how we were departing from the previous practice of months-long release cycles to a much faster cycle. When they indicated that their process didn't allow for that fast of a cycle I told them about the Liaison pattern and how it could be used to great success. After confirming that they all liked the idea I assured failure by making the foolish assumption that they'd actually do something about it.
What I should have done in that situation was to put "find a way to get InfoSec to give us a liaison" at the top of my priority list.
Back to the Liaison pattern. Never heard of it? You'll have to be a student of military organizational logistics to have come across the same definition that I have. In military circles, a Liaison is a person (or persons) that are a member of one group within a military organization but are assigned to be part of another group for the express purpose of helping that group to effectively interact with their "home" group. The pattern is most often implemented in situations where the "other" group operates at a much faster pace than the other group (e.g. Special Operations teams conducing operations in the same areas as conventional forces).
Examples: Forward Air Controller, Liaison Officer
Had I made it a priority to work with InfoSec to have a member of their team assigned to ours it probably would not have made much of a difference in the early days of that engagement, namely because we were successful at pushing back on their process thanks to Executive Sponsorship (yet another organizational pattern). Where it would have made a huge difference was when that same executive sponsorship shifted and we were no longer able to keep InfoSec from slowing down our cycle time.
By the way, that whole slowdown thing? That's an organizational pattern too - Organizational Antibodies. I'll be talking about that one in a future posting.
The moral of the story - Organizational Patterns! Learn them, learn to use them if you care about being effective. Most importantly, learn how not using them will have a negative impact on your team(s).
\No, I'm not going to talk about ball bearings or even Fetzer valves (inside joke for the Fletch fans out there).
To paraphrase, "Come on guys! It's all patterns these days!"
But before I do, a bit of history. First, the earth cooled. Then dinosaurs roamed the planet.
Too far back? OK. We'll just set the wayback machine to 1977.
An architect by the name of Christopher Alexander published a book titled "A Pattern Language: Towns, Buildings, Construction". Although reports vary on the influence it had on the Architecture industry, it is commonly cited as the inspiration design patterns in software architecture, interaction design and many other fields.
So what was the big deal? He introduced the concept of a Pattern Language. Pattern languages gave a structure to identifying common problems along with their best practices solution(s) in specific disciplines. This allowed valuable information about common problems and solutions to be communicated much more rapidly and reliably than ever before.
As a software architecture-ish kinda guy, I cut my teeth on the Gang of Four's Design Patterns book. Then as I started looking around at other disciplines I realized that they had their own pattern languages, and if I took the time to understand them I'd have a much better understanding of the problems and problem solving approaches to these other disciplines - think of it as an abstract version of the Rosetta stone
Imagine my delight when I discovered that there were organizational patterns - a pattern language devoted to problem solving challenges in organizational structures, something we have to do from time to time in this business.
Odds are good that you're very familiar with at least one of these, even if you don't know it as an organizational pattern. Ever hear anyone say "We're running a skunk works team"?
Yep. It's an organizational pattern.
During a recent Agile Roots 2014 planning session I was talking with Lory Maddox (RN extraordinaire and mother of Ruby guru and Clean Coder evangelist Pat Maddox) about her current job, which is taking new patient interaction innovations and operationalizing them to work within the highly regulated environment of clinical medicine.
As she was telling a story about how her team averted a logistic nightmare by stopping the release of a new communication solution that had not been adapted by her team for deployment into the highly regulated clinical medicine environment, I realized that her team (whether they realized it or not) were implementing an organization design pattern I like to call "Operationalizing".
Operationalizing: A team with deep experience in a specific (usually highly regulated) environment that has the skills and the responsibility for adapting new solutions (software, process, etc) in such a way that the new solution can be deployed successfully within the target environment.
Note: I have not found definitive literature on the name of this pattern, so I get to call it what I like for now. Comment if you can point me to something authoritative.
I know what you're thinking. No, we haven't gotten to the actual point yet. We're close, I promise! Don't get me wrong, the concept is very interesting, but it isn't the one I wanted to talk about. So why did I even take the time to mention it?
Well, because thinking about how the Operationalizing pattern would play out was the trigger for putting my finger on how I've failed to properly apply the Liaison pattern.
Let's go back to the SkunkWorks pattern for a moment (quietly, we don't want Lockheed suing us).
The SkunkWorks pattern is a very common organizational approach these days to attempt to solve the problem of innovation. Look at any large company you'd care to point to. Odds are very high that they have at least one SkunkWorks team running, maybe more. My former employer Walmart was no exception.
When I was with Walmart this was the organizational pattern that we used to restructure the Mobile Applications group. Or was it?
On the surface, yes. But we broke a few key rules of the SkunkWorks pattern - we did not completely segregate the team from the rest of the organization, nor did we completely decouple our infrastructure from the larger organization. Although I'm of the opinion that we could have done more to segregate the team the same was not true regarding the infrastructure. Because we were building live mobile apps that customers were using to buy real things from Walmart, we didn't have a lot of choices regarding our production infrastructure.
And this is where the Liaison pattern comes into the story. If you were paying attention a few paragraphs back you'll see that I actually used the dreaded "F" word in reference to myself.
One of the first external teams I met with was the InfoSec group - this was the team responsible for insuring that all production code met industry and company security standards. As you'd expect with any large organization, the InfoSec team was a single siloed team that evaluated and validated the output of several teams including our Mobile Applications group.
Here's the sad part. In my first meeting with them I explained how we were departing from the previous practice of months-long release cycles to a much faster cycle. When they indicated that their process didn't allow for that fast of a cycle I told them about the Liaison pattern and how it could be used to great success. After confirming that they all liked the idea I assured failure by making the foolish assumption that they'd actually do something about it.
What I should have done in that situation was to put "find a way to get InfoSec to give us a liaison" at the top of my priority list.
Back to the Liaison pattern. Never heard of it? You'll have to be a student of military organizational logistics to have come across the same definition that I have. In military circles, a Liaison is a person (or persons) that are a member of one group within a military organization but are assigned to be part of another group for the express purpose of helping that group to effectively interact with their "home" group. The pattern is most often implemented in situations where the "other" group operates at a much faster pace than the other group (e.g. Special Operations teams conducing operations in the same areas as conventional forces).
Examples: Forward Air Controller, Liaison Officer
Had I made it a priority to work with InfoSec to have a member of their team assigned to ours it probably would not have made much of a difference in the early days of that engagement, namely because we were successful at pushing back on their process thanks to Executive Sponsorship (yet another organizational pattern). Where it would have made a huge difference was when that same executive sponsorship shifted and we were no longer able to keep InfoSec from slowing down our cycle time.
By the way, that whole slowdown thing? That's an organizational pattern too - Organizational Antibodies. I'll be talking about that one in a future posting.
The moral of the story - Organizational Patterns! Learn them, learn to use them if you care about being effective. Most importantly, learn how not using them will have a negative impact on your team(s).
Tuesday, October 29, 2013
Getting political with Agile Sadism
I was on my way home from a medical appointment the other day and for some unknown reason decided that I needed to have a little talk radio background noise. After tuning into the local NPR station I was all set to disengage my thinking brain from my ears when I heard the interviewee say "Without common pain there is no chance to achieve real change in an organization."
Cue cinematic double-take record scratching sound.
Did I really just hear that? On an NPR talking heads program?
After a little research I discovered that the talking head in question making this point was no less than Mike Leavitt - former Governor of Utah (amongs many other positions I didn't bother to go look up) and the point he was making was in his new book entitled "Finding Allies, Building Alliances".
For those of you worried about being bored to death by a book report, fear not. I have yet to pick up the book. You'll just have to get by with being bored to death by my thoughts on what I learned from that interview.
If you haven't looked at the title of the blog recently, this would be a good time to do so. Go ahead - I'll give you a minute.
Done? Great. As you'd imagine, the fact that pain is an effective tool in the political arena isn't a huge surprise. What was a surprise was the fact that he acknowledged it as such. What was even a bigger surprise is that he went on to describe a situation where his approach failed.
See why I was surprised? Hearing a politician (or at least a former one) acknowledge not only the fact that he's applied "Machiavellian" techniques to get things done but actually admit that he experienced failure was the true eye-opener for me.
Sounds a lot like a reflection session, doesn't it?
What he "learned" from his failure was that not all of the stakeholders in a particular situation felt a common pain. As a result that same stakeholder ended up derailing the effort because they were better off maintaining the status quo.
Of course we'd never see such a thing in the software development industry, would we?
It is always instructional to see how similar problems are solved in different contexts. As this was the first time I've heard of a formalized approach to solving difficult problems in the political world I wanted to see what could be applied to my industry. Fortunately I was able to find the "Too Long; Didn't Read" book summary to get the big picture:
1. A Common Pain—a shared problem that motivates different people/groups to work together in ways that could otherwise seem counterintuitive.
Cue cinematic double-take record scratching sound.
Did I really just hear that? On an NPR talking heads program?
After a little research I discovered that the talking head in question making this point was no less than Mike Leavitt - former Governor of Utah (amongs many other positions I didn't bother to go look up) and the point he was making was in his new book entitled "Finding Allies, Building Alliances".
For those of you worried about being bored to death by a book report, fear not. I have yet to pick up the book. You'll just have to get by with being bored to death by my thoughts on what I learned from that interview.
If you haven't looked at the title of the blog recently, this would be a good time to do so. Go ahead - I'll give you a minute.
Done? Great. As you'd imagine, the fact that pain is an effective tool in the political arena isn't a huge surprise. What was a surprise was the fact that he acknowledged it as such. What was even a bigger surprise is that he went on to describe a situation where his approach failed.
See why I was surprised? Hearing a politician (or at least a former one) acknowledge not only the fact that he's applied "Machiavellian" techniques to get things done but actually admit that he experienced failure was the true eye-opener for me.
Sounds a lot like a reflection session, doesn't it?
What he "learned" from his failure was that not all of the stakeholders in a particular situation felt a common pain. As a result that same stakeholder ended up derailing the effort because they were better off maintaining the status quo.
Of course we'd never see such a thing in the software development industry, would we?
It is always instructional to see how similar problems are solved in different contexts. As this was the first time I've heard of a formalized approach to solving difficult problems in the political world I wanted to see what could be applied to my industry. Fortunately I was able to find the "Too Long; Didn't Read" book summary to get the big picture:
1. A Common Pain—a shared problem that motivates different people/groups to work together in ways that could otherwise seem counterintuitive.
Absolutely. Of course no virtuous person would ever consider actually manufacturing these common pains to get things done, right?
2. A Convener of Stature—a respected and influential presence who can bring people to the table and, when necessary, keep them there.
If I were translating these points into the software domain (which of course I am) I'd say that this is the equivalent to the concept of an Executive Sponsor
3. Representatives of Substance—collaborative participants must bring the right mix of experience and expertise for legitimacy and have the authority to make decisions.
This was a good reminder to me that the twin characteristics of recognized experience and decision making authority are key for all participants.
4. Committed Leaders—individuals who possess the skill, creativity, dedication and tenacity to move an alliance forward even when it hits the inevitable rough patches.
Since problems within the software domain tend to be smaller in scope to the challenges government groups face, I'd say that we'd see this be the same group as with point
5. A Clearly Defined Purpose—a driving idea that keeps people on task rather than being sidetracked by complexity, ambiguity and other distraction.
Definitely an important point for our industry considering how common it is for our teams to have split responsibilities.
6. A Formal Charter—established rules that help resolve differences and avoid stalemates.
I've decided I don't know how I feel about this one yet. My initial reaction is that establishing rules is counter-productive to solving a problem quickly, but as I thought about it more I realized that the teams that I'd point to as not needing rules were actually operating under a self-generated set of rules learned from prior experiences.
7. The Northbound Train—an intuitive confidence that an alliance will get to its destination, achieve something of unique value, and that those who aren’t on board will be disadvantaged.
This was probably my most valuable takeaway from this list. When you think about it, it is nothing more than a "pain" generated by the problem solving process. But it is also a particularly wide-reaching pain that if properly applied can increase the "rejection rate" of the solution across the wider organization.
8. A Common Information Base—keeps everyone in the loop and avoids divisive secrets and opaqueness.
This is not exactly news for our software world (Information Radiators, Sunshine, etc), but it is a good reminder for me as I have a tendency to not put as much effort into these tools/process as they deserve.
So I'm sure at some point I'll pick up the book and read it. It's probably worth your time to do the same, especially if you are (as I am) a student of seeing similar problems solved in different environments.
Subscribe to:
Posts (Atom)