Blog

Developing HTML Forms

Developing useful and professional HTML forms requires a lot more work than simple examples might suggest. There are a whole range of problems such as handling initial data, client-side validation, server-side validation, optimistic concurrency and performing the final action. This post explores the various steps.

The initial GET request

The initial GET request is a simple subset of what we need to consider. This is made up of two parts:

  • Load any initial data and convert it into a form suitable for rendering.
  • Render the form as HTML and transmit that to the client.

Gathering initial data is simpler for forms that are initially blank. Forms that provide editing will need to get the original data, convert it to a values that are suitable for HTML inputs and then render the form.

The POST request

When users fill in the form they post their results back to the server. Regardless of the client-side code, we need to do a number of things.

  • Parse and validate the entered values.
  • If valid, perform the intended action.
  • If invalid, render the form with error information.

If the intended action is an edit to an existing logical record, we might need some of the original data from the database, and we might need to convert the POST data into a form suitable for our application or database.

If the data is invalid then error information needs to be rendered back with the fields. You need to know which fields are invalid and how to help the user to correct what they’ve entered, and this needs handling in a way that can be rendered back into the form.

Converting data

HTML forms support key-value pairs or text, that’s it! Any structure is purely coincidental and is not understood by the browser. There is also support for files, where the value is binary and comes with a content type, but that’s beyond the scope of this post.

Often, when working with structures data such as objects and arrays field names can be generated according to a pattern. Using Node JS modules such as flat help with bi-directional conversion of structures. More complex conversions will involve numbers, boolean and dates.

The conversion only needs to be done on valid data. If you are converting invalid data it is often a mistake.

Rendering and validation

Rendering is needed for both the GET and POST requests so it makes sense to use the same trunking to do this. The only real difference is that the POST request involves rendering error information. This is where forms get complicated as you might add classes to fields to show their status and include a header with more complex information.

You might also have some optional client-side helpers that make the user experience better and provide client-side validation and assistance.

The validation rules are often rendered to the client as HTML5 or ECMAScript but must also be enforced on the server to avoid security issues. Inconsistencies in these rules create opportunities for users to exploit the system and for valid data to be rejected.

Keeping an abstract data structure that represents the fields, their validation rules, rendering hints, current value and any error status, makes it easier to develop rendering templates field and provide consistent rendering and validation for all conditions and field types. It also  makes debugging much easier as you can inspect this structure more easily that looking at the complex HTML output.

Optimistic Concurrency

Optimistic concurrency is extremely important when editing data on the web. It allows people to modify data out-of-process without the server keeping locks.

There are two common models, although sometimes something more complex is done, these are:

  • Fail if modified and
  • Last one wins.

The first approach requires sending information with the form that lets you determine if the data on the server has been changed by another user or process since the form was presented. This might mean a hash or revision identifier of a logical record, such as that used by Couch DB, or it might be a complete copy of the original data so that data can be individually checked.

The second approach is simpler and often the most appropriate, depending on the granularity and nature of the data. With either approach, one user loses out, the difference with this approach is that the first user loses and doesn’t get to know about it. When considering how and why data is updated there are many scenarios where forcing the second user to lose and try again gives the same result as ignoring what the first user did.

Some database technology includes optimistic concurrency systems. It is often useful to combine the initialisation step into the POST request to get what we need to overwrite existing data without error, especially when implementing a last-one-wins approach.

Finally

This post has been written to cover some of the issues that can arise when developing HTML forms, it is not comprehensive and assumes the usual level of support in your HTTP server for dealing with general HTTP request handling issues.

TDD or Test Driven Development Explained

TDD or Test Driven Development is something that’s easy to talk about but harder to do and a lot harder to do well and get value from. Done with good judgement TDD can help produce excellent quality code that is resistant to bugs through the ability to validate a systems behaviour quickly and consistently through a complementary suite of tests written using a unit testing library. Code written to be unit testable from the outset requires more care in it’s structure and helps developers view their design decisions through the eyes of future maintainers. However all this does require effort and may stretch delivery lead time and in the early stages of a new product this could be undesirable.

Oliver Shaw went back to basics at Agile Yorkshire to explain the basics of TDD and the red, green, refactor workflow followed whiled writing code as well as the bigger picture value and gotchas of a large testing code base.

 

Quick and Dirty Swap File (Linux)

Need a swap file on a Virtual Machine that didn’t come with one? Don’t care about the size, name or location? This is for you…

#!/bin/bash
fallocate -l 1G /swap
mkswap /swap
chmod 0600 /swap
swapon /swap
echo "/swap none swap sw 0 0" >> /etc/fstab

I use lots of tiny virtual servers for development and testing and on most hosting providers they don’t come with a swap file by default. Sometimes I need a little more memory to get over a hump, such as installing or compiling software, but not for general operation so a bigger machine is overkill. I found lots of step-by-step guides online but I couldn’t find a full cut & paste script very easily online so I’ve posted one here.

Not for use in production, unless the size and location all happen to match your requirements.

Shrink QEMU/QCOW2 Images

Needed to shrink a full directory of QEMU QCOW2 images today that had grown over time with snapshots and general use. While there is information around on the web about it, the focus is on single images and the code provided are just examples.

Here’s a script to keep around that shrinks and compresses all images in a folder, and shows progress:

#!/bin/bash
for imageFile in *.qcow2
do
    echo "Processing $imageFile"
    mv "$imageFile" "$imageFile.orig"
    qemu-img convert -p -c -O qcow2 "$imageFile.orig" "$imageFile"
done
echo "Warning: Test images before deleting the .orig files"

For convenience I stuck this in my QEMU image directory and made it executable. Be sure to test images and then delete the “.orig” files to save space.

Better Listening is Important for Better Software Solutions

Listening is a skill we generally don’t give a second thought to but, improving listening ability is possible with careful attention and work. Listening is an important skill for all product developers for collecting feedback and gaining insight into how people are reacting to new features. Stephen Mounsey presented at Agile Yorkshire and talked about how listening skills are especially important to testers gathering and interpreting data of all kinds and from various sources.

Conway’s Law Explored and Explained

Conway’s Law was observed by Met Conway and made famous in Fred Brooks’ 1975 book The Mythical Man-Month. It states – “Any organisation that designs a system will produce a design whose structure is a copy of the organisation’s communication structure”.  Considering the architecture of a piece of software can influence its overall value and usefulness, it follows that giving careful consideration to organisation structure and behaviour is important. However something as fundamental as human behaviour and relationships are not easily corralled. Jame Hull spoke at our Agile Yorkshire event and eloquently explained Conway’s Law, exploring it’s meaning and discussing how it may be harnessed.

What is Servant Leadership and What Can it do For Any Organisation

Servant leadership is often refereed to as a complement to a lean / agile software delivery approach. One of the traits sighted for servant leadership is to lead in a way that supports others and leadership in this context doesn’t mean you have to be the boss. Leading when your not in charge is something that anyone in any role can do and can help transform the effectiveness of any group.

Victoria Cassells has extensive leadership experience and has been closely involved with the servant leadership movement. She shared some of her experience at our Agile Yorkshire meetup to explain how the servant leader’s behaviour differs and can significantly amplify influence and impact.

Skills – What Really is Agile Coaching [presented by Geoff Watts]

Software is mostly hand built by people working in teams and good teams generally build better software more regularly. That’s a bold statement but software products that are reliable, easy to use, fast to respond and get the job done require many different skills and that normally needs a team of people working well together. Layer on top of all that the need to be commercially effective and teamwork become even harder to manage.

