How does Scrum work on a project starting from scratch?

[Mark Herschberg]

We built a prototype of a project in PHP. It wasn't designed well, mostly because it was a prototype and it was moved in one direction or another, until we finally came to understand what we wanted.

Now we're building the real system. It's being done in Java using Spring/Hibernate and related technologies. We are going to start using the scrum process. I've done through books and webpages on scrum and talked to people who have used it. one question remains: how do we take into account architecture and design in the scrum? Do you make a story such as "Design the syste architecture?"

I should note that for the last few weeks some engineers have been playing around with technologies, which is how we decided on Spring/Hibernate. We have a general idea about architecting the system, but it still needs to be fleshed out. How is this captured in the scrum process?

Thanks for any help.

--Mark

[Ilja Preuss]

Well, as you are probably aware of, Scrum actually isn't a software development process, but a more general project management process. So a software problem like coming up with the architecture is kind of outside the scope of Scrum.

On the other hand, with Scrum being Agile you will want to your architecture to support Agile development - which basically means that it needs to accommodate for early and frequent releases, as well as changes in requirements and everyones understanding and knowledge.

Early and frequent releases of working software with maximal business value means that the architecture needs to be build incrementally, together with the rest of the system. That is, you don't have a story "design the architecture", but the architecture is designed and build in the process of implementing the stories that deliver direct business value.

Easily accepting changes basically means two things for the architecture: it needs to be well decoupled and flexible, but simple (in contrast to overdesigned), and you will need to continuously and mercilessly refactor it, so that it remains flexible in the light of new requirements, new code and new learnings on all sides.

It's good that your engineers experimented with some frameworks, but I'd hesitate to use them from day one. Implementing the very first story probably will be much easier without those frameworks, and getting something working in the first week to show to the customer is very important, both for the motivation of the team and the feedback and trust from the customer. It shows that you are able to deliver and calibrates your communication with the stakeholders.

Your knowledge of the frameworks will put you in a very good position to write your code in a way so that introducing them later won't be a big problem - and to notice the point in the project where they actually will start to help you reduce duplication and improve the flexibility of the system - which is the day you should start using them.

Does that help? Sound reasonable?

[Mark Herschberg]

Hmm...

Reading Ken Schwaber's books, he talks about beginning scrum projects from scratch, so at some point someone did some design. I guess you're saying, "just do it" and the architecture will come out of it. This seems very XP and you may recall a discussion we had a few years back where I disagreed with XP because it didn't plan the architecture well enough, and wasn't convinced the Spike Method was a viable solution.

That said, I'm not arguing that the whole system should be designed up front. Merely that I have a brand new team (most people hired within the last 2 weeks, some starting day 1 of the scrum), a new type of product (there are no existing or even analagous systems), and they feel a bit naked without some idea of where we are going. I have given them some general design; maybe that's enough.

By framework I assume you mean, larger systems framework, as opposed to the frameworks of spring and hibernate. We do, however, still need to pick a front end (i.e. struts, SpringMVC, JSF, etc). We can just pick one the firts time someone has a need for it, but there's a good chance it's the wrong one, and will cost us time in the future. I'm willing to invest some time up front to get off on the right foot.

How does scrum manage this?

--Mark

[Ilja Preuss]

Originally posted by Mark Herschberg:
Reading Ken Schwaber's books, he talks about beginning scrum projects from scratch, so at some point someone did some design.

Certainly. But as far as I can tell, Scrum doesn't tell you at all how to do that - it leaves it fully open.

A Scrum team has to add software development practices to its process which aren't provided by Scrum itself. Many Scrum teams seem to gravitate towards practices inspired by XP.

I guess you're saying, "just do it" and the architecture will come out of it.

Ah, no, not really. Developing an architecture incrementally is a skill that needs to be learned - it doesn't "just happen". It needs careful thought and action.

To me, it is easier and less risky than having to commit to the architecture up front, though, as it allows to make decisions based on more real data and to more easily correct errors made in early decisions.

This seems very XP and you may recall a discussion we had a few years back where I disagreed with XP because it didn't plan the architecture well enough, and wasn't convinced the Spike Method was a viable solution.

Yes, it's certainly "very XP", but XP is in no ways alone in this regard.

