]]>http://theagilecoach.co.nz/innovate-or-die-trying/feed/0Five ways I’ve fucked up as a coachhttp://theagilecoach.co.nz/five-ways-ive-fucked-up-as-a-coach/
http://theagilecoach.co.nz/five-ways-ive-fucked-up-as-a-coach/#commentsSat, 06 Aug 2016 02:06:04 +0000http://theagilecoach.co.nz/?p=490Lets face it, whatever your profession, you don’t always get things right. What’s probably more important than the fuck up itself, is how quickly you learn…

]]>Lets face it, whatever your profession, you don’t always get things right. What’s probably more important than the fuck up itself, is how quickly you learn and recover from it.

Here are some of the things that I haven’t got right over the last few years. If you feel like sharing some of yours, please use the comments to do so.

1. Allowing bad behaviour in a team to go on for too long

The storming stage of the team can see conflict amongst team members as boundaries are tested. This is all part of a team’s formation process. In most cases the team will gel and they’ll move through it. Unfortunately, sometimes a team gets stuck. If this happens for too long the conflict will cause a toxic atmosphere and people will leave. The only avenues at that point are somewhat radical and time consuming for all involved. In retrospect, you’ll wish you had dealt with the behaviour much sooner.

Lesson learned: Trust and respect are the two key building blocks for an effective team. Regardless of the stage of team formation, nurture these two as fundamentals. Without these the team will implode.

Tips: Set clear boundaries for acceptable behaviour. Then make it clear to team members if they break those boundaries, what you expect them to do to reign it in or change things. Give them a timeline by which you expect to see a demonstrable difference in their behaviour. If after this period there is still an impact on the team, make the tough calls, you’re a leader. Whatever you do, don’t allow it to drag on and watch good people leave.

2. Allowing emotions to lead you

It’s hard not to get emotionally engaged if something gets in the way of a good outcome for a team, the company, the customer, or all three. The emotional response can be described as gut instinct. It can be quite raw. What’s certain, is it doesn’t always get the outcome you’re seeking. Emotional responses can make you come across as needy or may be easily dismissed by colleagues as irrational.

Lesson learned: No matter how good your intention is, if it’s coming from an emotional place, it’s very hard to successfully negotiate a good outcome.

Tips: If you feel yourself being tipped into an emotional state, try to understand the other perspective and look for the valid request in what is being asked for. People don’t tend to say or do things to be deliberately obtuse, there is usually a legitimate reason.

3. Didn’t say no enough

When you first join an organisation, you often want as much information about it as possible. You tend to get invited to a lot of meetings and included in a lot of emails. Sooner or later, the sum weight of information flowing your way will get out of control. This can make you feel like you’re always in firefighting mode, moving from one fire to the next. This is exacerbated when substantial organisational change is underway – uncertainty can trigger a lot of meetings. As a change agent and a better than average facilitator, people will call on your skill set. You’ll easily get pulled into meetings, some of which have little relevance to your overall strategy. What’s worse, you may be seen as the meeting administrator and you’ll be expected to write and distribute minutes.

Lessons learned: Too much information can be as ineffective as too little and soon the signal is lost in all the noise. If you’re in meetings, you’re not being productive. If you don’t have time between meetings, you can’t actually put any of your devised strategies into effect. Thus the circle of meetings continues.

Tips: Prioritise your time. Block out parts of your day in your calendar. If a meeting invite doesn’t have an agenda, email the meeting caller and ask them for one before you accept.

4. Spent too much time evangelising

When you first pick up some new theory that generates an a-ha moment, just eulogising about it to others doesn’t mean it will generate a-ha moments in them. Also, it’s just a theory.

Lessons learned: Avoid theorising, it only sparks debate. Unless you have a team of early adopters, the late majority and laggards will block any suggested change. It also makes you sound like a preacher, and if people aren’t ready to hear your message you’ll only push them away. The reality is, if people don’t understand the message, or you haven’t considered how it might work from their perspective, you’re going to have a potentially lengthy debate on your hands . The quicker way is to show them how it works, in a way that they can derive meaning so that they can incorporate the idea if they like it.

Tips: Once you’ve recognised the theory that resonates, decide how you want to incorporate into your practice. Design and execute experiments for putting it into place. Then measure and learn.

5. Didn’t make time for strategy

Once the teams are up and operating, you’ll need to increase your sphere of influence. There is only so much cost benefit that you get from coaching at the team level or one-on-one. Soon the biggest impediments to the team’s / organisation’s success will be ones that are occurring outside of the teams. If you haven’t strategised how you’re going to spread the Agile love, you’re going to quickly hit a ceiling.