Geoff Watts is one of the most long standing Scrum trainers and the author of The Coaches Casebook. He visited Agile Yorkshire and talked about what agile coaching is, how it differs from other forms of coaching and some traits coaches can look out for in themselves or the organisations they work with.

Geoff Watts: 00:00:11 Okay, I’ve been told to stand over here because this is where the light works best. You guys are no dark to me. Just about to make you out there. Evening, how are you doing?

Audience: 00:00:18 All right.

Geoff Watts: 00:00:20 Good, good, good. All right. I’m expecting a nice Northern interactive response rather than down south, mm-hmm (affirmative). Okay, yeah. Thanks to Roy for his introduction. Brief introduction from me, so yes I had two main parts to my job. I have the agile side of things where I’m a trainer and I’m a scrum coach and up into a few years ago, I was scrum master and product trainer and projects and things like that. Before I was a scrum master, before I got involved in the agile space, so I was also a leadership coach. That was the first job that I had. Those two streams of my work have coexisted for the last 15 or 20 years and everybody loves a Venn diagram.

Geoff Watts: 00:01:08 If I was going to create a Venn diagram, you’d have my agile a little bubble over here and you have my leadership bubble over here, and then in the middle obviously, there’s quite a bit of overlap where the leadership coaching merges into the agile space. That’s primarily what I’m here to talk to you about today. We would also mentioned a couple of books. The first book I wrote was a scrum book, so it was purely about being a scrum master and servant leadership in the agile space. The second book that I wrote was a coaching book, so didn’t mention agile once. I didn’t mention scrum anything to do with agile at all, and so that’s what I’m here to talk to you about today, the coaching but not the agile book.

Geoff Watts: 00:01:44 It was interesting that I was honored as always to be asked to come and speak at an event, but equally I was quite flattered and honored and encouraged and excited to be asked to come and talk about this book rather than the agile book because my mission might be too strong a word, but what I’ve been working a lot on over the last five years is to try and make that middle bit of the Venn diagram bigger, not just for me but for everyone. I wanted to try and get the disciplines and the professionalism of leadership coaching more into the agile space, and that’s what I’m going to talk about today.

Geoff Watts: 00:02:23 What really is agile coaching is one of … I want to explain why I wrote the coaches case but not the agile book because that’s pretty much the number one question I get asked about is why did you write a book that’s nothing to do with agile. I want to talk a little bit about a couple of the traits within the book because the book just talks about a number of traits that people have and at some point during this talk, I want to explore well what does that mean for agile coaching, so that middle bit of the Venn diagram again. I’m hoping it’s going to be a little bit more of a conversation than me just standing here and talking, but I guess that kind of depends on you as much as me, so we’ll see how that goes. Then why did I wrote the coaches case? Well, there were multiple reasons, but the big ones really were like I said to bring professional coaching into the agile world and to try and give people a way of explaining what coaching actually is. I got two kids and they get asked regularly what does your dad do, all right and even if they were just talking about the scrum side of things, that’s embarrassing and difficult enough for them. The coaching side of things is just as difficult for them. Now I already pointed out all the letters on there, but what I would like you to focus on is this stuff at the bottom.

Geoff Watts: 00:03:36 It says there’s scrum coach, professional coach, leadership coach, personal coach, sports coach, there’s a lot of other coaching that I do, but each of those is some subtly different and some quite significantly different. Sports coaching very different to leadership coaching. To help explain what coaching is, is very much to get that across and for some people to help them sell the idea of coaching within their organization and in some cases to themselves, but maybe talk more about that later on. The book is full of tools and techniques, you could try this, this is an exercise you could run if you’re coaching somebody or coaching a team so give people a whole load of tools that they can use.

Geoff Watts: 00:04:15 Then too at the bottom really which if I’m being brutally honest are, what this was really about to try and hold that mirror up to be agile world, to encourage self-reflection. All those people out there that have the term coach in there either job title or job description, they say how you and your organization and your team, your department, is how you define coach in any way similar to how perhaps others might define the term coach from the professional world of coaching and then the bit of catharsis. This is me overly over sharing, so I’m a bit of an oversharer. I tell people too much about myself, I apologize for that, but that’s just how it is. If you do get around to reading the coaches paid case, but basically it’s how screwed up is Geoff. Each of those traits is it’s a semi-fictional case study about … I wrote it with a lovely lady called Kim who’s becoming more popular than me on the agile circuit, who gets more invited to Malta. I’m not bitter, she’s lovely but it’s a collection of her coaching clients, my coaching clients, and a little bit of creative license to make the point, but equally there’s a lot of me and Kim in there as well. A bit of catharsis to some self therapy America. Yeah, if you want to insight into Geoff’s mind, then you can read that. The book, what is the coach’s case book so it doesn’t mention agile, it doesn’t mention scrum once.

Geoff Watts: 00:05:38 Okay so, it’s nothing to do with agile. It’s purely about coaching individuals and each of the chapters focuses on a particular trait that these people have and most of these traits, I’m pretty confident that you will relate to in some regard, okay. We’re talking about perfectionism. I mean I could do a quick straw poll. Hands up who thinks they’re a little bit of a perfectionist. All right, and they’ll probably get yeah about half the room. All right. Some people proud of being a perfectionist, some people a little bit guilty about being a perfectionist, depends on the circumstances. I’m not a perfectionist when I’m doing the garden at home, but I am a perfectionist when I’m doing a spell check or things like that.

Geoff Watts: 00:06:19 Looking at how does perfectionism play into our strengths, but also if it sounds have kilter, how can perfection also be something that traps us, actually limits our performance. There’s 12 traits, each of them with a story and we looked at how those traits can get a little bit out of balance. What was working for them, what was helpful in getting them to where they are and achieving the successes that they have achieved because they’re all good things. Okay. If they’re over done, if they’re out of balance or under done, then they can actually be harmful. Perfection is doing a good thing going to talk about but when does it stop being a good thing?

Geoff Watts: 00:06:59 All right, and so this is about coaching individuals to help recognize that to use the strengths, the good parts of those traits, but also recognize when those traits are not helpful anymore. Does that make sense? Cool. Well obviously, I haven’t got enough time to talk through all of them and Roy has already prefaced this with when Geoff finishes, we can go to the pub so that seed is in your head already. All right. I’m working against internal beer clock here, which I’m very aware of and I’m not drinking because I got a drive. This is hard for me. Normally I could just yeah hang on you with you. All right, so these are the three that I’m going to talk about today.

Geoff Watts: 00:07:38 Well from my perspective, this was interesting because it was a surprise, which of the 12 things that I talked about in this book the one that was by far and away being picked up on the most in the agile space, and I wasn’t expecting it too. Even though studies and statistics will say high numbers of … 70%, 75% of people have experienced impostor syndrome. I wasn’t expecting it to have picked up as much notice in the agile space as it has. I see lots of people talking about impostor syndrome now, tweeting about it, blogging about it in the agile space and that’s a great thing. That’s the middle bit of the Venn diagram is expanding there.

Geoff Watts: 00:08:21 The people-pleasing what I want to talk about and that’s not necessarily surprise for many people when we talk about what does that mean. Then perfectionism is another one, which quite highly correlated in realms like software development and things like this. I’m just going to talk about those three. If there are any other that you’re interested in that, we don’t get to go into a lot of detail about there’s going to be a little bit of time hopefully, and then where we can have some questions and you can talk about those, but those three we’re going to talk about. What is impostor syndrome? I said I was going to have a little bit of a conversation, so let’s start that conversation off.

Geoff Watts: 00:08:55 When I say impostor syndrome, what does that mean to you? Tell me something that you know about this already.

