RSS

Category Archives: Business Analysis

Performance agreements when you are on projects

I was happily running a class when someone asked about how performance agreements work if you are on projects.

“Really well” I replied, “you just need a new one for each project you are on.”

My answer didn’t seem to go down well though. After all, who wants yet another piece of administration to do?

Then we discussed the problem that both permanent staff and contractors often have with projects. Contractors get no real feedback on how they are going until their contract ends, while permanent staff have to have a series of discussions based on a document that bears little relationship to what they are doing on their projects.

Read the rest of this entry »

 
1 Comment

Posted by on August 3, 2011 in Business Analysis, Testing

 

Tags: ,

Learn from international experts. For free.

While you are progressing in your I.T. career you want to hear from the smartest people in the industry, right? Here at SoftEd we sell two and three day MasterClasses presented by industry experts, but if all you have is a couple of hours you can still benefit from attending a SoftEd sponsored meetup. Our speakers present at small, community events in Australia and New Zealand throughout the year; the next two talks will be in Brisbane and Sydney.

For Business Analysts in Brisbane

If you work in business analysis you have probably heard of Alec Sharp, author of the bestselling book, ‘Workflow Modelling’. He spends part of his time running his consulting business, Clariteq Systems Consulting and the rest of it conducting workshops and presenting at conferences. Any time which is left is dedicated to following his favourite ice hockey team, the Vancouver Canucks (and presumably sleeping). On the 28th July he’ll be in Brisbane presenting at the Agile Academy Meetup Group, talking about Agile Modelling. There has been a lot of change for business analysts over the past few years as companies have moved from ‘traditional’ software development which includes a huge amount of documentation to ‘Agile’ processes which have cut down documentation (sometimes dramatically). If you’re finding it tricky to negotiate between enough detail and information overload then Alec’s experience, tools and techniques will help you strike the right balance. As a result, your developers will have a better understanding of your project, your stakeholders will be happier and you’ll have an easier life, what could be better? If that sounds good to you please RSVP to attend.

Alec is running his Advanced Business Process Management course this July in Auckland, Wellington, Brisbane and Sydney and there are still a few places left if you would like to sign up.

For Testers in Sydney

If you work in testing you may have gone through the ISTQB to get certification, or you may have decided that it was not relevant or necessary and gone without, as one well-known testing expert, James Bach, has done. He is quite a controversial figure in the world of testing and is a powerful speaker who doesn’t shy away from challenges and rigorous debate. This means his Rapid Software Testing course is great for testers who want to examine what they do and why they are doing it, helping to concentrate their efforts and improve their confidence. James has partnered with SoftEd for years and we regularly bring him out to this part of the world to run courses, if you’re interested in hiring him to train your testers you can get in touch with us.

James will be in Sydney next Monday presenting at the Sydney Testers Meetup. Keep your eye on this group for future events because they’ll have more guest speakers throughout the year.

What’s next?

Who knows what the future will hold for you and your career? We don’t have any crystal balls, but we do have the phone numbers of international I.T. experts and if you subscribe to our blog or follow us on twitter we’ll let you know the next time they’re in town.

 

Splitting stories and exploding scope in agile projects

We used the  “Abstract to concrete” approach to splitting stories in a training course recently.The approach is published in our “resources” page, alongside some other approaches that also work.

But I told the class I would publish it here for easy reference, so here it is.

008

Read the rest of this entry »

 
1 Comment

Posted by on July 2, 2011 in Agile, Business Analysis

 

Tags: ,

IIBA Debate now online

In May this year Pete Tansey and I debated the Role of the Analyst in Agile Projects for an IIBA New Zealand members only event.
The session was videotaped and is now available to view on InfoQ:

http://www.infoq.com/presentations/iiba-role-analyst-agile

What do you think – how does the BA role change in Agile projects?
Posted by Shane Hastie

 
Leave a comment

Posted by on September 4, 2010 in Agile, Business Analysis, IIBA

 

What to look for in system testing

Previous readers of this blog will have noticed the intellectual firepower and sheer passion of the contributors who share their views on testing.

They will also have noticed the blatant and shameful lack of authority with which one contributor (me) replies to questions and issues around testing.

What you may not be aware of is that I frequently also share my confident but dangerously simplistic views on testing when running courses, talking in the pub and anywhere else.  So hopefully those better educated in the mysterious ways of the tester will continue to correct my wayward advice before anyone follows it.