Lesson learned: The Agile maturity of the organisation will often govern the level that Agile coaches are engaged. If you’re only engaged at the team level, changing the organisation around you will be hard, but not impossible. However, nothing is going to improve if you don’t make time for strategy.

Tips: Schedule time to strategise and enact strategy. Get out of the office if need be so you have clear time to innovate and create.

]]>http://theagilecoach.co.nz/five-ways-ive-fucked-up-as-a-coach/feed/1Standards and the definition of donehttp://theagilecoach.co.nz/standards-definition-done/
http://theagilecoach.co.nz/standards-definition-done/#respondFri, 22 Jul 2016 03:57:16 +0000http://theagilecoach.co.nz/?p=464Without standards there can be no kaizen, Taiichi Ohno. Kaizen is a Japanese word that can be translated as “change for the better”. It’s widely…

Kaizen is a Japanese word that can be translated as “change for the better”. It’s widely interpreted as meaning “continuous improvement” when referring to process or flow.

As Taiichi Ohno (father of the Toyota Production System or TPS) highlights, in order to improve, you first need to have a baseline standard. From the TPS perspective, standards and the improvement of said standards, relate to two aspects:

Process – the work carried out at a particular step on the production line.

Flow – the overall flow through the production line from end-to-end.

So, if we’re to translate this to cross-functional product teams, determining their baseline standards can be achieved by asking them three questions:

What defines an item of work and when do we know it’s ready to be worked on? This denotes the start of their flow.

When do we consider an item of work completed? This denotes the end of their flow.

What are the individual steps that are required to take a piece of work to ‘done’? This characterises each step and what that entails.

In this way, the team defines the process steps that take the product or features of the product to completion. This then becomes known as the ‘Definition of Done’.

It’s important to define done because it helps the team reach a mutual understanding of what an acceptable standard is. It also assists the team in an estimation of effort for a work item. For example, if the item of work is a User Story, the acceptance criteria for the User Story plus the items on the Definition of Done have to be completed for it to be considered ‘done’.

So, where the acceptance criteria for a User Story can be used to gauge if you’re building the right thing, the Definition of Done is a way to gauge are you building the thing right? It defines the quality aspect of delivery.

In setting up a Definition of Done, or any form of working agreement, accept that not every eventuality can be foreseen or catered for. It should be considered as a ‘living’ document, something that will mature and change as the team process matures and changes.

If a potentially better way or working is found, it should be discussed with the group that are bound by the working agreement and a consensus (most people are happy) on whether to alter it should be reached. For most teams this happens during the retrospective meeting, but can also happen at any other time when the team gathers.

One final thought, when setting up a Definition of Done, and for working agreements in general, keep in mind the Agile Values:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

This values will help the team form an appropriate agreement with an emphasis on ‘working’, rather than impeding. They should pay particular attention to the third value and in this instance instead of “Customer collaboration”, read just “collaboration”.

Contracts are generally inflexible, changes are not simple and to uphold them generally requires some form of policing. All very time consuming and should be avoided as much as possible, especially within a team.

Collaboration is inherently flexible and allows for change to occur more fluidly. It’s also self-policing, so no need for one individual to step away from the frontline, each team member has responsibility and is accountable for how things get ‘done’.

]]>Whichever way you look at it, if you’ve ever heard yourself talking to your team and uttering the words “I’m not your mother”, it’s probably not a good thing.

Even if you’re actually a Mum and have the healthy intention of creating independent and highly-functioning people – ready and equiped to face the world on their own two feet – having to tell someone who isn’t your progeny that you’re not their Mother means:

1. There is a clear case of mistaken identity
and
2. The aforementioned person(s) clearly aren’t in a place of independence or higher functioning yet.

If you’re their ScrumMaster and you’re saying these words, then you may have just fallen into the trap of becoming your team’s ‘ScrumMum’.

This can be an easy trap to fall into, particularly if you’re in the early days of an Agile adoption. This is in part due to the notion of Servant Leadership and maybe err-ing on the side of servitude over leadership.

It can also be exacerbated by the fact that few companies initially accept that the ScrumMaster role is a full-time position. They often create hybrid roles (or slashies as the movie Zoolander called them) despite protests from Agile/Scrum Coaches about ‘conflicts of interest’. In many cases, an early Agile adopter’s preference is for ‘resource utilisation’ over human objectivity.