Audience: 00:09:03 I’m not good enough.

Geoff Watts: 00:09:04 You’re not good enough. Well okay, I know you are, but you think you’re not.

Audience: 00:09:09 Yeah.

Geoff Watts: 00:09:09 Yeah. Okay. All right. Anything else?

Audience: 00:09:12 Fear of being found out.

Geoff Watts: 00:09:14 Fear of being found out. By who?

Audience: 00:09:15 By those people, by everybody.

Geoff Watts: 00:09:17 Everybody. Yeah, it’s not about necessarily being found out by hierarchy, by management, by anybody. It’s idea that if I walk into a room, my imposter syndrome is very, very high, my sort of internal monologue is saying I’m probably the least qualified person in the room. Before you know anybody, your default approach is everybody else is smarter than me, I don’t deserve to be here. All right. I’ve got to where I am because of good fortune or circumstance or riding on the coattails of others, and eventually someone’s going to turn around and say, “What the hell do you think you’re doing, standing on a stage in front of 50 people talking about psychology.” Someone’s going to come in and yank me out of this room in a minute and say, “Get back in your corner jet,” that kind of thing.

Geoff Watts: 00:10:03 All right. It’s not humility, okay, it’s not self deprecation of just sort of lowering expectations by saying I’m not quite as good as you think I am. It’s a genuine internal belief that I’m not good enough, and people really misread me. The people who have faith in me have really got it wrong and as I said studies have shown that up to 70%, 75% of people have experienced this quite significantly at some point in their career. All right. I’m going to click, okay. Yeah, we feel like a fraud and this word fraudulent, it does come through, soon we’re going to be found out. Luck is responsible for success. Success even though you’ve got it is unlikely to be repeated. This is this belief that okay maybe we’ve been lucky once, but I can’t count on that happening again.

Geoff Watts: 00:10:53 No matter how many times you are successful, there’s always this feel that next time I won’t be so lucky. All right. Every promotion makes it worse. The more that everybody says oh good job, good job, you deserve more responsibility, the anxiety level increases because you haven’t internalized that success yourself, you don’t think you have that capability, you’re now being put at a higher level and the consequences that are higher. Interestingly, I said this has been picked up quite a bit, so I’m wondering given what I’ve just told you about imposter syndrome, most that was obviously fairly negative, but are there any advantages that you can think of?

Audience: 00:11:32 Humility.

Audience: 00:11:34 Drives you to higher performance.

Geoff Watts: 00:11:36 It drives you to higher performance I head.

Audience: 00:11:38 Humility.

Geoff Watts: 00:11:39 Even though I said it wasn’t humility, it can come across as humility and certainly it’s not arrogance, so we’re not going to be running the risk of being arrogant, all right or cocky or hardheaded or anything like that. Okay. Yeah, there’s that we’re naturally cautious if you like.

Audience: 00:11:55 You rely on people more and you tend to.

Geoff Watts: 00:11:57 Yes, yes. We will look to other people, actually respect other people’s contributions more perhaps, which can lead to greater bonding, greater trusts, greater rapport so that’s a good thing. Any other advantages?

Audience: 00:12:14 Can I say questioning?

Geoff Watts: 00:12:14 Questioning of?

Audience: 00:12:17 Well, what you do know introspectively as well as …

Geoff Watts: 00:12:23 Yeah, there’s a lot of self-reflection that goes on with impostor syndrome about questioning of yourself, which ties in with the idea of humility and a lack of arrogance. Our default responsible … Well, I might be wrong here that that’s something that comes quite normal and actually if we do think that through and we use that to our advantage if where might I be wrong here, where might I be found out, where are the gaps in my knowledge, and we really don’t want to be found out, then we work harder and we fill those gaps quicker than other people. We can actually achieve quite a lot as a result of this, but the anxiety levels are quite high as a result, so there’s a big cost to it internally. All right.

Geoff Watts: 00:12:59 We talked a lot about the disadvantages, but if you’re trying to think to take those two and think well if you’re an agile coach, and we’ll come back onto that term in a minute, but anyone who has coaching responsibilities so that could be a scrum master, it could even be a product owner, it could be an agile leader within an organization. When you’re trying to create an agile culture and foster as an agile team, why is it important for that person to know about how to handle this?

Audience: 00:13:26 Because you might have responsibility for someone’s development. If you can understand how they could be, then you can then say you can relate to me and put yourself into their situation.

Geoff Watts: 00:13:36 Okay. If we’re aware this is happening, we can have greater empathy.

Audience: 00:13:39 Yeah.

Geoff Watts: 00:13:40 Yeah. If we’re aware of how people are naturally reacting to the anxieties and insecurities they have, we can perhaps go some way to reducing them, through increasing their confidence. What others things might be useful to be aware of? Think of this thing or any situations where a team that you’ve been a part of knowing that there is now a term for this and these sort of symptoms are out there, okay yeah maybe, maybe I didn’t realize this was going on or maybe I did, how if I would change the way that I dealt with that or we dealt with that, could we’ve had a more positive reaction within the team. Yeah.

Audience: 00:14:30 Probably prevents you from encouraging or complaining hardship.

Geoff Watts: 00:14:34 Okay.

Audience: 00:14:36 Not blaming for failure, but failed to yourself.

Geoff Watts: 00:14:40 Yeah, okay. All right. This fear of failure that we’re talking about is going to come up in a couple of other traits as well. It’s one of the biggest drivers that we have the fear. Okay, fear is a big driver in humans and something that we can either use and be aware of it and manage constructively or if we’re really evil, we can manipulate people, with this idea of fear of failure and we’re looking for in a self-organizing team. Some of the things that we’re looking for in a self-organizing team is productivity. All right. We want people to take the initiative. We want people to step up and be self managing rather than defer to somebody else. One of the things we need in order to do that is confidence in ourselves.

Geoff Watts: 00:15:21 All right. Confidence in our teammates, but that comes later, but first of all confidence in ourselves, the willingness to take risks. There’s a lot of risk, there’s a lot of vulnerability involved in self management, taking responsibility, stepping up, putting your hand up to make an estimate with incomplete information, to deliver something at the end of an iteration and ask for feedback on that. It’s quite daunting at the best of times, but if you’re constantly thinking as well as I might not be perfect in what I’ve done, it may well reflect on me as a person and give someone an opportunity to actually call me out on what I overly anxious about my own performance and ability.

Geoff Watts: 00:15:59 It’s very difficult to expect or very, very hard or even unfair perhaps to ask a team to do that without being aware of their anxieties that are driving their behaviors. An agile coach being aware, but also as agile coaches have impostor syndrome. How might that manifest itself in the agile coach? How might have that impact their behavior?

Audience: 00:16:27 Not being too confident about asserting their experience or opinion.

Geoff Watts: 00:16:34 Okay, so not being confident about asserting their experience or their opinion, and that can work both ways. All right. I’ve got an idea, I’d like to try something, my gut is telling me this, but I’m not really sure that I can pull it off so I’ll let it go or I don’t necessarily have the confidence to broach the elephant in the room with the team, will they finally twig that I’m not really up to the job or equally the other way around. That I’m so insecure about my role that I don’t trust the team to see my value unless I exert my authority. Does that make sense? To push too hard, to try and get some validation of my value that I’m adding to the team. Being aware of these things is absolutely critical.

Geoff Watts: 00:17:18 This idea of self-awareness and self-reflection important at the team level and the agile coach level. Agile coaches because of what they’re doing in terms of trying to develop self- organizing teams rather than implement hierarchical procedures have to model behaviors, okay, and one of the big behaviors that an agile coach needs to model is self-reflection, self-awareness. This is something we need to encourage in a team in order for them to be self-managed and if we’re not doing that ourselves, how can we expect other people to do that? Otherwise, it’s become basically self organize like this. Self organized as I tell you, all right, which is contradictory.

