Sharing bad news

If you have to give someone bad news, do it straight away. Don't draw out the conversation. Your body language will give the recipient hints that bad news is coming. The longer the lead up the more stressed they'll become and more likely they'll react badly.

Team visions

A vision is an often missing piece from software development teams. It is a powerful technique because it allows them to envision where they ultimately want to go. This allows for focus and then they can then take small steps to get there.

I've found that teams rarely know where they want to go other than a loose self organising team or high performing team. Not having a vision can stop them from making effective improvements in how they work. Small changes are made but can be scatter shot. Eventually they may become an effective self organising team, but not as quickly as they could have.

So if you don't have a vision create one in your next retrospective. It can be a lot of fun discussing what you want your team to be like in an ideal state. Just remember though, the vision should be revisited occasionally because it can change over time.

Does your team have a vision?

Team values and changes in membership

Following on from my post yesterday about changing team membership and working agreements, today I'm going to talk about values.

Most of the values a team holds are learn through osmosis. As the team works more and more together they generate a shared mental model of how the team works and interacts.

So what happens when team membership changes? The team's values might well be invalidated. Perhaps a new team member doesn't agree with the current values, but if the values aren't made explicit how would anyone know?

Getting these values out of the teams heads and talking about them is a valuable exercise. Not only does it allow the team to understand what values they each hold, but also the ones they have in common. The conversation is the most important part of this. After which they can document and display the values. This also has the added benefit of showing the surrounding company what you value and may spur more conversation.

Back to our new team member. He or she might value the same things. In that case, great. If they don't agree then there's a conversation that needs to be had. The team might still agree to keep the same values, but with buy in from the new member. They might also agree to change them.

The important things are the conversation and the buy in from all team members. Without the buy in it's hard for someone to really live those values.

Finally compare your values to that of the surrounding organization. Is there a match or mismatch? This may generate more conversation at a higher level.

Have you made your team values explicit? What do you value?

Working agreements and changes in team membership

Teams have both implicit and explicit working agreements. The ones the team does without thinking, and the ones that they've agreed on and written up. Explicit agreements can become implicit over time as the team internalizes those agreements.

What makes us think that adding or removing people from that dynamic won't affect the team?

Whether they are implicit or explicit, working agreements can be invalidated if the new team membership don't all agree. The entire team is meant to agree and not impose their rules on the new membership. The team has to find it's own path again.

Don't forget to iterate!

In the 1964 case Jacobellis v. Ohio, Justice Potter Stewart wrote that hard core pornography was hard to define, but that he'd know it when see saw it.

This also applies to product development. It's hard to define what you want, as people have a hard time envisioning the future. When someone actually has something tangible they can make better decisions about what they want. i.e. they know what they want when they see it.

One of the reasons why agile software development works is by shortening the feedback loop and adjusting a project based on the things that have been learnt over it's lifetime. This can be done in a couple of ways. Firstly by doing incremental development and secondly by doing iterative development. Unfortunately many Scrum teams focus on the former and forget about the latter. Incremental development it easy to understand and is baked into the Scrum cycle. It's expected that at the end of a sprint that we have a 'potentially shipable product increment'. I believe that this wording is partially responsible for creating a misunderstanding that we should only be incrementing.

One anti-pattern I've seen is when a team tries to develop an entire feature in a story so that they have their potentially shipable product increment. This feature is complete as far as they're concerned so they can then proceed to the next story and do the same. These stories then only get reviewed by the Product Owner (PO) in the sprint review meeting. Though there's a much shortened feedback loop compared with traditional software development projects, we've lost some of the learning. We shouldn't just learning about what features need to be developed, we should also be learning about how a feature is developed. This is where iterative development comes in. We need to getting something into the hands of the PO as quickly as possible so that they can see if it's really what they want.

I recommend doing the following:

1) Treat each feature like an experiment. Build a hypothesis about what you're trying to achieve then go about proving or disproving it.

2) Slice your feature into stories as thinly as possible. Start with the simplest possible implementation of the feature. Put things such as safety or experience factors into subsequent stories.