However the conflict of interest causes considerable issues. It’s really hard to be objective when under direct pressure to deliver. So, when faced with this situation, plus the desire for successful adoption of a better way of working, most ScrumMasters will take on any trivial task to free them of this conflict. They can then maintain the justification for their existence – ‘I’m not directly productive, but look how all the support I give enables the team’.

This can lead to an over reliance on the ScrumMaster, with the team effectively seeing them as the team administrator. Before long the team stops doing even the most basic of things: from updating the board or calculating their velocity, to writing up actions from retrospective. Instead the ScrumMum ‘facilitates’ for them.

Unfortunately, the ScrumMum, while trying to do the right thing, makes it hard for the team to move up the ladder to the next level of an Agile adoption. Mainly because it separates the team from working directly with the Scrum theories and practices which help them improve.

This is Scrum by rote, instead of the standup being the Team’s standup, it becomes the ScrumMum’s standup – with the ScrumMum orchestrating and asking the 3 questions. The team just go through the motions in an almost mechanical way. This can lead to the standup becoming a status update with a distinct lack of co-ordination, the very thing the standup was intended to avoid.

The same follows with the other Scrum ceremonies. The team often going through the motions with little or no understanding of why they are doing something. Their sole interest becomes exiting the gathering as soon as possible so they can get back to their work and be ‘productive’.

As the team disengages with the system they operate in, the opportunity to create profound change and a more effective way of working is lost.

It can take a great deal of effort to turn this around. Undoing the dependence on the ScrumMum often involves some form of ‘reset’ to transfer ownership and responsibility from the ScrumMum to the team.

This often involves helping the team realise that the ceremonies and practices of Scrum are their ceremonies and practices. It’s necessary to first transfer ownership, then help the team understand the nature and value they derive from protocols.

For example, the team’s velocity is their velocity. It’s a diagnostic tool to help the team understand how well their engine is running. It’s certainly not a measuring stick to compare them with other teams. And it probably shouldn’t be use as a predictive tool for ‘planning’ delivery dates.

Instead, when their velocity dips, it allows them to reflect in order to understand why the dip occurred and what they can do to prevent that particular dip occurring again.

When their velocity increases, the team have the opportunity to analyse why it increased and decide if and how they can take advantage of it.

So, with the example of velocity, the ScrumMaster’s role is to help the team understand the principles. Why velocity is calculated, what about it’s nature will help the team understand more about their environment and how it will help them unlock and move to the next level.

It’s my humble opinion the Scrum framework presents a set of training wheels just like those on your first bike. A ScrumMaster’s key role is to support the team in understanding the mechanics of riding the bike, demonstrate why the use of the training wheels are initially necessary and then challenge the team to remove said wheels as soon as they can.

This can be done by:

Demonstrating the mechanics, show them how it works.

Transferring ownership to the team, let them try, let them fail.

Gradually decrease the support until they’re able to go it alone.

Once the team is on this path, they’re fast on the road to becoming self-sufficient. Your aim as a ScrumMaster (just like any good parent) is not to justify your own existence. You’re not there to create a group of dependents, but to know that your team can go out into the world and forge its own way.

]]>http://theagilecoach.co.nz/scrummum-agile-adoption-anti-pattern/feed/0Portals and other tools for distributed working.http://theagilecoach.co.nz/distributed-teams/
http://theagilecoach.co.nz/distributed-teams/#respondFri, 04 Mar 2016 22:56:57 +0000http://theagilecoach.co.nz/?p=175We’re a team distributed between different cities who collaborate and work closely together. We’re a distributed team, but shy away from using the term “remote…

]]>We’re a team distributed between different cities who collaborate and work closely together. We’re a distributed team, but shy away from using the term “remote workers”, because one thing we definitely aim not to do is act remotely from each other.

We are a highly collaborative, cross-functional team who like to maintain fast feedback loops. Here are some of the ways that help maintain a close working relationship.

Technologies that help us collaborateFirstly, we work on high spec laptops, this means we’re very mobile. We also operate Activity Based Working in our offices, i.e. we don’t have fixed desks, we do have neighbourhoods, but can work at any desk we choose. At the end of day, our desk is cleared and anything personal gets stashed in our lockers or taken home.

The team members that are in the same location co-locate and tend to work in mobs (smaller, cross-functional groups within the delivery team). This definitely aids speed of communication and transfer of information amongst that group, reducing the need for some meetings.

To include team members in other locations, we use a number of tools to communicate. For example, each team member uses Flowdock, an instant messenger. There are different channels for different teams and groups. Notifications let you know whether other team members are calling out to you by name. This allows the team to chat as a group with the history of the conversation available and searchable. Not only is this good for direct communication, but also adds to the degree of information osmosis.

