Re: [scrumdevelopment] Re: In organization using Scrum, who's in charge of innovation ?
- On Mon, Jul 26, 2010 at 9:48 PM, gregc <greg@...> wrote:
I am total agreement that agile practices are a great enabler of innovation. They definitely orient the team to develop process innovations such as the example you mention of cutting system compile time in half. And agile promotes rapid feedback cycles. Customers can explain problems and respond to solutions. They are not so good at explaining solutions. So being able to show them something is important to product innovation.(Although concept docs and mock-ups are less expensive than development.)
Within a development team there are techniques to promote innovation. As I mentioned before HIT Matrix, trimming, plus others like provokation. These are skills. So, I agree innovation is the responsibility of everyone. But as Roy states, you can't just tell people to to be innovative and expect creative thinking to occur. It's much like quality is responsibility of everyone, but TDD is a skill. It doesn't just happen because we say quality is everyone's job.
There's an interesting movement emerging called the lean startup. Eric Ries is the one of the key guys and Steven Blank who wrote "four steps to the epiphany" is his mentor. They focus exclusively on the hardest type of innovation where the problem and the solution are both undefined. I worked for idealab during the dotcom working on this type of problem and there was much that we did because it just kind of made sense, but Steve Blank has put a framework around it. In this model there is a parallel customer development cycle that happens in along side the solution development. Anyway, the point of this and the part that readers on this list might find most interesting is Kent Beck presented at one of the lean startup conferences and offered an evolution to the Agile Manifesto that I personally found very thought provoking and really targets this question of innovation:
1. Team Vision and Discipline > Individuals and interactions > Processes and tools
2. Validated Learning > Working Software > Comprehensive documentation
3. Customer discovery > Customer Collaboration > Contract negotiation
4. Initiating Change > Responding to change > Following a plan
If your team is working on the left hand side of this list than your agile implementation is likely resulting in a lot of innovation. But if you are not, there's still a long way to improve and you can't just will it to happen.
Greg Cohen | Senior Principal Consultant | www.280group.com |
Author: Agile Excellence for Product Managers
--- In email@example.com, Alan Dayley <alandd@...> wrote:
>> Nice discussion, Greg. Thank you!
> I can see that innovation can be thought of as a different skill set. I
> must say that I see most of what you listed as techniques to uncover
> problems worth solving as the work of marketing research. A company should
> have someone investigating for value opportunities and defining them. It
> can be useful to think of such work as "the application of innovation
> skills" I suppose. Maybe I am naive to think this is part of the marketing
> department's charter for existence.
> I think innovation is the responsibility of everyone. From figuring out
> that pink tackle boxes would be great product to cutting system compilation
> time in half, every person in the company should be seeking improvements and
> breaking out of the box. Agile practices help innovative thinking to
> percolate through the entire organization.
>> > --- In firstname.lastname@example.org<scrumdevelopment%40yahoogroups.com>,> On Fri, Jul 23, 2010 at 3:10 PM, gregc <greg@...> wrote:
> > Alan,
> > I kind of like the way Roy phrases it "It would be nonsense to include in a
> > development methodology an 'innovation phase', or to stipulate 'innovative
> > thinking'." Therefore, if innovation doesn't sit in development, it must sit
> > separate and therefore is a separate discipline. That's my quick proof.
> > But to go a little deeper, let's define some types of innovation: business
> > model, process, and product.
> > 1. Business model – Auto financing. Now you can buy a car without having
> > all the money upfront. Salesforce.com succeeded in a similar way with SaaS.
> > Auto financing is separate from the product being delivered where
> > salesforce.com needed to leverage a number of technology innovations to
> > make it's product possible. These decisions should have happened prior to
> > development.
> > 2. Process innovation – actually, Scrum scores big here. Retorspectives are
> > built into the method. And it allows the team to work on process improvement
> > which can ultimately turn into competitive advantage allowing a company to
> > produce software better, faster, and cheaper.
> > 3. Product innovation – Define as a product that for a given segment of
> > users provides significantly more value than the alternatives. On the
> > premium end of product innovation, we can often look to apple for great
> > examples like the ipad. But the flip camera is also a great example on the
> > low-end. The camera is generally inferior in features and capability to the
> > traditional camcorder, but it wins on four key dimensions: portability,
> > simplicity of use, ease of sharing videos online, and price. Flip understood
> > its user and caught Sony and the other players off guard.
> > In responding to the initial question on this thread, I kind of took it to
> > mean product innovation. And for now I'll restrict my comments to that area.
> > I do not know the specifics of Apple or Flip and how these products
> > emerged, but I'm going to guess they did a lot of upfront work figuring out
> > the problem to solve. There are a number of established techniques to
> > uncover problems worth solving and testing those concepts and this in my
> > mind constitutes a discipline. To list some of them:
> > 1. Ethnography – observing you customer "in the wild". See what issues they
> > encounter that you might be able to solve. Lee Shaeffer of PLM associates
> > shared a great story with me the other day of a company that made tackle
> > boxes. The owner was in the sporting goods store observing people purchasing
> > tackle boxes when a girl walked up and bought one. He didn't think much of
> > it until another girl came in and did the same. At this point he engaged the
> > second girl in a conversation. Turns out the girls loved all the little
> > compartments in these boxes. It was perfect for her make-up and jewelry and
> > it could be locked to keep her younger brother out. And this became the seed
> > for a line of pink jewelry boxed sold through a different retail channel.
> > Intuit also pioneered these techniques with follow-me home interviews of
> > people who purchased their products.
> > 2. Interviews or focus groups – try to understand a customer segments
> > issues
> > 3. Opportunity score assessment – once you've done the research above to
> > identify problems that people want solved, you survey them to understand how
> > important an issue is and how satisfied they are today with their current
> > solution. Finding areas of large gaps, often with secondary capabilities
> > because the primary ones are well satisfied, are the opportunities. For more
> > you can read Anthony Ulwick's "what customers want."
> > 4. Kano Surveys – separates out what capabilities are must haves, what
> > capabilities that if they worked better would be more valued, and what
> > capabilities are not expected but would delight the user.
> > 5. Conjoint analysis – help understand what combination of capabilities
> > (and price) are valued. This can help teams optimize the tradeoffs for size,
> > weight, and battery life of a mobile phone.
> > 6. Innovation games – this is the area pioneered by Luke Hohmann on
> > collaborative play to get deeper into customer's minds and needs than
> > traditional interview techniques.
> > Once the problem is identified, there are techniques to help teams innovate
> > around the solution. A great compilation book on this that came out last
> > year is "the innovator's toolkit." One I learned from that book is HIT
> > matrix where you take two unrelated products and services and see where they
> > can be combined. Another technique is trimming – where you eliminate a part
> > of your solution, "what if you couldn't use the keyboard to enter data, how
> > would it work?"
> > And once you get good at driving all this innovation, you need to manage it
> > as a portfolio. Making sure you haven't bet the farm on one big and
> > expensive breakthrough innovation but rather that you have a balance of
> > innovation projects from incremental and large impact innovations, short
> > payback versus long payback, low risk versus high risk, and low cost versus
> > high cost.
> > Alan, to get back to your question "In what way is "innovation" a separate
> > discipline from some other skill set?", everything I listed above to me
> > represents a set of practices that can be studied and learned and employed
> > to produce better outcomes. In other words, we can be deliberate in our
> > desire to innovate. We do not have to sit around and wait for that eureka
> > moment. Also, innovation can be done as a team activity rather than reliant
> > on the sole inventor. Thus, I consider it a separate discipline. But let me
> > know if you think it fits your definition as well.
> > -greg
> > Greg Cohen | Senior Principal Consultant | www.280group.com |
> > Author: Agile Excellence for Product Managers
> > Alan Dayley <alandd@> wrote:
> > >
> > > Greg,
> > >
> > > I'm going to pull a small quote of yours out of context. I'd like to ask
> > > some questions about it. You stated: "...innovation is a separate
> > > discipline..."
> > >
> > > An example of separate disciplines, to me, would be hardware design vs.
> > > software design. In other words, an electrical engineer has experience
> > and
> > > long study in designing circuits and cannot be expected to know all the
> > best
> > > ways to create software. And the software engineer has the significant
> > > advantage in her realm but cannot be expected to design a PCB. These are
> > > separate disciplines.
> > >
> > > In what way is "innovation" a separate discipline from some other skill
> > > set? Should innovation be a separate discipline? If so, what does this
> > > separation look like?
> > >
> > > Alan
> > >
> > > On Thu, Jul 22, 2010 at 11:41 AM, gregc <greg@> wrote:
> > >
> > > >
> > > >
> > > > Pierre,
> > > >
> > > > You are right, Scrum and Agile literature say little about innovation.
> > Most
> > > > of the literature starts with the assumption that there is an approved
> > > > project that the business has determined it worthwhile to build. Agile
> > > > methods were about how to deliver on the approved project while
> > lowering
> > > > risk and delivering what the project sponsors and user goals were. If I
> > > > recall the goals of Scrum it was:
> > > >
> > > > 1. Improve productivity by 1x – 3x
> > > > 2. Increase flexibility
> > > > 3. Lower risk
> > > > 4. Create a better work environment
> > > >
> > > > Notice innovation was not a goal. So don't fault Scrum or other agile
> > > > methods for not addressing innovation because they were not trying to.
> > Just
> > > > realize innovation is a separate discipline and agile development are a
> > key
> > > > enabler in bringing an innovation to market with reduced risk.
> > > >
> > > > What Seth Godin is getting at when he writes "if you decide what to
> > build
> > > > based on what your customers (or users) want, there is no more place
> > for
> > > > innovation" is that it is not the customers' responsibility to design
> > > > solutions or to even know what is possible. However, customers are very
> > good
> > > > at talking about their problems and giving feedback when shown a
> > solution
> > > > (reread this sentence, it is important.)
> > > >
> > > > When a customer says they want a feature, we don't want to develop the
> > > > feature, we want to understand the need that sits behind the request
> > for the
> > > > feature. Once we understand what the problem is to be solved (in my
> > world
> > > > this would be a product management responsibility but should involve
> > the
> > > > product team in this discovery process), then development thinks deeply
> > > > about can technology be applied to solve this problem. The product
> > manager
> > > > (or could be a PO depending on titles and roles) and the dev team
> > > > collaborate on possible solution concepts. Once the concept is
> > developed
> > > > (and you may have multiple at this stage), the product manager would
> > test
> > > > those with the target customer and the concept is iterated. Once you
> > have
> > > > confidence that you can solve the problem effectively and sell it for
> > more
> > > > than it will cost to build, it should then become approved and
> > development
> > > > begins (and I and most people on this list would likely favor agile
> > > > development.) But notice, the idea of how to innovate (meaning the
> > > > identification of the problem to solve) has all happened prior to
> > > > development starting. Agile dev is key here because customers will give
> > > > better feedback to a real solution than a concept. So using iterative
> > > > development after concept validation lets you get the feedback to know
> > the
> > > > solution you are building is on the right track.
> > > >
> > > > So let me try to make it real with an example. I used to be a product
> > > > manager on supply chain solutions. Our customers wanted to automate a
> > time
> > > > consuming manual process they would go through to manage their
> > inventory and
> > > > avoid stock outs. Once a week they faxed a form with a list of their
> > key
> > > > products to their distributors who then had to fill out the form with
> > order
> > > > information and on-hand information for those products and fax it back.
> > My
> > > > customers would then compile the data in a spreadsheet, crunch some
> > numbers,
> > > > and determine if they had any stock out risk at any of their
> > distributors.
> > > > What my customer wanted was for us to collect that information
> > automatically
> > > > from the distributors' computer system on a daily basis (instead of
> > weekly)
> > > > and make it available in an online report that they could check every
> > > > morning. That is all my customers wanted! If I could do this for them,
> > I
> > > > would have saved them much time, a lot of headache, and given them more
> > > > actionable daily data. But I dug deeper, asking questions like "how do
> > you
> > > > determine if the distributor is going to run out of inventory before
> > their
> > > > next shipment from the manufacturer?" "What do you do when you identify
> > a
> > > > potential stock out?" What emerged from this further inquiry was the
> > > > customer didn't need to log into the product every day to look at the
> > > > report. Our product could apply their mental algorithm and send them an
> > > > alert if a stock out was likely. Further, we could also enable the
> > > > distributor to manage the situation themselves and only involve my
> > customer
> > > > if they could not solve the problem themselves (this might be the
> > customer
> > > > shorting distributors who have enough inventory to move it to a
> > distributor
> > > > that doesn't or arranging for a distributor to distributor transfer.)
> > Now I
> > > > use this example because the new functionality I uncovered during
> > discovery
> > > > is actually pretty obvious. But it wasn't to my customers, and they
> > were
> > > > very smart people.
> > > >
> > > > Now there's a lot more to innovation than covered above, and we can get
> > > > into that, but I want to make sure I'm addressing your situation before
> > > > going on much further. So let us know if this is relevant and
> > actionable for
> > > > you.
> > > >
> > > > -greg
> > > >
> > > > Greg Cohen | Senior Principal Consultant | www.280group.com |
> > > > Author: Agile Excellence for Product Managers
> > > >
> > > >
> > >