I thought this week’s retrospective was good and bad. Good that we have two new recruits to work on a new project, and it was good to talk them through some of the ways that work and would like to work.
The bad bit was that after we are done telling the new guys about how we work we don’t then back it up by demonstrating what we are talking about in practice.
If we are gonna attempt to be Agile then we need to do it. Without the actions to support what we say then it just becomes an overhead.
If we are gonna do it then can we please do it properly.
It’s not a work day today - indeed it’s the sabbath for some, but I thought I’d post a collection of thoughts in lieu of my daily ponderings.
In this week’s IKO we were a little cautious about what we commited to, so see if we can get our sprints back to fulfilling what we commited to. There were some big numbers that are apparently very close to finishing and we are also having a week where we are catching our breath and taking stock of the areas that we need to know more of. Hopefully by this week’s retrospective we will have a clear board and some good clarification of areas of weakness and a plan of action how to address them.
Personally, I’ve been continuing to look at cucumber stories with an eye on how we practically get them used. I am conscious that I do not want BDD to be percieved as a burden and to convince myself and others of that I need to see it working from stories all the way to code.
The only way to do that is to give it a go, then see what has been learned. Also this week, I’ve been enjoying reading the Pragmatic Programmers GIT book. Being confident in our tools can only help us code better.
Got a load of scenarios written today, and began work on a blog post explaning things to the rest of the team prior to using them to aid in coding the features described.
Also attended a curious meeting that discussed images and how the organisation handles images. Curious because I thought a lot of what is needed is already possible. Images are interesting because they sit pretty squarely on the boundary between style and content, so can quite easily become a bone of contention. Personally, I’d like to use more images on our websites, but I’d like them to be used in a far more illustrative and supportive capacity than they are at present. If they are relegated to the ill defined role of breaking up text then I really don’t see the point. That argument works in a more static medium like print, but on the web that fixed object becomes more problematic. I suppose my holy grail would be integrated and relevant images enhancing the content of our sites.
Still writing stories, which is turning out to be much harder than I’d hoped. I’m finding it hard to pick a suitable level of detail that would enable someone to code the behaviour. It all comes down to what assumptions we can make. Probably safest and clearest to explicitly state the behaviour, which is making things pretty time consuming.
I’ve taken some of our existing stories we garnered of our clients and am trying to putthem into features. As things stand it looks like I’ll have to revisit a lot of them after a bit of thought and see if they still make sense. I almost have to forget what we’ve discussed about the features, and pretend I know nothing.
If what I’ve written them makes sense all well and good, if not I have to try harder.
So, few things coming out in the wash this retrospective.
Good that we seemed to get it off our chests about the way we are writing the stories that make the tickets. I think after all of us have experienced frustration at work we haven’t sufficiently defined and that came out. Perhaps we will now do that work up front and make the actual work easier. I hope that we have some tickets ready to go for tomorrow, that are smaller and clearer.
Seem to have worked through a very frustrating phase today, when I had to work from home (which was fine) whilst not having a really clear idea of the work needing doing this sprint (bad).
Speaking to Funky Bunch, he agreed that our tickets are still too vague. This issue seems to have persisted for a while now. It with that in mind that I’ve been looking at the various options for us doing story driven development. If we invest more in the stories then perhaps we will force ourselves to be very clear. I think the time taken in writing clear stories will pay us back at the coding part of the job. It’s also made a little easier now that Sarah is managing the tickets, doing the things that we haven’t been great at :- setting priorities, matching work to releases and features and planning workloads.
So, crap start to the day, finishing on an upbeat note.Not quite sure that is good enough for a stand up though. I did watch a screencast on rspec, and followed it for a good while, but it still seems a little outside my jurisdiction.
Feeling good about tickets today. Perhaps I am a simple creature that is easily duped into a sense of achievement by small tickets. I’ve managed to get some things done, and the little tickets serve to oil the wheels for the big ones.
Of all the 8 retrospectives that we’ve had so far I found this one the least satisfying. It was gratifying see work done in the to demo, and good that Sarah introduced a new method for tracking the tickets as they get raised. It should help when we need to dip into the backlog, to see what the priorities are.
So the clients went away happy.
I was interested by Kev’s introduction to Cucumber and it’ll be good to see how what we’ve learnt about tests will help us to use it. Unfortunately I was less interested in the ‘cloud’. I find that the talk of the cloud is too amorphous at the moment, it COULD do a fantastic job of sorting out our content types and becoming a really responsive base for the entire project, and with Darrin’s stirling work and talent I’m sure it will.
I just don’t think that the retrospective was the place to talk about it. What happened to ‘show don’t tell’ ? I thought that was one of the guiding principles of Agile Development. I didn’t want to be rude and make Darrin feel that I’m not interested - because I am. I just don’t feel I can contribute to the cloud concept right now because I can’t get a good mental model. I don’t think explanations of the possibilities make it any easier for me to understand. I’m content to wait until there’s a bare bones thing that we can look at - I appreciate the desire to involve us and if talking the things through has helped then the retrospective has been very useful for Darrin. Just not for me.
The unfortunate side effect of this meant that we didn’t get to have recap on the week’s work. I thought we got a good amount of things done, clearing the decks ready for a good crack at the news tickets that have been sitting patiently for a while. We had a brief discussion on the nature of the site, and I think this arena is the place where we get each other’s opinions on what the site is and what it can become.
But heigh-ho, tomorrow is the planning for next week, and with a pile of precise story cards there should be plenty of work for all of us.
A day late on my daily summary of work, for no other reason than playing with an electronics kit with my kids.
Started the day with ‘messy’ ticket; by which I mean a ticket that included interactions with people and trying to make sense of documents that we’ve been sent. In fact, one of the clear things coming out of the agile process is that writing code, or dong design can only really work when the messy stuff has been done before. We’d be waiting a long time if we waited for tickets to arrive nicely packaged with simple start and end points. It’s a less appreciated part of a developers role but untangling what is said and what is meant has to be done before we can move on.
Picked a ticket off the board today that had been rated at 5 points, which in retrospect was probably about right, but I hadn’t factored in getting my local install of that site up and running since it’s been a long time since I’ve done any development on that site.
This brings me to something I’ve noticed that is puzzling and frustrating in equal measure. When I, as a developer look around the sites that we’ve built, I inevitably see things that we could or should have done better, or can be improved upon with things we’ve learnt. The frustrating part is that because we’ve now jumped in with both feet into agile development we are putting our faith in our clients to notice the same things.
I’m puzzled how we feed out ideas to make the things we build better into the system.
I guess that we suggest these things to our clients and have to make the effort to convince them of the value.