LeslieJ.net

A few weeks ago I read a Harvard Business Review Blog Network article and tweeted: “@lesliejdotnet: Just read @HarvardBiz @dorieclark‘s “Five Things You Should Stop Doing in 2012″ http://t.co/O7PWthPu (12/15/11) #BAOT translation to come.” So, here is the #BAOT version as promised.

In the post Dorie elaborates on 5 key points in a general way, here I have borrowed her 5 key headlines for things to avoid in 2012, and elaborated in relation to the Business Analyst role.

“1. Responding Like a Trained Monkey” The take-away from the original article is about focusing on work and avoiding the triggers within society that force us to multitask (i.e. e-mail, instant messages, text messages, Twitter mentions, Facebook notifications, Words With Friends reminders, etc.). In order to do true requirements analysis (and many other key BA activities) its important to have truly focused time and attention on the task at hand. Taking time to tune-out of icons, buzzes, and chimes that plead and beg for our attention will allow us to complete higher quality work in shorter periods of time.

“2. Mindless Traditions” Regardless of the SDLC methodology your organization follows I feel confident that there are tasks you complete, documents you produce, or meetings you attend that truly add zero value. In fact, they may have a negative impact on productivity and morale. So, be a thought leader and a proactive advocate for optimizing the effectiveness not only of your BA processes and procedures, but of the overall SOPs for your organization. (Side note: I think the reference to sending Holiday Cards is a good one. This was the first year I had sent them out in MANY years and it was sort of stressful – and likely did not make much impact on the recipients of the cards.)

“3. Reading Annoying Things” My BA twist on this is really related to focusing on reading the right things. If you’re going to take the time to improve yourself, this year focus on increasing your BA Toolkit and expanding your knowledge of the many techniques a BA can use and the right situations when you should employ the techniques. This will immensely increase your effectiveness as an analyst and your street-value on the job market.

“4. Work That’s Not Worth It” Produce just enough requirements documentation that has the right level of detail at the right time and with the highest quality you can. The most important aspect of this is focusing on the true business value and benefit case of the requirements. Don’t let your project team waste time implementing requirements that are not really needed by the business and are more the wants, desires, and requests of the moments. Leverage the Enterprise Analysis skills from the BABOK® and make your IT team one that is a strategic partner for the business that only does the work that is “worth it.”

“5. Making Things More Complicated Than They Should Be” Stop the hallway conversations, skip the politics, be a transparent and candid BA that escalates risks, identifies impacts and dependencies and produces requirements that are concise, readable, testable, and unambiguous. This will avoid unnecessary complication on your projects and make everyone more productive.

Towards the end of the piece when elaborating on #5 above, Dorie references Eric Ries new book The Lean Startup and states, “developing the best code or building the best product in the world is meaningless if your customers don’t end up wanting it. Instead, test early and often to ensure you’re not wasting your time. What ideas should you test before you’ve gone too far?” I think this is important because it ties into the notion of Agile Development practices and honestly relates to more than #5 on the list of things to stop doing.

• Prototyping early and producing working software that your stakeholders can review in an iterative fashion leveraging Agile Principles helps you…
  • Avoid Work That’s Not Worth It
  • Stop Producing Annoying Things (aka Requirements) that other people have to Read
  • Escape Mindless Traditions of deliverables and documentation that do not add value to the SDLC
  • Cease Responding Like a Trained Monkey and working on all the features the business requests and starts forcing collaboration and partnership to add value to your organization

May 2012 bring you a great year of increased productivity and focus in your role!

Continue Reading

The Elevator Pitch is to the Requirements Benefit is inspired for you by the following tweet: ”@EntMagazine How to pitch your business in 60 seconds or Less: entm.ag/t52rAO by @carminegallo”

I’m out on my own now. I left the giant Fortune® 50 company I worked for. I’m talking to small companies about potentially joining them full time and I am loving the freedom. Beyond that I am immensely optimistic about the opportunities. So for many reasons you are seeing updates to the site, and for many reasons this post from Entrepreneur Magazine was engaging and relevant for me.

Relevant in what ways you ask?