Geoff Watts: 00:18:06 What can you do? Well, one of the first steps that we need to do with someone who’s really struggling with impostor syndrome is just to help them objectively look at their successes and get them into the habit of internalizing and owning those successes. All right. I want you to do something for me. I’m not going to ask you to do it in front of everybody else, but just someone else in the room. What I’m going to do is I want you to think back and come up with let’s say around about three, three things, three things, three events, three achievements, three successes in your personal, professional life that you’re proud of that you’ve done, all right, that you’re proud of.

Geoff Watts: 00:18:46 It could be that you’ve achieved a certain level of proficiency in coaching children’s cricket, why did that come to mind because I’m doing my level two next month. It could be that you swam 104 lengths of a pool non-stop or it could be anything. It could be you overcoming physiotherapy. It’s something that you’ve done that you are personally proud of. Okay, the other person is not going to comment on it, they’re just going to listen, just take that information in. Three things that you can … Then you’re going to tell somebody else in the room and they will tell you their three things. That’s all I want you to do. I’m not going to ask anybody to tell anybody else.

Geoff Watts: 00:19:23 You’re not going to have to stand up and share in front of the room, but just two or three things, couple of minutes. That’s all, over to you. [Crosstalk 00:20:08].

Geoff Watts: 00:20:08 Thank you, thank you for that. I’m not going to ask anybody to share their successes with the rest of the room, but did anybody feel uncomfortable doing that?

Audience: 00:20:08 Yes.

Audience: 00:20:15 Yes.

Audience: 00:20:15 Yeah.

Geoff Watts: 00:20:17 Even though you knew you weren’t going to be judged on that, even though you knew we’re going to be pulled up on that, just talking about yourself and what you’re proud of, I mean that’s not just a British thing. I mean it’s very easy to say it’s a British thing, but it’s not just a British thing. Maybe it is bigger than Britain. I haven’t really done a study, but that thing, it’s uncomfortable but that’s often the first step in bringing this back into balance, being able to sit and hear from somebody else what you’ve done and learn to accept feedback about your qualities and take some time to not just immediately deflect that. Okay, so things to look out for when people say oh you did a good job there, what’s your reaction? Is your reaction oh yeah but? All right.

Geoff Watts: 00:21:02 As soon as you hear those words, okay, all right, what’s going on here, learn to accept compliments and help … I know there’s lots of retrospective techniques around things like appreciation. It’s just things get into the habit of being able to appreciate what others have done but also appreciate that others are appreciative of what you bring. Now that’s often overlooked. This idea of there’s career timeline is the technique they’ll do with a lot of people just actually get people stood up and in the moment a little bit more than just sitting there and talking to somebody, physically occupy the space of their career time. This is 1995 when I graduated and nobody thought I ever would graduate, so I was quite pleased with that.

Geoff Watts: 00:21:40 Okay, now moving on to 2001 and this happens and moving along the timeline, feeling like they’re in that position, it accentuates that feeling. We get into the habit of that. If we don’t, all right self-management definitely suffers. Okay, we don’t have the confidence to try new things. We don’t have the confidence to step up and take responsibility, to take the risks that are required, the teamwork and self-management. All right. That’s the first one. Second one, people-pleasing. This is again probably the second most common thing that people will associate with. When I say people-pleasing and I’ve got a little picture on there, which gives you a hint, but what does it say to you? What do you think I’m talking about here?

Audience: 00:22:29 Taking on too much.

Geoff Watts: 00:22:30 Taking on too much. Okay, so people ask you to do something, your immediate reaction is yeah, okay.

Audience: 00:22:36 See what people want to hear rather than the truth.

Geoff Watts: 00:22:39 See what people want to hear rather than the truth, yeah, and willing to …

Audience: 00:22:40 To walk over you.

Geoff Watts: 00:22:41 Let people walk over you, so they can take advantage of your good nature. Anything else?

Audience: 00:22:48 Procrastinate in difficult ones.

Geoff Watts: 00:22:51 Yeah. I know something’s coming on, but I don’t want it, that’s conflict. Something might go wrong with that, someone might not like the outcome, so let’s just put it to one side. It could be a conversation, it could be a decision, it could be anything. People-pleasing is a really interesting one and get into the heart of this. It’s a good thing. Okay, it is a good thing to want people to like you, all right, to do good things for others. This is a good thing and the world would be a terrible place if there were no people pleasers. Equally it can go too far and for a lot of people, it does, and we don’t realize it. I like the quote on the wall though.

Geoff Watts: 00:23:32 It says the question isn’t who’s going to let me, it’s who’s going to stop me, and well one of the things with these 12 traits things is actually a lot of the people that are stopping you are you, all right because you’re unaware of the things that you’re doing that are actually hindering your performance. People pleasing is something that can easily get out of hand and so it’s all over here. There’s a problem in the room, someone’s got a challenge, someone’s struggling, you have this urge to step in and rescue. I don’t like seeing people struggle, I want to offer help, I’m going to come in, I’m going to save this issue, not because I want to be seen as the knight and shining armor, but generally I just want this done, I don’t like people who were unhappy and said we will overcome it, we will step in and solve problems that aren’t really ours to solve.

Geoff Watts: 00:24:20 A lot of people say I’m uncomfortable conflict. Is that a phrase that you’ve heard yourself say I don’t like conflict, don’t like tension or I don’t like arguments? There’s usually a high people-pleasing tendency to that. Again, good thing no one really wants to have an argument for the sake of it. Just if you find yourself enjoying conflict, you probably want to have a look at the mirror as well. All right. Deliberately avoiding it, I was coaching somebody a while ago who said I’m starting my role as a scrum master and I know one of the things I need to focus on is keeping the team happy, all right, make sure they’re not arguing.

Geoff Watts: 00:24:59 You can see the logic in that because a happy team is a productive team, but all good teams in the history of sports team, software teams, projects teams. They all have the ability to have an argument. All right. It’s a deliberate choice of words that they have an ability to have an argument. They can have an argument constructively. They can see different sides of an argument. They can make very passionate cases. They can argue as if they’re right but also listen as if they’re wrong, and so actually as a scrum master, we want to encourage that. As an agile coach, we want to encourage that. You can’t effectively self manage if you’re ignoring a lot of the options that are available to you purely to avoid an uncomfortable discussion.

Geoff Watts: 00:25:38 Your uncomfortable conflicts if we refer people-pleasing constantly apologizing, oh sorry about that sorry about, sorry about that, sorry you feel this way, I’m sorry I’m late, apologies for the delayed email response, these kinds of things. We talked about knee-jerk responses of yes sure, so we end that we’re overloading, everyone else comes first, our needs comes last, and then constantly looking for reassurance. Is everything all right, did I I upset you, you don’t need to apologize today, that kind of thing. These are perhaps some of the downsides of it, but there are advantages as well. Okay, so thinking as an agile coach … Just skip to the third question.

Geoff Watts: 00:26:15 Thinking in as an agile coach, why might it be important to us to be aware of people-pleasing tendencies within our team?

Audience: 00:26:23 Because coaching agile is a structure that you need to get across and if the team is wanting to do better with different things, you can’t let them get away with that.

