It doesn’t take much for negative feelings to start to seep into a team but it takes a lot more to turn a team around and start to raise moral and motivation. The following isn’t based on an in-depth study of development teams across the world but on my own personal experience of managing and observing a number of teams over the last 10 years.

Take of that what you will…

When you look at the make up of a team it will always be staffed by people who raise the game and by some who only bring it down. It’s the nature of taking a group of individual people and asking them to work together for a period of time towards a common goal. It’s the individuality of these people that can take a project and make it fly or cause it to crash and burn.

One thing that’s clear is that it’s much easier for a single individual to bring a team down than it is for an individual to improve the team in any significant way. Negativity will spread like wild fire through a team whilst positivity acts more like treacle and can be much harder to spread around.

But why?

A negative attitude to work is a whole lot easier. Doing less, talking badly about the team or rubbishing the game is much easier than creating excellent content, taking responsibility for your work or stepping outside your defined role and doing something great.

 

What Defines a Negative Developer?

There are many ways in which a developer might have a negative effect on a team. The most obvious is through their general attitude to their current project, be that general low level complaining, pushing back against work requests for no good reason or general slacking off during the day.

It could be a lack of skill development or even a backsliding in the quality of the work they are producing.

But it could also be an attitude that doesn’t gel with the general ethos the team is aiming for. Maybe you want your developers to take more responsibility for their work and how it’s designed and implemented and one or two developers will only work when they are told exactly what they need to do.

Maybe it’s a developer who doesn’t get involved with the daily meetings, mumbling through and obviously not interested in what other people are doing.

At the end of the day, identifying a developer generating a negative effect on a team is usually pretty easy. They’re the ones who are difficult to deal with in usually many aspects of the development process…

 

Team Development

Lets have a look at a few situations, where a green developer is a ‘positive’ developer, red a ‘negative’ one.

In the first situation we have two developers working side by side, one working well and another not doing so great. Maybe one of them has a bad attitude, maybe they don’t want to really push what they are doing. Either way, their contribution to the team is much less than that of the positive developer.

In most cases, this will go only one way. The good developer, seeing their partner being allowed to get away with not working so hard, not having to put in as much effort will eventually start to slow down and equalise with the poorer developer.

It’s much less likely that the poorer developer who is getting away with poor work or a bad attitude will see the better developer and decide to put in that extra work. As a result, you now have two bad developers rather than one.

When does it go the other way? When does the poor developer look around and start to raise their game? The answer isn’t very encouraging.

Take the following situation

Theres a tight balance here, but since it’s much easier for a developer to reduce the quality of their work rather than improve it, it’s easier to slide the wrong way and at that point its’ very easy to see where this will go.

Based on a number of observations it seems at though while a 3:1 ratio might get you some good results it still brings risks because should one developer start to slip it then becomes 1:1 which puts us right back at the start.

In most cases you can only really guarantee that other people will not slip if you have a 4+:1 ratio between positive and negative developers. In a number of cases the negative developer didn’t change their attitude without help but other developers didn’t slip due to the peer pressure of the other better developers.

 

Positive Developers

But in all these situations I’m not giving these positive developers enough credit. A good developer won’t always slack, they’ll continue working hard, producing great content and generally continue to fly high.

But take the following situation…

These developers are good for a reason, be that personal pride, ambition or sheer enjoyment of the work they are doing. And if a good developer finds themselves in the minority for a long period of time, the outcome is inevitable.

Great developers won’t stick around if those around them are not working to their potential or failing to create an environment in which the better developers feel themselves being pushed. And once your great developers leave you have a much higher chance of those left realising they don’t need to actually work that hard to get through the day.

Solving the Problem

There are two ways to deal with poor developers on a team. The first is the most drastic, but initially not an option if you’re working in a region with sane labour laws.

Just drop them.

To be honest I wouldn’t recommend this anyway.  Simply letting someone go generally removes the problem but it can leave a lot of holes on the team and you hired this person for a reason, why not try and get that spark back?

Performance Management structures (you do have a performance management process don’t you?) within an organisation can, if done correctly, not only resolve the problem but allow the poor developer to raise their game and become a star on the team.