So, with that opportunity, here is an email request I recently received:

Dear TWG (Testing-wannabe-guru):

On our last day of our BA course, you mentioned several things a tester should test for in system testing.  Would you be able to send me the list?

Yours – BA who believes in quality

So here is my response- subject to correction from the pros:

Dear BA

In system testing we should test for things that might be wrong with the system.  You would think this means the process, the IT applications, the training material and other things that a business person would think are the “system” we are delivering.  But this would be hard and might result in a lot of work when we realise there are issues.

So we normally only test the IT applications and even then we only test three  things:

  1. Test things the developer should have already thought of when writing the code.
  • Since the developer should have thought of these things, we should not need to test for them at all.  So you can assure yourself of the system’s integrity by asking the developer “does the system do what we asked you to make it do?”  They will generally say “yes” and look a bit shifty.
  • We then ask the developer “how do you know” and they will respond “I don’t know – its the testers job to tell you if the system does what you asked me to make it do”
  1. Test the developers patience.  You should now ask the developer if they are a proud member of the professional elite of great developers.  They will tend to say “yes”.  Then you say – “Excellent, then clearly you would have not only made the system do what we asked you to make it do .. but even suggested innovative new things that nobody else could have made it do … Surely that is the difference between the adequate developer and the great one.  So, how can I prove to others that you deserve their respect and even their awe?”
  • They will generally look perplexed or annoyed – so ask them “OK, assuming we had great developers then we should only need adequate testers – what would an adequate tester test for to make sure the system works”
  • Now ignore what the developer says, because this is the stuff they  have thought of and that will generally already be working.  This is therefore not what we spend time testing in the system testing phase.
  • Testing the developer’s patience should always be included in your testing.  Not only is it fun, but you will soon learn who the good developers are (they actually do know the system does the obvious things they were asked to make it do) and this is a good measure of the quality of the overall system.
  1. Test for bizarre things the developer would not think  of
  • Begin with scenario tests – create some examples of how people might use the system.  Don’t just look at one requirement but think up and example where the user would want the system to do several things.  For example, to test a banking system, don’t test just whether you can log in.  Do an example where someone logs in, looks at an account balance, performs a transaction and then goes back and looks at the account balance.
  • Think of some more examples (scenarios) and spend about 70% of however much time you have available running these though these examples to see if they work.
  • Now do some “bizarro testing”.  This is often called “exploratory testing“.  Think of random things that someone might do if they were dumb/they were distracted/they were intelligent but did not understand the system/they were older than normal/they were younger than normal/ they were in any way different to how a developer would imagine them to be.  Spend 30% of your time just doing some of these random seeming things and see what errors and unpleasant outcomes you can uncover.

Its pretty easy really.  The only problem is that you will only have a few days available and you will need about 6 months to test the system properly.  So, oddly enough what we pay testers for is not “finding bugs” but

“Spending very limited time to

  • Help the good developers discover the issues and problems they would not have thought of and
  • Let us know if it is likely that the system will suck in production and embarrass the team, or work as designed and make us look good.

I am not sure how they do this with so little time available but apparently this is their job.

Does anyone know how we can do better in system testing that the above approach?  It seems quite straight forward and yet appears to be a real challenge on projects.

 

What actually happens on an Agile Project – part 1

I have frequently been asked about how work actually changes on an Agile project. Here is the first part of what I hope will become a detailed examination of what actually goes on inside an Agile project:

I’ve been working with a team at a company in New Zealand recently, mentoring and coaching their implementation of Agile practices.

Last week we had a series of workshops to scope and define a new project. This is a major rewrite of all their branch systems, with an SOA link to the core legacy system backend. The basic architecture has already been defined, largely based on the existing technology environment the company works with.

The team consists of project manager, iteration manager, developers, testers, business analysts, the project sponsor (senior manager responsible for the branch network), a branch manager, and four branch staff members– one from head office, three from branches around the country.

We started the workshops with the project sponsor setting the scene – explaining his vision for what the company is trying to achieve. We then used a brainstorming approach to define the key success criteria for the project. Each person wrote their own understanding of their key success criteria for the project on post-it notes which were then stuck onto a flipchart. We grouped and clustered the statements, following which we agreed on the key drivers for the work (which is more important – deliver on time, meet budget, meet functional requirements, meet quality needs …).

