New Artwork…

Disclaimer… this is not testing related, but is a result of a connection made via the testing community.

I’ve been following Damian Synadinos from afar for quite a few years, primarily from a testing industry perspective. More recently I’ve also started taking note of his artistic abilities over at idrawstrangers.com. So just the other day (yes, this whole process only took a few days!) I reached out to Damian via Twitter and asked if he could create some artwork for me from a picture that my daughter took of me…

I promise I wasn’t posing! Not a huge fan of looking at myself in pictures, but we all need some form of profile picture these days… so why not make it fun!

Given the time difference between Australia and the US, I sent the message assuming it would like be a while before hearing back… however within 7 minutes(!) Damian replied. In my initial contact I had sent a few examples from Damian’s gallery to show him the style I was looking for, and after he explained the overall process to me I left it with him to come up with an initial sketch…

This came back the same day and after confirming I was happy with it Damian went ahead and started inking. The only change I requested was the shrink the gap between my hairline and glasses (smaller forehead). This was a result of the angle my daughter used when she took the picture (I think it’s a .6 zoom as well), so no fault of Damian’s. The next day I got draft number 2…

All inked and ready to go. Now that it had a black outline, I could see the size of my bottom lip was giving me a bit of a pout… so I asked if that could also be shrunk a touch. After joking that the pout ‘had to stay’ (ha), Damian got to work at making that change and applying the shading…

As expected, I was delighted with this version. Earlier in the process Damian had asked me what my favourite colour was in anticipation of background options. Blue was my response, along with black and white, and grey scales (hence the direction Damian took with the main drawing).

Next to arrive in my inbox were a few different background options (note – I gave Damian no direction at all for these)…

My next task was to let Damian know if any of these struck me in a positive way, or provide inspiration for more options. While I like all 3, the 2nd option was the one that did the most for me immediately. All I asked Damian was to have a go at fading the solid blue line near my feet.

At the same time I also made a slightly cheeky request for another version of the previous edit (grey background) with coloured glass lenses. I think you’ll all agree that my example is outstanding from an editing point of view…

😉

Damian was happy to oblige and did admit that my version was better than his (jokes, of course)!

The finals then arrived…

Needless to say… I’m stoked with the outcome! With high resolution versions now in my inbox, the entire process took just a touch over 48 hours. Damian did let me know that I caught him at a good time, but even with that knowledge I’m still very impressed with the turnaround time.

So if you’d like some artwork done, you should reach out to Damian and see what he can do for you!

Peace…

On Being Agile…

It’s been a while since I’ve written here… a lot has been happening. This won’t be an in-depth post, but more a quick brain dump… no, knowledge share if you will.

I’ve recently started a new project for my current client and when I catch up with people I know the common question gets asked, “So, how’s the new project?” I start off with the usual stiff like it’s great to be learning something new again, etc. but then I find myself describing it as ‘semi-Agile’. The reason for this is that we’re using sprints, but we’re not using Scrum. We’re using a board, but we’re not using Kanban. So without thinking too deeply about it I tell people that we’re a little bit Agile, but not full Agile. Another reason being that this client is only just starting to see some Agile projects kicking off, otherwise the common process is Waterfall.

It struck me the other day… I’m telling people this because we’re not ‘following’ a known Agile framework/process. It then also struck me – like a slap from Batman – that this was completely stupid!

What’s happening in our project is us being agile, not doing Agile. Each of us have differing levels of experience with Agile, and we’re taking bits that may work for us and trying them. There is a sense of freedom in all of this. We don’t ‘have’ to answer 3 questions in our stand-up. We don’t ‘have’ to apply a strict story point process to estimation. We try something, and if it works we try it again next time. If it doesn’t work, we drop it.

Looking back and trying to pinpoint the cause of this freedom… I can neither confirm or deny, but I’m pretty sure it has a lot to do with us saying right from the beginning that we would try Agile, but that we won’t be restricting ourselves to any set framework/process. Upon hearing this I can imagine that many people freaking out and wondering how that could possibly ever work. Well, it does! I mean it won’t work if you want to do a certain type of Agile, but it will work if you want to be agile.

I’m not usually one for checking boxes, but…

• Individuals and Interactions over processes and tools – Check!
• Working Software over comprehensive documentation – Check!
• Customer Collaboration over contract negotiation – Check!
• Responding to Change over following a plan – Check!

Yep, so far we’re nailing it!

So instead of trying to drag your bulldog over hurdles in the hope it’s Agile… just let it be a bulldog!

Note – Yes, the bulldog is a poor example as they are far from agile… but god dammit they’re cute!

Peace…

The Phoenix Project

One word required for this book – Awesome!

