Comments on: Driving Innovation, Get It? http://theappslab.com/2007/08/29/driving-innovation-get-it/ Driving Innovation Sat, 22 Nov 2008 04:48:52 +0000 http://wordpress.org/?v=2.6.3 By: Rich Manalang http://theappslab.com/2007/08/29/driving-innovation-get-it/#comment-542 Rich Manalang Mon, 17 Sep 2007 22:17:48 +0000 http://oracleappslab.com/2007/08/29/driving-innovation-get-it/#comment-542 Jake... I agree, of course. Check this out... ran into it yesterday -> Secrets to Amazon's success: http://www.37signals.com/svn/posts/600-secrets-to-amazons-success "Teams are small. They are assigned authority and empowered to solve a problem as a service in anyway they see fit. Work from the customer backward. Focus on value you want to deliver for the customer. Force developers to focus on value delivered to the customer instead of building technology first and then figuring how to use it..." Jake… I agree, of course. Check this out… ran into it yesterday -> Secrets to Amazon’s success:

http://www.37signals.com/svn/posts/600-secrets-to-amazons-success

“Teams are small. They are assigned authority and empowered to solve a problem as a service in anyway they see fit.

Work from the customer backward. Focus on value you want to deliver for the customer.

Force developers to focus on value delivered to the customer instead of building technology first and then figuring how to use it…”

]]> By: Jake http://theappslab.com/2007/08/29/driving-innovation-get-it/#comment-541 Jake Mon, 17 Sep 2007 21:36:16 +0000 http://oracleappslab.com/2007/08/29/driving-innovation-get-it/#comment-541 Dude, you know I'm familiar with Extreme Programming, we talked about what we could use of that years ago in Dev. Why can't we use a smaller team approach or something, anything? The agile method has merit too. You can't tell everyone to read something like "Winning with Software" and then implement none of the suggestions. That's not a useful exercise. Tim has unique experience with documentation. My point is that change is needed. You agree we need change, but . . . Why not try what you think works from agile methods, mixed with the waterfall method? You can be the case study. Jake Dude, you know I’m familiar with Extreme Programming, we talked about what we could use of that years ago in Dev.

Why can’t we use a smaller team approach or something, anything? The agile method has merit too. You can’t tell everyone to read something like “Winning with Software” and then implement none of the suggestions. That’s not a useful exercise.

Tim has unique experience with documentation.

My point is that change is needed. You agree we need change, but . . .

Why not try what you think works from agile methods, mixed with the waterfall method? You can be the case study.

Jake

]]> By: David Haimes http://theappslab.com/2007/08/29/driving-innovation-get-it/#comment-540 David Haimes Mon, 17 Sep 2007 21:01:30 +0000 http://oracleappslab.com/2007/08/29/driving-innovation-get-it/#comment-540 Jake, You should also check out Extreme Programming http://www.extremeprogramming.org/ It's been around a while and talks of these short iterations. Tim's observation that as the team gets bigger the need for documentation increases. With an Enterprise Software vendor the team can run into thousands. I believe there is a need for some departure from the waterfall model, but the rapid development methodologies bring an equal number of issues for large development organizations. Jake,

You should also check out Extreme Programming

http://www.extremeprogramming.org/

It’s been around a while and talks of these short iterations.

