Do you have a scrum team consisting of individual players? Does your team know why it exists in the first place? Do the team members know eachother's personal preferences for doing the things they do? Are they aware of what they find important as a team? A Team Poster crafted by the team itself will improve collaboration and contributes to a performance increase.
One of the cool things that Europeans added to Judo is the belt system. Japanese are patient by nature, they either do or don't. In fact they distinguish only the black belt, you either have it or are progressing towards it.
We need a bit more guidance to know we are on the right way, hence we have the different belts (which actually originate from the game of pool.) So what are five distinct levels of Product Ownership that we can observe and what must change before we move on to the next level?
Robot Framework is a great automated testing tool that uses a keyword-driven approach. When you want to run Robot Framework tests within the context of a running system-under-test you can load Robot Framework's RemoteServer as a java agent. This is not something that comes out of the box so we will explain how to do it here.
Google managed to surprise both the market as well as the fans by cancelling the Project Ara modular phone. But from a Product Owner point of view it was no surprise. Ara phones lack a fundamental pilar that makes a product successful.
The Robot Framework Remote Library Interface: using the Remote Database Library to connect to IBM DB2
In the aftermath of my Robot Framework workshop at the Xebia 2015 TestWorks Conf, I received several e-mails from people who had attended the workshop. They were asking questions and describing (smaller and larger) problems surrounding various aspects of their test automation efforts with the Robot Framework. Some of these questions and problems are identical to those that, as a consultant, I encounter in the field. Since the involved topics may thus be of interest to a broader public, I decided to dedicate a series of blog posts to them. Better (very) late than never, right?
The first of these posts will show you how to use the Java Database Library while running RF on Python and also elaborate on why you may want to do so. As an extra, we will be putting the library into actual use as well, by connecting to an IBM DB2 database and, subsequently, running some keywords.
Please note that I will use these treatments also as an opportunity to shed some extra light on various aspects of the RF that we will encounter and that I feel may be of interest to those that would like a somewhat better understanding of RF's internals. So, for some readers this will feel like a mild and acceptable (and maybe even welcome) digression, while for the practically inclined it may constitute an inexcusable transgression. You can't win 'em all, I guess. 🙂
Methods based on Agile and the Kanban Method both stimulate collaboration to achieve focus and flow. In practice this is often challenged by teams with specialists who have a tendency to maximize the utilization of the specialists.
So, is a team with a focus to finish work more effective than a team with focus on efficiently using expertise? Read more
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.
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.
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.
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 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.
However, 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 . 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.