Identify the source of the problem.  Does the developer just not like the game, are they having a difficult time outside of work, do they disagree with how work is being allocated or do they just not want to be there?  Depending on what their answers are, you’ll have a good idea of where to go next.

Make sure goals are set. Define goals designed to turn the situation around but don’t just set and forget about them (which happens far to often).  Monitor them on a weekly or bi-weekly basis, setting very short term goals to complement the longer term ones.

Define a fixed period of time.  Don’t just let things drag on with only small improvements here or there, have a deadline at which point things will get more serious.

Make it clear what the end results will be.  Whether they are the chance to work on something different or whether it’s a termination of the contract, make it clear so everyone knows what will happen when the goals are reached or missed.

Keep constant records.  Make sure every meeting is documented and the progress or results of all the goals are recorded daily.

Let them go.  While it is drastic, if improvements are not being made given all the opportunities you’ve given them then there really is no other option.  If you’ve bent over backwards to try and solve the problem and the developer hasn’t taken you up on the offer then there really is nowhere else to go.

And even with those sane labour laws, the documentation you’ve been keeping over the Performance Management period mean you can release the developer from their contract knowing you tried your best and they didn’t want the help.

 

So negative developers, whatever is defined as negative based on the goals of your team, are almost guaranteed to have a bad effect on a group developers.  Negative attitudes to work and development can spread much faster than you might think and will either cause people on your team to normalise at a level far below where they need to be or will simply leave.

It’s vital that as a group these developers are tackled fast, rather than when their effects start to be felt.

I’ve been using Jenkins as my CI server for a while and though user permissions has always been a bit of an issue (I’ll explain why in another blog post covering my Unity build process) running command line tools has never been to much of a problem once it got going.

At least not until I tried to run Ruby 1.9.3 via RVM on our Mac Jenkins server.

I’d developed the Ruby scripts outside Jenkins so I knew they worked, but when I came to run them through Jenkins (using nothing more than the ‘Execute Shell’ build step) it started behaving strangely. Running the script caused the step to fail instantly claiming it couldn’t find any of my installed Gems.

A quick ‘gem query –local’ on the command line listed all the gems I needed were there.

As an experiment I added a build step that installed the Trollop gem (a fantastic gem, you should check it out!) to see if that made any difference, in effect forcing the install in the service that would run the Ruby script. I was surprised when the install worked, but it installed it for Ruby 1.8 rather than Ruby 1.9.

Adding ‘ruby –version’ as a build step showed that for some reason the Jenkins server was using Ruby 1.8.7 rather than 1.9.3.

It turns out that RVM is not available when run through a non-interactive shell script, which is a bit inconvenient when you need it run as part of an automated process.

Searching around I came across this Stack Overflow answer suggesting I make changes to my .bash_profile but those changes were already present meaning I had little luck in finding a solution.

Other suggestions involved rather convoluted steps to just get the thing working, something I neither had the time for nor thought should be required.

Luckily Jenkins provides a RVM Plugin which allows the build step to run inside an RVM managed environment meaning it will respect the RVM settings I’ve set outside of Jenkins…

Now when running ‘rvm list’ via a build script shows that we have multiple versions of Ruby available with 1.9.3 set as the default.

And all of a sudden my Ruby scripts work like a charm!

I’ve recently made the switch to Git and started using it on a couple of project at work.  One of the important things I needed was to get automatic generation of reviews working on ReviewBoard for our Git server and I was in luck because it’s pretty simply to do.

I’m posting this here both for a reminder to me should I need to do it again and in case anyone trips over on a couple of steps that are not highlighted as clearly in the documentation.

 

The Git Server

ReviewBoard works best if you have a primary Git server (we’re using Gitolite at the moment) which most people clone from and push their changes to so using this with any GitHub projects you have won’t be a problem.  It’s against the content of this server that the reviews will be built against.  I went along the path of having a local clone of the repository on the ReviewBoard server (more on that later) so for now it’s simply a case of cloning your repository onto the ReviewBoard server machine, somewhere the user used to run the ReviewBoard server can access it.

 

The ReviewBoard Repository

One you have a local clone, you can start setting up your repository in ReviewBoard.

