Agile Coaching

Is Working Outside-In Always Better?

On Sunday, I went to GOOS Gaggle, a micro-conference on the development ethos described in  "Growing Object-Oriented Software Guided by Tests", the new book written by XP stalwarts, Steve Freeman and Nat Pryce.

After the main presentations, we moved into Open Space format. I joined a conversation with John Daniels and Willem van den Ende about "Why Start with End-to-End Tests?". Although we agree whole-heartedly with this, John was interested to explore whether this approach is always a good idea? You can read John's write-up of our conversation on his blog.

John starts by writing this up on the board.

When you start solving a problem from the outside, you ensure that inner workings connect to the real world setting. You start to grapple with all the interfaces to the system from user interface to the back end activities of logging and persistence. An excellent way to flush out any issues that might catch us out and require rework later on.

 
We wonder if the reason working outside-in and creating end-to-end tests is the simplest way to ensure we tackle risks early. John suggests that the biggest risk on some projects could be in the inner logic, for instance if the project was based on running complex calculations. Maybe there are situations where an outside-in approach may not be the best one to take?

Then I rack my brain trying to remember past projects where we didn't start end-to-end. What were the barriers that stopped us doing this?

The first example I remember was back in 1994 when I was working on a broadband switch demonstrator. My company was providing the call-control component but we were working in a consortium where other companies were providing other components that we would interface to, such as a set-top box, etc. Message protocols were not agreed and the hardware was work-in-progress but we had a hard deadline to demonstrate the kit at an industry expo. We did the only thing we could to make headway. We made-up a reasonable message protocol and then worked against software stubs which piped in messages in our imagined protocol. When the real interfaces were revealed, we mapped them into our own internal protocol, on the way in and out. This worked really well for us. We made the trade show deadline. Another example is more recent. A team I am coaching are building on some content-management infrastructure being developed by another department. It's not ready and they've been trying to work out whether to: wait, work on other features, or build their own solution using existing infrastructure.

Realistically, sometimes you need to make a start without having full end-to-end picture.

Our worry is that sometimes teams may prefer the "path of least resistance" because it's easy or they're naive about integration.

However, we ought not to forget that sometimes the biggest risk is organizational politics. It can be important to demonstrate progress to get buy-in from key stakeholders. Scrum can be perfect for mitigating such risks. We work on tangible product backlog items that we can demonstrate every few weeks. This builds trust in the team's ability to deliver on their commitments.

Willem adds that it can be hard for a team to justify "technical" product backlog items that mitigate risk over juicy features with obvious business-value. The team can attempt to make the value of such technical items more obvious by linking them to the money lost in downtime when a site crashes or security is breached.

Another common approach is to pair a Business Product Owner with a Technical Product Owner for projects where there are lots of infrastructure considerations. John pointed out that there's likely to be a tension between long-term technology decisions and short-term project goals. This is where it can help to have a project manager facilitate decision making. Thus, you need a three-way balance (as in this sketch) rather than (as we see too often) the Scrum team kowtowing to Product Owner without speaking up on technical risks.

Perhaps one of the main values of the GOOS approach and working from outside-in guided by tests is that we are able to flush issues out early rather than attempting to anticipate them. Thus we avoid awkward conversations with a Product Owner about potential risks because the issues stare us in the face having driven them out with end-to-end tests.

Collaborative Writing Tips

Now our Agile Coaching book is published, I am often asked about the process that we used to write it.

Your first question is always: how long did it take to write the book? Not an easy one to answer. Writing a book is not one continuous activity. There are peaks and troughs of activity, while the book goes though the review and edit cycles, and the creative juices ebb and flow. Overall, it took us from November 2007 to August 2009 from start to finish---about the same gestation period as an elephant. A long-haul but we're both very proud to see our book in print and hear that people find it useful.

Budding writers are also curious about what it's like to work with a co-author. I want to share my experience of collaborative writing here, to give you some insight into how we work together. You may be surprised to learn that we had very little face-to-face time while writing the book. We live 100 miles apart with different work patterns so the book was essentially a distributed agile project.

We both have families and day-jobs to work around. So the book grew in staccato bursts of activity, as we snatched time where we could to work on it. Liz would write on her long London Underground journey in to work. Whereas, I get a real burst of energy after midnight and often worked like a night-owl into the early hours of the morning.

So if we were working asynchronously how did we pull our work together?

Selecting Tools

We like to keep it simple. Our collaboration tools of choice are Google Docs, which provides a shared writing space, and Skype for free voice calls, without webcams as that can be distracting. We're bound by contract to keep the details of Pragmatic Bookshelf hamster-powered technology confidential. Like us, you can find out some basics by reading their write for us info.

For our writing, we made our own choices. Liz has a Windows laptop and I work on a MacBook. I prefer to write without being distracted by formatting so I write in plain text using TextEdit or TextMate. I used Eclipse when comparing files in SVN. I have no idea what tools Liz used on her laptop, as we did not pair-write I never needed to know.

We also relied on good ol' paper and pen, free-writing often helps when you get blocked. I turn off all distractions like email, twitter, and skype and use ambient internet radio to get into the zone. I find going into a different room than my office helps too.

Plus I always had an index card in my handbag with snippets scribbled on it, such as ideas to include or books to reference.

