Product Camp Vancouver

/by

I’ve been participating in ProductCamp Vancouver since moving to Vancouver nearly five years ago, and I’m proud to announce that, for the third year running, agile42 is a sponsor of Product Camp Vancouver 2015 taking place on Saturday February 28th.

ProductCamp Vancouver

At agile42, we love the ProductCamps. A free event with a focus on innovative and thought-provoking practices in the world of product development. After sponsoring ProductCamp Vancouver over the past couple of years, we also sponsored ProductCamp Berlin in September 2014, This year, we’re proud to come back to our roots and sponsor ProductCamp Vancouver in February, 2015.

If you’ve not been to a ProductCamp, block your calendar and get to the next one in your neck of the woods. It is the first and only unconference for product managers, product marketing managers, entrepreneurs and others with a passion for product, online and IT. At agile42 we introduce lean and agile practices to our clients, and while this usually starts in a technology group, we often end up focusing on introducing validated learning and product innovation practices as part of the product development lifecycle. Having an incredible agile development capability is the starting point for product innovation, not the end goal.
 
This year, ProductCamp Vancouver has moved to a larger venue and promises to be the largest ever in Vancouver. They expect 200 participants, and following the Barcamp idea of “no attendees, only participants”, they will actively engage in a day of workshops, discussions, networking and learning.

ProductCamp Vancouver will take place at UBC Robson Square on Saturday February 28th. Unfortunately registration is sold-out at the moment but you can join the waiting list.

agile42 sponsoring Agile Open Northwest 2015

/by

Agile Open Northwest, a non-profit alliance of agile practitioners in the US Pacific Northwest region, presents the ninth annual Open Space conference exploring agile practices, techniques, realities, and visions. agile42 is extremely proud to sponsor AONW 2015 and to attend the event!

The theme for this year Open Space, held at the Leftbank Annex in Portland, Oregon, is “Agile Vision”. We are happy to bring fresh empirical evidence driven Agile transition services jointly working with client to develop future Agile workspace.

Hope to see you at Agile Open Northwest 2015, 11-13 February 2013.

Let them know

/by

An Agile Transition can be a difficult thing for those that have previously been responsible for direction or closely monitoring people’s activities. Often, new techniques and approaches need to be learned and practiced.

Even with the most co-operative person trying to make this change can be difficult. I often hear talk of uncooperative managers or middle managers and wonder if they have been given a fair chance to succeed in the new approach.

This is just one example, but you’ll see the same could apply to many situations.

I describe the situation as “Let them Know”.

Here’s a scenario… 

A development manager new to Scrum in charge of 30 people “wants to do the right thing” (their words).

The manager is looking for a place to start changing his behaviour to help the team, the Product Owner and the ScrumMaster succeed.  Sounds good right !?

Through coaching with the manager and with the team’s ScrumMaster and Product Owner, everyone agrees that the next Sprint, they will really change their focus and for the first time, will allow the team to make their own commitment during planning without any influence whatsoever. They also agree that they won’t push the team and assign tasks to get the stories done.

This is of course, the ideal we all have learned. The team making it’s own decision.

In this particular example, the team did not complete their work, or even have any idea of what they needed to do. Planning was inappropriate, the team devolved into complete chaos.

After careful facilitation during their retrospective, the team realized that they did not KNOW that the manager was changing their behaviour.

The resulting retrospective indicated that if they had known they suddenly had this new responsibility, they might have taken it.

There are other questions to be asked about the role of the Product Owner and the ScrumMaster and what they might have done, but for now let’s focus on the specific role of the manager in this situation.

Self-organization is a wonderful thing.  But, give your teams a chance (and the managers who are trying to change).  Consider letting people know that you intend on changing your approach and ask them what you can do to support them in this change.  

Surely, if they don’t know you changed the rules of the game on them, then it’s really not right to say afterward.  “See, I told you they wouldn’t self-organize”.  The problem might be, do they even know they can?  In many command and control environments, people are not used to having the autonomy to make their own decisions. A sudden change to this without letting people know their new rights (and responsibilities) is just going to result in failure.

Before_After_Switch

Remember, just because you change your behaviour, it doesn’t mean that next Sprint the team will miraculously do so.  You can’t just flick a switch.

Consider letting people know you are changing your approach.  It might not work for everyone, but some might appreciate knowing that you intend on doing so.

They might just surprise you and succeed as opposed to feeling bad because they just didn’t know your approach was changing.

 

Just a thought.

 

 

When NOT to Coach

/by

Coaching is a fantastic way to engage with people and help them to achieve great results, but coaching is not the answer to everything. There are situations where you feel encouraged to use your coaching skills but the context does not make coaching the best approach. Something else is more appropriate! The purpose of this blog post is to sharpen your awareness on when to coach and especially when NOT to coach.

The word no made from jigsaw puzzle pieces

