Working as an individual or as a team member

In one of my recent posts about teams a friend of mine commented 'We are the Borg. You will be assimilated'. Though this was in jest it made me evaluate my thoughts about collaborative teams vs the individual. This post is really a brain dump of my thoughts about this issue so I apologise if it's a bit disjointed.

At one end of the team work continuum is working on your own all the time and at the other end is working as a team at all times. My view is that, like everything else, it's a balance. Being at the extreme of end or the other isn't optimal. In addition people also fall somewhere along the introversion - extroversion spectrum. Those that trend towards introversion prefer to work individually and those who trend towards extroversion, team work. Software development seems to attract more introverts than extroverts. That said, I trend towards being an extrovert and perhaps that's why I find team work better. There's also another continuum that we have to take into account and that's the spectrum of creativity. Though this spectrum doesn't correlate to the ones I've listed about there are some other connotations that we have to take into account. Though everyone has a level of creativity, there have been numerous studies showing that those who are on exceptionally creative end of the scale are also prone to downtimes due to depression. I myself go through periods of extreme creativity and extreme depression.

As I mentioned above working only as an individual or only as a team isn't optimal. At the extreme end of team work, where everyone sacrifices their individuality to the team, people are prone to group think and lack of creativity. On the extreme end of working as an individual there can be motivation, communication and transparency problems.

I've found that we need to work somewhere in the middle of the team work spectrum. We need times where we can work individually and times where we collaborate.

Our work environments need to reflect this too. We need individual and collaborative areas. The trend has been away from individual cubes or offices to working in open spaces. If you are in an open workspace all of the time one option is to use headphones for certain periods of the day, though not all day, to get the solitude needed. 

As much as working as a team is important, it's equally important to embrace individuality while doing so as everyone have different backgrounds and experiences. If you don't have diverse backgrounds/experiences, your team is very prone to group think and lack of creativity. Diversity in this case can stimulate creative conflict which is one of the key features of a good team. Part of that though is to make sure that everyone's voice is heard. If someone feels that they aren't being heard they will withdraw and not contribute. It's also important to make sure that any personal conflicts that happen within the team are discussed openly. If communication goes on behind other people's back it can affect the overall performance of the team.

People working by themselves can be extremely creative but can also miss out on the diversity of ideas from others. We can have a lack of transparency as a lot of things are just in their heads. This also becomes an issue if we need to transfer knowledge between people.

Finally for people on the high end of the creativity spectrum, during times of depression working as a team is essential especially using techniques such as pair programming. This is because they can feed off of the energy of the person or people they are working with to help them through it. Otherwise they run the risk of going dark for days at a time.

Anyway this post is just skirting the edges of a number of complex topics, but I wanted to get them down to help solidify my own thoughts.

I'd love to know what you think about this. Am I missing something big or misunderstanding something?

Thanks to +Steve Streeting for inspiring this post.

[Edit]
There's been an interesting discussion about this post here:

https://plus.google.com/105719943141175185993/posts/PF8ZDqBNkxs?fd=1

Sustainable pace at work and having a special needs child at home

Sustainable pace within software development teams has been discussed in depth for many years. I first came across it when I was introduced to eXtreme Programming in 2000. It's a sad state of affairs that we have to explain that knowledge workers perform better at a pace that isn't to fast and not too slow, but at an even cadence.

This isn't just good for productivity at work, but also for those of us with children with special needs. If you don't have a child with special needs you may not be familiar with the amount of stress parents are under. Firstly there's the stress just from the fact that your child has additional needs. Then there's dealing with the additional needs themselves. (In my case there's constant supervision, many sleepless nights, meltdowns, developmental delays, sensory issues, etc). In addition to this there are appointments and paperwork that needs to get done. There's also worrying about the future too. The list goes on.

We have all this and have to hold down a job. Working the occasional night or weekend is fine, but because a lot of us are so tired already this can't be maintained for long periods of time.

This is where sustainable pace comes in. It levels the playing ground between parents of children with additional needs and everyone else. We can come in on time and leave on time without feeling guilty or stressed, because everyone else is doing the same. It also lessens the risk of burn out or getting sick.

What are your thoughts on this issue?

Are software maintenance teams an anti-pattern?

This might be a controversial position, and I'm not trying to make light of the good work software maintenance teams do, but I'm questioning the need for maintenance teams at all.

The idea behind having a maintenance team is to take pressure off of software development teams so they don't have to deal with triaging customer issues and fixing bugs. Sometimes this also includes creating minor enhancements to the software. There's also the economy of scale where one team can support many applications across an enterprise. Note: I'm not talking about support teams that help customers and may in turn create bug tickets (that's a conversation for another day).

