Is Scrum anti Agile?

Is Scrum anti Agile?

When an organisation is moving from a top down process such as waterfall to an Agile methodology like Scrum, for the people involved it can feel like everything is coming off the rails. All the comfortable and reliable “process” is gone and now you really have to think. Change can be difficult and this type of change is no different.

When moving in this direction, a process or a framework is a safety net or a comfort blanket. If you are not careful people can miss the point of the Agile transformation and instead focus on the framework, methodology and tooling. Work management tools such as JIRA, which are a bit of a swiss army knife, can, if you are not careful, become another facet of the process safety net. Before long your work management tool is configured with so much “process” people have stopped thinking and any Agility that was blossoming in that organisation is slowly evaporating.

But let’s look at it from the other angle. Some small organisations have little to no process. From an outsider’s perspective, it looks like chaos but the reality is that these organisations have started from nothing and now have paying customers, so they must be doing something right.

These organisations might be looking to frameworks like Scrum to provide some stability and some predictability. They want to build on a successful foundation and grow without losing what made them special in the first place. So, you might look at implementing Scrum and related tooling simply to manage stories in a backlog. You might encourage using sprints to create a delivery cadence.

And then the backlash starts. In the same way waterfall practitioners think you are trying to take away their comfort blanket, so do the developers in the start-up that needs to mature. Whichever way you look at Scrum it has some rules. Okay, they may be called a framework but they are still rules. These rules drive home the point that to be stable and predictable you cannot have a free for all. The transforming organisation may start to realise that their current ways of working are not special and instead they need to conform with what the majority of the industry is doing.

In this situation, you must realise that processes or frameworks, even lightweight ones like Scrum, can be seen as a burden when transforming chaos into stability. While it might seem like common sense to you, the people undergoing the transformation may believe that agility is being lost, along with the innovation that got the organisation to that point in the first place.

 

Painting the Forth Bridge

Painting the Forth Bridge

They say that it takes so long to paint the Forth Bridge in Edinburgh, by the time the painting team have worked their way across the bridge, the paint at the start will need renewing, so they have to start again. This is of course, a myth, but if it were truth the workers painting the bridge would have a job for life.

Sometimes software projects are like this. They are in a state of perpetual rewrite. The rewrite may be needed because the wrong JavaScript framework was selected at the start so the team are moving to framework N which when completed will solve all problems. Or the application is considered a monolith so the team are “doing the right thing” breaking the solution up into Microservices. The “rewrite” is done with the best intentions but the outcome is often the same. The rewrite takes so long, that the IT world has moved on and now the goal the team is working towards is old fashioned and out of date, Fresh thinking is required, which triggers the next big rewrite and so the cycle continues, much like painting the proverbial bridge.

As professional technies, developers like solving the hard problems. They like using new technologies and the latest frameworks. However, it is a fact of life that most development work isn’t sexy or glamourous. Often developers spend a lot of time grinding out “business logic”, or fixing bugs. The work can become repetitive and boring. There is often a tension between the motivation to keep software development simpler and predictable through standardisation vs. a desire from the technical team to keep their skills fresh on the job.

For freelancers or developers working for software consultancies, getting stuck in one technical stack for a single project is not a problem. The next one is never too far away and it is likely to be very different. Change doesn’t come so frequently for those developers working in software houses. Typically they will be working longer terms on a smaller portfolio of projects and products. For software houses the economics are straight forwards, ship more products – make more money! Investing time in rewrites is a big challenge. Redirecting effort is large scale technical changes means they are not fixing bugs nor are they delivering as many features.

But if a product isn’t changing in pace with the technology landscape it is in danger of stagnating and becoming irrelevant. The software used to build it become out of date. The development team start to feel deskilled and may started to leave this business taking critical knowledge with them. It becomes harder to replace them as your technology stack is no longer attractive to the job market. Before you know it all the innovation that took you from a start up to a mature software house in the first place has leaked away.

As with everything there is a balance to be found. The development team need to be able to stay current but the organisation still needs to pay the bills. Here are a few things to look at to ensure that this balance is maintained.

Be aware of technical debt and pay it down frequently. This is simple really. The best way to avoid big changes in the first place is to fix problems soon after they occur. If they are left to mount up over time it become much harder to fix. Therefore, ensure that the team have the opportunity to fix things as part of the development process.

Ensure that the business value of large technical changes is understood. All work the development teams do should have a business value so ensure that this is understood when it comes to technical changes. There are often valid business reasons for changing from framework X to framework Y, but it is often hard to articulate. There is a temptation to avoid identifying the business value because it is hard to do, and instead the change is delivered as a side project or worst as someone’s pet project. Avoid this temptation as the term “side project” implies a lower priority so it is likely to be pushed to the side when your important customers are hammering down your door asking for the next great feature. Technical changes and evolving architecture is just as important as new features and so all the work should be in the same pot. The Product Owner must be given the hard problem of deciding whether to improve the system itself or deliver new features.