OK, so I’ll write a little more than one word. While I was still working in New York my client began showing interest in DevOps as their Head Office in Europe had already progressed quite well with their transition to Agile and had begun pushing towards DevOps in some teams. I was asked to run some initial workshops where key staff from Head Office would visit and discuss their transition and some of the challenges they had faced, etc. It was a great opportunity for me as I learned a great deal and my interest was spiked.

One of the visitors mentioned some resources for me to look into, and The Phoenix Book was one of them. The reason he suggested it was due to me advising that I generally don’t enjoy technical books. That I much prefer a story which tells me the same thing, well at least as much as it can of course.

The Phoenix Project is just that; a story. A fictional novel centred on an IT Ops Manager, Bill. It’s written so well, and its structure based on a project timeline is great as it’s so easy to relate to.

The book’s blurb…

Bill is an IT manager at Parts Unlimited. It’s Tuesday morning and on his drive into the office, Bill gets a call from the CEO.

The company’s new IT initiative, code named Phoenix Project, is critical to the future of Parts Unlimited, but the project is massively over budget and very late. The CEO wants Bill to report directly to him and fix the mess in ninety days or else Bill’s entire department will be outsourced.

With the help of a prospective board member and his mysterious philosophy of The Three Ways, Bill starts to see that IT work has more in common with manufacturing plant work than he ever imagined. With the clock ticking, Bill must organize work flow streamline interdepartmental communications, and effectively serve the other business functions at Parts Unlimited.

In a fast-paced and entertaining style, three luminaries of the DevOps movement deliver a story that anyone who works in IT will recognize. Readers will not only learn how to improve their own IT organizations, they’ll never view IT the same way again.

A story that anyone will recognise… yep, I sure did. The first half of the story, where everything that can go wrong does go wrong, was like reading the first 10 years of my career! Not specifically from an Ops point of view as I’ve never spent much time in Ops, but more from the general perspective of working in ‘traditional’ ‘silo-ed’ ways. I could relate to so much of what was written that it hooked me like an episode of Law and Order SVU – I just had to see how it ended.

Being a fictional story the technical details surrounding DevOps are not prescriptive in the writing, but they are there and the use of ‘common’ DevOps language means they are easier to recognise (assuming you have a basic understanding of the core principles). For those that prefer a more technical approach, there is a section in the back of the book dedicated to resources which are very helpful. However, technical details date quickly, which is why I enjoy the story. The principles tend to stay current, so building a story around those will keep the book as timeless as it can possibly be.

There are approaches to try, lessons learned, benefits realised… and although they may be fictional, I have lived through a few so I know they are coming from a non-fiction place! One thing that may have helped me was the addition of diagrams. There are times in the story when Bill and his crew are trialling a new approach and white boarding things, and it would have been good to have more visual aid with this. However, the writing is fairly descriptive so it’s not a deal breaker.

Finishing the book I feel like I have a better grounding in order to start more research. It’s almost like I’ve now got a ‘real life’ story on which to base my understanding. Sure, I know it’s not actually real… but it feels more genuine coming from that rather than a text book of theory.

If you’re interested in DevOps, then you should read this. If you’re interested in a funny story about IT, then you should read this. If you want both, then you guessed it.

Peace…

Working in New York

I recently published a post which covered a bit about our personal journey in NYC over the past 18 months (approx.). Here I wanted to write more about it from a working perspective.

I’ve known Paul Holland and Keith Klain for a while now. I met Paul in person for the first time back in 2014 when we both attended and spoke at StarCanada in Toronto. About a month later we saw each other again in Sweden for Let’s Test. Later that year I met Keith in person for the first time when he came out to Australia to keynote for Let’s Test Oz. Of course, I had known both of them previous to these encounters through the online testing community.

At Let’s Test in Sweden I recall getting up early one morning to partake in a game of disc golf (yep, I had no idea what it was either… but it’s fun, so check it out!) which Paul was running. He’s bloody good at it, but don’t tell him I said that. While throwing discs and trampling the Swedish country side (and, as it turns out, collecting a deer tick) we got talking about Paul’s recent move to NYC to work with Keith. What they were doing, and attempting to do long term, was inspiring. It wasn’t just good testing work, it was also making an impact socially. I know our memories can deceive us, but I’m confident in quoting Paul as saying… “Do you want to come work with me in New York?” I laughed it off. I thought to myself, it’s too big a move. I can’t take my entire family across the other side of the planet. I can’t even comprehend what NYC would be like after living my whole life in little old Adelaide, Australia. Well, apparently I can. Approx. a year and a few Visa hurdles later we landed in NYC!

I’ll be honest, the move was tough. It would be one of, if not the, hardest things we have ever done. NYC for a holiday… fun and exciting. NYC to live… fucking scary. You can read more about this stuff in the other post.

