Download Score: 1 is best Refs: how many distinct relevant places you

Score: 1 is best
Refs: how many distinct relevant places you explicitly cited, including text and class slides
ID
Score Org
Refs
Notes
strengths
2044156
2440447
2480334
2483770
2484797
2
3
2
4
4
weaknesses
ok
problems: large team + novel
platform + slow information spread
+ final tasks too large + too little
refactoring along the way +
wholesale one-person refactoring +
no TDD + no retrospectives or
iteration planning; successes:
project finished, value delivered
4 every iteration,
so so
problems identified: bus factor +
fixed pairs + mixed dev envs + no
weekly demos + large tasks + no
vision + dropbox for source control
+ no daily standup + slow client
response + single client point of
contact; very short "how we fixed
2 things"
good long list of issues
too much narrative; many
problems lumped into one section;
analysis not drilled, e.g., 5 whys,
nor linked to the literature
problems identified: user stories +
backlog not updated + empty
iteration backlog + missed
requirement; successes: jelled
team + freq meetings + swarming +
6 good slice size;
5 whys on missed requirement
organization by random topic
(team, user stories) rather than
problem or practice; inadequate
fixes for 5 whys (for "we didn't
refactor" just "we should refactor;"
for "didn't ask questions" just "ask
more questions"); misunderstood
"technical debt" as monetary;
seems to conflate unit testing with
user testing; not clear why this
project had just one deadline or
why that means unit tests less
necessary; several references to
being just a "class" project;
so so
none
problems: team size + task
1 management
so so
problems: complicated mvp +
learning curve + overdependence
on one team member + no team
ownership + poor intra-team
communication + client
communication + poor iteration
implementation + poor use of
0 backlogs +
solns done and proposed: mailing list,
small meetings, more detailed
planning, wiki for documentation;
one-level causal analysis, overly
good links to the literature
narrative;
specific fixes to each
problem;interesting ties to service
design;
no organization into sections;
more narrative of what happened
than analysis; no root cause
analysis of problems so fixes
random and not backed up with
arguments; no connection to the
literature;
good (if rambling) description of
client vision issues
no causally-based fixes for client
issues; reads more like a list of
excuses for why the project was
hard instead of features of the
project that needed to be
accomodated; no connections to
the literature, not even book
references!
ID
2488594
2503052
2503324
2508792
Score
2
3
1
4
Org
Refs
Notes
strengths
weaknesses
ok
problems: not all teams had
platform working + bus factor +
scope creep + no user testing + no
unit or integration testing + missed
requirement ; solns: value every
5 whys on scope creep; missing
week, frequent communication,
requirement solution (multiple
3 communicate fears,
scenarios) is OK
ok
more intuitions than analysis; 5
whys analyses not tied to multiple
layers of response; little discussion
of pros and cons of solutions
proposed (many of which are more
aspirations than actions); there are
better links to literature for
technical debt, overzealous
refactoring, overachievers, etc; too
problems: communication + large
simplistic to say a course with
team + members missing meetings solns proposed: google docs,
students is that different than a
+ losing steam + little pride in
taskboard, several 5 why's analyses real project with distributed
project + one person taking over + (though not highlighted as such); links developers, including new hires, on
5 not everyone met client +
to literature (not always the best)
multiple projects
good
problems: tech platform issues +
no tdd + code breakage before
demo + communicating effectively
with team as client + maintaining
client engagement ; successes:
learning from tech issues, using
spike to test authentication
alternatives early, frequent
3 deployment to target platform,
good
problems: losing team members +
late user scenarios + inadequate
testing + no refactoring + poor
intra-team communication + poor
1 task management
good use of book;
very good 5 whys on tech platform
issues, with good proportional fixes;
good identification of specific bugs
tdd might have caught faster;
rambled a bit when bringing in
prior experience; no layers of fixes
for scope creep; limited use of
literature
little use of literature beyond class
materials (book and slides)
only book referenced; more
narrative than analysis; no analysis
of late user scenario problem
causes and possible fixes
(ultimately, the fault is on both
sides); no specific causally-based
(e,g., 5 whys)l fixes for testing,
refactoring or team
communication issues beyond
"should do better"
ID
2508926
2509574
Score
2
4
Org
Refs
Notes
strengths
weaknesses
ok
causal analysis stopped after 1 or 2
levels; sometimes focused on
debating a practice, e.g.,
swarming, when the point is )
rather than analyzing and fixing an
actual team issue; seems to claim
that 2 subteams would have a bus
factor problem and that the
recommended cure for low bus
factor is maximum redundancy all
the time; didn't use the literature
on subteams in large projects;
recommended unit testing but
didn't address causes of why it
problems: large team size +
didn't happen (CI only helps run
inadequate communication of
tests if tests exist); little
specifications + scheduling
recognized that practices, like daily
connection to the much larger
meetings + poor prioritization +
standup, aren't the point--what they software development literature,
inadequate test suite + inequal
try to accomplish is what must be
just Rasmussen and Brooks
experience + technical debt + poor replicated; recognized that "better
(briefly) -- Shannon reference is
2 use of pairing
leadership" is not easily achieved;
analogical at best
so so
problems: large team in demo
project + understanding primary
client goal + missed key
requirement + platform learning
curve + no refactoring + little
testing; successes: cross-functional
team + use of source control +
swarming + jelled team + engaged
client + frequent commits and
1 delivery of value
problems: using source control
effectively + late deployment
testing + platform issues +
midpoint attendance problems +
midpoint intra-team
communication + late client
breakage + late scope creep;
successes: swarming + jelling + high
bus factor + inception deck +
6 focused MVP + low technical debt
text rambles and is more narrative
than structured analysis, e.g., no
explicit root cause analyses; fix for
honest look at weaknesses in fix to
missing requirement (cover every
code merge conflicts; good pondering possible scenario) not feasible; no
about possible issues in agile project reference to literature beyond
closure
book
2529566
1
so so
2532239
2
so so
interesting discussion on inception
deck; very good 5 whys on source
control failures, client
organization by random topics;
communication issues and late scope good analysis buried in long
creep;
narrative chunks
just a few main sections
(communication, server); overly
problems: communication + bus
narrative in sections, e.g.,
factor + stalling + lack of reflection; good (if rambling) analyses of
differences of opinion on
successes: email for
problems and possible fixes; good use communication, problems with
communication + swarming
of Cottmeyer reference; good
game server; references not easy
2 sessions with rotating members;
discussion of agile for class projects; to find at a glance;
fine
problems: low productivity + novel
platform + scheduling meetings +
low bus factor + too few devs
meeting client + varying skill levels
+ more skilled take over + eroding
morale; solns: regular meeting
times, small group swarms, wiki
well organized; articulate but one1 docs,
level analysis
2542682
3
more narrative than analysis; no 5
whys or layers of fixes; little
connection to the literature
ID
2549361
2551448
2553978
2557016
2559949
2561638
2584968
2617186
Score
1
1
3
3
1
3
2
3
Org
very
good
Refs
Notes
strengths
problems: source control + large
size + organization + client
communication + bus factor +
technical debt + no refactoring +
4 user value not always created +
so so
5 problem-based sections; 5 whys in
each
good mixing of issues then fixes;
problems identified: learning curve connected fixed pairs to being cross+ fixed pairs + large tasks + silos + functional; 5 whys analysis on
mixed client vision + slow client
integration failure, with possible fixes
response + bus factor + vague
at each level; good use of Cohn
4 tracking + broken source control
reference;
so so
problems: large team + team
ownership + lack of jelling +
learning curve + silos + meeting
attendance and communication +
task tracking + bystander effect;
2 successes: client communication
weaknesses
some fixes just "don't do that" or
"make sure that …" -- those aren't
fixes; used "large" bus factor to
mean a small one, i.e., 1;
"lack of training" is more a cause
of problems than a problem; a
problem is something bad that
happens, like buggy or late code
some good fixes considered for the
large team size issue;
"fixes" for learning curve not really
fixes (don't do project not really an
option in general, and help each
other more doesn't address the
causes for why this didn't happen)
good
2 5 whys analysis with fixes;
problems identified: no client value sectioned by problem; well+ large slices + learning curve + bus articulated concerns about agile for
1 factor
beginners in a course
1st fix for first 5 whys (replace
"learn X" tasks with "do specific
tutorial X") doesn't address lack of
client value; seems to say planning
poker identifies features to build
(it doesn't); seems to conflate "no
value" with "didn't work when
deployed;" no links to the
literature
good
5 whys on no early value, with
problems: no early value + no
reasonable proposed fixes; 5 whys on
backlog + poor team
meeting issues and reasonable fixes; overly narrative; 5 whys buried in
5 communication + too few meetings very good use of the literature;
narrative text;
ok
5 whys on scheduling problem
gets hung up on just one factor
(engagement); only that aspect
problems: team meeting
fixed; with source control, lack of 5
scheduling + conflicting changes in
whys means how the fixes for
source control + weak testing +
layers of defense not explicit; no
poor story writing and
5 whys on scheduling problem starts specific fix for client
management + inadequate
well; good multi-layer fixes for source communication problem; no
communication with client + too
control problem; good connections to connection to the literature other
1 much bugs accumulated
book
than book
ok
problems: broken code + no tdd +
4 technical debt +
so so
problems identified: bus factor +
5 whys analysis on big slices; good
too experienced a team member + analysis of problems, ok hypotheses
9 untracked velocity
on fixes
3 5 whys;
2nd 5 why causals not linear (3rd
row didn't cause 2nd); root cause
too often "we were still learning;"
fixes for 2nd 5 whys mostly "do
better;" 2nd and 3rd 5 why fixes
about what they did rather than
what they changed in process;
too focused on just bus factor -even blamed large slices on it; all
projects have many problems
ID
2646877
2679230
2695649
2696988
Score
2
3
2
1
Org
Refs
so so
Notes
strengths
problems: github learning curve +
client tech platform constraints + ;
successes: using branching in
github, inception deck,
communication with client,
swarming, feature-driven
development, frequent value
3 delivery
ok 5 whys on tech platform conflicts;
weaknesses
weak
problems: demo breakage + done
didn't equal tested and deployed + good use of literature; reasonable
integration failure + bus factor;
question about short iterations
4 successes: 5 whys + iterations
leading to shortcuts;
sections organized by random
topics (github, inception deck)
rather than issues; says there was
a 5 whys on github issues but none
given; 5 whys on tech platform
conflicts better but could've been
laid out more clearly;
more narrative than analysis;
claims 5 whys used on demo
failure and elsewere but doesn't
present any; says large bus factor
is bad when it's small that's bad,
e.g., 1
ok
problems: team turnover + learning
curve + bus factor + poor task
5 whys for each problem; specific
prioritization + inadequate client
process changes for team cohesion
3 interaction + no tdd or ci;
problem;
5 whys causes often subjective
feelings, not specific actions or
conditions; 5 whys for learning
curve went to parallel causes than
to linear chains; no real specific
fixes for learning curve problem; 5
whys for task prioritization lost
sight of asking real questions and
became a laundry list of random
factors; fixes basically just "do
better"; no analysis or fixes for tdd
problem
ok
poor fixes for 5 whys -- "changes
must be communicated" is a
requirement, not an action; "this
was the actual reason" isn't a fix at
problems: db broken by client +
all; fixes should be process
bad communication on updates +
changes, e.g., "when x is present,
risk from little testing at scale + ;
do y," not "must" or "should
successes: using branches in git
haves;" a "all X must be Y" fix is
appropriately, deployment
hardly ever implementable or
documentation was easy (tested on good connections to the literature,
sustainable; some literature
client though?), cross-functional
book and class slides, e.g., Fowler on connections unmotivated by
7 high bus factor, good team trust, db evolution 2 5 whys analysis;
project experiences;