The Value of Pair-Coaching… What’s in It for You?

/by

Coaching is the process of facilitating a reflective thought process within somebody else in order to enable them to make some progress towards a goal. One can coach another individual in a one-to-one setting, or one can coach a team. While the principles are effectively the same, the techniques employed may well be different.

Coaching is very different to training not least because the agenda within a coaching relationship can emerge and be tailored to the needs of that individual (or group) there and then. Coaching isn’t focussed on passing on a specific skill or filling an educational gap but rather helping them tackle a specific challenge or understand their strengths and weaknesses – technical, psychological and inter-personal – in relation to a particular task or situation.

Coaching is usually spaced out over days, weeks or even months rather than a concentrated one-off event and this allows for time in between each new piece of insight or nugget of reflection. Time that can be used to digest, analyse, experiment and explore further, allowing the person or group to discover what is important to them.

Pair of bikers

Often the presenting issues at the beginning of a coaching engagement turn out to be symptoms of something else or part of a bigger picture. The evolving nature of a coaching engagement gives both coach and coachee the opportunity to inspect and adapt, to reflect and adjust what they are focussing on for the benefit of the coachee.

A flip side of the evolving nature of a coaching engagement is that it can be difficult to create success factors. In general, coaching is successful if it leads to an improved behaviour of the coachee and commitment to self-improvement in a sustainable way. Behavioural change requires time and persistence to be fully established and so as coaches we only really know that we have been successful when we see genuine and natural behavioural change in the medium term.

Coaching isn’t easy as it requires not just technique but continual practice and reflection. One challenge for many coaches is practicing detaching themselves from the problem and remaining objective in guiding the coachee without pursuing their own agenda. When faced with a problem that needs solving it is almost inevitable to begin to think how to solve it, even when actually, the agenda of a systemic coach is to help the coachee find their own solution.

While agile coaches follow the same underlying principles of systemic coaches, they don’t have the luxury of being completely solution agnostic as agile coaches have the additional responsibility of embodying the agile manifesto principles and values. This means that in the case that the coachee is diverging significantly from those values and principles, the coach has the professional and ethical responsibility to point this out.

What is pair-coaching and how does it work?

Pair coaching refers to a pair of coaches – two people working together as coach. This isn’t a good cop/bad cop setup but rather two minds and two perspectives coming together for the overall benefit of the client.

The principle of pair coaching ultimately stems from the practice of pair programming from the world of software development where two programmers share one workstation with one person “driving” while the other observes or “navigates”. Roles are switched frequently and this built in review process increases not only quality but innovation, speed, learning and – somewhat interestingly perhaps – work satisfaction [Ref 1].

In the world of coaching, this often follows a similar approach although instead of a workstation that the pair is sharing, it is a conversation or workshop. Typically one is driving which involves having a direct conversation or running a specific exercise or technique.

This more often than not involves one coach getting fully “in the zone” with the client – almost a melding of minds as their listening and intuition deepens to a deeper than “active” level or what Co-Active Coaching might call “Global Listening” [Ref 2] – while the other is supporting, observing, facilitating and noticing. The “navigator” is ready to provide insight and perspective from “outside the bubble” to both the coach and the coachee. Then the roles switch.

Anyone can pair-coach and we believe that everyone arguably should. We see pair coaching as an example of a commitment to growth and a willingness to improve. There is an implicit acceptance of exposing one’s style, behaviour, technique and experience to a peer’s feedback, which should also lead to improvement, and change. There is an inherent sense of vulnerability in pairing – whether at a workstation, in a workshop or in a coaching conversation.

As such pair coaching is not easy and not everyone takes to it straight away. It requires humility and the ability to collaborate and share rather than own the conversation. One needs to be open to feedback and “performing” in front of another. Can you shut out the fact that others are observing you? Are you able to dance in the moment and follow an unknown and forever evolving path that not only you are in control of?

The outcome of a collaborative activity – and pair coaching is such an activity – is the inability for anyone (including those directly involved) to be able to say (or have the desire to say) “this was my work”. It will inevitably be “our work” and will be so intertwined with back and forth that it is even difficult to distinguish the parts that we played individually. If one retains the need for individual recognition then pair coaching will inevitably lead to personal frustration or suboptimal pair coaching.

