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.


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.


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.


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.

Understand What Your Customers Want with Agile User Story Maps

Quick post to point out two other blogs I recommend you read.

User story mapping is an essential practice for every agile team. Have a read of Understand What Your Customers Want with Agile User Story Maps to get some background and then follow up with Anatomy of an Agile User Story Map for the details.

Minimise Context Switching

Often if a team picks up too much work it is because they don’t fully understand, or can’t see, the cost associated with their action. Fortunately there is an exercise you can run with a team in 10 minutes to help them see first hand the cost of context switching.

3’s & 5’s

3’s and 5’s is really simple to run. We’re going to ask the team to ‘deliver’ their multiplication tables for 3x to 60 and 5x to 80. They will go through each team member to reach that goal (value delivered).

First, ask the whole team to stand up (or run the exercise immediately after the daily standup – easy!). Explain that they are being asked to deliver 3x table to 60 and 5x table to 80, and to do so by saying the numbers out loud. The first run through they will do 3x, followed by 5x. You’ll time it.

Once they’ve done that give them another chance to improve their time for the 3x followed by 5x. Then we introduce context switching.

On the third run tell them you’ll yell out “Five” and “Three” and they need to switch the number set, while keeping their place in the other number set. Here is a short demo to show you what I mean:


So the team now knows the cost of context switching for a simple task like delivering 3x and 5x multiplication tables. Imagine the impact when you have context switching for a hard task like writing a distributed system. Phew!

Ultimately you should expect to see the team take on less work, lowering their work in progress and cycle time. You’ll deliver more value to customers as a result, and you’ll force prioritisation discussions and decisions.

Give it a try with your team and let us know how it goes.

Serious Games to Teach Agility

There are a few games and exercises that you can use to help teams understand the why and the mechanics of being agile. Take a look at:

  • Rival Effort – a three-to-five person game that explores process optimization and efficiency strategies, asking players to allocate their effort between projects. Through the game participants become managers in a company competing to make as much revenue as possible, and thus winning a promotion. After playing the game, an open discussion and debrief with all of the players ensure a solid understanding of the key principals and learning of the game.
  • getKanban – the quickest, most effective way to teach the principles and mechanics of Kanban. Ideally played with multiple teams of 5-6 people to keep it moving along and make it competitive.
  • 8 Great Short Games for Groups – a compendium of games for teams to play.
  • Scrum Lego City – simulate every aspect of the Scrum process in a fun way.
  • Penny Queuing Exercise – understand the efficiency that can come from moving away from a waterfall or large batch process. The exercise can be done with 20 pennies, 5 people and a clock with a second hand.

Have you got a favourite game that you play with teams to help them understand agile and lean practices and principles? Reach out on Twitter @VelocityCounts and let us know.

Measuring Engineering Performance

Just got a great query from an Engineering Director. Love it.

I’d love to pick your brain about engineering team performance measurement. How do you do it? Do you have any experience with what works/what doesn’t work?

I’ve got lots of thoughts on measuring the performance of engineering teams. No doubt you do too, so please Tweet @VelocityCounts and share your perspective. Okay, onwards…

Long story short: if you measure it, and the team is aware you are measuring it, they will game it. So, if the team is going to game the number (as you are measuring it) then you’ll want to make sure it is a metric that, when gamed, leads to the behaviour you want to see. For instance:

  1. Estimates: some teams may think it is about getting more story points completed in a sprint, so they inflate their estimates over time to make that metric look better. Measuring story points leads to poor behaviour as teams inflate estimates at the expense of consistency and predictability. Estimates are for the team. Consistency from sprint to sprint is the key. And you can not compare output between teams due to a different baseline for the estimates.
  2. Code Reviews: a great way to lower the cost is to catch bugs before they hit production, right? Code reviews are one way to do that. Some teams like to measure the time spent awaiting code review, not a bad idea. Just avoid measuring the time spent in code review as teams will optimise for lower time, which may mean lower the quality code reviews and lead to the team missing things.
  3. Incidents: one thing that incidents measures is the direct impact on our customers (outcomes). I see no downside to measuring incidents and I see a positive impact when people try to game this – less incidents, makes the team look better, better for the customer. Also, you may like to ask yourself: can you leverage this alongside code reviews to see who are the people that give ShipIts to deploys that lead to incidents.

