Death by dogma versus assembling agile - Sander Hooendoorn
This guy is a fantastic speaker. Funny, informative and really gets his point across.The talk centred on the fact that agile is everywhere nowadays. It’s huge buzz word. Everyone has to be seen to be doing agile, whether they really are or not. With that comes a host of problems, not the least of which is that agile, or in particular Scrum, can be seen as a silver bullet. It’s not. There’s also a lot of people getting certified as Scrum Masters then being thrown into a project, which can lead to a very dogmatic approach. Everything must be done to the letter because that’s what the “certified process” says and Scrum Master doesn’t know another way.
Sander’s main point was that if you take this dogmatic approach to agile, it’s not really agile. In fact it’s the opposite of agile. He suggested you should assemble your own method, find something that works for your team and stick to the basic principles of agile:
- Work iteratively
- Have small units of work
- Plan continuously
- Deliver early and get feedback
- Simplify communications
Integrity driven development - Roy Osherove
Roy is another absolutely cracking speaker and not a bad singer (the talk ended with a song). Unfortunately I’m finding it difficult to summarise the gist of his talk so I’ll pick out a few interesting points.One subject which struck a chord with me is was what Roy called survival mode. Essentially this is a team that is overloaded so they are too busy to learn and practice. Obviously this is incredibly bad. It’s bad for the developers because they’re stressed and the work is less gratifying because there’s pressure to cut corners. It’s also bad for the employer because developers will be less happy and so more likely to look elsewhere for employment. Roy suggests a couple of ways to get a team out of survival mode; remove over commitments and increase time estimates to include quality.
Another interesting technique cover was using a decision matrix. Surprise, surprise, this is used to make decisions. In short, you list our options along the top and your values down the side then rate each one between 1 and 5. The option with the highest total is the one your use. Simple.
The final point I want to cover from this talk is this; “great teams are grown, not hired”. I’m not sure I agree 100% but I really like the principle. To me this says focus on building the skills of your current team and be willing to invest time and money. Roy suggested several ways of doing this:
- Challenge your team
- Give them the time to practice
- Include learning time in estimates
Introduction to the reactive framework - Richard Blewett
The Reactive Framework (Rx) is all about providing a powerful wrapper around IObservable and IObserver. The interfaces are also fluent, making it very easy to read. Another particularly useful application is to wrap events. Rx provides various extension methods for handling events.To be honest, this is a very difficult thing to explain without examples. The talk was essentially one big demo with a few slides thrown in so did a very good job of explaining things. Unfortunately I don’t have those samples so the Rx getting started page is probably a good place to find out more information.
Individuals and interactions over processes and tools - Kevlin Henney
Again this is a talk which is difficult to summarise as a huge amount was covered. Kevlin is one of those speakers who gives the impression they could speak for hours and hours on their chosen subject. So again I’ll pick out a few points that stood out.Many of the points made in this talk were along similar lines to the assembling agile keynote. Agile should be flexible. There is no one way to rule them all. It was also pointed out that the idea of being a certified Scrum Master is a little ridiculous. What’s the point of being certified in a process that shouldn’t be defined rigidly?
Estimates are tricky. One figure, for example three weeks, is not sufficient. There is a probability associated with an estimate being correct so it’s better to suggest a time period. E.g. Two to three weeks. Also units should be chosen with care. Fifty two weeks sounds much more precise than one year. If a team member estimated a project would be completed in fifty two weeks, how much time either side would you give them? One week? Two weeks? If they said the project would take a year, it’s sounds much more fuzzy, much more imprecise, so it’s natural to assume there are bigger inaccuracies in the estimate. Perhaps you would allow one or two months leeway.
Apparently a study has been done about what motivates people. For us knowledge workers the top motivator was not money or recognition, it was progress. Now that is interesting.
Practice programming, what’s the point? Ben Lambert
I’ve been a fan of this idea for a while now. The idea is you practice programming in much the same way as you’d practice a sport, or playing a musical instrument. Why would you do this? To improve your skills, to learn something new, to challenge yourself. This can be done at work, but ideally it’s done in a no pressure situation. Then you can take your time and have fun. But, saying that, Ben pointed out that it is important for your employer to give you the time to practice. To understand something fully you need to take your time, which can be difficult at work.- What kind of thing can you do to practice programming? Ben gave a few examples:
- Write the same task in different languages
- Solve the same problem in several different ways
- Learn something completely new
- Write a simple game, or anything else you find interesting