• I have to be able to clearly articulate why I left a very intriguing and growing Fortune® 50 eCommerce team.
• I have to be able to articulate what I am doing now to add value to new clients (i.e. people that can give me money so I can pay my bills).
• I can always improve the way I approach business analysis (have you noticed I derive inspiration and ideas from many verticals and disciplines?).

After reading this article, I modified Carmine’s list of four questions into what a BA (whether Agile or Waterfall) should be asking of their stakeholders.

1. What do you do? –> What should it do?
2. What problem do you solve? –> What problem does it solve?
3. How is your product or service different? –> How is it different from what is done today?
4. Why should I care? –> What business value does it add?

Please note, I did make “stakeholders” generic above. I did this intentionally. I originally wrote “business stakeholders” but I realized in fact, that the IT stakeholders are almost more important because of questions #2, #3, & #4. As a BA we know all too well that our IT stakeholders are phenomenal at telling us “how it should do it” – but are historically horrid at telling us the answers to those remaining questions (why it should do it, the problem solved by doing it that way, how we can differentiate by doing it like that). Getting the true problem statement, differentiator, and value proposition out of the IT constituents will help us as BAs convey the importance and value of more technical requirements.

The Gist of the Article
Essentially the article, “How to Tell Your Business Story in 60 Seconds or Less,” conveys the importance of entrepreneurs having the ability to clearly summarize the value proposition of their new venture to investors in under 60 seconds. It really is important. I’ve had a start-up of my own and you have to have the canned statement ready when people ask you what you do and why they should believe in/trust you. (I can assure you it was not my dashing good looks that got me contracts when I was a geeky college student with a web development company.)  You almost have to have the story embedded into your DNA, its like having a tape recorder as a part of your voice-box and when someone asks you, you just hit rewind and then play again – spitting out the same paragraph over and over again. Carmine does a good job of emphasizing the importance of this, and offers a good suggestion for summarization (as noted in the list of 4 questions above).

The General BA Tie-In
I can’t tell you how many times I have spaced out listening to a stakeholder. And less attractive for me to admit, I don’t even want to imagine how many times people have spaced out listening to me talk about a requirement. (Notice there is no “s” on that – I truly mean a single requirement.)

If you, as a BA, cannot articulate the intent and benefit of a requirement in less than 60 seconds then you’re not doing the best job you can do.

• You won’t be able to effectively communicate with your executive sponsors or executive management if they ask about it. (Communicating at ALL levels of the organization is a paramount skill to possess.)
• Your developers will tune you out when you start talking. (They want direct, concise, to-the-point explanations of what they need to do/why they need to do it.)
• Your business stakeholders will likely perceive you as overly verbose. (They need the confirmation that you “get” what they are saying, what they need, and that you can articulate it for them. Not to mention, if you don’t elicit all of this information from your business stakeholders you are not doing your job,)

The Agile Tie-In
Requirements in agile are most often depicted by User Stories. They are a STORY – using the guidelines from this article allow you to frame up the majority of the information you need to convey within a user story, help you partner with the  product owner in order to understand true business value, and tell a story about the feature/capability of the system.

User Stories are also meant to foster the conversation. Remember, agile is about “conversation” not “documentation” – so internalizing these key benefits from an elevator pitch along with the primary aspect of a user story (actor, action, benefit) you can nail the communication during daily scrum sessions when team members have questions and you can succinctly summarize for team members during story review and story grooming sessions. The quickness of the conversation is also important. Iterations/Sprints are meant to be short, and very moment is valuable as you want as many minutes available for producing working software as you can get. The more concisely the requirements can be articulated, the more efficient the team, the higher the velocity, and the more business value gained.

Lastly, the User Stories should (if at all possible) be articulated from the end-user point of view. Asking these questions will get you to that level of detail and allow you to spin something around to showcase business value and benefit.

More context to come on my recent professional transition, for now I leave you with a note wishing you Happy Holidays!

Continue Reading

Last night there was boxing on Showtime. My husband likes watching it. I, on the other hand, am pretty good at sleeping through it. My slumber last night must not have been too deep though because I have a vague memory of talking to him during the match and this morning he certainly assured me that I did.

