I recently joined Boost after spending over a decade in the UK.  Having worked within a traditional project management process over the last 5 years, I was very keen to learn about the benefits of Agile project management, specifically the benefits of Scrum and the comparison with my previous experience of web development projects.

What I found after a week of observation was that unlike my previous experience of web development projects, an ‘us and them’ (supplier v client) situation causing conflict and resentment is less likely to arise under Scrum.  This is due to the scrum itself -  both supplier and client are team members with clearly defined roles and responsibilities.

I was asked to observe a number of Scrum meetings in my first week; a stand-up, story sizing meeting and a retrospective.

The stand up 

The stand up occurs daily and is a chance for the team to confirm what they are working on and to communicate progress from the previous day. I was immediately struck by the fact that each team member contributed to the stand up in the same way – developers are not asked what they are working on, they tell the team what they are working on and have the opportunity to identify any blockers to their progress.  Although brief and straightforward this meeting immediately appears to be beneficial for a number of reasons.

• the entire team knows exactly where in the sprint each person is
• issues or blockers are raised early
• progress is seen as it happens, stories are closed out each day throughout the sprint

Story sizing

Story sizing consists of all team members sitting around a table with a hand of sizing cards (numbered 1, 2, 3, 5, 8).  A member of the team reads out a story, team members are then asked to ‘play’ a sizing card.  The card indicates a measurement of effort that is not classified in time but by a proportional comparison.  For example if the first story is sized as a 3 (or medium) then a story that is larger and will consist of more tasks may be sized as a 5 or 8.  If a team member’s sizing differs dramatically from other team members the team member will then explain why they consider the story to be larger or smaller and after a discussion a consensus is reached.  Sizing of stories informs the decision as to how many stories will be undertaken during the upcoming sprint.

The advantage of the entire team sitting down to size work as opposed to a more traditional method of having the developer who will undertake the work provide a time estimate is that each and every team member has a chance to input to the sizing of the story therefore the team takes responsibility for the timing of the story, as opposed to an individual.  It is a transparent process that ensures the commitment of all team members to the delivery of each story.

The retrospective    

The retrospective is a feedback meeting in which each team member is asked to focus on particular aspects of the previous sprint and to record both positive and negative feedback on these.  The aims of a retrospective are for the team to communicate, review and improve on previous sprints.  Retrospectives may be run in any number of ways in order to get the best out of the team.

During my observation of a retrospective I was immediately struck by the difference between this meeting and that of a traditional lessons learned meeting (held at the end of a traditionally managed project).  The retrospective encouraged all team members to communicate openly.  Contributions from team members are presented as statements, and are constructive rather than obstructive or defensive.  The advantage of holding retrospectives regularly (at the end of each sprint) is that points are raised early and the project goes into a cycle of continuous improvement – as opposed to a traditional lessons learned meeting where any constructive conclusions are beneficial only to the next project the team works on.

My conclusions from my first week of observing Scrum in practice are very positive;

• Developers are encouraged to fully participate in all meetings demonstrating work completed and inputting to decision points as required.  As a direct result of their commitment to the project developers take a great degree of responsibility for project outcomes, they are very obviously accountable for tasks, while also having the benefit of the entire team’s support.  All too often in non scrum projects the developer is asked to take responsibility for tasks in isolation and are therefore reluctant to commit to timescales and successful outcomes.

• Clients are fully immersed and committed to the process and as such are very much a part of the team.  Unlike projects I have worked on previously  there is less expectation that the supplier will drive the project in isolation, instead the client is fully involved in all aspects of the project and always aware of exactly what work is taking place and when it will be delivered.

• Processes are consistently reviewed for effectiveness and all team members input to the review process.  There are opportunities for both positive and constructive feedback and actions are undertaken as a result.  In comparison with the traditional ‘lessons learned’ aspect of a project this seems far more beneficial in terms of continuous improvement rather than undertaking process improvement at project conclusion.

• Project tasks are broken down into explicit finite tasks and the acceptance criteria are clearly defined and agreed at the outset rather than development task estimates taking place at the outset of a project in isolation from other team members.

My overall impression in this early stage of exposure to Agile project management and Scrum is that Scrum builds a happier, closer team and minimises risk by ensuring frequent and open communication between all team members.

Related Posts:

• No Related Posts

 

As an intern here at Boost I have had the privilege of working with a group of experienced and friendly developers. I have been here two weeks now and already feel settled in completely. One of the great things about working for Boost is that everybody is very approachable when you need to ask for help or when you need things to be elaborated. This has made the transition from university to industry easier than I initially expected.

