Thursday, March 29, 2012

I am a Business Analyst. Where do I fit on our Scrum team?

Recently, I was chatting with a team member on a newly formed SCRUM team.  Her background is as a Business Analyst (BA).  They are not a customer of mine, just someone I know going through a transition at their company.  I'll call her Sally.

She was concerned that she didn't know if SCRUM was right for her because "In SCRUM there is no Business Analyst". Sally "didn't want to become a developer.  There is too much of a skills gap".  Her words, not mine.

I thought I'd respond to her here and perhaps share some ideas for others that might be going through the same sort of question.  Maybe these ideas will work for you or maybe not.  If more than one person can be helped by reading this, then great.  It's just food for thought.

On a SCRUM team, team members are expected to work on Stories (a piece of functionality or value for the company or customer) as a team.  This means that everyone pitches in to complete tasks to finish the story.  YES, this means you will need to learn SOME development skills. The reality is, if  you're truly working WITH the team, it seems highly unlikely that you wouldn't learn something, just by proximity and osmosis alone.

What should be said though is that if you feel that being on the team means you will become a developer, something is missing from your environment.  The team should be cross-functional.  This implies there are people with different backgrounds and skill-sets coming together to try and deliver a Potentially Deliverable product each Sprint.  It also implies that team members learn more about each other's skill sets.  This to me at least is part of the fun of being in a SCRUM environment.  I love to learn.

You (as a BA), help the team in many ways.  Firstly, you have a natural ability to notice that what is being created is not what the "customer" is looking for.  On an Agile team, you don't need to wait until the entire Sprint is completed to recognize this.  Your abilities are vital during Sprint Planning, during Grooming and during the complete development of every story.  You are a very important part of the product delivery.

As you are working on these stories together as a team, you have the same level of input into the stories as any developer on the team.  You need to be asking yourself, "Why is my team not working on stories together as my input is valuable?" Talk to your team about this.

There is more to software delivery than just writing code.  Agile Testing is a form of QA (that is imperative to successful delivery) and is actually closely related to your existing mind-set.  Perhaps you don't have the technical skills in that area today, but you'll soon discover that if you take the Testing position seriously, it can be more like what you naturally do as a BA than you might expect.

Yes, there are some specific skills to learn (some which might require some development type knowledge).  Professional QA is a career in itself.  I don't want to lessen QA career skills here, just trying to help with a possible solution for you.  The key here is for you to learn this WITH the team's help and for the team to learn from you.  You are in it together (or should be).

As a SCRUM team member, you still need to want to learn the skills of the other team members to become a more rounded person.

However, I  know that even if I spent a year in design school, I would still be just an OK graphics designer, and not an expert.  It's just not in me.

That being said, I still learn what I can about it. I have learned for instance that I should not leave only a 10% space at the top of the page without talking to the graphics person on the team BEFORE I decide to do that.  I have also learned that I should not assume that the page will be white and design everything up front based on this.  This is why we should work TOGETHER.

In a pinch, I could probably pull of reasonable graphic.  I wouldn't be afraid to do it if it was left as a task on a team I was on.  For me, at least, this is part of the fun of SCRUM.  I needed a graphic for this page, and managed to make the graphic on the right :->

Generally, when people say they don't want to try new things, it is because of their Environment, not that they don't want to learn.  This is where you should have your Scrum Masters and / or Coaches help the organization to change to give you the ability to feel comfortable with experimentation.  Experimentation and learning from mistakes is very important to becoming exceptional team members.  You need to be able to learn new things and inspect the results as a team.

Sally, I know you have a passion to help the customer and listen to their needs.  This is ideal for a SCRUM team.  The customer is a VERY important part of the process, and no amount of teamwork will be worth it if the customer won't or can't use the product when the team is done.  This is why there is a such an aggressive requirement to have the Product Owner or Customer's representative there during the very quick development cycle.

Sally, you've told me that the company has not agreed to provide Q.A. people for the team.  As you mentioned, the team is sharing this responsibility.  YOU however, have some very special skills that you already possess; The ability to see the customer's viewpoint.  This is invaluable to the team.  In a SCRUM team, "QA" or testing is a CONSTANT part of the process, not something that happens at the end.  Every screen, every bit of important logic, should be considered from the perspective of testing, both technically and from the user's perspective.  A development team member really shouldn't be writing logic without discussing it with others on the team to make sure that it can be tested and that it makes "business sense" as well.  Think of usability for instance and it's importance.

You already have the goals and aspirations related to quality for the customer.  It may be a natural fit for you to think of yourself as an Agile Tester and learn more about it.

In the book "Agile Testing, A Practical Guide for Testers on Agile Teams", Lisa Crispin and Janet Gregory have the following to say about Agile Testers;
Agile testers see each story or theme from the customer's point of view but also understand technical aspects and limitations related to implementing features.  They can help customers and developers achieve a common language.
Hmm.. Sounds like how BA's think to me.

As your team gets faster (if they work as a team and not individuals), they have the ability to create software Really, Really Fast.  Without the QUALITY part of the equation, your company risks making lots of BAD software, Really, Really Fast.

