AgileWelly – Wellington Agile Barcamp No.2
I attended the most excellent, second ever, Wellington Agile Barcamp in the weekend. The event was well attended – around 60 people; not a huge event but certainly a very welcoming one.
We ran three rooms, with four sessions each throughout the day. The four which I attended are as follows (and being cheeky / a responsible member of the community I recorded the audio for these, available on SkyDrive as MP3 Podcast: http://cid-97423eb2afc7174a.skydrive.live.com/browse.aspx/.Public/APN%20Barcamp%202009%20%5E3AgileWelly), you can also find more info on the event all over the web under the hash-tag #agilewelly
Agile and Architecture
A lot of people see the terms Agile and Architecture as being mutually exclusive – something I disagree with; it seems I wasn’t alone.
I asked people how they managed architectural constraints and NFRs on an agile project, here’s what came back:
- Use two story boards: one for functional stories, the other for non-functionals.
- Including architectural constraints as separate user stories was seen as being a good move politically, but had practical limits.
- Add the constraints to the user stories (as appropriate, I assume)
- Include as part of the ‘Done’ statement.
That last point is an important one; stuff like performance testing isn’t something you can demonstrate effectively from your development environment. I think it’s something you’d test (as ‘done’) along-side your continuous integration work. Also of note:
- Good (appropriate) engagement between the solution architect and the project was key (this shouldn’t be new to you solution architects out there).
- In some ways the solution architect is a member of the development team, and in other ways they are a client or stakeholder.
- Just as the business owner should prioritise user stories for business value, the solution architect should prioritise technical stories (NFRs) for technical value.
Self Organising Teams
Rashina Hoda presented where she’s at with her research into self organising teams; she’s found that while everyone in an agile project will have a formal role (developer, tester, and so on) people will also adopt informal roles.
Rashina has identified six of these:
- Mentor
- Co-ordinator
- Translator
- Champion
- Promoter
- Ternimator
Each role has a specific function, and whilst her research has found that they are usually undertaken by someone in a specific formal role, they can be undertaken by anyone; for example a senior developer or agile coach is most likely to be a mentor, whilst the terminator is most likely to be the agile coach.
Rashinas research has so far included project teams in both New Zealand and India.
TDD and BDD
This was a good intro session to TDD, and positioned BDD as well. I must admit I didn’t know a lot about BDD (and I still don’t) but it seems to be focused more at the business level than the code level – TDD is largely an engineering focused practice to support good code development, where as BDD seems to be more about why you’d write the code in the first place.
The crucial connection that the session made for me was how TDD and BDD relate.
Nigel Charman drew this diagram on the whiteboard (with my own notes in blue).
Basically, in a vertical sense, BDD is business facing (top) and you’d ‘do’ BDD via your User Stories, where as TDD (bottom) is closely associated with Unit Testing. On the other hand, horizontally, we have checks which are automated (left) and tests which are typically manual (right), and it’s over on the testing side that you’d (manually) test your UI and NFR’s like performance.
This is based (as far as I can tell) on a couple of assumptions:
- You can automate (check) your systems tests (at the business requirements level) using tools, just as you can check that your code still works (via unit tests).
- You can’t (easily) automate the testing of UIs or NFRs.
As far as continuous integration is concerned – that’s obviously a left-hand side activity. Just going back to the ‘Agile and Architecture’ discussion for a moment, I think that’s how we fit in management of our NFRs from an architectural stance – which would be on the right-hand side (checks).
What we’re after is a process that brings together the automated DBB and TDD checks with the manually tested NFR and architectural tests. I’m sure things like performance and security will be possible to test in an automated way to the not too distant future, and if we couple that with our continuous integration work we’ll be a long way to really bringing architecture into the agile fold as a first class citizen.
If you’re after tools to help you with BDD you could try:
Also see:
Agile and Government RFP Engagement
This was a really popular which generated some interesting, controversial and predictable comments.
An idea that grabbed a lot of support form the group (which included representatives from both sides of the RFP fence) was multi-stage commit. Apparently the idea isn’t that new – but who cares how old it is if it works, right?
The idea behind multi-stage commit is that you agree on a small (appropriate) size chunk of work – lets say some time to kick-off the project (get the first cut of a story board up, if we’re doing SCRUM) as well as three iterations. You need a bit of time for the team to settle down, and the period of work gives both parties a chance to see how comfortable they are with the union.
As the project is restricted to kick-off and three iterations it’s much easier to cost, and the risk all round is minimised. Rather than committing to a two year project you’re only committing to a 10 week one (four weeks to get started and 3 x two week iterations, plus some sort of review).
Another idea, also very popular, was the idea of a meet and greet. Get all the potential respondents in to meet the client face to face. This is a very agile like approach: OMG! Face to face communication! It’s great for respondents as they can quickly decide whether they want to compete of not (as responding is not something to be undertaken lightly), and it provides excellent feedback on the viability of the project and other options that might meet the business need – but were previously excluded by the way the RFP was worded.
Really, the more you think about the RFP process and the benefits of agile, the more you realise there is an enormous opportunity there.
|