Geoff Watts: 00:26:34 Right, and that’s a double-edged comment which I’m going to address one edge of it and I’m going to come back to the other edge of it slightly later. This idea of well there is a certain amount of freedom within an agile approach, but not complete freedom. There are times when actually a self managing team does need to apply and fit within and adhere to constraints and rules, whether that be something as simplistic as yeah we’re only going to have 1 minutes in our daily scrum. That’s a rule, it’s a constraint of an agile process. If the team have decided to adopt that, then that’s something they need to do and someone needs to be able to say well stop, just we’re breaking our rules here.

Geoff Watts: 00:27:19 All right. There may be times when we need to have that discussion within an agile team, yes. Any other situations we need to be aware of that?

Audience: 00:27:26 Be really bad if you’re a product owner that’s saying yes to everything.

Geoff Watts: 00:27:29 Yeah. All right. A product owner has to be able to say no, right? Otherwise, how do they prioritize, how do we ever make any decisions or any progress, how does the project ever going to end? If they’re constantly saying yes, that’s going to be a problem for us, for them, for the organization. Any other examples where we need to be aware of this? Yeah.

Audience: 00:27:47 You may have people pleasers in your team that take on to and get overloaded and burnt out.

Geoff Watts: 00:27:53 Yup. Over commitment, that could be over optimism, it could be just we can’t say no to things, and so we burn ourselves out or perhaps compromise quality in the product to meet those unrealistic commitments that we’ve made. If we are people pleaser equally and we don’t want conflict and we don’t want to be seen to be letting people down, so we won’t want to share that message until really, really late until we absolutely have probably later than we have to. All right. That idea of transparency is probably going to go at the window. The idea of sharing the hard realities that we talked about earlier on is going to be quite difficult, so we’re going to be looking for uncertainty, we’re going to be looking for anxiety, we’re going to be looking for tension.

Geoff Watts: 00:28:31 We might even be able to hold the mirror up and go seriously. I mean I had one team, this was a long time we get, one team where the product owner turned up to the sprint review and said seriously guys, you need to be more realistic, you need to tell me the truth, every sprint and he had the data. Okay, so you got up on the whiteboard and you wrote down this is the amount of story points that you said you were going to do in sprint one, this is what you did, this is what you said you’re going to do in sprint two, this is what you did in sprint three, what you did. Every single one of them was about 20% more than what they actually managed to achieve and so it’s not that you’re a bad team.

Geoff Watts: 00:29:03 All right. If you’ve said you’d have done this stuff, I’d have been all right with it. What you’ve done is said you could do this and I’ve had to go to my stakeholders and effectively over-promised, and then you’ve let them down, tell me what you can do. That was a really hard thing for them to do. They genuinely wanted to please. They wanted to help the product owner in their role, but they weren’t helping. What about an agile coach who has a strong people-pleasing tendency, what might they need to be aware of?

Audience: 00:29:33 We’re not going to tell them the truth and where they need to improve because you’d be scared of hurting their feelings and the whole reason you’re there is to help them improve and see things that they need to work on and you go saying, “Oh, that is all right. Don’t worry, I’d be fine.”

Geoff Watts: 00:29:33 My head.

Audience: 00:29:33 Well, everybody has to go on …

Geoff Watts: 00:29:33 I was a bit worried about my head.

Audience: 00:29:57 That kind of thing. You’re not addressing the actual problem, you’re just actually hurting them more by not telling them what they need to know.

Geoff Watts: 00:30:04 Yeah, so avoiding the feedback, the real feedback, and also that that’s magnified because there’s that one specific instance of the feedback not being true, but also then everybody’s looking at that and they can stay no. Okay, people know when you’re dressing out, when you’re buttering things, when you’re sugarcoating things, when you’re avoiding the real issue just to stay nice, stay on good terms, and that’s then copied. Consciously, subconsciously that’s kind of expected behavior that’s rolled out within the team. It’s magnified and everything that an agile coach does, everything that an agile coach doesn’t do has a massive impact on self-organizing behavior than the team.

Geoff Watts: 00:30:42 They have to run the risk of being slightly unpopular at times, but how can we get to a point where we’re comfortable doing that is the challenge that agile coaches face. Now this is where I said that the double-edged sword to the initial comment of there maybe rules that we need to follow as a team. They might not be rules that are comfortable to address. Agile coaching is different to professional coaching in a number of ways that I’m going to come back to, but one of them could be around that area. Okay. In terms of the ownership of the rules, where does that lie? Okay, so agile teams have perhaps less ownership of the rules compared to the agile coach in contrast to a professional coaching engagement.

Geoff Watts: 00:31:28 All right. Just hold on to that thought for a minute, I’ll come back to that explicitly towards the end. What can we do? Okay. Well, we need to get comfortable with saying no. Product owners need to be comfortable saying no, developers need to be comfortable saying no, agile coaches need to be comfortable saying no. Can we drop our daily scrum? Do we really have to have it every day? No, we can’t drop it. No, no, no, we need to do this every day, and this is why. There’s two things we can do. Natural knee-jerk reaction was one of the common symptoms of people pleasers. Without thinking, without giving themselves time, their default response is yeah all right then, sure.

Geoff Watts: 00:32:08 Store, buy yourself some time, just get into the habit of let me get back to you on that, so I can think things through and come to a decision from my head rather than my gut instinct. Store, adjust the boundaries to just gradual exposure, so taking a little bit more ownership, setting your boundaries just a little bit further than they were before. The idea of if you’ve got a phobia of spiders, maybe you can be in a room when that’s in a cage and it’s locked in the other end of the room. That kind of gradual explosion, slowly we can move it forward, slowly we can unlock the cage, maybe we can get to a point where we’re touching it equally with saying no.

Geoff Watts: 00:32:44 Now can we adjust our boundaries gradually rather than going cold turkey and turning into an ass? I’ll be careful my language, I’m being filmed. Let people know that they are allowed to disagree and actually I see a lot of teams will actually use the idea … I’m a big fan of debating. I’ve just got my son to go to debating club. I think every child should go to debating club. I think every human being should do some kind of debating practice. If you’re going to be part of a collaborative team, we need to be able to disagree constructively, we need to be able to know that disagreement is okay as long as it’s respectful, and being able to make an argument for something you don’t believe in I think is quite important.

Geoff Watts: 00:33:25 All right. We need to have that dissent within our team. I’ve seen a lot of teams that will have debate retrospective, debate style retrospectives just allow us to consider different alternatives with passion. All right. Respectful passion that we know we’re arguing something that we don’t believe in, but we can do that, it’s okay, the world’s not going to fall apart. All right. We’re not going to end up with a fistfight, we can do that. Network audit is a lot more specific to individual coaching, but actually it’s quite useful to be aware of with our agile teams as well. A network audit would be actually looking at the people that you surround yourselves with.

Geoff Watts: 00:34:02 All right. How many of those people actually take advantage of your people-pleaser nature and whether you need to reduce that? How many people are actually helpful to you? How many people support you? How many people encourage you to set and keep your own limits? How many people are looking out for you? What kind of composition do we have within our agile team of people pleasers and people who shirk these kinds of things and being aware of that? What about the people who were surrounding the agile team? . All right. Are people taking advantage of the people pleasing nature of the team? The average developer thinks they’re above average, right? We all know this. The average agile team over-commits.

Geoff Watts: 00:34:38 All right. Our estimates are terrible. Some people out there are aware of that and some product owners are aware of the consequences on them. It looks good in the short term, but they know it’s going to hit them in the medium term. Some aren’t aware of that and will take advantage of that. Are we aware of the access that these people have to the team. The word at the the bottom, they offer no excuses I found quite interesting. This is very difficult for people pleasers to do because when I say, ” I’m going out on Friday, can you look after the kids?” They’ll say, “No, I can’t because I’ve got to take the dog for a walk.” It’s a grasping at straws but once they feel they have to have some reason to say no.