The conversation I am about to recap for you is a likely sign I am thinking a little too much about work.

Some History
The IT team I work with converted from Waterfall to Agile in January of this year. We are in the process of wrapping up operational enhancements that we call “Agile v2″ in the hope that we can address some of the gaps in the processes we rolled out at the beginning of the year. This has meant countless working sessions, process flows, and debates on the good - bad – and ugly of the way the teams have been doing theirwork. It has also meant receiving Agile-Purist advice from our Agile Coaches as well in order to help us keep true to the methodology we are committing to.

Last Night’s Conversation
As my husband tells me, in the middle of the match I started trying to explain to him that boxing was like agile software development. It probably went something like this…

Me: (picking my head off of pillow) “Hey, ya know, agile is sort of like boxing.”
Him: “What?”
Me: (sleeping)
Him: “Honey, did you say something?”
Me: “Huh? Yeah…Agile. It’s sort of like boxing.”
Him: “What are you talking about? Just go back to sleep.”
Me: (somewhat incoherently) “No, it’s true. Agile is like boxing because…[something nonsensical]”
Him: “Sweetie, you’re half asleep. You’re not making any sense.”
Me:(somewhat belligerently) “I am not sleeping, they really are similar because… [something nonsensical]“

There were probably some pretty significant pauses between my rebuttals and it probably continued on for several more rounds. This morning we got a good laugh about it, and he was convinced I was completely out of my mind. But of course I couldn’t stop thinking about it, and once I drew a parallel in my head I had to try and convince him that Agile and boxing really are similar. My rationale was that like agile…

• Boxing has rounds (similar to sprints)
• During the breaks between each round they talk about how it went (a retrospective)
• Before starting the next round they talk about what they should do (sprint planning)

Very simplistic, but at least amusing – and very likely I’m in need of a break from the office.

Continue Reading

This has been a year of learning. I’ve gone through several significant professional changes:

• Conversion to Agile: In January my entire department (all 200+ of us) decided to jump head-first into the Agile from the rather messy semi-interative/hybrid world we were in trying to managing nearly a dozen waterfall projects with moving parts and dependencies.
   
• Promotion to Manager: Now I’m officially leading a team a 20+ BAs
   
• Onboarding of New Leadership: Not only is there a new CIO of my company (from the business side of the company), but the Director of my department is brand new to the organization. Lots of cultural change.

The first of those has probably been the most interesting though. I’m passionate about Business Analysis, and I conceptual understood that documentation would be lean in Agile, but I never expected the phases of acceptance we have had to work through as the BA team for our department.

It’s Agile: We don’t Need BAs
As teams went through the training, a fantastic bootcamp with curriculum provided by DavisBase Consulting, many left with the impression BAs were an unnecessary part of the team structure. As a manager this immediately had me fighting fires. The majority of my team is made up of contractors and they all thought they were going to lose their jobs. I also knew the reactions of these individuals were wrong, so it was time to help our Agile Coaches and provide more context in order to get BAs back in the loop.

Less Than Adequate Involvement
After relatively short order we found that the BAs were being leveraged, but not for requirements elicitation, analysis, or validation – but as administrative assistants. Many were simply just writing note cards, rearranging the task boards, formatting excel documents. At least the Scrum Master’s were getting them engaged, but not in the right way. No matter how much the stronger BAs were fighting to do the right thing and I was trying to coach and mentor, we just wern’t getting any traction.

The Light Bulb Came On
It took a little longer than it probably would have, because much of the product backlogs for the teams were derived from existing requirements documentation written for Waterfall projects, but once the teams starting relying soley on the new user stories being produced by teams they had an ah-ha moment.

The teams were committing to complete stories, but once they got into the middle of the sprint and heavy into the coding they found all sorts of unanswered questions. As a result, the teams were failing to be “complete” on stories, velocity went down, and the everyone was getting frustrated. I wonder what was missing?

The BAs were getting engaged in the process, but they were trying to do all the requirements defined during the sprint where they were coding the functionality and they stories were simply not granular enough to fit within the 2-week periods. We were definitely making progress.

