How our team “does Agile”

Super quick background: Our project started Jan 2015. To kick things off on the Agile methodology, our Scrum master conducted a brief training (less than half a day) to the team, and we’ve been playing it by ear ever since.

Over the course of many sprints, retros and releases, we’ve made adjustments on how we’re doing Agile. I’m not sure if there are Agile Purists who would frown down and shake their heads at us for the variations we’ve made. But the thing is, despite our possibly non-canon approaches, what still matters most is the team closely working together to deliver working software.

This post might be TL;DR. But in case you’re still interested in having a peek at how our little team does Agile Scrum, go on and have a read…

Continue reading

Honest KC needs to put some brakes on it

I gave a rather tactless feedback during a meeting I was in earlier today. Somehow, we stumbled on to the weekly tidbit email. I might have implied or maybe even explicitly said that it was rather useless, either way that cat’s out of the bag. I was wrong, my feedback could have been more constructive. What I could have said is what I had emailed months ago that their weekly tidbits could be more helpful if they provided some content and/or context to it.

I mean, the one I received and gave feedback to was a tidbit with an image containing the text:

Test Managers, level up your basic excel skills! ☺

That’s it. No link, no content, no context. It doesn’t give me a background on why, what good will this bring, what is it for, where is this coming from, etc. And even if I had been interested in that tip, it would have been helpful if I was given a lead to some recommended reference that had been helpful to them in the past that way I wouldn’t need to scour the internet for some really good and quick reference. That aside, I also think that there could have been more testing-y skills to level up on over Excel skills.

Anyway, should I have even bothered? Well, maybe I could have just ignored it, but it comes in once a week into my mailbox without the option to unsubscribe. I do recognize that the intent is good. But you know what they say about good intentions — aside from paving the way to hell, good intentions aren’t enough.

Credibility, and being leaders people would want to follow

A Facebook friend shared a video of a TEDx talk on leadership. And it starts off by posing the question why would anybody follow you. And I think this is something leaders should ask themselves. And if the reason is just because  “I’m the boss. (mic drop, gangsta pose)” then that’s not leadership to begin with.

Leaders should ask themselves this question — why would anybody follow you. It’s not about being insecure. It’s about empathy and understanding that most people are driven by purpose. It’s about finding out how you can be someone people would willingly follow.

Below’s a link to the video and some excerpts:

“…If you want to lead others, they’ve got to believe that you’re credible. They’ve got to believe that you’re honest, competent, forward-looking and inspiring. You can ask yourself how would people describe me. And you can ask yourself, in my behaviour and in my actions: Do I demonstrate to people my honesty? Do I demonstrate to them my competency? Do I demonstrate to them my enthusiasm, my passion? Do I demonstrate for them what it is that I care about?

We need to be able to tell the truth. We need to be clear on what’s important and why it’s important. And we need to be able to make sure that we act in ways that we say: we say this is important, we follow through with that. We need to continue to develop ourselves, our competency.  Our competency is an asset that appreciates over time. You’ve got to keep filling it up. And leaders are great learners. They’re always open to wonderment and always open to trying to learn more things that they can get better. Good enough never is. You’ve got to be willing to show your enthusiasm, to show your passion. … Show your enthusiasm. Be willing to say: I’m excited about this, this is important, this is significant. And you’ve got to be willing to take a stand. You need to be able to express an opinion. …You need to believe in such a way that other people will believe that you believe and will in fact be infected by your enthusiasm. … The simple truth is this: People will not believe the message if they don’t believe in the messenger.”

Bugs happen — learn from them

So for the past couple of weeks, our team deployed updated versions of our app into production to address some interesting issues. But of course, when we were in the midst of trying to address them, they didn’t seem so interesting then.

Issue 1: Login would fail *sometimes*