3) Shorten the feedback cycle. Talk to your PO throughout the sprint. Show them as the feature evolves and gather feedback. Some of this feedback will generate more stories. Others will allow us to make smaller course corrections. We're continually learning.  Also remember that your PO is meant to be a partner in this effort, a collaborator.

4) Deploy each completed story into a staging environment so that the PO or trusted end users can start playing with it. Remember that just because a story is of a potentially shipable quality, it doesn't mean it can be shipped. That decision is up to the PO.

To sum it all up, don't forget to iterate!

Agile Cambridge session: Questions not Stories: Build a business-value oriented team

The last session I attended today was run by Adrian Howard. Going into it I thought that the session was going to be about replacing user stories, but this wasn't entirely the case. Essentially it was about starting with a user story and then conducting an experiment.

Adrian used the following example:

As a potential customer I want to be able to signup with my Twitter account so that I don't have to fill out a registration form.

The first step is to turn the story into a question.

As a potential customer I want to be able to sign up with my Twitter account so that I don't have to fill out a registration form?

The next step is to ask why the story is needed. Too many times we just assume that there are good reasons for it and don't question. After finding out the main reason why, we should design a hypothesis to validate that assumption and then conduct an experiment to prove or disprove it.

Adrian's team wanted to validate that a percentage of new users would want to signup using twitter.

To do this they put a fake Twitter link page which logged how many people clicked on it. The user was then redirected to a page saying that the Twitter signup was currently offline and redirected them to the normal registration page.

After the experiment was over they found that very few people actually clicked on the link, so they didn't build the feature. Traditionally the team would have just built it and no one would validate if it was ever used after being deployed.

This has potential to be a catalyst for turning an organization into one of experimentation.

I'm still mulling this over, but I think it has great potential.

What do you think?

Sleep, creativity and culture

Note: The following is a brain dump of what I currently understand and what I'm trying to understand.

I've been thinking a lot about time recently and how we're dominated by the clock. It controls every aspect of our lives, even during sleep. The following are my thoughts based on information that I've read and my own life experiences.

Due to the pressure of modern life, most of us function with less than the recommended eight hours. This is mainly because of our culture. The dominant work culture frowns on sleep, especially around the topic of entrepreneurship and leadership. Sleep is for the weak. There's time for sleep when you're dead. These are just some of the phrases that are indicative of that culture. There's an increasing amount of information about why we should get more sleep and we know that we should but we don't.

Sleep is extremely important for our overall health and especially for our brains. During sleep the brain basically reorganizes itself, choosing which connections to make and what to discard. Sleep also improves our creativity. It's also been shown that one of the times we're most creative is when we're sleepy. This is because you tend to make more connections between disparate thoughts at this time. To harness this creativity it's recommended that we ease into our day, not rush out the door. For example, I spend the first 15 minutes after I wake up just mulling over what ever comes to mind. I also take a leisurely walk to the station each morning in which I do the same thing. Those times are when I tend to have some of my most creative thoughts and I'm not a morning person.

Perhaps our sleep cycle is a result of our modern lifestyles. I've been reading a few articles recently which have found that eight hours of straight sleep isn't necessarily our natural sleep cycle. It appears that information is coming to light that historically humans would sleep in two parts. We would enter what has been called first sleep, or little sleep, wake up for a few hours and then enter a second deeper sleep. The single eight hour sleep cycle appears to have been a relatively recent occurrence in the grand scheme of things. This might account for people who often wake up in the middle of the night for several hours. Unfortunately because we are dominated by the clock this time awake. It also matches the sleep cycle of some children with autism. My son for instance will wake for several hours a few nights a week. He'll generally be content to quietly play or talk to himself for a few hours (though that wasn't always the case), before returning to sleep.

Waking up in the middle of the night can cause undue stress for some. We worry about not having enough sleep for work the next day which decreases the likelihood of getting back to sleep. This worry is caused by the the work culture I mentioned above and our lives being dominated by the clock.

