April Agile Yorkshire

I managed to get a seat at Agile Yorkshire this month, I’ve missed a few of these recently partly due to other commitments but also the sheer popularity of these events.

Royd (from NewRedo) organises and coordinates these evenings, this week he’d arranged for Chris Cheadle and Sean Craig from NHS Digital and John Le Drew who runs The Agile Path to speak to us.

Chris and Sean went first, they spoke to us about an event they’d run a little before Christmas. They’d called it Firebreak, during a two week period almost the entire organisation downed tools and worked on “whatever they wanted”.

They’d started with almost a kickstarter approach, people posted ideas on postit notes and their colleagues pledged their time – once a project was fully resourced it was banked and it would go ahead.

I love the idea of this sort of thing, really opening the doors to let teams work on what they want – what they feel wild make a difference. Anything from process improvement to a proof of concept or a piece of server maintenance. It certainly seemed to be a positive experience for the NHS team, some of the projects saved thousands of pounds on licence fees!

The second talk of the night was about Safety and how important it is to effective teams.  John explained that he considered safety to be “free to make suggestions, give feedback, and make mistakes without fear of punishment or humiliation.”

For me this feeds into the fundamental requirement of trust which Patrick Lenconi described in his book Five Dysfunctions of a Team. He postulated that without trust (or in John’s words safety) teams would not challenge each other and discuss ideas.

John had a few examples of this, my favourite was a role play exercise where three characters were so determined to avoid taking the blame for pressing The Big Red button which would overload the nuclear reactor they refused to cooperate to press the three buttons which would save them. Contrived? Perhaps… but it makes the point that if you are scared to look foolish then you’ll naturally be less confident to make suggestions.

Something which did niggle me was the idea of accountability, as managers we need to hold our directs responsible for their performance but this is challenging without undermining that feeling of security. In Lenconi’s book he encourages the team to hold each other accountable, finding the balance between a blame culture and safe, self motivating team is a difficult balance to find!

I’d certainly recommend listening to John if he’s speaking in your area. At the very least I’d say every manager should hear his views about engagement and workplace stress! I for one will be listening to his podcast.

It was a great night, as I’ve said before I’d always suggest Agile Yorkshire if you’re a Leeds based  geek!

Defining Value

I was recently at a talk where one of the key topics was “Defining Value”. I actually felt rather prepared for it – after recently reading The Goal I was fairly confident that the goal of any business was to make money. So “Value” would be anything which either earns us revenue or aids in our ability to make money.

It sounds boring, but it’s true.

My point actually kicked off a lot of discussion, in a room of experienced developers the proposal that unless we’re earning money we’re not adding value was rather controversial “what about paying technical debt!?” was one of the initial reactions (and one we came back to very quickly).

Delivering maximum value is of course what Scrum is all about, the idea that the team is constantly working on the most valuable piece of work is key to the sprint framework. So to be challenged to define value was an interesting idea, especially when Pete (our facilitator) threw out the following quote things became interesting:

“As a general rule of thumb, when benefits are not quantified at all, assume there aren’t any” – Tom DeMarco and Timothy Lister

With paid for work the value is often clear, the work is worth whatever the customer is willing to pay for it. Again, work to generate sales the Product Owner can list the contracts which will be opened up by a particular feature if it was to be implemented.

Support work becomes much harder. We all know that it’s easier to retain an existing customer than to earn a new one and anyone in sales will tell you the value of upsell and good customer service. So how do we justify spending hard pressed development resource fixing bugs, answering questions and supporting our existing customers when it does not earn us any revenue?

We all agreed that the only way to quantify the value of technical debt was to look at how much time and effort was being spent in supporting it. If an area of your software is full of bugs and you spend four days of each month assisting customers using it then over the course of a year it’s worth at least forty eight days to improve it!

Support work is valuable because by not doing it you’re putting your customer’s loyalty to you at risk. Reducing technical debt is valuable because it makes support work easier.

The next time you’re working in an unloved area of code, don’t moan about it – measure it. Present the business case to your Product Owner and help them quantify the value of refactoring and improving the code. It will make it a lot easier to justify doing the work!

Agile Planning vs Planning for Agile Teams

I’ve been reading Agile Estimating and Planning by Mike Cohn recently, one of the ideas introduced in the first couple of pages is that Agile Planning is very different to planning an Agile Project.

Mike explains that as you progress throughout the project the amount of uncertainty diminishes. He calls this the Cone of Uncertainty and argues that you should continuously revise your plans as you revise your priorities.

In an agile project change is embraced and priorities are adjusted so the team are always delivering maximum value to the business. The idea of agile planning is that your plans should develop as this uncertainty reduces.

For example:

  • Sprint 1 – We estimate this is about 12-18 weeks’ worth of work
  • Sprint 2 – we’ve done some of the initial R&D and underestimated several of the user stories. We now believe the total project will take 22 weeks
  • Sprint 4 – We’re happy with our 22 week estimate at the moment but we’re getting into some of the big refactors at the moment, we’ll confirm in a few weeks
  • Sprint 6 – the majority of the work is behind us and we actually got some quick wins. We are now aiming to deliver on the 20 week mark
  • Sprint 8 – we’ve mostly finished and will be delivering on the 20th week
  • Sprint 10 – your install will be on Tuesday 15th

As you can see progress reports and updates are continuously being fed back to the stakeholders but these are updates and estimates which refine with time rather than hard deadlines before the work has even begun.

I’m very intrigued by this idea. I do have my concerns how it would work when delivering to a 3rd party – several of our customers pull large testing teams together for UAT testing of our software. I’m not sure how they’d react to a “it’ll be 12-18 weeks” but I’m certainly interested enough to continue reading!

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?

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?

The Importance of Testing Early

I recently had a conversation with a Development Manager at a company based in Leeds. We were discussing when to involve the QA Team in a release we were planning, I argued that there was little value in wasting the QA guys’ time until we were feature complete. After all, everything was still subject to change and they’d only have to repeat those test again at a later date.

Ironically I now hold the opposite view.

If you walked up to me today and asked at what stage of development you should bring QA resource into a project I would always advise that as soon as the developers start coding it’s too late.

Your QAs are not automated test machines, I can crank out a few Selenium scripts to test a UI during my lunch hour! Your QA team are there to ensure that the features you deliver are the highest quality they possibly can be. So when does quality begin? I would argue in the design phase!

I’m currently working with a QA who, for a variety of reasons is trying to work out all a feature’s permutations eighteen months after the design was originally done. He’s documenting these, generating Functional Tests for them, and raising bugs where required. This is incredibly time consuming and takes lots of time from him, a development resource, and the Product Owner. Imagine if he’d had the opportunity to work this out before development work had begun!

The key here is to allow you Product Owner, QA, and Developer to create the spec together. The developer sets to work and the QA begins creating their functional tests, as soon as the feature is code complete your QAs are ready to go!

So, my original concern was that our testers would have to continue to test over and over again. Yes, this is a risk, however, when would you rather be alerted to any issues… as the developer is adding finishing touches, lining up buttons and tidying Unit Tests, or six weeks after they’ve finished? I know which I’d prefer!

This is where the distinction between Functional Tests and Signoff Tests becomes important. Functional Tests are used to test every permutation of a feature, to verify it against the spec, and to perform regression testing after substantial change. Signoff Scripts are to protect your critical functionality. Use your Functional Tests early to ensure that the newly created feature behaves according to spec, use your Signoff Scripts to verify your functionality before a release.

Get your QAs involved in your spec documents, organise your Sprint so they create tests while the developer codes, and get timely feedback on your features while you’re still in a position to fix them.