Post-Mortem

From ZenWiki

Notes

• Look for key points on poster

• Rules for SEI technical report
  • May need to submit a SEI document plan
    • Look for old document plan from communications
    • Talk to Felix to see if we have to do it

• First week of program
  • Customer Pitch
  • Submitted choices
  • Formed into team
  • What was idea of what we'd build?
    • Allen: Goal: Build best interview tool ever
    • Marc: Grace had strong vision, hasn't changed over a year
    • Somakala: Grace had strong vision, Felix's Arch-Centric approach was what attracted her to it
    • Session: Vision was clear, devil was in the details; his experience didn't map to the dev environment; he was attracted to it because it was SEI; didn't like "Google fan club", DOD system, other systems; Additionally, he thought it would be more straightforward; not so many pieces to it
    • Sajjad: Grace's vision remained unchanged over the year and given its strength, we had a clear idea of what to build i.e. a fine interviewing tool.

• Open Source
  • Why
    • Did experiments, did QAW, Grace said she wanted mysql, Grace said no money for other products
    • Grace said they want to transition to industry, so product had to be modifiable, extensible, standardized
    • Scope caused us to have to use Off The Shelf stuff

• At what point did we start to make informed choices?
  • Experiments in spring were designed to answer these questions
  • Ready to do it in fall
  • Grace's vision and our constant meetings

• Customer was good?
  • She was a asset
  • Strong vision
  • Regular contact
  • good communication
  • High level requirements + experiments + feedback + clear vision = good results
  • Having a smart customer is a disadvantage in some cases

• Poster piece
  • Clear communication and strategy with customer worked for us
  • What did we do to take advantage of the customer?

• Is having Grace (former MSE) as customer good or bad?
  • Very helpful

• How did we know when to rethink/when things going wrong?
  • Very blunt
  • Had mentors train us (had to ask for it)
  • On at least one occasion, things went wrong and we did not know when to rethink until it was too late

• Session: Would have helped to go into more detail in spring
  • Somakala: by spending 12 hours/week on studio, we had to make tradeoffs
    • Grace wanted arch in a certain way

• Allen: Phil is saying in mentor meetings that "we keep telling you to do X but you fail to do it"
  • Finding areas of uncertainty early would have been helpful

• Somakala: We focused on the client to eliminate uncertainty which helped, bad for server
  • Prioritized well, in identifying the client is important
  • Phil was worried about prioritization, but wasn't really horrible

• Our work on the client established trust with Grace, so that she's not worried about the server
  • Makes a world of difference when you can do this

• I think with 92% estimation accuracy, maybe we pushed on details enough

• Optimism: maybe there's too much optimism?
  • Somakala: more of a skeptic
  • Marc: Shocked
  • Sajjad: Really shocked

• 3 things went wrong
  • Client Communication
  • Data access layer/general work of Sajjad
    • Sajjad: Unfortunately, no one (including mentors) never really brought this up until the end. Like most projects that do not meet their original expectations, Sajjad (at least as one can elicit from this discussion) was used as the primary source of all the troubles. Major issues (especially those relating to the server) have really been overshadowed by this.
    • Additionally, there was a component called "SERVER CONSOLIDATION" for which separate estimation was done (and was originally allocated to Somakala) -- however, when she re-scoped half way through the semester, this component disappeared and its resources (time etc) were not added to the data access layer components which ended up doing the consolidation on the server. This is a major point to ponder and a thing that went wrong.
  • Ajax inexperience

• Allen's level of quality
  • Good for getting the project out with quality
  • What happens when we change stuff at the 11th hour when Allen finds a better standard?
    • Session: Goes back to finding the low level detail earlier
    • Whenever we switched it was hard, but was a good learning experience
    • Allen: Architecture can evolve
    • Somakala: When do you stop driving to details? You can't go too far
  • He liked doing it, he likes getting things in right
  • Putting quality into code is hard because you have to change the way things are done

