Scrum in a Remote Team

If you find yourself reading the Agile Manifesto (as for some reason I do from time to time) you may notice this:

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

I don’t think anyone would disagree with this. However in these days of satellite offices, home working, and outsourcing your team members are often scattered across cities, countries, and time zones you may not have the luxury of every team member sitting in the same room.

So what can you do?

There are a few tricks and tips I’ve found help you keep a high level of communication between team members.

  1. Ensure your daily standup times suit everyone. Make sure it doesn’t force people to start early or stay late, consider people’s lunch and prayer times. There’s no golden rule saying you must meet at 9am!
  2. Use tools like Trello to move post-it notes online.
  3. Keep a running channel open for informal chat (such as Skype or Slack) and switch important notifications onto email so people don’t miss important information.
  4. Work from home yourself, experience any pain points of your remote colleagues your are describing and aim to resolve them.
  5. Use video calling. We were a little reluctant to start this but after years of Skype the difference was noticeable, remote team members were more engaged and banter was at an all time high.

These are a few of the tips and tricks which have worked for us, what do you do to help your distributed team thrive?

Driving Technical Change Book Review

Driving Technical Change is a great little book who wants to understand how to influence different people in a technology organisation.

If you’re expecting a book on mind control then you’ll be disappointed. If you’re looking for a book which will explain why people react in particular ways to new ideas and technologies then that’s exactly what you’ll get.

Terrence Ryan discusses a series of personality caricatures. These are a little extreme, but you’ll be amazed at how closely they match up with people you know!

Then, the book discusses why these people may resist change or disagree with your proposals and how you can help to win them around.

For example, one of the characters in the book is “The Overworked”, this guy has far too much to do and never enough time. They can’t spare the time to pick up your idea, so how do you convince them? Show them how your project or proposal will save their time and help them complete their neverending pile of work.

I don’t want to plagiarise Terrence work, I’d much rather you picked up a copy and let him explain them first hand.

Would I recommend this book to someone working in a development team? Absolutely! Not just to help them drive powerful ideas forward, but also to help them appreciate other points of view – understand why The Boss, The Overworked, and The Burned may not necessarily agree with every suggestion.

Scrum Is Not Enough!

Let me start by saying I’m a big advocate of scrum (despite some of my posts in which I challenge it over and over again). Having said that it has it’s weaknesses (like any process), one I’m going to highlight in this post is the insular nature of some scrum teams.

The best way to explain this is to describe my own experience. When I started in the Scrum Master role I was very keen on continuous delivery and wanted the development team to produce a build every two weeks which could be supplied to the business to decide whether to deploy it or not.

We had a lot of projects on at the time and we were working very hard to meet the commitments my predecessor had signed us up to and get features out the door on time.

This went on for a month or two, we hit every deadline in the calendar and provided the builds to the deployment teams on the dates we’d agreed. So what happened? Nothing…

What I’d failed to realise was that despite our hard work over the last few months we’d failed to release a single new feature to a customer. The deployment teams had struggled to install our software into UAT and without any contingency (except when it was carefully planned for) we had no capacity to assist them or pick up any issues – until the next planning session of course (where usually the next feature was the most urgent due to “customer commitments”).

Development kept on working, features continued to be produced and deadlines were hit. But the customers were sat waiting, UATs couldn’t be completed (or in some cases even installed), and the business because frustrated with us because we weren’t available to help them get the product out the door.

So what went wrong?

This is where you may have to forgive my sleight of hand in the title. I don’t believe the problem was with the scrum methodology as such, merely the most common implementations of it. The first oversight was the handover, the second was the goals of the team. Let me explain…

Firstly the handover, the issue wasn’t that it was sloppy or that it we didn’t have consistent priorities across the business (although that certainly didn’t help). The issue was that we had one… A scrum team should contain all the skills and knowledge required to get a feature from concept to customer. Rather than handing builds over to the business to deploy we should have had someone from the deployment team working in the scrum team who would actually do the implementation. The team itself would then support the new feature through it’s UAT phases and out into the customer’s live environment.