That said, handing software over to another team is problematic and expensive. It's not possible to transfer all of the knowledge that has been gained through the development cycle and the application may have to be documented heavily to compensate.
In a lot of organisations I've come across the idea of having a maintenance team is standard practice and sometimes considered a best practice. This is something that I think we should challenge.

To me when I hear about software being handed over to a maintenance team it points to one thing, they are having quality problems. There are too many defects escaping to production and the developers are getting bogged down with fixes so they aren't able to create new functionality as quickly.

Rather than putting a bandage on it, the organisation needs to step back and ask themselves why they are generating so many bugs. The bandage may take pressure off of developers, but also tells developers that they don't have to be too vigilant about finding bugs before release because the maintenance team will fix them.

There are many reasons for quality problems within an enterprise, too numerous to mention. That said, there are a number of things a software development team can do to improve quality and reduce the need for a maintenance team.

1) have quality as your number one organisational and team value and actually practice what you preach rather than paying lip service to it.

2) give the team the space to create quality software.

3) use techniques to push defect detection as early as possible (TDD, continuous integration, pair programming, pair testing etc).

4) focus on ways to improve quality in some of your retrospectives and make sure that the action items actually get tested and implemented.

5) make sure your code is potentially releasable at the end of each sprint.

6) visualize your bugs so that everyone can see them at all times.

Yes you probably will still get bugs in production, but they should be fewer and shouldn't overwhelm the development team.

What are your thoughts on this?

Which member of the Agile/Lean software community influenced you the most in 2011?

Nominate the member of our community who influenced you the most in 2011. Please one nomination per person. Based on this list I'll set up an online poll.


Leave the person's name in the comments below as well as their Twitter id, G+ or blog URL.


This was originally posted on Agile+

The role of a tech writer on an agile team

There is a common myth surrounding the agile community that being agile means no documentation. This is a huge fallacy. The agile manifesto states clearly that we value working software over comprehensive documentation. It also states the following:

"That is, while there is value in the items on
the right, we value the items on the left more."

For me as long as the documentation is useful and will be read we should still do it. This might be user manuals or supporting sales material. Whatever the document it's often a good idea to have a technical writer on the team. Some clients do require  comprehensive documentation even if it's just a checklist item. If they can't be dissuaded and they are willing to pay for it then I say do it. So yes we do want a writer on the team.

One mistake I've seen teams make is to start the documentation for a story after it's been completely developed. The theory is that this prevents rework, but the side effect is that there's often documentation left undone at the end of the sprint. The tech writer gets frustrated due to the lack of time left and can feel that it's their fault that the sprint commitments weren't met. This can lead to the documentation to be written one sprint behind the development. What's the big deal with that? Well if there are any questions for the developers they're already focusing on something new. These questions can disrupt the developer through causing them to dredge up the memory or go back to the code to remember what they did.

So how do we fix this? One way is to have the tech writer attend all of the important design meetings with the developers and testers. They should get enough information to start work. Sure there maybe some rework and screenshots that need to be taken can't always be done until the end, but you've now lessened your risk for not getting everything done. If the writer has any questions they can ask the developers while everything is fresh in their mind. Another strategy is to pair the writer with a tester on the team. Testers are great at seeing all of the intricacies of the story and can communicate that to the writer.

I'm interested to hear about how other teams deal with technical writers on their team. 

Android Contact Storage issues when syncing Twitter and/or Google contacts?

For the last 6 months I've slowly been running out of phone storage space on my HTC Desire. This means that I've been hovering between 3 and 16 MB free for a while. Unfortunately the HTC Desire only has 128 MB of internal storage and as soon as I go below the 15 MB mark my phone stops syncing its apps.

Until recently I didn't realise where the space was going so I tried a few things, short of rooting my phone, to fix it.

