Moving to weekly releases

[Daragh]

Presenter: Rob Lambert

View the webinar Here

Download the eBook Here

If you have any questions or observations, please type them below. I look forward to hearing your feedback 🙂

[Paul]

Hi Rob,

Thanks for the presentation! A question from Nikhil Garg, who attended today’s webinar:

“As we are following each and every thing from start to end how will this process help us to reduce the release time?”

[Mike Harris]

are releasing software in the same “sprint” that is is written?

[Neil]

Hi Rob,

Thanks for the presentation! I’ve just got a couple of questions – I’m sure I’ll throw some more at you during TestBash.

1. Releases traditionally have a fair amount of overhead and drama, and it’s often beneficial to let people get their breath back after a release. How does your team avoid burnout with such frequent releases? Or do you find that smaller releases = less drama?
2. How frequently do you perform traditional scrum activities such as planning and retrospectives – wouldn’t these significantly eat-in to the available time for a one-week iteration?

(I had a lot of other questions which I’ve deleted as the presentation went along, as you’ve answered most of them! Thanks for a great seminar!)

[Gabriel]

Hi Rob,

I have a question about the notes taken during exploratory testing sessions.

Since you mentioned a number of tools where notes are introduced, I was wondering if there’s any duplication of the data collected during the test session.

Also, what’s the typical duration for an exploratory session? And how long it takes to input the data collected in all the systems used for tracking.

Thanks,
GabiD.

[Gabriel]

You mentioned moving more testing to code.

Could you share some of the major challenges your team faced while doing that move and how these challenges were overcome?

[John Beckett]

What can actually be done in a week that provides value to a customer?

[Daragh]

Question from Cristina Keusch

What is Cross functional work?

[Paulo]

Hi Rob,

just wanted to say that the rough slides work very well and that the presentation was great. Well done!

[Anonymous]

Hi Mike,

Question: “are releasing software in the same “sprint” that is is written?”

Yes – sometimes we will see a story come in and be finished within a few days and be released in the next release. Sometimes the story will make it to the next release.

As I mentioned it’s like a release train and if the story makes it in then it goes in to production.

Thanks
rob

[Frank Pedersen]

I have a question regarding the exploratory testing.
How do you log those results? And how do you decide what to test during the exploratory testing? The reason I am asking is because I would like to be able to see exactly what has been tested (what risks are mitigated) before adding a story to a release. Is that something you do? I find that logging exploratory testing is often neglected, but is it only me that can see the advantage in having a good log of both results and coverage even with exploratory testing?

[John Beckett]

I concur with Neils question. We tried doing weekly sprints for about 2 months on our (quite sizeable.) project and we couldn’t breath after each release. The drop out rate (burnout/stress, etc) among the team was climbing, so we put it back to two weeks and then 3 weeks that seems to be the middle ground.

[Anonymous]

Hi Nikhil Garg,

Could you expand the following question a little – I’m not sure I fully understand the question.

“As we are following each and every thing from start to end how will this process help us to reduce the release time?”

Thanks
Rob

[marzio]

Hi Rob,

very glad to be able to follow your presentation.
my only question is on the “free testers” in the ending thought, what did you mean about?

many thanks,
m.

[Nikhil]

I want to confirm As we are following all the procedure that is followed during traditional release than how we can provide a quick release .

[Anonymous]

Hi Neil,

Thanks for the kind words and questions.

Question – “Releases traditionally have a fair amount of overhead and drama, and it’s often beneficial to let people get their breath back after a release. How does your team avoid burnout with such frequent releases? Or do you find that smaller releases = less drama?”

Answer – The smaller the release the less drama really. If we are improving the process all of the time then we are looking at ways to reduce some of the cost of release. We’ve invested heavily in automation and in streamlining the process. We spent a lot of time mapping out our process and reducing the waste in it – we’re still doing this. As such the release is less painful than a major release. It’s something that happens each week. It’s not pain free but it’s a regular operating process that happens with well defined process and a talented group of people supporting it.

Question – “How frequently do you perform traditional scrum activities such as planning and retrospectives – wouldn’t these significantly eat-in to the available time for a one-week iteration?”