Apparently, we were using an old LDAP server that was on its way to being decommissioned. You’d think getting our app to point to the updated LDAP server would be the needed fix. Well, technically, it was! But in the course of deploying, a new version of nodeJS got released wherein one function our app was using got deprecated. This then caused problem in saving records which we hadn’t anticipated when we did our impact analysis. The lesson is not to skip on the smoke tests even though the change seems quite straightforward.

Issue 2: We’ve deployed a new version but the browser keeps using the cached old version.

We typically find Chrome more reliable than IE. But this time around, we found that IE was the one behaving as designed / implemented / intended. Despite the initial setup not to cache, Chrome was still using an older version of the app even though we had already deployed a newer one. It also didn’t help that we kept on clearing our cache during testing so we had always been getting the latest version. The lesson here highlights the value of having a staging environment that is a mirror of production — this way we’d simulate what prod users would encounter when the new version gets deployed. Also, another lesson is to test in another environment where we don’t keep on clearing the cache since prod users most likely won’t be clearing their browsers as often as we do while doing integration testing.

Issue 3: Error on saving a particular profile record

One of the standard test cases from where I previously worked that I somehow carried with me (most of the time) is to check for whether leading and trailing spaces are trimmed when saving data in forms. For our app though, we had to previously make a decision to ship or delay, and opted to go ahead with deployment with that bug still open. Extra spaces in the field values didn’t seem critical compared to not having the app at all. Little did we know that spaces entered into a particular field would somehow cause a circular reference in the json formed to submit the data and cause an error in saving and retrieving the data. Thankfully, the impact wasn’t so bad considering we only had 1 instance of this issue out of around 300 records that had been created or modified. Lesson learned here is well not to skip trimming leading and trailing spaces if you can help it and to test for the impact of spaces in your test data.

So there. Bugs happen. There’s no such thing as perfect software. There’s no sense in kicking yourself endlessly over bumps like these. What’s important is to get some learning out of instances like these and to keep on moving forward.

Not every new thing is an innovation

My friend Alice shared that she conducted a talk and shared that they were using so-and-so tool in their project, whereas typically projects use this other so-and-so tool. That seemed to have wowed her audience and they said that could be considered as an innovation. Alice and I agreed that it felt like it wasn’t. Unless you’d call it an innovation if I suggested to use Google Docs as opposed to Microsoft Office.

But isn’t innovation simply a new idea, device or method? Something new that will make things easier for yourself and others? Yes and yes. But taking that definition kind of opens the floodgates where anything new could be taken as innovation — which shouldn’t be the case because not every new thing can be regarded as truly innovative.

In googling what is not innovation in the hopes of getting more insights on this, I found this whose points I do understand:

First, an improvement that only meets the market standard or reacts to innovation that your competitors have already introduced into the market is NOT innovation. It’s playing catch-up.

Second, introducing an improvement that does not significantly differentiate you from your competitors is NOT innovation. It’s simply just an improvement—evolutionary, not revolutionary.

And finally, introducing improvement that may give you a competitive advantage but also can be easily copied by your competitors is NOT innovation. It’s just a temporary advantage.

…Here’s the takeaway: It’s easy to confuse improvement with innovation. But only innovation creates a unique outcome that, despite the superior financial returns resulting from the action, competitors are either unwilling or unable to match.

Now, innovation or not, I still believe in looking for and sharing things that helps us make things easier for ourselves and others. Whatever ideas we put onto the table and help realize, just push for it if it holds the promise of making things better. And you can just let other people decide if it’s an innovation or not.

Looking for that singular statement

There’s been some recent talk about vision and goals where I work, and that has somehow led me into thinking about what I personally stand for (at least professionally). Or maybe it could also be because I watched Batman v Superman last weekend and there was this scene wherein the lady senator wants to know what Superman stands for. Anyways, I tried to give it some thought. The truisms and platitudes that I often say crossed my mind. I thought of my default thoughts and my fave quotes. But it’s hard to capture what I stand for or what I’d like to stand for in a singular statement.

Be kind. Play fair.

Let your work speak for itself. Keep on learning. Keep the saw sharp.