Tim’s observation that as the team gets bigger the need for documentation increases. With an Enterprise Software vendor the team can run into thousands. I believe there is a need for some departure from the waterfall model, but the rapid development methodologies bring an equal number of issues for large development organizations.

]]> By: Jake http://theappslab.com/2007/08/29/driving-innovation-get-it/#comment-390 Jake Sat, 01 Sep 2007 04:20:42 +0000 http://oracleappslab.com/2007/08/29/driving-innovation-get-it/#comment-390 Paul, I like the cut of your jib. We aren't intentionally disruptive, but we have been trying to provoke (I like that word) innovation. We are a part of Apps Strategy after all, and I think we can all agree that the old ways could use a jump start, e.g. sitting in a dark room showing slides on how you think we should do stuff won't cut the mustard anymore. People are 1) too busy, 2) too comfortable with the old ways and 3) too focused. Focus in this case is not a good thing b/c it can blind you to innovation. Anyway, we do what we can. Time will tell. Keep reading and commenting. Jake Paul,
I like the cut of your jib. We aren’t intentionally disruptive, but we have been trying to provoke (I like that word) innovation. We are a part of Apps Strategy after all, and I think we can all agree that the old ways could use a jump start, e.g. sitting in a dark room showing slides on how you think we should do stuff won’t cut the mustard anymore. People are 1) too busy, 2) too comfortable with the old ways and 3) too focused. Focus in this case is not a good thing b/c it can blind you to innovation.
Anyway, we do what we can. Time will tell. Keep reading and commenting.
Jake

]]> By: Paul http://theappslab.com/2007/08/29/driving-innovation-get-it/#comment-388 Paul Thu, 30 Aug 2007 23:57:32 +0000 http://oracleappslab.com/2007/08/29/driving-innovation-get-it/#comment-388 hmm. Seems to me you are just making a case for agile methodologies, albeit with shortcuts! But I don't see anything exclusive to Web 2.0. Even the idea of "perpetual beta" is not exactly groundbreaking (could make a few jokes at this point). So what is the real message and meaning of Connect? I'd suggest its not really about web/enterprise 2.0 at all, not even about methodologies. It's about being the intentionally disruptive force that provokes innovation elsewhere. In other words, driving for an indirect but exponential payoff. So from that point of view, where Connect itself is not necessarily a "product" with longevity but a means of stimulating the applications dev and aria teams to adopt and extend "connect" innovations, then how you build it and whether you wrote any doc is pretty irrelevant;) What's more important is how you can best isolate, evaluate and evangelise the "innovations that worked". hmm. Seems to me you are just making a case for agile methodologies, albeit with shortcuts!

But I don’t see anything exclusive to Web 2.0. Even the idea of “perpetual beta” is not exactly groundbreaking (could make a few jokes at this point).

So what is the real message and meaning of Connect?

I’d suggest its not really about web/enterprise 2.0 at all, not even about methodologies. It’s about being the intentionally disruptive force that provokes innovation elsewhere. In other words, driving for an indirect but exponential payoff.

So from that point of view, where Connect itself is not necessarily a “product” with longevity but a means of stimulating the applications dev and aria teams to adopt and extend “connect” innovations, then how you build it and whether you wrote any doc is pretty irrelevant;)

What’s more important is how you can best isolate, evaluate and evangelise the “innovations that worked”.

]]> By: Mark http://theappslab.com/2007/08/29/driving-innovation-get-it/#comment-379 Mark Thu, 30 Aug 2007 15:47:16 +0000 http://oracleappslab.com/2007/08/29/driving-innovation-get-it/#comment-379 One way to look at Connect is to view *it* as the design document. It conveys the current thinking of the requirements, based on feedback from live and continuous usability studies and anyone can look at it to see what the current state of requirements are. It's just a lot more dynamic (and a lot richer in content) than a word doc. As long as the investment/return ratio is in line, *how* you gather requirements should be open. One way to look at Connect is to view *it* as the design document. It conveys the current thinking of the requirements, based on feedback from live and continuous usability studies and anyone can look at it to see what the current state of requirements are. It’s just a lot more dynamic (and a lot richer in content) than a word doc. As long as the investment/return ratio is in line, *how* you gather requirements should be open.

]]> By: Tim http://theappslab.com/2007/08/29/driving-innovation-get-it/#comment-378 Tim Thu, 30 Aug 2007 15:37:26 +0000 http://oracleappslab.com/2007/08/29/driving-innovation-get-it/#comment-378 Oh Jake, tsk tsk, no design docs! Welcome to the world of what we call 'Rapid Application Development' - its not made up as an excuse for lack of doc - http://en.wikipedia.org/wiki/Rapid_application_development It's worked for us but we now have some growing pains. As you get more customers, more and more requirements flood in and your team grows to cope, documentation becomes a necessity. If nothing else than to help team members understand who is building what. We are not fabulous at the doc thang but we are getting better ... especially now Im remote and whinging all the time for doc. But there is still room for iterative innovation which will be addressing requirements that the customer has not even thought of yet :0) Which, lets face it, is what keeps the development team happy and motivated - that and donuts and coffee. Oh Jake, tsk tsk, no design docs!
Welcome to the world of what we call ‘Rapid Application Development’ - its not made up as an excuse for lack of doc - http://en.wikipedia.org/wiki/Rapid_application_development
It’s worked for us but we now have some growing pains. As you get more customers, more and more requirements flood in and your team grows to cope, documentation becomes a necessity. If nothing else than to help team members understand who is building what.
We are not fabulous at the doc thang but we are getting better … especially now Im remote and whinging all the time for doc. But there is still room for iterative innovation which will be addressing requirements that the customer has not even thought of yet :0) Which, lets face it, is what keeps the development team happy and motivated - that and donuts and coffee.

]]>