Increase Employee Engagement with the 3 C’s of Internal Communication

This post originally appeared on the Stiltsoft blog in April 2016 as a guest post by Nicholas.

Effective communication is vital to keep employees engaged and motivated. Research shows there is an “explicit positive relationship between communication satisfaction and employees’ organizational commitment”.

Authentic, frequent and collaborative conversations with employees leads to increased trust, decreased turnover and improved productivity. In this post we’ll explore how candor, cadence and collaboration can drive increased employee engagement and improve organisational performance. These are the ‘three Cs’ of effective internal communication.

Candor

Through internal communications, the management team is able to share company news and operational details with employees. Including facts and figures that may not be suitable for the general public can enhance employees’ understanding of the business and market, helping them make better decisions.

Further, communicating candidly can create trust and empathy throughout an organisation. For example, a leader could share their own shortcomings and how they are working to address them. This encourages others to reflect on their performance and pursue their own areas of improvement. When a leader demonstrates transparency, it shows the rest of the team that honesty really is the best policy.

Cadence

Let employees know that you highly value internal communication by sending company updates regularly. Maintaining a regular frequency lets employees know when to expect your updates. Every two weeks works well and provides a leader with ample opportunities throughout the year to share news with employees.

Keep company updates interesting by asking different members and teams of the organisation to provide news on their projects. By retelling the stories of others, you can keep employees engaged with different areas of the business.

Collaboration

The bigger the organisation, the more difficult it is to give employees a sense of ownership in daytoday business operations. By bringing intracompany conversations online, all members of the company can read up on important news and participate in conversations.

You can encourage these important online conversations by asking leaders to blog on Confluence. When a blog is published on Confluence, employees can log in and leave comments on the blog post. Comments and @mentions allow employees to reference colleagues and discuss a particular aspect of the blog’s content. The Confluence notification emails include a Like button, allowing employees to provide immediate feedback.

Finally, Confluence enables leaders to easily and quickly tell compelling stories, using rich content such as images, tables and charts.

Better Blogs for Confluence

With Better Blogs for Confluence it is easy to implement the Three 3C’s of internal communication.

Better Blogs

Better Blogs is a Confluence add-on that enables a Space Administrator to subscribe an entire group of people to email notifications of new blog posts in a space. For internal communication I recommend setting up a Confluence space called ‘Announcements’ and subscribing the ‘employee’ LDAP group to email notifications of new blog posts in the space using Better Blogs.

With the ‘three Cs’ of effective internal communication you can increase trust, decrease turnover and improve employee engagement.

Ready to improve the engagement of your employees? Install Better Blogs for Confluence today.

Building an Ideal Agile Team Workspace

Trendy technology companies love the open plan office. From Atlassian to FacebookTwitter to Zynga, they’ve all recently built beautiful open plan offices. More traditional tech companies such as LinkedIn and eBay favour the clustered cubicle approach. One trendy tech company that stands out amongst the open plan and cubicle loving crowd is Campaign Monitor, check out their office:

While the open plan office is lovely to look at I fear that it may be a recipe for disaster when it comes to collaboration amongst software development teams. And I believe teams working in amongst cubicles face a similar problem.

For instance, have you ever seen a team look for or book a room when an ad hoc conversation would suffice? Ever seen an individual wearing headphones to drown out the background noise and allow them to focus? Yep, me too. This is common in an open plan office and unfortunately this behaviour stifles the collaboration that a team requires to attain optimum performance.

The most effective team I had the pleasure of working with was isolated in their own room, free to chat as a team, hop up and use the whiteboard, play music in the afternoon, and generally bond as a team. They could do all this without disturbing any other team. Thinking back to that team and their environment, and looking at some of the problems I’ve experienced recently with open plan offices, I decided it was time to explore the ideal agile team workspace.

 

First, let’s step back. To have an ideal agile team workspace you need to have an ideal agile team. That means a cross-functional team of no more than ten people – you know the adage ‘seven plus or minus two’. While I’ve seen larger teams work together effectively I don’t believe the collaboration and camaraderie exists at that size.

Second, budget shouldn’t constrain this approach. While every company will have a different budget for the office fit-out I believe the basics can be in place for little more than an open plan office – and don’t forget, the benefits of having high performing teams will well and truly outweigh the cost of an office fit-out over the long run.

Let’s take a look at what we need to get right to provide a foundation for building high performance teams.

Ideal Agile Team Workspace

Room
Clearly we want some space. We don’t need people sitting on top of one another unless they are pairing. This space allows team members to quickly swivel their chairs into the centre of the room to have a conversation or ask a quick question – Has anyone seen this bug before? Product Owner, what did you expect to happen in this situation?