Ensure that large technical changes are delivered as a series of steps as part of a roadmap. Agile development is based on short feedback loops. This is no different when it comes to technical changes. Therefore, a big change should be broken into a roadmap. At the end of the roadmap is a goal and a vision, and at the beginning is a next few steps to get there. The idea is that you don’t create a detailed plan. You might only define the next few steps. This approach also allows the goals to change with little impact. It should be easy to get started as there is no long planning exercise which also means there is no temptation to follow through on a now invalid plan simply because too much cost has been sunken into the planning exercise.

Speeding up Azure Cloud Service deployment in Octopus Deploy

Speeding up Azure Cloud Service deployment in Octopus Deploy

This post is a brain dump of something I discovered working with Azure Cloud Services specifically, when deploying them to Azure with Octopus Deploy.

In the beginning.

Cloud Service deployments have been designed by Microsoft to provide a seamless upgrade experience.  If your cloud service infrastructure comprises of multiple cloud service instances, than the fabric controller in Azure which controls deployments will perform a rolling upgrade. The underlying instances will be gradually upgraded until all are done. When you are deploying to a production slot this all make sense. You want to avoid down time, you want to minimise impact for your customers. However this convenience comes at a cost – time. If you have a large number of Cloud Service instances and web roles the process seems to take for ever.  That is the last thing you want if you are watching over a Live release in an evening.

What other choices are there?

In some deployment scenarios you might deploy to the staging slot of the Cloud Service, do all of your testing and then perform a slot swap to get this version into Live. In this case you don’t want to incur the cost of a rolling upgrade as customers don’t use the staging slot.

The Cloud Service upgrade documentation talks about a deployment mode called Simultaneous. Unfortunately there is not a lot of documentation around that describes what it does. This Stack Overflow question highlights that simultaneous mode is referred to as BlastUpgrade in the topologyChangeDiscovery attribute in the Cloud Service’s Service Definition File. What I determined by experimenting is that in this mode, the fabric controller ignores all upgrade domains meaning all instances are upgraded at once. This was a lot quicker and exactly what I wanted when deploying to Staging slots.

So the obvious answer would be to update the service definition file? Wrong! This didn’t work with Octopus Deploy so I was faced with looking for other options. This led to an investigation of how Octopus Deploy actually deploys Cloud Services. I found that it uses this script by default.

function CreateOrUpdate()
{
    $deployment = Get-AzureDeployment -ServiceName $OctopusAzureServiceName -Slot $OctopusAzureSlot -ErrorVariable a -ErrorAction silentlycontinue
    if (($a[0] -ne $null) -or ($deployment.Name -eq $null))
    {
        CreateNewDeployment
        return
    }
    UpdateDeployment
}

function UpdateDeployment()
{
    Write-Verbose "A deployment already exists in $OctopusAzureServiceName for slot $OctopusAzureSlot. Upgrading deployment..."
    Set-AzureDeployment -Upgrade -ServiceName $OctopusAzureServiceName -Package $OctopusAzurePackageUri -Configuration $OctopusAzureConfigurationFile -Slot $OctopusAzureSlot -Mode Auto -label $OctopusAzureDeploymentLabel -Force
}

function CreateNewDeployment()
{

    Write-Verbose "Creating a new deployment..."
    New-AzureDeployment -Slot $OctopusAzureSlot -Package $OctopusAzurePackageUri -Configuration $OctopusAzureConfigurationFile -label $OctopusAzureDeploymentLabel -ServiceName $OctopusAzureServiceName
}

function WaitForComplete()
{

    $completeDeployment = Get-AzureDeployment -ServiceName $OctopusAzureServiceName -Slot $OctopusAzureSlot
    $completeDeploymentID = $completeDeployment.DeploymentId
    Write-Host "Deployment complete; Deployment ID: $completeDeploymentID"
}

CreateOrUpdate
WaitForComplete

You’ll notice calls to Set-AzureDeploymentwhere the modeparameter is set to Auto.However the documentation for this powershell cmdlet states that the optional mode argument can be set to Simultaneous. How do you get Octopus to do something different. Luckily if you drop a powershell script called DeployToAzure.ps1 into the root of the package you are deploying , Octopus will use your script rather than its own. Therefore you can adjust the script to look like this.

if ($UseSimultaneousUpgradeMode -eq "True")
{
    Write-Verbose "Using Simultaneous Upgrade Mode"
    Set-AzureDeployment -Upgrade -ServiceName $OctopusAzureServiceName -Package $OctopusAzurePackageUri -Configuration $OctopusAzureConfigurationFile -Slot $OctopusAzureSlot -Mode Simultaneous -label $OctopusAzureDeploymentLabel -Force
}
else
{
    Set-AzureDeployment -Upgrade -ServiceName $OctopusAzureServiceName -Package $OctopusAzurePackageUri -Configuration $OctopusAzureConfigurationFile -Slot $OctopusAzureSlot -Mode Auto -label $OctopusAzureDeploymentLabel -Force
}

