Writing My Professional Credo

As a contract Business Analyst, I've been working in some interesting places with different philosophies about development. So, I've decided to write my own credo for working with the real development talent... the programmers.

#1: I am not my code

For developers that put their "all" into their work, it's important to let them know that if there is a problem with the product, it's not a reflection of their individuality. The work is a team effort and everyone plays a role. You know you are successful at this, if people are asking for help, and others are stepping up to help out.

#2: The mind is amazing. It automatically adjusts the road rules to justify what we do
Everyone on the team processes information differently, so it's important to learn from each other. It's exactly  why the end product might just be better than anything one person could ever think of. Use that to think creatively and build smarter solutions. Challenge ideas, but be prepared to give support to the reigning choice.

#3: As Business Analysts, it is our job to DO the hard and discern the impossible
I've always taken the approach that the BA is the Administrative Assistant to the project team. If something isn't getting done, no matter how hard or tedious, the BA should get it done. If it can't be done, then find a workaround or make the case to take a new direction.

#4: Habit is "read only" memory

For me, it's a talent to know when to use best practices and when to break out and make a change to processes.

#5: There is always someone smarter than yourself

Regardless of industry, everything changes and it's important to stay in touch with others who may know more. Read the industry magazines and web sites, and talk to other people.

#6: Garbage in, garbage out

Product quality is directly related to the raw materials used in development. Strive to use the highest quality components and data possible. Every company tolerates different levels of quality, so make sure you understand what those thresholds are before trying to implement quality assurance practices that are too far above those quality measures.

#7: I accept that I will make mistakes, but commit to learning from them

Mistakes are a waste only if you don't learn from them. I've even been known to "take the hit" for a developer who did something wrong, admitted to it, and took accountability for it. I protected them, maintaining their anonymity, just to ensure that we move forward for the team.

#8: The only constant is change

The Business Analyst should always keep an eye out for possible changes and be ready to provide analysis of the impact to the project(s) or product(s). Make sure that all the relevant information is ready for leaders to make an educated decision.

#9: Treat those who know less than you with respect, deference, and  patience.

If you have newbies on the team, make sure that their questions are answered, so that they can grow their knowledge. Often, I've seen those newbies ask great questions that end up taking the solution in a new direction. So, don't discount them if they haven't yet found the boundaries. They may pull out a gem that could be used.

#10: True authority stems from knowledge, not from position

On a high performing team, everyone is an equal, and feels like they have a voice. 

Reunions

This has been a season for reunions, for me. My former team lead got married, so my old team gathered to be with her at her wedding. It's also my 30-year high school reunion, held at our friend's ranch in the country. Both were amazing experiences.

I grew up in a very social household. My Dad was a minister, so parishioners were ever present in our house, in our community, in our lives. We lived on a horseshoe shaped street, so our yard was the shortest route to the grocery store. We had constant traffic through our yard, of people going to pick up some groceries, so our porch in the backyard, had visitors that would just hang out, night and day. As an adult, it became important to me, to have privacy. So, when there is some social function, I go through a series of qualifications, before I commit to attend. With all these reunions, it was tough to say "no".

It had been a year, from when I was laid off, to Christina's wedding. I missed them so much, but wanted to make sure they knew, I was happier and healthier. I worked with them for several years, so I went into a mourning period when I was released. To have them talk about how things were going for them, I knew I got the better end of that deal. I honestly hoped that they could handle the load without me, but it seems that its only gotten worse for them. So, I assured them that there are better things to come for them, too. It was a wonderful validation.

Then it was a week later for my high school reunion. In the past, the school reunions were not particularly enjoyable. For some reason, I had a desire to go this year. Thankfully, immediately upon arrival an old friend greeted me and I relaxed and fell into a groove of sorts. It wasn't just about having shed 30 pounds of weight (they hadn't seen me, after all) or about having a great job, because I'm a contractor, so it's certainly not a stable job... not anything to be excited about. So, I connected with people whose cliques may have prevented us from getting to know each other in our teen years.  It felt like time melted away all those barriers, and all I wanted to do was learn how their lives were going... about kids, work, music, etc.

Why is this relevant to this blog? We all carry baggage that time diminishes. If you are in a job that causes you stress, or is unhealthy for you, make a change. If change comes to you, approach it with faith that it's being presented to you as a challenge, and the real test is how you respond to it. And I promise to work harder to be more social and get out to see more friends.

Diva Developer

What's a good Lead BA to do with a Diva Developer? He doesn't bother to participate in Scrum meetings, and avoids attending any meetings in person. Fortunately, he reports to our stakeholder. Yes, I said our stakeholder, which should throw a few flags for you as you read this. If not, allow me to explain. When our technical lead decided he had better things to be doing than working on this project, our stakeholder took over the role of technical lead. I can't say I understand that, since the technical lead role requires some technical skills.  I certainly didn't have any authority to point out the hazards of that arrangement. It was just done. So, one of our developers now takes his cues from our stakeholder. Today, that developer insisted that he couldn't attend our Scrum meetings because it interfered with taking his kids to school. So, I moved the meetings to 9:00am, 30 minutes later. Funny though, since school only just started, so I don't know why the 8:30am time slot was troublesome all summer long.

When our new Project Manager joined our team about 10 days ago, of course we discussed a list of things that should change and this Diva Developer's attitude was high on the list. She insists she'll whip this crew into shape. It should be interesting since the top two items she's already had to defer. It'll be interesting to see if this Diva Developer continues his diva-ness. (What is the masculine for "diva"?)

Hungry for IT Work

It just so happens that my current project has almost no IT involved now. I LOVE technology. So, I'm preparing to hand this project off and move on to the next project, which my current manager is already working on. The vast majority of the current project work is to be processed by other business areas, so the three web sites we've already built are now the only IT-associated requirements for the project. I feel like I've completed my part and can leave the rest to the other analysts. So what shall I do next? The world is my oyster!

The Website that Should Never Be

In the weirdest turn of events on my current project, we built a website that the stakeholder never wants anyone to actually use. Yes, you read that correctly. This web site was built to meet an external requirement, and warns any users to contact our stakeholder before using it. It produces a lovely list of information, so it actually functions, but I struggle with "why" anyone would ever build something like it. What questions would you ask of that stakeholder, to bring to light the risks of such an endeavor? Why would we hire expensive contract resources for 3 months to build such a ridiculous solution? Let's role play!