Category: Agile

The Four Types of Work in an Agile World

~ Adam ~ 4 Comments
NOTE: I’VE REVISTED THIS TOPIC MUCH MORE RECENTLY, IF YOU’RE INTERESTED ON HOW MY VIEWS HAVE CHANGED READ 4 TYPES OF WORK REVISTIED.

If you have read The Phoenix Project (which I highly recommend you do) you’ll be more than familiar with Eric who introduces us to the four types of work.

  • Planned Work – these are typically business projects or new features
  • Internal Projects – server migrations, software updates and so on
  • Changes – usually driven by feedback on already completed work
  • Unplanned Work – support escalations and emergency outages

In the book Eric talks about how Unplanned Work is unpredictable and destructive as it can often push out planned work. I can’t even begin to count how many times have I’ve planned in projects and tasks only for a crisis to arrive and my sprint to fail!

Managing a Product Backlog is an excellent way to handle three of the four types of work. After all, Agile Principles encourage us to collaborate with stakeholders, listen to feedback, and embrace change. The value of internal projects can be evaluated against other projects and then planned correspondingly and what is the backlog at all if not a prioritised list of Planned Work?

It’s the infamous Unplanned Work which continues to disrupt our Sprints, break our commitments and lower our productivity. Over a few years I’ve tried a number of different approaches to handling the inevitable Unplanned Work.

I’ve tried introducing slack into everyone’s sprint, only planning fifteen instead of twenty Story Points. I’ve tried allocating Support Tickets as they come in, assuming that the demand will cause our average sprint velocity to drop and the balance between Planned and Unplanned Work to find a happy equilibrium. It never does!

The only strategy I’ve found to work is to completely isolate the Unplanned Work from the other three types. Create a specific team (in our company we call this the SWAT team) who will react to all incoming unplanned work and “pitch in” with other work when there isn’t enough to do (Parkinson’s Law pretty much guarantee’s that this never happens).

The SWAT team handle the urgent, unplanned, and reactive work (often using a strategy like Kanban or Scrumban) while the rest of your team focus on delivering maximum value to the business (Sprints, commitments, and all the other wonderful concepts we hear about on Agile courses). That’s not to say they don’t fix bugs or take on internal projects, it’s that they work in a structured, planned environment in an effort to build solid releases and reduce the amount of Unplanned Work long term.

Speaking of Parkinson’s Law if you do decide to create this buffer between Planned and Unplanned Work (and I strongly suggest you do) you need to consider what happens when the work expands to fill the allocated time. What happens when the urgent support demands of the business exceed the capacity of your SWAT team? Hire extra people? That would be nice! But I can tell you what you must not do – DO NOT pass the extra work over into your Scrum team. I’ve made that mistake before and I can assure you that it’s a very slippery slope which is nearly impossible to come back from. Once you start roping in extra developers you undo your good work and Sprints start to fail once again. I mention it between I’ve seen it happen!

I hope I’ve given you some thoughts, I hope that my views on throttling the amount of damage your Unplanned Work can do help you safe your own commitments but I’d be delighted to hear your views – what do you to do safeguard your team’s productivity while meeting the urgent needs of the business? Post a comment below and let me know!

April Agile Yorkshire

~ Adam ~ Leave a comment

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!

Who Should you Share your Backlog With?

~ Adam ~ Leave a comment

I mentioned last week that I’d been to an interesting meeting discussing (and challenging) a few of the Scrum ideas. One of the questions we asked was about Backlog Visibility.

We all agreed that by making the backlog visible to our customers would invite feedback and reduce the likelihood that we’d spend time developing features which gave little value to our clients (see last week’s post on exactly what “value” is). But we couldn’t shake a distinct unease at making our plans visible, it took quite some discussion to articulate why this was.

Many customers and businesses work to project plans (ours included), they have long term visions of where they want to be and what they want to achieve. We realised with some trepidation that by sharing a fluid and ever changing backlog list of ideas with these customers it would create an expectation, which upon the next meeting would lead to disappointment as we had to admit the features we discussed were never in fact developed.

In an Agile environment we want to encourage this change, we want to update our backlog to remove unnecessary items and reorder the list to put the maximum value items at the top. However when presenting this to a client it could undermine us, particularly if the customer liked several of the items we ultimately decided to prune.

We decided that this is where clear communication is key. We talked about making it extremely clear that these were items we were considering working on and not a definitive product plan. A Development Forecast we suggested, after all – no one blames the weatherman if the reality turns out to be slightly different to our expectations!

What are your thoughts, do you share your Product Backlog with your clients? How do you handle their expectations that some work they are hoping for may still be cut?

Defining Value

~ Adam ~ Leave a comment

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!

Redefining User Acceptance Testing

~ Adam ~ 1 Comment

User Acceptance Testing or “UAT” is a critical part of any project. It’s where the customer takes your software into their environment, tests it and reports any issues which must be resolved before they take it into live. Development teams then resolve these issues, send the application for retest and (hopefully) get a signed off version.

I have a deep seated dislike of this concept.

I should clarify that I have no problem with customers doing their own testing – in fact I encourage it, we’re software professionals and don’t work in our application’s domain. High quality customer collaboration is essential if we are to produce a good product. No, what I have an issue with is the concept of a development, testing, and bug fix phase.

