Author Archives: danrough

Private key errors from Logstash when shipping logs over SSL using filebeat

We use the filebeat shipper to ship logs from our various servers, over to a centralised ELK server to allow people access to production logs.

Because the logs are shipped from various data centres, the filebeat shippers are configured to send logs using SSL. To achieve that, we followed the how to guide. For the curious, that means that each of our servers has a filebeat.yml configuration file containing the following excerpt,

output.logstash:
    hosts: ["hostname:5044"]
    ssl.certificate: "/etc/ssl/certs/our.crt"
    ssl.key: "/etc/ssl/private/our.key"

and the inputs config file on our ELK server contains the following,

input {
  beats {
    port => 5044
    ssl => true
    ssl_certificate => "/etc/ssl/certs/our.crt"
    ssl_key => "/etc/ssl/private/our.key"
  }
}

I upgraded Logstash this morning, from 6.2 to 6.4 and found that Logstash wouldn’t start. When I inspected the Logstash logs I found errors as follows:

[2018-08-30T10:58:50,842][ERROR][logstash.inputs.beats ] Looks like you either have a bad certificate, an invalid key or your private key was not in PKCS8 format.

I checked the filebeat shipper logs too, and found errors similar to the following:

2018-08-30T11:26:02Z ERR Connecting error publishing events (retrying): read tcp ip.address.here:45896->ip.address.here:5044: read: connection reset by peer

In actual fact, I needn’t have gone further than the error that I found in the Logstash error log which said, “your private key was not in PKCS8 format”.

The SSL key that we had shipped to the box was not in PKCS8 format, which according to the documentation is a requirement. The fix in the end was simple, and was provided in this comment against a github issue. I needed to create a PKCS8 version of our existing key. To do that, I ran the following command,

openssl pkcs8 -in /etc/ssl/private/our.key -topk8 -nocrypt -out /etc/ssl/private/our.p8

To use the new PKCS8 version of the key, I also needed to update the beats input file to use the new our.p8 key file and then restart Logstash. The revised config is as follows:

input {
  beats {
    port => 5044
    ssl => true
    ssl_certificate => "/etc/ssl/certs/our.crt"
    ssl_key => "/etc/ssl/private/our.p8"
  }
}

Hope this helps someone else!

Advertisements

Getting Image and Flavor information from the Rackspace API

At Gamevy we’re lucky enough to have been accepted onto the Rackspace UK Startup Programme. In combination with that, we’ve been using Ansible to deploy new servers, and perform application deployments.

When you create a new server at Rackspace using Ansible rax module there are two pieces of information you’ll need from Rackspace. One of those is the flavor, this defines the instance type (the configuration of the instance – e.g. how much RAM it is given). The second is the id of the image (operating system) you wish to use to create the server.

To date, we’ve not found an easy way to get this information. Our current method is to use cUrl, get an Access Token, and to then make further requests to the API to get the required information.

Given this is an infrequent task, I normally forget the necessary steps. I thought that by noting them down I might save myself, and others, some time in the future. This post assumes that you already have a Rackspace account, and that you have API access via a key which is associated with your account. If that’s not the case, Sign Up here, and then follow these steps to get your API key.

It’s worth noting that this post focuses on accessing functionality provided by Rackspace UK. If you’re accessing from the US, the steps are the same, but  you’ll need to change the URLs that are accessed. Full information about Rackspace’s API can be found at their documentation site.

Getting An Auth Token

First things first, let’s get an Auth Token. To do this, you’ll need a few pieces of information from your Rackspace account: your username, your API Key and your account number.

Login to your Cloud Control Panel, and in the top right hand corner of the screen you’ll see your username with an arrow pointing down next to it. Clicking on that will reveal a menu at the top of which will be your account number, note that down, you’ll need when you make calls to the API, later.

From the menu, select Account Settings. On the resulting screen, access your API secret and note that too.

Create a file, call it whatever you want, I called mine rackspace-creds.json on your machine (I put mine in my home directory, for ease of access). The file should contain the following:

