Jul 22

Techniques for Giving Your Glow

I was inspired when I attended ScrumGathering out in Las Vegas (SGLAS) this May and now we are just weeks away from Agile2013 in Nashville and I am psyched that I will get to see lots of great friends and contacts again. It should be a really superb week.

The Women in Scrum OpenSpace session at SGLAS was one of the more powerful sessions I attended the other month, and when there I mentioned the phrase “Borrowed Light.” It immediately resonated with people, and I am fortunate enough to have a blog post in waiting for Lyssa Adkin’s newly re-branded blog series “Women in Agile” on www.coachingagileteams.com. In the post I explain the notion of “Borrowed Light” a concept I picked up from my Davisbase Consulting colleague Russ Fletcher. (He by the way, is awesome.)

While getting the post ready, my friend (and ScrumMaster Diva) Natalie Warnert suggested I add content about ways people could share their light, but I didn’t want the post to be too long…so…here we are!

Techniques for Giving Your Glow is a quick hit list of ways you can help share your light with others and lend a little bit of the credibility, trust, and subject matter authority you’ve earned yourself with someone else.

In order to build the list I asked @nataliewarnert what she thought…

Before you can begin Giving Your Glow you first have to be out there meeting new people. Otherwise, who would you be giving your glow to? Once you have that taken care of, there are a few really basic ways to Give Your Glow:

  • Sharing or Re-posting people’s blog posts / co-authoring posts / allowing people to guest-post on your site
  • Introducing people to others who may be able to help them
  • Co-teaching and facilitating meetings (They key: Look to co-present with someone that you can share your light with. In addition to sharing your credibility with them, there is also an opportunity for reverse mentoring from their side. Someone who is newer and less experienced often has a lot to share both on a different demographic and a perspective you often don’t get from peers with similar experience levels as you.)

But perhaps one of the easiest ways to share light is exactly what we is going on right here – be involved in social media. Reference people’s relevant posts with links in your own blogs, Tweet and Re-Tweet posts, articles, ideas, and have conversations on Twitter or through blog comments. Its benefits are two-fold because it gets their name and content to your wider range of followers and since you’re promoting them shares your light while simultaneously reaching their followers and promoting yourself as a mentor and supporter to their followers. For example, Bob Hartman (aka Agile Bob) was sharing his light with me when he tweeted “Every so often you meet someone that is a bright, young, #agile and #scrum enthusiast who gets it! @nataliewarnert is one of them!” to his many followers. The more their name and your name appear online the more both social media presences and personal brands will develop. We’re seeing this from #WomenInAgile right now.

A final idea is to network, now everyone knows what networking is but networking within the frame of sharing light is a bit different. It’s not just about meeting people, it’s about making meaningful introductions with the person who you’re sharing your light with and helping them to establish connections being backed by your credibility. For example, I’ve been introduced to many people and have made some great UX and Agile connections because of the shared credibility and light from more experienced and well know professionals who introduced me.

I think that is a pretty great list. Just imagine yourself with an aura around yourself related to your career (or something you’re personally passionate about) and then imagine inviting someone in close to you, so that they are standing within your glow. When you do that, and you acknowledge that they are there whether publicly to the world (e.g. thru social media) or more privately (e.g. in a client meeting) — then when they walk away they get to take a little bit of your glow with them and that makes both of your auras brighter.

Who are you sharing your glow with today?

 

Jul 12

Accepting Failure

Catching up on some reading tonight during a pomodoro session. Yes, I built in reading e-mail, reading blogs, and writing blog posts into my backlog tonight. Ha. 

So, I just read When to give up by Stef Lewandowski (@stef) over at Makeshift. I suggest you read it yourself, but I thought I would use this as an opportunity to ramble about failure myself for a few moments.

My favorite points from the post were Listen to Yourself – The idea of paying attention to how you feel about something, how you sound when you talk about it, or how you react to it when someone brings you up. I can’t help but completely agree. We spend way too much time at work as a standard employee to be disgruntled with our work. And if you happen to be an entrepreneur, then the amount of devotion and effort put into running the business far exceeds that of a standard employee at a company. Don’t let yourself be unhappy or always stressed about your work. At the end of the day it just isn’t worth it and if it is meant to be – it will be. Don’t kill yourself over something that is simply not intended to happen.

The second of the points was Zombie Fails – I had never thought of it this way before. Stef references a point made by Makeshift co-founder Nick Marsh, “It’s not the mega-fails that you need to watch out for. It’s the zombie-fails. It’s the things that you do, that aren’t quite working, but are always showing a bit of potential. The things that always require of you to just do one bit more because that’s the thing that will make it go big. Except you do it, and it maybe improves a bit, but there’s another just one bit right around the corner.”

I liked this one, not as much from the entrepreneurship angle – although that is very important –  it really hit home for me when it came to projects we undertake at Davisbase (@davisbase) and projects my clients undertake. So think of them like the Zombie Projects – the ones you know you should really abandon and quit, but for whatever reason you just can’t seem to let go of because it just might turn out to be great, or it just might get back on track. They cause headache and swirl and make you have that awful stressed feeling all the time. If everyone in your office gets “that tone” in their voice when talking about a certain endeavor, then maying its not the right initiative to be working on.

And lastly, I complete agree with the idea of building failure into your plan. I have a tough time of convincing new agile teams to do it, or program managers to allow for it during portfolio planning – but you have to acknowledge (just as change in inevitable) failures will happen. So just roll with the punches and cut your losses when you need to. Not everything is a great idea, and maybe you need to get some cojones in order to man-up to say enough is enough.

May the power of failure be with you!

May 17

“Breaking Analysts” at #SGLAS

If you didn’t make it to ScrumGathering Las Vegas (#SGLAS) by the Scrum Alliance last week, and as a result missed my “Breaking Analysts” presentation – never fear! I will be presenting a variation of it at Agile Alliance‘s Agile 2013 conference in Nashville, TN May 5-9, 2013. What, you aren’t going there either? Well… I guess a PDF of the slides will have to do you. Here is a brief description of the talk I gave:

Leslie J. Morse presenting "Breaking Analysts"

Breaking Analysts: A Real-World Tale of Converting a Traditional Business Analyst into a Lover of Scrum
Team members that can perform proper Business Analysis are key to Scrum teams building valuable products that truly meet customer needs. “Breaking Analysts” will lead you throughwhat your BAs are thinking when they first learn about Scrum and equip you with tactics & strategies for getting the light-bulb to come on and ultimately build a team of analysts that are willing and ready to go all-in.

And as always, a HUGE thank you and shout-out to Davisbase Consulting (@davisbase) for allowing me to have a career that provides for these sort of great opportunities!

Dec 30

#BAOT: 5 Things to Stop in 2012

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.

Five Things to Avoid in 2012In 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!

 

Dec 20

Elevator Pitch : Requirements Benefit

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

Elevator Pitch is to Business BenefitI’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!

Dec 04

A Sign of Too Much Work?

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 HistoryBoxing and Agile
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. :-)

Apr 03

The Progression into Agile Analysis

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.

Dec 29

Avoiding The Never Ending Requirement

‘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.

[ Elicit : Analyze : Document ] Repeat

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.

Shorter Analysis Duration results in greater likelihood for stakeholders accepting 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.