Since you find yourself in this position, why not consider learning more and just "assuming" the responsibility of improving QA practices on the team (with them knowing so of course).  You already have the emotional desire to think about the customers' desire for quality.  You obviously have SOME technical skills.

This doesn't mean you should be the only one on the team doing this.  Quality is still and should always be a complete team responsibility and you shouldn't become the only person who cares about it on the team.

Testing and the testing mindset is a very important part of software development.  QA professsionals will learn a bit about coding and coders should and will automatically learn about how to think more like a tester.

So, although you have some problems on the team, YOU have the power to work with your team to help yourselves out.  You've told me the team needs QA , and that you all recognize it as an impediment.  This has been going on for several months.  Clearly your management is not listening, which is truly sad.  Perhaps instead of you being frustrated, you could just start to do something else to help the team out.  Try out the book "Agile Testing from Lisa Crispin and Janet Gregory", and see if it inspires you.  Perhaps, try one or two of the ideas from it.  Maybe you'll surprise yourself how much you like it.

Yes, you will still do some occasional coding, but there's NO WAY the team should be delivering software that hasn't been tested at all during development and without the benefit of someone thinking about the customer's view-point from a technical perspective (someone like you are).

Another alternative for you is to pursue the Product Owner role in your organization.  That might work for you as well.  This would be up to you.

After you've tried all these things, you might still find that SCRUM is not for you.  No one ever said it was for EVERYONE, though a team of only pure development really isn't a SCRUM team either, which might be part of your frustration.

You should give yourself a chance to learn the "Agile Tester" idea and see if you can help your team out that way.  The team, and the company should really appreciate it, and you'll have learned some new skills, which could never hurt you :->

Maybe you'll even discover a whole new career path you never saw before!

You're in a big company.  If all else fails, you could always go to a non-Scrum team, or migrate into the Product Owner Role somewhere.  Your company is big enough that you could easily do this.

Another thought, though not pleasant; you MAY be holding the team back by not embracing the idea of cross-functional work, especially if they are all prepared to so and you are not.  I don't believe that's where your mindset is, but I needed to mention it.  If you simply don't want to work with others, learn and share with others, no amount of reading, practice or coaching will change that in you.

Anyone who tells you that Quality and the customer isn't an important part of SCRUM, is seriously missing the point. It's about delivering VALUE.  Software that the customer can't use; likely has no value, other than to your competitor.

Mike Caspar




Saturday, March 17, 2012

Continuing on the path to a "Test Driven Mindset"

In September, 2011, I made a post called "How to Introduce a Test Driven Mindset".  You can read it HERE if you're interested.

I had introduced OpenAgile to a small software development company with team members in Toronto, Montreal and India.  They have been using an iterative approach to development with continued improvements to productivity since then.  At the time, we talked about the concept of thinking in terms of "How are we going to test this" before writing code.

Many people (including developers) have a hard time seeing the benefits of thinking about testing as a way to save time in the development process.  Often, tests are created "after the fact".  Unfortunately, this is often what causes the biggest hurdle to learning the practice.  Trying to write tests for code that was not intended to be tested can be more troublesome than simply learning to create the test first.  There are ways to test legacy code.  I won't get into that here (at the end of this article, I'll put a link to wikepedia about mock objects or "mocking".

Back to the company that inspired this article...

It has been a tremendous help to the company to work on the highest ROI items first and to be moving forward toward their goal of potentially shippable software each cycle (OpenAgile uses cycles for iterations and encourages progress to be made primarily through Learning).

I have been visiting them for a few hours every week for a few months now, and have been reviewing problems they have been having with their application as they crop up.  They modify something and a problem re-occurs from code they fixed weeks ago, or even months ago.

As each cycle goes by, they have a larger and larger list of regression testing to do as the tests are not automated.  They find defects that they have fixed before because of a recent change.  Sound familiar ?

As I introduced the Mindset to them back in September, they knew exactly what I mean with my usual response; "Hey, you know EXACTLY how to improve this situation.  You just need to find a place to start."

I know it is very difficult for someone to immediately jump right on board the testing mindset. It can be a slow road and isn't easy to switch to if you're in fire-fighting mode... One step at a time is better than no progress at all.  

Often, the difficulty is that the idea of Testing is too abstract or not directly related to what the company does to have it make sense.  As defects from the past crop up, just gently bring them up as examples of problems that could be avoided with an Automated Test.

I find that nothing works better than real life examples.

Unfortunately, fixing old defects might be tougher to do as they were likely not designed to be tested.  Start with something easy.  You will find it likely that the team would prefer to start with something easy as well, so this will work out just fine.  You can even get the ball rolling by including the "FIRST" test into their testing environment or Source Control.  That test could simply be to make sure the testing environment works, such as 1+1 should equal to 2, or my favourite, Assert.AreEqual(true, true);

PLEASE be careful and prepared.  If things happen like they did for me at this company, one day they will take you up on your offer and want you to assist them to create a Unit Test.  You should be prepared to help them or, at least know someone who can.

It's a big deal that they are finally willing to give it a try.  Don't lose this wonderful opportunity to help the company out!

by Mike Caspar



Original Post -Sep 2011Introducing a Test Driven Mindset
Test Driven Development
JUNIT (Java)