So why do we stress about when we get into work? This is something I've never really understood for knowledge workers. If you have a meeting then it's a sign of respect to the other participants that you be there on time. Being late sends an implicit message that your time is more important than other peoples. Getting into work at some arbitrary time which doesn't seem to add any value and causes stress. If I've had a bad night sleep isn't it better for the company that I get in later so that I can perform better? Being exhausted at work does no one any good. We're all adults and should be trusted to put in the hours the company requires of us without having to stress when you're arriving or leaving. How many times have you sat at work at the end of the day, but you're too tired to do anything, especially late in the week? What happens is that people make themselves look busy. Wouldn't it be better for that person just to head home early and recharge?

Another idea is for companies to let people nap during the day. Several studies have shown that taking a nap, where you achieve a deep sleep, improves creativity.

All of the above mainly applies to people in creative jobs. We tend to need large blocks of time to concentrate and achieve flow. This is different from managers who generally work in smaller hour blocks. Getting these large blocks of time might require being on a different schedule from managers. For example, working late in the evening because there are less distractions.

We need to change our work culture and habits to help improve the creativity of knowledge workers rather than ruling by the clock.

What do you think?

Do not fear your Product Owner

The role of Product Owner (PO) is an essential one, but is also one that teams often fear. I've felt that fear myself in some environments.

Perhaps they are higher up in the org chart, but what does that matter?

Your PO is not your parent and you shouldn't assume a parent/child relationship. They are your team member in producing high quality software. Sure they might have different responsibilities, but you're all professionals and experts in your own domains. Treat each other as such.

• Don't be afraid to ask them questions. 
• Don't be afraid of making mistakes or taking risks
• Don't be afraid of challenging them. 
• Don't be afraid of telling them when they aren't doing what they need to be doing to help the team. 
• Don't be afraid to tell them if their actions are detrimental to the team.

Try not to be afraid. If you are, recognise it and then push through. Work together as professionals.

What do Kung fu and ScrumMasters have in common?

I look at being a ScrumMaster a bit like Caine from Kung fu, but without so much ass kicking.

Instead of going from town to town we go from team to team. We teach them, coach them, guide them and leave them when we're no longer needed.

This isn't the type of ScrumMastering that you're going to learn from a woefully inadequate 2 - 3 day certification course. This is what you're going to learn from practice, self improvement and others experienced in the field. That said, even if you're new to this, it's important to understand where your journey is going to lead you.

Firstly though we need to look at the primary roles of a ScrumMaster a little differently.

These are the ones I perform.

1) Guide the team towards self-organization.
2) Continually challenge the status quo and help the organization improve.
3) Help other ScrumMasters improve their practice.

Ultimately a self-organizing team will no longer need you. That's when you can walk away, head held high and say "My work here is done".

ScrumMasters and impediments

One of the roles of the ScrumMaster is to help the team resolve impediments. i.e. things that are stopping the team or a team member from making forward progress with their story or stories. The keyword above is help. Do not necessarily do it for them. If a team member can resolve an issue, let them. Sure a SM can help have the difficult conversation or chase some hardware that's required, but we should understand why they can't resolve it by themselves. Perhaps they shy away from conflict and they are to scared to have the difficult conversation. Perhaps the hardware requisition is distracting them from coding. After understanding why the impediment cannot be resolved by the team, work with them to resolve it together. Build up their confidence to do so. The SM is the teams coach and should be helping them self-organize. By resolving all impediments you're increasing the teams reliance on you and decreasing their ability to self-organize.

How do you see the role of the ScrumMaster for removing impediments?

This is who I am

I am:
Not content with business as usual
Continually improving
Building my own opportunities
Following the value not my career ambition
Following my passion
Continually learning
Dedicated to my family
Doing what I think is right
Working across white space not in silos
Doing what needs to be done
Not asking permission but asking for forgiveness
Working regular hours

Some of the things I need to improve at.

All of the above and...

Handling conflict
Obsoleting myself
Standing up for myself
Listening to others
Putting myself in other people's shoes
Helping others
Taking care of myself

and much much more.

Who are you?

A message to my fellow developers: I want my apostrophe back

On the web my last name is a blessing and a curse. The name itself isn't the problem, it's just how it's mutilated in the name of security

More often than not, when entering my last name into a web form, I receive a message that it's not valid because of the apostrophe.

It is a valid name, it's mine. It's O'Sullivan not OSullivan and I'm rather attached to it.

