Following on my intention to blog a bit about our internal development environment here at PRAGMA, let’s start with a look at the software development team, how we communicate, where we work and what Software Development Lifecycle we follow.
Team
The software development team has grown quite a bit during the past 2 years. Currently we have a Software Development Manager who takes the responsibility of managing the project, prioritizing the feature set, interacting with clients, ensuring the product vision etc. Reporting directly to the Software Development Manager is a Development, Test and Analyst lead. They are responsible for managing the 13 developers, 3 testers and 1 analyst that compromise the rest of the team. The management function forms only a small part of their responsibility as they are all hands-on, doing full-time development, testing and analysis together with the rest of the team. We believe in a flat structure and in the team taking collective ownership for the solution. As Development Lead, I share the overall responsibility for the architecture with another senior developer in the team. We also have a Project Manager/Assistant who helps with administrating the project plan and also currently plays the role of SCRUM Master.
Communication
One of the benefits of working at PRAGMA is that we get to work from home for 2 days a week. Initially I found it very hard to adapt to not having the whole team co-located. Especially in the early stages of the project, where I had to do a lot of mentoring, I missed the simple “luxury” of pairing with a developer to illustrate some concepts or to fledge out a design on a whiteboard or through some code. As the project progressed and things settled in terms of architecture and skills the issue became less of a problem. I still feel a co-located team is the most productive setup, but there is also a lot of merit in allowing people to work remotely for a day or two in the week by giving them the flexibility of not having to commute into office every day.
When working remotely keeping in touch is obviously very important. We use Skype for IM and VOIP calls to interact between individuals and small groups of people. I specifically mention small groups as we struggled to use Skype for calls that involved the whole team. The call quality was not good and people would frequently drop and had to reconnect to the conference call. This might be due to bad connections from the different ISP’s that the remote workers are using so your own mileage might differ. Fortunately for us PRAGMA makes use of Interwise Participant for web conferencing so our daily feedback session currently involves a combination of using Interwise for visuals and PRAGMA’s normal teleconference facilities for audio. This obviously incurs a bit of cost for the remote workers but it doesn’t nearly weigh up against the other benefits like not having to commute. As the broadband scenario in South Africa is getting better and better we re-evaluate this setup every now and then to see whether we can’t get away with only using Skype. For simple remote pairing/debugging sessions we find Microsoft SharedView to be an excellent solution.
Office Space
Our offices are located in the Bellville Business Park in the Northern Suburbs of Cape Town so fortunately we miss out on all city traffic. We moved into our current premises end of November 2009 and the new, modern offices are equipped with a very nice canteen and other facilities that make working at the office a pleasure. Of course there is some good, free coffee as well 
The seating inside the building is based on an open plan setup. The software development team sit together in what is refer to as the Lab with each person having his/her own small cubicle. This is a picture of my cubicle in the Lab.
The cubicle barriers are about 1.6 m high and allow you to work without being distracted when somebody walks by your desk. This setup works quite nicely although there are some days that I feel the cubicle barriers should rather be taken down to create a feeling of more openness and to “increase communication” in the team.
We have whiteboards against all the walls for design discussions and two small adjacent meeting rooms to the Lab for ad-hoc design discussions and meetings. We also have our build monitors setup against a wall in the Lab that shows our TeamCity builds and other dashboard related statistics relevant to our ongoing development efforts.
We will hopefully be replacing the two smallish monitors with one big monitor during this year to make it easier to read as we also use these monitors as an electronic SCRUM task board during our daily at-the-office SCRUM stand-up sessions.
SDLC
Talking about SCRUM, one of my first responsibilities when I joined the team way back in July 2008 was to look at adopting a more formal software development lifecycle. I’m a firm believer in an agile development methodology and all the disciplines involved with doing agile development so we adopted SCRUM. We went through quite a few Sprints trying out the different aspects of SCRUM to find out what works best in our environment. After starting with 2 week Sprints we eventually settled on 3 weeks as our ideal Sprint length. We tried Planning Poker for a few Sprints but eventually dropped this in favour of just estimating the tasks for a Sprint in Ideal hours. We had some big debates about using Story Points versus Ideal Hours and how we should track our Velocity. We took quite a long time to get a Prioritized Product Backlog in place and also struggled to map the backlog back into a project plan that was required due to immense pressure from a big international client. We eventually got into some kind of SCRUM rhythm, but we still have quite a few areas where we want to improve on going forward.
For a start I think we need to break the team into smaller groups that focus on specific functional areas of On Key. We can then use a Scrum of Scrums meeting to discuss the areas of overlap and integration. We also need to get better at breaking down the functionality in coarser tasks (or work items). I feel we are breaking down our tasks into too fine grained work items and this causes unnecessary management overhead and also totally clutters the task board with too much detail. I think a lot of this is as a result of us rewriting and expanding on an existing system, i.e. we have a very good idea of what is required, but I think we must still try and manage the work at a higher level. This might ease the pain of integrating back into the project plan as well. Having said all of this, we have mastered a lot of the technical disciplines (like continuous integration, TDD, automated acceptance testing etc.) required for agile development in place and we do succeed at delivering small increments of working functionality in our 3 week Sprint cycle.
Sprint
So how does a typical 3-week Sprint look taking into account that we work remotely for about half of the time? The following 3 week roster gives a quick summary of the high-level activities involved:
| Mon | Tue | Wed | Thu | Fri |
| At the office Individual Planning and Design Discussions | At the office Daily Scrum @ 10:00 Daily Build @ 22:00 | Working remotely Daily Scrum @ 10:00 Daily Build @ 22:00 | At the office Daily Scrum @ 10:00 Daily Build @ 22:00 | Working remotely Daily Scrum @ 10:00 Daily Build @ 22:00 |
| Working Remotely Daily Scrum @ 10:00 Daily Build @ 22:00 | At the office Daily Scrum @ 10:00 Daily Build @ 22:00 | Working remotely Daily Scrum @ 10:00 Daily Build @ 22:00 | At the office Daily Scrum @ 10:00 Daily Build @ 22:00 | Working remotely Daily Scrum @ 10:00 Daily Build @ 22:00 |
| Working Remotely Daily Scrum @ 10:00 Daily Build @ 22:00 | At the office Daily Scrum @ 10:00 Daily Build @ 22:00 | Working remotely Daily Scrum @ 10:00 Daily Build @ 22:00 | At the office Daily Scrum @ 10:00 Sprint Build @ 22:00 | At the office Retrospective @ 09:00 High level Planning @ 10:00 Demo @ 13:00 Design, Training @ 14:00 Drinks @ 16:00 |
Well, I think that’s enough for now about the overall work environment. In my next post I’ll look at the Development Tools that we are using.
No comments:
Post a Comment