Hosting Service: Custom

Repository Type: Git (obviously!)

Path: This needs to be the absolute path of the Git repository on the ReviewBoard server machine, not your local machine.  In my case it was simply ‘/home/administrator/git-repositories/repo_name/.git’.  Since we have a number of Git repositories on ReviewBoard they all get put in the same git-repositories folder so it’s easy to set them up.

Mirror Path: This is the URL of the Git repository you cloned from.  To find this, simply run the following git command and copy the address from the Fetch URL line.

git remote show origin

My Mirror Path (because we’re using SSH over Gitolite) is something like git@git-server:repo_name.

Save your repository and now that’s done.

 

Doing Your First Review

Now you can start on your first review to see if everything is set up correctly…  One thing to note is that a review will only be generated based on what you have committed to your local repository.  So if you have unstaged local modifications they won’t be picked up.

So, modify your code and commit.

When using Post Review (you are using Post Review, right?) creating a review is easy – simply call the following from the root of your Git repository (you can make it even easier by adding this to the right button content menu in Windows)

post-review --guess-summary --guess-description --server http://rb-server -o

If all has gone well, the review should pop up in the browser of your choice ready to be published.

 

Doing Your Next Review?

Now this will work fine until you push what you’ve been committing.  Now when you next commit and try to generate a review you’ll start to get rather cryptic errors…

The problem is the repository sitting on the ReviewBoard server is still in the same state it was when you first cloned it as the content you pushed hasn’t been pulled and the ReviewBoard server doesn’t check whether anything on the git server has changed.  So we need to make sure the RB server is keeping it’s local copies up to date.

It’s a shame this isn’t built into the Review Process to be honest, but I can understand why, so we simply need to do the work for it.

All I’ve done is create a simple Ruby script which spins through the repositories in ’/home/administrator/git-repositories’ and polls whether anything needs to be updated.  If it does, it does a pull, if it doesn’t it moves onto the next one.

So as an example, just manually update the repository on the RB servers and try to post another review.  This time it’ll work flawlessly and you just need to set up a system to update the repositories that fits in with whatever system you’re using.

 

Creating Reviews Using Post Review

In the above examples we used the following command to create a review which pulled out all recent commits and generated a single review from that

post-review --guess-summary --guess-description --server http://rb-server -o

But there are other ways to generate reviews.

The following will create  a review containing only the last commit you made

post-review --guess-summary --guess-description --server http://rb-server -o --parent=HEAD^

This one allows you to create a review using the last [n] number of commits you made

post-review --guess-summary --guess-description --server http://rb-server -o --parent=HEAD~[n]

 

I’m not a big fan of Perforce but it has it’s plus points and as a result we use it at work. One thing I don’t use is Perforce’s official Visual Studio SCC plug-in which I think it just trying to be too smart for it’s own good. I do use NiftyPerforce though which is a small, quick and simple plug-in that does exactly what it needs to do.

I recently installed it on a 64bit version of Windows running VS2010 and the 64bit version of Perforce. NiftyPerforce has issues with this, leading to the following dialog when you try to use it.

Could not find p4.exe installed in perforce directory? Well I know it’s there because I use it every day…

If you have a look at the NiftyPerforce output, there’s an interesting line in there…

Found perforce installation at C:\Program Files(x86)\Perforce\?

What? There is no ‘C:\Program Files (x86)\Perforce\’ folder since the 64bit version of Perforce is actually installed to ‘C:\Program Files\Perforce\’

I quickly Google’d the issue and was surprised that there are a few bugs reported on this issue but nothing else.

Anyway, the solution was actually quite simple (if a little hacky). I created a Symbolic Link to the actual Perforce install so to NiftyPerforce it looks like Perforce does exist in ‘Program Files(x86)’

> mklink /D "C:\Program Files (x86)\Perforce" "C:\Program Files\Perforce"

Interestingly it actually works if you remove the /D option too, but maybe that’s just a quirk of Windows?

Now when NiftyPerforce looks for our Perforce install via the (x86) directory, it’ll link nicely to the directory that actually stores the executable.