• Marc: should have forced Sajjad to follow the dev process
  • However, wasn't this really approved by the lead and by the rest of the team very early on in the semester? Was this a bad team decision that at the end looks as if it was really an individual decision? These are points to ponder.

• Session: wanted to follow the dev process but had difficulty doing so
• Sajjad originally wanted to follow the process, but after getting approval from the lead and the rest of the team very early on in the project, went with the staged type of approach that I followed.

• Good cohesion with 4
  • Maybe not so much with 5?
  • Sajjad: I am not sure if this was really the case (at least never throughout the semesters was this felt by me).

• Poster idea: Quality process (also maybe in TR)

• for the most part, integration went very smooth

• TR: QA process helped

• Session: Allen's personality lent himself well to his role as QA manager

• Somakala: disappointed in Sajjad because he was insisted that he work on the DB
  • Sajjad: At that point, this seemed to be the best decision (not only to me, but probably to everyone in the team) -- however, as time went on, things rightly did not flow as expected -- however, this is similar to you taking 4 or 5 components, and re-scoping half way through; I do not think that I can say today that I am disappointed from Somakala because she originally insisted on doing 4-5 components and half way through, these were allocated to Session (and she officially worked on only one component). I think this is evolution and yet another reason for understanding that things are not always perfect. Similarly, there was a component called "SERVER CONSOLIDATION" for which separate estimation was done (and was originally allocated to Somakala) -- however, when she re-scoped half way through the semester, this component disappeared and its resources (time etc) were not added to the data access layer components which ended up doing the consolidation on the server. This is a major point to ponder and a thing that went wrong - however, I do not think that blaming any one person for this oversight is the right thing to do.

• Warning Signs for Sajjad?
  • Marc: didn't get anything until 2.5 semesters in
    • Sajjad: If this really was the case, don't you think bringing this thing up 2 semesters ago would have been the right thing to do? If this wasn't done, do you think this is really true?
  • Session: Disappointed because Sajjad seemed open to learning, but ultimately he didn't change based on suggestions
    • The reason why I didn't wanted to change midstream was driven by the idea that if I change now, the project will be delayed. I think partly, this is the reason why the project finished with only a one week overshoot (and that too primarily from the server front and middle-tier)
  • Session: It was really hard to do debugging with him, hard to focus
    • Sajjad: If everything on the server (including integration and development) is done/pushed in the last 1.5 weeks, this I think is not a rare occurrence. Regardless, I think I did the best that I could do given that I was working on my components at the same time and was rushing equally for the deadline (with two very heavy components).
  • Marc: got input from mentors, ignored
    • I think more specifics need to be added here.
  • Allen: Very hard to push quality into someone; didn't work
  • Session: Learning experience; we didn't know, couldn't tell
  • Somakala: Wanted to accept his word, trust him
  • Marc: Recognized that he didn't place the same level of importance
    • Sajjad: If this really was the case, as the team lead don't you think this should have been discussed individually or as a team early-on? If this really is true, shouldn't we have had some sort of process to tackle team issues like this?

• Poster idea: Team dynamics
  • Roles
  • Respect
  • Dynamics

• Session: Other team had an issue; they recognized it early; didn't think we had the same problem
  • They realized it early on and worked around it

• What decision had the most positive impact?
  • Doing the QAW
  • Deciding to communicate better with the mentors
  • Giving the right people the right jobs
  • Fall & Spring role choices
  • Common working hours

• Bad turning points
  • Dealing with data access layer/sajjad
    • Sajjad: Dealing with data access layer proved to be difficult and understandly so due to lack of detailed design in the begining. However, despite this fact, it is both sad and disappointing that this has been made more of a personal/individual issue (e.g. dealing with sajjad) as opposed to a technical issue.
    • Data access layer eventually evolved into a logic & data access layer. As an example, there was a component called "SERVER CONSOLIDATION" for which separate estimation was done (and was originally allocated to Somakala) -- however, when she re-scoped half way through the semester, this component disappeared and its resources (time etc) were not added to the data access layer components which ended up doing the consolidation on the server. This is a major point to ponder and a thing that went wrong.