This isn't just limited to apostrophes, but certain other characters too. For example, a friend of mine has a space in his last name and experiences similar problems.

Yes I know that we should sanitize input to help prevent things like SQL injection attacks and cross-site scripting, but the former can be handled by not generating SQL with data baked right in. We can use placeholders or a full blown ORM to help prevent attacks. The latter with encoding data correctly.

You may think what's the big deal, but can you guarantee that you have all combinations of possible characters for last name validation? A simple a to z match isn't going to cut it.

One of the blessings about having an apostrophe in my name is that I learnt how to deal with them safely very early in my career.

Things have improved over the years though. My name used to break many an app, these days very few. If I do find one, this tells me that I shouldn't use their service.

My biggest problem with all this is usability. Earlier I mentioned telling the user that their name is invalid, but the bigger problem is with credit card processing.

Pretty much every site I've visited that asks for credit card info, asks for your name as it's written on the card. If you can't enter it exactly then it puts doubt in the mind of the user as to whether or not their transaction will succeed. There must be a reason why it has to be exact right?

So please can I have my apostrophe back. 

Who's with me?

Pet peeve of the day: the business

It really makes me cringe when people in IT or software development refer to those outside of those departments as 'the business'. It night seem innocuous, but there are certain things that this simple phrase implies.

1) IT and software development aren't part of the business, where the real work gets done.

2) it creates an us versus them culture.

3) if you refer to yourself as separate from the business, people will treat you that way.

It's amazing how a simple phrase can pack in so many meanings. Just remember that we are all part of the business.

Retrospective safety, we've got it backwards

When we talk about sprint retrospectives we talk about them as a safe place for team members to discuss their issues. This safety is normally from people external to the team, often management. This isn't what it's about, it's about having a safe environment to express your own personal views without fear no matter who is in the room.

Let's start with the normal suggested practice of safety from management. This is an anti-pattern. If your teams feel that they can't be open and honest then there's something seriously wrong and that needs to be worked on. Transparency and honesty are hallmarks of agile. Your agile coach, ScrumMaster or agile manager should protect the team from outside interference. If teams don't feel that they are protected from repercussions they won't be open and honest.

My previous company had two important values; say the hard things and hear the hard things. This went a long way to helping build a culture where honesty was tantamount. Did it happen all the time? No, but changing culture can take time.

It's all comes down to personal safety. That doesn't mean being closed off and hiding your feelings.  Quite the opposite, you should feel safe to share without repercussions. This can be especially important for team members who find it hard to discuss what's on their mind. This can be caused by a number of things. Confidence/self-doubt, fear of conflict, bad experiences, having one or more dominant people on the team amongst other things.

Setting up a place where being open and honest is required, helps create a safe environment for all team members to open up. It's not quite that easy though. You *need* have a dedicated facilitator who is neutral and impartial. The facilitator is there to make sure everyone's voice is heard and to navigate conflict. This helps build up confidence so that team members can share freely in the retrospective, eventually going as far as sharing issues at any time which is the ultimate goal.

Sharing issues never go away. Team members can revert to not sharing if the team goes back into a storming mode. That said, my own experience is that if you've done your job right, they still feel that the retrospective is a safe place. This is why it's so important to continue it as a practice even if teams feel they no longer need it.

Scrumbut isn't always a bad thing

There have been discussions for many years about the need to always do Scrum by the book. I think this statement might be true for some teams, but not all. I'm not talking about having a half-arsed Scrum adoption, but allowing your teams to evolve beyond it when they are ready. The last four words of that last sentence are critical. There's a dichotomy within the framework, we are expected to inspect and adapt, but not in ways that adapt set parts of the framework. 

The mantra of, do it by the book, seems to have grown out of problems with teams that only adopt parts of the framework and then wonder why it's not working. Hence the name scrumbut, we do Scrum but.... Agile and/or Scrum are often the obvious scapegoats rather than looking into internal problems.