I’m waiting for this to blow up in my face as other tools start to get confused as to where my Perforce install is, but so far, so good…

I originally posted this to #AltDevBlogADay on Saturday February 25, 2012.

Choice is a wonderful thing. Blind choice isn’t and when it comes to degrees listing themselves as a great place to do a ‘Technical Games Degree’ there’s a lot of choice and not a lot of information available to sort the good from the bad.

It’s this abundance of choice and the issues resulting from making the wrong choice that drives my involvement with SkillSet. Good courses need as many opportunities as possible to stand out from the crowd especially when prospective students may have to narrow down the Universities they’ll investigate let alone apply too.
 
 

What Is The Accreditation Process?

I’ve been a lead evaluator for the SkillSet accreditation process for quite a few years now. The process (I’ll keep it short) involves an application by the University to SkillSet, a paper based investigation into the University covering the skills taught, the attainment and employability of students (amongst other things) followed by an on-site visit by an evaluation team. This visit involves interviews with staff and students, examination of the work done and the facilities available with a recommendation to accredit based on their findings.

This evaluation team is always made up of active game developers working in the discipline the course focuses on.

Courses have and will continue to be rejected at various stages of the process if they are not up to scratch and the criteria used is often very strict with a high barrier for entry. Courses have to be producing quality graduates with the skills suitable for the industry before they can even start to think about applying for accreditation. Cross skill courses (those teaching programming, art and design in a single degree) have never been accredited and never will.

The process and documentation is publicly available so you can have a more detailed look here.
 
 

Student Choice

There are a lot of Universities in the UK and a large number of them provide a some kind of game related technical course. Unfortunately a lot of them don’t provide a high enough level of education to warrant the time and money students spend on them. Accreditation awards allows students to quickly narrow down the kinds of Universities they should be looking at and to spend the time they have investigating the best rather than trying to simply find the ones worthy of their time.

Word of mouth and past experience all goes into this but it still takes time that could be better spent especially when students will be applying to Universities at the same time as working towards their A-Levels, a period of time which may well be the most stressful time they’ve had in their academic career so far.

An accredited University at least gives them the knowledge that they’ll get the right kind of education allowing them to focus on finding one that best suits them rather than anything else.
 
 

Industry Involvement

A lot of developers want to get involved with the education of future game makers and University partnerships such as guest lectures and industry panels are one of the best ways to do that. Universities like industry involvement and some developers can end up being overwhelmed with requests especially if they are already working with other courses and word starts to spread. And because a developers time is so valuable, it helps to be able to target the Universities that we know are already providing the kinds of skills students will need in the future.

Building on a quality foundation allows much more scope for growth than having to start from the bottom and working upwards.

But you might think this is a path to ruin. If the industry only helps accredited courses surely none can become accredited because no-ones willing to work with them to get there!

But that’s not the case. Bigger companies such as Sony, MS, Blitz, Codemasters and others work with those up and coming courses, allowing them to get the point where they can apply for or work towards accreditation. Once that happens, it becomes a positive feedback loop, as the course gets better and gets accredited it leads to more industry involvement which leads to a better course…
 
 

It’s The Skills Stupid

The argument between game focused and traditional Computer Science courses is always the same and is usually spot on. Take a CS course over a game course because in a few years you may not want to work in the industry and the skills you learn on a CS could will put you in a stronger position should you want to do something else.

Without a doubt this is a good argument to make but one that I hope accreditation can resolve. In every evaluation I’ve taken part in the skills we look for and the modules on display show that the course could quite easily be rebranded as ‘Computer Science with a games slant’ rather than ‘Games Technology with a little bit of Computer Science thrown in’. As a result the skills taught will still put the student in a good position should they decided the industry is not for them and while a ‘Games Technology’ degree won’t look as good as a ‘Computer Science’ degree on a CV, accreditation should allow it to grow in stature depending on which University awarded the degree.

As applications get larger and more complicated with every iteration it sometimes becomes difficult to know if incorrect behaviour is down to a bug or badly designed user interface. XCode 4 is an application that has some quirky design choices, some which I really like and some which just baffle.

Here’s one a I found recently when trying something as simple as ‘Find and Replace’