No, not quite. Each statement doesn’t quite cut it.

Then something hit me. 16 years out of college, and it hit me! I don’t think I’ve ever been the type who’s so overly gung-ho about graduating from our state university. But I realized that the singular statement I was looking for was in our school motto all along:

Honor and Excellence.

Honor. This captures how it’s not about winning all the time, but more importantly it’s how you played the game. It covers honesty, integrity and respect. It covers selflessness, doing what is right, and giving credit where it’s due.

Excellence. This highlights competence. It covers knowing your craft and continuing to learn to be better than you were previously. It covers setting the bar high. It covers uncompromising standards. This also extends to paving the way for others to excel and being a spotlight to others when it’s their time to shine.

Honor and Excellence. You need both. It’s not one or the other. This means being good at what you do without the needless assholiness. This means rising above others while still remaining grounded. This means expanding your mind, capabilities, scope, or whatever; without getting so full of yourself.

This is a good reminder of what I’d like to see more of in myself, and what I should reward or encourage more in others.

Read: Leading the Transformation

Our product owner is one of the rare few individuals I know at work who actually still reads books. Last month, he recommended that we read Leading the Transformation: Applying Agile and DevOps Principles at Scale by Gary Gruver and Tommy Mouser. It’s a thin book with only 112 pages on paperback and around a 3-hour read. It’s intended for leaders/executives so it gives a high level overview of the changes teams and the organization need to make and the benefit of those changes, and it repeatedly emphasizes management’s role in pushing for those changes. In particular, the changes that they want to drive at center around Agile, DevOps and Continuous Delivery (CD).

At work, small teams have now been shifting to Agile, our own team has been in this Agile project since January of last year, and I’ve heard of proposals wherein the methodology they suggest is already Agile instead of Waterfall. But then, I pick up from the book that trying to scale up Agile adoption across the board with small teams as the starting point doesn’t quite work for large organizations. Whoops. The book suggests that if you want an enterprise-level change, you have to plan for it and drive it from the management level down to us lowly minions. A key difference though is that within our organization (at least locally that I know of), we don’t really have hundreds of developers working on the same product or code base. And in our case, we’re only under 20 in the team, but even so the book still offers a good introduction to a lot of mature development practices that we need to look into.

Key items highlighted in the book that I’d like to reiterate further:

Importance of having quick feedback loops

Unit tests and static analysis tools can already weed out a lot of problems so that defective code won’t even get committed to the repository to begin with. And having those fixes done even before passing it to the test team — instead of fixing them only after the code has been deployed and testers found issues that were caused by those defects — will definitely help reduce the turnaround time.

Quick feedback loops will also help the team work and resolve issues while the code or user story is still relatively fresh in their heads. It’s more difficult for both the devs and testers to fix and retest an issue on a behavior that they’ve pretty much forgotten about.

Having builds as release- or production-ready as possible

With regular and stable builds in place, it’ll be easier to identify when a commit breaks the build. Since you don’t have to backtrack through days or weeks of commits, it’ll be easier to narrow down and identify the problematic commit.

Having dev/test environments as close to production as possible

One problem that we’ve personally encountered in not having a test environment in sync with the production version was that whenever we encountered an odd behavior in the test environment we had to double check whether the issue was also in prod. We also had to be mindful of issues that were already resolved in prod but not in the test environment. But I guess this problem is a combination of why it’s good to have the test environment as close to prod as possible and the next item related to why it’s good to have good deployment procedures in place.

Having repeatable build, deploy and test processes

From experience and the example above, having a reliable and repeatable deployment process could’ve saved us all effort and heartache. It could be so frustrating to test the same build (supposedly) but then get different outputs even if you’ve done the same steps using the same test data. In the same vein, you’d hate for a feature not to work in prod even if it had already been thoroughly code reviewed, tested and signed-off in UAT/PO review.

And last, but not the least, having test automation

You simply will never achieve the full benefit of Agile development until you get your automated testing properly built out and integrated into the development pipeline.