Standing desks allow people to stretch their legs and continue to work. I often see people spend an hour or two at a standing desk before returning to their seat.

At one end we’ve got a conference table and a whiteboard. Whether you’re working through something with another team member or having a chat with the customer via the phone this is a great place collaborate. There is also a chair to recline in if someone is working on a laptop and a mini fridge as well. Which, let’s be honest, is a bit of an extravagance, although one can always dream.

In the corner north of the whiteboard there is the wallboard – think JIRA issues, Bamboo build metrics, open Stash pull requests, product analytics, etc.

Finally, there are a few plants dotted around the room to keep the place feeling alive and fresh.

Lighting
Occasionally a contentious issue, hopefully not too bad. My personal preference is for lots of light, which means you need monitors that are anti-glare. I’ve often found that designers prefer a darker space and if you encounter similar try to accommodate them by placing them further from the windows.

Remote Team Members
Let’s face it, this happens. Whether you’ve got a product owner on-site with a customer for a week or an engineer working from home for the day you still want to be able to include them in team activities like the daily standup. Make it easy by having a decent desk phone and perhaps consider a remote video feed on the monitor for those activities.

Pros and Cons
I believe a room such as that above will solve those two key problems which are a barrier to high performance teams, namely the individuals putting on headphones to drown out the background noise and the inability to have a quick ad hoc conversation.

I asked Dave Elkan, an exemplary engineer from Atlassian, to play devils advocate on the proposal above and he raised the following questions:

  • Could a company attain similar results without a complete remodel of the office?
  • How do you scale the teams?
  • What impact will this have on cross team collaboration and communication?
  • What open spaces will you have for people to interact?

Unfortunately I am not sure of the answers to these great questions, although I’d love to give the workspace a shot and see how it fares!

What would your ideal agile team workspace look like? Draw it and Tweet or email me. I’ll include a selection of your ideal agile team workspaces in a follow up post.

Inspiration

Thanks to the articles below for helping me obtain a better understanding of what has been tried previously.

A Daily Scrum can be Strategic!

I’ve spent a good portion of the past 11 years as a product coach, working to introduce scalable agile techniques to hundreds of product engineering teams.  My work has brought me around the globe in pursuit of helping enterprise teams accelerate product development, doing so in a manor which helps increase individual performance and promote healthy interactions.

In my travels, I’ve met some amazingly talented and creative product teams, and as you might imagine, my sessions with these bright contributors are often filled with insightful interactions and meaningful exchanges.  More often than not, I feel as though I’ve left with more gained than I’ve imparted.  There could be no better reward for a coach and just recently, I had one of those sessions.  However, this was not the typical session.  There was no classroom, the instructors were not product people; and this time, I was the student.

Etched at the top of my notepad that day was:  “Daily Scrum can be Strategic!“.  I’ve been practicing Agile since the signing of the Manifesto, so one would think that by now I would have already learned the values of a Scrum!  Believe me, I was just as surprised.  Equally surprising if not shocking was the fact that I learned it not from an engineer, not from a product owner, or even someone in the product world at all.  I learned an very valuable lesson on Scrum from an athlete.

Sitting in an airport lounge having been delayed for several hours, I struck up a conversation with two gents who were scheduled to depart on the same flight.  Both traveling towards the States and both interested in why I was connecting my Mac to a banana and orange.  Having explained Makey Makey as if I were talking to two electrical engineers, they stopped me and said “… we have no idea what you are talking about, but controlling donkey kong with fruit is awesome!“.  I quickly turned the conversation back over to them.  I asked them where home was and whether or not travel was for business or pleasure.  They both said that they were more into sports than computers (I had my suspicions).  I asked them what sport and one of them quickly replied rugby.  As it turns out, both were on the USA Rugby Team, traveling back from the Sevens tournament.

The Outrigger on the Lagoon – Fiji So Close in the Coral Coast Sevens!

Half jokingly, I then said: you know, we have something in common.  “… You play rugby?” one of them inquired?”.  Hah.  No, I replied.  I told them that although I don’t play the sport, I have studied rugby as one part of the game often makes it’s way into my work as a product coach. I then went on to describe Agile Scrum and the typical activities that occur within a daily Scrum.  One of them piped up and said, “..but it seems you have part of it wrong!“.  Oh?  Thinking to myself, how could I have it wrong?  I then asked:  Which part?

