Posts Tagged ‘agile’

My new course is out, teaching Scrum agile project management framework. Inside the course, you will earn:

• Artefacts: product backlogs, sprint backlogs and definition of done documents
• Ceremonies: Daily Scrum (stand-up), backlog refinement, sprint planning, retrospectives, ways of working meetings, wash-ups and sprint reviews
• Estimating points, velocity and agile poker
• Team roles including product owners, scrum masters and stakeholders
• Team psychology including psychological safety, coaching and best practice
• Agile requirement gathering, user stories, tech debt, prototyping and user labs
• Agile release management, continuous integration and continuous delivery
• Scaling scrum beyond a single team with product splitting and Scrum of Scrums

You can preview the course on Udemy.

What do you do if you need to scale your Scrum team? Ideally, have multiple teams and use one of the many fine methods for scaling with multiple teams. But what if you want to scale a single team? To say, 30 people?

This was the situation I ran into with a recent client. They had an important project and lots of money to throw at it, and they wanted it all to be one team.

You might think “but there is no way that could possibly work”. And you would be correct. It didn’t work that well. But, having no other option, we did find some hacks that made it easier. I’ll present these below.

Kim’s Corners

Doing a stand-up with 30 people is tough. You might think it took ages. But it didn’t. We got done in 15 minutes. There were so many people (in a special meeting room we had to book every day) that people kept it short and sweet. From that point of view, it was a good learning experience.

But it wasn’t useful. There was so much stuff going on that nobody could remember what everyone else has said. Most people did not even try. They just tuned out for most of it.

So, we moved to Kim’s Corners. Each workstream had a corner and we went around one corner at a time. The people in that corner listened to each other intently, while only taking a high-level overview of what the other corners said.

Goldfish Bowl

Having a retro was also challenging because there were so many people wanting to weight in. To solve this, we used the Goldfish Bowl technique.

This involves having five chairs in the middle of the room. Four people sit on them, with one empty chair. Everyone else sits around in a big circle. Only the people in the inner chairs are allowed to talk on the topic at hand, and the discussions are time-boxed to five minutes. The group can vote to allow another five minutes if required.

What if you are sat on the outside? You go into the circle and claim the empty chair. At which point, someone from the inner circle is obliged to get up and go back to the outer circle, freeing up a chair to be the new empty chair. Anyone who has a strong opinion can take a chair, but without too many people talking at once.

Refinement Lucky Dip

30 people were too many people to have sat around looking at a Jira board and pointing stories up. So, we used a lucky dip system in which five people were randomly selected to attend backlog refinement sessions.

Anyone else that particularly wanted to be involved, perhaps because they had the a specific knowledge or interest in a piece of work that was upcoming, was also welcome to attend. But they were not required or expected to attend otherwise.

You’ve no doubt heard of us at Glorry, the exciting Silicon Valley startup that is taking the world by storm. We’re best known for raising £17 billion in funding on Kickstart in less than 38 minutes, despite having no discernable business model. Still, that’s what they said about Instagram and look who is laughing now. Mark Zuckerberg, that’s who.

We’re pushing the limits of Agile delivery to see how we can deliver the most value to our customers. But our Service Delivery team are also looking to ensure a consistent and stable customer experience that doesn’t allow new features to compromise on quality.

The result is a methodology we’ve called “No-Release” and I’m excited to share some details of it with you today.

What is No-Release?

Simply put, we don’t release any code.

What are the results like?

They’ve been outstanding. Since we adopted this approach, we’ve had zero bugs introduced to the live system. That’s not a misprint: zero bugs. Not one single incident has been released related to the new code we’ve been writing.

Since adopting this approach, our velocity has increased. Developers feel more confident that their work will not cause issues in live. Product Owners are happy to prioritise tech debt because they know it won’t delay new features arriving in live. Service Delivery is less jittery about degradation due to changes to the product.

How does it work?

We based our workflow on a traditional Scrum methodology. We operate in two-week sprints with a backlog of features prioritised by the Product Owner. Each ticket begins with a Business Analyst sitting down with a Developer and a Tester to work out how we can deliver and test the acceptance criteria of the ticket.

When a ticket is complete and signed off, including going through our continuous integration pipeline where a series of automated tests are run, we then merge the ticket into our develop branch. At this point, the ticket reaches our Definition of Done and we can close it.

Our master branch contains a copy of the code deployed to live, while our develop branch contains all of the new features. Because we operate under No-Release, we almost never have to deal with merge conflicts because we never merge develop into master. Or anything else for that matter.