In "Agile Software Development Ecosystems", Jim Highsmith writes (pg. 159):

"There are three key factors in doing "Agile" architecture or modeling. First is recognizing and constantly reminding ourselves that plans are just plans. Plans change and models change - constantly throughout the project. Second is to have as a constant mantra the need to keep things simple and understand that refactoring will help recovery from oversights. Third is that the best way to manage up-front architecture work is to time-box the effort - short time-boxes."

He then goes on to suggest spending a couple of weeks (called "iteration zero") on working out a class structure or data model, but not much more.

In "Crystal Clear", Alistair Cockburn suggest to start with a "Walking Skeleton": "a tiny implementation of the system that performs a small end-to-end function. It need not use the final architecture, but it should link together the main architectural components. The architecture and the functionality can then evolve in parallel."

Then, he suggests, you should "Incrementally Rearchitecture": "The system architecture will need to evolve from the walking skeleton and handle changes in technology and business requirements over time. [...] the team evolves the architecture in stages, keeping the system running as they do so." "Developers in the last decade have shown that tidy, simple architectures are reasonably straightforward to upgrade to their next stage of complexity and performance. The business consequence is that, very often, a company can create an early version to demonstrate function and possibly even generate revenue, and then use the incremental rearchitecture strategy to revamp the infrastructure under the running system."

Lean Software Development - a methodology adapted from how Toyota builds cars, has principles such as "set based decision making", making decisions at the "last responsible moment" and "learning-based software development".

The theme can be found everywhere in Agile Software Development: learning how to keep your options open so that you can defer both making decisions and investing work is better than the best plan.

I understand that this sounds risky to you, and it certainly can be frightening if you've never experienced it. And you certainly won't do it perfectly the first time you try.

Still, the best advice I know to give is to go as far into that direction as seems comfortable to you. I'd trust you to learn quickly!

That said, I'm not arguing that the whole system should be designed up front. Merely that I have a brand new team (most people hired within the last 2 weeks, some starting day 1 of the scrum), a new type of product (there are no existing or even analagous systems), and they feel a bit naked without some idea of where we are going. I have given them some general design; maybe that's enough.

Did you ask them what they needed to feel more comfortable?

Frankly, I don't see how a spike could possibly *not* help them. And it's really not that big an investment, so if they'd like to try, what could you loose?

By framework I assume you mean, larger systems framework, as opposed to the frameworks of spring and hibernate.

I don't know Spring well enough to comment, but I'm definitely talking about Hibernate. Depending on the system you develop, I could even imagine not having any persistence implemented in the first week at all. It all depends on what your domain experts and the developers think where the risks and the most value lie...

We do, however, still need to pick a front end (i.e. struts, SpringMVC, JSF, etc). We can just pick one the firts time someone has a need for it, but there's a good chance it's the wrong one, and will cost us time in the future. I'm willing to invest some time up front to get off on the right foot.

Well, yes. Again, a spike would give you some more data to work with, I'd assume. But even with a spike, selecting the "right" framework still is a lot of guesswork.

There is an interesting idea in the "Lean Software Development" book - I haven't tried it yet, but it sounds very reasonable to me: start by using a couple of the most promising solutions in parallel. Of course that means more work at the start, but it has some strong benefits: it spares you most of the guesswork in return, it forces you to have an architecture that decouples the rest of the system from this decision (so that you can change it again later for minimal costs) and it gives you a lot of real data to base your decision on.

How does scrum manage this?

Again, as far as I know, Scrum itself doesn't have anything to say on this topic. It's simply outside it's scope.

[Mark Herschberg]

The good news is we have a working system (a prototype) and the developers have spent the last few weeks (1-3 depending on when they came on board) building such prototypes and playing around with technologies. We have done some parallel development and, maybe not spike solutions, but bump solutions, to plan some methods.

Thanks for all the advice.

--Mark

[Lasse Koskela]

Regarding architecture, Ken Schwaber suggests planning architecture up-front just enough to allow for scaling the number of teams you want to have.

In other words, if you have 10 people on the project you probably don't want them in a single team so you split them to two teams. Now, starting from scratch, you'll want to put those 10 people into a meeting room for a couple of hours to come up with just enough of a plan for an architecture that will let the two teams proceed without too much overlapping.

[Ilja Preuss]