{
    "auth":
    {
        "RAX-KSKEY:apiKeyCredentials":
        {
            "username": "YOUR_RACKSPACE_USERNAME",
            "apiKey": "YOUR_RACKSPACE_API_KEY"
        }
    }
}

To get your Auth Token, open up a terminal and issue the following command

curl https://identity.api.rackspacecloud.com/v2.0/tokens -X 'POST' \
-d @rackspace-creds.json -H "Content-Type: application/json" | python -m json.tool

I’ve piped the output of the cUrl command through python’s json tool to prettify it. In the response you receive, you’ll need to grab your :

"token": {
            "RAX-AUTH:authenticatedBy": [
                "APIKEY"
            ],
            "expires": "",
            "id": "YOUR_AUTH_TOKEN",
            "tenant": {
                "id": "",
                "name": ""
            }
}

List The Flavors And Images Available To You

Now that you’ve got an Auth Token, you can go ahead and make calls to the API endpoints for Flavors and Images. I’ve pasted the corresponding examples below:

Flavors

curl https://lon.servers.api.rackspacecloud.com/v2/YOUR_ACCOUNT_ID/flavors \
> -H "X-Auth-Token: YOUR_AUTH_TOKEN" | python -m json.tool

Images

curl https://lon.servers.api.rackspacecloud.com/v2/YOUR_ACCOUNT_ID/flavors \
> -H "X-Auth-Token: YOUR_AUTH_TOKEN" | python -m json.tool

 

Iterating an ansible task using a dictionary object of variables

Recently we have been writing ansible scripts to deploy one of our applications. In doing so, we came across the need to configure 3 node processes as services. All of these node processes used a similar init script but required different values writing into the script.

We chose to use the template task thinking that with the 4 variables we needed to populate on each occasion we should be able to use the with_items method on the task to do what we wanted. We did plenty of Googling and couldn’t find a way forward and so were all set to revert to writing three separate implementations of the template task, and three associated templates.

Asking a question on the ansible IRC channel eventually yielded an answer and I thought I would share our implementation.

We start with a generic template, service_init_script.j2. The script itself is not important to this blog post, you should note that way in which the ansible ( / jinja2) variables refer to item.foo – this is important, and was our initial stumbling block. Each time the task is iterated upon the items within the with_items block are referred to as an item:

#!/bin/bash
### BEGIN INIT INFO
 # Provides: {{ item.service_name }}
 # Required-Start: $all
 # Required-Stop: $all
 # Default-Start: 2 3 4 5
 # Default-Stop: 0 1 6
 # Short-Description: {{ item.service_description }}
 ### END INIT INFO
# Taken loosely from https://gist.github.com/tilfin/5004848
 prgcmd={{ item.service_exec }} # What gets executed?
 prgname={{ item.service_name }} # What's the name (used to ensure only one instance is running)
 prguser={{ item.service_user }} # Which user should be used
 pidfile=/var/run/{{ item.service_name }}.pid # Where should the pid file be stored?
 logfile=/var/log/{{ item.service_name }}.log
export BJA_CONFIG={{ bja_config }}
start() {
 if [ -f $pidfile ]; then
 pid=`cat $pidfile`
 kill -0 $pid >& /dev/null
 if [ $? -eq 0 ]; then
 echo "{{ item.service_name }} has already been started."
 return 1
 fi
 fi
echo -n "Starting {{ item.service_name }}"
nohup start-stop-daemon -c $prguser -n $prgname -p $pidfile -m --exec /usr/bin/env --start $prgcmd >> $logfile 2>&1 &
if [ $? -eq 0 ]; then
 echo "."
 return 0
 else
 echo "Failed to start {{ item.service_name }}."
 return 1
 fi
 }
stop() {
if [ ! -f $pidfile ]; then
 echo "{{ item.service_name }} not started."
 return 1
 fi
echo -n "Stopping {{ item.service_name }}."
start-stop-daemon -p $pidfile --stop
if [ $? -ne 0 ]; then
 echo "Failed to stop {{ item.service_name }}."
 return 1
 fi
rm $pidfile
 echo "."
 }