The second failing I mentioned was the team goals. I have already alluded to this but the goal of the team was to “write this feature” whereas it should have been “deliver this feature to the customer”. Only once that goal has been met should they move onto the next one.

This continuity and accountability is a very powerful thing. Projects fail when departments don’t communicate with each other or their priorities are not aligned. Systems slow when there’s too much Work in Process (for example incomplete UATs) clogging up the pipeline and generating unplanned work. If you want to break out of this cycle you need to stop thinking about departments and handovers. Stop thinking of scrum teams as groups of developers delivering feature after feature and start thinking of projects being created and delivered by teams of people from all the disciplines you need.

If you can do that, then you can make your scrum team work for the business and not only for it’s own productivity.

New Years Resolutions

I’ve never been much good at keeping resolutions, they start out strong but then quickly slide.

Let’s see if I can do better this year. Here are my New Years Resolutions:

Look at the Needs of the Business

Too often developers and development managers focus too much on the code and the features and not enough on the business they’re working within.

Mind blowing functionality is worthless if it’s not user friendly, performant, and deployed. I want to keep the goals of the business in mind and make sure that my (and my team’s) goals are aligned with them.

Dedicate Time Each Week to Learn

I’m a great believer in continuous learning, but it’s hard – particularly when there’s firefighting to be done or issues to resolve.

To help me continue to grow as a developer and a manager I want to allocate a little time each week to my CPD.

Get out the Office

I mentioned a few weeks ago The Importance of The Local Development Community so this year I want to make a real effort to attend Agile Yorkshire, Leeds Sharp and a DDD Conference!

I want to meet with clients, put in some face time, and understand how our system (both solution and business) works (or doesn’t) for them.

Find And Exploit Our Bottleneck 

If you’ve read The Goal or The Phoenix Project then you’ll have had this one drummed into you. People, teams, and businesses are systems… systems have constraints and bottlenecks, if you want your system to work optimally then you’ll need to find and exploit your bottleneck.

I want do do more work to analyse our Support System to identify the bottlenecks. It’s important for me to understand the big picture. Goldratt tells us that any improvement made anywhere other than the bottleneck is wasted effort, I need to make sure I’ve examined the whole system – customer to customer, if I want to add real value to the business!

The real challenge here will be what to do if the bottlenecks are not within the development team…

Scrutinise Our Signoff Process 

Your signoff process is your last chance to avoid walking into a crisis. Finding bugs is not about luck, it’s about procedure and diligence- I want to continue to give ourselves the best chance possible to find those those showstoppers before the customer!

 

So those are mine, what do you think? What are your professional New Years Resolutions?

What I Read in 2016

This post is shamelessly inspired by John Sonmez’s blog post Books I Read, seriously 72!? I need to get an audible account! Here’s my list:

IT Related

Always space for some geeky books on my shelf!

The Phoenix Project

img_0319

This is possibly the most important book IT managers can have on their bookshelf at the moment. The Phoenix Project illustrates how systems thinking can be applied to IT and shows you how futile software development is without it. If you’re going to read one book in 2017 make it this one!

The Goal

220px-the-goal-bookcover

An oldie but a goodie, I did a book review on The Goal recently and I have to say. Once you’ve read The Phoenix Project if you want to go a little deeper then this book is absolutly essential!

Rolling Rocks Downhill

img_3736-1

This is a book I’ve quoted from several times before, Clarke came to speak to us at Agile Yorkshire and I made a point of picking up his book. What I love about this book is how Agile ideas are developed as solutions for problems the team is having, rather using methodologies and presenting them as solutions to your problems.

5 Disfunctions of a Team

dysfunctions

This one was recommended to me via a colleague, it’s a great quick read and essential reading for anyone works in a team (therefore pretty much anyone). I’ll do a review of it sometime soon, recommended reading!

 

Personal

Although my wife doesn’t believe it I do occasionally read books which are not work related!

The Mermaid Singing

516xlezdovl-_sx330_bo1204203200_

My wife reads dozens of books where people are brutally murdered and has always encouraged me to do the same. While we were on holiday she talked me into reading a the first of Val McDermid’s Tony Hill series and I have to admit I loved it. I’m reading The Wire in the Blood already!