Answer – Each team is slightly different. We do a fortnightly show and tell session where we demo what we’ve built to the wider business but the reality is it may already be in production. We do retrospectives still and we do kick off sessions in some teams. Some teams are true Kanban and they do story kick off sessions as they pull a story, some teams do a sprint kick off but still pull Kanban style. Some teams are running on one week iterations, some two. The smaller the sprint the quicker the kick offs, and our retrospectives are typically very well run and optimised. They are important parts of our process so we still do them as they help to improve the process

See you at Test Bash.
Rob

[Daniel]

Thank you for your presentation. It was interesting.

I would like to thank you as well for a little bit of confirmation bias on my part. We currently have a change management consultant in our organisation who was looking at our development and testing approach. He was miffed when we didn’t give him a concrete name to our agile approach. He wanted us to say “We do scrum” or the like, when in fact we do our own agile approach taking what works from many sources and creating our own parts of our approach that suit the needs of our teams and organisation. The opinions I have about the value he’s adding in general I’ll keep to myself however. I don’t think following an agile methodology to the letter is fitting with the whole philosophy of agile at all. A little off topic side comment, but you momentarily mentioned teams having their own take on agile and it resonated with my earlier discussions.

I’d like to echo a sentiment above and ask how you decided a 1 week iteration was suitable for you and what pros and cons you’ve felt this brings. We work on a 2 week cycle and I think this is a pretty widely used sprint length for normal (there’s such a thing?) projects. Also, what happens to larger complexity stories that may take over a week? Do you try and break them down further?

Many thanks,

Dan.

[Rainer]

Hi Rob,

thanks a lot for your excellent presentation!

I have two questions which are not really related to it, but might still be allowed to be asked:
Which tool did you use to draw the pie diagramm? Looks like it was drawn with a real pencil
and scanned on a scanner, but I guess that’s wrong. Which was the book again you recommended
during the presentation?

Thanks a lot!

Kind regards
Rainer

[Anonymous]

Hi Gabriel,

Question : “Since you mentioned a number of tools where notes are introduced, I was wondering if there’s any duplication of the data collected during the test session.”
Answer : Each tool is somewhat unique in what it offers so mostly there is little duplication. Some tools like NewRelic and Papertrail will offer details of errors in the event logs, but we just use the tool that provides the richest analysis on a case by case basis.

Question : “Also, what’s the typical duration for an exploratory session? And how long it takes to input the data collected in all the systems used for tracking.”
Answer: “The typical duration is about 1 hour for sessions. The process of adding notes to confluence is pretty quick, it’s usually just a case of copying from the note taking tool of choice and pasting in to Confluence. The google form maybe takes a few minutes to fill in and double check the details. all told – maybe 10 minutes at the end of a session to fill in the metrics. We’re in these tools anyway so the overhead isn’t massive.”

Thanks
Rob

[Luis]

Hi Rob,
nice presentation.
I wan’t to know more about acceptence/UAT process:
1) Is it done by end users?
2) have you ever experienced it with independent testing teams?
How does it “affect” your cycle? Can you share your share the major “dos” and “don’t dos” of it?

Thanks in advance.

[Anonymous]

Hi Gabriel.

Question: “You mentioned moving more testing to code. Could you share some of the major challenges your team faced while doing that move and how these challenges were overcome?”

Answer : Sure – a big challenge was building out our test framework – it’s still an on going challenge. We have some technical obstacles which mean we have to approach automation differently to many typical websites so getting that in place was tough.
Convincing the development teams to write automated testing at an API and UI level took some time and we’re working hard to reduce the cost of writing some of these tests.
Finding the right testers who could champion test automation but then also work in a rapid release environment is hard, and is still hard. Not many testers are comfortable with relying on Exploratory Testing as their main activity.

Thanks
Rob

[Anonymous]

Hi John,

Question: What can actually be done in a week that provides value to a customer? – See more at: https://huddle.eurostarsoftwaretesting.com/forums/topic/moving-to-weekly-releases/#post-1105