In all of our meeting rooms we have Google Chromeboxes and large screens so that we can include team members in other locations via Google Hangouts. These are used for daily standups and other team meetings.

Instead of a physical visible workspaces, we use a Jira Agile board. When in the standup we ask someone to share the board via the hangout. They then update the board on screen as the team is talking.

For pair/mob programming we use Floobits, a great tool that allows the team to share their development environments with each other. This gives each team member the ability to navigate and type within one shared environment. This, along with video and voice, means they can effectively pair/mob program over the wire.

And finally, the most recent of these we’ve named “The Portal” after the Valve Corporation game of the same name. In the game it’s possible to use the portal device to create doors that transport you to different, not necessarily adjacent, rooms. This allows the player to move instantaneously from place to place within the fictitious game location of Aperture Laboratories.

For us, a portal is an always open video connection which allows us to see the office environment at the either end of the connection. This gives us something akin to telepresence in each other’s offices. In other words, we feel as if we’re in the same room as the other team members. Simple things like being able to see if someone is in the office, at their desk and maybe available to talk, become much easier. We also share moments where someone just stops by the portal, waves good morning or starts an impromptu conversation.

Technology is great, but what else?
Although these technologies enable us to communicate effectively as a team, we’ve found that they wouldn’t operate well without the teams having a good relationship built on trust.

One thing that we are actively working on as a team, is building a “trust bank”. It’s important to establish and build up trust between members before they are inevitably put under pressure. The trust investment that has been squirrelled away by the team can then be relied on to help them maintain an effective working relationship in trying times. This will help them overcome obstacles much sooner than if they fall back to operating as a bunch of individuals and the fallout that occurs when that happens.

Ways of building up trust within the team include:

Co-create (establish) and maintain (regularly discuss and adjust) a working agreement.

Hold regular team rituals like the daily standup and the end of iteration retrospective with video and voice. Face-to-face offers a more authentic form of communication than any other.

Virtual coffee – one or more distributed team mates grab a coffee, get away from your desks, open a video hangout and chat. Chat about what ever takes your fancy. When the coffee is finished, go back to work.

Virtual team building games, a great example of this we found recently is a game called “Keep talking and nobody explodes” – a bomb defusal game. One team is given bombs of increasing complexity to disarm. The other team is given the manual. Neither can see both. It lends itself well to being played over a hangout.

Regular gatherings where we physically get together and spend both work and social time together. Preferably the whole group at least once a year. With individuals visiting other locations probably at least every couple of months, preferably once a month.

A work in progressThese are just some of the ways we’re looking to improve how the team collaborates when distributed across different locations. The important thing is that all team members have active participation in creating the way we work together.

Technology is important, especially a high quality internet connection for video and voice. Whilst our usual internet connection works well in the most part, sometimes there is nothing better than a dedicated connection. For that purpose we have Cisco video conferencing tools in certain meeting rooms. The consistent clarity of video and voice on these devices make you feel as though you are in the other room.

Also, remember that while technology is often the enabler, for the team to work effectively together we have to know and trust each other. We’ve learnt that human relationships take longer to develop over a distance. To this end we have devised a number of ways to actively work on building them.

If you work in a distributed environment, I’m keen to hear about your experiences. If you have time, please comment.

]]>http://theagilecoach.co.nz/distributed-teams/feed/0Do, or do not. There is no tryhttp://theagilecoach.co.nz/do-or-do-not-there-is-no-try/
http://theagilecoach.co.nz/do-or-do-not-there-is-no-try/#respondMon, 03 Aug 2015 06:38:00 +0000http://theagilecoach.co.nz/?p=312“Do, or do not. There is no try”, says Master Yoda in a pivotal scene from the movie The Empire Strikes Back. When Luke, his…

When Luke, his protégée, goes onto complain about his Master’s general insensitivity to how big the task in hand is, Yoda demonstrates it is in fact possible by lifting Luke’s submerged spaceship out of the swamp. Luke’s response is “I can’t believe it”, to which Yoda replies, “that is why you fail”.

On the surface what Yoda is saying sounds harsh.

I believe he is merely instructing Luke that he already has the necessary skills and discipline. If Luke believed in himself, he’d likely succeed.

This doesn’t mean he won’t run a risk of failure, like losing a hand in the final climatic battle scene of the movie. But it does create a mindset shift where he is more likely to see failure as a hurdle rather than an obstacle. It’s what Luke learns from that failure and how he uses that to go on and complete his task (and despite the considerable odds against him, fulfil his destiny) that is important.

