IIBA Business Analyst Europe Conference 2011: Keynotes

Two of my highlights of the event came in the form of keynote speakers.

Ivar Jacobsopn – Use-case 2.0

Firstly, was the impressive Ivar Jacobson discussing the topic of Use-case 2.0. Unlike other methodologies and brands that have jumped on the 2.0 bandwagon, the latest version of the use-cases include a rework to allow for quick adoption by smaller software teams (without having to invest a career in trying to understand how to properly document them).

Perhaps most impressive for me was Ivar passion for using use-cases as a way for agile teams to generate user stories by slicing through the use-case workflows. He was able to show some great examples of how this approach can be used in support SCRUM and Kanban.

We have learnt one thing, we don’t need to document as much… People won’t read it anyway!

Ivar Jacobson 2011

Euan Semple – The Impact on Social Networks on Business

Secondly came Euan Semple (@euan). Now as a former digital marketer and user of social networks I have to confess to not being very excited about this keynote. Yet, what I had anticipated was going to be Social Media 101 was actually something much, much better.

Euan’s background as former Head of Knowledge Management at the BBC made me sit up and pay attention. What was to follow was an insightful and well constructed presentation of Social Networking Tools and how, using examples and anecdotes, they can be used to bring us closer together. Euan made the point that it didn’t matter if we were employees co-located in the same open-plan office or if we were a customers of a multinational, the tools could allow us to engage.

Now I know that there is nothing new in this thinking but what I loved was Euan’s views on using social networking tools as a way to capture knowledge, aid collaboration, break down one-way communication channels in organisations and empower employees. So many times I have seen poorly managed B2C social media failures, and Euan showed us a few, but the real value came in considering what an organisation could do with these tools that Euan suggests “are already being used” to radically change an organisations culture. Watch Full Movie Online Streaming Online and Download

Knowledge Retention sounds like something you’d take a laxative for!

Semple 2011

Conclusion

  • Never underestimate the power of passion and humor when presenting – even if it is on a nerdy subject
  • We live and work in a rapidly evolving environment. Both Ivar and Euan showed examples of what had been and gone in the past 10 years. Our ability to learn, adapt and overcome new problems with everchanging tools will be what diffenciates us from those that don’t succeed.

IIBA Business Analyst Europe Conference: Roundup