status() {
if [ -f $pidfile ]; then
 pid=`cat $pidfile`
 kill -0 $pid >& /dev/null
 if [ $? -eq 0 ]; then
 echo "{{ item.service_name }} running. (PID: ${pid})"
 return 0
 else
 echo "{{ item.service_name }} might have crashed. (PID: ${pid} file remains)"
 return 1
 fi
 else
 echo "{{ item.service_name }} not started."
 return 0
 fi
 }
restart() {
 stop
 if [ $? -ne 0 ]; then
 return 1
 fi
sleep 2
start
 return $?
 }
case "$1" in
 start | stop | status | restart)
 $1
 ;;
 *)
 echo "Usage: $0 {start|stop|status|restart}"
 exit 2
 esac
exit $?

We then wrote our ansible script and call the template task thus:

- name: Create the service init scripts
template: src=service_init_script.j2 dest=/etc/init.d/{{ item.service_name }} owner=root group=root mode=755
with_items:
- { service_name: paymentHandler, service_description: 'Handles payments', service_user: blackjack_attack, service_exec: "{{ application_directory }}/apps/paymentHandler.js" }
- { service_name: tablePool, service_description: 'The pool of tables available', service_user: blackjack_attack, service_exec: "{{ application_directory }}/apps/tablePool.js" }
- { service_name: userManager, service_description: 'Manages users', service_user: blackjack_attack, service_exec: "{{ application_directory }}/apps/userManager.js" }
sudo: yes

So, we are calling the same template task, which in turn refers to the same jinja2 template, passing in a collection of dictionary objects.

The key point to understand here is that when the playbook is run ansible enumerates the items specified referring to each object as ‘item’. This is the reason why we had to prefix the variable names in the template with item.*

I’ve exposed both of these pieces of code as gists here, and here.

Do we need clearer roles and responsibilities?

Why are people are still preaching that better, more clearly articulated roles and responsibilities will improve productivity? Provide a transparent environment where people have a clear understanding of what they’re working toward, and its value, and you’ll get better results.

As I write this, I’m sitting on a train travelling home. I’ve just been through the blog posts in my RSS feed. Three offer very similar advice about how to improve an individual’s productivity in the workplace. Their answer to this perennial conundrum is that we need to provide clearer objectives and roles and responsibilities on a daily basis. Given that the posts originate from people promoting Agile as a more enlightened way of working, I shake my head in wonder. Really, I do.

The value of roles

There are times when clear roles and responsibilities are essential – this post is not to suggest that their use be completely dropped. Consider the outcome of the incident now known as the Miracle On The Hudson; having just taken off from New York City’s LaGuardia Airport, a US Airways aeroplane, flight 1549, struck a flock of geese. Both engines failed. Some 3 minutes later, the Captain and his crew, a First Officer and 3 Flight Attendants, had performed an emergency landing on the Hudson River. In an air crash, speed, accuracy of trained response and calm are paramount. Although the First Officer had been flying at the time, the Captain took the controls, leaving the officer to go through a 3-page emergency procedure to restart the engines. The three flight attendants showed passengers how to brace themselves for impact and took control of evacuating the plane, even as it filled with water. The captain walked up and down the sinking aircraft to be sure no-one had been left behind and was the last person to leave. Each of the crew members was helped by their training and their knowledge of their specific, unique roles and responsibilities.

The difference for IT

The problem, is that few business teams – IT or otherwise – face the same kind of challenge as existed for the air crew. In IT, problems tends to require a creative response, one that cannot be considered in advance, which no training will prepare us for, but which must be invented anew each time. Strict roles and responsibilities don’t help with this. Indeed, they may hinder it because instead of thinking freely, people are prescribed. Control does not sit well with creativity, originality or motivation. Attempting to control an individual in a group setting reinforces a silo-based mentality to work. That means that the attempt to control an individual through a strictly defined role and associated responsibilities, affects the whole system. In my opinion it compels people to work within the boundaries that are set for them – intentionally or otherwise.

Do rigid role boundaries assist in speed?