They both went back and forth for a few moments describing what takes place within a Rugby Scrum and in essence what they described was the fact that not all of the moving parts and team interactions within a Scrum are meant to be tactical in nature.  What they described was that the actions and techniques, which formed the basis of a play were more strategic than tactical in nature – in fact far more strategic than they appear in real-time on the field.  Both emphasized that the goal wasn’t just about moving the ball forward.  It wasn’t always about “this play“, or “this portion of the field“, or “what the current scoreboard reflected“.  Sometimes the situation called for more strategic thinking.  The kind of big picture thinking that wins games and not just plays or position.

WOW!  I was speechless.  For two guys who struggled to understand microcontrollers and simple circuitry, they certainly had a way of connecting the dots with Agile!  For years I’ve struggled with how to keep teams thinking big picture, while driving ceremonies centered around small parts of a larger whole.  Is it possible that through airport conversation, I inadvertently found a solution?  While boarding the plane, I couldn’t help but smile.  Who better to teach me the true value of a Scrum than members a Rugby team!

Do you struggle with keeping your team focussed the big picture, while working continuously in “the now”?  If so, have you changed or altered your ceremonies in a manor which stimulates strategic thinking?  One idea that Nick and I have been discussing, is to possibly add a fourth question to your daily Scrum.  So in addition to the typical three, how about adding #4 to the list:

  1. What did you do yesterday?
  2. What will you do today?
  3. Are there any impediments in your way?
  4. What strategic things are you thinking about / working on?

Courage! Close off old and stale backlog items.

The following question is one that comes up every few months. A product owner is overwhelmed by all the items in their backlog, and quite often the backlog is growing faster than the team can work through it. Every time a product owner wants to visit the backlog it is a mess, which causes waste.

We have a giant backlog of 400+ tickets. We’ve been cleaning it up, but some tickets are great ideas that we just can’t get to in the foreseeable future. We’d like to resolve these tickets so we can more effectively prioritise our backlog, but our users get upset when we Won’t Fix things.

How do you suggest we handle this? Is there an appropriate status for this? Must we wade through hundreds of backlog tickets and risk losing good work for fear of upsetting people by closing? Must we use lame labels? 🙂

Being good lean practitioners we want to minimise that waste. And we also want to focus on the highest value and impact items we can deliver to our customers.

As this product owner uses JIRA I suggested that he search for old, untouched issues via the Issue Navigator. I generally recommend that all issues untouched in over six months are triaged and the ones that aren’t going to be addressed soon are resolved as Won’t Fix.

If a customer does return to an issue then we want to make sure they know they can reopen it for the team to explore again so it is always nice to add a comment to the effect of:

“Thanks for your suggestion, while this may be a fantastic idea we don’t envisage addressing this in the foreseeable future. As such I am closing this issue as Won’t Fix to focus the product backlog on the highest value work. If you believe this is really important and we should be looking at it sooner please reopen this issue and I’ll be notified.”

Give it a try and see how much you can clean up your backlog. Minimise the noise, minimise the waste, focus on the high value work.

Roles and Responsibility, Essential to a High Performing Agile Team

There are three key roles for every Agile team: Product Owner, ScrumMaster and the Team. And, of course, we also have the stakeholders – our customers, managers, board of directors, etc. We’ll take a look at these roles and their various responsibilities and then we will explore how these people gel to form a high performing agile team.

Product Owner

The Product Owner is the proxy for the customer. They are available to the team during the course of their working day to answer any questions about the customer – for instance, the team may want clarification around the problem the customer is trying to solve, or their motivation, or when and where they experience said problem. The Product Owner is a necessary role in every agile team as it ensures that the Team has a subject matter expert on hand and can get their questions answered promptly to avoid being blocked.

Ideally the team would be co-located with the customer and could ask them questions directly. Often this is not the case, which is unfortunate. However, even when the Team is co-located with the customer the role of Product Owner is still necessary.

The key responsibility of the Product Owner is to paint a vision for the product and order the product backlog. They take all of the input from the customer and work with the customer to identify the highest value problems they have – ordering the backlog from highest value to the customer to lowest. Clearly we want to focus our effort on delivering the most value to the customer as soon as possible.

ScrumMaster

The ScrumMaster is another essential role for a high performing agile team. The ScrumMaster has a number of responsibilities and they have a place in both Scrum and Kanban teams – the term KanbanMaster is not in common parlance, although the responsibilities are the same.

ScrumMasters are often considered servant leaders1 as they put the priorities of the Team before their own. They help the Team overcome blocked work, defend the team from scope change, maintain the reports to measure Team progress and facilitate the agile ceremonies such as planning sessions, daily standups, demo’s and retrospectives.