Putting Flesh on the Bones

A book outline provides a basic skeleton but how do you put flesh on the bones? We agreed on several types of content:

• explanations of agile basics,
• true stories drawn from experience, which we fictionalized,
• worked examples with a fictional team (loosely based on people we've worked with),
• hurdles, typical challenges we've met and tips on how to overcome them,
• checklists - summarizing key points,
• personal opinions - "Liz/Rachel Says.." soapbox items.

We also created loose "acceptance tests" for various book elements. Here are some snippets from our tests so you can see how these guided our writing.

Each Section

• Starts at the beginning (i.e. doesn't assume too much knowledge)
• Has a purpose, and purpose is explained in first paragraph
• Relevance to coaching is explained in first paragraph
• Relates to the chapter purpose
• Relates to coaching
• Contains examples

Each Page

• Targeted at coaches
• Useful - I learnt something
• Practical - I can do it right now

Agile Mindset

I believe the big secret to our successful collaboration is that we both have a background as software developers using XP. Our shared belief in the XP values (below) provide a great foundation for working together:

• Communication
• Feedback
• Simplicity
• Respect
• Courage

From the outset, we agreed that we would practice Collective Code Ownership on our writing. For us, this means that we're both responsible for the whole book and either of us can change any part of the book. So we although each section starts with one of us writing a first draft, it will be edited by the other later on, and go through many iterations until we are both happy with the result.

At the start of each new chapter, we had a Skype call to brainstorm content captured in a Google doc. As a visual thinker, I would often create a mindmap for each chapter to help get my thoughts straight to help flesh out a chapter outline. Then we divvied up sections to work on separately based on experience and preference.

We set ourselves mini-deadlines to have specific sections ready for review at our next Skype call. Liz put together an electronic Kanban board, in a Google spreadsheet, which listed all the chapters and sections with current owner. The status of each section is shown in color-coded in columns matching our definition of done. We also needed to keep track of outstanding reviewer comments and editor concerns. I use Apple Stickies for my to-do lists and my immediate book-related tasks were pasted into a long blue sticky  that I could roll-up when I was doing other things.

A book is a team effort and we also worked with a wider team of agile folk. Our trusty band of reviewers kept us honest, and helped us to see weak areas to rework before the book was ready for publication. As new authors, we couldn't have written a book for for print without guidance on writing style and structure from our amazing editor, Jackie Carter. Our early drafts were dry and impersonal. Pragmatic Bookshelf helped us create a readable end-product by helping us learn how to polish up our own work. The book "Keys to Great Writing" by Stephen Wilbers became our writing bible.

Benefits of co-authoring

Do I recommend co-authoring to anyone considering writing a book? My answer is a big "Yes!"

Not only is a co-author an invaluable source of ideas and feedback. You can rely on a co-author to help you maintain momentum and keep you focused on getting the book finished. Liz has great drive and determination and her project management skills meant we never lost sight of our goal, to have our book out in time for Agile2009.

When we set out, Liz and I were naive about the effort required to write a book. We'd only met a couple of times at Extreme Tuesday Club in London before we decided to pitch in and work together. It was pure luck that we got on well enough to work together over such a long period of time. In hindsight, it would have made sense to pair on a smaller project to test out our collaboration skills.

My advice is if you're pondering an idea for a book, find a writing companion to help you on your way but try small experiments before going all in. Happy co-authoring!

Agile Coaching Beta release

Exciting news! Andy Hunt announced our "Agile Coaching" book is available as a beta book from Pragmatic Bookshelf

The basic book blurb is:
"Discover how to coach your team to become more Agile. Agile Coaching de-mystifies agile practices—it’s a practical guide to creating strong agile teams. Packed with useful tips from practicing agile coaches Rachel Davies and Liz Sedley, this book gives you coaching tools that you can apply whether you are a project manager, a technical lead, or working in a software team."

You'll find some excerpts from the book on the Pragmatic site so you can get an idea about what the book covers. The first one is from the chapter "Working with People" and gives advice about developing an essential skill for agile coaches, listening to people. The next excerpt gets into how to coach agile practices starting with Daily Standup meetings. Daily Standups appear to be simple to run but our experience is that most teams need to evolve away from the Scrum format after they've got the basic idea how to use the meeting to co-ordinate their work.

We want to let you know that it won't be in beta for more than a few weeks as the book is already "content complete" with the full set of chapters written. We're just going thru indexing and copyediting at the moment. We're hoping print copies will be available in time for the gathering of the agile tribes at Agile2009 conference where we're presenting two sessions on agile coaching.

We've been amazed at the huge wave of orders in the first 24 hours! Get your eBook now (available for PC, iPhone, Kindle, etc.) and you'll get the final eBook in a few weeks time.

Agile Retrospectives

At last we have a book available that gives tips and advice on facilitation of end of iteration retrospectives. Esther Derby and Diana Larsen have just published Agile Retrospectives: Making Good Teams Great. The book will be really useful to agile coaches and team leads who want to apply retrospectices in their teams. Plenty of exercises are described so that your retrospectives won't get boring and will continue to reveal process improvements that help your team optimize their process and stay sharp. This will become a well-thumbed trusty reference for agile teams.