Answer : Quite a lot. Plus it’s important to look at the sum of all of the parts. If we are building a big feature we can be shipping much smaller parts of the whole for feedback from our customers. That way we can evolve the features or features in the right direction.
Sometimes we may not always know the best way to solve a problem. In my past this was often the case and we solved it by asking our customers and choosing a direction, then building it out only to find it was the wrong decision. With short releases you can trial a solution and iterate on it to get it right, whilst all of the time working closely with customers.
Bug fixes, enhancements, tweaks, small features like UI changes and many other pieces of work can all add value to a customer.

Thanks
Rob

[Nicolaj]

Thanks Rob, that was some great content. Keep it up and some day world domination will be in Done 😀

[Martin]

Hello

Lets take a tricky case that we have a complicated functionality. For example a workflow fthat starts with creating a document followed by a number of steps up to finalization. Analyzing that kind of process takes time as well developing and testing it. Any tips or tricks for that kind of situation? Cuz even if we assume that we already have the input for analysis and its with decent quality – building it all together takes time.

Cheers!

[Anonymous]

Hi Cristina Keusch

Question : What is Cross functional work?

Answer : Cross functional work is really the work across functional departments or hierarchies. Most companies have a development team and separate test team. This is an example of different functional departments. They may have their own management structures, goals and objectives. Another example is the operations team and service desk and other departments who all support and help the customer.
True customer service is only possible by aligning across these departments and having everyone heading in the same direction. It is very hard to achieve but ultimately results in providing the best solution and best service for customers.

With a cross functional team we can solve problems quickly and provide great service for our customers.

Thanks
Rob

[Anonymous]

Paulo,

Many thanks indeed.

Thanks
Rob

[Anonymous]

Hi Frank,

Question: “How do you log those results? And how do you decide what to test during the exploratory testing? The reason I am asking is because I would like to be able to see exactly what has been tested (what risks are mitigated) before adding a story to a release. Is that something you do? I find that logging exploratory testing is often neglected, but is it only me that can see the advantage in having a good log of both results and coverage even with exploratory testing?”

Answer: I may well have already answered this in a blog post I wrote a while back. Instead of me listing the same content here I’d like to provide the link:

http://thesocialtester.co.uk/managing-exploratory-testing/

In a nutshell the team are talking about risks, problems and areas to test and deciding on the best approach. Mostly this will result in automated tests, or a round of exploration to discover more to mitigate risks. The story breakdown and test definition process is a team event and this is where the discussions about what is/is not testing is discussed.

Hope the above plus the link answers the question.

Thanks
Rob

[Anonymous]

Hi John,

Yeah, it can be really hard at the start of agile to find the right cadence and flow of work. We’ve seen the same thing and in all cases tweaking the work in progress tends to solve the problems. Of course much pressure can be applied from commercial deadlines but the burnout by trying to do too much often ends up delaying work in the long run.

I know of some teams who have a “relax” sprint every three or four sprints to tidy up some tests, clear some tech debt and reset ready for the next march.

Each week we adjust our WIP (Work In Progress) limits to deal with the context we find ourselves in (people off, work taking longer than expected) all with the goal of finding an even flow. It’s constant and sometimes we get it right – sometimes we don’t.

I’d be keen to hear more about you addressed it in the end.

Thanks
Rob

[Anonymous]

Hi Marzio,

Question:
my only question is on the “free testers” in the ending thought, what did you mean about?

Answer:
It was really a reference to freeing testers to do what they are good at and that’s testing, rather than checking. Computers are very good at checking and they are generally more efficient that people so it makes sense to automate what you can. This then frees up the testers to do exploratory testing and other testing activities.

Thanks
Rob

[Anonymous]

Hi Nikhil,

Question: I want to confirm As we are following all the procedure that is followed during traditional release than how we can provide a quick release

Answer : The answer is you probably can’t. It’s typically not possible to release often whilst following a traditional release process. It requires some deep rooted change across the business to adopt new ways of working. It may be possible to improve the release process in a traditional environment by reducing some of the waste in the process, but even then the business needs to buy in to this process.

Thanks
Rob

[Author]

Posts