What are the drawbacks?

One of the biggest drawbacks to No-Release is that you do not release any code. This means that no new features and improvements ever make it to the end user.

Making this work requires buy-in across the organisation. Without everyone being on board you can easily get developers saying “this is pointless, what am I doing here” every stand-up, and upper management suggesting they can fire the entire team and get the same results for much less money. Therefore, it’s important to get everything to embrace the methodology before starting.

Each organisation needs to make its own decision as to whether this drawback is acceptable to gain the benefits discussed above.

Conclusion

No-Release methodology allows you to increase your development velocity while eliminating any risk of service disruption to the end user.

As a software consultant, I spent a lot of time going into big, slow-moving organisations with legacy software and helping them sort it out. One persistent feature of these organisations is regular but infrequent releases of their platform and a fear of moving to anything more rapid.

By infrequent, I mean they might release a few times a week (Tuesday and Thursday are fairly common), or maybe each weekday, or maybe even just once a week. In the world of agile, all of these schedules are infrequent. Modern, agile platforms release constantly.

Typically, these companies will be afraid to move to anything more agile because they have a system in place and they think that it works. They say things like “we can’t risk continuous delivery (CD), people depend on our platform”.

This, in my view, is a mistake. And in this post, I am going to set out the reasons why it is safer to use CD. Not why it is better for the product owners, makes more money and keeps your developers happy, though those are all good reasons. I will make this case purely from the view of change management and their worry that it will damage the integrity of their system.

Big bang releases do not work

The old model involves people from every team merging their code into a release branch, that branch being put on a staging environment and then manual tests being run against this.

This is a terrible way to do things. As everyone merges in their code you get conflicts. Some of which will be resolved correctly, some will not.

The changes interfere with each other in ways that you cannot predict and there is just too much ground for the manual test engineers to cover.

Worse, when everything does break because you have pushed 20 features live at the same time, it is then really difficult to do anything about it because you have to check whether you can roll back, then check whether there is anything critical that needs to go out, then do a fix branch or a new release branch and rush through the whole process again.

And it produces a huge number of incidents. If you have zero incidents right now, you have a good system. But does anybody have that?

It created an automated testing culture

Such companies often say “we will move to CD when we have 100% automated test coverage”. But this is an unrealistic standard because they do not have 100% manual test coverage now.

Worse, because people rely on the manual test engineers to do the regression test, they don’t bother to put in place the correct level of automation. Maybe someday there will be a company that magically finds out how to do that. But nobody I have seen has so far.

The only way to force your engineers to do it is to move to a CD model and let them know that if they don’t put the automation in place there is no safety net and it will be traced back to them.

You don’t get features interfering with each other

Under the CD model, you release one feature at a time. So, gone are the days when two changes are merged in and don’t play nicely with each other. Each change goes out separately having passed all of the tests.

Critical features don’t get blocked

Sometimes, you have to push something out that is really important.

Under the traditional model, this is a major issue. Either you push it out as part of the scheduled release, and risk another feature breaking and you having to rollback your critical change. Or you block out the entire release and stop everyone else releasing for a few days. Which, as you can imagine, creates an even bigger big bang release later down the line.

These problems are eliminated with the one-feature-at-a-time CD model.

It is easier to roll back

If you do get a problem, it is super easy to roll back. You just hit the rollback button.

Under the traditional model, you have to check if you can roll back (due to all of the dependencies) and then if you are allowed to roll back (checking with the product owners that they are all okay with it) and then do some complicated rollback script.

All of this is simplified under a one-feature-at-a-time CD model where if it doesn’t work, you just roll it back straight away and don’t block anything else from releasing their features.

You can get fixes out faster

If something does slip through the net, you can get a fix out of the door faster than ever before. Gone are the days when you make the fix, try to work out what release branch it needs to go in, do all of your manual testing and then push it out the door.

Instead, you just write the fix and release it. And it’s fixed, way faster than it could be using the traditional model.

Summary

Yes, continuous delivery will make for happier product owners, happier developers and a faster-moving business.

But, and this is most important of all, it will also make your platform safer and more reliable. People think it will make things riskier, but, as I have outlined above, this is simply not the case.

With the CD model, you isolate every feature and every release, which is the gold standard of good change management. And, if anything does go wrong, it’s easier than ever to rollback and push a fix out.