Here at Boost we use the Agile software development methodology known as Scrum. So every day I have a stand up meeting with my scrum master (Jacob Creech) and product owner (Nathan Donaldson) where I go over what I have done, what I will be working on today, and discuss problems that I need to get out of my way. So far at Boost I have been working on bug fixes for our online usability testing tool IntuitionHQ, which is built in Ruby on Rails. Working in this way has helped me get my head around the large code base that I will gradually move towards developing features for.

The IntuitionHQ Scrum Board

Using Scrum means that I’m working in ‘sprints’, or two-week long development periods. Each bug in IntuitionHQ is written up as a user story. At the start of my first sprint I took part in a sprint planning meeting which included sizing the stories (assigning them points between 1 and 8 to indicate their complexity/the effort required to fix them) and then breaking the stories down into tasks. I had to indicate how many of the stories I could commit to in the two-week sprint, and how confident I was that I could complete them in that time frame.

As an intern I was not really sure how much I could complete, being new to Rails and working in the industry in general. But one of the cool things about Scrum is that at the end of each sprint you have a sprint retrospective. This is a chance to talk about how the sprint went, and what can be done to improve things. If I don’t complete all my stories in the first sprint, the next sprint will be adapted to deal with this, and so on and so forth. So in the case that I didn’t complete all my stories it will be known for the next sprint to take on less stories in relation to their size. Overall, this is about figuring out your ‘velocity’ – how many story points you can get done in a sprint.

For my first sprint I initially committed to seven stories. I ended up completing the stories early and brought in two more stories from the backlog. One of the fun things I have found about fixing bugs is it really stimulates the mind’s problem solving abilities. I developed most of my problem solving abilities while doing my Software Engineering degree at Victoria University. Although university is a great learning environment I have found that learning in a working environment has more merits. This is because you are working with a group of people towards a common goal so they are more likely to help you out and I find that social learning is the best way to learn. This differs from university as everybody in your papers are competing to get higher grades than you so they generally don’t feed you all the facts.

One of the cool things about coming out of university into a working environment is that once you get home from work it’s your time, not stressing-about-assignments time. I believe that the less stress you have weighing on your mind the more productive you can be. Not being stressed out has helped me to be more productive working here at Boost and has got me highly motivated and keen for my next sprint. To sum up my experiences so far I would say that working here has been awesome!

Related Posts:

• Free Friday Agile workshops at Boost
• Agile experiments: creating user stories with story mapping and ‘buy a feature’ prioritisation
• User stories and stakeholders – bringing people on board with Agile
• Pair programming: When and why
• Jean Tabaka on the Golden Circle of Agile & StackExchange for project management

 

If you like tables and percentages, you’re in luck: two chewy releases in the past couple of weeks are going to give you hours of happy data crunching.

Social networking and our lives

Pew Internet have recently released their report ‘Social networking sites and our lives’, which updates the findings of their 2009 report ‘Social Isolation and New Technologies‘. In their introduction, the writers note:

Questions have been raised about the social impact of widespread use of social networking sites (SNS) like Facebook, LinkedIn, MySpace, and Twitter. Do these technologies isolate people and truncate their relationships? Or are there benefits associated with being connected to others in this way? The Pew Research Center’s Internet & American Life Project decided to examine SNS in a survey that explored people’s overall social networks and how use of these technologies is related to trust, tolerance, social support, and community and political engagement.

2,255 American adults were surveyed between October 20-November 28 2010 for the report, including 1,787 internet users. Of these, there were 975 users of social networking sites. One of the great things about the Pew research is how carefully they control their findings to account for different factors:

The findings presented here paint a rich and complex picture of the role that digital technology plays in people’s social worlds. Wherever possible, we seek to disentangle whether people’s varying social behaviors and attitudes are related to the different ways they use social networking sites, or to other relevant demographic characteristics, such as age, gender and social class.

What’s in the report?

The report is full of fascinating information about who is using social networking sites, what they’re doing on them (especially Facebook), the size of their social networks and strength of their social ties. There’s a special focus in this report on whether use of social networking sites contributes to the ‘echo chamber’ effect (reducing people’s engagement with a diversity of opinions and experiences), affects the level of trust social networking site users feel towards other people, and political and civic engagement. These findings have been really well summarised on the Nieman Journalism Lab site.

Who are these people?

Amongst the people sampled for this report:

• 79% of American adults said they used the internet
• 47% of adults (59% of internet users) say they use at least one of social networking site

This is nearly twice the number found in the 2009 report, which found that 26% of adults (34% of internet users) used a social networking site in 2008. Internet users of all ages are more likely to be using a social networking site now than they were in 2008, with the most pronounced increase being in people over the age of 35.

As is common in use of social media, more women (56%) than men are users of social networking sites, and more women than men use Facebook, Twitter and MySpace. However, nearly twice as many men as women use LinkedIn.

And age-wise:

