Willie Went To Webstock

Presenter M. Jackson Wilkinson
Twitter @wafro
Site: www.jounce.net
Developer(Python), Project manager, Agile Man

So i went into this presentation having seen a couple of agile projects in practice, and not quite sure what it was all about i did a couple of googles some time ago. When this opportunity came around i thought it would be rude not too.

Jackson was a great presenter and covered a wide range of topics from various peoples perspectives in the project team. I will not try and repeat it all as i would be here forever and its a bluebird day in welly so i’ll keep it short.

- Collaboration is imperative
- Embrace change
- Choose the team very carefully
- Everybody on the project team must “buy-in” to the goal
- Attention to the technical detail not just a quick hack as more time is spent on the development rather than the process.
- Release _working_ software often to the client to show progress. Not every cycle has a release

We brushed over the how the process works :

1. Cycle Zero
- Research
- Product Design
- Development Prep get ready to start coding
- Moodboards(very cool) for quick look & feel concepts
- Very importantly Defining Done

2. Cycle Planning
- Develop User stories eg. User can search for a photo.
- Test planning – asumption, success criteria, out of scope bits
- Use and index card to capture information gathered so far.
- Estimate is placed on each card and determined which cycle its targeted for.
- Use 1.2.4.8.16.32.64 for giving each storie points.
- Find your teams balance on how many storie points you can complete in a cycle
- Keep team rolling with backlog of the easy 1.2.4 tasks

3. Collaborative UX/UI
- Get business and designers to build mock ups together
- Quick and on paper gives you LOFI wireframes
- You can do more detailed wire frames but risk quibbling over detail
- Mock ups avoids confusion and developers love them

4. Daily Progress
- Focus on YTB, yesterday, today, blocks
- Use time keep it short and standing
- Just Google “scrum” it’s all there i promise
- there are all sorts of rules but use what works.

5. Pairing
- Thinker and Checker and the Does/Executor
- Development – Beter code less bugs
- Wireframes – review asumptions and help brainstorm

6. Test Driven Development
- Is a must
- Every function must have a test
- Selinium and Windmill for frontend test automation

7. Continuous Integration
- Automate Release cycle (cruzecontrol or hudson?)
- Frequent Release cycle (dayly, hourly)
- Check out, Build, Run Test, Notify if errored, Deploy(in Test)

8. Retrospective
- just before start of next cycle
- where are we at now
- reflect on previous cycle
- review story points completion
- review pairing arrangements

Appendix – Artifacts
- This one is still baffeling me as the whole point of agile is to just get into it, and only document what will be reused. But this means that some desision points may be lost because of lack of documentation.
- The code should be self commenting plus enough comments to make the rest understandable, frequent refactoring and good comments should improve this further
- Project wikis was also suggested.
- I do like documentation, so im unconvinced on this point of limited documentation

An interesting new term that was topic for a bit of discussion as it wasn’t on Google yet was “Layered Progress”
It is when you do development for your whole site in high level wire frames in the first pass. Next stage as they become available replace high level wire frames with more detailed ones, and as the final functional pages are available replace them again.
Implementation of this is up to you, if you hunt hard enough something like this may be found somewhere.

Another new one, for me at least, was “Coding Dirty”
It is when you developer builds the functionality and designer does the design afterward. This is fraught with danger as if your html/css is not marked up well it will produce a sub optimal result. Some people in the group has had success with this order.

Soo final thoughts. I’m not totally sold yet, there are some facets to it that i like but i will chew on the methodology a bit longer.

To give it appropriate visibility in an organisation you will need to try it on a small not critical but highly visible project to get the hang of it and get buy-in based on its success.

Now for some rest before day three AJAX and Accessibility shenanigans.