Loading ...
Sorry, an error occurred while loading the content.

Re: What is a 'Product'?

Expand Messages
  • davenicolette
    Based on the description, it sounds as if just about anything they tried would be an improvement over what they were doing before. Actually, I think the
    Message 1 of 12 , Apr 30 8:58 AM
    • 0 Attachment
      Based on the description, it sounds as if just about anything they tried would be an improvement over what they were doing before.

      Actually, I think the time-boxed iterations provided by a framework like Scrum sound like a good fit here. It would help them get a handle on priorities and give them a basis for regular delivery at predictable intervals. Scrum's mechanism for keeping interruptions to a minimum will also be helpful.

      Because they have a lot of work requests coming into a small team, one page they may want to take from the lean book is to keep work in process to a minimum. It sounds like there will be pressure and temptation (not to mention force of habit) to have a lot of work items in flight simultaneously.

      Part of the problem seems to be upstream prioritization of projects ("many things were coming down from the executive level"). That isn't addressed directly by Scrum or by Kanban, but if the team continues to get hammered with disjointed work requests it will be very hard for them to keep the work flowing smoothly, regardless of what sort of framework or process they use.

      So, I would say Scrum is a reasonable starting point for this organization, just based on the description that's been posted here, plus paying attention to prioritization and work in process.

      Cheers,
      Dave


      --- In scrumdevelopment@yahoogroups.com, "Cat Schwamm" <cat.schwamm@...> wrote:
      >
      > I know this is the wrooong group to say this in, but perhaps Kanban would suit your team more. If you are having items with competing priorities constantly interrupting your sprints and you are unable to create a clear path of work, a rolling wave kanban is probably more helpful for you than scrum. With This link might help you work out whether or not this is true:
      > http://agilethis.com/2009/04/15/kanban-vs-scrum/
      >
      > Or, you can always take the middle path with Scrum-ban or Scrumbut!
      >
      > --- In scrumdevelopment@yahoogroups.com, "Jackie" <jpark@> wrote:
      > >
      > > --- In scrumdevelopment@yahoogroups.com, Adam Sroka <adam.sroka@> wrote:
      > > >
      > > > On Wed, Apr 29, 2009 at 12:50 PM, Jackie <jpark@> wrote:
      > > > >
      > > > >
      > > > > Hi,
      > > > >
      > > > > I have a question for everyone. To you, your team, product owner, or whoever
      > > > > else in your organization how do you define what a product is? Do you have a
      > > > > definition for it? Is there even one for a product?
      > > > >
      > > >
      > > > A product is something that a customer will want to buy. Defining it
      > > > is the easy part. The harder part is that very rarely do two customers
      > > > want /exactly/ the same thing so the art of product development is
      > > > figuring out how to improve your product in a direction that will
      > > > satisfy the most customers (Current and prospective.)
      > > >
      > > These are just some questions we at my office have been discussing. We are in the process of overhauling our Scrum process that we started just under a year ago and have found many things we were doing wrong, some things we were doing alright but needed to improve upon.
      > > >
      > > >
      > > Well I hope that helps, but I suspect not. I'm curious to know what sort of problems you are experiencing. I would guess that not agreeing on the definition of "product" (The definition I have provided is pretty close to the dictionary) is just the tip of the iceberg.
      > >
      > >
      > > Thank you for the help!!
      > >
      > > Our problems are many and varied! First. We've been running too many sprints at a time and many of the teams on those sprints were teams of 1 or 2. Second. We'd work for 1 - 2 2 weeks sprints and then my teams would get pulled in another direction on a different project and then after that go back to the one they were working on. Third. We weren't working and developing in a real iterative fashion. Fourth. Our product owners were either not in house all time, were too busy with other things to focus on the project, or just didn't know what to do. It's been a challenge for me as a scrum master to try and get things changed when many things were coming down from the executive level. Finally, after all of the developers sat down w/management they understood our frustration with the way things are going.
      > > So now we're reorganizing the way we do things. And have settled on only working on 2 projects at a time. Doing training for product owners so they know what's fully expected of them and then adjusting their workload so they can focus more on the project. We're also doing a short training or retraining on Scrum and some processes for everyone.
      > > We're a small company (about 50 total) with about 9 developers that's trying to accomplish a lot all at once. But now I think with some changes and people understanding everything better we should start to head in the right direction.
      > >
      >
    Your message has been successfully submitted and would be delivered to recipients shortly.