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!

What Do Developers Want?

As a "retired" developer myself, I understand that developers aren't always motivated by the same things as Business Analysts. BAs, as representatives of some form of "customer", are responsible for meeting that customer's needs. Developers, well, are different. In most cases, developers just want to produce solutions to problems. How they arrive at solutions can be widely variant.

For one of my assignments, I was well aware of conflict within the team, so I made it my first objective to figure out what was on each team member's wish list. By doing so, I learned what motivated them and could tailor my approach appropriately. With my current project, I'm feeling a little out of the loop, since the Project Manager wants to handle our current situation with the developers. So, I'm just trying to think how I can "coach" her a bit on how to motivate our developers. So what do you think? Have you ever tried the "wish list" approach? What has worked for you?

Testing Tribulations

Today we handed the defect log of our testing back over to our customer to review and assign priorities. Unfortunately, he chose to discuss the defects with the developer. Why is that bad? Because if the customer is asking which defects are quick fixes, versus determining the ones that provide the most value, we are wasting precious time. Besides the fact that in the process, the customer has pulled the developer away from working on the next highest priority item, if he's constantly popping questions on the fly to our developer, then it's interrupting and causing wasted ramp up time to get back up on what he had been working on. Besides, that, the developer gets the message that the easy fixes should be done sooner rather than later. There is nothing preventing that developer from jumping in ahead and working the small stuff, when there are far more pressing things that will need his undivided attention after the BAs have reviewed the priorities.

You may think I'm being trivial, but for every interruption, it takes a developer about 20 minutes to ramp up. So, with 2 interruptions, the developer has to ramp up 4 times and at 20 minutes a change, that's fast approaching an hour and a half of precious time. How did I get "4?" Think for moment. I ask you a question, you take time to think about it, get all the facts together, we are at 20 minutes. But when you answer the question and return to what you were doing before the question, that's another ramp up that occurs, another 20 minutes. This is why we try very hard to prevent our customers from direct contact with developers during development phases. It's only in the best interest of the project and in the name of "efficiency."

As part of our role as BAs, it's key to the project to teach these concepts to repeat customers. It'll absolutely streamline your development process. Of course, that's assuming you have a good handle on requirements.

Cha Cha Cha Changes...

Some people might call me "crusty" while others call me "visionary". So many things are changing around me and I seem be pulled in so many directions right now. My new team's lead is moving into a new position, while my old team's lead is getting married next month. The manager at my old job wants to meet with me, and my new job now requires some additional responsibilities for me. The best part, I'm excited by this. It's really nice to think that perhaps I'll be asked to return to the job I loved, but was laid off from. Additionally, I seem to be in a good position where I'm at, even though it is still a contract job. I'm certainly not a visionary right now, but the crossroads are in sight. Wanna ride along?

Different Strokes

With one iteration of work done, I'm enjoying thinking about how each BA has such a different personality and approach to their work. One is a powerhouse who drives the work very deliberately and yet injects humor creating an easy-going atmosphere. He talks very candidly about what he expects and where we need to be, then he grins widely and waits for the conversation to take off. He's highly interactive and is able draw our shy IT guys out of their shells.

Our second BA is a note-taking maniac, who is a master manipulator (in a good way) and has a way to make everyone feel extremely valuable. She's adorable and plays the ignorant role to extract more information from our SMEs and IT guys. She really is very smart and her recall is great. Additionally, her patience borders on the insane. So when a developer makes a claim that doesn't seem quite right, she refers directly to her notes and reads it back, but with a sweet tone. She really wouldn't hurt a fly.

And the last BA on the team, but not least, always asks questions that lead people to think from different perspectives and exposes flaws in logic while celebrating every win. Her research is thorough, and she will flesh out details and check facts until she is absolutely satisfied. At the same time, our SMEs love to work with her because she's always prepared and respects their time.

Their personalities blend together with their own styles to create complimentary business analysis processes. I've purposely allowed them to use their own style and approach, so that they can "own" their work. I plan to continue this study and share whatever this symphony becomes from here.

Press Conference

Have you ever been the main attraction at a press conference? Yeah, me neither. Today we celebrated the completion of an iteration on our project, still in the "green" and going strong, so when I was introduced as the BA Lead for the project and two of our program level execs jumped directly into questions, I felt like I was suddenly thrown into a press conference. Yes, the team is wonderful and we enjoy helping each other, and no one is overly protective of their work. I was lucky to have already been engaged as a contractor for a set of work when this project arose, so I "fell" into the Lead role and LOVE IT! We have a culture where your assigned work can be shifted with no judgement about previous work, and while we do have some conflicts, we aren't afraid to talk through it and arrive at the other end stronger.

