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!