A ScrumMaster may, for instance, help a team write out their Definition of Done and Working Agreement, and help the team stay accountable to themselves for these definitions which they own. Discipline is key to a high performing agile team, to any high performing team, and so the role of the ScrumMaster requires great discipline too.

Team

The Team themselves have responsibilities as well. Ultimately everyone in the Team, including the Product Owner and ScrumMaster, are responsible for the deliverable – if the quality is not up to scratch the team has no one to blame but themselves.

An agile Team works as a cohesive unit – not a loose grouping of individuals. It is important that the team strives to become cross-functional, if they are not already. Being cross-functional helps the Team avoid being blocked and assists with the flow of work ensuring they deliver value to the customer consistently and frequently, enabling a positive feedback loop.

The Team estimates work on the backlog2 to give them confidence that they can meet the sprint commitments (Scrum) or to allow them to measure cycle time with greater accuracy (Kanban). This drives predictability for the Team, and may give the Product Owner the confidence to provide delivery estimates to the customer.

Delivery is another key point, if the Team commits to deliver then they must do so. To do anything else could harm the trust of the customer. Clearly there are unforeseen circumstances that arise and impact this from time to time – these should be the exception and should be explored in a retrospective. When the team commits they also commit to stick to the Definition of Done and Working Agreement that they own.

Chickens and Pigs

Above we’ve looked at the ‘Pigs’. There are also the stakeholders, the ‘Chickens’. The Chickens have responsibilities too. But first, why do they get these terms? Think of bacon and eggs for breakfast (yum!), the chicken is involved by providing eggs while the pig is committed by providing bacon3.

So, what are the stakeholders responsible for? Customers in particular are asked to explain their problems, not merely the first layer but the root cause of their problem. The team will help the customer identify this root cause and work to address it. The customer is also responsible for providing input to the Product Owner around priorities.

Finally, stakeholders should not disturb the Team directly with new work requests, instead they should speak with the Product Owner to get these requests entered in to the backlog.

High Performance

When these roles and responsibilities are clearly defined by the Team people will not abdicate their responsibilities, will work together better, and will hold one another accountable for delivering. The underlying ethos of Agile is to be constantly looking for opportunities to improve, and this is no different. If you find that one person is better suited to being the Product Owner – perhaps they have built a good working relationship with the customer – then feel free to try switching roles.

Clearly defined roles and responsibilities give the team structure to perform at their capacity, minimise disruption, and focus on getting work done.

Now, what’s stopping you from being a high performing team? Follow @VelocityCounts to be notified of future blogs.

Enjoy this essay? React on Twitter:

  1. Is Your Scrum Master a Servant Leader? []
  2. Why do high performing Scrum teams use story point estimation? []
  3. Wikipedia: The Chicken and The Pig []

Eliminate Free Radicals – A Path to Scaling Agile in the Enterprise

You might remember from chemistry class that a molecule can exist without a paired electron, making them highly reactive. Molecules fitting this description are considered “Free Radicals“. What your professor may not have told you (mine certainly hadn’t) is that Free Radicals (or Radicals as I like to refer to them as) also exist in human form and unlike their scientific brethren, they often appear in clusters, especially within large organizations. While they may play an important role to science, I’ve always placed the human version at the top of my list of reasons preventing Agile from scaling within large enterprise.

Characteristics of a Free Radical

I have some great news for you. Free Radicals are extremely easy to recognize within your organization. Here’s a list of characteristics and mannerisms to watch for:

  • Every task they represent to the organization is urgent and a top priority
  • They do not use a consistent medium to communicate information
  • It’s not easy to recognize any direct contributions they make to the organization
  • They don’t want to take time to learn about the methodology you work within (e.g. Agile)
  • They submit requests just short of the due date
  • They echo communication across many channels (e.g., email, IM, phone, etc)
  • They are quick to offer compliments privately, but never in public forums
  • They are indecisive
  • They are often the center of conversations with conflict
  • They wander the hallways with lemon water in hand (a tangental observation)

Free Radicals can Squelch Agile Adoption

When I speak or meet with Agile coaches or any executive looking to adopt or grow their Agile deployment, I begin with a cautionary statement about Radicals. Their meer presence, no matter the number, can quickly squelch Agile adoption. Therefore, you must develop a plan to insulate yourselves (see below). By exerting their own chaotic manor of work, Radicals squelch Agile adoption by:

  • With Scrum teams – Insisting that changes be admitted to active Sprints (e.g., backlog promotion / scope change mid-Sprint)
  • With Kanban teams – Insisting that their items be expedited and change SLA course
  • Not accepting deliveries against their agreed upon definition of done
  • Frequently interrupting team members
  • Forcing exemptions to be from an accepted list
  • Contributing to the delay of requirements definition
  • Refusing to obtain status updates from systems or boards, preferring them from people
  • Breaking cadence (our internal rhythm)
  • Contributing to friction and causing frustration

