Hell of a Tester

  I lately was asked to participate into workshopping in creation of "career paths and titles" in a software development organisation. I have seen a few. Some with a lot of work put to them. And all wrong. Is it them or me? Definitely me. That's because I don’t in general like titles, the way are assigned to people. I think it would be more reasonable to discuss the responsibilities a person has and things they do, periodically. And help everyone pick a title that describes this well. And adjust it whenever they want. Seniority is also a hard concept. Is it about years in field? Or years in life? Or about specific knowledge, or knowledge in general? Or about the successes and mistakes you have been part of? Or on how you treat yourself and other people? Or on how you compare to another random coworker? I don't know, and maybe I don't care. Why other people do, at least because of the money. And the way salary raise is usually tied up to a promotion. For that I hav...

Attended a week ago the Frogs (friends of good software) online unconference https://frogsconf.nl/. Unconference type of events are these days pretty much the only type of conference I wish to participate. They almost automatically establish what many more traditional desperately try - discussions and interactivity. Frogs was no exception, and was also extremely well organized. It followed a typical unconference/openspace format, of creating the content and schedule of the conference in the beginning, and then people attending the ones they find most interesting. The conference organizers have background in testing/qa type of work, which is why there where a lot of testing minded people attending, but happily there were also a lot of people from different backgrounds.  We were using Welo as the platform for the unconference and it worked well, allowing you to move virtually between rooms and hangaround places.  Depending on the timeslot, there were 3-5 topics happening at the ...

Are managers valuable? Or useless? Or harmful?! I can admit that during my 17 years career in sw development, I have developed sometimes a bit cynical view on managers. And therefore a sound interest on ideas around not having any, like teal and holocracy (although I am not a big fan of those either 😀). Cynicism comes from managers who think it is their job to make decisions for other people. Decisions like what information to share and for whom, who to hire where, and how to do things. So decisions which mostly affect other peoples work. And these type of managers are not just useless, I think they are extremely harmful. I'd rather take a manager that does nothing than this type of a manager. But I've also had privilege to work with managers who advice, share, participate, challenge and empower. Managers who get the best out of teams and individuals. Managers that give me hope. My question to all managers is: what type do you want to be?

  "Does everyone have something to work on?" Is a question I sometimes hear from a product owner (or similar role), often in the end of some planning/coordination meet. And I consider it a big red flag. As it is an indicator of trying to keep developers busy and attempting to get a lot of tasks and features done. Which is not the goal. The goal is to maximise the impact of the team for delivering long term business value. So instead of "is everyone busy enough", I'd suggest to try rather asking something like: 1. Do we agree that the work we have planned and prioritised is meaningful and valuable based on our current knowledge 2. Can we somehow assess and evaluate that later on 3. Are we excited!? And then as a team organise and start to work around those goals. Yeah it will be harder, but a lot more engaging. And yeah you will not get as much features out, but you might just get the right ones.

There often seems to be a thought around sw development especially in bigger orgs, that if you plan something very well it will be then easy to allocate the work to individuals in a team, and then fast for them to do. And that way you can get plenty of "tasks done on a sprint". Which may be true. But forgotten are the months the thing has been "planned" in various ways.  And forgotten are the hours and days of planning things that eventually never even get done.  And in the end, forgotten are the goals and impacts one originally hoped the product to achieve. Instead of all this effort planning it would be often way more effective to spend the time to clarify and generate shared understanding on the objectives of the work. And then let the team do the work with planning, implementing and analysing being intertwined activities, focusing on the impacts you are aiming to achieve.

I got to listen to a discussion today where a topic was if a team kanban board should have a "ready for testing" column. I am happy that the discussion ended with the decision not to have it. I am happy on that because in the world of software development, testing is  not a phase to happen somewhere after programming and before pushing something to production.  If/as testing is about raising good questions, seeking answers to those questions, and about exploring risks and opportunities - it should happen all the time. From the beginning when  thinking if the thing should be built at all, into the end when analysing and observing the actual impacts. Everything that happens between is about doing, and any extra column, phase and handover you create inside this is going to hurt you.