What is the value of pair-coaching?

As well as the obvious benefits to the client of having two coaches providing expert insight, reflective feedback and a more focused and effective approach, there are benefits to the coaches as well. Pair coaching has built in supervision and thus allows for real-time observation and feedback on coaching style, presence, technique and effectiveness as well as learning from each other.

A single coach, especially in a situation where there is a large group of people to help, could miss individual behaviours or signals of dissatisfaction or even lose control over time and objectives, depending on how much she is entering into the flow. When coaching alone, one needs to alternate between the specific content level and its meaning and significance while also keeping control over time and the agreed rules of engagement. With two coaches, these roles can be alternated and you can be sure that both coaches will be much more effective at both observing and supporting activities and conversations with a group of people.

I get it, it’s cool, but how come very few people actually do it?

That’s a very good question actually… why doesn’t everyone pair-coach? It’s very difficult to answer and we can only speculate. However, some of the reasons that pair coaching isn’t yet a widely accepted practice probably include:

  • It requires quite a lot of trust as it inevitably includes vulnerability. There has to be a good relationship between the pair or at least a certain level of mutual respect. This can take time to practice in order to develop the level of understanding and affinity which allows to switch naturally during a coaching session.
  • It requires confidence, partly in your ability as a coach but also your ability to adapt your style. It also requires enough self-confidence to not seek individual recognition for the pair’s output.
  • It requires taking some risk, and accepting that the journey will end up in places which might not be the one that we have envisioned.
  • It requires giving up control over how your part of the coaching conversation will play out. Of course a coach is never in control of the conversation but in a pair-coaching environment they aren’t even in control of their own side of things.
  • From a client’s perspective, it isn’t easy to accept paying double for the “same” service. Why should I pay for two coaches to do the job of one? This is a similar argument that surfaced in the pair-programming world and clients were rarely informed of the potential benefits

Have you ever tried pair-coaching? How did you find it? Why do you think it is not more prevalent? What might make you give it a try? We would love to hear your thoughts.

References

  1. Laurie Williams, Robert R. Kessler, Ward Cunningham, Ron Jeffries. Strengthening the Case for Pair Programming. IEEE Software. IEEE Software, July–Aug. 2000. Web. 4 October 2013
  2. Henry Kimsey-House, Karen Kimsey-House, Philip Sandahl, Laura Whitworth (2011) Co-Active Coaching: Changing Business, Transforming Lives, 3 edn., London, UK: Nicholas Brealey Publishing.

Photo “DualSport, KTM 525EXC” by Cadams7649

Thanks to our guest author and friend Geoff Watts! He is a Certified Scrum Trainer & Servant Leadership Coach at Inspect and Adapt, a TEDx speaker, and author of Scrum Mastery and The Coach’s Casebook. You can also follow him on Twitter as @geoffcwatts.

Agile Transition in German magazine wissensmanagement

/by

I have been asked to author an article about Agile Transition in the German magazine wissensmanagement. The article will appear in the March issue with title Agile Transition: New roles require new thinking (Neue Rollen erfordern neues Denken).

Logo wissensmanagement magazineIn the article we explain how Agile methods help companies to adapt quickly to changing market conditions and remain competitive. An Agile Transition is not made of individual tools or methods, but requires the willingness to learn and to continual improvement ahead. These are concepts that we often teach and coach as part of our Enterprise Transition Framework™. It’s been a pleasure to be able to communicate our point of view to a wider audience.

You can download the PDF from our site or from the magazine archive.

We have been listed between the top 100 Agile blogs

/by

100 Top Agile blogs in 2015We are happy to have been included in the list prepared by the Oikosofy Team of the 100 Top Agile blogs in 2015! We always try to show you a snapshot of what happens in our corner of the Agile world through events, trainings and the great hindsights provided by our team of coaches.

We are looking forward to make the chart again this year… We are listed at #18, take notice blogs 1-17!

Jokes aside, the list is a great tool for newcomers and experts alike. It shows the variety of the Agile community and the endless opportunities to learn from the experiences of fellow practitioners. Thanks to Oikosofy for publishing that.

