Why aren’t we… why don’t we have…

Warning: A lot of mention of “innovation”, “innovate”, “innovative” in this post. Here’s a photo of my two cute dogs if you need a break from those buzzwords.

A question got raised one evening while we were in Tinola (that’s the name of the conference room, which is also the name of a local viand), and we ended up having a full-blown discussion over it complete with a mindmap on the white board.

So the question was: Why aren’t we innovating as much as they want? We decided the key points were: Time, Skills, Motivation. Experience is essential for the insights and the intuition it brings for being able to distinguish what could be of value and what would most likely be a waste of time. We had a dotted line to “Management support” as they’d be the one most qualified to allocate time and skills at least. But that didn’t make the cut on what’s at the top of our list. Looking at the image, it kind of generally addresses any other question on why we don’t have something that’s being demanded of us.

why_arent_we

I’ll try to go over each item from what I can recall.

Time – To produce something or create something generally takes time. I think that’s a physical, realistic, and basic requirement. Just sitting down on a problem can’t solve it — you have to think about it, process it, rack your brains for solutions or ideas. That by itself takes time. And implementing the solution all the more. So when folks are so busy in their projects, it’s a bit hard to expect them to focus on anything else.

But say you free up people so they can work on “innovations”, there’s this other aspect on skills.

Skills – If the expected solution is an implemented application or system, then that requires skills in software engineering — design and analysis, then there’s implementation or coding, testing, etc. These are skills you don’t just build overnight so with the learning curve, it’s going to take a lot more time to come up with a minimum viable product (i had to use that term*). Then there’s this concern on which skill do we need to build up further — shouldn’t we focus on strengthening our testing chops since we’re testers after all? Learn more about other aspects of testing that could be relevant to our craft/career? Or should we use that hypothetical free time learning to code so we can create applications?

And then again do we know how to innovate to begin with? Maybe there are some workshops to develop one’s skills in problem solving or creative thinking which could increase one’s chances in coming up with something innovative.

So say we have the time, we have the skills. It doesn’t mean we’ll already be working on innovating. We need a reason why to drive us and that’s the third point which is motivation.

Motivation – This is what would compel us to innovate. It’s so important to have a why! It’s emphasized so much even in the Jillian Michael’s workout video I’ve been regularly watching where she says “If you have a why, you can tolerate any how.”

It’s but natural for us humans to ask what’s in this for me? What would I get out of this? This could take on different forms — it could be financial rewards for some, fun for others, opportunities to learn for the rest, etc. It depends on the person’s individual priorities on what would be rewarding and in turn motivating for him.

Then there’s also the question on whether there is even a need to innovate. Of course, there are always things that could be improved, but there has to be a good problem to solve — the kind that’ll feel like you have an itch to scratch, the kind that will merit the need to spend time on it.

So that’s pretty much it for what we discussed that evening. Thanks for reading!

*Long story — maybe i can share some other time. I’ve rambled on for too long already. Thanks again for reading!

Sprint retro: Testing worked!

So my friend is in this other agile project doing 1 week sprints implementing a web-based system. Until last week, their team didn’t have a tester. Of course, they probably dev-tested their own work and they did have sprint reviews with their product owner. But, as they’ve also brought up in their retro, and what’s also great about their team is that they recognize the need or value of testing (I quote: “need proper testing”).

A couple of weeks ago, my friend asked me to take a look at their site, give it a quick run through, and give feedback. So I sat down on it for an hour or so, and did some exploratory testing on a few available features. After that session, I had spewed out as many comments (bugs) as I could and consolidated them along with screenshots. For the sprint they were doing a retro on, they fixed some of the items I raised and finally got a tester in their team. It felt great to see this dev team post under “what worked”:

  • Tester
  • Bugs are raised
  • Some bugs are fixed / completed
  • KC (that’s me!)

Yay for testing!

Active testers should be the norm

So yesterday we had a sprint review wherein the testers conducted the demo to our product owner. I reckon it went rather smoothly. I am pleased with how my tester team mates did their presentations. The delivery team overall got good feedback from our PO (yay!), and we testers got some kudos from our PM (yay, again!).