For your initial scrum adoption I do recommend that you do everything by the book. Also hire some seasoned ScrumMasters to help you out. Though Scrum is a simple framework, sending someone on a 3 day course and expecting them to be an expert is naive at best. Another option is to hire an agile coach to work with your newly minted ScrumMasters. I can't stress this more. Don't go it alone. If you're serious about agile, then take it seriously and hire the right people to teach others. 

Anyway getting back to the point of the post. I'm a great believer in the martial art concept of Shu, Ha, Ri (which I was introduced to by Lyssa Adkins in her Coaching Agile Teams book).

Shu - learn the rule. 

Ha - break the rule. 

Ri - be the rule.

Teams start in Shu, i.e. do Scrum by rote. This is essential so that teams build up the discipline needed for a successful adoption. It doesn't mean that you can't ask questions as to why something is done a specific way. In fact that is encouraged, but you aren't ready to adapt away from the constraints of Scrum. This is where a seasoned ScrumMaster or coach is essential. They'll be able to give knowledgeable answers to any questions that arise and know when a team is ready to move to the next state. Ha.

Note: teams might be at different levels for different practices. 

When teams have achieved Ha, the ScrumMaster will start letting them break existing rules. This will allow the team to learn, but without the discipline that has been built up they won't have a frame of reference. 

Lots of teams want to skip directly to Ha or Ri stages without going through Shu.

Finally as the team learns through breaking the rules they'll achieve Ri. This is the state of high performance. Teams will be able to inspect and adapt how ever they want. At this stage, they may have evolved their Scrum practices in a way that would be considered Scrumbut, but they now have the experience to understand why they've done it. 

Finally, I believe there's a conflict of interest here with certifying organizations. If teams keep on changing their process, they may no longer fit the model of strict Scrum and have no need for certifications. 

Remember that Scrum is a starting place on your agile journey, not the final destination and not the only way to get there. 

Are you doing Scrum by the book, in ways that would be considered Scrumbut? Do you think Scrum by the book should be the only way to do it?

Breaking flow at the end of the work day

It's getting towards the end of the work day, you're cranking, feeling great and everything is just clicking into place. You notice the clock in the bottom corner of your screen and realise that you could maintain this state for a few more hours, but that will get you home late. You don't want to stop but you know you have to go. What do you do?

This is a situation that I find myself in a few times a week. My family commitments mean that I really need to leave on time unless there's a work related emergency. The problem is that I don't always want to leave. This isn't because I don't want to go home, but because I'm in a state of flow and find it hard to switch off. I tend to end up working until the last second and then running for my train. On the first half of the journey home I'm mentally coding and getting stressed out because I can't actually code. This stress is caused in part by not having a transition period between activities.

Transition periods are quiet times between activities which help you go from one activity to the next without added stress. These transitions are often combined with a ritual.

For example, when I get into work the first thing I do is get a coffee and read a few blog posts for about 10 minutes. If this transition ritual is interrupted my stress immediately goes through the roof.

I do have a transition ritual for the end of the day, but when I'm in a state of flow I don't do it. Yes I could force myself to wind down but this also creates stress.

I feel like I'm between a rock and a hard place, so I'm wondering how others deal with this situation. How do you break flow without causing too much stress?

Getting an agile software development job

I recently received an email from someone asking my advice about getting a job at an agile software company. This is a common question so I thought I'd write a post about it.

In my experience finding agile work isn't that different than finding any other software development job, but your success will be on how much preparation you have done beforehand.

So why would you want a job in an agile software company?

The answer to this is a post in itself, but some of the major points are:

Self organizing teams rather than micro management - teams are given a vision, direction and goals, but how they work together is up to them within those boundaries and that of the agile framework they are using.
Sustainable pace - rather than having times when you are pushed to the limit and times where you're twiddling your thumbs, agile companies promote working at a pace that isn't too fast or two slow and at an even rate.

Rapid feedback cycles - teams work in short iterations/sprints where they'll produce working, valuable functionality. These are 1 - 4 weeks in length (2 weeks is the most common). During this cycle continuous feedback to the customer or customer proxy is recommended. The team also gets together once a day to talk about what they achieved the previous day and plan what they are going to do that say. At the end of the iteration the work done is potentially shipable/releasable.

Continuous improvement - teams are encouraged to always find ways to improve themselves. This is usually through using retrospective techniques at the end of a sprint/iteration.