Once we had a common understanding of the goals and drivers for the project we spent the bulk of the afternoon of the first day identifying key stakeholders, constraints, assumptions and risks – again using a brainstorming and discussion approach. We ended the day with a set of flipcharts around the room that identified the overall scope of the project, key success criteria, assumptions, constraints and risks (with trigger points and mitigating actions identified for the currently agreed most important risks).

We then defined the key features that the new system needs to have in currently understood priority order. This formed the basis for the next day’s discussion about specific features and releases. The second day started by reviewing the wallware from the first session, double checking that we had a common perspective. A number of items were reprioritised at this point as people had pondered them overnight.

We then took each feature in turn and broke it down to the level of user stories. Some of the stories were in the <as a> <i want> <so that> structure, but most were simple one-line statements of high level requirements. We then prioritised the stories and roughly grouped them into three releases.

It is understood that the releases are not fixed, but this is an initial starting point. We focused most of the teams’ time on features and qualities which must be delivered in the first release, which has a clear target date. The remaining features have been identified and ordered, but only in a loose fashion – this is expected to change as we actually do the work.

One clear outcome that has already been of benefit is the way expectations have been set. The project sponsor acknowledged that their initial goals were unrealistic, and already expects to either cut scope or spend more money than was originally allocated.

The business analysts have found that their role is largely facilitating the workshops, and asking a lot of “what if” questions. They are also taking responsibility for recording the decisions that are being made in the workshops and keeping the team focused on the task at hand.

The next step is to take the top 10 or so stories and expand them in detail. A workshop has been scheduled, involving the same team for next week. The technical team are setting up environments and doing all the iteration zero tasks in the meantime, so we’ll be ready to start work with the workshop.

I’ll post another message explaining what happens with the next workshop – we’ve labelled it “story elaboration” and the intent is to expand on the stories so the team can start work on iteration one immediately after the workshop. The key user representatives will be collocated with the technical team for the duration of the project and there is strong management support, so the project should be set up for success.

Many Thanks to the team – you know who you are 🙂 

Posted by Shane Hastie

 

 

Tags:

The power of the BA

I was doing some spring cleaning recently and I started reading some old material I was meant to be filing (I am not a very efficient spring cleaner).

I came across some of my masters degree notes on power, politics and negotiation in organisations.  Some of the main sources of power were:

  • Being the “locus of communication”.  In other words being the person between multiple teams that handles a lot of the inter-team communication;
  • The ability to set the agenda in discussions (generally meetings and workshops by also interviews); and
  • The one framing the questions for discussion (apparently the way you word the question often dictates the answer, which dictates what will happen next in the organisation).

As I read through the list, these and several other sources of power seemed almost like a job description for a BA.

Then I read another old paper which I sometimes quote in courses.  It talked about who survives, thrives and gains power in tumultuous times in organisations.  This paper concluded that the power brokers (survivors) were the:

  • Boundary spanners (those who communicate between teams);
  • People who understand their own knowledge needs and the knowledge needs of others; and
  • Those good a team facilitation (workshops, meetings and BA stuff).

I pondered these papers (which still need filing) and I began to think about the book “Bargaining for advantage” by Richard G Shell.

This is my favourite guide to negotiation.  Among other things the book stresses the importance:

  • Information gathering and understanding in the negotiation process (ie what BAs do);
  • The importance of knowing who the influencers are in a negotiation (often the BAs); and
  • Knowing where to go to bring outside (but maybe biased) views to the table to influence the discussion.

I began pondering the idea of finishing my filing, but instead drifted off to wondering how much power BAs have.  It seems to me that they wield vast organisational and political power on projects, in their teams and in their organisations.

Yet, one of the gripes I hear from BAs is that they don’t have any power to make things happen on their projects.  All power rests with the PM and the BA is mere a pawn in the mighty game of organisational politics.

I have concluded that in fact business analysts DO wield vast power.  They just claim that they don’t.  I’d be interested to know if you agree.

I’d also be interested to know the answer to my new question – If, indeed, the BA does wield vast power and yet claims not to …. is this because he or she is unaware of the power of the BA, or is it a conspiracy, where they are controlling the information to keep everyone else ignorant of the impact they are really having on the world?

 
Leave a comment

Posted by on February 26, 2010 in Business Analysis, Culture