Re: beginning a SCRUM project
- 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 email@example.com, todd <todd@p...> wrote:
> aacockburn wrote:
> > In my book, therefore, it does make sense to spend time deciding
> > the company should build, and also what basic architecture to
> > and then it makes sense to start building early, so you can
> > 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
> example, without deciding what you want to build before coding
> The process of building a business plan, meeting with customers,
> with VCs, and talking with industry representatives is what guides
> in what to build. Typically people go through 3 or 4 iterations of
> product idea before they settle on something. This may take years.
> friend finally got funding after 2 years of constant effort.
> For example, on a corporate wifi startup, considerable effort had
> into issues like hardware and software architecture to create a
> BOM of the system. The number of high level decisions you need to
> a BOM is amazing. But without the BOM you can't get to costs and
> selection and vendor selection which means you don't have a product
> build and you don't have a profit margin to show. Cost and
> issues can easily cause the entire process to start over again.
> Where security is done has massive software and hardware
> Modern chips have a high degree of security and network
> They are costly though. What platforms do they have drivers for?
> third party software works with them? If it doesn't work with are
> we get someone to port it? If we can't and the software would cut
> time to market can we change OSs and processor choice? What does
> mean for memory, CPU, the network, etc? Could we up the CPU power
> use a software only stack, but what does that do for costs? How
> users would that support? How else could we handle more users? Does
> take more boxes, more memory and what does that do to the head
> the hardware side and can we get the people we need to design the
> additions? Would we need a bigger office to handle more people?
> 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
> Writing software at that point would have been a useless effort
> distracted from the real goal of that phase of the project.