IT Werkz Sometimes

I’m working for a pure play web company right now and it’s kinda neat. I thought I was good at webby stuff but there’s still a whole pile of stuff I’ve learnt and need to learn.

We had a new release the other night which was a bit stressfull as you can’t tell your users to not use the system while you’re upgrading, as this lot probably gets about 10k hits an hour. They also do agile, the scrum variety, so jack shit is written down which can lead to some confusion. They are definitely into the ‘we haven’t got time for all that. Charge!!!!’ thing. In fact not only is it a paperless office and a documentless office – where’s the printer? what the hell do you want that for? – they even hate the term ‘requirements’. They prefer ‘backlog item’. I just don’t get the daily scrum meetings though. I always wonder what the heck I am doing on them. Telling everyone that yesterday I tested something and today I’m gonna test something else isn’t exactly rivetting, in fact it sounds like I’m barely doing anything. If you mention any bugs you’re immediately told to take the conversation off-line, so I don’t bother.

There are a couple of guys there that have been on the project for a couple of years and when they do regression testing it’s something to behold. They work unbelievably hard and charge through the regression scripts at a gallop. Trouble is they keep missing problems such is their intensity to mark all the scripts as passed. More like rubber stamp testing. The last 2 or 3 sprints they had before me and this other guy pitched up hadn’t gone so well and the test manager actually went to the testing agency and said something like ‘get us some experienced people’, so they got us and the sprint we have worked on since we started has worked pretty well. Apparently all the top guys are happy, so that’s something. It wouldn’t surprise me if they only real difference was that we trapped some of the missed issues that the regression testers failed to be tripped up by.

They just don’t get some things though. The developers have only ever worked on web pages and have no idea of anything else and if we suggest any neat ideas to improve any processes you’re initially met with a blank look, and I mean very blank. Then when they have thought about it for a while they come around to possibly having an interest but still give us a load of resistence. They think we can’t possibly know anything about IT even if your resume is in their face, they just don’t understand anything but web. I still like it though.

Scrum Roles

The Product Owner
The Product Owner is responsible for representing the interests of everyone with a stake in the project, achieves ongoing funding for the project, initial overall requirements and release plans. The list of requirements is called the Product Backlog.
The Team
The Team is responsible for developing functionality and is self-managing, self-organising, cross-functionaland are responsible for for figuring out how to turn Product Backlog into an increment of functionality with an iteration.
The ScrumMaster
The ScrumMaster is responsible for the Scrum process and for implementing Scrum so that it fits within an organisations culture.

How it works
The Product Owner generates a prioritised list of requirements which are known as the Product Backlog.

All work is done in Sprints which is usually an iteration of 30 consecutive calendar days. At the beginning of each Sprint there is a Sprint planning meeting with the development team and the Product Owner to talk about what will be in the Sprint. The Product Owner selects the highest priority functionality from the Product Backlog and the team tell him how much of his required Product Backlog the team believes it can turn into functionality over the next Sprint.

In more detail the Sprint planning meetings consist of two 4 hour parts. The first part is the Product Owner with the Team where he presents his list of requirement from the Product Backlog and the Team questions him or her about the content, purpose, meaning and intentions of the Product Backlog (Any chance of anything being written down at this stage? Ed). When the team knows enough then they select as much Product Backlog as it believes it can turn into a completed increment of potential shippable product functionality by the end of the Sprint. The Team commits to the Product Owner that it will do its best (Whaaaat? Ed)

During the second part of the Sprint Planning meeting the Team plans out the Sprint. The Team is responsible for managing its own work (What happens if you have lousy coders? Ed). The tasks that the Team have agreed to do (How nice of them. Ed) are placed in a Sprint Backlog.

Every day the Team gets together for a 15 minute meeting called a Daily Scrum where each Team member answers the three questions a) What have you done on the project since the last Daily Scrum meeting? b) What do you plan on doing on this project between now and the next Daily Scrum meeting? c) What impediments stand in the way of you meeting your committments to the Sprint and this project? (Gee, it’s so easy. Ed). The purpose of the meeting is to synchronise the work of all the Team members daily and to schedule any meetings that the Team needs to forward its progress.

At the end of the Sprint a Sprint review meeting is held where the Team present to the Product Owner what has been developed during the Sprint. After the Sprint Review the ScrumMaster holds a Sprint retrospective meeting with the Team where he encourages the Team to revise its development processes to make it more enjoyable and effective for the next Sprint (Give me strength. Ed)

Well for my own 2 pennies worth I’m not convinced that Scrum’s gonna work with any project with more than five people on it. And if you want to see some good old logic-chopping do a Google search for criticism of scrum.

Just read the following in a book about how to bust web software:

“We are already seeing a backlash against many of the mainstream waterfall and iterative software development methods in favor of agile and Extreme Programming methods. If taken “to the extreme,” agile development is a completely unstructured, chaotic process that employs unrepeatable processes and bypasses much of the testing and design phases. Although agile development might decrease time-to-market delays and increase the rate at which programmers can write code, whether such an approach improves quality is uncertain at best.”

But agile is still the new kid on the block so we have a few years more with agile before the light is seen.

I have some intermittent iTunes problems which, bizarrely, tend to happen in the early evening. When I need iTunes to connect to the web to update podcasts or applications or just go to the App store quite often it doesn’t actually connect and eventually I get a message that the Bonjour service isn’t running. When I check services it does say it has started. If I get that message then I also get a message when iTunes starts stating that it isn’t the default music player and do I want it to be the default music player, or words to that effect. I also sometimes get a message from the firewall asking me whether I should allow iTunes to access the web.

The last of these two issues make me think that good old Vista thinks that iTunes is being used for the first time and it needs configuring. I have stopped and started the Bonjour service, I have set iTunes to being the default music player and OK’d that iTunes can be run through the firewall. I have then successfully restarted the PC so that the registry settings are firmly applied.

But then if that was the case I wouldn’t keep getting these problems so my thinking isn’t quite right here. So what the heck happens in the early evening that doesn’t happen earlier in the day? Think..think.