The purpose of companies creating Business Analyst positions is to improve IT quality and efficiency while reducing project failures. When I first started as an Analyst, coming previously from the position of Software QA and having an education in technical writing (think documentation), I thought I was the perfect mix for the position. I quickly learned that having a job where I prove my worth through project success can be stressful.It’s because I am a perfectionist.
It’s a personality trait that I need to refine in order to become a great Business Analyst.
Don’t believe me?
How many times have you been working with a perfect project where your cost estimates are exactly correct, you’re completing all of your tasks on the exact day you estimated that you would and you perfectly understand your end users’ expectations?
If that describes you, wow! Ask for a raise.
But for most Business Analysts, we come in every day to a less than ideal environment. The better the BA, the more struggling the projects are that your boss will give you. And suddenly, each work day, you struggle with imperfections.
If you are continuing to strive for some sort of imaginary perfection in our analyst world, it’s time to rethink. When was the last time you gave yourself a pat on the back instead of zeroing in on feeling like a failure? Do you find yourself, too often, focusing on your mistakes and beating yourself up?
It’s time, instead, to stop. Take a step back. Evaluate.
In the last few years, we’ve been implementing the Agile software development process at work. Here’s our unique definition of how we manage it. On our teams, our Business Analysts serve as scrum masters, with the rest of the team consisting of product owners (end users), software QA analyst, and programmers. We schedule our iterations as either two-week or month-long sprints. At the beginning of sprints, we organize our stories with tasks and estimate our hours in sprint planning meetings. At the end of sprints, we hold a retrospective meeting to discuss, as a team, what went well, what didn’t and what we could do better.
One of the things I’ve learned about Agile is that we can focus on our imperfections and these can make us great! As is said, “stumbling blocks become stepping stones.”
Our quest for perfection is like the quest for the perfect spouse. Is there really a person out there who fits the exact list we made when we were young and looking for love? Or do we eventually settle with somebody who is a really good person that makes us happy? I wouldn’t know for sure because I’m still looking.
But I had a religious leader once tell me that all I needed to find was “Good Enough.” If I paid attention to the big things like integrity, work ethic, how the guy I was dating treated women and did he love children, then the rest shouldn’t matter so much. In the end, we all lose our fit body, we all get grey hairs, and we all end up a little hunched over from the weight of life. Don’t focus on what can be lost.
How does this apply to Agile?
We can focus on “Good Enough.” Mind you, “good” is a high standard, but NOT perfect.
When our end users approach us, we can offer them good enough. We can get this application out quickly, we tell them, with these main features. That will be good enough and then we can go from there. We can also focus, as a team, on one story at a time instead of cramming in as much as we can and letting our expectations exceed our outcome.
When our team gets together to review the end of each sprint or iteration, we can talk about “Good Enough.” Did we do what we could, as a team, to accomplish all of our tasks? Is our definition of done focusing on marking tasks as complete when they are good enough?
Do you have projects where you feel like you’re guessing? Everybody on the team is busy working, but who knows what the person next to them is working on? It’s time to have a “DTR.” Define the relationship. In dating, it’s the painful conversation where you put yourself out there to see if they like you as much as you like them.
This is where your sprint retrospectives come in handy. As a team, each sprint, we want to grow, we want to improve, and we want to share how we are doing this verbally. We can update our definition of done, redefining our good enough each sprint. As we move through development, we continue to add enhancements to the list of good enough as we send each new version to production.
It takes me back to the relationship metaphor.
Good relationships are those in which both people continue to review their feelings and verbally discuss how they are continuing to grow and improve on their “Good Enough.”
So is your agile project in a good relationship or do you need counseling?
When I first joined one of the project teams I am currently working on, we didn’t utilize the retrospective meetings well. Instead, they were abused. They were an afterthought. The project was struggling, but nobody wanted to spend too much time talking about why; instead, the team just wanted to move on to the next task and try and catch up. Next time will be better.
Sometimes the sprints went okay, but we weren’t excelling. Sitting in a meeting about how to be a better scrum master, I started to write down a list of things that went well on the project, things we didn’t do well and what we might possibly do better. Surprisingly, despite the struggles the team was having, according to our project tracking reports, I had a substantial list of things that went well. I was excited to share them with the team.
We finished up our sprint, things went okay. We then meet up for our sprint retrospective. I brought treats and right away, the meeting went well, of course. But we really did, finally, Define the Relationship.
And what happened in the next sprint?
We outdid ourselves. Before we knew it, we had completed everything and needed to get together again to assign more tasks. In the past, we usually deferred tasks that couldn’t be completed in the time box set out.
We deserved a high five. We were now in a good relationship.
Figure 1: These sprint burndown charts give a visual representation of how the team went from deferring many hours (top), to almost meeting their goals (middle), to excelling (bottom):
And what were the items we talked about in our retrospective? We listed all of the positive accomplishments of the team. They weren’t big accomplishments at all. They were just “Good Enough.” But armed with that positive reinforcement, team members excelled.
Perhaps we might change the title from a sprint retrospective to a “Good Enough” meeting. Like Stanford philosophy professor, Obert C. Tanner said, “We seek for a future better than our present best.”
Author: Lauren Campbell is an IT Business Systems Analyst for ARUP Laboratories and works part-time as a freelance technical writer. She previously worked for ARUP as a Software QA Analyst while they went through the difficult transition from the waterfall development method to adopting scrum, an Agile methodology. The transition, at times, felt like they were trying to replace the engine on their airplane while in flight. No casualties were sustained.
Note: Article image © monamakela.com - Fotolia.com