• 32 – the age of the average adult MySpace user
• 33 – the age of the average adult Twitter user
• 38 – the age of the average adult Facebook user
• 40 – the age of the average adult LinkedIn user

And what are they doing?

The report looks closely at Facebook activity amongst the people surveyed.

Status updates are an infrequent activity for most users; 56% of Facebook users update their status less than once a week. Only 15% of Facebook users are updating their status daily or more frequently. 16% have never updated their status.

Commenting on other people’s status updates is a more common activity: 53% of Facebook users comment on other users’ status once or twice a week, and 22% are commenting at least daily. Commenting on photos is also popular: 20% of Facebook users comment on someone else’s photos at least once a day. But overall, the most popular activity, according to the the Pew Internet report, is Liking.

A List Apart web survey 2010 results

A List Apart have released the findings of their 2010 survey of people working in the web design industry (and their graphs are super pretty).

I’ve been completing the survey for at least three years now, and I’m always so glad I do – because either women are very underrepresented in the industry, or they don’t get round to filling out this survey. Of the 16,593 respondents to the survey, less than 20% were women:

Women make up a very large proportion of respondents working with content and in usability roles, according to their job titles: 46.3% of content strategists, 45.7% of writers/editors, and 32.5% of usability experts/leads/consultants.

Sadly, for the past three years, writer/editors have expressed under 90% confidence in the security of their roles.

Every year I find the satisfaction findings particularly fascinating. But the whole report makes interesting reading – make yourself a cup of tea and settle in.

Related Posts:

• Facebook is now the first step
• 10 Great Scrum and Agile Practitioners on Twitter
• Reminder: EYC unconference this weekend in Wellington
• Social media workshops for museums & galleries
• 5 social media themes from 4 workshops with 31 organisations

 

As far as civil defence goes, we have always maintained a high level of preparedness, our bright yellow plastic water containers shine out from under out pods. recently however, the devastating earthquake in Christchurch has made us re-evaluate our own readiness for a natural disaster.

Previously we had enough food and water for each person for 3 days, packed into lidded buckets that could be used for containing water or becoming toilets. These buckets were placed into our cvil defense cabinet along with cooker, pot, fuel, and a water purifier. As the company has grown we were overdue for a re-stock. And since the February 22nd quake we have had a re-think what is needed and how best to prepare.

We had simply followed the NZ civil defence guidelines to have enough food and supplies to last three days. It has now become clear to us that if we were hit with a earthquake on the scale of the Canterbury ones it would be unlikely that we would all be trapped in an intact office bidding time for 3 days – although if might be possible if we were struck by a tsunami or floods.

Our preparedness objectives are no longer to simply survive in one place. Our priorities are now:

• Ensuring everyone in the office is as safe as possible at the time of an earthquake
• Accessibility to first aid equipment
• Movement through rubble and broken glass
• Survival if trapped
• Escape from the building if normal exits are blocked
• Getting back home to family members

We realised that there were a few things missing in our kits. and added the following:

• Gardening gloves for moving objects covered in broken glass
• Overalls, face masks and gumboots to deal with rubble
• Backpacks ($5 at the warehouse) to get back home on foot
• Smaller, portable bottles of water
• A really great first aid kit
• Abseiling gear with a 50 metre rope to descend from the 8th floor to the ground

We have stocked up on even more water, several water containers in our civil defence cabinet and a further 15 litres under each pod. Coats that were destined for a charity shop have been stocked away we now have two transistor radios, one of which can be powered by a hand crank. Our latest additions are whistles, and I’m sure we’ll be continuously adding and upgrading as we think of new items.

After having a look at current earthquakes and the weeks after we have had an opportunity to understand better some things we can do now to make things easier for the future. If the big one does hit Wellington there will be huge variables that we have not accounted for. But we are in a better position now than we were a week ago.

Related Posts:

• No Related Posts

 

It’s not too late to register for the Engage Your Community unconference, being held in central Wellington this Saturday, 21 August.

The unconference is a free day-long learning and skill sharing event for people working or volunteering as webmasters in community groups, volunteer organisations and not-for-profits. Industry professionals are invited to come along as well, to share their knowledge and experience.

I attended last year’s EYC conference in Wellington, and had an absolute ball running a social media workshop. I love the informality and sparky atmosphere you get at barcamps, so I’m really looking forward to going along this weekend.

The details

Who’s it for?

• volunteer webmasters
• people communicating with member groups using the web, email or social networks
• comms professionals or webmasters in not-for-profits
• people responsible for almost everything in an office, including communications
• industry professional wanting to give back to the community by sharing knowledge and skills.

Why should I go?

• meet others with similar interests
• share and learn alongside your peers
• find ways improve your website, and explore other web tools.

Where and when is it?

9.30am-4.30pm Saturday, 21 August 2010
Rutherford House, Victoria University Wellington