Geoff Watts: 00:35:17 By offering that as a reason, it’s saying to me okay, so if I can solve your dog walking problem, you can look after my kids. All right. That’s opened the door for people to push, and what we found is that you can offer three and says okay yeah, maybe I’ve got the dog walking but I got another problem, all right, I’ve got do this. I may well try and say no three times, but after that, I’ve lost my energy, it feels rude. Okay. It’s just easier to say yes. Don’t offer excuses. It’s really difficult, but the more excuses you offer, the more likely you are to eventually say yes. Get teams into habit, just you have the right to say no. Our third trait … How are we on time?

Geoff Watts: 00:36:09 Okay. Third trait that I want to talk about, perfectionism. Again, the third one that most people will be aware of, they either put their hand up as a yeah, I’m a bit of a perfectionist. Some people oh yeah, I’m a perfectionist and I’m proud of that, I wear the perfectionist badge or some people if you’re not, then you’ll certainly know somebody that is, you’ll be aware of this kind of stuff. Now perfectionism is an interesting one especially in the software development industry, especially over talking about agile. All right. Everybody’s got a favorite principle of the agile manifesto. I’m not going to ask you what yours is, but the idea of it not having a perfect design, having good design, continuous attention to technical accidents and good design enhances agility.

Geoff Watts: 00:36:55 That’s my favorite because it talks specifically about good design rather than perfect design, but for a lot of people, that’s really difficult. All right. I was actually reading an article by the CTO of the Daily Mail. It was a LinkedIn blog post saying that agile doesn’t work, it never has. All right. It’s quite a bold statement. All right. I’m on camera and you can draw your own conclusions, but the culture of an organization is going to have a massive impact on whether agile works and whether you actually trust people to do a good job, whether you actually believe in the human nature. Positive aspect of human nature will have a massive impact on whether self-organization and self-management takes hold, but this idea of unrelenting standards is a big driver behind perfectionism.

Geoff Watts: 00:37:45 It’s a right angle or it’s a wrong angle. All right. These kinds of things is got to be perfect. You get into the OCD type sort of things, which there are people out there that says a high correlation of OCD and software developers. I haven’t studied that myself, but this idea of having perfect code and things like that, some perfect designs and I’ve definitely spoken with UX designers who say I don’t want the developers getting their dirty hands on my designs until they’re perfect. I’ve had someone say that to me, so I know there is a certain element of this in the software and the agile space. This idea that we’re never satisfied unless it’s absolutely perfect and we gold plate things and we keep going and keep pushing is a big concern of the product owners side of organizations.

Geoff Watts: 00:38:26 You can’t trust development teams because either their shoddy or they go play, which is ironic. Really I mean it’s two extremes of the same coin they’re worried about and it’s very difficult for human beings to simplify, and that’s my second favorite principle of the agile manifesto, simplicity is essential. All right. The art of maximizing the amount of work not done. How can you maintain technical excellence while keeping things simple is a big concern for many people. Perfectionism is a big thing in the agile space in my opinion. Advantages though, advantages to perfectionism?

Audience: 00:39:04 Get perfect stuff.

Geoff Watts: 00:39:05 Do we? Because this is me …

Audience: 00:39:10 It’s like attention to detail, isn’t it and things like …

Geoff Watts: 00:39:12 Attention to detail is a good thing, right?

Audience: 00:39:14 Very conscientious.

Geoff Watts: 00:39:15 This is one of the Daily Mail CEO’s concerns is that you just crap shoddy code that people don’t pay attention to. You are constantly iterating on something that’s never finished. All right. You never to think things through. It’s all by the seat of your pants this idea of that cowboy coding. I haven’t heard that argument that loudly for quite a while, but there we go. This idea of well you should get something really, really good. Okay. If you’re really conscientious, okay your standards are really, really high and if your standards are really high actually encourages other people to step up as well. They say well okay well yeah fair enough, okay you’re this conscientious, I’m not going to be sloppy because I don’t want to be seen as the shoddy one.

Geoff Watts: 00:39:56 All right. Actually there’s justification for me putting in that extra effort because these are the standards that we’ve set. There’s definitely advantages there in terms of quality. What are the other advantages might there be to perfectionism?

Audience: 00:40:13 I supposed in line.

Geoff Watts: 00:40:15 Yeah, the reliability the maintainability and that conscientious nature in terms of maintenance as well, right? Okay, maybe we can accept the fact that stuff happens, probably someone else’s fault, not ours. If it does happen, then I don’t want that to be against me or what I’ve built so I will work hard and eradicate that. We don’t tolerate anything that’s left suite. The conscientiousness, it’s an interesting one in terms of standards because standards can work the other way in terms of disadvantages. If you know that the quality bar is up here and you don’t believe you can meet it, a lot of people will rather than try and not meet that bar, they’ll check out. They will procrastinate and they would rather say I ran out of time then I couldn’t meet the quality bar, find all sorts of reasons to procrastinate because they don’t think they can make it. All right. If you couple that with the idea of imposter syndrome where we don’t think we’re good enough. All right. You’ve got a lot of demotivation, you’re like oh I can never meet that so what’s the point, and even if I do meet it, all they do is raise the bar because if it was easy enough for you to meet, it obviously wasn’t perfect enough. All right. Perfectionists do this to themselves once they meet the bar. Well, it couldn’t have been high enough because I met it. They’re actually writing the rules of the game against themselves.

Audience: 00:41:34 With that, both them seem to feed imposter syndrome, so the people are trying to be perfectionist and reach perfection and then going to potentially feel imposter syndrome with themselves with the people that don’t want to go on for long.

Geoff Watts: 00:41:50 Yeah. Yeah. That’s possible one of the reasons why we’re looking at to 70% to 75% of people that will look at that at some point. If they either check out of the task or in many cases sadly they’ll check out of the team or the organization, burnout, fear of failure associate with these levels. There’s loads and loads of stuff on perfectionism out there, not just in the agile space, but really important to know because what are we aiming for is the question really. Perfection is a good thing to aim for if we can cope with the consequences and in our case, the inevitable consequences of not making it. When I say in our cases, in the agile space, we’re being explicit in saying perfect is not possible because things are changing so frequently and there are so many unknowns.

Geoff Watts: 00:42:42 We’re constantly striving for excellent, not perfect and there’s a difference. All right. This term adaptive perfectionism as opposed to maladaptive perfectionism. Adaptive perfectionism is we’re aiming for excellence and we can cope with the fact that it will never be perfect and we’re continuously looking to maintain excellence, which again feeds back to why that agile principle is my favorite because it talks about excellence and good design rather than perfection. All right. In some situations, perfection is achievable. It is something we should be aiming for.

Geoff Watts: 00:43:22 All right. I would suggest in an agile space where we are working with incomplete information, frequently changing requirements, lots of unknowns, perfection is not achievable and it’s destructive. Agile coaches need to be aware of that. We want that conscientiousness, but we don’t want the destructive side of things. Does this make sense? Okay, cool. Some of you may have seen this picture before. I’ve used it before in my talk. My son is now 10 and at some point, he will realize … He’s got YouTube channel and things, so now at some point he’ll Google Daddy and he will see daddy’s done a talk and he’s used his picture. If he can get to 35 minutes into my talk, we should probably wait so I’m safe, but he will eventually realize that I’m using this and he’ll hate me for it.