Making Time for Refactoring

/by

One of the most common things I hear about refactoring is that there isn’t enough time for it. I hear that there is important refactoring to the code and architecture that will take days or weeks and there’s no time to fit that in because of tight timetables.

Often times teams write off refactoring as something other teams with more time get to do, but not them. The truth is all teams have tight timetables for delivering their software and the key to refactoring is not more relaxed deadlines (deadlines do need to be realistic, but that’s another topic).

A quote attributed to Aristotle tell us: We are what we repeatedly do. Excellence, then, is not an act but a habit.

The same is true for great coding and, by inference, refactoring. To effectively make refactoring part of our development process, it must not be a large effort that we spend days or weeks on, but rather, a habit that we practice continuously while writing code. So, if we want to make refactoring a habit, that raises an important question.

When Should We Refactor?

Always! When we refactor in small increments as we develop code, we’re able to spend a few minutes at a time keeping our code at a high level of quality. Let’s look at the TDD (Test-Driven Development) cycle to see how it integrates refactoring.

TDD (Test-Driven Development) cycle

In test-driven development, there’s a spot after every time you’ve successfully written a segment of code to evaluate the code and refactor it. In practice, most times you look at your code and you’re happy with it or there’s a small refactor, like extracting a method, which takes a minute or two of your time. On rare occasions, a significant refactoring becomes apparent and takes up 20 – 30 minutes of your time. After each code refactor, you run your tests again to make sure you didn’t break anything.

Another often forgotten trick is to use the automated tools at your disposal. Most IDEs have refactoring facilities built in nowadays. Learning how to use them correctly will save a lot of time and reduce the risk of errors. Knowing what change to make is still essential.

Does this save you any time in refactoring compared to doing a large effort after several months? No, I don’t think it does. In fact, I think you’ll spend more time refactoring. That’s because when you spend a few minutes at a time, it’s easy to absorb that time into the development process. It’s just part of what it takes to get the work done right. When you wait, you’ll probably spend less time because you won’t do all the refactoring that should be done. If you’re like many teams, you won’t do much refactoring at all. Waiting makes you feel like you have to settle for low-quality code. The team isn’t proud of the work and the business isn’t really happy with the results, but they feel like they’re stuck with it unless they pay a large ransom of technical debt to refactor it.

Building blocks

What About Refactoring Legacy Code?

Sure, we’ve all been in that situation where we’ve been handed a pile of code that isn’t up to our (or in fact anybody’s) standards for good code, but refactoring it would take forever. Perhaps it’s mission critical too, or written by somebody who just can’t be questioned. What do we do with it?

First, we have to acknowledge something: people always try to do their best, but circumstances can prevent them from doing a proper job. That code was probably written by people who were capable of better, but rushed through and didn’t take time to refactor because of tight deadlines. So that leads us to step 1:

Step 1: Break the Bad Habit

You can’t change what was done to the code before it got to you, but you can stop it from getting worse. As a team, agree that from here on, no code changes are made without building in time to refactor. Each time you open a file, leave it just a little cleaner than you found it.

Step 2: Set Expectations

You’ve inherited all of the problems with the code and just because it’s been given to you doesn’t mean it’ll magically get better. Make sure there’s an understanding between your team and the business stakeholders about what improvements they need and when they need them. Some things may be able to wait until they come up naturally. Others may be causing customer pain and need attention right away. These items should get worked into your backlog so they can be given appropriate priority and it’s clear what business value they are delivering.

Step 3: Isolate Your Effort

You can’t fix a huge amount of code all at once. As you need to make changes, isolate a particular behavior that you’re testing. Wrap it in tests, and refactor what you’re changing. Sometimes this is as simple as identifying a class or two where the changes occur and focusing effort there. Other times you have to put some work into isolating code.

How we work with legacy code can be very complex and is far too involved to solve in a blog post. Luckily, a very good book has been written on the subject: Working Effectively with Legacy Code by Michael C. Feathers (Prentice Hall, 2004) rightly belongs in the bookshelf of every coder.

Summary

