Agile Development Process Un-conference Session notes

Here is the ND agile process.pdf - Here is the link to the 7 slides used in the presentation.

Agile Development Process Un-conference Session 2014-10-02
Chris DeLuca from Notre Dame leading/presenting.

We didn't have pre-designated note takers but Mchael & Ian happened to take notes that do not claim to be comprehensive.
----
Michael Daul's notes
----
- a person is assigned as ‘batman’ who spends 25-50% of time ready to fix production problems

- for serious problems, bat man can go to work for a day or two to fix the problem

(a method to not slow down product delivery)

- “story triage” - spend an hour or two, read stories from backlog, fill in missing details (technical requirements, etc). Only project leads work on this. Helpful to have customers as well. Can be taken in any order.
Do it every two weeks.

>> how do they identify which stories need fleshing out?

- identifying tests (test-case creation)

- code review (developers & QA people)

- deploy to staging, do manual testing

- demo to stakeholders

- retrospective > meet with team at end of sprint (every two weeks or whatever) >> what worked, what didn’t, etc. What new things we want to try. Take a team temperature > how each person feels about how the sprint went.

- use a virtual sticky board for distributed team members

- circle back around into sprint planning

- Story writing:
as a xxx when I yyyI want zzzto happen

- more requirements the better >> put as much in the stories as is possible

- daily standup meeting:
yesterday, today, any blockers

- adhere to retros >> it’s important to think about changing things
- don’t try to change everyhting at once >> small tweaks!!
- you can always try something for one sprint

- moved standup to email, now spend standup talking about big issues >> do we need to focus on anything important, etc.

- pull request model / pair programming >> it’s very important to have two sets of eyes!!

- inviting people to attend meetings is an empowering experience >> helps people understand how long it takes to do things

- finding the level of effort >> “points” = hours (they use 1-5, if it’s a 5, they need to break it down. 1 point = 6 hours = 1 day) They want nothing larger than 3

- rotate faciliatation of steps? Make sure the retrospective happens

- Somebody has to do QA >> shouldn’t be the person who did the work!!
- get conversations going “I think I did the test case right, but it’s not working…”

- don’t point fingers, just fix it! It’s about the users!

- unclear responsibilities are an issue!!
- someone’s job is making sure the process is correct!

- “certified scrum master!”

- for giant new projects, it’s worth spending several weeks planning out the suer stories
- get together in a room >> talk about what’s necessary for ‘go live’

- “velocity” >> how much you can get done in a sprint (17-22 points)

- “planning poker” >> go around the room, estimate how long it takes to do something (in points) >> talk through discrepancies
- helps identify pain points, do ‘horse trading” for desired features - helps devs feel comfortable with work load
- gives credibility!!

- typical story is one actionable thing >> can create sub tasks, but that might not work for all

- stories can start out pretty large >> might decompose it along the way (talk to developers about how to do so)
----
Ian's Notes:
Agile Process- Chris DeLuca from Notre Dame leading/presenting.
Agile: epeatable process where unknows have minimal impact on product delivery.
Notre Dame has 1 person - the Bat Man - who only has 25% of their time devoted to the software develoment effort.
Story Triage and flesh out done by product and technical leads. They also fill out acceptance criteria. Done every two weeks.
Then they create Tests. TCC - Test Case Creation.
Story creation: as a user of this type I want this functionality, so that.....
Daily stand up: what yesterday, what today, what is blocking.
Don't try to change all the things identified in Retrospectives.
6-8 people in their group working with this Agile process.
Jeremy points out that they invite everyone to their regular meetings
2.5 years N.D. has been using this process. It really helped to define roles.