In the air crash example, knowing who is responsible for each task helped speed. Proponents of clear roles and responsibilities suggest that decisions are made faster and are accepted with less confusion. Yet in my experience one of the negative results is a reduction in collaboration. The classic case of this, which I am sure we have all experienced, is somebody justifying their inaction with: “well, it’s not my responsibility”. I’ve known many cases where people fought NOT to take responsibility for an unpleasant job or fought over who TOOK responsibility for a prestigious job and the result was always that the product slowed or sometimes stalled as collaboration evaporated.

Individuals can always change the rules

So far I’ve focused on the work. But software development is ultimately a people-orientated endeavour. I was thinking about this as I sat with my son – a four-and-a-half year old, to do his numeracy homework. For some reason he was writing a lot of his numbers back to front. I kept on trying to correct him and at one point said to him “just write me five nines”. His response was to write the number 5 and 9. Perfectly, I might add. Some might say it showed intelligence. I’m inclined to say that he was being subversive. Either way, it was a proud Dad moment. But that’s one of the problems with the advice being offered: people don’t like being told what to do. They either do what they think is best at the time, or in a small amount of cases intentionally subvert the system.

Demotivating boundaries

When we’re children recognition from our dads and teachers motivates us, as we grow older the influence of our peers is what counts. I tend to perform best when I know I am there to make a defined contribution. To this end, a degree of definition of my role and responsibilities helps, but a rigid boundary is demotivating, because it constrains my ability to contribute as much as I could or would like to. This demotivation is exacerbated when people have to discover where their responsibilities lie. I’ve heard people refer to this as being knocked back – they’ve tried to do something which is perhaps of interest to them, or where they perceive there to be an opportunity, only to be told that their contribution wasn’t wanted.

Doing things differently

So what instead? As with all pernicious problems the first step is to observe what is happening. You might find people in a stand up talking about the piece of work they’re doing, rather than the work the team needs to do. Perhaps you see executives or departments becoming more rigid in role demarcation. A lack of vision or sense of purpose might pervade the organisation. Worst of all, perhaps no-one thinks making things better is any part of their ‘responsibility’. Cause and effect is difficult to establish in a software development scenario, but you should be able to state your observations and assumptions. Establish what effect an improvement might have. Test your assumptions with others – what’s their opinion? Don’t fall in to the trap that it is your role to change people. Remember, the way in which people behave is far more likely to be driven by the environment around them than anything else. Once there is agreement in the group about the perceived problem, consider what you might change to bring about improvements. Test whether these improvements have had the desired effect. Respond to the feedback you receive. Rinse and repeat.

I know that those advocating clarity of roles and responsibilities see the same problems in demotivation and wasted efforts as I do. The difference is that they believe more control is the answer, while I believe that less direct control frees people to create their own solutions. Those 5 crew members on US Airways flight 1549 worked as a team, each within their specialisms, and brought off “the most successful ditching in aviation history”[1]. Software development teams need to be more cross-functional in nature, but I believe that they too can perform their own miracles – as long as they have an environment that supports them rather than dividing them.

Thanks go to the inimitable Joshua James Arnold, Lady H of Edmonton (but of no fixed Twitter abode), and the sartorially precise Mark Krishan (50 shades of) Gray for helping me to improve this blog post.

[1] New York Post, 2009. Quiet Air Hero Is Captain America. [online] Available at: <http://www.nypost.com/p/news/regional/item_Goem4fAiUd2hsctASfAjGJ>. [Accessed 28 November 2012].

Using The Voice Of the Customer As Input For A Retrospective

Previously, I have worked with a team whose overall effectiveness has been called in to question by people who the team interfaced with. Upon further investigation it became clear that the perception those people had of the team was largely based on anecdote and yet, as the lead of the team said, perception is reality.

The lead and I sat to discuss this and agreed to substantiate some of the comments being made and the process that we would follow to derive actions that we could then take towards discernible improvements. I think that what we ended with is an interesting way of looking at gaining input in to a team’s retrospective and contrary to the way I have seen it done previously, namely that the team sourced opinion from outside of the team rather than internally, and so wanted to share it.