June 1 was my first day on the job, and what do I walk into? A public RST class being lead by Michael Bolton, with co-presenter being Paul! I had taken RST back in 2012, but that was with James Bach… so I was looking forward to the course from a different perspective. Attending an RST class is a pretty big deal for an Aussie, we don’t get the opportunity very often while down-under (in Australia), so I was stoked!

After the course I spent more time learning about the business, helping out with some pre-sales stuff, and also getting the office organised (building book shelves, etc.) as it was only very recently completed. Travelling out to the South Bronx each day was an eye opener, but as with most things… you get used to it.

What the company was doing, and what they wanted to do, for the community was outstanding. You could not only take pride in the operational work you did, but also the positive impact you were having on people’s lives. It made getting out of bed each day that much easier.

My first and only client (as I stayed with them throughout my time in NYC) was a global financial services organisation. You can read more about my time with them here. It was a huge learning experience for me, and I’m very grateful for the opportunity.

The client work kept me pretty busy, so unfortunately I couldn’t get involved as much as I would have liked in the consulting side of the business. However, I did learn a lot from Paul and Keith. It’s unfortunate that it broke down the way it did. Early in 2016 Keith left, and Paul also departed later the same year. For those that want to know more about it… don’t ask me – I’m not interested in talking about it or potentially fuelling any bullshit that’s out there. Those that need to know, know… and those that are true friends won’t judge without finding out the truth from the source.

The client work, along with my personal life (trying to get as much out of the city as possible while there) also meant I didn’t end up doing much with the awesome NYC Testers meetup group. I managed to get along to quite a few of the meetups, and they were always well organised and useful. I didn’t get the chance to present, despite their best efforts, and for that guys, I’m truly sorry.

To my team in the ‘Chicken Room’ – You guys kick arse! One of the best teams I have ever worked with. An often frustrating and complex project, but you held it together really well. I’ll miss you all very much.

Tristan and Cochrane – Thanks for being my homies when I most needed it. Peace and love.

NYC Testers – You’re a shining example of what a meetup can become, the power it can bring, and the friendships it can create. Kate, Anna, Tony (Tiggr – yes, I left the ‘e’ out on purpose), and Perze… keep on doing what you do! I hope to see you all again some day.

Paul – There are few people that can make me laugh as much as you can… all while teaching me important things about testing. Thanks for your ongoing support. It’s a shame things didn’t work out differently towards the end there mate. However, I do look forward to working with you again in the future… I’ll make it happen somehow!

Keith – There are few people who can curse as much as you can… and get away with it! I’ve said it before, and I’ll say it again… best boss ever! Thank you for everything. You went above and beyond the call of duty, and I’ll be forever grateful. I also look forward to working with you again in the future mate!

Peace…

Removing a Tester…

So, Katrina Clokie (KC) tweeted a tweet last week…

Katrina Clokie ‏@katrina_tester Oct 28

Still thinking about this question that someone asked me a week ago: “If we removed a tester from the team, would quality go down?”

To which my initial reply was…

David  ☕ ‏@DMGreenlees Oct 28Adelaide, South Australia

@katrina_tester you never remove a tester though, you remove a person and that person is unique. So very hard to answer.

Followed by…

Katrina Clokie ‏@katrina_tester Oct 28

@DMGreenlees Yes, thank you for articulating so clearly one of the reasons that I’m finding it difficult to find a generalised response.

Katrina Clokie ‏@katrina_tester Oct 28

@DMGreenlees I feel like there should be a “these are the 5 things to consider” type of response, but I can’t even nail that. Yet.

So I started tweeting my thoughts on some of them (which I’ll articulate further below), and that was followed by a few more tweets from KC, including this one…

Katrina Clokie ‏@katrina_tester Oct 28

@DMGreenlees I feel like we’re thinking about the question entirely differently, and I’d like to read your blog on this topic 🙂

…and here we are. 🙂

So hopefully KC will reply to this with why she thought that, because I’m still a little confused by it. Anyway, there were quite a few replies to her initial tweet and many ‘cautions’ about defining what quality means… which I completely agree with. However, I’m stuck by the ‘remove tester’ part of it so I’ll stick with that for now.

My first thought was in relation to ‘tester’ versus ‘testing’. I know KC reasonably well, so I was confident I didn’t need to clarify and that she in fact was talking about the role of the tester rather than the activity of testing. With that I moved immediately to thinking about the person who was in the role of the tester because, let’s face it, a role description is only ever as good (or bad) as the person performing the role. With that, there was no way I could answer the question without getting specific about a particular context, which wasn’t going to happen on Twitter because I hate conversation on Twitter. 😉

So I tweeted my initial response.

After KC acknowledged and mentioned the ‘5 things’ I tweeted the following…