At present I’m really interested in measuring outcomes for customers and maximising for that, rather than engineering team performance specifically. For instance, a small change does not mean much output in terms of code, story points, etc, although it may have a massive outcome in terms of customer experience, conversion, etc.

That make sense? What metrics are you thinking of measuring? Let me know @VelocityCounts.

Scale Engineering Effectively with Cross-Functional Teams

As companies grow they place ever greater demands on their IT (and/or Engineering) organisations. There are constant requests for assistance, be they from the CMO who is looking to get a better understanding of customers to the customer support team looking to keep costs stable while expanding to 24×7 support. If you’re a VP or Director of Engineering at one of these growing companies this post is for you.

So, how do we approach this problem? What is the best way to grow and scale? To address those questions and more, we need to first determine how to structure our teams. Let’s explore that now.

An IT organisation can adopt one of two approaches when it wants to grow: the functional or the cross-functional team structure. One approach will lead the IT organisation down a path that will enable them to:

  • effectively scale as the company grows,
  • minimise bottlenecks and inefficient exchanges,
  • consistently deliver high quality product to their customers, and
  • maintain a happy and productive workforce

Unfortunately, the other approach will not achieve these goals. Instead you’ll be faced with an IT organisation unable to give an indication of what they will deliver, or when it will be delivered. Your teams will be constantly churning, wasting time and resources. And, they certainly won’t be delivering their best work.

To ensure you’re headed down the right path we’ll explore both approaches and explain why having cross-functional teams is the right approach.

Functional Teams

This is, unfortunately, still a common scenario. Using this approach, the IT organisation builds teams around a particular skillset, be that design, engineering, operations, quality, databases, etc.

Functional Engineering Teams

This is the path most commonly taken as it allows a VP of Engineering or a CIO to find a Director of Design and allow them to build their team. Then that same VP / CIO will find a Director of QA and have them build their team. And so on. Although logical and easier to implement, this approach has many unfortunate downstream consequences.

Fairly soon you’ll find fiefdoms within the IT organisation. Each Director will be building out their team in the way they know best, often in direct opposition to the approach that will enable the whole company to be most successful.

The functional approach leads to barriers being built between groups, often through the use of requirements documents and/or contracts. No doubt you’ll also find significant bottlenecks emerge between groups and people start talking about their people like they are talking about cattle – not fun.

Getting functional teams to operate harmoniously and collectively, while focusing on delivering solutions to meet customer demands is difficult and not at all optimal.

Imagine the value we could unlock with a better approach!

Cross-Functional Teams

In the world of cross-functional teams you may well still have a Director of Design, a Director of QA, and so on. However, the difference is that teams are structured across functional boundaries.

Cross-Functional Engineering Teams

Using this structure, we build a backlog of projects and any team within the IT organisation should be capable of delivering on a given project. Different teams may have a different scope – for instance, imagine a cross-functional hardware team that comprises firmware, capacity planning and hardware engineering people, or a cross-functional web application team that comprises front-end HTML/CSS/JS people and backend Scala people.

In this scenario there is no need for a clear contract between Operations and Engineering as we’ve got a number of teams that can approach any given project, and each of those teams have all the people they need to deliver that project. Furthermore, having stable cross-functional teams allows us to cross-train the team members – thereby making more resilient and higher throughput teams (although that is for another post).

With cross-functional teams we proactively build teams full of people that have a diverse set of skills, and in doing so we alleviate the distrust and blame that can fester within a functional organisation.

On top of that we have eliminated the greatest form of waste in the IT organisation – the bottleneck (see Mitigating Bottlenecks below).

For best results you will want all the people within a cross-functional team to sit together, you can learn more about that approach in Building an Ideal Agile Team Workspace. Another aspect we leverage in the cross-functional model is to build a team of t-shaped people, more on that in Why Agile Teams want T-Shaped People.

Mitigating Bottlenecks