Go to the search tab and search for something (preferably something that exists!). So in the following screenshot I’m searching for ‘defgroup’ which is a Doxygen documentation tab.

Now switch over to ‘Find’ and, as you would do if you did this a while later, change what you last searched for to what you want to replace. In this example, I’m now looking to change ‘client’ to ‘user’. Looking at the following screenshot, what would you expect to be replaced?

In my mind, I expected ‘client’ to be replaced with ‘user’. After all, that’s what I’ve put next to the Magnifying Glass icon – a universal icon for ‘search’ – and the results are for the last search I did, not this one.

But if I select Preview…

It’s actually replacing the results of the original search for ‘defgroup’ and not what I actually asked for, which was to replace ‘client’ with ‘user’. If I’d gone and selected Replace All then the same thing would have happened.

To get it to replace ‘client’ rather than ‘defgroup’ I need to either

• Go back to Find search for ‘client’ then switch back to Replace and do it again
• When entering the new search term, hit enter after typing ‘client’. This won’t do the replace, it’ll redo the search.

 

So, is this a bug or a failure of UI design? Should Preview and Replace All take what I’ve just put in the search box (in which case it’s a bug) or should it use what I last searched for (in which case it’s a UI issue).

Personally, I see this as a bug. As I work down the panel, I add what I what to replace with the new term then select Replace All. Since we read from left to right and top to bottom, information at the top of the screen is more important (the new term) than at the bottom (the results of the last search).

But then, some people could argue it’s a UI issue, and in that case an improvement to this work-flow from a UI perspective would cause this bug to never appear in the first place.

I originally posted this to #AltDevBlogADay on Friday February 10, 2012.

There has been a significant amount of press in the UK about the quality of computer related education at Key Stage 3 and 4 (Secondary School level with pupils ages 11-16 years old) and to a much lesser extent Key Stage 5 (college or 6th form students aged 17-18 years old).

As someone who used to teach ICT at these level I have first hand experience of the kind of topics, software and skills taught to children in classes across the UK, and agree 100% that, as a subject, ICT should be kicked to the kerb and approached from a completely different angle.

And we’re certainly heading in the right direction.

The Next Gen. report by Livingstone and Hope details how we can provide the skills our children require to take our industries to the next level and beyond and even the current Education Secretary Michael Gove is making moves in the right direction. Change is coming and it’s change for the better.

But we must be careful not to rush these changes and to make sure the structure and content is right, that suitable facilities are available and we have the right people in place before we start this process otherwise we’ll be back to square one within a couple of years.
 
 

You Can’t Teach What You Don’t Know

The largest problem facing the introduction of a new, highly scientific and difficult subject is getting the right people in place to teach. And the most important word in that sentence is ‘right’.

Sure we can use existing ICT teachers but it’s clear that the skills required to teach ICT are not the same skills required to teach a Computing GCSE. Also, don’t get me started on the number of ICT teachers who don’t actually know how to use a computer…

We can draft in science and maths teachers to teach elements of the course others are unable to but those teachers already have working place directives in place limiting how many hours they can teach and those hours will already be more than accounted for.

If we really want to create a next generation of developers is passionate and knowledgeable educators pushing that passion onto the open minds in front of them. Sure, anyone can learn enough to teach a subject, but it wont be exciting, it won’t be boundary defining and it won’t make those pupils crave more. Sure, some teachers will really take to this, will develop that passion along with their students, but the majority won’t and as a result the subject could easily be seen as stale, boring and dull.

So the ideal solution is to hire for the shortfall but with approximately 3,900 state run secondary schools in the UK and with many schools having the need for more than one or two teachers per subject that’s a big recruitment drive.
 
 

Custom Content Is Risky But Rewarding

One of the most interesting aspects of this push towards a more computing focused subject is the idea of having a more flexible curriculum. Now this could mean a myriad of things though I’m taking it to mean schools being given the ability to cherry pick the elements they want to teach and to ignore elements they don’t.

This is extremely useful especially with a lack of specialist teachers and it also tackles one of the main criticisms of the National Curriculum, that it creates boilerplate content and restricts creativity and freedom in the classroom.