Getting Ahead
We aren’t there, nor am I overly confident any time in the next few sprints we will be, but the team is moving forward. The BAs are feeling engaged and the teams understand their value. We are just trying to adjust velocity and expectations in order to let the BAs get 1 – 2 sprints ahead and the team ensuring the backlogs are fully groomed and stories are ready for the team to develop against them.

The key strategy I am suggesting:

• Make Two Commitment Lists at the Beginning of a Sprint: The stories the team will code against, as well as the list of stories the team will complete “grooming” on.
  • Spread available velocity across both lists accordingly.
    • BA & UX team members will have most of their velocity allocated to the “grooming” tasks
    • Development & Testing team members will have most of their velocity allocated to the “coding” tasks
    • Both groups must reserve some of their velocity to ensure that all tasks are successfully complete, and at the end of the day, the “coding” tasks are more important because the completing stories for the demo is how you measure success. (This is why it is great for the BA to be at least 2 sprints ahead because of the “grooming” commitment isn’t kept – then the team isn’t left at a disadvantage in the next sprint because the majority of that analysis should already be done.)

As you can tell, there have clearly been some bumps in the road, but no matter how annoying those bumps may be I know that the adoption of agile is a step in the right direction and I’m thrilled to be getting this hands on experience leading a large complex organization through this conversion.

Continue Reading

‘Analysis Paralysis’ is a theme that comes up often when discussing problems with requirements gathering. It’s true, there is a tendency for organizations to get stuck in the elicitation and analysis phases of a project and you end up with The Never Ending Requirement. It just so happens that the phrase ‘never ending’ makes me think of the film series “A Neverending Story” from the 80′s – 90′s and I always picture the odd flying dog-like creature (see him here). As a result, he is my mascot for going on a ride of never ending requirements. I digress…

When it takes a long time to elicit requirements the requirements inevitably keep changing, teams lose momentum, and you re-hash things over and over again. In the end, every notion of motivation has gone out the window and no one is happy. That’s why I believe it is important for organizations to take the time and have a clear methodology for elicitation. I’m  not talking about reading a book and implementing it word-for-word. I mean taking the time to study your stakeholders and settling on a process that works for you. As a consultant once told me, “I am not so much for best practices, I am for what works.”

I’d love to tell you a beautiful story about how this has worked for me, but the truth is that I have been operating in an environment of incessant change. In the fall of 2009 there were 5 analysts on the team. Today there are 21 and we are still in the process of hiring. Had we taken the time to have a clean methodology for elicitation before the growth started I am sure things would have progressed more smoothly, but we all take baby-steps and this has been my mantra: Group requirements into the smallest cohesive chunks possible.

I’ve been encouraging the team to apply an object-oriented lens to analysis. Often the group is presented project scope that is large an unruly. So instead of playing the role of attention-deficit-analyst we are decomposing requirements into like bodies and asking them to complete the analysis on a single ‘chunk’ of work at a time.

This repeatable pattern gains several key benefits.

1. Greater buy-in. By asking focused questions on a single set of functionality, the stakeholders see a shorter duration of analysis. The shorter the analysis duration, the more likely stakeholders are to approve and confirm requirements.

2. Faster Time-to Market. BAs produce complete sets of requirements that can be turned over for development iteratively as opposed to waiting for one long elicitation and analysis phase to complete.

3. Better Planning. While not intended, although very beneficial, this approach can influence the way upstream planning works. Often times business units are conditioned to ask for a Mack-Truck when they really only need an SUV, because they know if they ask for an SUV, they will get a hatch-back. Successful BA groups that deliver thorough and accurate requirements for small chunks teach the stakeholders to change their frame of thinking and as a result planning and intake for solution delivery organizations can deliver against more manageable requests.

Currently this attitude is being applied in a waterfall shop. I am preparing to undergo a transition to agile, and I can’t help but believe this way of thinking will contribute to the team’s success. It isn’t a full methodology – although the goal is to head that way. For now, this is one way we are making our analysis efforts more manageable and it hasn’t failed us yet.

Continue Reading