Originally posted by Mark Herschberg:

Thanks for all the advice.

You're welcome!

I'd be interested in hearing what you did and how it worked for you, if you find the time...

[Ilja Preuss]

Originally posted by Lasse Koskela:
Regarding architecture, Ken Schwaber suggests planning architecture up-front just enough to allow for scaling the number of teams you want to have.

Interesting - where can I read more?

In other words, if you have 10 people on the project you probably don't want them in a single team so you split them to two teams.

I guess you are speaking of 10 *developers*? Is that really too much for one team? Mhh, I guess it depends on whether you are pair programming...?

Now, starting from scratch, you'll want to put those 10 people into a meeting room for a couple of hours to come up with just enough of a plan for an architecture that will let the two teams proceed without too much overlapping.

Another strategy is to start with one smaller team and wait for "natural seams" to emerge in the architecture, than split the team at one of those seams and carefully grow the subteams.

Mark, how big *is* your team?

[Lasse Koskela]

Originally posted by Ilja Preuss:
Interesting - where can I read more?

I don't know, actually. This is coming from some private conversation with him some weeks or months ago.

Originally posted by Ilja Preuss:
Another strategy is to start with one smaller team and wait for "natural seams" to emerge in the architecture, than split the team at one of those seams and carefully grow the subteams.

Indeed, this is a very viable option. I'd say it's even the preferable option assuming that you don't have the typical situation of a BigCorp giving a project manager the full "headcount" starting from day one...

[Lasse Koskela]

Originally posted by Ilja Preuss:
I guess you are speaking of 10 *developers*? Is that really too much for one team? Mhh, I guess it depends on whether you are pair programming...?

Actually, I'd say that 5 pairs is already beyond the ideal team size in my mind. I'd much rather have something like 3 pairs per team.

[Ilja Preuss]

Originally posted by Lasse Koskela:

Actually, I'd say that 5 pairs is already beyond the ideal team size in my mind. I'd much rather have something like 3 pairs per team.

What happens, in your experience, beyond the 3 pairs boundary, that you would prefer to split teams? (I'm very much interested, because that's exactly the boundary our team will cross in the near future...)

Mark, sorry for hijacking your thread - perhaps we should spawn a new one...

[Mark Herschberg]

I don't mind the hijack.

My team is 6 developers (2 of whom start the day of the first planning meeting). There are are 2-3 product managers/graphic designers.

--Mark

[Scott Ambler]

As far as initial, up front modeling goes, you might want to read AMDD -- Initial Modeling. With Agile Model Driven Development (AMDD) you do some initial modeling up front to identify a potential architecture and the initial stack of requirements during "cycle 0". Then, during development iterations/cycles you model storm on a just in time (JIT) basis for a few minutes before coding for a few hours. As far as implementation goes, I suggest a Test Driven Development (TDD) approach, but don't insist on it.

- Scott

[Unnsse Khan]

Mark, Ilja, Lasse, and Scott:

Although the "core mechanism" of Scrum can be considered �agile project management�, Scrum is still a software development process, on absolute terms. In XP, the "iterations" are one to two week based intervals (although, Kent Beck told me that he prefers his iterations to be only for one week, because it enforces his philosophy of "accountability"), whereas in Scrum an iteration is called a "sprint" and is basically a month long period of development.

A Scrum project starts out with a "Product Backlog" which the ScrumMaster creates while working with customers.

Afterwards, there's a Spring Planning Meeting conducted, in which, the ScrumMaster and the developers spend 4 hours with the customer and come up with realistic estimates and help each others answer uncertain matters...

The next four hours consists of only the ScrumMaster and development team. They come up with a �Sprint Backlog� which entails how they are going to prioritize the requirements contained in the Product Backlog. At the end of this eight hour meeting, the first sprint has started and will end in 30 days.

Every day, developers and ScrumMaster hold 5 minute "Scrum stand up" meetings which entail 3 crucial questions:

1. What did you do yesterday?
2. What will you do today?
3. Are there any impediments in your way?

The purpose of the stand up meetings is to help with visibility (what are the projects� risks?) and for the collaborative power of other team members. Now, you can incorporate common XP practices (unit testing, continuous integration, pair programming, and refactoring) during development.