So by allowing schools to be flexible with what they teach we allow our teachers to experiment and push the boundaries of our children’s imaginations, if they have the knowledge to do that.

But it also opens up the possibility of a (and I hate myself for using this awful and overused phrase) postcode lottery where some schools are teaching more valuable skills than others. It complicates the act of awarding consistent and meaningful grades across the country and it could lead to stagnation as some schools resist pressure to improve as technology moves on.

Though you could make that argument for the education system as a whole due to the varying levels of skills between teachers of all subjects in all schools.
 
 

We’re A Fickle Bunch

With the issues highlighted above there is every chance that if we rush headlong into these changes we risk the first years being less than stellar as people find their feet, new teachers are recruited and less talented teachers are let go.

And this one worries me the most.

With every change of Government, or in many cases with every change in Education Secretary, schools are given newer mandates, newer targets and newer goals. And it’s always in response to a perceived failure by the last Government/Secretary.

If the introduction of a Computer focused subject is seen as a failure in any way then the next Education Secretary will trip over themselves to ‘fix’ the situation. Not by removing the subject but by constantly tweaking and ‘refocusing’, leading to a course that drives schools (and good teachers) away from the subject and turns it into something resembling what we already have.
 
 

ICT Isn’t All Bad

ICT isn’t just Word and Excel. There’s some really interesting content in there that shouldn’t just be discarded out of hand.

I’ve taught lessons in web design and planning using both graphical editors (Dreamweaver at the time) and text editors. We used some rudimentary programming tools in the early years (getting frogs safely across the road by managing traffic light systems) and video editing tools in later years. All of these were exciting, interesting and (usually) generated some pretty interesting results!

I’m confident that these elements will not be lost no matter what comes next, but we must be careful not to discard what we have and what actually works for want of a ‘better’ system.
 
 

Word Processing Skills Are Important

Something we need to acknowledge is that (this might nark some people) word processing and spreadsheet skills, and the ability to use MS products, are important skills that pupils need to have. Whether we like it or not the majority of the world uses MS Office and while this might change in the future having the ability to use these tools improves a child’s employability, their work rate at school and their computer literacy in general.

But the removal of these ‘skills’ from a specific subject is nothing but good news. By teaching these skills as part of other subjects will lead them to be seen as more natural tools that can be used in a wide range of situations rather than just in their ICT lesson.

But we need to make sure that time is available in all subjects to do this and acknowledge that it’ll take a whole school approach to achieve, something that will vary greatly on a school by school basis.

 
 
I’m certainly excited about how these changes will alter how our children see and use computers on a daily basis and how that can only improve the industry in general. But there are significant challenges that must be faced before we can move forward, confidently, and create a true next generation of developers.

I originally posted this to #AltDevBlogADay on Sunday November 27, 2011.

Successful communication is one of the most important aspects of a well functioning and productive team. Without good communication between peers, managers, publishers and anyone else involved in the game development process a team will not perform at it’s best.

If developers do not feel confident in the reasons behind their work, if they don’t fully understand how their work will fit into the project as a whole or indeed when it will be required, the team will produce lower quality work with last minute changes and requirements fostering an atmosphere of distrust and crunch.

But communication is one of the most difficult things to get right but so costly when it’s done wrong.

The following are methods I’ve used over the years to try and improve communication within the team. I’d be very interested to hear other ways people have tried too!

 
Team Wiki
Having an open Wiki that people can contribute information and notes is a good idea for documentation and persistent information. It is not a good tool for perishable short term information. Documentation on team processes (getting the latest build, creating submissions, setting up PC’s etc.) is usually the kind of information that finds a home on a wiki and while it’s useful it’s not something that affects the team on a daily basis.

And as it requires people to physically search for the information in the long term people don’t bother looking for new information on a regular basis.

As a result, the Wiki is useful but doesn’t actually improve the day to day communication on a team.

 
Blogs
We have a team blog that people update about 2 or 3 times a week, usually discussing their recent work, posting up screen shots or letting people know the state of the project. It’s a nice simple way to push information to the team, though it does require everyone to contribute to the blog to get good cross team communication going.

Discussions can take on a life of their own which is actually a good way to gauge buy in into a project but can’t be used to judge the success of the process.