David  ☕ ‏@DMGreenlees Oct 28Adelaide, South Australia

@katrina_tester 1. Mindset, 2. Skills, 3. EQ/personality, 4 and 5. Hmmmmmmmmm

David  ☕ ‏@DMGreenlees Oct 28Adelaide, South Australia

@katrina_tester 4. Current team fit. How they work together. Are they a motivator/demotivator? Do they hold it together?

David  ☕ ‏@DMGreenlees Oct 28Adelaide, South Australia

@katrina_tester communication is too broad and sits in skills anyway… help me out with 4 and 5 KC.

Katrina Clokie ‏@katrina_tester Oct 28

@DMGreenlees 4. Support (from other people/teams & artifacts/automation/monitoring) 5. Quality (depends what it means to your org?)

Notice how nothing we’ve mentioned is ultimately role specific? It’s all very much related to the individual who may be removed, rather than the role. So when reading the following consider it in relation to a specific person in your team, the one that you call tester and performs the role of tester (whatever that may mean to you).

1. Mindset – I’ve often said the following… developers are positive, testers are negative. Now before you get angry with me, let me explain. Developers build stuff. Sure, they may break things down in order to build, but ultimately they build, create, bring life to new code. Testers seek to break things down. Sure, they may build things in order to break other things down, but ultimately they find breaks and disprove. If you remove a tester who likes to break things down, what impact will that have on your team and it’s output?
2. Skills – Humans are unique. Each bring different skills to the team. You may have two testers who are both brilliant with SQL, but does that mean they look at things the same way? No. Skills go much deeper that how they use a keyboard, or what they may have listed on their CV. So when you remove a tester, what actual skills are you taking away from the team?
3. EQ/personality – Sure, you could put this under skills and call them ‘soft skills’, but I won’t. I’m calling them out separately because that’s important I think they are. I’ve worked in many teams over the years and it’s always been fascinating for me to watch how people interact with each other and find their place within the team. Introverts, extroverts, people who have empathy, people you don’t… oh, and there’s usually at least one ass-hole. Taking one person out of the mix can have a huge impact, which can be very positive, very negative, or somewhere in-between. So, go ahead… remove that tester, but think about it first.
4. Current team fit – In hindsight, this is likely an amalgamation of all 3 points above. Everything adds up to the ‘team fit’. I guess I was in a hurry to produce a number 4!
5. Communication – Yeah well, like I said in the tweet… too broad and likely sits within skills also. However, it’s still very much worth considering when thinking about how your team communicates, and more specifically how the tester you’re going to remove communicates. They may very well be a conduit to the wider team. In my experience testers seem to fit well in that spot as they tend to have a broader perspective of the project… focusing on the initial business need right through to the developed solution’s use.

I’ll let KC explain her 4 and 5 (hopefully – please KC?).

So the key message from me is exactly what my initial tweet said – you don’t remove a tester, you remove a person performing a role. Getting another person to perform that same role, or the activities that are intended to be performed by it, will always give you different results, always.

So who has removed testers and what happened?

Example: Atlassian QA Model (there’s way more than one link BTW) – OK, so they didn’t really ‘remove’ testers. They changed their approach, and the role seems to have changed with it (although the number of staff appears to have significantly decreased in the ‘testing’ space). What happened? Well, from what I’ve researched the outcome has been more positive than negative. I don’t work there, so I don’t know this first hand, but it appears to be working for them.

I’ve used (and still do use) Atlassian products, and my experience has always been quite good. So if I’m a measure… well done Atlassian.

Unfortunately (or perhaps fortunately) my first hand experience has always been introducing testers rather than removing them… so I can’t add any personal experience. However, the way the industry is moving, I think I’ll soon be experiencing the removal. Things move quickly these days. The time available to explore a product is constantly shrinking as we push things to production faster and faster. We’re pushing automation to developers (which I think is good), we’re doing more automation (which I also think is good if it’s well thought out), so the need for large numbers of testers is reducing. I don’t believe there will ever be a point where we won’t need a human interacting with and exploring a product (not in my lifetime anyway). However, does that human need to be called a tester?

Ah, and now we return to ‘tester’ versus ‘testing’… so when removing a tester don’t just think about the role description. Think about the person you’re removing and the activities they perform. Will the other members of the team be able to do what they did? Think… and I mean critically.

I liked this from Aaron Hodder…

Aaron Hodder ‏@AWGHodder Oct 29Porirua City, New Zealand

@katrina_tester A team is a complex system. I don’t think you can predict the outcome. (plus let alone diving into “what does qual mean”)

A complex system indeed, and why is that? Because they’re built with humans!

Also, again, that caution on what quality means… an extremely important part of the equation which many books could be written about (oh, they have!).

Peace…