Improvement based upon action

Toyota was founded by Toyoda (Kiichiro Toyoda to be exact), so it’s no surprise that as a company they have similar values to the great Jedi master. But also, and very tenuous naming link between Yoda and Toyoda aside, guess what? Car manufacturing involves quite a lot of UX, design and writing of software, so they share similarities with knowledge workers.

The Toyota Way is continuous improvement based upon action. Fujio Cho, their Chairman and former President explains:

“We place the highest value on actual implementation and taking action. There are many things one doesn’t understand and therefore, we ask them why don’t you just go ahead and take action; try to do something? You realize how little you know and you face your own failures and you simply can correct those failures and redo it again and at the second trial you realize another mistake or another thing you didn’t like so you can redo it once again. So by constant improvement, or, should I say, the improvement based upon action, one can rise to the higher level of practice and knowledge.”

The Toyota Way, Jeffery K. Liker

Some of you may dismiss this as merely learning on the job, but there is more to it than that. Toyota is a company which expects its employees to innovate and constantly improve on the way they deliver. To do that it must first release them from the paralysis caused by the unknown and the fear of failure. They do this by saying it’s ok, we know you’re not going to know everything up front. You’re skilled and disciplined, we hired you for that reason and we believe in you. If you fail, learn and move on, but above all else, do.

]]>http://theagilecoach.co.nz/do-or-do-not-there-is-no-try/feed/0Aligning people & organisations via purpose – PART 1http://theagilecoach.co.nz/purpose-part1/
http://theagilecoach.co.nz/purpose-part1/#respondWed, 22 Jul 2015 10:00:34 +0000http://theagilecoach.co.nz/?p=225People and Purpose: I remember a story that my father used to tell of a traveller in thirteenth- century France who met three men wheeling…

I remember a story that my father used to tell of a traveller in thirteenth- century France who met three men wheeling wheelbarrows. He asked in what work they were engaged, and he received from them the following three answers: the first said, ‘I toil from sunup to sundown and all I receive for my pains is a few francs a day.’ The second said, ‘I am glad enough to wheel this wheelbarrow for I have been out of work for many months, and I have a family to support.’ The third said, ‘I am building Chartres Cathedral.’ ―Ben Shahn, The Shape of Content (1957, 1985)

I had a conversation with a developer not so long ago, I asked them why they did what they did. She responded that nothing really drove her to be a software developer other than the money, in fact she would sooner do another type of job if it paid as well.

What she said dwelled on my mind. To be truthful, this made me a little sad. I was sad that a person who’d chosen a particular career path that required higher education and a relatively long period of time as a journeywoman, did a job purely for the money.

I realise there are many people who have to take what work they can in order make ends meet. We often have external drivers which means enjoying our work comes second to the pressures of being the provider for a family, or repaying a mortgage or both. Sometimes we compensate by offsetting our lack of fulfilment at work with a trip we have planned or a new “toy” we intend to purchase.

Salary, bonuses, health care (especially for those that don’t live in countries that have public healthcare), company cars and other rewards help us satisfy our extrinsic drivers – whether providing for us and our families, or otherwise.

However, many of us spend at least 40 hours a week at work, a major portion of our waking lives. If we’re not doing something we enjoy, are the things it enables us to do outside of work enough to allow us to feel compensated? In my experience as a knowledge worker, probably not – the bunch of smart, well educated, technology savvy people we are – once we have those things, we will start to look deeper for satisfaction. This is when our intrinsic drivers start to come into play.

Intrinsic Drivers
Our intrinsic drivers are the things that naturally motivate us. Our choice of hobby often reflects what intrinsically drives us. When work is combined with inner drive, our sense of job satisfaction increases. If we are lucky enough to work in our chosen field, intrinsic drivers are what get us out of bed in the morning.

Dan Pink in his Tedtalk nails much of it – once the question off money has been taken of the table, the common things that many people seek at work are:

Mastery: Early on something in this industry peaked our interest and this is what started us on this journey, probably initially as a hobby, it laid down a challenge. We then spent long hours of study and modern apprenticeship in pursuit of mastering this craft – a craft that is evolving at a such a rapid pace that it will provide us with a life time of learning and challenge.

Autonomy: Independence n the way we carry out our work is important because knowledge work is creative and creativity is unique person to person.

Purpose: Our deep down need to do something in this life that makes a difference. Something that either sets us apart from the crowd or gives us a sense of belonging.

Jurgen Appello, based on the works of Dan Pink, Steven Reiss, and Edward Deci, takes this a bit further and has identified 10 “moving motivators”; curiosity, honour, acceptance, mastery, power, freedom, relatedness, order, goal and status.

