The myth of epiphany is that great ideas dawn upon you in an a-ha moment. Take for example the popular story of an apple falling on Newton’s head when he discovered gravity or Archimedes’ eureka moment in the bathtub. But what those stories seem to miss out is the significant amount of work that they’ve poured into solving related problems, and that it’s only when they took a break and let their minds wander that the answer came to them. We mustn’t overlook that there is work that leads up to those a-ha moments. There is a period of incubation where we try to digest the information that we’ve observed as we work on things, and our brains are catching up with all that’s been observed. Then if we’re lucky, the answer or the great idea comes to us at an instance that seems so out of the blue that it makes for a good story.
One quote from Ted Hoff (inventor of the first microprocessor, Intel’s 4004) said it best:
“… If you’re always waiting for that wonderful breakthrough, it’s probably never going to happen. Instead, what you have to do is keep working on things. If you find something that looks good, follow through with it.”
The Myth of Epiphany is from a chapter in Scott Berkun’s book, The Myths of Innovation.
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.
I’m grooming a team mate to become a test lead. What makes this role different from being a tester?
As a tester, your focus is on your test assignments. But as you become more senior (and not just when you become a test lead), you need to start looking at the bigger picture. Not just in terms of functions being tested e.g., you become more concerned as the system as a whole. But you also start seeing your purpose in the software engineering process i.e., you’re an integral part of it and what you want to deliver aren’t test cases or bugs but rather an application that has been fortified by your testing, an application that the target end-user will actually want to use. Software isn’t made to just make jobs for us who are in the business of delivering software. Software is for helping people do the stuff they need.
I guess I’m getting ahead of myself with that explanation and that might be too much to take in.
So a simpler answer…
- As a test lead, you need to be able to coordinate test tasks among the test team.
- There’s also a lot of admin work like you need to be able to note attendance or how to contact folks just in case they don’t show up.
- You also need to watch out for risks, dependencies, assumptions, constraints (or basically anything that could go wrong), and for issues (when things went wrong), and capture lessons learned. As a tester, you already do this but it scales up when you’re the test lead.
- You also act as a representative of the test team — if there are concerns that they hesitate to raise, you have to either encourage them to raise it or raise it yourself.
- You need to be able to initiate creation of templates, standards, guidelines, workflows that will help the test team do their work.
- You need to be able to review other testers’ work — be it test case drafting, test execution, bug reporting, status reporting.
- You need to be on your toes in case something tricky or complex comes along so that you can suggest options or strategies on how to go about with it.
- You also need to be able to take the blunt hits for your team when something doesn’t work out, because in a way you are more accountable if you’re the “lead” in general. You might think leads or project managers have it easy because most of the time it looks like they’re just doing reports or asking others to do the work. But when shit hits the fan and the team doesn’t deliver, someone’s going to look for a neck to choke and often it’s theirs.
Ok. That’s about all I can write this morning. Till my next brain dump.
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
I finished a couple of books last week, though I’m not sure if the 20-page “infoline” counts. So anyways, one is this infoline I read on “Creating a Modern Mentoring Culture” by Randy Emelo over at Books24x7. Here are just some of the stuff that I’ve highlighted for myself and for sharing:
Modern mentoring is connecting people across an organization to share critical knowledge and skills. Everyone has something to learn and something to teach, regardless of age or title, and people can be both mentees and mentors at the same time.
Key Pillars of Modern Mentoring
- Open and Egalitarian
- everyone has something to learn and something to teach
- different perspectives within mentoring communities and relationships help novel ideas and approaches arise in answer to organizational problems or issues people are facing
- Safe and Judgment-Free
- people don’t want to show perceived weaknesses by asking for a mentor
- Independent and Autonomous
- no need to try to control the amount of time people spend engaged in mentoring, the topics they connect around, or the people with whom they connect.
- Too much rigid control will only create unwanted barriers to knowledge flowing from those who possess it to those who seek it.
- Once you have created an enabling structure for modern mentoring, let your employees take the reins of their own learning.
- technology-enabled communication (email, online communities of interest, business social networks, mentoring and social learning software) is only on the rise and is a key enabling structure that supports modern mentoring
- Self-Directed and Personal
- Self-directed learning also allows individuals to learn what is applicable to them right now, gain skills that can help them with their unique work context, and make them more productive.
- means to connect with others and a space to collaborate and communicate
- allowed and encouraged to shift in and out of your mentoring program and of the mentee-mentor roles themselves, as learning needs and knowledge strengths evolve
If the open nature of modern mentoring is compromised by too much organizational involvement, the quality of mentoring connections and the caliber of learning that takes place as a result of these connections will be degraded.
Creating a Modern Mentoring Culture
- Re-Educate Leaders
- need to help organizational stakeholders understand the expanded and broad vision of modern mentoring and its associated benefits
- must be re-educated to understand that modern mentoring is a productive activity that won’t detract from employees’ effectiveness, but rather will help to strengthen it.
- Get the word out
- webinars or e-briefings, various media (podcasts, webinars, or newsletters), brief “commercials” at other training events
- Sponsor roadshows or lunch-and-learns where mentoring participants share their experiences. Offering a venue for mentoring participants to meet and mingle can help energize your program and provides another opportunity for people to network and make learning connections.
- Leverage employee resource groups, town hall meetings where a brief presentation could be followed by a question and answer session, Leverage your program’s evangelists.
- Modernize Current Mentoring Programs
- expanding your current mentoring programs and making them modern
- Onboarding – new hires
- High-potential development
- brightest talent pull from an array of mentors and knowledge resources [instead of just one mentor]
- allow high-potentials to be mentors themselves and share their knowledge with others while concurrently learning how to be a leader
- Augment your formal training initiatives with mentoring cohorts
- alumni of training programs mentor and advise a group of people currently going through training
- Peers going through the same training can also connect and share stories around application of concepts learned in class to help cement the newly attained knowledge.
- Amplify Using Technology
- Let employees use technologies you have available to communicate and collaborate.
- Make online employee directories or other skill profiles available to help participants see who would be a good mentoring connection.
- Allow people to join your mentoring program at any time.
- Acknowledge the efforts of those in the program.
When things slip, a typical reaction is to add processes especially for tracking and monitoring. Just take the overhead effort for effort tracking for example. I’ve been in a lot of projects that at one point or another have gotten so delayed. A knee-jerk reaction is to have the team prepare more reports — daily status updates from everyone, summarized daily progress reports from the leads, reports for upper management, reports for client, etc, etc. This has its benefits — it provides more visibility on what’s going on in the project, and it can pacify stakeholders since it gives the impression that you’re on top of things. What it doesn’t do is get more of the actual needed work done. It doesn’t get more work coded. It doesn’t get more tests executed.
Instead of just diving into the “more reports” bandwagon, what I’d like is for the team to look into how we’re currently doing. What’s working for us? What isn’t? What do we need to do differently? These are questions that usually get asked in a retrospective meeting. If we google “retrospective”, a definition that turns up is “looking back on or dealing with past events or situations”. Reflecting on what has happened is but a part of it. In retrospectives, you also try to identify what you need to bring forward to keep your project successful or to recover so that your project will (hopefully) be successful.
I think I can pretty much go ahead and do a little retrospective on my own. We all can do it individually. But that just won’t suffice. I can plan all I want but if the folks who will execute are not aligned with the plan, then the plan will just fail to materialize. And you can come up with all brilliant sorts of ideas and workarounds but if you can’t get the other guy to execute then it wouldn’t matter so much (but I’ll credit your brilliance, of course). Retrospectives need to be a team thing. WE need to come up with plans for improvement that WE are ALL willing to execute or follow through. In the end, there is no one else to drive the project’s success but US as a team.
I stumbled upon this deck again and it’s really something that I want to share to the younger ones. Time management wasn’t exactly something I learned when I was starting out. I came from projects where OT would become the norm at certain points, and we even had Saturday work. I was so time-poor. As I grew older, I came to realize how valuable my time is. How I could make up for losses for some things, but I can never get back time I have lost or wasted. And that the more efficiently I manage my time will allow me to spend it on things that matter more.
Saved myself some time by not writing my own presentation covering the same topic.
One of the points I like is #18 which had a quote from Jason Cohen (@asmartbear):
Only ever work on the thing that will have the biggest impact.
I think most especially for the younger ones, we often get sidetracked by initiatives or other non-project related tasks. We fill up our plate with a lot of things. We say “yes” to this and that. But then you have to think about it, step back and look at the big picture, and reflect whether the things that you are doing are really the things that you need to grow or achieve your goals. As an aspiring tester/technologist, are these tasks really relevant to making myself more technical and capable in my craft?
We’re three weeks in our current project. I know it’s still a period of adjustment for you. You have a lot to take in, and I’ve been asking you to do stuff that is new to you. I know things can be a bit difficult at first. You might feel overwhelmed. You might just want to curl up into a fetal position, hug your favorite stuff toy, and just wish everything away. I know, I’ve been there. And I’m here to tell you to not despair.
Sometimes it’s the fear of having to do something big that freezes us into inaction. We end up not accomplishing anything because our minds are too caught up at the scope of what we have to accomplish.
It is not because things are difficult that we do not dare, it is because we do not dare that they are difficult. ~ Seneca
When you feel like there’s too much in your plate, here’s what you can do. Take a step back, breathe in, breathe out. Don’t try to tackle everything at once. That’ll just be crazy. Find out what you need to prioritize at the moment, then focus on those. Try to break up the work into smaller bite-sized portions. Taking it one step at a time will make it less stressful and less daunting for you. Sometimes it’s just hard to get the ball to start rolling, but once kicked off, things get easier as you go along.
When you feel like you’re sinking, do not hesitate to call out for help. You must remember that you are not alone in this project. Your team mates are here, we’ve got our senior test automation engineer (Sr. TAE), and I am here (I’m not just a pretty face, you know). We also have support from our team leads and our manager. Don’t take asking for help as a sign of defeat or something that will be taken against you. That may be the case in other cultures or other teams, but I assure you that it’s not the case with me. But don’t take this as a cue that you can just ask for help anytime and every time. What I’d want is for you to learn how to help yourself first. And if you come to the point when you’re already doing your best and things are still not working out, that is when you reach out.
So there. I hope you don’t feel too overwhelmed. Know that you can rise above that feeling and that you have my support.
In the end, everything will be okay. If it’s not okay, it’s not yet the end. ~ Fernando Sabino, translated from Portuguese