We started by identifying the customers of the team and given that this was the first instance of running this process, we also chose to keep the group size small, identifying just the key individuals with an agreement that in subsequent iterations, we would extend the group.

We designed a small survey comprising 4 questions that we would ask of the individuals:

  1. What is your perception of the team’s performance?
  2. On a scale of 1 to 10, how would you rate the performance of the team?
  3. Given the rating that you have just given the team, how could we make ourselves a 10?
  4. Can you suggest any ways in which we could measure the effect of the improvements that you suggest?

Questions 1 and 2 in the above were actually of little significance in respect of helping the team to improve, their purpose focused more on providing some context to the presentation that would be made back to the team after the interviews had been conducted.

Question 3 gave the person being interviewed an opportunity to make specific recommendations for how the team could improve and so in our opinion, was the most important. Less important then was question 4 though it did serve to make the people being interviewed question the feedback that they had in response to question 3 and to offer the team with some sense of measures that they could use that would be meaningful to their customers.

With this data, the team lead conducted a Retrospective. It started with a presentation of the information that had been collected. The team was told from the outset that this was data that had been collected and that while they may disagree with some of the comments made, it was the perception of others and that therefore they needed to accept it as it was.

The remainder of the Retrospective was split in to three sections, an idea generation session titled “What Changes Can We Make That Will Result In Improvement?”, followed by an associated filtering session which looked at the ideas generated and asked the question “How Will We Know That The Change Is An Improvement?”. The purpose of this filtering session was to filter out those ideas that could not be measured one way or another. The team estimated the value an item would have in respect of impacting their performance using a relative scale and followed that by estimating the effort involved in bringing about the change. Both of these estimates were done using a relative points scale. Finally, the value estimate was then divided by the effort estimate to give an indication of the Return on Investment and the item with the highest return was selected for action by the team.

Experimentation: A Pattern for Affecting Measured Change

Note: This post is based almost entirely on one of the things that I took away having attended a talk titled “Agile Coaching Tips” by Rachel Davies held at Skills Matter but perhaps overlooked at the time. As such, the originating ideas are not mine and instead, Rachel’s. This post is more something that I have constructed as a result of my own recent thinking, primarily driven by my interest in the kanban community and talking with people like Benjamin Mitchell which has led to me growing more appreciative of the value of qualitative and quantitative measures. This in turn has led me to revisit one of the subjects that Rachel introduced in the talk she gave, “Making Change As An Experiment” (See between 38:36 and 42:09 in the video I have linked to.)

Why Experiment?

Rachel proposed, and I agree with her, that talking about change with somebody can often result in them becoming wary whereas using nomenclature, in this case talking of experimenting with something different, instead of using the word change can make those people involved and or potentially affected feel more comfortable. In that respect, I like the idea of using experimentation as a means to effect change within what I do as primarily, it is considering the feelings of the people that are involved in that change up front. So often in my experience that not insignificant factor can be overlooked.

Secondly, when thinking about experiments that are run in a laboratory, it is accepted that you may fail to meet your objective; you’re questioning whether you can change some thing’s existing state. In relation to that. because you had a hypothesis that were looking to prove or disprove, you will have had to measure the outcome of any actions you performed and the conditions they were attempted under.

With those 2 points in mind, I’ve taken Rachel’s original idea and noted how I think it could be used as a pattern to bring about measured improvements.

Experimentation As A Pattern

1. Understand the Current State

The first step in my opinion, is to understand what it is you are attempting to achieve overall (your vision). From there, the next step is to understand the first step (perhaps the first impediment you want to remove or the first improvement you want to make otherwise) you want to take you towards your vision. Techniques such as Retrospectives, The 5 Whys and A3 Thinking amongst others, can help here but above all, the one tool that I keep coming back to currently is Force Field Analysis.

2. Hypothesise