• Poster point:
  • Important roles/semester

• Somakala: Working around differences worked very well
  • Sajjad: If this true (and I think mostly it was), why were the difference pointed above not worked around? I think this is a key reflection.
• Marc: Identified it early, found the common goal

• What was the worst decision that we made?
  • Marc: no sleep before eosp?
  • Session: procrastinating
  • Allen: maybe doing the process differently with use cases?
  • Sajjad: Not doing detailed design early on.

• Allen: The point of the program is not to crank stuff out; it's to make good software

• Somakala: We had fun during the summer; it's a good indication of how well we set ourselves up; also she survived the 12 month thing

• Did process get in the way?
  • Session: generally worked, but this is a 1-shot deal; cannot evolve
  • Marc: process worked due to tailoring; proposals didn't work because we didn't write them
  • Allen: Process worked well, but how do we know if it works well in general?
  • Marc: process works great because of the context-clear vision, good communication with client, lots of feedback
  • Sajjad: The process was really good, but being allowed by the team to tailor it to the way I was working proved to be a not-so-good decision - it felt the best decision at that time, but as a reflection - maybe it wasn't. Again better decision making, more communication and cooperaiton would have helped.

• Architecture Centric Development
  • Best
    • Once we started to work on architecture, it really flowed
    • Helps you focus on design, fix problems earlier on in the process
    • Gives you a map to get where you are going
  • Worst
    • We didn't understand what he wanted
    • Too much going on to really learn what he taught it
    • Can miss some things (like the server), also the functional requirements & business drivers
    • Its important to do detailed design in order to get the maximum returns from this approach. If this is not done early enough (like in our case), the key benefits from Architecture centric development are not achieved.
  • Use it again?
    • Somakala: Yes
    • Marc: Yes, thanks to the training
    • Allen: Yes
    • Session: Yes
    • Sajjad: Yes

• TR content
  • Day in the life of developing using arch. centric process?
  • Does using this approach minimize "bozo factor"/people issues or make it worse?

• Poster content
  • What would we do diff
    • Allen: Requirements, more detail
    • Session: More detail
    • Marc: ask for demonstration/proof
    • Somakala: Reassign work/shifted roles as needed
    • Sajjad: More detail; especially doing detailed design after completing architectural design.

• If the team was only 4, what would have happened?
  • Marc/Somakala: rescoping, but would have delivered
  • Session: with 5, she's getting everything + nice to haves with only a 1 week slip, so should make customer happy; also based on trust
  • Somakala: Grace wouldn't be happy until she gets everything she wants

• What 1 thing will you take away?
  • Allen: Estimation is important; quality of milestones are not well defined; defining quality levels would be a great take away
  • Marc: How to make your customer happy: give them what they want at the level of quality they want
  • Session: When you build a reputation, that will drive you and carry you throughout your career; Understand your customer's values and manage them actively
  • Somakala: Agree with Allen
  • Sajjad: Same as Allen. Also, when some one is absent (especially at the end), it is easy to use him/her as a scape goat for anything that doesn't end up perfectly -- this is a universal fact and one should keep this in mind.

• When estimating, we added time for quality, very important

• 1 line, 1 piece of advice to the incoming class (put on poster)
  • Marc: If you are committed, you will succeed; if you manage to come through it, you will be the better for it
  • Somakala: Interact more with team members, find out where they're coming from, learn to interact with your team, learn to understand your team; stick to your goals; hang in there
  • Allen: Always try to learn something from others; if you commit more, you will learn more
  • Session: Murphy is out there; don't let people tell you that you can't
  • Sajjad: Learn from others; however, if you have a concern regarding something tell everyone where your opinion is coming from (and why?) sometimes you are right, while at other times you are wrong -- both cases lead to better learning (and ultimately, to a better decision)