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:

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.

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.

Don’t have a strong product owner?

In this post we explore why a product owner is needed, and how we can ease the burden on the customer as well as the product owner by setting expectations and speaking in language the customer understands.

Recently received this email from a fantastic gentleman who runs an Engineering team in a wonderful part of the world (let’s call him Bob). Bob is facing some challenges with the business side of the company who is his customer:

  1. Business wants hard deadlines for completed functionality. However they do not provide clean and concise scope / acceptance criteria. Further, they struggle with the concept of iterating to a solution and just want it now.
  2. Lack of understanding from the business about the level of effort required to be a successful Product Owner. The business is the customer and the customer can not articulate their vision (perhaps they believe we should read their minds).
  3. The business can not focus, going from one thing to the next before Engineering has had a chance to complete the first item.

It’s great to get emails like this as it just reminds me we’re all struggling with many of the same challenges. For instance, I’m having a similar conversation with another fine gentleman (Steve) in another part of the world, at another company. The key difference is that Steve is on the other side of the equation. Steve is the business side that is struggling with an Engineering team which can not deliver.

I wanted to share the two sides, as told from different people at different companies, as they are useful in helping us overcome these shared challenges.

So, Steve is on the business side and can’t understand why the Engineering team just doesn’t deliver what he wants, when he wants it.

Steve and I walked through an exercise where I asked him for all of the requirements he wanted in his “2.0” release. He rattled off several things, and then started out on some more. I asked him why they were important, what he was trying to solve with each.

All the while his Engineering team is struggling – they hear “go this way”, “no, go that way” and never feel like they have clear direction or a vision. So, I continue with the gentleman (who should be wearing a PO hat, although is a business owner so “doesn’t have the time”) and ask him to order the top three things he wants, out of that long list of ideas. Steve does so.

I want to confirm with him – “are you sure these are key to 2.0?”, I ask. Steve says that yes, that is what he wants for 2.0. I explain that he hasn’t mentioned the UI/UX rewrite the team is currently working on, nor has he mentioned X, Y, Z from the teams backlog. “So why are they working on all this stuff which is nice to have and not valuable?” I ask.

Steve hasn’t noticed that he is pushing the team in a different direction every day. He hasn’t noticed that the vision has not been set, or communicated.

In that situation, and I’m sure this is similar to Bob’s, there is a lot going on. The business folks have a million things they want, but there is only one thing top of mind at the time you speak with them. So it looks like they have no vision. I asked Steve to write the release blog for his 2.0 – what would he like it to say, how would he pitch it to his clients, etc.

This was a forcing function to get Steve to consider the scope for his 2.0. It was a release planning exercise in language he understood – a blog post, not a backlog.

Now I’m not sure how successful this approach will be at every company, for every team. I do hope that it provides the business side an understanding of what is involved in being a product owner and setting a vision. Of course you can also use this as a tool to define scope for a release – if/when the business comes back to Engineering and adds something to the list you can respond with “didn’t we agree last Tuesday to do X, Y, Z first, and then move on to other items?”. Don’t let agile be an excuse for less discipline, more WIP, and less value being delivered.

Be agile. Be smart. Help the business side, or your customer, have some discipline and get value early and often. We need to educate our customers as much as we need to educate ourselves.

Got thoughts or suggestions for Bob or Steve? Share them in the comments below.

Agile 2013 – that’s a wrap!

Nick had a grand ‘ole time in Nashville for the Grand Ole Oprey Agile 2013.


Take a look at his posts highlighting the sessions he enjoyed most. If you haven’t been already, make sure you grab a ticket for next year, the conversations in the hallways are worth the price of admission alone!

Technical Debt meets Agile

Agile Coaching

Agile Metrics – Velocity is not the Goal