Geoff Watts: 00:44:14 This is a picture he did maybe when I think he was about three or four and he came rushing into the kitchen and said, “Daddy look what I’ve done, look what I’ve done.” I said, “That’s brilliant, that’s brilliant.” He said, “What is it?” There are many answers to this, right? I got lucky. All right. It’s a spaceship. I knew he’s into spaceships at the time so the good thing yeah, it’s a brilliant spaceship, I can tell it’s a fantastic spaceship, but other people, it’s not other people and I asked them what it is, they’ll say it’s a toothbrush or a jellyfish or something and equally it could be. All right. Now my question then is is this perfect?

Geoff Watts: 00:44:54 Well, obviously it’s not perfect because it’s not an exact blueprint for the design of interstellar space travel. It’s not perfect in that regard, but to the dad of a 4-year-old, it is. All right. To the 4-year-old themselves, it is, unless they’ve develop impostor syndrome. We look at this and say yeah, that’s great, that’s perfect, that’s absolutely perfect and the next question he asked me was, “Daddy will you come and draw with me?” I said, “I can’t draw.” . All right. Now because I know I can’t draw perfectly, I’m judging myself like I could probably draw it like that, but would I be happy with that, is that excellent, is that good enough? I’m terrible father, right?

Geoff Watts: 00:45:34 I’ve now planted in his seed if you can’t draw perfectly, you shouldn’t draw at all. All right. I’ve planted that seed in his head. Thankfully he ignores me as most people should, but it’s like the point that I want to make here is that failure and perfection is relative, it’s subjective, depending on the context. All right. If perfection is relative and is subjective then so is failure and this is about redefining failure. You’ll hear this phrase redefining failure a lot in your teams and your organizations. We need to look at the assumptions that we’re making. It’s often unconsciously about why perfection is important to us. What are we worried will happen if we are imperfect?

Geoff Watts: 00:46:12 Okay, are we going to get judged, are we going to lose a promotion, are people going to think badly of us, are we going to think badly? What assumptions are behind that drive for perfection and if we can explicitly state that, then we have a chance of challenging. That’s what a coach will hopefully do. They will help people see what the assumptions are behind their perfectionism, hopefully challenge them, challenge them to channel those drives towards excellence rather than perfectionism and insist on improvement and pursuing of excellence. This idea of changing what failure means to us will help us bring that perfectionism trait back into balance.

Geoff Watts: 00:46:45 That’s what I’m going with all this stuff really because perfectionism is a good thing, perfectionism is a bad thing, imposture syndrome is a good thing, imposture syndrome is a bad thing. All right. It’s about finding that middle ground, using the positive side of it, mitigating the negative side of things. All right. This bringing it together and that’s what for me coaching is all about. It’s not about agile is good or agile is bad or waterfall is good, waterfall is bad, perfection is good. It’s about finding out what’s right and helping others know when that’s not in balance.

Geoff Watts: 00:47:24 All right. The key to self management is self-awareness and self-regulation, so a coaches primary job in my personal opinion is to help the people they’re coaching, be aware of those traits and be aware that when they are out of balance, how that is helping or harming them and give them some tools and techniques to bring them back into balance.

Geoff Watts: 00:47:44 Bear in mind, this is to the leadership coaching, personal coaching rather than agile coaching, but looking at well where does this start, where’s the first example of perfectionism that you can think of, what assumptions are you making about that, tell me about how that has played out throughout your life, are there times when you aren’t overly perfectionist, are there times when you are really, really perfectionist, what’s the difference what’s happening in those situations where you’re able to control it and where you are less able to control it, can you take elements of that and apply it to this situation, so thinking about the bigger picture there.

Geoff Watts: 00:48:18 What alternatives do we have available to us, what options do we have when thinking about bringing perfectionism into balance, we can we think about this in a different way, what could we try perhaps, and then putting some new behaviors into practice, into place, trying something new, making some commitment to trying something new and then looking for some evidence that that new behavior is adding some value to them. All right. That’s a model for helping people bring things back into balance and of course there are specific tools and techniques that we can use, but that overall model of balance is something that I try and encourage people to at least think about.

Geoff Watts: 00:48:51 All right. What really is an agile coach? I mean I was the title of the talk. The scrum guide, there is no agile coach. All right. If you’re doing scrum, there’s no agile coach, yet most of the organizations that I work in and you got to work in, there will be the role of an agile coach, right? You come across this, you see job adverts for it, usually more highly paid than a scrum master or something like that. As far as scrum is concerned, there isn’t one, just three roles. That’s an interesting starting point. Other agile methods may have the term agile coach, others don’t. I’m a member of the ICF, the International Coach Federation, so as a member of that before as a member of the Scrum Alliance, that has nothing to do with agile although I’m trying to bridge the two worlds.

Geoff Watts: 00:49:38 The ICF, the International Coach Federation defines coaching in a number of different ways, but I’m just pulling out a few definitions that I think are of interest when looking at this from an agile perspective. The ICF says individuals or teams, we believe they are capable of generating their own solutions. Okay, if we’re coaching them, we believe they are capable of generating their own solutions and the coach will supply supportive discovery based approaches and frameworks. They just give them something where they can use to identify their own solution, not about finding my solution or the right solution, but everyone that we’re coaching has that capacity. That is an underpinning belief of coaching from the ICF.

Geoff Watts: 00:50:15 Partnering with clients in a thought-provoking and creative process that inspires, inspires them to maximize their personal and professional potential. It’s not about saying this is what you need to do, it’s not about saying this is what the process says has to happen or this is what is expected of you. All right. Thought-provoking and creative process that inspires, so a coach should inspire people to think new things, to be creative about how they’re doing thing. The coaching process does not include advising. As far as the ICF is concerned, a coach should not advise, they should not counsel. All right. Instead, they’re looking at focusing those people, individuals or groups on setting and reaching their own objectives. Okay, I still have come back to that double-edged sword of there may be rules in your agile process that an agile coach is responsible for enforcing. That is at odds with the ICF definition of coaching. That’s a challenge. All right. What else have we got? Unlike athletic development, so I said I’m a sports coach as well, there are some differences there. Professional coaching does not focus on behaviors that are being executed poorly, does not focus on behaviors that are being executed poorly according to the ICF or incorrectly. Instead, the focus is on identifying opportunities for development based on individual strengths and capabilities. Focus on what you’re doing well and think well could I do more of that, could I apply some of that somewhere else.

Geoff Watts: 00:51:41 All right. In essence if we were being rudely honest, your kid comes home with a report card of A, As, a B and an F, we don’t care about the F. Okay, we just focus on the strengths and then maybe the F would increase by applying those strengths to other situations. All right. That’s an interesting one. How many retrospective have you been to where we focused on where did we screw up this spring? Not explicitly, I don’t expect you to turn and say that’s the question we’re going to answer, but we focus on the problems and where we screwed up more than we focus on our successes and our strengths in general, don’t we? Now I’m not here to say that this is something that we should be following to the letter because there is a lot of benefit I believe personally.

Geoff Watts: 00:52:19 Even though I’m an ICF accredited coach, I still think there’s a lot of benefit in looking at and maybe addressing some of our weaknesses. Okay. If we don’t address the fact that we write terrible code, are we ever going to be a successful software team? No, so we probably need to address that. The question then is, is that the place of the coach though ICF would say no. ICF would say the coach provides the framework for the team to identify that and trust that they will find a solution to addressing, but most organizations say or the agile coach is responsible for them and that puts the agile coach into potential conflict of interest I would say. The scrum guide versus the ICF.

