7

Kanban absolutely sounds like the right solution for you. I'm just not sure what you describe that you are doing is Kanban in the common definition. Having a task board, with work phases does not make it Kanban. One thing I hear you saying is that requirements can change from when you start to when you finish. This is telling me that your cycle time, from ...


6

thank you for this hard question. My answer is two-fold. First about your belief ("I believe, that they can't start work together without preliminary coordination."): Remember principle 11 behind the agile manifesto. Those amazingly senior guys who had worked on huge projects for large enterprises agreeing on: "The best architectures, requirements, and ...


2

You need three values to forecast a cost: Speed of the team, estimate from the team and the cost of the team. Leading to a formula like this: FeatureStoryPoints * (TeamCost / AverageVelocity) = Estimated Price AverageVelocity: For speed you could take the average velocity (yesterday's weather) of a team. Do calculate capacity and normalize the velocity ...


1

From Add or edit enterprise custom fields in Project Server: To add a field to the formula, click Pick field, point to a field type, and then click the name of the field that you want to reference. To reference an existing Enterprise Custom Field, point to a field type, point again to a custom field type (such as Custom Date or Custom Finish), and then click ...


1

Lately the cases that I see are usually the other way around - building web (and mobile web) to catch up to the mobile apps :) But to answer your question - it is possible to have a scrum team of mobile + web + backend working within a certain domain with the PO responsible for that domain - be it identity management, payments, online chat, whatever. This ...


1

How much work should you do up front? Well, as much as you need and no more of course. What I find works well on large teams is to just get started. You should get enough backlog ready for the teams to start their first Sprint. Bare in mind that they will not deliver a lot as the basic infrastructure and understanding is not in place. The hardest part will ...


1

The answer is simple: architecture should be defined BEFORE build, regardless if it is scrum, waterfall, etc. doesn't really matter if you define just a portion of architecture to support only the first sprint. Simple fact of life: Architecture comes BEFORE build. In future sprints you can scrap/adjust/enhance/redefine/whatever the bare minimum ...


1

What is it you aim to gain from an answer? What is your role in which any understanding of this matter is relevant? Whether an individual or an organization follows either perspective (or even yet another) of the ones you described is most likely dependent on one of the following: Individual interests "Business" usually leads the charge when there is a ...


1

I know nothing from transportation vertical industry, but regarding something industry independent and applicable for HW, SW, and embedded systems, the V-Model could be something to start with: http://en.m.wikipedia.org/wiki/V-Model. Here is a link to the complete description in English: ftp://ftp.heise.de/pub/ix/ix_listings/projektmanagement/vmodell/V-...


Only top voted, non community-wiki answers of a minimum length are eligible