During the Sprints, developers draw graphics called �Release Burndown Charts�, in order, to track its Scrum project�s progress against a release plan, by updating this chart near the end of each Sprint.

At the end of the Sprint (the end of the estimated 30 day interval), the customers, ScrumMaster and development team will meet and conduct a �Spring Review Meeting�. This meeting covers the work product, to date, and unravels the remaining requirements to have the Sprint Planning Meeting (to produce Product and Sprint Backlogs, and kick off the start of the 2nd Sprint) for the second sprint.

So, my advice to you Mark, is to plan a Sprint Planning Meeting with the customer and developer and take it from there.

The benchmark software management application for Scrum is called VersionOne,
(see: http://www.versionone.com/scrum.asp ) and is web based. A colleague who works there told me, yesterday, that the beta for the new release is either out or is coming out.

I wish you success in your Scrum project!

[Ilja Preuss]

Originally posted by Unnsse Khan:
Although the "core mechanism" of Scrum can be considered �agile project management�, Scrum is still a software development process, on absolute terms.

Post that sentence to the Scrum mailing list, and you will get a lot of interesting replies...

In XP, the "iterations" are one to two week based intervals (although, Kent Beck told me that he prefers his iterations to be only for one week, because it enforces his philosophy of "accountability"), whereas in Scrum an iteration is called a "sprint" and is basically a month long period of development.

I prefer one week, too. And as far as I know, a lot of Scrum teams also prefer shorter iterations.

[a lot of good stuff about how Scrum works snipped]

As far as I can tell, we all know the basics of Scrum quite well. The question of this thread was: how much architecturing do you do at the start of a Scrum project? Do you have any input to that question?

[Unnsse Khan]

My input is that there is architect that belongs in the team and is intuitive enough to pick the closest frameworks (during the Sprint Planning Meeting), which might match the solution, and the development starts, right away. Agile processes encourage smaller releases and incremental builds. A lot of what the Agile philosophy encompasses is rapid application development and a way to embrace vague and quick requirements change. If a product is so complex that it needs a well thought out plan, before attack, I would recommend RUP or the traditional waterfall method.

"As far as I can tell, we all know the basics of Scrum quite well."

If this is the case, then why would you state that its not a software development process? Very contradictory statement. I chose to summarize the basics, in the previous posting, to exemplify why its not just geared towards "agile project management". Agile project management has a lot to do with it but Scrum does entail how to set up a software project from ground up and to keep it going in a way that is different than traditional software development approaches...

Cheers,

[Ilja Preuss]

Originally posted by Unnsse Khan:
My input is that there is architect that belongs in the team and is intuitive enough to pick the closest frameworks (during the Sprint Planning Meeting), which might match the solution, and the development starts, right away.

Mhh...

Agile processes encourage smaller releases and incremental builds. A lot of what the Agile philosophy encompasses is rapid application development and a way to embrace vague and quick requirements change.

Well, yes. So what you are saying is that the way "to embrace vague and quick requirements change" is to quickly pick an architecture up front and stick to it? I must be misunderstanding something...

If a product is so complex that it needs a well thought out plan, before attack, I would recommend RUP or the traditional waterfall method.

This sounds exactly backwards to me. The more complex a project, the harder is it to guess everything right up front, the more we benefit from early and frequent feedback from a running system. In my understanding, Agile development is *especially* applicable to *complex* projects.

"As far as I can tell, we all know the basics of Scrum quite well."

If this is the case, then why would you state that its not a software development process?

Because I remember having read exactly that on the Scrum mailing list several times, if I remember correctly even from Mike Beedle himself. I might be wrong, though. Anyway, that wasn't my main point - it was that Scrum doesn't say anything about how to come up with the architecture. Do you disagree?

Very contradictory statement.

"Do I contradict myself? Very well, then I contradict myself, I am large, I contain multitudes." - Walt Whitman

I chose to summarize the basics, in the previous posting, to exemplify why its not just geared towards "agile project management". Agile project management has a lot to do with it but Scrum does entail how to set up a software project from ground up and to keep it going in a way that is different than traditional software development approaches...

Frankly, I don't see what's specific to *software* development in what you wrote. See also http://tinyurl.com/cp6ll

[Ilja Preuss]

Originally posted by Unnsse Khan:
The benchmark software management application for Scrum is called VersionOne,
(see: http://www.versionone.com/scrum.asp ) and is web based. A colleague who works there told me, yesterday, that the beta for the new release is either out or is coming out.

I'd suggest to try using index cards instead for a while. You know, I'm quite obsessed with this "people and their interactions over processes and tools" idea...

[Lasse Koskela]

Originally posted by Ilja Preuss:
What happens, in your experience, beyond the 3 pairs boundary, that you would prefer to split teams? (I'm very much interested, because that's exactly the boundary our team will cross in the near future...)

I wouldn't call it a boundary per se because it's a highly artificial number coming from an approximation based on past experience. Having said that...

I've worked in teams of 2-5 developers where everyone has still remained intimate with what they're building as a team. I've also worked in teams of 2-10 developers where nobody has felt comfortable saying anything about any code other than what they've personally written. I've never worked in a project that has had more than 10 or so people in a team*. From this experience, and looking at how people almost naturally end up clustering into small cliques, I'd be wary of having too many "fish" (a developer or a pair of developers) in the bowl simply because it's easier for a team of 3 pairs or 3 developers to keep themselves from forming two clusters than it is when they are 4.


* = I have participated those 100+ developer projects which by definition have their own problems that are far worse than picking a slightly unoptimal team size...

[Unnsse Khan]

Well, I posted these questions on scrumdevelopment in Yahoo! Groups, and this is the response I got pertaining to "what time in the sprint should devote to
architecture?"

This is the response I got from one ScrumMaster:

"The architecture is emerging as the level of
agreement as to what is needed and the level of clarity as how to do it move
toward each other. Scrum, Agile, Xp, all work from the idea that what they
are doing will hang together until the next refactoring. Ergo a good idea
is defined as one that hangs in their until a better one appears"

"People who want a roadmap, should stay on the porch. Emergent environments
require people who can figure out how to get there and back."

I didn't author these comments so I can't speak for the author's behalf, by the way.

Ilja wrote: "Frankly, I don't see what's specific to *software* development in what you wrote."

I gave an overview of the activities that set forth a Scrum project and the how the Sprint is planned and executed. Isn't demoing the initial release in the Sprint Review Meeting an example of something that happens in software development? From what you made it sound, I was under the impression, that some sort of project is in place, and Scrum is just used to manage it in an Agile way.

What Mark was asking was where to devote the time to plan the architecture and my suggestion was to dive right in and just incrementally build on the releases...

BTW, I like your quote of Walt Whitman... Excellent response! I agree with you regarding the "people and their interactions over processes and tools" philosophy...

Kindest regards,

[Ilja Preuss]

Originally posted by Unnsse Khan:
Well, I posted these questions on scrumdevelopment in Yahoo! Groups

You beat me on this...

The thread starts here: http://groups.yahoo.com/group/scrumdevelopment/message/10473

"People who want a roadmap, should stay on the porch. Emergent environments
require people who can figure out how to get there and back."

Mhh, well, I think you *can* combine a very rough roadmap with letting the details emerge, but this might just be nitpicking...

I didn't author these comments so I can't speak for the author's behalf, by the way.

Understood.

Ilja wrote: "Frankly, I don't see what's specific to *software* development in what you wrote."

I gave an overview of the activities that set forth a Scrum project and the how the Sprint is planned and executed. Isn't demoing the initial release in the Sprint Review Meeting an example of something that happens in software development?

Yes - or rather something that *should* happen.

My point is that it isn't *specific* to *software* development, though - you can do exactly the same things when you want to design an innovative car or the next spaceship.

From what you made it sound, I was under the impression, that some sort of project is in place, and Scrum is just used to manage it in an Agile way.

I'm not sure I understand what you mean by a project being in place and Scrum "just" used to manage it. It doesn't seem to connect to anything I wanted to or would be likely to say.

What Mark was asking was where to devote the time to plan the architecture and my suggestion was to dive right in and just incrementally build on the releases...

Well, yes, that basically would be my advice, too - although I would probably spend a minimal amount of time up front evaluating the alternatives. The architecture can't emerge to a Spring architecture if you don't know Spring.

But I understand that this sounds (and probably *is*) risky if you don't have experience with doing it this way. In the end, a team must do what it feels comfortable doing. Hopefully that includes experimenting with new ideas in a controlled way, so that their comfort zone has a chance to widen.

BTW, I like your quote of Walt Whitman... Excellent response! I agree with you regarding the "people and their interactions over processes and tools" philosophy...

[Ilja Preuss]

Lasse, I wonder wether those "big" (~10 developers) teams where that big from the beginning.

Our team started fairly small and grows slowly, but steadily - around one to three new team members a year. I suspect that this way the team might have a chance to incorporate new members without building too much of cliques. Well, we will see what happens...

[Lasse Koskela]

Originally posted by Ilja Preuss:
Lasse, I wonder wether those "big" (~10 developers) teams where that big from the beginning.

Mostly yes. "This one's a rather big project. We'll need... mhh... 10 developers! Let's write it down. Next week, when the project starts, we'll have 10 developers."

[Mark Herschberg]

A few comments...

Ilja is right, Scrum is not software specific. In fact in "Agile Project Management with Scrum" Ken makes a reference to a marketing project using Scrum. Fundamnetally Scrum is about prioritizing tasks, short daily meetings, and an emphasis on just-in-time documentation/communication.

RUP on the other hand, while in theory can also be applied to oher projects, it is more related to software, as many of the articfacts, roles, etc are software specific.



We're using XPlanner. It seems like a pretty good, open source tool. It does look like excel does 80/20 of what you need... backlog, prioritization, and burndown. XPlanner just mkes it easier to have automated charts and similar things that look flashy to upper management.



The challenges I face are: new team, new process, new technologies, new ype of product (as opposed to smething like email on your cell phone which people can understand). I had the team play around with technologies the past few weeks, basically giving them "free time" for research. I suppose you can use Scrum, the "Iteration 0" idea, although with true R&D (not just picking technologies, but real near science level R&D), it's very difficult to estimate, plan and prioritzie tasks, and communicate progress.



In terms of team size, when I teach people and companies about methodologies, I usethe term "inflection point." For example, you can put 2-3 developers in a room together and they don't need much process. When questions arise, they turn around in their chairs and talk to each other. You don't need much formally or things written down. There's an inflection point around 8 people where that model breaks down. One guy turns around in his chair to talk to another, and a person on the other side of the room should have been involved and wasn't. At this stage you need add a little more formality to the process to insure proper communication. Other inflection points exist around 16-20 people, 40 people, and 100 people. Where exactly you hit the inflection point depends partly on the process and software being developed. Whether Scrum hits and inflection point at 6, 8, or 10 people, depends on individual or pair programming (since that roughly cuts the communication by 2 in meetings) as well as the amout of interdependence between the different parts of the software being developed.


--Mark

[Ilja Preuss]

Originally posted by Mark Herschberg:
We're using XPlanner. It seems like a pretty good, open source tool. It does look like excel does 80/20 of what you need... backlog, prioritization, and burndown. XPlanner just mkes it easier to have automated charts and similar things that look flashy to upper management.

XPlanner is OK. It's nice for tracking actual times worked on a task. And it's nice that it's open source (and the code isn't too bad) - it's rather easy to expand it. We already contributed some minor enhancements over the years, and have written a small CSV export, so that management can import an iteration into Excel and do with the data whatever management does.

We also noticed some "flaws", though - it didn't work well for the actual *planning*. Since we also introduced index cards into the mix, it works *much* better (I think I recently already wrote about this in MO...)

We also have a handdrawn burn up chart on the wall - again, having it handdrawn seems to work better than something automatically generated. Of course it's also much bigger and more visible than something on a website. It's intent is not to look nice to management, but to actually make the data visible to everyone, though.

The challenges I face are: new team, new process, new technologies, new ype of product (as opposed to smething like email on your cell phone which people can understand).

Yes, that sounds kinda risky. I wonder whether it would make sense to try to give them some things that they feel familiar with, and to introduce some of the new things only later in development.

I had the team play around with technologies the past few weeks, basically giving them "free time" for research. I suppose you can use Scrum, the "Iteration 0" idea, although with true R&D (not just picking technologies, but real near science level R&D), it's very difficult to estimate, plan and prioritzie tasks, and communicate progress.

I guess your iteration goals need to be very high level, along the lines of "reduce time needed to do task X by 50%" or "send a capsule with a dog inside into space and return it to earth with the dog being alive". Communicating progress on tasks doesn't sound that important to me, as you will likely have to change your tasks mid-iteration anyway, but progress on the iteration goal will probably be vital.

If you have problems with tracking tasks, I'd also think about reducing the size of the iterations, so that the iteration goals can be smaller and you regain some of the control over progress.

In terms of team size, when I teach people and companies about methodologies, I usethe term "inflection point."

This sounds very similar to the way Cockburn divided his Crystal family of processes: one dimension he uses is team size. He also uses "inflection points" of 7, 20, 40 and 100 (continueing with 200, 500 and 1000).

Where exactly you hit the inflection point depends partly on the process and software being developed. Whether Scrum hits and inflection point at 6, 8, or 10 people, depends on individual or pair programming (since that roughly cuts the communication by 2 in meetings) as well as the amout of interdependence between the different parts of the software being developed.[/QB]

I wonder wether Scrum, with its daily scrum meeting, already deals with the first inflection point appropriately.

[Mark Herschberg]

I bought 3x5 cards because of your other post suggesting to have something physical. The product owner is actually creating powerpoint slides, and will print htem out two per page and cut them up. I mentioned the concept of the small size of the cards so you don't get too detailed and he was fine with that--a powerpoint slide generally doesn't get more detailed than what you can get on a 3x5 card anyway. So we'll play with that in the meeting and then transfer it to XPlanner as the sprint backlog for each iteration.

I agree that this is fairly risky given all the variables. However, we also have a working prototype abeit different technology and not scalable), a lack of people on the product management side to write specifications, and a deadline to rewrite the existing simple product in 6 weeks. Traditional methodology with specification emphasis won't work because we're currently understaffed. Thankfully we have an existing prototype to help compensate. I partly choose the process because of the just-in-time specification writing and it gives engineers the directive of "get something done even if not perfect" while management and the product management groups knows that if they don't like it, it can change in a month. Another important consideration is that is isn't just a new product, it's a new concept and industry. We don't really know how it will be used in 2 months, let along 6 or 12. We can't even predict which features will be a priority in 3-6 months. The product must be very flexibile and will change rapidly.