Test automation is key to the first item I mentioned since it enables quick feedback loops. It also allows repeatable tests to be executed across the different environments, and it allows repeated execution of the regression tests which you might not be able to afford to do so manually.

Having test automation, by itself, will not suffice. Tests have to be designed such that it’ll be easy to localize the cause of failed tests should any be encountered. Maintainability of the automated tests also have to be considered. Otherwise, the benefits of test automation won’t be realized since the team ends up ignoring the test results on account of being not sure whether the issue encountered is a code issue or a test issue.

One last thing… it’s a cultural shift

You can’t just invest on tools for CD or test automation or announce “Let’s do the Agile thing”, and expect the benefits to magically follow right away. This kind of thing takes time because there’s the technical learning overhead, plus shifting to a new way of doing things requires discipline and resolve so that folks won’t revert to the old habits that they’re trying to change.

It is important for executives to understand early on if the organization is embracing this cultural change, because if it doesn’t, all the investments in technical changes will be a waste of time.

It’s not going to be enough for the project team alone to be invested in the changes. The management and executives need to be aligned with this. In fact, they should help drive it. Otherwise, they might give demands that would bypass the adoption of change and instead force people back to their old habits (just because it might appear faster but only in the short term).

The book, after all, isn’t entitled “Leading the Transformation” for nothing. Management’s presence and push isn’t merely a suggestion; it’s a necessity. Sure, the project teams are the ones making the technical changes; but management needs to understand and support the changes. Essentially, people need to be in the same page in order to move in the same direction.

Finished reading: Managing the Test People

It’s a quick and easy read as it promised to be. I’m not a manager and it’s not something I’m planning to be. But I am somewhat in a position of leadership so the book is still quite relevant to me. Judging by how much I’ve highlighted in the book, it’s undeniably quite relevant.

I’m also working with younger folks who I believe have great potential to be leaders. They can be even better leaders than who we have at the moment, but only if they’re positively influenced by the right mindset on both leadership and technical aspects.

I’d go recommend this book to them since the author really paints a great picture of a leader (or manager) to aspire to be. And with its focus on testing teams — or technical teams in general — it’s a perfect fit for us. Reading the book raises the bar for our expectations on managers but only as it should be because we can’t expect nothing less than for our managers to lead and empower their people. You also get insights on how managers should (better) deal with things. But more than that, and I guess what’s most important, you also get to pick up and be reminded on how you should be as a leader (even if not by title).

In closing, the author shares:

Stay on the right path by frequently asking yourself, “Am I being honest? Am I being consistent? Would I want to work with* me?”

*Originally “for”. But since we’re not bosses or managers, “with” seems more relatable.

Maybe that simple level of introspection — especially on that last question — is what we all need to remind us to be first and foremost good colleagues or team mates before even rising to becoming good leaders.

On valuing your time, Maker’s and manager’s schedules

Time and again, my hate for useless meetings seems to keep on drawing me to Paul Graham’s essay “Maker’s Schedule, Manager’s Schedule”. (And also, I did tell a friend I’ll go share this link with her). Every time I read it, I couldn’t help but agree to a lot of the things he said. So much so that I find it hard to cite just one particular line to quote here in this post. You really just have to read the whole thing yourself.

To me, this essay is a pretty good reminder of what we should all be doing (just in case I’ve lapsed, and have been setting meetings or following up like there’s no tomorrow), and that is to respect my own time and other people’s time. In doing that, you make a more conscious effort to (well, if i can help it):

  • avoid interrupting or disturbing people unnecessarily
  • express gratitude when someone obliges you with their time
  • be present in meetings where your inputs or feedback are actually needed
  • set up meetings with the implicit target of not wasting people’s time
  • decline meetings I’m pretty sure I won’t be engaged in
  • decline meetings when they’re in conflict of personal commitments — Those are just as important (and sometimes even more) as work commitments
  • honor commitments to yourself — Ages ago, I had to block of time just for my lunch or dinner, and I even missed that because of work. That just isn’t healthy. Also when you block off time to work on something, then use that time to be productive.