He created a card based game which you can play to help you identify what drives you, Moving Motivators. Best played with others so you can compare and discuss results. This is a great game to play as a team so you can see what makes each other tick.

It also allows us to play out different scenarios and see how our motivators would change accordingly.

What’s interesting is that if we are rewarded based on our intrinsic drivers, we are far more likely to have a sense of satisfaction and less inclined to ask for extrinsic rewards.

My hypothesis
As employees, if our intrinsic drivers are aligned with our role, we’re likely to attain job satisfaction with less need for extrinsic reward. We feel “got” as individuals and as a result are more motivated towards obtaining good outcomes at work.

As employers, we are more likely to get better results if our people are happy in their work, feel trusted and able to do the best work they can. This has the additional benefit that satisfied employees are less likely to be on an insatiable quest for reward. Therefore they are less inclined to seek increasing compensation for being in an unsatisfactory role, or worse still, go else where.

As an industry we’re starting to tap into mastery and autonomy fairly well. Providing professional development and environments that encourage individual thinking and contribution. However, if we were able to align an individual’s purpose with an organisation’s, we’d have a very powerful thing indeed.

In this series of blog posts, I want to explore this hypothesis in more detail. In particular to determine how employees and employers can align their purposes. In the next blog post, part 2 of this series, I’ll take a look at organisational purpose.

As Stuart began to explain how to setup a negotiation to get a good outcome, I became very aware that I go through a similar setup to get a good outcome for the teams and individuals that I coach.

In fact, I view the role I perform in most meetings as lying somewhere between facilitator and negotiator. A coach often sits in the middle between two parties, for a software product that’s between those who want something built and those that are building it. If both parties are to get a good outcome, the coach cannot act as the arbiter or judge of what is good and what is not. Instead they act as a processor and reflector of what is being exchanged between the two. The coach is impartial, yet invested in getting a positive outcome for both parties.

With reference to Stuart’s talk, I thought I would look at the setup a negotiator goes through prior to a negotiation and explain how that is similar to the setup a coach would perform for a team meeting.

Stuart explained that three things that you can do that will effect the process of negotiation and are likely to lead to a positive outcome:

1. Remove need

Neediness creates vulnerability. This effects your listening, thinking, focus and will cloud your judgement. It’s not good to be needy if you’re trying to negotiate or act as a negotiator. Sounding needy can have one of two effects on people in a negotiation. Either alarm bells go off and they will withdraw, or they hear needy and their predator instinct will come to the fore.

Bottom line, if you aren’t prepared to say no, you’re probably being needy. Try to reframe from need to want.

From a coach’s perspective if we are tied to a particular outcome and we try to drive the team or individuals toward this outcome, then we will come across as needy. This will ultimately set the team on edge and they will either back away from the suggestion with a heavy dose of skepticism or they will take advantage of your neediness.

For example, the business are disappointed with the speed of delivery and need the team to deliver faster by increasing the velocity. If as a coach we try to drive the team to deliver faster without fully understanding their perspective, they are likely to see us as unreasonable and disengage. At the other end of the spectrum, the team hear the need and decide to take advantage of the situation. Because trust has been broken, they will probably take measures to protect themselves, for example increase the level of contract between them and the business. Neither option gets an outcome that is mutually beneficial for either the team or the business.

2. Help them hold the vision

No vision, no decision. If the people who are in a negotiation don’t hold a vision of the opportunity available to them, they are unlikely to be able to make a decision. Before negotiation starts we need to ask ourselves “who must see what now?” We need to think about how we’re going to discover and shape what they want to see. During the negotiation we are able to help them own the vision by asking them open and powerful questions. The type that Lyssa Adkins talks about in “Coaching Agile Teams” and CTI train their coaches to use in their Co-active Coaching model. We need 2 to 3 good questions.

Stuart pointed to a number of good examples. For example, this blog by Seth Godin asks what is most powerful question a Girl Scout going door to door selling cookies could ask? Selling door-to-door is a hard enough for an adult, for a child it can be terrifying, but Godin says that in less than 10 words – “What’s your favourite kind of Girl Scout cookie?” – you can increase your chance of selling by more than double. Why? Because that one question will immediately make us start to think of our previous cookie experiences, the smell, the taste, we may even start to salivate.

An open question this powerful immediately allows the other party to own the vision. This moves the negotiation far beyond a simple exchange of money to where the potential purchaser actually imagines what those cookies would smell and taste like. At that point they will realise the value of those cookies and exchanging money for that experience will come much easier.

