In the Pub after my Difficult Conversations Talk

I was talking to this guy in the pub after my talk on Thursday.

"I've been the MD of two or three technology companies and I thought I understood what software was all about. I thought I knew all about technology. Then, just recently I started writing some macros in Excel, and then I got into VBA - and I thought - how hard could this be? And then after a couple of weeks it was like wow! Some things you think are easy are really hard - they take you days and other things, once you've got the hang of it, they're really easy. But when I'm doing this stuff - you'd better not talk to me, I can't be answering my phone or reading email of any of that stuff, when I'm writing code I've got to CONCENTRATE.

"And then suddenly it struck me - all these things programmers had been saying to me all these years..."

For further information, contact Mark@agilelab.co.uk (07736 807 604)

Feeback from my Difficult Conversations in Software Development Talk

This is the feedback I got for the talk "Software without (so many tears): dealing with difficult conversations in software".

Clearly I need to be more specific about how the things I talk about apply to software, but otherwise, I'm very pleased.

"covered a lot of personal conversational issues not exclusively software related. "

"Was an interesting talk on soft skills that are actually important for people in the software industry, lots of good and humorous points made! Perhaps there could've been some more direct software examples, but that's a minor quibble at best :) "

"This was a good presentation, refreshing to hear something on the often overlooked human angle of engineering/development. As someone who has had 'difficult conversations' in the past I enjoyed listening to Mark's no nonsense approach to reaching agreement. "

"Really got me thinking about how I react to others when having difficult conversations and Mark explained a diverse subject well in the short period of time. He also gave good direction for other resources regarding this topic."


For further information, contact Mark@agilelab.co.uk (07736 807 604)

Experts Know what they're Capable of - Using Velocity and Yesterday's Weather

This is a reply that I gave to someone on the London Java Community mailing list who was asking about better ways to manage estimation of tasks and time. I thought it was worth reprinting it here.

Dear X,

One of the best ways of improving your abilities at estimating over the length of a Sprint is to use two concepts combined: velocity and yesterday's weather. These are actually some of the more tricky aspects of Agile to explain, but I'll have a go just now, really quickly.

Imagine that you're first sprint is a fortnight. And so, quite naturally you plan to do 10 days work in that week and sign up to do enough stories/tasks to fill those 10 days. At the end of the 10 days you count up how many stories that you have actually done. Surprise, surprise, some things took longer than you thought so you actually only managed to do the tasks that you estimated would take you 7 days.

Ok, important concept #1: Velocity - this figure, the number of days of estimated work that you actually delivered is called your velocity. You can think of it a bit like your power. You thought you could deliver 10 days work, but actually you can only deliver 7. Ouch that hurts doesn't it? But the pain is worth it because by understanding your velocity, you're on the way to being able to accurately estimate things in the future and actually deliver things when you say you're going to deliver them.

Ok, now important concept #2: Yesterday's Weather. For the next sprint of 10 days, you only sign up to stories/tasks that you estimate will take 7 days. Ouch - that hurts even more doesn't it? But what you're doing is using your experience of how good you are at estimating and feeding it back into the process. This of course doesn't meant that if you get through all those things by the end of Wednesday on the second week, you don't find some other stories to work on. What it does mean is that over the course of several iterations, you keep checking with yourself how good you are at estimating your own velocity.

This feature - knowing what you're capable of, being aware of what you can and can't do in a fixed period of time is a well-documented feature of experts and high-performing teams. This books is a fascinating account of how experts are different from beginners http://is.gd/pots