Later in the day, our team had our sprint retrospective. Under the header of what worked well, one of our team mates wrote “DEV-TEST” (which someone corrected to DEV♥TEST) referring to how well the devs and testers were working together. It was actually one of the most upvoted items. And from the retro deck I quote: “Strong and instantaneous link-up between developers and testers. Notification and resolution of defects are faster due to great work relationships between the team”.

Under the header of what to do differently of our sprint retro, not wanting to make scrummerfall a norm in our coming sprints, I suggested to plan sprints such that there are testable features earlier in the sprint (and definitely not 3 days before the end of the sprint as what we’ve encountered for Sprints 0 and 1). This concern didn’t go unheard and the team actually brought up a couple of action items which addresses this.

Earlier today, we got word from our PO on the priorities for this sprint. The devs had to prioritize several bug fixes and that left one of the high-priority items on data encoding to us testers. It’s not exactly testing work, and it’s not exactly dev work either. But it needs to be done this week, so we went ahead and owned it. We actually completed the task in half the time we estimated. Yay for efficiency (or overestimation, but I’d say the former).

So where exactly am I going with this post. I guess I’m just glad that the testers are having such an active role in this project. We’re being heard and (I’d like to think) appreciated. And I guess this shouldn’t be an expectation only in Agile projects. This should go for any project.

Hello again, world

I haven’t been in this space for some time. Lately, I’ve been instagramming about my lovely dogs and tumblring my attempts of doing art. I am still in software testing. I still feel that the work we testers do highly contributes to making software better (or at least less sucky).

I’m around month and a week into my 2nd mobile testing engagement. We’re at the 2nd week of our 2nd Sprint. There are a lot of things that are new in this project so it’s a really great learning opportunity for myself and more so for my younger tester team mates. For one, we’re adopting an Agile Scrum methodology, and it’s probably the closest we’ve gotten to an actual agile project (we have some scrumbuts). This project is also an implementation project, so this provides them with the opportunity to see something get built from scratch. I think testers who haven’t tried working in an implementation project are missing out. This is where the fun is, and where testing can make the most impact. Plus, this one’s building a mobile app so it has a really modern feel to it.

So tomorrow’s a holiday and we still haven’t received a build for half of the user stories in scope of this sprint or for the fixes of the bugs that were already reported, and Friday is the last day of the sprint. Ah, scrummerfall! It’s a word I picked up yesterday. One of the questions in a webinar I attended touched on the topic of agilefall or scrummerfall. It happens in Agile projects wherein the testing work starts at around the 8th day and the testers are scrambling to test the features and doing overtime work to catch up, and the developers are already moving on to other things. If you’re experiencing scrummerfall, sorry but you planned it that way. The good thing is you can choose to not plan it that way (or so the speaker says). Someone needs to raise their hand and point it out so that the team is planning for a sprint that has something testable as early as day 2 or 3.

Something to raise for our retro. :p

Bothering to reflect

A friend just shared a link over at twitter to a blog post by Scott Berkun — The magic numbers of project management.  The part on “What to do instead” just made me nod in agreement… especially at the part below (emphasis mine).

The best way to think about estimates is that it’s a culture, not a formula. It’s no accident better teams are better at staying on schedule. They ask better questions and care about things most people on projects ignore.  What are those things? You discover them for your kind of projects by going back and studying. Focus leadership attention on the dozens of factors that contribute to scheduling, note some basic and fundamental things you missed, and consider applying that knowledge, as a team, the next time around. Don’t fight the last war, but make sure to learn from it.

It also reminded me of something I’ve read and mentioned in passing to another friend on the bothering to reflect.  In the book, it raised two questions:  What did we learn?  What can we do better? To my friend, I asked the rhetorical questions:  What are we doing wrong?  What are we doing right? Another colleague raised a question which he thinks not many would appreciate:  Are we (as a company) good at what we do?

Asking and reflecting at these kinds of questions, looking into our past project experiences for ways we can improve, introspection — these are things that could help us.  Although we sometimes do have project postmortems, yet sadly we encounter the same problems over and over again (a lot of which are classic mistakes but that’s not an excuse).  And maybe that’s one thing to do a CAR on — ironically, on why our CARs need to be CAR’d on.