As a coach we seek to help the team to find solutions that work for them. As with a negotiation, the parties involved are far more likely to follow through with something if they had a part in creating it. To do this we help them create a vision of the problem that helps them see all sides. This then helps them find a solution that will be mutually beneficial.

3. Focus on the controllable

You can only control what you can control, which isn’t much, including the outcome. If you can, don’t be attached to a particular outcome as it creates neediness (see point 1). Therefore, focus on your behaviour, the thing you can control. Ways to approach this:

No talking – talk less, listen. This is something we do as coaches, we ask ourselves why are we listening? Are we listening because we waiting for our turn to talk or are listening because we genuinely want to hear the other person’s point of view? More importantly are we listening so that we are able to facilitate an exchange of views?

Blank slate – don’t hold any positive or negative assumptions.

3+ your questions, i.e. ask the question in 3 different ways to ensure you have all the information you need.

I actively work on the facilitating and negotiating aspect of my role. If the coach is less than impartial, there will be a break down in trust and the negotiation for the desired outcome will fail. The important thing is that we prep for meetings and get ourselves into the right mindset.

One coach I know joked they had a four step process to meeting preparation – on the final four steps of entering a meeting, their thoughts turned to how they would facilitate it.

This joke isn’t too far from the truth, once you have method that works and you’re practiced enough, it doesn’t take long to get into the right mindset.

Step 1: Ask yourself what do the attendees need from this meeting?

Step 2: Ask yourself what do you need from this meeting? Think about how you want to be and act to get the best outcome for everyone involved.

]]>http://theagilecoach.co.nz/art-negotiation/feed/0Impact Mappinghttp://theagilecoach.co.nz/impact-mapping/
http://theagilecoach.co.nz/impact-mapping/#respondSun, 21 Sep 2014 20:06:48 +0000http://theagilecoach.co.nz/?p=81The other day we workshopped some ideas around one of our products using a technique called Impact Mapping; a collaborative approach to Agile requirements gathering…

]]>The other day we workshopped some ideas around one of our products using a technique called Impact Mapping; a collaborative approach to Agile requirements gathering and planning created by Gojko Adzic. For the purpose of a demonstration I’ll describe the steps we went through using this blog as an example.

Impact Mapping asks four questions:

1. WHY ARE WE DOING THIS?
This is the business goal, or one of the goals, we’re hoping to achieve for our next phase of product development, e.g. increase the number of visitors to this blog.

The goal should be SMART – an acronym which stands for Specific, Measurable, Attainable, Relevant and Time-based.

It’s also wise to determine how you are going to measure success – how will you know when you’ve reached your goal? The following format is suggested in the Impact Mapping book:

2. WHO WILL HELP US?
The people that will help us achieve this, e.g. the readers of this blog. Gojko uses the term “actors” to describe the people who interact with our system and categorises them as primary, secondary and off-stage actors. This equates to the 1st, 2nd and 3rd degree users of your service.

For example a primary actor will be the primary focus of your product, the person that you’re aiming the product at. A secondary actor is someone who interacts with product in order to provide a service, for example the blogger writing blog posts. An off-stage actor is someone who interacts with your product indirectly, e.g. use analytics to determine where best to target the next phase of development.

3. HOW WILL THEY HELP US?
The way the actor will help us achieve this – e.g. share this blog’s posts on social media. In essence, this describes the outcomes that we believe will help us reach our goal.

4. WHAT WILL WE DO?
The things we’ll create or change to encourage this behaviour – e.g. make blog posts easily shareable. These are the changes we’ll undertake to our product in order to create the behaviour we desire.

In this step we’ll write down as many actions as we can think of, for each of the outcomes we identified in step 3. The result should look a little like this:

Once we’ve created all of our actions, we will need to determine which will deliver highest value to the business soonest. So the next step is to generate a consensus on the order we should carry out the changes. We used a system called dot voting. Each person gets a set number of sticky dots (votes) and they vote on the ideas for action they think will most likely increase the number of visitors to The Agile Coach. For the demo we didn’t have sticky dots to hand, so we used sharpies to mark votes as crosses.

It’s then easy to create your backlog and order the User Stories according to priority using the Impact Map. The template we use for writing User Stories is:

As an ACTOR I want ACTION so I get OUTCOME

On the Impact Map this translates as:

ACTOR OUTCOME ACTION

As a READER I want the Agile Coach to have BETTER SEARCH ENGINE RANKINGS so I can DISCOVER BLOG POSTS.