--Mark

[Ilja Preuss]

Originally posted by Mark Herschberg:
I bought 3x5 cards because of your other post suggesting to have something physical. The product owner is actually creating powerpoint slides, and will print htem out two per page and cut them up. I mentioned the concept of the small size of the cards so you don't get too detailed and he was fine with that--a powerpoint slide generally doesn't get more detailed than what you can get on a 3x5 card anyway. So we'll play with that in the meeting and then transfer it to XPlanner as the sprint backlog for each iteration.

Sounds good to me!

The product must be very flexibile and will change rapidly.

I hope your team is used to refactoring?

Do you plan to write automated system tests?

This sounds exciting - keep us updated! I guess you can't tell us more about the what the project is about...?

[Mark Herschberg]

Yes to refactoring.

Yes to automated test systems. Right now JUnit and Cactus. I am also going to investigate tools for our QA team to use like Mercury, Silk, etc.

You can check out the prototype at root.net. You'll also need to down load the Attention Extension. Remember that is this a prototype which is currently getting overloaded by highed adoption than expected. The next version should be much better, performance wise, visually, user experience, etc.

--Mark

[Ilja Preuss]

Originally posted by Mark Herschberg:
Yes to refactoring.

Yes to automated test systems. Right now JUnit and Cactus. I am also going to investigate tools for our QA team to use like Mercury, Silk, etc.

Way to go!

You can check out the prototype at root.net.

Mhh, not really my world...

Nevertheless, some feedback: the first two things I tried to find out more was to click on "first open market" and "trusted participation". Once that failed, I really wasn't sure how else to get more info on how this whole thing works.

[Mark Herschberg]

Apparently our database crashed last night. The place we're renting servers from didn't notify us (despite the SLA)! I am not very happy with them.

--Mark

[Ilja Preuss]

Just to clarify: with "once that failed" I meant that apparently the text, although shown highlighted, wasn't a link at all.

[Stan James]

I keep seeing this on the forum list:

How does Scrum work on a... and think the rest must say a really tough stain? Am I watching too many TV commercials?