There are bunch of other psychological tricks that you can use to detach yourself from trying to get the number right for any particular job. One that I found very useful is to try to imagine what the absolute worst case scenario figure would be and what the minimum time would be and then take the geometric mean (http://en.wikipedia.org/wiki/Geometric_mean).

I got this idea from this brilliant book about estimation -
Guesstimation: http://tinyurl.com/cypdbg



There's a really good book that looks at all this velocity/yesterday's
weather stuff in close detail: Scrum and XP from the trenches. It
also deals with "focus factor" which is a big issues in actually
delivering on estimates.

http://tinyurl.com/c26p8p


You could also come on my next course:

http://www.nmk.co.uk/event/2009/3/12/reducing-risk-and-improving-results-agile

Regards,

Mark Stringer.

For further information, contact Mark@agilelab.co.uk (07736 807 604)

Four books about negotiations and difficult conversations

Getting to Yes: Negotiating Agreement Without Giving In



The grandfather of all negotiation books. And the best place to start reading about this subject. Introduces some of the most important ideas in the field, including the BATNA (Best Alternative to a Negotiated Agreement) and the idea that you should concentrate on interested and values rather than positions. 20 million copies sold and it's no suprise.

Difficult Conversations: How to Discuss What Matters Most



Very good at describing the whole story of difficult conversations, and why we have to include discussions of feelings and identity if we're going to have a chance of making any progress. Not so good at offering solutions on how to deal with the issues of feelings and identity. Infuriatingly, it doesn't have any kind of bibliography even though it's clear that a lot of the wisdom in it is drawn from other sources.

Beyond Reason: Using Emotions as You Negotiate



A really interesting book which is very good and outlining the different kinds of identity issues that might be at play in a negotiation. The trouble is, it doesn't really do what it says on the tin at all, it definitely doesn't show you how to use your emotions to your advantage in negotiation. Everything is very well referenced, so it's a good sign post to lots of other interesting reading about negotiation.

The Emotional Brain: The Mysterious Underpinnings of Emotional Life



A truly scary book. It shows you how little control the conscious part of your brain has over your emotions, especially the negative ones, fear and anger. The positive side of this is that it makes you realise very quickly that if you want to change your behaviour, a self-help book or a couple of days on a training course isn't going to be enough. You're going to have train yourself to behave differently, create a new "muscle memory" of the new way of behaving.


For further information, contact Mark@agilelab.co.uk (07736 807 604)

Talking about Difficult Conversations Tonight

I'm talking tonight about difficult conversations and software development.

The beta version of my presentation is here (pdf). I'm very interested to see what the response is from an audience of Java Developers.

For further information, contact Mark@agilelab.co.uk (07736 807 604) or Matt@agilelab.co.uk (07713 634 830)

Introduction to Agile Methods – One Day Course

Are you involved in the specification, purchase, project management or delivery of an IT or web-based project? If so, you need to know about Agile methods. Agile methods, are a group of new techniques which make it easier to deliver IT and web-based projects in environments of uncertainty and constant change. Did you ever try to plan a project but things didn't go quite as you expected?

Agile methods are designed to deal with that kind of experience. They emphasise the delivery of projects in short iterations: the end of each iteration, priorities can be re-ordered or new ones can be added making sure that you are always delivering to the client the things that they value most.

This introductory course will give you an immediate feel for the difference that working using Agile techniques can have for the IT projects that you work on. Attending this course will allow you to: Provide the most value in the work that you do for you client; plan your work in short iterations; deal with new and unexpected information and changes as a project progresses; improve your estimates of how long work will take; and deliver what you say you'll deliver, when you say you'll deliver it.

Suitable for people working as either a producer or project manger or software developer in any new media or software development environment. Also suitable for people involved in the specification and procurement of software. No programming skills required.

This entry as pdf

For further information, contact Mark@agilelab.co.uk (07736 807 604)

Agile for Programme and Project Managers

A crucial part of the Agile approach is to “Start from where you are”. This one-day course won’t advocate the complete overthrow of any project management approach. Rather, through some teaching and a lot of hands-on case studies and activities, it seeks to add Agile techniques to the project manager’s existing repertoire.

What is Agile?

We give a brief outline of the Agile Project Management approach and how it differs from other more conventional approaches. We explain why an agile approach is a much better fit for many new media and software development projects.

Estimation

What can estimation do to help you? What can’t it do? Why do people feel so bad when they get their estimates wrong? We delve a little bit into the psychology of estimation. Then we explain how the Agile concept of velocity can help you and your team to improve estimates and provide the psychological detachment from estimates that is essential for good negotiation.

Negotiation

One of the major benefits of an agile project management approach is that it offers repeated opportunities for re-negotiation throughout the course of a project. But you can only take advantage of these opportunities if have appropriate negotiation skills and are willing to have difficult. We take you through the principles of negotiation that you need to get best deal for you and your customer at every stage of a project.

Risk Management

How can Agile help to reduce risk for you and your customer? We explain the Agile concepts of prioritisation and velocity. We show how these concepts work to ensure that your team is always working on the thing that is of most value to your customer and is within realistic budgets and time scales.

Getting buy-in

How can you persuade your senior management, your customers and your team that Agile can help deliver projects more effectively? How can you still get some of the benefits of Agile approaches even if those you work for and those you work with still insist on more conventional approaches to project management? We discuss strategies for introducing effective Agile methods into real-world workplaces.

This entry as pdf

For further information, contact Mark@agilelab.co.uk (07736 807 604)

Technical Aspects of Agile – Two-day course

Aimed at developers and team leaders who are already familiar with Agile approaches, this course with three important technical aspects of Agile software development.

Pair Programming

To many people, especially in senior management, pair programming seems completely counter-intuitive. Surely, by getting two people to do the job of one person you're just halving your productivity? A substantial body of research shows quite the opposite - that pair programming doesn't reduce productivity, but maintains productivity whilst substantially reducing the number of serious defects that are found in the code.

This course covers the very good reasons for introducing pair programming and how to deal with some of the potential objections. It also deals with how to start pair programming - what are the do's and don'ts and provides course participants with some hands-on experience of programming with other people.

Test Driven Development

The practice of writing a failing automatic test for each piece of software functionality, together with a script that can run all of these tests has many beneficial effects on the process of software development. This course gives participants experience of writing tests and then coding against them using the well-known testing framework JUnit.

Re-factoring

As software development progresses on a project, code gets messy and changes in one place cause unexpected problems in others. Re-factoring accepts the reality that code gets messy over time and builds on the advantages of TDD (test-driven development) to allow principled clean up of code. Course participants will be given a chance to clean up the kind of horridly entangled bits of code they might experience and be shown the possible benefits of re-factoring for the ongoing support of the code base.

Attending this course will allow you to: transform the way you write software by getting hands-on experience of three important technical aspects of Agile – Pair Programming, Test Driven Development and Refactoring.

Suitable for: Software developers and leaders of software development teams. Working knowledge of the java programming language required.

Contact: Mark Stringer
Email: mark@agilelab.co.uk
Mobile: 07736 807 604

This entry as pdf

For further information, contact Mark@agilelab.co.uk (07736 807 604) or Matt@agilelab.co.uk (07713 634 830)

Agile Training

Agile Training Course in Central London
Thursday May 28th at the University of Westminster.

We're running our most successful and popular course - Introduction to Agile Methods - for a second time in conjunction with NMK at the University of Westminster.

For further information email mark@agilelab.co.uk (07736 807 604)

New Course - Build Interfaces that Users want to Use

Introduction to User Interface Design and Development

User interface design and development is perhaps the hardest aspect of web and software development to get right. What makes it particularly difficult is that there are no good ways of developing interface software that don't involve getting feedback from users.

The good news however is that there are a set of relatively quick and easy methods for involving users in the process of designing and developing user interfaces. These methods can dramatically improve the speed and quality of user interfaces that are developed.

The course provides course participants with the basic skills that they need to develop better user interfaces – interfaces that users will actually want to use. As well as introducing the most important concepts of UI design and development, the course gives participants direct experience and practice of using the methods discussed.

Low-tech prototyping of interfaces and wire-framing
The fastest way to develop effecting and compelling user interfaces is by starting out with paper and pencil. Wire-framing is a computer based technique that is almost as fast but gives a better feel of what a final interface might feel like.

Really, really fast user testing
User testing doesn’t have to be a long drawn-out process, it can be done very quickly and can massively improve the quality of the final interface design.

Including feedback from user testing into production code: the lifecyle of user interface design
It is very rare that the first attempt at coding an interface is the final one. But rearranging the software development process so that it can take account of the feedback about the interface from users can seem like a daunting task. However the changes do not have to be major to have major effects.

10 Do’s and don’t for user interface design
We go through the 10 most important heuristics - ″rules of thumb″ that should be applied when developing a user interface. Applying these rules can substantially improve the quality of user interfaces in a very short time.


Mark Stringer is a trainer, coach and consultant. He has worked as a software developer and project manager for IBM and Xerox and for a series of small internet start ups. He has also worked as a researcher and taught Human Computer Interaction and Interface Design at Cambridge and Sussex Universities.


Mail mark@agilelab.co.uk 07736 807 604

New Course - Difficult Conversations Made Easy

Talking Technical: Dealing with Difficult Conversations in Software and Web Development

Everyone in every walk of life has had experience of conversations that don't go the way they would like, or result in more anger, upset and frustration than they do in progress. These kinds of conversations seem particularly common when people talk about software or web development, especially when technical people and business people try to talk together about software of the web.

Research into the field of negotiation and difficult conversation by groups such as the Harvard Negotiation Project has revealed that difficult conversations can all be seen to be following the same fundamental pattern. Once the structure of difficult conversations is understood, it is much easier to learn strategies for approaching them that can massively improve the effectiveness and success of communication. At the same time, the chance of upset, anger and other negative and time-wasting responses are reduced.

Identity: It's always about you. Issues surrounding our identity are very often the drivers behind the most emotional difficult conversations. By understanding what identity issues are commonly behind difficult conversations,

What happened: What happened? Whose fault is it? What should happen next? This conversation is very often the aspect of a difficult conversation which is most obvious. We investigate the ways in which the ″What happened″ conversation can conceal the real causes of a difficult conversation and investigate the use of the ″And stance″ - a method for understanding the contribution that all parties have made to a problem without the need to apportion blame.

Feelings: Though many people think that there should be no place for feelings in the workplace. The uncomfortable truth is that ″If you don't have your feelings, they'll have you.″ Many, many difficult conversations which claim to be disputes over ″What Happened?″ and involve blame, finger pointing and accusations of bad intentions are in fact conversations about feelings. Unless these feelings are addressed, the problem can't be solved.

This one-day course covers the basic structure of difficult conversations and then covers a general approach to dealing with difficult conversations that can be applied in a wide variety of different situations. Throughout the day, participants are asked to take part in a series of exercises taken from real-life experience of the tutor of over fifteen years of software development. These exercises give participants the opportunity to develop skills in dealing with difficult conversations in a safe, supportive environment away from the workplace.

Mark Stringer is a trainer, coach and consultant. He has worked as a software developer and project manager for IBM and Xerox and for a series of small internet startups. He has also worked as a researcher and tutor at Cambridge and Sussex Universities.


For further information, contact Mark@agilelab.co.uk (07736 807 604)

What do you do all day? When you get right down to it...

I read, I write and I talk to people. But the talking to people is the most important bit.

When I was working as a researcher, I spent some time visiting people in their homes and interviewing them about various things. I was always so surprised at how open and friendly people were once they'd let you into their home. Just spending a few minutes at the beginning of the conversation doing some "active listening", nodding your head, not interrupting, asking questions that show you're paying attention to what they're saying and then, it's amazing. They relax, they open up, they tell you all sorts of things. They tell you things that you couldn't imagine they would tell to a perfect stranger.

In a lot of my work as a trainer and a consultant, things don't go quite so smoothly. I've become fascinated with the whole business of conversations and how they can go wrong. So many of the people who come to me asking for help with training, or consultancy are really just trying to avoid difficult conversations. They don't want to have the conversations that they need to have with their bosses, with their clients, with their colleagues. And it's hardly surprising that they don't want to have those conversations because they've been burned in the past. Those kinds of conversations have gone very badly for them in the past and what kind of fool puts his or her hand in the fire for a second time?

What I'm trying to do with the new course that I'm putting together is to give people the skills they need to have difficult conversations so that they can broach awkward and difficult subjects with confidence. And a lot of the answers are to do with listening and understanding the others point of view.

Innovation and the Credit Crunch: tell me a new, new story

This post is a response to a call for writing for this discussion.

I recently read London Lore: The Legends and Traditions of the World's Most Vibrant City by Steve Roud. One thing I learned from this book is the power of certain types of story to dominate over troublesome facts and details. For example, any tract of land in London that appears disused was once a plague pit: "The plague pit idea, for example is particularly common among legend makers...for many years any unused piece of land seems to have attracted the story to explain its condition, and in the last fifteen years or so there has been a veritable explosion of these stories."

Several other stories also recur: that buildings are haunted, that ugly buildings were built incorrectly because the architect got the plans upside down or that buildings hide secret tunnels used by "monks, nuns, smugglers... assorted kings and queens with motives criminal, religious, amorous, or if possible, all three."

In form and in content, the stories that people tell very often have much more to do with stories that other people tell and the stories that people want to hear than they have with the actual facts. Even though the world is a very complicated place with new things happening all the time that we need new concepts to understand, there is a tendency to explain it to ourselves in terms of the same few old old stories.

This was never more clear than in the way that the credit crunch has been reported, even in the supposedly "serious press". Runs on banks, announcements of job losses, and scape-goating of "greedy" bankers and short-sellers: these few stories seemed to account for almost all stories about the credit crunch. There were far fewer stories about the precise nature of collateralized debt obligations and how similar financial derivatives might be regulated in the future.

I think the stories that we tell ourselves about innovation are a similarly impoverished set. Internet success stories are perpetrated by geek geniuses in their bedrooms. The story of Google is of two really, really clever guys, not the story of Stanford University's enlightened attitude to intellectual property. The story put out about Facebook is that it is another "bunch of college kids in a dorm" success story, not the story of part-ownership by a defence research company part-owned by the CIA. But this in itself shows how hard it is to avoid one old, old story, without slipping into another (in this case a conspiracy theory).

As with the credit crunch, there is a real danger that clinging to old old stories can prevent us from making any real sense of new data that we need new models and new stories to understand. There's no way of getting away from what Steve Roud in London Lore calls "The astonishing power of narrative in our everyday lives." But perhaps by collecting stories which don't fit comfortably inside the same three or four old old formats and paying less attention to those that do, we can get a better understanding of what's happening.

Here are few just for starters:

• Ebay was started by a French-Iranian geek in his bedroom but almost as soon as the company started to make money he hired serious business people with MBAs into all the company's senior positions.(see The Perfect Store: Inside Ebay by Adam Cohen)


• Adobe started off as a hardware company and went through 5 years and at least as many business models before it started to make any serious money. Postscript started off as a way of describing the movement of ships in New York harbour. (See Accidental Empires: How the Boys of Silicon Valley Make Their Millions, Battle Foreign Competition and Still Can't Get a Date by Robert X. Cringely)


• Edison may have had some inspiration, and perspiration but a some of his success was down to theft from inventors like Nikola Tesla. (See http://en.wikipedia.org/wiki/Nikola_Tesla and The 48 Laws Of Power by Robert Greene)

For further information, contact Mark@agilelab.co.uk (07736 807 604) or Matt@agilelab.co.uk (07713 634 830)