1. Initial architecture
1.1. Where should we store data?
1.1.1. Cloud
1.1.1.1. Amazon EC2
1.1.1.2. New node
1.2. Should we store files or only metadata (e.g. Slides as file or only a link to sildesharing provider)?
1.3. platform
1.3.1. mobile app - NO
1.3.1.1. PhoneGap approach
1.3.1.2. native app for one platform
1.3.2. web app - YES
1.3.2.1. for mobile
1.3.2.2. for laptop
1.4. Programming languages
1.4.1. Jython
1.4.2. Groovy
1.4.2.1. Grails
1.4.3. Any language
1.5. New node
2. Development environment
2.1. as download
2.2. as USB Sticks local
2.3. at installed and configured development computers
2.4. web based
2.4.1. existing service e.g. Cloud 9
2.4.2. locally hosted - coding dojo or equivilant
3. Minimum Viable Product
4. overcome the participants inhibitions
4.1. Support of as many programming languages as possible
4.2. Support of a simple to setup an use dev enviroment
4.3. Support of their own dev enviroment
4.4. Build something that can be used during the unconference
5. Continuous Delivery
5.1. every hour a new version
5.2. this is the key agile practice under stress test
6. Time Table
6.1. Features are very time driven - needed in real time for the conference.
6.2. Teaser Talk (5 min) at the 1st day during Talkshow
6.3. Iterations in parallel to Talks and Open Space session (12 times)
6.4. Iterations in the evening (if possible) of the 1st and 2nd day (4 times)
6.5. Retrospective (1h) during the last Open Space slots of the 1st and 2nd day.
6.6. Closing Session (1h) at last Open Space Slot of the 3rd day.
7. Needed Attendance
7.1. Moderator/ Scrum Master
7.2. Initial PO
7.2.1. we think at least 3 people will be needed to play this role over the period of the conference
7.3. Technical Instructor
7.4. the ALE2012 organising committee are a key set of stakeholders in this app and must be involved in its development as users
8. Needed Infrastructure
8.1. At the venue
8.1.1. Task Boards
8.1.2. FlipCharts/Whiteboards
8.1.3. Desks
8.1.3.1. Monitor
8.1.3.2. Keyboard/Mouse
8.1.3.3. Power Sockets
8.1.4. Buildmonitor
8.2. In the cloud
8.2.1. Deployment Stages
8.2.1.1. Dev
8.2.1.1.1. Branching
8.2.1.2. Test
8.2.1.3. Production
8.2.2. CI Server
8.2.2.1. Build Pipeline (Simple, no artifactory, one test env, one prod. env)
8.2.3. Source Repository
9. Session staff
9.1. Preparation
9.1.1. Team of 6 people to sit on the sofa
9.1.1.1. Needed competences
9.1.1.1.1. Organizing
9.1.1.1.2. technical
9.1.1.1.3. requirements
9.1.1.1.4. advertisement
9.1.1.1.5. process modell
9.1.1.1.6. coordination with conf orga
9.1.1.2. New node
9.2. At the conference
9.2.1. facilitators
9.2.1.1. the sofa team
9.2.1.2. will we need any more?
9.2.2. Build infrastructure team
9.2.2.1. at least one is part of facilitator team
9.2.3. POs
9.2.3.1. how many POs should be identified beforehand?
9.2.3.2. at least one is part of facilitator team
9.2.4. Objective is to run with as few as possible but enough to succeed
9.3. Video Team
10. Preparation
10.1. Initial application
10.1.1. Empty application
10.1.2. First feature with business value
10.1.2.1. information feature to update users that a new feature has been delivered
10.1.2.2. the most time critical feature required by the organisers of ALE
10.1.3. add a feedback feature before the start
10.2. Investigate candidate mashup APIs
10.2.1. Lanyard
10.2.2. TwitCard
10.3. The team sofa should build trial backlog and throw it away
10.4. The Agile Process
10.4.1. Scrum?
10.4.1.1. ScrumMasters per hour?
10.4.2. Lean
10.4.2.1. Kanban
10.4.3. Which practices are we adopting
10.4.4. Focus
10.4.4.1. 1 Story per hour
10.5. Coordination with ALE2012 conference team
10.5.1. many features of this app will mimic/replace conference administration or activities
10.5.1.1. Conference activities need to be understood
10.5.1.1.1. documented
10.5.1.2. a time table of which features are needed when
10.5.1.2.1. user stories will be generated with the organisers who are users of this app
10.5.1.2.2. Every feature will have a manual process
10.5.1.2.3. each feature will need a test process to give the ALE organisers confidence that the feature will work
10.5.1.2.4. features that miss their allotted time slot maybe abandoned as no longer needed for this product
10.5.1.2.5. the delivery time maybe some hours before the event it is needed in
10.5.2. this will need continuous information sharing with the ALE organisers before and during the conference
10.6. Add all the tasks to the ideas on this mind map with an outline of times
10.6.1. preparation area first I suggest
10.7. Test Run of process
10.8. Initial Tooling
10.8.1. JIRA, Confluence ? Sponsored by Atlassian? Hosted?
11. Other Agile Practices
11.1. TDD (expected)
11.2. Pair Programming (suggested)
11.3. Retrospections
11.3.1. every hour after release - 5 min
11.3.2. every evening - 30 min
11.3.3. end of the conference - 1 h as closing session
11.4. Continuous Delivery
12. Legal Stuff
12.1. Open Source ?
12.1.1. we need something like this
12.1.1.1. http://www.apache.org/licenses/cla-corporate.txt
12.1.1.2. http://www.apache.org/licenses/icla.txt
12.1.1.3. MIT license
12.1.2. ensure that it is unencumbered - correctly assigned rights
13. Fail Fast and Fail early
13.1. What is a failure for us?
13.2. But it should not fail due to lack of preparation
14. Session Objective
14.1. A new feature with business value every hour
14.2. Every contributor contributes to working code
15. Future Conferences
15.1. a secondary objective
15.2. will evaluate how it runs a ALE2012
15.3. we need to ensure that contributed code is OSS
16. Sponsorship
16.1. normal conference sponsorship identified with this event
16.2. to be sponsored
16.2.1. needed
16.2.1.1. Cloud Infrastructure for Production
16.2.1.2. Cloud Infrastructure for Development
16.2.2. optional
16.2.2.1. Material for Dev
16.2.2.1.1. Stickies
16.2.2.1.2. Indexcards
16.2.2.1.3. Pen/Flipchart
16.2.2.2. Video (if done)
16.2.2.3. USB Sticks for distribution of dev enviroment
16.3. awards for the most contribution to the development
17. Culture of Behaviour
17.1. what you can do
17.1.1. when to rewrite
17.1.2. obey the process of the hour
17.1.3. Focus on the story of the hour
17.2. help set the boundaries of the session
18. Announcement(s) of the session track
18.1. content
18.1.1. What should/could prospective contributers prepare?
18.1.1.1. Legal question of providing OpenSource results
18.1.1.2. Installation of the dev enviroment
18.1.2. How to integrate a currently not supported technology stack?
18.1.3. What are supported technolgy stacks?
18.1.4. General Ideas and Goals of the session track