If Agile and Scrum techniques have taught us one thing it’s that we need to move away from “development phases” and towards continuous delivery with ever increasing value.

Leaving bug detection and resolution until the end of project is bad!

What then is the role of UAT in modern development methodologies? How do we achieve a signed off version without digging ourselves into these waterfall defined project stages we were supposed to have abandoned years ago?

By making UAT a continuous process alongside the development.

In my view as soon as a project begins, while the stories are still being written and the mock ups created the latest and greatest version of your application should be installed into the customer’s UAT environment. Then, while you’re working away creating the new features the stakeholders in your client’s business are testing the suitably of what you’ve already developed against their needs.

As you continue, Sprint on Sprint, Story on Story you can incorporate your client’s feedback (both bugs and suggestions) to deliver the best possible product at the end of the project. It’s only by presenting your build to the customer early that you can get this feedback. Forcing your clients to wait until your project is feature complete and signed off internally will create these heavy bug fixing phases we’re all working so hard to avoid.

Have you tried At Desk Testing?

~ Adam ~ Leave a comment

Last week I wrote about the value of finding issues early. How it becomes increasingly expensive and time consuming to fix issues the further down the development lifecycle you get. With that in mind we can now appreciate that anything we can do to find bugs earlier makes our software not only better but cheaper to develop.

Something we’re trialling at the moment are at desk demos. The idea is simple, before signing off a piece of work and passing it onto the next link in the chain (Dev to QA, QA to Support Analyst, Support Analyst to Dev and so on) you demonstrate the issue or feature to them.

For example, before I finish a feature and pass it onto someone who specialises in testing I invite my buddy over to “give it a bash”.

Remember last week? I talked about the time it takes to move from on link in this chain to another. I discussed how it can take a few hours to build your software, another hour or so to deploy it, and a day to run the signoff scripts (obviously this varies if you’re fortunate enough to be working on a ‘modern’ solution or have invested in some proper CI). Time moving backwards is time wasted, if you can avoid rework then you should always take the opportunity to do so!
By offering up my work to the QA for a few minutes before formally handing over can save hours of wasted time. These guys know what they’re looking for and can often find edge cases and give feedback on a few scenarios you’ve not considered. By having these pointed out to you early you’re saving all this extra time!

The same theory can be applied to a Support Analyst demoing bugs to a Developer rather than just recording replication steps on a ticket or a Developer showing a bug fix to the same analyst before shipping it to a customer’s UAT environment for testing.

So far it’s working well for us. Do you demo before handing over? Do you feel it works for your team?

Agile Planning vs Planning for Agile Teams

~ Adam ~ Leave a comment

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!

Continuous Delivery at the Supermarket Checkout

~ Adam ~ Leave a comment

To explain the reason for this post I should probably take a step back and explain that I’m currently fascinated with system design and the idea of workflow as described in The Phoenix Project and The Goal. I should also add (in case there’s any doubt) I hate shopping! So as Lucy and I were stood waiting in line on a particularly busy Saturday morning I had an epiphany.

Because I didn’t have anything better to do I mapped out the process in my head. The boxes on the left represent the customer, the ones on the right the cashier – at the end of the process they would tell me how much I owed and I’d dutifully hand over my money.

supermarket_flow

You’ve probably been involved in this process firsthand!

As I was loading my shopping onto the conveyor belt I couldn’t help noticing that the process wasn’t smooth. For a few minutes the belt would keep going, I was adding more and more groceries into the queue – then, for no reason I’d have to wait until more space became available.

I became convinced that if I wasn’t forced to endure this wait then the whole system would balance nicely, after all – the checkout assistant seemed to be able to scan groceries as quickly as I could load them (input and output were reasonably balanced). Then suddenly, frustratingly he would stop and complete the transaction with the customer and I had to wait for more space to become available.

In my mind the entire system mirrored a typical release schedule – features are requested, created, and released. The last part, the creation of a signed off build is often what holds up the process (either through bug fixing or code freezes) and that was exactly what I was seeing here.

Scrum practitioners advocate having a build which is good enough to ship at the end of your Sprint, this prevents large delays being caused in your process and helps make your deployments routine and safe. I’ve written previously about the quality benefits this can bring.

As I looked around me in the supermarket I began to wonder why there wasn’t a second person on the till. One could scan the items and the second would complete the transaction to ensure the workflow continued uninterrupted. That was when I realised that many have introduced something far more revolutionary!

Consider the new Scan as you Shop processes popping up around the country. These hand held devices let you scan your purchases as you work around the shop, this reduces the over complicated process above to this much simpler one:

kiosk

This simplified process reduces the need for staff and makes the entire end to end process far more efficient, there are even customer benefits such as being able to keep track of your trolley’s value as you shop. The supermarkets are so keen that they’re even willing to take financial risk on you not to steal their stock!

Tesco, by reworking their system have simplified their process and hugely increased bandwidth – I wonder if there are any similar process changes can we make in software development which will have such drastic effect our productivity?

*Thanks to draw.io for the flowchart software I used to create these images.

Scrum in a Remote Team

~ Adam ~ Leave a comment

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!

~ Adam ~ Leave a comment

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.