In short, there is no silver bullet for refactoring code, but good practices will take you closer to the goal day by day. Make an effort to refactor every time you are about to close a source file and take the time to diligently chew down legacy code into smaller pieces. Always implement automated testing on the module level or higher to give you a safety net that guards against changes in the behavior of the component and learn to use the automated tools at your disposal.

 

Photo by Holger Zscheyge

How to do Scrum better?

/by

Do Better Scrum cover

We often distribute a list of read-further pointers that are useful for students that have attended our Certified ScrumMaster and Certified Scrum Product Owner trainings, and for anyone interested in deepening their understanding of Scrum. Some of these topics are discussed during our 2-day classes while others are left for further exploration.

A good read to sum up the learning about Scrum is Do Better Scrum, an unofficial set of tips and insights into how to implement Scrum well, free for download.

Do Better Scrum is written by Certified Scrum Coach & agile42 Trainer Peter Hundermark and translated in French, German, Spanish and Portuguese. The original English version is available through InfoQ in PDF, ePub and MOBI format.

In the words of the author “I hope this little booklet may be a source of inspiration to help you do Scrum and Agile a little better each day.”

Agile & Gaming Companies

/by

In many cases, the artwork and creative elements of a product, such as a game, requires work from many skilled artists, from graphic artists and UX to animators and audio engineers. Creating an art team to deliver art assets, and having them operate as a Scrum team can work. But there can be challenges with this too. In the following article I describe the experience of a gaming company that experimented with art Scrum teams and ended up combining engineering Scrum teams with art Kanban teams. This change was driven by the art team as an experiment, with the clear need to outperform the status quo (an art Scrum team).

Design + UX + UI + TESTIn many Scrum development teams, the design component is included in the team’s delivery. Either stories include mock-ups to be implemented as seen, or the cross-functional team includes a dedicated graphic designer/front-end designer who works as part of the cross-functional team to deliver a working product at the end of the sprint.

For highly creative (artistic) products, such as games, that include a large amount of design work, often equal to or greater than the engineering component, this approach can be difficult for a number of reasons.

•   First, the team size tends to be too large. Including art, audio, animation and engineering skills on a single team can lead to a large team, easily in double figures.

•   Second, there is often weak dependency between art and engineering. Building out art assets, including audio and animation, has little to do with the engineering components (how the art assets behave or interact) once the core mechanics have been proven (normally with wireframes or concept art).

•   Third, conflicting product ownership. The product ownership for art assets is typically owned by the Art Director, while the entire game is owned by a Game Designer or Executive Producer.

While there are many different ways to address this, and ultimately, every product team will experiment to find the way that works for their team, below is the story of one such team, and how they solved these challenges.

A well known US-based gaming company develops freemium games for handheld devices. These games are free-to-play with in-app purchases,  and designed specifically to be played online through mobile devices. One of their game teams, in the final stages of development, were developing against a tight deadline with high expectations on the team.

The team itself consisted of up to 25 developers (engineers, testers) and artists (designers, animators and audio engineers) responsible for bringing the final product together. Initially, the game team split into three Scrum teams, two engineering teams and an art team. While this worked well for the engineering teams, the nature of the work that the art team had to deliver (part concept work, part asset creation, part final asset delivery) fit poorly into a sprint. The art team felt pressured unnecessarily to follow a commitment to deliverables that didn’t match the reality of creative work.

The art team required constant review and approval by the Art Director, with a high chance of considerable change as the entire game design developed with time and functions such as audio or animation, were rarely needed until final assembly. It quickly became apparent that an art Scrum team was not going to work, and rather than persevering at the risk of losing the enthusiasm of the designers, the team was asked to come up with a different approach that had to work as well as or better than the current model. With some guidance, the team identified Kanban as a potential alternative, and decided to try it out.

There are four particular guidelines agreed with the team that enabled this to work spectacularly well.

1  The art team stayed as an art team, meeting every day around the board and sharing successes and learnings together at the Sprint Review. Art skills shared with other game teams were also included in the team meetings as necessary.

2  The Kanban board visualized all the asset work to be completed, and broke that work down into the different stages of development, from concept work to final art to animation to audio to final assembly and integration with the game. This helped team members support one another and stay focused to get a particular asset or deliverable all the way across the board.

