Dockerised Jenkins 2 on Google Cloud Platform

Marc Rooding

Any company doing serious software development needs a platform. The platform allows the company to build and test software and support running all applications.

I have had a lot of experience with a platform based on AWS, Docker, and CoreOS using Fleet for orchestration. But being as curious as I am, I wanted to look into alternatives. The Google Cloud Platform powered by Kubernetes (which has matured into a production-ready container orchestration tool over the past year) drew my attention.

This article explains how I’ve built a persistent, resilient Jenkins instance powered by Kubernetes. It includes everything you need to create a CI pipeline with GitHub and Docker support. It also assumes basic knowledge about Dockerfiles and Google Cloud configuration.

Continue reading on Medium.com

Help Me Create a Better Way to Prioritise Features

Chris Lukassen

Do you remember the legendary PID? the Project Initiation Document. The famous big binder that we used to create in the beginning of a project to satisfy governance and then bury in a drawer so we could get started. Then agile came and we broke things down. We learned story maps, customer journeys, vision statements, business model canvases. For me it works for the big picture, but when it comes to feature development or epics, it's not perfect.

Product Samurai use elegant weapons for a clear and effective battle. So what is our weapon of choice? I have not yet seen te ultimate tool. But I'm close and I need your help to complete it.

 Read more

The Legend of the 5 Monkeys, the Doctor and the Rose

Chris Lukassen

As Product Managers people look up to us to carry the vision, to make sure all the noses are aligned, the troops are rallied and that sort of stuff. But what is it that influences behavior? And what makes your team do what they do? The answer has more to do with you than with others.

 Read more

Mapping Biases to Testing: Confirmation Bias

Maaike Brinkhof

I use terminology from earlier blog posts about biases. If you have missed those posts, read part 1 here. I explain the terminology there. In the second post I wrote about the Anchoring Effect.

Let me state the ‘bad news’ up front: you cannot fully avoid the confirmation bias. That’s actually a good thing, because if you could you wouldn’t be human. We jump to conclusions (with System 1) when our assumptions are likely to be correct[1] and a mistake is acceptable. For example, when you meet a new person you immediately judge him or her based on stereotypes, what type of clothes the other person wears, his/her posture, etcetera. This happens so quickly that you cannot stop it.

confirmationHowever, jumping to conclusions can be a bad thing when the situation is unfamiliar, the stakes are high and when there is no time to collect more information[2] . This screams ‘testing!!’ to me. We are often dealing with unfamiliar situations, the stakes are high and we usually face a deadline. How do we deal with this? Let’s explore what the confirmation bias has to do with testing.

 Read more

Seven Reasons why Darth Vader is a Terrible Product Manager

Chris Lukassen

It’s not that I have run out of Samurai parallels but I ran into this blog called: “Darth Vader - The Best Project Manager in the Galaxy” and since it’s my sincere belief that this sword wielding (see there is a samurai parallel!) manager actually displays some pretty terrible Product Management Skills:

Here are 7 examples, which should help you, gauge in what side of the force your product management skills lay.
 Read more

Scrum Day Europe 2016

During the 5th edition of Scrum Day Europe, Laurens and I facilitated a workshop on how to “Add Visual Flavor to Your Organization Transformation with Videoscribe.”

The theme of the conference, “The Next Iteration,”  was all about the future of Scrum. We wanted to tie our workshop into the theme of the conference, so we had a creative brainstorming session and identified four key elements that we think are important in the future of Scrum.

Scaling: Do Scrum well first, before scaling Scrum.  You should only scale when needed and if the organization is ready.

Done: A “done” increment means actually done, all the way into production. We hope that future Scrum teams will be able to put things into production themselves. We still see a lot of teams with dependencies on other teams for delivering increments to production.

Product Owner: We’re still searching for great Product Owners who understand the product and the market. These Product Owners work well with teams and are empowered, mandated and have a product vision.

Scrum everywhere: We already see Scrum in construction, health care, schools, marketing and many other places. In the future, we see Scrum used everywhere.

Since Laurens is such a great drawer, he sketched out the four elements, and we made a VideoScribe of them. You can find our video here: https://www.youtube.com/watch?v=XKYjWS4H26I

During our presentation at Scrum Day Europe, we demonstrated each of the seven steps required to produce this video. To bring Videoscribe to life, we asked the attendees to suggest a fifth element for the video on the future of Scrum. They came up with “Happiness.”   We then went through the steps to make a video, asking for different volunteers to record a voice over and draw pictures for the message. Here are the results: https://www.youtube.com/watch?v=uWlSaC3K9Kg

The attendees were impressed and amazed to see that they could produce a very smart looking Videoscribe themselves.  Overall, the workshop feedback was very positive. We also received some tips for improving it, such as showing examples of how real companies have used this method. But because Videoscribes are usually made for internal use only, we could not show these at the conference.  For our next session, we probably  make an example Videoscribe for a non-existing company which is shareable with the audience.

One of our attendees was so inspired by our session that we are invited to facilitate a workshop for her management team!

1468915285615

 

The Ultimate Tester: Wrap-Up

Maaike Brinkhof

ultimate_tester1

To everyone who has read all or some of the past blog posts in this series: thank you so much for reading. I hope I have given you some food for thought on where you can improve as a tester (or developer who tests!). 

 Read more

Our Answer To the Alert Storm: Introducing Team View Alerts

As a Dev or Ops it’s hard to focus on the things that really matter. Applications, systems, tools and other environments are generating notifications at a frequency and amount greater than you are able to cope with. It's a problem for every Dev and Ops professional.

Alerts are used to identify trends, spikes or dips in your metrics and events – for example to detect low free memory, high page-fault errors or unavailable database servers. With the right alerts in place you can get notifications or signals of problems before they escalate or respond quickly before it takes a business service down which could affect your customers.

But most companies don’t have the right alerts.

When problems occur, they have to manually correlate all alerts, metrics, events and log files from different tools to get contextual information and to understand the problem they are dealing with. How do you know which alert you have to focus on and which not?

To read the full blogpost, please visit blog.stackstate.com. 

 

Verbal Aikido for Product Managers

Chris Lukassen

"Well eh ok, I guess so" mumbled the student in the training exercise where he was practicing how to say no to feature gluttony. I decided to give the class an additional exercise to awaken their inner diplomat.

“Diplomacy is the art of telling people to go to hell in such a way that they ask for directions.” - W.S. Churchill

All sweet and well, but how do we say NO?

 Read more

The Purpose Alignment Model

Chris Lukassen

When scaling Agile/Scrum, we invariably run into the alignment vs. autonomy problem. In short, you cannot have autonomous, self-directing teams if they have no clue what direction they should go. Or, even shorter, alignment breeds autonomy.

But how do we create alignment? And what tools can we use to quickly evaluate whether or not what we want to do is part of the mission? Niel Nickolaisen, chief technology officer at OC Tanner, created the purpose alignment model. I use it with innovation labs in large enterprises to determine what aspects of innovation to keep, and what to leave to others.

 Read more