Companies often believe that they cannot risk moving to a continious delivery model. However, if their platform truly is important, then they cannot risk not moving to the CD model.

If you are not familiar with a burndown chart, the idea is this: you pull so many points (bits of work) into a sprint (a period of time, typically two weeks) and your burndown chart shows you how far you are through said work. So, the red line on the chart (the amount of work done) should follow the grey line.

Or, at worst case scenario, the red line should stay flat because you have done literally nothing.

However, what it should never, ever do is go in the opposite direction to the grey line. Because that would mean you actually ended the sprint with more work to do than you had at the start of it. The point of a sprint is that you should not be bringing in extra tasks.

Safe to say then, that this was not a great sprint for us. But, it is at least comically bad.

Last month I attended a Leeds PHP event where the guest speaker was Konstantin Kudryashov, author of Behat. He made a great case of how using BDD can really help you stay on track with the agile process.

Unfortunately I was sat directly behind a massive dan boy who spend the entire time enthusiastically nodding to everything that was said. I am sure he is a nice guy, it was just very distracting.

Richard had a very different opinion. He described most of what BDD did was nonsense. It works fine on your Symfony2 stack, but it just adds massive overhead for little benefit he argued, citing an example of how the company he is working with at the moment has just ripped years worth of it out.

I know what he means. It does work great on some stacks but become difficult on others. Also, I was working with a company that had done half their unit testing in it. I will not mention which mayor subscription TV company that was, but it was a great example of applying Behat to the wrong use.

However, on the whole I think BDD really can add a huge amount of structure and benefit to a product. You can knock “value” as a buzzword, but actually it just means actually focusing on what makes a product better and that genuinely is all that matters.

I recently requested an evaluation of Go, an agile release management tool from ThoughtWorks Studios.

I filed out the form but unfortunately it insisted I hadn’t filled out my city, even though I had. So I sent a support request to them and a few hours later, someone emailed me back asking where I was based so they could direct my query. I told them, but never heard back from them.

A month later I got an email from one of their sales guys asking me how I had got on with my evaluation. I emailed them back saying I never actually had an evaluation because they had never got in touch. He apologised and sent through my license key. However, at this time I was on my Mac, so I had to download the Mac client. I went to the website and this time I managed to register and download the software. Great, I thought.

Unfortunately, I didn’t get time to look at it until I was back in the office and by that time I was back on my Windows machine, so I needed to download the Windows version. I went to the website and tried to enter my email address I had used last time I registered to download.

But I just got an error. So I tried again. Another error, different this time. So I tried to go through the whole registration process again, but this once again went back to telling me that I hadn’t entered my city when in fact I had.

I sent their support another email asking for the direct download links and having been sent them, I was finally able to download and install the server. Huzzah! So I did that, but then didn’t really know what to do. It said it had started the sever, which was fine, but there was no indication of what to do next.

After some googling, I eventually found the URL I was supposed to access the dashboard with and entered that into my browser, but didn’t get anything. I tried restarting the server, no luck. I tried running it from the jar. No luck. I even tried uninstalling and reinstalling it. Still nothing.

I decided to boot up my CentOS virtual machine and try installing it there. I downloaded it and tried to run the installer but it told me I needed JDK 1.6 or greater. A quick search through yum and I had it installed. I tried to run the installer again and I got the same error, even though I now had JDK installed.

Eventually, after searching the web for awhile, I found out that they didn’t support OpenJDK yet (you know, the JDK that everyone on Linux uses) so you have to install it using the ignore dependencies flag. Finally, it installed.

It then said that Go Server was up and running and so I tried to access the URL, but it did not work. I tried Apache, and that was working fine, so my virtual machine was working fine, it was just Go Server. By this time it was quite late so I turned everything off and headed home.

The next day I got in early to have a play around with it. I booted up the virtual machine and tried to start Go Server using the service command. All I got was “Error starting Go Server”. I tried googling the phrase, but apparently, it had never before been seen on the internet.

I tried googling some more and eventually found a post that seemed to have the same problem that I had. They eventually found that the problem was to do with the hostname. I couldn’t find any way to change the hostname though, so decided to try the Windows approach and remove and reinstall it. This didn’t work either.

I tried to go look it up in the online documentation, but their website was down again with a 500 error. I waited a few minutes and did a couple of refreshes and eventually it reappeared, but I couldn’t find a solution.

By this point, I had wasted far too much time on this, so I gave up. My advice is, go elsewhere for such software.