3  Work on the board was prioritized according to the commitment of the two engineering teams. That is, the highest priority work was directly tied to the expected deliverables of the engineering teams during their sprints. The art team actively participated in the planning, refinement and standup meetings of the engineering teams, and tracked the dependencies between art assets and engineering stories. The aim* of the art team was to deliver completed artwork to the engineering teams during the sprint so that the Sprint Review included a truly shippable product increment, including engineering changes and complete artwork.

4  The team worked to a Definition of Done for concept work, and a separate, more rigorous Definition of Done for final assembly. This was required to make concept reviews consistent and meaningful, so that a minimum level of content was available.

*This was not a hard and fast rule. Sometimes, there was considerable amount of artwork to be delivered once the engineering was complete – for example, think of the levelling up artwork for a building with seven possible upgrade levels. Each level requires considerable creative work, but little or no engineering work.

The result of Scrum engineering teams working in parallel to a Kanban art team was a Sprint Review every two weeks that delivered a working game (shared across the studio for immediate feedback directly after the Sprint Review). The art team was much more comfortable without the constraints of the Sprint, and able to build their own team dynamics driven by the needs of the game that maintained a focus on deliverables for the game, rather than functional areas of responsibility.

Finally, UX work – designing gamescapes and in-game environments, continued to be delivered in close coordination with the engineering teams, building out concept work ahead of the engineering teams so that the engineering teams knew what to build when they needed to build it. UX work, like architecture, requires a runway. Design work needs to be completed ahead of the sprints in which the concepts are built by the development team. This provides enough time for thoughtful and thorough analysis and, where possible, feedback of concepts or prototypes, before providing the development teams with well-defined concepts to build into the product.

In conclusion, as the level of creative work on a product increases, the structure of the cross-functional teams creating the product becomes less ideal, less likely to follow a single cross-functional team. The creative work may need to split from the engineering work. In our case, the teams evolved how they worked to best suit the skills and temperament of the small, cross-functional teams involved. The guiding framework was a clear focus on the game increment as a final product. Although the art teams choose to work using a different method than the engineering teams, the regular cadence of review was maintained – a game increment produced every sprint that included completed artwork. This resulted in iterative and incremental deliveries, combining work from both Kanban and Scrum teams. Regular delivery of a game increment, not how each team worked, is the defining constraint

Join us in Munich to celebrate 25 years of OOP Conference

/by

We are very happy to be once again a sponsor of OOP 2016 Conference in Munich, Germany, which celebrates this year its 25th birthday! The event will run from 1 to 5 February 2016 at the International Congress Center Munich (ICM).

OOP Konferenz 2016Over a quarter of a century, OOP has provided the platform for both technical and business professionals to update their knowledge and share their wisdom. Architects, developers, requirements-engineers, or testers as well as technical managers and leaders gain an excellent view on the state-of-the-art of the interplay of software and business. Year after year, OOP offers a succesful blend of Software Engineering topics, Testing Agile Programming, Management, RE and Testing topics. In 2016, OOP will look again into the future of IT but also reminisce about previous years and we’re proud to be part of this history.

Senior coach Andrea Tomasini will give his talk on February 3rd Stop Scaling… Start Growing an Agile Organization! in the Trends & Techniques track.

Insurance industry case study

/by

In business, significant organizational change is challenging, particularly for large, well-established corporations. Change of this nature involves a substantial investment and a level of risk. Yet, with today’s increasingly competitive market demanding faster, more efficient product delivery, even traditionally risk-averse businesses are making critical decisions to stay in the game.

Such is the case with a company in the insurance industry that began the transformation from a Waterfall project management method to an Agile approach in 2014 with the implementation of two successful pilot teams. When moving forward and scaling beyond these pilots required a more comprehensive approach, the company partnered with agile42 in the summer of 2015. Unlike other coaching companies, agile42’s Enterprise Transition Framework™ (ETF) offered a pathway to success, an important consideration for any company, especially one in a risk-averse industry.

A strategy session using agile42 approach

Today, with the help of agile42’s unique empirical approach and trademarked tools, the company, currently with seven agile teams and more in the immediate pipeline, continues to move closer to becoming fully agile.

Please contact our office for further information.