The received wisdom is that hypothesising should be the process that is used to understand the goals of the experiment with which I would agree. Important to me here though is that the goal should be something that can be clearly articulated to anyone, i.e. in the case of a development team, those outside of the team from a non technical background too. It is possibly worth noting the goals too, this is not something that I have personally done but I do see that it might have brought value to previous change efforts.

It is particularly key here that if the experiment you wish to run is related to a practice within a team, everyone within the team understands why you are wanting to introduce a new practice or change an existing one. Furthermore, it is important in my opinion that everyone in the team has an opportunity to discuss how you might change. This is important so that everyone is in a position to question the validity of their own and that of their peers approach on a daily basis throughout the experiment. In my opinion, it is for all those involved in the experiment to ensure that it runs as defined.

3. Plan The Experiment / Decide On How To Measure Effect Of Change

The idea that any change in practices or process should be measured is, as I describe above, one of the most important aspects of why I think that experimentation is a useful way of looking to introduce change. Based on the findings from Understanding the Current State and the goals derived from the work done whilst Hypothesising you should be able to define either quantitative or qualitative set of measures. It would be ideal in most cases if you were able to identify measures that you already have in place so that you can compare and contrast, but not essential. In the absence of existing measures, I would suggest that it is worth extending the duration of the experiment so that you can observe change over time.

By way of a simple example, let’s imagine that you or the team you work within notice that features are batching when they get to the tester and perhaps even that in a lot of circumstances, the features end up having to be reworked. The overall affect of this is that the team is unable to concentrate on other work and that the features themselves take longer to be delivered unnecessarily. Some measures you might consider are: The amount of re-work, for example the number of times that a feature is passed between a developer and a tester; the number of bugs raised against a feature whilst it is being developed and finally the Cycle Time for features.

Finally, decide how long the experiment will run for. As I mention above, be mindful of how long you will need to gather data that will be statistically significant. If you already have a good set of data to compare any new metrics with then you can (though not necessarily should) use a shorter period of time and conversely, I would suggest that in the absence of any data to start with you should consider leaving the experiment to run for as long as possible.

4. Run the Experiment

As I’ve suggested in the sections above, I think the most important things to be concerned with whilst running the experiment are as follows: Have a clear vision for what you’re trying to achieve and be able to articulate a set of discreet measurable goals for the experiment. Ensure that, on a best endeavours basis (acknowledging that some people will always be difficult to be persuaded of the benefits of one practice over another. See Diffusion of Innovation, the Five Stages of the Adoption Process) everybody in the team is signed up to the experiment and know that they have a role to play within the experiment; time box the experiment so that those that aren’t necessarily persuaded of its virtues know that it is for a set time and furthermore to ensure that the amount of energy expended on an invalid hypothesis is minimised; take time at regular intervals to ensure that you remain true to the practices or process improvements that you are trying to bring about, without doing this it will invalidate the experiment.

Finally, at the end of the experiment take another opportunity to review what happened throughout the experiment, not just from the perspective of the measures that you have in place but from the perspective of those involved too; how did everyone involved feel the experiment went and what benefits did they feel it brought? In addition, my advice would be to be as transparent with all affected parties as possible with the measures that you are using and the results that you publish. I think this is important if for no other reason than it might generate further discussion, particularly outside of the team.

5. Iterate

It’s important to recognise that what is learnt from the experiment is the most important thing, as opposed to whether or not you succeed in meeting your goals. If you successfully met your hypothesis that’s great, but if you didn’t, ask yourself whether there is still value in what you are trying to achieve? If there is, can you change your previously defined practices to derive the value you are hoping to? Importantly too, are the measures that you defined still valid, are there ones that could be replaced with others, alternatively are there any that can be added to allow you to better understand performance against your goals?

In Conclusion

I am sure that the using experimentation as a pattern for change is something that others including Rachel have suggested before and so what I am proposing is nothing new, it is also without doubt that making change using the technique that I suggest adds overhead to the change process itself. I do firmly believe though that using experimentation as a technique to introduce change is beneficial owing to its focus on using measurement which allows those involved to be objective in their appraisal of any impact and that lastly, it considers the people involved up front thinking about the fact that when confronted with it, most people are wary of change.