Discipline on how you manage your time or own your own calendar starts with one’s self. And how badly your time gets mistreated by others (and even by yourself) highly depends on how much you’d allow it. So for your sake, start respecting and managing your time.

What makes them leaders I want to work with

So leadership happens to be one of the things I think about, you know, just for fun. I’ve been working for quite some time now and I’ve had my fair share of leaders — some by title and some for real. Now, I don’t want to dive deep into my memory banks so I just thought of two leaders I’ve had the good fortune of working with recently. One is my former manager, Eric, and the other is my current project’s product owner, Maneesh. I posed the question: What about them makes it feel like it’s worth it to follow them?


They aspire for great things. They have an idea of what they want (or at least they seem to). You know they already have a picture of what they want to achieve or some sort of a plan in their heads (or at least it feels like it) so it doesn’t feel like they’re waiting on you to hand them the answer on a silver platter. More importantly, they are able to communicate their views clearly enough to get the team’s buy-in.

What you say matters

When they ask for your inputs, it doesn’t feel like they’re just asking out of courtesy (well, they could’ve been but you couldn’t tell). When you raise a concern, it doesn’t feel like it went in one ear and out the other. You go out of the discussion feeling like you’ve been heard.

Ego is thrown out of the door

They don’t insist on being right all the time. So if you happen to have conflicting ideas, they’re willing to hear you out and they’re also willing to explain where they’re coming from. The focus is on the problem that needs to be solved. So it doesn’t matter if you’ve disagreed on some points midway — what matters is you agree on a solution in the end.

Follow through

When something needs to get done and they’re the one who needs to do it, they act on it right away. Of course, you understand that they’re busy with a lot of other stuff but you can still count on them to follow through — without the need for multiple follow-ups from you.

Clarity, transparency and integrity

It’s hard to pinpoint if one is just the effect of the other. Or if they should be separate points instead of bundled as one. Either way, these three make it easier for us to understand the reason behind certain decisions or actions. Things don’t come in as a surprise (or a shock) because they’re communicated clearly, discussed openly or aligned with some bigger plan or purpose. What’s been done is congruent to what’s been said. There’s little to no room for second guessing or thinking “Oh, he probably means well…”

Your success in mind

Maybe it’s just me, but I think to have your success in mind is a basic expectation from your managers. Of course, I also expect that people help themselves but managers have the role of removing impediments on your way and setting you up for success. I don’t want to work for someone who just passes the buck (delegation doesn’t always equate to “empowerment”) or throws you out to the wolves.

As for our product owner, I expected that his focus would only be on the product that we’re working on. But for him to express interest in our career progression or on us maturing in our practice, that was something. I do understand that if we do improve ourselves, in turn we’ll provide better service to him. But what I like is that he considers wins for both sides — ours and not only his.

Coincidentally, there’s a buzz in the team on the “growth mindset” — the thinking that you just have to work at something hard enough in order to succeed. But while I understand that it is hugely up to the individual to drive his own success, you can’t discount how it’s also a matter of a bunch of other things including leaders who truly empower and enable you. I guess the paragraph below from this post states it much better:

“Ultimately, I’m convinced that there’s great power in starting from a place of believing that all people can improve themselves if the conditions are right, and I think that’s what Kohn is getting at when he worries about the growth mindset ideology being co-opted by personal responsibility advocates. Human beings are not vacuums. We rely on family, teachers, economics, societal expectations, and a range of other factors beyond ourselves to contribute to our success. The notion that personal responsibility is the only condition that matters for success, or the most important one, is just plain false.”

That’s about it

So those are just the stuff that’s on the top of my head. Ultimately (I just had to use “ultimately” myself), I think the best relationships are the ones that don’t feel forced, and that also goes for you and your leader. I guess one last thing I can add to the list is how they didn’t just ask for my respect — they earned it.