As an AUTHOR I want to PROVIDE QUALITY AND QUANTITY OF POSTS so that I can INCREASE MY REPUTATION.

As an AUTHOR I want to SEEK REFERRALS for my blog posts so that I can INCREASE MY REPUTATION.

As a READER I want the ABILITY TO SHARE VIA LINKEDIN so I can SHARE BLOG POSTS.

As a READER I want the ABILITY TO SHARE VIA EMAIL so I can SHARE BLOG POSTS.

Once you have a prioritised set of User Stories, it’s fairly straightforward to create a release schedule based on the team’s velocity (or estimated velocity). You can also look at setting milestones for your measurements to check if you’re on track, i.e. to meet our end of December deadline to increase the number of visitors by 100%, we should have increased to 37,500 visitors by mid-November.

And in a nutshell, that’s Impact Mapping. For further information I recommend you read Gojko’s book Impact Mapping, or if you can, attend one of his workshops. The Impact Mapping website is also a great source of information.

In practice, I found this technique straightforward to use. I like that it focuses on actors to drive the group’s thinking and focus on the people who actually use your product. This has similarities to Jeff Patton’s technique of Experience Mapping which uses personas to achieve the same aims.

I’ve found the key to success for both approaches is to prepare the questions that you ask the group, for each stage of the process.

It’s also important to keep things moving along so that ideas don’t get stale. To do this I’ve found it necessary to 3+ questions, i.e. reframe the same question in at least 3 different ways. If no more information was forthcoming after the 3rd reframe, move on.

]]>http://theagilecoach.co.nz/impact-mapping/feed/0Negative metrics – why you shouldn’t focus on themhttp://theagilecoach.co.nz/negative-metrics-why-you-shouldnt-focus-on-them/
http://theagilecoach.co.nz/negative-metrics-why-you-shouldnt-focus-on-them/#respondTue, 09 Sep 2014 10:25:00 +0000http://theagilecoach.co.nz/?p=48What is a negative metric? Well, a metric is something that you measure in order to give you an idea of how something is performing.…

]]>AUTHOR’S NOTE: This post is inspired by several keynotes and subsequent conversations at Agile NZ Conference 2014.

What is a negative metric? Well, a metric is something that you measure in order to give you an idea of how something is performing. A negative metric is a performance indicator that tells you if something is going badly, but it doesn’t tell you when that same something is necessarily going well.

For example, velocity. If velocity is low, or fluctuating between iterations, this is usually a sign that something isn’t going well. However if velocity is normal there is no guarantee that the team is delivering value. We know that they are working, but that is all we know.

If we want to be sure that they are delivering value, then we have to measure it directly. Measuring delivered value is much more complicated than measuring velocity. It requires feedback from the customer telling the Product Owner if what the team are building is meeting their needs.

Therefore velocity is useful if it’s being used by the Product Owner to determine what the team is capable of. It will certainly aid in release scheduling, but it is no guarantee that the product development is on the right track.

Another reality of metrics like velocity, is that the very act of focusing on it, has the potential to cause a decrease in the performance you desire. For example, if velocity is being used as a stick to beat the team (the usual statement from the business being something like “your velocity isn’t high enough and you need to raise it so that we can go faster”) then, overtime, velocity will become less meaningful. Why? Because the team will raise their velocity, but it won’t necessarily be as an increase in output. The team will merely increase their estimates, i.e. a story point will move from being 2-3 ideal days worth of work to 1-2 ideal days of work.

This results in the same value as previously being delivered, but with a higher velocity. In my experience, this isn’t done deliberately by the team, it’s done because a light is being shone on them and they will merely change it in an effort to please.

Other examples of negative metrics in software product development are:

Lines of code written – shows that your developers are writing code, but doesn’t testify to the usefulness or quality of that code in any way. Focus on this metric and you will certainly get an increase in lines of code written if nothing else.

Test code coverage – percentage value of code covered by tests. Shows that tests have been written to run the code, but there’s no guarantee of the effectiveness of those tests in preventing bugs.

Examples of metrics that you could focus on:

Value delivered – is the customer getting what they want/need?

The flow of value – how much and how often is value delivered?

Number and severity of bugs released into the wild – one of the only true measures of fit-for-purpose quality that customer and the business should care about. The further down the value stream bugs are found, the more expensive they will be to fix. Agile methods advocate testing from the get-go.

Happiness of your team(s) – happy teams are working in a way that is sustainable. Standards and quality will be high. The team will have a high sense of satisfaction.

In short, negative metrics have their place, however used unwisely they can have unintentional side effects and actually de-optimise the performance you’re looking to gain.