This week I attended two days of the IIBA BA Europe Conference 2011 (#BA2011).

It was an excellent event and one that attracted practitioners and suppliers for right across the BA spectrum. These included: Business Analysts, Process Managers, Change Managers, Business Engineers, Systems Analysts, Business Architects, Enterprise Engineers and even a few PMs/PMOs!

What will follow in the next few days are my thoughts and notes from sessions I attended and things that I learnt while I was there. These are likely to be broken down into the following key areas:

  • Keynotes
  • Models, Tools & Techniques
  • Networking & Mentoring
  • Case Studies

I read and heard a lot while I was away and am likely to be digesting it for a few more days to come. Hopefully the write-up will be of interest to some of those that also attended.

Understanding Business Rules and Data Requirements

Last week I was thinking about how to capture and analyse business rules and data requirements for a current project. I’ve worked on a number of projects where the focus can often be on either rules or data, however focusing on one while leaving the other out can cause issues further on in the project life cycle. I’ve learnt this on previous Business Intelligence/Data Warehousing projects where over analysis of the data can lead analysts to start to ask more questions of the data then the end-users or owners ever wanted to ask, while key rules are not enforced.

While doing some reading around the subject I came across Mary Gorman’s IIBA Spotlight Webinar on Business Rules and Data Requirements.

But firstly, what is a rule?

A declaration of policy or conditions that must be satisfied…. In order to define, stream or enable our system or process behaviour. (Gottesdiener 2005)

Mary discusses 4 types of rules that can aid a BA in categorising rules and their corresponding data dependencies. These 4 rules are:

  • Term Rules
  • Fact Rules
  • Constraint Rules
  • Derived or Calculated Rules

I am listing them below more for my own reference benefit, but hopefully others will find them useful.

Term Rules
Defining nouns such as “Customer” or “Gift Card” is important. This task is not just for your glossary but for giving context to your system or process. We’re able to identify actors (Customer) from terms based rules and this helps us define the scope or boundary of the work to be undertaken.

Fact Rules
Fact rules are a two way relationship between terms rules. For example:

  • A purchase is paid for by a gift card
  • A gift card pays for purchases

These can be extended to use cardinalities

  • A purchase may be paid for by one or more gift cards
  • A gift card may be paid for by one or more purchases

As we identify fact rules we can determine data attributes. For example:

  • A customer has an address. An address is made up of address lines, city and location.

Defining these data types allows us to define the scope of the rule. For example we don’t want a second address line.

Constraint Rules
Constrain rules can be used to constrain the action of a rule. In this example an expiration date is added to the gift card.

  • gift card expiration date must be equal to or greater than purchase date.

Derived or Calculated Rule
A calculated rule allows us to derive new attributes from existing ones. For example:

  • A gift card date is calculated from the date of activation plus 365 days.

Gottesdiener, Ellen, The Software Requirements Memory Jogger: A Pocket Guide to Help Software and Business Teams Develop and Manage Requirements. Goal/QPC, 2005

Managing Change – The Agile Way

Today I came out of one of our showcase/demo sessions with a client and his stakeholders. These are usually the points in the project that we all look forward to. Increased collaboration with our clients and the proximity of their office to ours has meant that we have a great rapport with the client’s team and these demo meetings act as an opportunity to impress the client and for the developers to get a few pats on the back.

However, today it was different. The client had brought in a new stakeholder and as we started the demo he put his hand up and said something that silenced me, he said “We don’t do it like that any more”. I was panicked and a little shocked. The guy apologised and clarified the position, “I’m new here I know but we’ve just been told by our supplier that we need to give them visibility on orders earlier in the sales pipeline, so the workflow needs reworking”.

My initial thoughts were that of worry. In traditional projects a conversation like this usually has cost and time implications intrinsically linked to it and I was worried about what I’d tell the developers and my boss.

Thankfully the team allowed me to complete my demo and then we got the whiteboard out and started reworking what we had implemented to help tackle this 11th hour requirement. By doing it in this way we were able to remain professional while being adaptive to change with the client.

The Poster

When we got back to the office I had a look closer at the ThoughtWorks Agile Manifesto poster that we had on the wall. It reads:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

  • Individuals and interactions over processes and tools
    (Well I’d been there, sat with the team and interacted with them – tick)
  • Working software over comprehensive documentation
    (The client wants working software – the docs were out of date but the software didnt have to be – tick)
  • Customer collaboration over contract negotiation
    (I did’t scream ‘Change Request’ even though I wanted to… we worked it out – tick)
  • Responding to change over following a plan
    (We responded to the change over the plan – tick. However, if it hadn’t been for the plan we wouldn’t have identified the change. I think it’s important to plan – but to use it as a guide, not a law book) 

Today it all made sense. The agile manifesto was written to help people in exactly the same boat as I had found myself in.

 

Do Business Analysts need technical expertise to be an excellent Business Analyst?

This is a topic that was recently raised and discussed in the IIBA’s Linkedin Group. As I read my way through the case for and against whether a BA should have technical expertise I started to doubt my own answer.

At university I studied Information Systems Engineering, so while I did’t study any programming languages I did study a range of modelling techniques and use a number of technical tools. I put the discussion out of my head until a few days later when, unlike me, I undertook some plumbing at home!

My objective was to plumb my washer dryer into my downstairs bathroom to make a utility room. While I lacked the plumbing skills I knew what I needed to be done and I was able to communicate this vision to others. I wanted to:

  • Get cold water into my washer dryer
  • Get waste water out of the washer dryer and into the drain
  • Get power to the washer dryer

I was reminded of many of the systems I have helped clients define requirements for. They too had similar requirements:

  • There was some data that had to get into the system
  • Once the data was in some processing had to take place
  • After the processing had taken place reports/exports had to come out of the system
  • And the system needed an infrastructure that would keep it working
Systems Integration
Systems Integration!

The flow of data into a system is not that much different to that of water flowing into a washer dryer. I’m not a plumber but I knew that this will involve pipework from an existing water supply. I found myself drawing systems architecture diagrams of how the systems would communicate, my water pipe would need a new tap (an API) and piping of the right format would be needed to help the water flow, just like that of a webservice.

I could really take this much further – and you’ll be glad to know that I won’t today, but it made me realise that a BA doesn’t need to be a developer. What is important is to be able to have aptitude to understand the big picture of what is trying to be achieved and to visualise a workflow. It’s then important to be able to communicate this to someone else, so that they can do the implementation – in my case a plumber!

Update: Last week my wife and I had our first little boy and this taught me something else about systems implementation – The ROI of a good system is often time and efficiency… or in our case – sleep!

IIBA Membership

This week I signed up to become a memeber of the IIBA (International Institute of Business Analysis).

Some of the attractive things about joining the IIBA were:

I’m looking forward to attending some of the events and getting access to some of the great resources that the IIBA have to offer.
Giveaway iPhone 7 Plus

Becoming Riders of Paradox

ThoughtWorks Live 2011Last week I had the pleasure of attending ThoughtWorks Live 2011 in London’s St Martin’s Lane hotel. The conference, entitled Continuous Delivery: Push the button, was a showcase of ThoughtWorks thinking on how to become truly agile through the implementation of Continuous Delivery and Continuous Deployment.

Among the speakers were heavyweights such as Martin Fowler, ThoughtWorks Chief Scientist & Roy Singham, ThoughtWorks Founder & Chairman – positioning ThoughtWorks as not only global experts but as global educators, both practically and aspirationally.

Riding Paradox

Paradox Horse
"Paradox" by Michael Bergt

A real favourite for me was a presentation given by ThoughtWorks Studio’s Managing Director, Cyndi Mitchell on Adaptive Leadership: Accelerating enterprise agility, based on Jim Highsmith’s whitepaper of the same name. In the presentation Cyndi discussed a number of challenges that leaders face in being adaptive. The real eureka moment for me, in both the presentation and the whitepaper, was the concept of Riding Paradox. We were encouraged to be ‘And’ rather than ‘Or’ leaders, inclusive of elements from multiple methodologies that can add value and work together for the benefit of the project. No one methodology has it 100% right and we should look to take aspects of different practices and thinking and incorporate them more. A quote from Rotman summed it up well “Integrative Thinking is the ability to constructively face the tensions of opposing models, and instead of choosing one at the expense of the other, generating a creative resolution of the tension in the form of a new model that contains elements of the both models, but is superior to each“.

Highsmith discusses in his whitepaper “The paradox horse seems always to be going in opposite directions at the same time. Furthermore, the leader is exposed, drawn by the traditional norms of many organizations in which it’s OK to be wrong, but not OK to be uncertain“.

As a Business Analyst I often find myself in a similar position, for two reasons. Firstly, due to the nature of my role I report into my Managing Director for the purpose of sales targets and planning, while reporting into my Technical Director for the purpose of scoping and quality assurance. It can often feel like attempting to serve two masters, serving two areas of the business who sometimes have opposing expectations.

Secondly, clients can sometimes be prescriptive about the methodology that their software project should use. This is rarely based on thoughtful consideration of stakeholder needs, rather that the client has heard a buzz word or has used that methodology on a previous project and feels safe with it. As an example, I have had clients come to me and say “We want to use Prince2”, for no other reason then a third-party advisor has suggested it would ‘be best’. This leads to lengthy planning and scoping phases of work up-front which the client is happy with. However, once the project moves into production the development team opt to take an agile approach to the job, breaking down my long specification into chapters – renaming them iterations and delivering little and often.Watch Full Movie Online Streaming Online and Download

At the same conference one of the speakers, Dave West from Forrester, coined the phrase “Water-Scrum-Fall” that perfectly describes this idea that scoping happens, the development team run off with an agile approach and then the final mile of the project reverts back to a very formalised sign-off process.

I’m excited by what I’ve heard at the conference and challenged to implement changes in my working practice. Lets hope I can attempt to ride paradox without falling off!

Rotman. (n.d.). Integrative Thinking. Retrieved from Rotman Business School [online]. Available from: http://www.rotman.utoronto.ca/integrativethinking/definition.htm

Highsmith, Jim. 2011. Adaptive Leadership: Accelerating enterprise agility [online]. Available from: http://www.thoughtworks.com/articles/adaptive-leadership-accelerating-enterprise-agility

Image from: Jim Highsmith: “And” Leadership.

Stakeholder Interviews

This week I have been revisiting the topic of Stakeholder Interviews, in the hope to refresh my own thoughts on the subject. I’ve found some great resources that I would like to share along with a number of hints and tips that I have from my own experience of undertaking Stakeholder Interviews. I should note that this post is not intended to be a definitive list of potential questions, more a guide to those who wish to understand how to undertake Stakeholder Interviews.

Firstly, what is a Stakeholder Interview? Well – I couldn’t find a book definition to reference, so I have made one up:

An interview between a Business Analyst/Project Manager and pre-identified stakeholders of an organisation or department, for the purpose of understanding a current system and/or eliciting requirements for a new system.

Like many interviews that you will have taken part in, either in seeking employment or helping in market research, they follow what is known as a structured interview style.

Bryman & Bell (2003) describe the purpose of the structured business research interview as being “for the interviewer to elicit from the interviewee or respondent, as he or she is frequently called in survey research, all manner of information: interviewees’ own behavior or that of others, attitudes, norms, beliefs and values.

So now that we know what a Stakeholder Interview is, how do we undertake one? Thanks to Brad Botz over at BA Mastery, I came across a great podcast that he put together on the same topic. Brad suggests breaking down your questions in the following way:

Function
– How do you use this software? What are some examples of what you do regularly? Which actions do you perform the most?
Frequency
– How often do you perform these tasks?
Preferences
– What do you like best about the software?
Problems
– What problems do you run in to on a regular basis?
Expertise
– What are the tips and tricks that you have learnt? Are there any workarounds that you have discovered to make the tasks easier?
Miscellaneous
– Have I missed anything? Is there anything that you would like to show me?

It is important when to stay on topic with this last set of questions. Try not to allow the stakeholder to deviate from the original purpose of the interview and remain positive about the system, even if their own concerns or experiences are negative. It’s also to remember to let the stakeholder follow the course that they wish to take throughout the interview. While it is appropriate for the interviewer to help guide the respondent, encouraging them down a particular route is not appropriate and should be avoided where possible.

In Summary

Advantages:

  • If you build a rapport you are going to get much more acceptance of the project, not just through the interview but throughout the life cycle of the project
  • Its easy to conduct interviews – easy to extend them if they overrun and easy to record their findings

Disadvantage

  • It can be difficult to obtain consensus if there are many stakeholder
  • Follow up questions are heavily reliant on the interviewers experience of the interview process and their understanding of the domain they are working in
  • You may lead someone accidentally

Bryman, A. and Bell, E., 2003. Business Research Methods. New York: Open University Press.
Clash Of Clans Cheat And Hack Tool

Measuring and Monitoring Velocity

Recently, I have been doing some work with User Stories. As a result the developers and I have started to estimate user stories using story points. This is a good way to allow a team of developers to collaboratively estimate the complexity of a piece of functionality and how long it will take to implement.

The question was asked about how we make our progress visible to internal and external stakeholders of the project. Unlike a traditional waterfall project there is no gantt chart or detailed project plan, only a series of iterations and some expected deliverables for each iteration. This lead us to think about how many story points we were expecting to complete in any single iteration.

Many of the projects that I have worked on in the past use Burndown Charts, but most of them were produced out of a project management tool. I decided to take the user stories that I had from the current project and have a go at producing my own Burndown Charts.

Using Google Docs I was able to take data from the user stories, broken down into the 5 iterations, or sprints as some prefer, and produce a burndown chart.

Traditional Burndown Chart
Traditional Burndown Chart

However, when I looked at it I couldn’t help but think that it looked too good. Like the project had been too easy. I went over my notes and I was reminded of two things that happened during the project:

  1. The teams estimates changed
  2. Scope creep set in

What that actually meant was that while the project looked like it had gone really quickly and that we had over estimated the user stories in each iteration, there had been some changes mid-project that we had negotiated and these had effected the overall number of story points in the project. To better show this I have produced a second chart that I think helps stakeholders see the movement in scope in relation to the burndown.

Burndown (including scope creep)
Burndown (including scope creep)

The addition of the ‘scope’ line shows the burn down in a slightly different light.

At the end of iteration 1 (i1) the developers are behind of where they should be. Being an iteration in and being able to rework their estimations they deem some tasks to be more effort and increase their estimations to match. This saw an increase of 5 story points, 2.6% of the project.

At the end of iteration 2 (i2) the client team dropped a piece of functionality. We were able to cater for this change and thus removed 18 story points, 9.5% of the total project.

The rest of the project continues on its projected line but had there not been an additional line to show change the client team could have easily misunderstood why the project was in its current state.

I don’t know how people feel about using such charts and if hacking them to show more information is allowed. I believe strongly in giving clients as much useful information and feedback as is possible. It is important that a client team see a strong correlation between scope creep and effort. If the scope of a project is increased a project will, in most scenarios, take longer. However, if a scope is decreased then often there is time savings.

That last point about time is one thing that I should extend on. We struggled to take the conceptual theory of a story point, determine a velocity and then convert that to developer days. In the end we settled with estimating in developer hours, so 1 story point = 1 dev hour. This seems like a bit of a cheat and not as pure as intended, if anyone has suggestions on how to improved project estimations I’d love to hear from you.

Users, Roles, and Personas

The ability to understand a user and their role in a software system is not a new thing to many. We have all interacted with applications and software where there is, at minimum, a normal user and an administrator. Users can’t do all the things an administrator can do and an administrator can do all the things a normal user can do – plus some additional things.

However, when we look at systems in this way all we are really modelling is permissions. Who has permission to perform a task? Who is allowed to perform an action? If someone does something wrong who will moderate this? These are all valid questions about the systems and it’s intended Access Control List (ACL), but captures nothing about the individuals that will be using the system, what their goals are and what things we can do with the interface that will improve performance for the users.

I found myself in this position on a recent project and something I read caused me to rethink my approach. This is what I read:

User roles do not resemble real people nor are they intended to; roles are spartan abstractions narrowly focused on those aspects of the relationship most likely to be relevant to presentation and interaction design. Compared to personas, user roles are a more technical and formally structured model.

By contrast, personas are figurative models rather than abstract models, that is, they are constructed to resemble real users, even down to photos, background information, and personal history. Verisimilitude most likely contributes to the popularity of personas. They sound like people you could know, and over the course of a project can take on a reality that encourages empathy and facilitates thinking from the user perspective. What is more, many people find that the creative process of constructing personas to be engaging and energizing. Personas are fun. (Constantine 2005)

The suggestion here was that when modelling users for a system it wasn’t a case of picking one or the other, role models or personas, but that really the two needed to be carried out together in order to get the fullest picture of how a user would use the system and what they wanted to achieve from the system – not just what they would have permission to do.

I decided that it was time to put this into practice, to give it a go. Was I going to add the persona modelling to my toolkit or not? The system I was working on (and still am currently) is for managing learners in a learner centre. The scenario I am going to use as my example is quite simple: Learners attend the centre in the morning and are greeted and registered by a ‘learner administrator’. The learners then commence on a piece of learning and are assessed by a ‘tutor’.

In this scenario I identified two users a learner administrator and a tutor, the learner was not interacting directly with the system. However, due to resourcing issues at the centres it was important that learner administrators and tutors had the ability to perform the same actions. In essence the two users share one role.

So under the role based model this is fine, nice and simple. I don’t really need to create two user types I can just create one and add a label that just identifies their job title, in case I ever need to reference it somewhere. However, I’d decided to add personas and see if anything changed. Here are my personas:Watch Full Movie Online Streaming Online and Download

Learner Administrator

Sarah is a single mum in her early twenties. Her day consists of checking students in, chasing the ones that haven’t turned up and ensuring that the correct reports are run so that the centre can claim its allocated funding for the learners they have had through the door. Between admin tasks Sarah uses Facebook to see what others are up to and uses an IM client to chat to her boyfriend. She’s a confident computer user who finds the system easy to navigate.

Tutor

Phillipa is an ex-school teacher. She works as a tutor part-time more to keep her busy rather than because she is dependent on the income. Phillipa has older children who are no longer at home and her husband is a consultant surgeon. Her day-to-day tasks are the assessing of learners, recording their outcomes and helping them to move on to the next piece of learning. Phillipa is focused on the learner and finds the need to record everything on an online system a chore. She only uses about 25% of all the systems functionality but the areas that she does use are used relatively. Phillipa doesn’t mind using a computer for her tasks but likes to have peoples on hand to check with and ask questions when needed.

From this it became very obvious that my two users with the same permissions role were going to be using the system for very different purposes. I had been able to identify this early, rather than waiting for User Acceptance Testing (UAT) and I was able to do something about the design of the system and its interface.

The system has not been fully implemented yet but one suggestion that has come out of this was a configurable dashboard. The dashboard is made up of a number of blocks and pods that either display content or a forms and filters into other areas of the system. The layout of this dashboard would be dictated by the priority of certain day-to-day jobs, allowing for learner administrators and tutors to rearrange these pods to suite their needs. Also, based on the understanding that the tutors were generally older, less computer savvy users I opted to prioritise the default dashboard around their needs so that they would need to do less configuring, allowing the more confident learner administrators to customise their dashboards heavily.

So what did I learn from this exercise?

  • I learnt that an ACL role model isn’t always enough
  • Roles need context. Personas allow us to add context
  • You can create an interface that is different for two users but only charge them for one.
Constantine, Larry. 2005. Users, Roles, and Personas. [online]. Available from: http://www.foruse.com/articles/rolespersonas.pdf