But you’d be amazed how many people don’t have any kind of RSS feed reader set up…

 
Micro-blogging
Internal mico-blogging tools like Yammer or Status.net allow people to quickly thrown up what they’re working on, problems encountered or general team information. The best thing about micro-blogging is it’s push communication style with peoples updates being automatically feed to clients which people can update as much as they want (I usually recommended at least twice a day).

But so far I’ve had very little success with micro-blogging tools in a team environment.

Not because the idea was bad (when it worked it worked well) but I’ve yet to find a service where the official client is anywhere near usable and able to filter out the information people don’t want to read. Without a good way to filter and push information where you want it (like all the best third party Twitter tools do) it either becomes an information overload or a sea of noise, neither of which improve communication.

 
Wall Displays
Walls are valuable real estate especially in an Open Plan office and I’ve rarely seen them used to their full potential. But highly visible walls in the middle of a team area are one of the best ways to communicate information across a team.

As an example on my current project we have the entire timeline of the project (it’s only a short one) with dates/deliverables clearly indicated, a ‘where we are right now’ marker and a description – feature by feature – of what is required for a given milestone.

Next to that we have our sprint wall which is our most ‘live’ wall display. But position is key and in our case the sprint wall’s impact on the team is reduced due to it’s rather awkward position between a big TV, a constantly spinning fan and quite a lot of server machines. But I did say wall space is valuable real estate and it’s always hard to find a compromise between distance from team and accessibility.

 
Morning Meetings
Morning meetings are one of the best ways to push information across a team but I’ve found that you need to follow a few rules to make them really valuable.

• Keep the groups small. I’ve lost count of the number of 20+ people stand up meetings I’ve seen where the majority of the ‘participants’ are looking bored or simply waiting for their turn. If you’re groups are not small, the information is less targeted and much less relevant, meaning more information is lost than actually passed around the team.
• Keep them focused. There is nothing worse than 1 out of the 6 people speaking for 15 minutes about the most intimate implementation details, leaving everyone else itching to get back to their seats to carry on working.
• Don’t make them reporting sessions. If everyone is talking at a single person (usually their manager) take the manager out for a while and get people used to talking to each other as it makes it much more likely for people to take in what is being said.

 
Milestone Reviews
I love the concept of a milestone review. Everyone playing the game, lively discussions about what went right, what went wrong and what we can do better next time. But it’s easy for these to be less than stellar if not approached in the right way.

If these reviews are not focused, maybe even as structured as a schedule or points to cover, people may start to feel unsure as to what they can comment on or what exactly they should be doing. You’ve also got to make sure that people feel comfortable both giving and taking criticism and manage the situations when that goes pear shape (and sometimes it will).

I’ve found that when done right, when people contribute to discussions and when people can (importantly) see change as a result of these reviews, the quality of information coming out of them is invaluable. It also has the added bonus of making people feel like they are making a difference to the team and allowing their thoughts to be heard.

 
Sprint Planning
The days of managers sitting in a room building up a schedule and dishing it out to the developers is (almost) long gone. And there’s good reason for it.

Getting a group of developers (again with the morning meetings it needs to be small and focused) to discuss, schedule and plan the work ahead significantly improves the knowledge people have of what is happening across the team. Again, if people feel that have a say in how work will be implemented, how it will be assigned and when it’ll be done by is vital to spreading information about the project and the work being done.

 
So those are a couple of methods I’ve used to try and improve communication and information across the team. I’m sure there are plenty more (and I’ve tried a few which have been colossal failures) so what methods have you used and how well did they work out?

 

Title image by deathtogutenberg.  Used under license.

 

I originally posted this to #AltDevBlogADay on Saturday November 12, 2011.

Refactor: Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.

 

I pretty much wish that word had never been invented. The above definition (taken from Martin Fowler’s Refactoring Home Page) seems to have lost nearly all meaning when used in day to day programming conversations.

To further describe the original definition of refactoring:

Its heart is a series of small behavior preserving transformations. Each transformation does little, but a sequence of transformations can produce a significant restructuring.

 