What does it cost?

The EYC unconference is a free event

What’s an unconference?

An unconference is like a conference, in that it’s a gathering of people interested in a particular topic, who come together to share and learn. An unconference is unlike a conference, in that it doesn’t have a preset schedule of talks that you sit through: instead, the agenda is built on the day by the people who attend. Anyone can run a session, whether it’s to share something they’ve done, ask for help with something they’re trying to do, or just to kick some ideas around. The EYC unconference site has a list of topics people are interested in talking about on the day.

So what are you waiting for? Register now! And if you come along on Saturday, make sure you come say hi – I’m running the schedule board on the day, so I should be easy to find.

Related Posts:

• Data data everywhere: Pew Internet on social networking sites and A List Apart on the web design industry
• 10 Great Scrum and Agile Practitioners on Twitter
• Jelly at Boost: Friday co-working for free
• Facebook is now the first step
• Social media workshops for museums & galleries

 

This is the first entry in a semi-regular series sharing things that we’ve been looking at and reading recently …

Sarah (one of our project managers)

• Broadband becomes a legal right in Finland

• Guggenheim collaborates with YouTube and invites video submissions

Sue (one of our designers, recently returned from a break in the sunny northern hemisphere)

• Eye-candy and inspiration on www.citid.net

• Great experimental fonts (also: free!)

• Lighten up your winter blues: heaps of colour and shapes on Coolhunter

Alastair (one of our developers)

• Firefox 4 introduces more HTML 5 and CSS functionality. One step further towards the death of Flash? Still in beta so one for the developers.

• Excellent! Wayne and Garth spotted in the UK. Party on!

Rachel (our office manager)

• Artist creates masterpiece on an iPad

• World Cup 2010 statistics: all the key data for each team, from the Guardian

(Rachel notes that she’s not as much of a sports fiend as the above link might suggest, and also recommends data/infographic blog Cool Infographics)

Jake (who looks after our usability testing tool IntuitionHQ)

• David Gillis on Fusing Content Strategy with Design, in UX Magazine

• The Real Life Social Network, slides from a presentation by Paul Adams, Senior User Experience Researcher at Google

• Gnarcade – Video Game Invasion: for video game fans, and geeks in general

Courtney (that’s me – project manager)

• Aaron Straup Cope’s magical slippy map showing the world as revealed by geo-tagged photos on Flickr

• Significant Objects, an investigation of art and the market through short stories and eBay

• Swallows and Amazons, the current exhibition at Robert Heald Gallery, which is close to our office – on show until 31 July.

Related Posts:

• Pair programming: When and why
• International study on pedagogy and ICT
• e-Learning Research Network launched
• e-Fellows for 2009 announced
• How are we using the internet?

 

During a brief slow period on a Friday afternoon I started pondering how much work I actually do, and if it was even useful knowing. Obviously all our code is stored in a version control system (git), so in a way all of the data for finding out the quantity of work is readily available. A little investigation and I found that it’s quite easy to pull a list of commits from git showing total lines added and deleted per file:

git log --oneline --numstat

I’ve committed a lot of code that I didn’t write, such as plugins, the Rails framework etc. So a quick and dirty ruby script later I could get a list of all unique files in all repositories that I’ve committed to. It was pretty easy to go through the list and create an exclusion list. I then broke out Ruport to aggregate everything by extension. That gave me the following table:

I’ve cleaned this up a little and collapsed some alternative extensions down.

Commits per week

Just over 110,000 lines added and 50,000 deleted, of which about 100,000 are to Ruby files. Now I’m not claiming to have written all those lines myself, any part of any line changed counts towards the total. All this does is illustrate the general balance of work that I do. There have been two lines added for every line deleted. This year has seen a lot of refactoring work, so it’ll be interesting to run the same exercise next year and see if the results are similar (of course git holds historical data, but we only started using it about 18 months ago, and previously had everything stored in subversion).

It’s interesting to see that the proportion of additons to deletions is much higher in view (rhtml/haml) files than in ruby code. This could point to the way things look being changed much more than the way things work.

Now if only there was a way to measure the quality of work. (Actually there are tools; metric_fu is a good starting point and we use it a lot at Boost. However, that’s going a little too far for this post).

Another interesting bit of data I extracted from git is the number of commits I’ve done per week over the last 52 weeks.

I’ve posted my script as a github gist. You  can run it by modifying the @repositories array with a list of git repositories, @author with your email address and @excludes with a list of regular expressions for excluding files. Run the script as ruby gitcount.rb. If it is run with the argument “files” then it will list individual files, making it easier to build the exclude list.

Related Posts:

• Custom application and CMS integration
• Hosting in the cloud
• How the west was clustered
• What should break the test?
• Squirrel and the custom nut matcher