Divergent, Insurgent, and Allegiant

divergent-series

I actually really enjoyed these, I’ve seen the Shailene Woodley films on the shelf at the supermarket and have held off on buying them until I’d read the series. I’d expected another Hunger Games or Twilight Saga and while I wasn’t too wrong I loved the idea of the factions system. A good read, loved the twists and thought the big series twist was inspired.

 

8 books, nowhere near John’s 72 but still a good list. What have you read this year? Anything to add to my list for 2017?

 

The Goal Book Review

I recently finished reading The Goal by Eliyahu M. Goldratt. This is the book which is referenced in The Phoenix Project and Rolling Rocks Downhill so I was determined to get my hands on a copy and read it!

Alex Rogo is a Plant Manager, work isn’t doing so well… in fact he’s been given an ultimatum and is about to get shut down. In order to save his job he enlists the help of an old teacher who persuades him to question the standard measures and processes he’s been using his whole career.

What follows is a very interesting and in depth look at the Theory of Constraints (although I don’t actually believe the term is used in the book) as the team try to identify the bottlenecks in their plant and work on ways to exploit them.

Like the best books Eli doesn’t try to throw too many concepts at you, his message is clear – find the bottleneck and organise work around it. There are some great analogies (such as Herpie leading his fellow boy scouts through the woods) and you genuinely feel like you’re working these problems out alongside Rogo.

The last few chapters felt a little disorganised to me but they they carried an important message – build up the process of how to examine your system, don’t just rely on a defined step by step guide. Continuously review, understand, and adapt.

Would I recommend The Goal to other IT Managers? Absolutely! You’ll gain a great understanding of how to observe and measure your team’s throughput.However, I’d say it’s absolutely essential for anyone in software development to read The Phoenix Project first so you understand why we’re looking at manufacturing plants to help us run IT departments!

When and Where to Automate Testing

A year ago I undertook an interesting piece of R&D to write Selenium tests for our main UI. I watched the pluralsight course, learned the difference between WebDriver and the IDE, and started building my Page Object Model. My simple test took the best part of three weeks to build and executed in around half the time a decent QA would take if you gave them a double shot of espresso.

I patted myself on the back, demonstrated the work to our Product Owner, and then advised that we should shelve the work because I wasn’t confident to hand over the mind boggling complexities of waits, framesets, and inherited view models into general practice.

Over time I lost confidence in the project. If it had taken me days to generate even the simplest of tests how would a junior developer fair when asked to automate complex financial scenarios. Quietly I put the idea to the back of my mind and concentrated on other more pressing matters.

That was until last week. We’ve been doing some work on our BACS integration and as part of the regression test I’d enlisted the help of one of our QAs to mock each response code and import it into the system. The process was tedious, repetitive, and I hated myself when I had to tell him he’d missed a vital check off each scenario.

As I was speaking to him cogs in my head began to turn. I’d gone off the idea of large scale test automation because of the complexity of our UI but the BACS processing system doesn’t have a UI. I could knock something together in a couple of hours which would create customers, mock BACS files, and schedule our JobServer. Even more powerful, if I used a technology like SpecFlow our QA could write the tests he wanted, I could automate them, and we’d be able to iterate over every scenario within a couple of minutes. Even more exciting was the idea we could send the feature files off to our Product Owner and banking partner and ask them to verify the behaviour was correct.

Later that week, after we’d proven our project to be a success and found a handful of low priority bugs to be corrected I started to wonder why this automation project had delivered such value where the previous UI automation had failed. I decided this was because:

  • The BACS process was an automated mechanism already so the test automation steps were simpler
  • The UI had been designed for human use, it wasn’t a chore to run through but it was complex for Selenium to navigate the controls
  • Mocking and importing BACS files was repetitive, slow, and tedious

The project turned out to be a huge success, we’re already planning on how we can expand the solution to cover other payment integrations such as SEPA.

The next time you’re considering whether or not you should automate an area of testing consider the nature of the tests. Do they use complex UIs? Do you have to repeat very similar tests over and over again? Do they currently take up a large portion of your testing cycles?

Try to automate the hidden process which run over and over and you wished you could test every time if you had the time!