How great it is to have the ear, even if it was just for a couple of minutes, of some high level execs. And now I can claim that I've gained some experience in a press conference, even if it was just internal to our program. Can't I?

Shyness and the IT Professional

On our project, this week, we reached a major milestone. Today, our first major deliverables were scheduled to be completed, but yesterday, things didn't look very promising at all. The developers couldn't (or wouldn't) show us a demo, and couldn't provide my BA team with testing materials, and wouldn't meet with us to review our test plans. The Project Manager (PM) and I could do nothing but hope this was a case of "Hero Syndrome" where developers hold out delivery to rake in the glory when they do deliver on the deadline.

Thankfully, they did deliver, but nonetheless a few gray hairs were also achieved. This story repeats with nearly every project I've ever been privileged to be a part of. So what is really happening?

In this particular case, we discovered that the customer was working directly with the developer, so what we saw today had some very distinct differences from what the BA had documented as being needed. The BA was instructed NOT to "distract" the developer and could only attend meetings to extract what she needed from those. 

The result, we have a web site without any idea where the data is sourced, unsanctioned and simply not entirely what was approved. And in order to set it back on course, all documentation has to be reworked, setting us up to be behind schedule for the next iteration.  We realized this week, that the development team and the customer had never worked with BAs before, so they didn't understand our role, and they unknowingly introduced complications to the project. 

I've dramatized this more than necessary and it's nothing new to most, but I have to wonder, too, if some of the problem is shyness, too. Our developers and the customer sit within a few office cubes of each other, so the customer was constantly dropping by and "checking in" on his web site, while the BA sat 2 floors away and asks a lot of questions of both the customer and the developers. With a looming deadline coming up fast, they thought they could expedite the process by working directly with each other, when the BA had captured a lot more information about the company's requirements, which are not presently delivered.

Some of the smartest people in the world suffer from varying degrees of Social Anxiety Disorder. In a world where we value extroversion over introversion, this creates a culture where shyness is undervalued. I would hope that if we truly embraced our SAD-inclined developers more, that BAs might have had more opportunity to curb this diversion and made more progress. C'est la vie!

Jukebox Mentality

What happened to the jukebox mentality? I'm not really old enough to have been a member of the generation of poodle skirts and slick hair. I do remember a certain vintage diner where anyone could drop a coin in a machine and wait in queue for our favorite song to be shared with the entire place. And our excitement filled us with such joy, that we'd dance in the aisle and sing along with the tune.

My family always found music an important tool of expression, a form of communication, and therapy for what ails your soul. A few days ago, when my daughter informed me that she didn't like music, my heart ached for her. I held on to the hope that perhaps this wasn't real somehow. Has the proliferation of MP3s and cell phones, where music is a click away dulled her?

So my new personal project is to learn how to encourage an appreciation of music and help her find music that speaks to her. Perhaps I could rent a jukebox somewhere?

Recipe for Great Brainstorming

A very important tool in the toolbox for a Business Analyst is the brainstorming session. I typically have a framework for the session to provide some broad boundaries that allow me some leverage to reign in conversation, but usually don't enforce. These are just general rules such as "everyone has a voice," "rudeness is forbidden," "participation is mandatory." Don't worry about them. If you have professionals in your session, they often recognize when they are "out of bounds" and police themselves. I also like to have a children's toy, such as Legos, that offer some creative outlet. Often people aren't willing to open themselves up initially, but when you offer up some toys, it demonstrates that silliness is welcomed. You may have to start the silliness. Throwing Nerf toys at each other creates an atmosphere that promotes light-heartedness and opens people up to throwing out ideas freely. Additionally, if someone starts to close up, I'm very liberal with comments like "I think I know where you are going, so let's explore that." Try gently drawing them out and ask questions.

I don't know how to conduct a brainstorming session without sticky notes. Every idea is written on a sticky note and given a place on the "wall" of ideas. After we get lots of ideas and the audience starts to quiet down, then start organizing the ideas. Group them in whatever fashion makes sense for your topic. Then ask everyone to talk about their favorites and justify potentially exploring those ideas. But keep all ideas handy, in case you need to go back to them if your chosen ideas don't survive a few tests later on.

This approach to brainstorming may or may not work for you, it depends greatly on your personality to pull it off well. I believe wholeheartedly in developing your own style and techniques. But let me know about your experiences. I love to learn. Please share!

Laughing at Myself

As a BA Lead, I now have 4 analysts working for me. One of those is just like me when I was in my twenties. She's fiesty, funny, and does things her own way. All I needed was a template of a Traceability Matrix filled out with a small group of BRDs to help me track down where those BRDs are in the process. She went completely overboard and captured all kinds of additional information that was already documented elsewhere. She didn't know about the other documents, and it would have been great, except we had already done the work she decided to do on her own. If that had happened to anyone else, I would have lightheartedly joked about it, and moved on. But, because I know I would have done exactly the same thing at that age, I just laughed at myself. Was I really that ambitious? I'm sorry to say, YES! And if I get upset, I'm really just upset at how silly I looked when I started doing this kind of work.

The Starfish Team

This week, I witnessed the power of leaderless teams when our Project Manager fell ill and we were left to manage the work ourselves. The team stepped up their games, made smart decisions and never stopped. In the process, they also began to notice where constraints kept us from moving forward on some tasks, and they found other tasks that will be required and worked those while they waited for obstacles to clear. I myself fell ill one day, and they rose to the challenge.

In the book The Starfish and the Spider: The Unstoppable Power of Leaderless Organizations by Ori Brafman and Rod Beckstrom, the authors explore decentralized leadership. When you hire the right people in the right jobs, and share a vision, business goals and ownership in the work, there is little need for traditional leadership. For us, the change came when executive leadership asked questions about the project methodology were we following. They immediately instructed the team to throw the methodology out the window and just get the work done. My manager called it the "GSD" methodology (or "Get Stuff Done", with a substitute for the middle word). We quickly refactored and removed steps in the official methodology of the enterprise, and cleared more than 12 obstacles. The Business Analysts quickly adapted and sent 4 BRDs into development (who had been relatively idle, waiting for approvals on requirements). So now that each group in the whole application development process has work, the obstacles removed (for the most part), and adapted to change, I think this team is working extremely well together.

So when our key leader, the Project Manager, unexpectedly stepped out, everyone rose to the occasion, and filled in where needed. Where a "spider organization" would have lost their stride, this "starfish team" demonstrated great strength of character and kept the project on track. When I spoke with our Project Manager on the phone, and discussed the situation, she commented that this was the first time in her career, where she felt completely confident that the team would deliver for her and the enterprise. No greater compliment than that!  

Mining Coal - Tough Lessons to Learn

Leaders of any kind, can learn a lot from coal mining. I've been watching a new series on Spike TV called "Coal" where a couple of guys buy a coal mine and the series documents the struggles of coal mining. The balance between technical, mechanical, psychological and medical challenges occur every day. Presumably, the primary goal is to cut tunnels of coal from the mountain, however they quickly learn that there is so much more. From extreme risks to man and machine, and issues with weather and power, this is a series that anyone with ambitions to be a leader should see. And educators could use the series to illustrate the ethical decisions that face most managers.

If you've seen the show, please share your experiences as they relate to something that occurred on the show. I'm watching, so I'll be happy to discuss with you.

A Whole Lotta Crazy Goin On

With Financial Reform requiring all kinds of new processes and practices in the financial industry, you'd think that perhaps an Agile approach would provide the tools needed to respond to the constantly changing laws. We discussed ad nauseum, why Agile is required. With literally thousands of new reports that have to be produced, Financial Reform has certainly created jobs where I am. We have analysts with compliance, finance, technology, data warehousing, archiving, administration, data stewards, and many more working on the project. How will we keep track of everything that's going on? Unfortunately, the only thing Agile at this point is that we are having scrum meetings daily. It's still early in the project, so hopefully we'll arrive at more Agile processes, but for now, we are just storming. First, we are getting to know each other, figuring out who has what skills, and leveraging talents as much as we can. Follow this blog as this project takes on a life of it's own and perhaps, we'll find some new great tools and learn together.

Throw the Rule Book OUT!

There are TONS of books and methodologies about how to be a Business Analyst, but in the end, you have to make the call. Evaluate the personalities of every member of your team. What are their motivations, their desires? Tailor your relationships to them accordingly. That's not to say you shouldn't study the wide variety of techniques offered by different methodologies, but a fully XP approach will not fit most developer's personality or approach to work. Most of all, try to set your team up for success. Learn to recognize their needs and use that as a tool to celebrate when tasks are completed. It's about results, not about how you get there, after all.