The truth

"Seek the company of those who search for truth. Run from those who have found it." - Vaclav Havel @mcafee

A BAs Top Three

So what three things should we be looking for in modern Business Analyst?  


Capability, Competencies and Skills are often use these terms interchangeably. What results is a messy overlap that compares apples with oranges...it just doesn't work. So I decided to provide my top three of each. Below is how I define these characteristics:

• CAPABILITY - ability to derive relevant value. Usually a combination of skills and competencies eg effective 'Business Process Management (BPM) is valuable to an organisation. Can be assessed, but difficult to train as it is a set of complex attributes.
• SKILL - activity related components that contribute to capability. eg i'm skillful at business process modelling and contributes to my capability in BPM. In isolation provides little value. Can assess and trainable.
• COMPETENCY- intrinsic ability to execute skills and derive capability. Often related to leadership, however in Business Analysis the scope is broad. eg i am an excellent listener which helps me engage stakeholders and elicit requirements. Difficult to assess, can be improved with training and experience. Not industry specific and often stronger competencies are learnt through industry diversity.

Top three capabilities...

1. Business Process Management - capture/improve/redesign, governance, strategic alignment, culture/people implications, tools
2. Requirements Management - elicit, manage, document, tools
3. Enterprise Analysis - vision/strategy, stakeholder assessment, financial analysis, business case

Top three skills....

1. Collaboration (tools and techniques)
2. Business Process Modelling
3. Writing Business Documents (as opposed to technical documents)

Top three competencies...

1. Integrity and trust (leadership)
2. Interpersonal savvy (leadership)
3. Business trends and best practice (functional)

There is a place for email

A recent blog I responded to encouraged me to explore appropriate use of email.


Email is a channel too often used inappropriately...
It is time to discuss what it should be used for, and what it should not.


What email is for:

• Personal messages - can be a good tool for clarity in one-on-one dialogue, eg after a phone call..."I'll send you an email to confirm our discussion"
• A directive - to a group of people and don't expect a response
• Specific people - when you want to limit (not control) distribution
• Notifications - consolidates updates from various platforms (C3, Facebook, Linkedin, etc)

What email is NOT for:

• Dialogue - telephone and IM are better tools for one-on-one discussion
• Discussion  - email is a channel, not for discussion. Stop the 'reply all' emails. 
• Innovation - Controlling distribution is a significant dampener to innovation.
• Everyone - a question, comment or answer will be of greater value on a platform.

Stop inappropriate use of email!

Are BAs ready for Agile?

Over the past 12 months I've been involved in some interesting discussions about BAs and Agile. What is clear is that the capabilities needed for business analysis in Agile delivery are quite different to that required for waterfall. BAs traditionally are training to define solutions and limit change. In Agile, we are looking for BAs who resist the temptation to define the solution, and accepting of change. Waterfall is about documenting with the client in mind, whilst Agile is with the developer in mind.


With this said, it is understood that the transition from waterfall to agile is a step learning curve for all concerned. What is possibly lacking in the BA space is role models and/or managerial reinforcement. Engineers are generally taking this journey as a team, but from experience... BAs tend to have a lonelier existence. Methodology that is inherently highly structured, management that are struggling with the shift in required capabilities, and engaging with businesses that just want documented requirements.

The thing is BAs should be better suited for Agile than most. They have a set of competencies that are well suited to dealing with ambiguity. Good BAs are experts at managing expectation, and this is a important for Waterfall or Agile alike.

My personal experience is with Scrum, and good evidence for effective use of BAs. In one project we used a BA to work a sprint ahead, preparing the sprint backlog for the dev team. On another (a large Defence project), after a number of setbacks the lead BA became the scrummaster and completely turned it around. It was so effective, there was consideration for this to become a norm. On my last project (before switching companies) I was the Product Owner on a BPMS implementation where business commitment was a problem. I am obviously bias but would like to think we provided an impressively innovative solution with equally impressive speed.
I found this in the definition of a PO "product owner is in many ways an empowered business analyst" (http://goo.gl/JM8xw).

I am convinced that BAs are in the box seat to play an integral role in the Agile transformation and believe we will see benefits from a greater overlap between the communities.