In the functional structure where we have silos for Engineering, Operations, etc work may wait on a particular function. For instance, you’ve got a lot of DBA work on and only so many people capable of doing it – blocker. This may also be due to understaffed roles or different priorities between teams. Aligning the organisation is key, for more on this see Collaborating Across an Enterprise from Atlassian Summit 2013.

With a cross-functional team we’ve immediately cut the cross team communication headache that used to take place, we can better align teams with the company priorities and we deliver more value to our customers.

Now go, grow!

So, with the functional teams you’ve got…

  • Engineering and QA teams pointing their fingers at one another, questioning who’s fault it is for the poor quality of a release,
  • the Operations team pointing their finger at the Engineering and QA teams for delivering a release that can’t be deployed, and
  • no doubt you can think a few examples from your own experience

Cross-functional teams are the best way to scale an IT or Engineering organisation. They enable an IT organisation to:

  • effectively scale as the company grows,
  • minimise bottlenecks and waste,
  • consistently deliver high quality product to their customers, and
  • maintain a happy and healthy workforce

Remember to take a pragmatic look at your organisation before deciding on an approach as you may find areas where a functional team will work best. For example, Legal is one area where I would advocate for a central team looking after all activities.

Ask yourself: can we afford to keep the current functional structure in place? To learn how to change from a functional to a cross-functional structure let us know your top concern via Twitter:

Velocity Counts in 2014 – A Preview of our Backlog and Commitment to You!

VC’ers –  Happy 2014 from Nick and I.  First off, we’d like to thank all of you for all of your encouragement, support and fellowship in 2013.  We are thankful for your steering and guidance and we are moved by your actions.  In 2013, we felt part of your Agile practice and part of your everyday experiences.  What you shared with us was wonderful and what you delivered back to your organization was great, and, in 2014 we can collectively do better!

Before I go any further, let’s take a minute to thank our fantastic sponsors that allow us to provide all of you with valuable content free of charge!

Appfire - North America's most trusted provider of Atlassian Enterprise Services

Appfire is North America’s most trusted provider of Atlassian Enterprise Services


Enterprise Tester by Catch Software helps teams deliver high quality products


Practice Ignition is the #1 tool for the modern accounting practice

What an exciting year ahead!  2014 is going to be nothing short of electric.  During the holiday break, Nick and I were hard at work coming up with an editorial calendar that will finally help you and your organization deliver against the intended promise of your Agile implementation.  We both know that you are not delivering your best and we aim to change that.

Thanks to our sponsors the free content we provide will:

  • allow your Agile implementation’s to become more stable and scalable,
  • make teams more predictable,
  • increase quantity and quality of output,
  • strengthen intra and cross-team collaboration,
  • increase team velocity,
  • allow individuals to achieve peak performance (their Nirvana state), and
  • help teams deliver substantial value back to your customers

Our Definition of Done for 2014 is simple:  Nick and I want to see an immediate and sustaining increase in your velocity.  Dare I say the obvious:  Velocity Counts!

Nick and I have never been this excited to write about content in the Agile space.  There is quite honestly so much going on in this space, that it’s hard to pick areas of focus.  Sadly, we must.  In order to keep our promise and deliver against our definition, we need to be laser beam focussed on the development of content in our areas of expertise.

In early 2014, Nick is focussed on creating content that will help: your teams take shape, move directionally, and create environments that inspire the very best from your teams.  This year, I’ve got my mind wrapped firmly around content that will grow individual performance.  I want 2014 to be your best, which requires you to be at your best – in order for you to deliver against the commitments you are making to your teams.  I’m going deep inside you and that giant brain of yours to make some much needed adjustments.  I’ll help improve your personal velocity and in doing so, your health and behavior.  Definition aside, expect nothing but one hell of a year at Velocity Counts! 

Now, more than ever, Nick and I are interested in hearing what you and your team are up to.  If you’re stuck on something, have a burning question that’s been haunting you, or have an ingredient of your own that you’d like us to share, simply Tweet @VelocityCounts or comment below.

Randall and Nick

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

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.

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.


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.