But when someone comes to me and says “I’ll just refactor that…” I can no longer assume to know what they’ll be doing. Based on how people now use this term it could be any one of a number of things including (in order of violence)

• Making small changes to make the system more understandable, simpler and easier to use without affecting it’s perceived behaviour
• Optimising elements of the system which should hopefully(?) not effect the external behaviour
• Making wide ranging changes to a system which will effect elements of its behaviour
• Deleting the whole thing and starting again without even looking at what we have now

It seems like there is a reluctance to use the words ‘re-write’, ‘modify’, ‘break’ or (in a some cases) ‘trash’ when discussing intentions towards an existing system. As a result what was a very descriptive and clear term has lost all meaning and resulted in something what can no longer be used to clearly describe a useful and often necessary development process.

Do I wish the word hadn’t been invented? Maybe I just wish it hasn’t taken on an image that ‘refactoring’ is somehow cooler or more elite than simply saying what you mean when describing what you’ll be doing.
 

I originally posted this to #AltDevBlogADay on Friday October 28, 2011.

I recently came across an interesting post over on Agile Game Development titled ‘Scrum Prohibits all Specializations’. The part that stuck me was the following:

I understand that Scrum has been applied mainly to software products and that the elimination of “specialties” means that the database programmer, UI programmer and QA engineer should all be able to perform each other’s roles equally. This is valid.

 

Now I’m concerning myself with only the technical side of an agile team but I’ve seen this raised in a number of different agile circles. In those cases there seems to be the impression that swapping a database, physics or audio developer with any other specialisation like UI, animation or graphics and an agile team should be able to roll up their sleeves and perform the different roles to the same level with the same level of outcome.

To me, this is emphasised in how the product backlog is often used, which is a priority and risk ordered document that doesn’t take into account the skill set of the team that’ll be working on the final product.

Processes such as pair programming, constant re-factoring and code reviews (to name but a few) seem to be seen as ways to not only communicate intent and project information but also skillset and ability across an entire discipline.

 

So What Do Specialists Bring?

But we have specialist developers for a reason. They are great at what they do, they understand the area in which they work and they know how to get the best results in the shortest amount of time. They have a passion for the area they are focusing in which usually means they’ll go a step further to research their area and keep up with developments which other developers may not have the time or the understanding to do.

By spreading your talent thin and assuming that people can fill each others shoes leads to the following issues

• You are not respecting the knowledge, skill, experience and passion that a specialist can bring to their work and as a result not respecting the developer themselves
• You’re reducing the impact these people can have on a team and it’s often the experienced specialists that inspire younger members of the team into an area they are interested in
• The ability of those specialists to learn more about their area and pass that onto others is drastically reduced.
• The ability for the team to push their development boundaries will be indirectly reduced as everyone on the team aims for the ‘generalist’ role to fit in

 

What About Pair Programming?

Now I’m a massive fan of the various agile techniques out there. Pair programming is an excellent mentoring, development and training tool but it won’t allow one developer to fit into the shoes of another. True, they will have a better understanding of the tools, pipeline and systems being developed which will allow them to fill in, but it won’t transfer the amount of background experience the specialist has.

The same goes for code reviews, constant refactoring and feature discussions. It spreads the knowledge which reduces the risk to the project should the specialist not be around when needed, but the core experience and drive that made the specialist who they are simply cannot be replaced by dropping in a new developer.

 

But Everyone Does A Bit Of Something Every Once In A While?

Of course, sometimes people do need to jump into another developers shoes (illness, staff turn-over, hit by a bus etc.) but this is not the same as expecting a people to be able to fulfil each others roles equally. We can take steps to decrease the impact this will have on the team using the processes mentioned above but it will not allow those specialists to be inter-changed as the project continues development.

We need specialists in any development field because it’s these people that can push their respective fields in directions we might not even be able to imagine. By treating them as interchangeable we might be gaining flexibility to schedule our staff, but we’re losing something far more important and vital to a development team and the products they are creating.

As I said to some one (in 140 character or less of course) when pointed out that people have done this, and even the author of the original post has done it (see the comments)

I’m sure he has done it, I’ve done similar, but it doesn’t mean we did both with the skill of an expert of either.