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

Re: beginning a SCRUM project

Expand Messages
  • Justin Creasy
    We started our company, Immerge Technologies, using a few projects we did in college. So basically we had a few proof of concept programs that had created.
    Message 1 of 9 , Jun 15, 2005
      We started our company, Immerge Technologies, using a few projects we
      did in college. So basically we had a few "proof of concept" programs
      that had created. These projects sparked enough interest from the
      school, town, and VC's to get us the very basics of what we needed to
      start turning our programs into products.

      We moved into some office space provided by a local engineering firm
      about 3 weeks ago. We spent those first few weeks reviewing what we
      had, talking about what we wanted it to become, and creating basic
      diagrams of what needed to be done to get it there.

      These plans will most likely change a whole lot as we create the
      product. Since we'll have changing requirements and we already have a
      small tight-knit group, SCRUM made a lot of sense.

      Now our basic planning is done and we're ready to start coding the
      core of the product. I have a list of classes/methods/techniques
      that's long enough to keep us busy for awhile. What I wanted to know
      when I first posted was basically how long of a sprint is right for
      us. I know that sprints tend to be a month long, but it seemed to me
      that in these early stages when we're still learning how to use SCRUM
      correctly that we should keep our sprints short.

      So far all of your feedback has been very helpful. I just wanted to
      clear up some of the questions that have been addressed. Thanks again
      for taking the time to help me and my company out and I'm looking
      forward to any more information that you can provide.

      --- In scrumdevelopment@yahoogroups.com, todd <todd@p...> wrote:
      > aacockburn wrote:
      >
      > > In my book, therefore, it does make sense to spend time deciding
      what
      > > the company should build, and also what basic architecture to
      use ---
      > > and then it makes sense to start building early, so you can
      discover
      > > which of your assumptions was ill-founded and which of several
      > > alternatives works better.
      > >
      > I am curious as to how you would go about getting funding from a
      VC, for
      > example, without deciding what you want to build before coding
      starts?
      > The process of building a business plan, meeting with customers,
      meeting
      > with VCs, and talking with industry representatives is what guides
      you
      > in what to build. Typically people go through 3 or 4 iterations of
      their
      > product idea before they settle on something. This may take years.
      One
      > friend finally got funding after 2 years of constant effort.
      >
      > For example, on a corporate wifi startup, considerable effort had
      to go
      > into issues like hardware and software architecture to create a
      detailed
      > BOM of the system. The number of high level decisions you need to
      create
      > a BOM is amazing. But without the BOM you can't get to costs and
      part
      > selection and vendor selection which means you don't have a product
      to
      > build and you don't have a profit margin to show. Cost and
      availability
      > issues can easily cause the entire process to start over again.
      >
      > Where security is done has massive software and hardware
      implications.
      > Modern chips have a high degree of security and network
      integration.
      > They are costly though. What platforms do they have drivers for?
      Which
      > third party software works with them? If it doesn't work with are
      OS can
      > we get someone to port it? If we can't and the software would cut
      our
      > time to market can we change OSs and processor choice? What does
      that
      > mean for memory, CPU, the network, etc? Could we up the CPU power
      to
      > use a software only stack, but what does that do for costs? How
      many
      > users would that support? How else could we handle more users? Does
      that
      > take more boxes, more memory and what does that do to the head
      count on
      > the hardware side and can we get the people we need to design the
      new
      > additions? Would we need a bigger office to handle more people?
      What
      > would that cost? What happens if we are making assumptions about
      > software performance and cost and we are wrong?
      >
      > And these are not one time decisions. They all interplay over
      months.
      > Writing software at that point would have been a useless effort
      that
      > distracted from the real goal of that phase of the project.
    Your message has been successfully submitted and would be delivered to recipients shortly.