Output from the Session I Proposed at the UK Agile Coaches Gathering, 2010

At the recent UK Agile Coaches Gathering (held at the magnificent Bletchley Park), the theme for which was Helping People Grow,  I proposed a session titled “Leaving a Legacy, How Do You Leave an Environment in Which a Team Can Continue to Grow” for one of the slots during the Open Space. There follows a summary of the session and then the notes that I captured, augmented from memory where possible.

To start I thought that I should provide an explanation as to why I proposed the session. In recent months, I have heard an awful lot of stories about change efforts that have been fantastically successful but when one thing is changed, perhaps a person leaving an organisation or the structure of the team changed, the momentum from that effort goes too and in some circumstances then leads to those involved moving backwards to their previous state. Furthermore and whilst I have never held the title of Agile Coach, from personal experience there seems to be a ceiling within organisations which when reached by a team, change becomes more difficult; typically because they are needing to challenge hierarchies or the received wisdom within that organisation.

Prior to the session, I did some preparation and thought about how as a coach you ensure you leave a legacy I came up with the following:

As a coach, you need to help a team learn how to change but that at the same time, you need to help an organisation learn how to allow that team to change

I then specifically listed a couple of points for each of Team and Organisation that I thought would ensure a legacy of a culture of continual change. From a Team perspective, I noted that I thought primarily they need to be taught how to be introspective and secondly and linked to the the first point, you need to also provide them with a tool set to facilitate their continued change. Form an Organisation’s perspective, I noted that you would need to help them understand their purpose, to help them understand the value they want from that team and lastly, how to communicate both those things to the team.

Once I’d set the scene with the above, we moved in to the discussion the notes of which follow:

  • The team need to get to a point where they have the courage to stand up for what they believe in
  • A coach should not become too embedded within a team
    • Doing this reduces the team’s reliance on the coach
  • Internal learning within a team leads to a team encountering blockers outside the team
  • Teams can be too busy building stuff to have a vested interest in removing the impediments outside their team
    • The above is most apparent in Scrum when the Scrum Master is delivery focussed (e.g. a Project Manager or Lead Developer) as opposed to being focussed on Process Improvement
  • It is key that the team needs to feel as though they own the process
    • Process Smell: 1 person owning the process
  • A lot of the examples given by teh attendees centred around organisations that were hostile to any change in the first place
  • Even if you have somebody that really cares about improving the team, people, including those outside the team need to experience the benefit before they will actually assist in further improvement
  • (Team reaching a ceiling) Awful lot of organisations that can’t articulate their vision
    • Means that they struggle to say no to additional work load as a consequence meaning that the org is just busy, no slack
    • No tools to resolve conflict
  • It was noted that is is harder to help an organisation be able to define and communicate their values when they have existed for a long time
  • Is the answer, in terms of leaving a legacy that you leave a team that have a clear set of values that they believe in?
  • To test whether in a coach’s absence the team is still being successful the following might be considered to be good indicators:
    • Are they still working as a team
    • Are they changing things
    • Are they still focussing on quality, internal and external
    • Are they learning
    • Are they innovating
    • Can it still be said that they have confidence
    • It was noted that the tests above are valid at an organisational level too
      • e.g. Kanban boards spreading outside of IT departments
  • Differentiating factor? If teams or the organisation is stressed?
  • See image below, showing how trust of a team is derived by others, thanks to Rachel Davies
    • Reciprocal though is that the others need to know that you as a coach know what you’re doing
  • We should accept that change efforts are incredibly fragile. e.g. When a new leader enters an organisation they will always want to make their own change
    • Credibility comes from evidence: gut feel is not enough
  • Is transparency part of the answer?
  • Are the goals of the team and the organisation aligned? If not, changes in practices will never flourish
  • Is the thing that is missing conversation? In a hierarchical structure is the ability to hold conversations across all levels there?

Image: Trust Equation

Thanks to all the participants who came along to the session and made it what it was, I enjoyed it and learnt something too, hopefully the same can be said for yourselves.