Where $UseSimultaneousUpgradeMode is an Octopus variable that can be used to control which mode is used when.

One word of warning. You see the function in the script called WaitForComplete()? This is used by Octopus to determine when the release is complete. It works by querying the relevant AzureDeployment. I have found that this reports back as complete before the Cloud Service instances have upgraded. And if you were to swap from Staging to Production whilst they were still upgrading… oops you have a temporary outage. So if you are doing this remember to physically check the status of the staging deployment before swapping.

Never ending stories – Agile Anti Patterns

Never ending stories – Agile Anti Patterns

The Never-Ending Story was a 1984 fantasy film about a boy who reads a magical book that tells a story of a young warrior whose task is to stop a dark storm called the Nothing from engulfing a fantasy world.  Apparently it was quite good but all I can remember about it is the large white flying dog like creature.

The Never-Ending stories I am more familiar with are those in Agile projects that start out as something that is assumed to be quite straight forwards but then generates much more work than was expected and before you know it, not only are you carrying it forwards into the next sprint but it starts reoccurring in multiple sprints. So, what are the characteristics of a never-ending story.

A story really represents a feature and as such becomes a bucket for all areas of functionality related to that feature

Agile is about reducing feedback loops in order to build confidence that you are always working on the most important thing at any given moment. Often never-ending stories internalise that feedback loop. Maybe the story represents a new area of a solution. You don’t what to do too much up front design or suffer from analysis paralysis so you have a story that enables you to try a few things out. This is reviewed with the Product Owner and the rest of the team which generates new ideas which is new work.

There is nothing wrong with this description so far, however a never-ending story emerges when that new work is added to the original story. Often this is coupled with a feeling that no one really knows what good looks like. The team starts to feel like they are working towards a moving target. It will only be a matter of time before the “When will you be done” questions start. Think for a minute about how it is possible to formulate an answer. Every time the team asks for feedback, more work is generated and so the goal has changed. Yet they are asked to say when work, which they may not know about yet, will be complete.

Work is blocked by external dependencies

Sometimes someone outside the team has a stake on when a story is complete. It may be that you are integrating with a third party and they have onboarding activities. Perhaps there is an external customer that has a final say on whether the work has been delivered to the necessary standard. The important thing to realise is that you cannot control this decision making and it is highly likely that your timescales will not align. The best thing to do is to accept it and then put in controls to minimise the impact on you.

There are a couple of things you can do to take control.

  1. Understand the requirements of the third parties upfront and ensure that this is factored in when creating the stories in the first place. This may feel like up front design but you are doing just enough to mitigate the risk of a delay in the future.
  2. Don’t “leave the bonnet open” on work whilst it is outside your control. Deal with feedback whether that is good or bad as new work coming into the backlog and deal with it on a priority basis.
  3. Minimise external dependencies by only having them when you absolutely can’t avoid them or where they add value to solutions you deliver.

Quality defects stopping work being completed

In this situation, the work has been done and the team’s tester is working on it only to find a quality issue. The story goes back to the developer to be fixed. Subsequently the tester picks up the work only to find more issues and repeat.  When this has been happening for some time, e.g., it is a reoccurring theme in multiple stand ups, the team needs to try to understand why things are bouncing around between two team members. Are the developer and tester working together on the story or is the developer “throwing the work over the wall”?  Are the defects being raised related to the changes being made under the story in question or are they coincidental. Are the developer and tester on the same page as to the quality metrics for the story?

So what?…

Never-ending stories are bad because they harm your team’s predictability. They are a black hole, they consume effort and people. No-one in your team is really sure when they will be complete. If you are working on one it can be very demoralising. Personally, I am motivated by finishing things but never-ending stories can really feel like a ball and chain, never allowing you to finish and never enabling you to move on to other things.

When you look at the examples I give there are a couple of ways to avoid never ending stories

Firstly, ensure that you are aware of the work that is being created. Whilst it is normal to create some new work when delivering stories, you need to decide the point at which you need to call it out, surfacing it as new work in the backlog and letting the PO prioritise it rather than absorbing it. If you are not doing this during a sprint, maybe when the story is carried over at a sprint boundary, this would be a good time to ask yourself if the story should be broken down.

Secondly many of the problems with defining the scope and boundary of a story could be resolve by investing time in defined acceptance criteria at the start. You may use a Story Kick-Off for this. The acceptance criteria could describe how the story should function, they define the quality criteria for the story and the expectations of third parties. And let’s not forget that we should be aiming to avoid large stories, breaking them down along their natural seams in order to keep your team predictable and high performing.