Insulate and Scale

Ahh, recognize them now – don’t you. Worse, you realize that Radicals are all around you, possibly looking over your shoulder right now? Relax, they don’t like to read from a far, especially articles with the word “Agile” anywhere in the title. There are three simple ways to insulate your teams and reach scale – and even better, a simpler way to remember them. You WOW them. Walls, Obstacles and Warfare. I developed this strategy years ago and it’s something that I’ve continued to practice and introduce to hundreds of Scrum teams operating within enterprise-size organizations.

Walls

I’m not talking about the physical here. Unfortunately building codes and the such require that you have adequate doors and means of egress. Admittedly a slower life form, Radicals have evolved to a point where they have opposable thumbs and can navigate simple obstacles quite readily. As an Agile organization, everyone on your team needs to be comfortable saying no to requests which challenge the methodology in which you work or jeopardize the working agreements you have in place with other departments / divisions. For humans, it’s often hard to say no and Radicals can make this harder and outright uncomfortable at times. You need to have a common redirection in place, one that everyone on your team understands and feels comfortable using. The key is that everyone must respond in the same manor and provide a near-identical response. It won’t work unless this is the case. An example of this redirection might be: “Sorry, we are in feature freeze right now, so I can’t make additional changes without jeopardizing the project schedule. You need to talk to <INSERT The Big Boss HERE> if you want that change made”. Radicals will hear this and then check with the next team member, and the next, and the next… and so on. They are looking for a weak link in the chain. If they receive the same response, take my word for it, they will go away.

Obstacles

I’ll be the first to admit, Radicals from time to time will have a valid reason for causing an interruption or asking for an exception, etc. When this occurs, we still need to steer them towards a less-chaotic manor of introducing the new work stream. In other words, let’s not just stop what we or everyone is doing just because they are in possession of a valid item of work. As an Agile organization, we need to have a well described process of how we accept work, what details are required before we will evaluate, how long it will take us to respond, how we will respond, etc. Effectively we are sharing the teams working agreement with other parts of the organization. The process of handling exceptions needs to be clear and available to all, so making it part of the working agreement makes sense. The working agreement is a living document that your team visits as part of your retrospectives to see if there are opportunities to modify and strengthen the contents. An example of an obstacle might be the fact that your team will not accept any User Interface (UI) items without prior receipt of PO sign-off against User Experience (UX).

Warfare

Let me guess, you skipped ahead to this section didn’t you? If you did, it’s alright, but please go back and read Walls and Obstacles first. Ok, welcome back! The first two-thirds of this strategy are highly effective techniques at protecting your Agile deployment and teams from Radicals, they should be employed first and then we move to the last stage of our strategy. It’s time to rid your organization of Radicals. Trust me, it can be done. Here are some simple and proven methods to handle the job:

  • Every month, make it a goal to take a Radical to lunch. At lunch: (a) explain Agile and how your teams have adopted from 10k feet and (b) let them know in no uncertain terms, that the better they follow the process, the more work will get done for them (e.g., bribe them).
  • When a Radical follows the process correctly (listens to Walls, navigates Obstacles), go out of your way to recognize their act and do it in a public forum. Reward positive behavior and discourage Radical behavior. (Yes, the same applies to puppies).
  • Publish a list of work items completed, grouped by Radical in descending order. Display this list in a public location (e.g., Wallboard). Peer pressure will help foster non-Radical behavior.
  • If Scrum, then invite them to join a sprint review / demo, give them a front row seat to view potentially shippable product first.
  • If Kanban, them join your team when reviewing team activity. Demonstrate how the team pulls items through stages of completeness.
  • Offer to help a Radical organize and map their teams chaos into an Agile framework. Maybe show them Scrum or Kanban applied to their world. I’ve converted dozens of Radicals using this simple technique.

In other words, the best way to rid your organization of Radicals is to help them grow their knowledge of the way your teams have elected to work. By doing so, you are helping to retrain them and making their job and others more enjoyable in the process.

Does your organization suffer from Free Radicals?  If so, how are you handling them? We’d like to know, share your perspective in the comments below. Want to learn more about high performing teams? Follow @VelocityCounts for the latest blogs and podcasts.