Firstly I made sure that all apps that could be moved to the SD card were moved. This helped slightly but I soon realised that it didn't help as much as I had hoped, this is due to the dalvikCache. Even though an app is on the SD card, Android creates a dalvikCache instance of it on the main phone storage which is usually smaller than the original but not always by much.

Secondly I deleted all applications that I didn't need. Then I started to delete applications that I do use in descending priority order. Three days ago I was down to only having the apps that came loaded onto the phone, the Google+ app and DiskUsage. Blogger, Facebook, Evernote, Feedly and Twitter had all been uninstalled.

This was the last straw and I made a last ditch effort to find a solution, or I'd go ahead and root my phone.

Though I'd searched for solutions many times before, this time I came across an article that gave me some hope.

Clear Storage Space on Your Phone Without Rooting

This article mentions a Contact Storage bug which causes it to bloat but doesn't give a great amount of detail. Mine was around 50MB so I figured that this post might be onto something. Long story short, I tried the solution listed in the post but wasn't able to restore my contacts other than the ones that were saved to my phone as opposed to my Google account. What this did allow me to discover was that I had over 1200 contacts synced to my phone from Google+ each just containing a URL to their profile. I believe that this could well be the reason why my contact storage was so huge rather than a bug.

What I ended up doing to fix the issue was as follows:

1) I uninstalled Google+
2) Turned off all app syncing within Accounts & Sync
3) Deleted my Facebook for HTC Sense account entry from Accounts & Sync
4) Cleared my Contact Storage
5) Restored my backed up phone contacts to my phone storage (not the 1200+ that were attached to my Google account)
6) Verified that the small amount of contacts had been imported correctly
7) Added a new Facebook for HTC Sense account and made sure that Sync contacts was on.
8) When the Facebook sync was complete, I verified that there were entries in my people app and re-linked accounts appropriately
9) Reinstalled all the apps that I wanted.
10) Turned on all the app syncing again, except for Sync contacts for my Google account and my Twitter account.

Note: I did lose some contacts so I don't recommend you do this yourself

When this was all done I had most of my contacts back and Contact Storage was down to about 2MB in size. For now I'm not going to sync my Google or Twitter contacts to my phone as I have between then 1900+ people. This will hopefully give me enough room until I upgrade my phone in 8 months.

I'm curious of any other heavy users of Google+ or Twitter have experienced similar problems.

Has the ScrumMaster role evolved due to a vacuum in line management?

If you look at the ScrumMaster role you'll see that they are there to serve the team. They are there to guide the team to improve themselves and the way they work. They are there to protect the team from unhelpful distraction. They are there to help the team overcome any obstacle that is preventing work from flowing smoothly. They are there to help the team self organise rather than telling them what to do. They are there to help the team deal with conflict and finally they have the authority from management to do all of the above. I could go on, but these are the most important parts of the ScrumMaster role.

The thing is all of these responsibilities are all things that a great manager does, so why does the ScrumMaster role even exist?

To me this implies that there are managers out there that don't realise that the items listed above are part of their role. This is especially prevalent in IT where managers have been pulled from the ranks of the company's senior engineers and given some management training. This isn't a bad strategy as managers should have the experience in the field that they are managing, but I'm of the view that management is something you need to have a passion for rather than just the next step in your career ladder. If you don't have the passion you won't necesarily drive yourself to improve continually. Good ScrumMasters have the passion and drive themselves to improve as well as their teams.

Some other posibilities as to why the role exists is due to the inherent lack of trust of management and company's with a culture of fear. The team tends to trust the ScrumMaster more as they have no authority over the team other than that agreed to by the team. In addition, as I mentioned before, they are responsible for protecting the team from undue distractions.

My final thought as to why the role came about is due to consistency. Management styles differ greatly between people within an organization or even the same department. Add in the fact that in larger organizations, managers change every few years which can cause the way the team works to change drastically. With a ScrumMaster you know what you are getting as the responsibilities are pretty clear. Yes each one may do things slightly differently but the core should be the same.

Of course the ScrumMaster is there in another capacity and that is of a pseudo project manager, but this is needed less as the team self organizes.

I'm not trying to bash line managers here, but I do believe though that both roles should be very similar. I also believe that both roles can work together to achieve great results.

I'd love to hear your comments about my post. Do you agree or disagree? Have I missed something?