Geoff Watts: 00:53:02 The scrum guide says that the scrum master … Because they don’t have an agile coach. Okay, they expect the scrum master to be a coach. The scrum master is responsible for ensuring that the scrum team adheres to scrum theory practice and rules. All right. They are responsible for planning scrum implementations within the organization, causing change, not facilitating change, causing change that increases the productivity of the scrum team against the ones that we’ve already talked about, generating their own solutions does not include advising, setting and reaching there.

Geoff Watts: 00:53:34 The scrum guide talks about the scrum master being a coach and I believe that the scrum master is a coach, but I think there’s a big difference between how scrum defines a coach, how agile coaches are defined, and how professional coaches are defined. I try and operate those two worlds. I believe that a lot of people who are in that role, some of them aren’t aware of that dichotomy, they aren’t aware of that conflict. Some of them are aware of it, just don’t know how to square the circle. They actually believe in this stuff but are being asked to do this stuff.

Geoff Watts: 00:54:09 In its worst examples organizations, they call their people coaches, but actually what they expect, what they’ve hired for our managers or consultants, and what that leads to is do agile this way, self-organized like this which is contradictory but it’s not explicitly contradictory. It’s something that everyone’s wet that doesn’t feel right, but what do we do about it? Now I don’t necessarily have an answer here, but what I have been trying to do the last few years is build awareness. Firstly, there is a potential conflict there and secondly, to provide some tools and techniques from the world of professional coaching that has been dealing with this for years into the agile space.

Geoff Watts: 00:54:59 How can we build up those self-coaching techniques within the team so they can coach each other that they’re aware of the potential conflicts within that role because who we are is how we coach and who we are is defined by our role and our responsibilities as well. All right. Most coaches, that’s probably very harsh, but it’s quite late and you’re going to go to the pub soon anyway, so you’ll forget this bit. Most coaches are unaware of the impact they have on the team in what they do and what they say and what they don’t say, how they act. Esther Derby explained this a lot better than I ever did, so I’ll give her credit for this.

Geoff Watts: 00:55:38 She was telling me how dogs are quite useful at this because you can say to a dog sitting there, we can beat this out right, you’re an ugly little shit on you, you’re an ugly little shit in a nice voice and the dog will sit there biting its tail because it’s listening to the music, it’s not listening to the words. People in organization, I’m not saying that people in organizations are animals or dogs or anything, but they listen to the music, when there is a conflict they listen to the music. Okay. If there is a mixed message, they think well what’s behind the words and well we may be saying we’re agile and may be say we’re agile coaches, but if the music behind those words is saying something different, then we lose faith in the whole process.

Geoff Watts: 00:56:24 What can you do? Well, my hope is that I’m looking at professional agile coaching, the facilitators of team self-actualization, that’s what I believe an agile coach should be. We have this dichotomy of the ownership of the agenda. Okay, that’s the big one, but for me, that’s all about what does this team want, okay. Does the team want to be an agile team, does the team want to be a self managing team, if they do, then they buy into that process and they buy into the role of this person being the facilitator of their self-actualization. If they don’t buy into wanting to be a self-organizing team, for whatever reason then that person has got some work on the rest of the organizational culture in the environment they’re operating in first before the team can buy into that.

Geoff Watts: 00:57:06 They’re respectful of where the team is. Okay, so they don’t expect to be able to self manage completely from the start, but equally they’re respectful of where the team can be. They genuinely believe in the potential of the team to self-manage. They believe that is possible almost inevitable, but they don’t expect it overnight. They walk the talk, so they’re aware mixed messages, they accept their impact on the team, they own that impact on the team, they’re rigorous in their self-reflection, so constantly … This is for me probably the biggest thing that I was hoping people would take from the coach’s case, but they haven’t, but that’s life is the idea of in-professional coaching as with all other sort of helping professions like therapy and things like that.

Geoff Watts: 00:57:48 There’s an element of supervision, so the coaches have coaches, they walk the talk. They’re expecting other people to reflect on their behavior, but those coaches are expected to do that themselves, and very few organizations have an agile coach support network or a scrum master support network or anything in there where people are actually expected to reflect themselves on how they’re working and the conflicts of interest they may have. That rigorous self-reflection should be part of what we’re doing and that discipline of supervision, that regularity as well is where I think we need to be going. Now I was challenged, I was sent a speaker pack. Now I was told the stated goal of Agile Yorkshire is to be champions of no-nonsense software delivery.

Geoff Watts: 00:58:24 I was pretty sure before I turned out that I was going to fail on that because I don’t talk about software delivery really. Okay, this is about coaching and I think the last time I was here I admitted that I do have a certificate somewhere that says I can program and visual basic, but you wouldn’t want me on your team. All right. I’m not really a software guy, so really just as the coaches casebook is nothing to do with agile, it’s nothing to do with software I would say but then I would say that. All right. It’s everything to do with agile and it’s everything to do with software delivery.

Geoff Watts: 00:58:56 I think if you’re expecting a team, a software development team to self manage, to self organize, to operate within an agile environment, to cope with the natural inevitable imperfection, to cope with the natural human anxieties around impostor syndrome, and people pleasing, they’re prevalent within human beings, then we need to know about this stuff and we need to have some tools that will help us manage that and also to coach others to manage that. Although okay, I haven’t taught you anything that will make you a better software developer, hopefully it’s a part of the conversation that needs to have. Our audience does like detailed engineer. I haven’t got any detail engineering for you. All right.

Geoff Watts: 00:59:34 I guess I failed on that one. Speaker should try to explain how their chosen topic improve software development outcomes. I hope that I have, but I don’t know. That’s what these feedback forms are for I suppose. My contact details are on the slide here. Yes, my contact details, so my email address, my Twitter ID. I’m more than happy for you to contact me through anything like that, LinkedIn, anything you want, send me messages. I’m more than happy to answer questions that you thought I didn’t want to ask this in front of everybody else or I wish I’d remember this as I was going at the door. I set no service level agreement about how quickly I respond, but I do guarantee to respond. I’m back in Leeds next month running a CSM cost bit of a pitch at the Marriott.

Geoff Watts: 01:00:17 I’m trying to bring more training to Leeds rather than force everybody out of London all the time, see how that goes. I made a stupid mistake of scribbling my name in the inside cover of a few copies of my book, which apparently reduces the value of them. I’m selling them at a reduced rate. I’ve only got everything as many as I could carry, so there’s only a few copies here. If you want to buy them, a reduced rate of 10 quid, they’ll be available at the back. Other than that, it was a genuine pleasure to talk with you rather than talk out at you and yeah, you’re free to go to the pub or finish up a booze here.

Lean Agile Principles Deconstructed

Lean / agile software development ideas are essentially modern management methods that take a sideways view at how things can be done. Mostly the ideas within the lean / agile body of knowledge are rooted in system theory and build on other work that has taken place in other sectors, particularly lean manufacturing. However lean manufacturing isn’t the same as lean software development because the type of work is different. While the underlying ideas are similar some of the tactics and emphasis has to be different.

Jon Terry presented an excellent talk on the lean / agile software development body of knowledge at our Agile Yorkshire event that can be an excellent foundation for further learning.

Agile Business Analysis Using the Three Amigos

Good outcomes when building software features is strongly connected to having the right insight and information at the right time to help form a consensus on what to actually build. The problem with traditional requirements documents is that they typically don’t achieve this because they are normally written by a single person with a single perspective and often a long time before the actually coding work starts when ideas may have been different.

The idea of the Three Amigos with the agile development world refers to the regular coming together of people from analysis, coding and testing to form a more rounded view of what work to do by using the multiple perspectives of the group.  Josh Lynas presented an excellent overview of the technique at a recent Agile Yorkshire event we hosted.