One of my beginners mistakes as a coach was when I was approached by one of my colleagues in a previous job. She had just taken on the responsibility of being the project lead of the marketing department in the company, and she wanted my advice on how she could develop her skills in this area. To be specific: Which Project Manager Education would I recommend? I took this situation as a great opportunity to use some of the coaching tools and skills I recently had learned. So I started bombarding her with powerful questions and the like, but forgetting to actually agreeing with her about what kind of conversation we were having. During this conversation she became very frustrated with me. She just wanted my advice, but whenever she asked me a question, she got at least two other questions back in return. Did I serve her well? Absolutely not!

Looking back on this situation I realized that coaching is not the answer to everything. There are situations that call for coaching and situations that absolutely do not call for coaching.

Agile coaching differs from pure coaching

Agile coaching is different from pure coaching, because sometimes we as agile coaches really have the answer or at least, we have our own agenda for the interaction we do with the team or person we coach (Siegfried Kaltenecker and I explained about this in our article: Agile & Systemic Coaching). Therefore, an agile coach needs to have awareness about different engagement approaches, reflect on the situation and pick the approach that serves the purpose in the best way. As discussed by Ralf Kruse in his blog post: My understanding of effective Agile Coaching, an agile coach needs to be able to switch between the positions of Coaching, Teaching, Mentoring and Advising people. In addition to that I would like to add Role Modeling, because a good agile coach needs to live by the Lean and Agile values, being a living example for others. These approaches are collected in what we call the Coaching Approach, which is part of our Team Coaching Framework. Here we take Coaching as the basis position, from which we can choose to involve other positions, but we always comes back to coaching.

If I would have been aware of our Coaching Approach at the time when my colleague asked me about the project management training, I would have been able to serve her better.

Open and closed contracts

In my blog post: Have a structure for your coaching conversation, I introduced a format  to better structure a coaching conversation. An essential part of this format is to agree with the coachee on the topic and approach of the conversation. We call this establishing the contract. When you are doing pure coaching establishment of the contract is open, which means that you as the coach are open-minded and you follow the coachee on the topic he or she wants and you comply with the decisions on the approach made by the coachee. As an experienced coach, you of course have been giving suggestions to the approach, but the coachee decides which to follow.

However, coaching conversations can also be held with fixed or closed contracts. Closed contracts are for when the coach is having something on his or her mind – seeing potentials for improvement for the coachee. This can for example be when the Scrum Master have observed dysfunctions during a sprint and wants to address this with the team at the retrospective; it can be when the agile coach sees inappropriate behavior in the acting of the Scrum Master or Product Owner; or it can be when a manager wants an employee to improve on an area not yet realized by the employee.

When establishing a conversation with a closed contract, the coach shall be firm on the topic and also more directing when it comes to deciding on the approach than she usually would be. Closed contracts are often initiated by expressions like: “As your Scrum Master, I have observed some obstacles in the way we handle xxx. In my experience this is a problem. Therefore, I would like us to discuss which challenges we have in this area and I want us to decide what actions we are going to make in the coming time to improve on this matter. I suggest we do this in the format of a coaching conversation where I will be your coach”. It is of cause important to have the coachee(s) committed to participate in this conversation, accepting the frame that you are setting.

If you are using coaching as someone who is superior to the ones you are coaching, is it especially important that you are constantly aware of which perspective you are speaking from. Are you speaking as the manager/ScrumMaster/agile coach or are you speaking as the pure coach. Make it explicit when you are talking as someone else than the pure coach.

Coaching is not the right approach for giving feedback

If you have started using coaching from a managerial perspective, you probably feel encouraged to use this approach for as many of your conversations as possible. But be aware: coaching is not for any kind of conversation.

If you are planning to have a conversation with a person or a team where the purpose for you is to deliver a certain message, coaching is not the approach. Especially not, if your are giving specific guidelines or even dictating how certain matters are to be handled in the future. To go to the extreme: If you are warning someone about the consequences of his or her behavior or even firing the person, coaching is an absolute no-go. However, inviting the person to a series of coaching conversations (probably with closed contracts) as follow-up of a warning, can be a splendid idea. It shows your interest in investing in the person after all.

It is not therapy

In my blog post about keywords and levels of listening I stated: “Coaching is for well-functioning people, who want to reflect on a matter and find new ways to act with the purpose of improving their situation”. That means: coaching is for people that are mentally healthy and as a person practicing coaching, you have a responsibility of not harming the person you are coaching.

Practicing coaching does not make you a psychologist or a therapist, you are still just an ordinary person who is practicing coaching. Therefore, if you have the slightest concern that the person you are consulting actually needs therapy instead of coaching, it is your responsibility to end the coaching conversation and help the person to consult a professional person with the right skills. How will you know? Well, as I once learned from a pilot about landing an airplane: If you are in doubt, then you are not in doubt! Meaning: if your are concerned that your are on the wrong path then act as if your are on the wrong path.

A pilot in doubt will make a fly-by and initiate a new landing attempt. A coach in doubt will end the coaching conversation and help the coachee to meet the right professional person. It has happened once or twice to me in my career of practicing coaching and I am happy that I did not just move on, experimenting with the coachees mental health.

Photo by Horia Varlan, on Flickr