Trust - self organization is one part of this, but also allowing the team to set working hours and when they come in and leave. Teams are asked to do a certain number of hours during the week, but it's up to them to set those hours. After all, we are adults.

The use of techniques such as TDD, BDD and Continuous Integration.

Be prepared to answer this question.

Preparing yourself

Before getting your CV/resume out there, there are a number of steps I'd recommend.

1) If your new to agile, read the Agile Manifesto, understanding the valued and principals is essential. A good place to start understanding it is here:

http://agileinaflash.blogspot.com/2009/08/12-principles-for-agile-software.html?m=1

Also research the different favours (XP, Scrum, Kanban, etc.) and research the techniques and technologies used by agile teams. Some essential ones are test driven design, behaviour driven design, continuous integration and pair programming. Not only research but try out some of these on your own.
If you're experienced with agile, I'd still recommend continually researching new techniques and practices.

2) Get involved with a local agile group. This will allow you to build relationships with other agilists, but also listen to what they say about their own companies. Some of these companies maybe worth direct applying to when you're ready. You may also hear about open positions from other members, but not treat this group as your own personal recruiting circle. Without building a relationship first, you'll just alienate people by continuing to ask.

3) Improve your internet presence. Companies who are passionate about agile look for people who are equally passionate about it and software development. I'd recommend starting a blog. If your new to agile it doesn't matter, just blog about your experiences with it so far and blog your own experiments with techniques like TDD. It doesn't have to be all about agile, so write some posts on your core strengths too.
Blogging is only one way to improve your internet presence, engaging with other agilists on social networking sites is another. Join Twitter, Google+, Facebook, LinkedIn and start talking with others.
Here are some people you may want to follow:

https://plus.google.com/105719943141175185993/posts/baoEVdf4Jpz
https://twitter.com/#!/JOSullivan/recommended-agilists

After you've prepared yourself. Now it's time to:

Find a position to apply to

Hopefully by now you've started to build your network. Your network is the best place to start looking for an appropriate job. Not only will you get some inside knowledge about the companies you're applying to, but usually if someone has put your CV/resume forward you'll get an interview. This is because people generally won't put people forward unless they think they will do well.

The downside of working your network is that positions aren't always open. With that in mind, your next option is to find a good recruiter.

For my last two positions I used recruiters and found good agile companies to work for. One thing to do is make sure the recruiter knows that you're looking to work in an agile environment. This will dictate the companies you you'll be put forward for. If a company passes you over for an interview, ask the recruiter why. This is valuable information so learn from it. You may need to change something about how you apply.

Finally if a company likes your CV/resume they'll bring you in for an:

Interview

There are a good number of companies that pay lip service to being an agile, but there are also a good number that are passionate about it and they look for people who also have that passion.

The interview is as much about you interviewing them as it is about them interviewing you. Use this time to try and understand how they practice agile and their understanding of it. I'm going to assume that you've been for a technical interview so I won't go into this in depth, but some questions you may want to ask are:


Can you describe your agile process?


How do you deal with technical debt?

What are your company values?

What suggestions would you make for people looking for an agile software development job?

Should a Product Owner attend a retrospective?

At my new company the common practice is to invite the Product Owner and any interested stakeholders to the end of sprint retrospective. When I first heard this it surprised me as I've always believed that the retrospective should only be comprised of members of the development team. The reason for that being that the team may not be comfortable discussing some things with those outside of the team. It's essentially a safe place to discuss issues. As a ScrumMaster, the only times I've allowed managers, product owners etc in is if they are also members of the dev team. That said if a team is truly happy with others being there and vote to include them, who am I to say no.

When I brought this up with my manager, his counter point was about transparency. If the team feels that they need a safe space then there's something wrong.

I can definitely appreciate that as I always try to surface conflict and promote open discussion within the dev team. I'm also a great believer that transparency is crucial. Talking about issues behind the PO's back goes against what I'm trying to do with the team. That said having the PO at the retrospective can drive conversation underground when there is conflict.

What are your thoughts on the subject? Do you include people from outside the team in your retrospectives? What about transparency?

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+