Last time around I mentioned I would blog about the software development tools we are using. They say a picture is worth a thousand words, so with time to blog being a bit short in the week running up to the final release of On Key, here’s a mind map showing the different software development tools we are using in the different software development disciplines! Btw, if anybody knows about a decent Live Writer plug-in to insert a thumbnail, be sure to leave me a comment.
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.
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.
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.
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.
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.
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.
As I mentioned towards the end of last year, we delivered an important Release 3 milestone of Pragma On Key V5. We are currently working hard to further improve the application performance and to fix the remaining bugs with the aim of going live with a big international customer 1 March 2011. For those unfamiliar with PRAGMA and On Key [Source]:
PRAGMA is a global engineering company providing physical asset management improvement services and products to our clients. We believe that the most important value derived from our service is peace of mind. A client's CEO and his production or service team can focus on delivering their own client promise, whilst we, along with the in-house maintenance team, take care of optimising the performance and longevity of their assets over the life cycle of those assets.
Pragma On Key is our homegrown Enterprise Asset Management System (EAMS). Apart from the traditional functionalities generally expected from an EAMS, it has a variety of sophisticated modules that allow the client virtual and real-time access to asset information.
We are based in the beautiful Cape Town, South Africa and we have customers across a wide spectrum of industries in South Africa and also overseas.
We currently support two major versions of On Key:
Both versions support interfacing with other ERP systems like SYSPRO and SAP via custom interfaces that we build. In addition to rewriting a lot of the V4 features onto V5, we also added some really nifty new features to provide our customers with great flexibility in managing their physical assets. In V5 we also started creating a SDK that allows third parties to build additional services on top of the core On Key application platform.
Besides these cool features in On Key itself, we have also IMO come along way in creating a solid software development environment within PRAGMA. The team closed to doubled in size during the last 3 years (we are now 22 people) and we simply had to mature our SDLC practices. There are of course still a lot of areas where we can and will improve on, but I think we have a good foundation to build on for the future.
I want to start a series of blog posts where I write a bit about our software development environment - reflecting on the work environment, what tools and development practices we use and also areas that we want to improve on in future. I also want to spend some time writing about the design of some of the core features within On Key. I don’t quite know how all of this is going to pan out and how many posts I am going to create, but off the cuff, here is a short list of areas that I want to cover:
This list is quite long! Time permitting, I’ll try and keep posting on some topic hopefully once a week. Till later…
A wonderful 2011 for all! I’ve not made many New Year resolutions, but one resolution that I do want to try and keep is to work through my library of ever growing IT books that have been gathering some dust on my desk and hard-drive. In stead of spending time reading through blogs, I want to rather concentrate on broadening/sharpening my skills through working through some of my books. I’ve got quite a few good books where I’ve only read some part of the book and I also want to complete these as well. So without further ado, here is my list of IT books for 2011 that I want to read:
Happy reading :-)
I’m watching the final TeamCity daily build as I type this and I’m super excited about the next major milestone that we’ve accomplished for Pragma On Key, our company’s Enterprise Asset Management System (EAMS). It’s been 30 months of hard work to re-write and extend the system using Silverlight and .NET. We started off as early adopters with the Silverlight Beta’s and .NET 3.5 and with the latest build we are using Silverlight 3 and .NET 4.0 as the technology platform. We evaluated Silverlight 4 but due to some unresolved memory issues in the framework we decided to stick with Silverlight 3 for now. We hope to be upgrading to Silverlight 4 soon here after.
I’m very proud of the way the team pulled through all the difficult times to end up with what I feel is a solid platform to build on for the future. As always there is still a lot of things we can and will improve on going forward, but I think we have come along way since the start of the project. From adopting a new SDLC (SCRUM) to learning a complete new technology skill set (C#; Silverlight, TDD, CI etc.) and in the process close to doubling in team size. Currently we have 2 Analysts, 5 Testers, 13 Developers (me included) and a Software Development Manager. I can honestly say that within the 2.5 years we only had one or two isolated incidents with the team dynamics. I think this is a great testimony to the quality of the people working here at Pragma.
We are now entering the final phases of testing the new release of On Key at a big international client who is planning to go live with the system end of Feb 2011. So after more than 20 000 CI builds, 230 tested builds, 26 820 commits and with just more than 9000 unit and integration tests it is great to finally see the new version of On Key coming of age! We’ve got some real nifty features included in this release and I think customers will enjoy the new web based interface as well. I hope to be blogging a bit more about this and our internal development environment in the future. Well done to all involved!
