Test Driven Requirements

{Disclaimer – this is a cross-posted article appearing both on the Triton-Tek blog and my personal blog Budding BA}

My job at Triton-Tek is not an easy one to define, but predominantly I am a Business Analyst and Project Manager on Agile web development projects, see my previous articles here and here.  However there is one major project on which I have been working since day one that has required a lot of Quality Assurance (QA) support from me so that the developers get quick feedback on their work.  This work as a QA, has been incredibly beneficial to me as a BA in crafting the requirements for the project.  In an Agile environment, the approach is very much “just-in-time”, and the same applies to requirements gathering.  We will have a set of stories for the release, and a plan for the current iteration, but the specific ins-and-outs of the stories are still very foggy.  So as a BA I will add details to the stories as they come up, but often it is an iterative feedback loop that defines the requirement.

Agile User Story completion cycle

Because of this emphasis on QA in my role I started to read about how to do this in an Agile fashion, and the results are fascinating.  The connection between the QA role and the BA/requirements role in Agile projects is very strong, and the Agile testing techniques I have learnt have helped my requirements analysis and definition as a result.

This mindset change starts with the “Agile Testing” book by Lisa Crispin and Janet Gregory.  It is quite a large book, but very practical and describes in detail the daily hands-on role a tester must play on an Agile project.  I will not review the book here, that is another post on its own, but I am adding the Agile Testing Quadrant below as it gives a good overview of the different areas of testing.

Agile Testing Quadrant from "Agile Testing" by Lisa Crispin & Janet Gregory

Essentially the book drills home the many different angles from which the product must be tested in order that you can be sure of as solid an end result as possible.  Critically the developers must practice Test Driven Design (TDD) for this all to work.  This is accomplished by starting with failing unit tests (because the functionality does not yet exist) and then coding the solution so that the tests now pass.  So for example, they would start with a test titled “User can enter a username and password to login”, and then code the user login functionality so that the test passes.  I learned of TDD upon starting at Triton-Tek and understand what its purpose was, however since reading this book my eyes have been opened to how the same approach can be used when gathering requirements, and how that can feed directly in to the code, simultaneously creating automated unit tests and setting the acceptance criteria for when a story can be considered “done”.

Now, before I continue, I want  to stress that this is not a new discovery on my part, there is a community around Acceptance Test Driven Design and Behavior Driven Design (BDD) that talk about exactly this process.  However, as a BA with no coding background, the personal progression in understanding of how this all ties together is one from which I think a lot of BA’s can benefit.

Going back to the quadrant above, the area we are focused on is Q2, the functional and story tests that can be automated.  The book specifically talks about using the FitNesse tool to automate functional testing.  This tool allows you to create understandable “business” phrases, using a certain format, that the developers can then take and use a fixture to directly test their code to make sure the functionality works as the business expected.  The great thing about this approach is that it expands on the quickly jotted down acceptance criteria on a story card so that the developer is immediately presented with the list of tasks he or she needs to complete in order to call the story done.

From a BA perspective, this approach is hugely helpful.  Since reading about FitNesse, I spoke with the team at Triton-Tek and Matt Hidinger recommended SpecFlow as that uses the more business and domain friendly BDD approach, building on the Cucumber syntax, and integrates easily with TFS and the .NET world in which we work.  In BDD, the tests are created using the following syntax:

Given [condition]

When [action]

Then [result}

So an example would be:

Given the user has already registered

When the user enters the correct username and password on the login screen

Then the user will be logged in to the system

These “Given .. When .. Then” statements can then be used by the developer as the basis for their unit tests ensuring the functionality of the story meets the business / user requirements.  This is a very simple, but powerful tool for a number of reasons critical to a BA’s work:

1. The language is easy to understand, so it can form the basis of supporting requirements documentation.
2. Anyone can write them, so you can pull in stakeholders and product owners to directly contribute.
3. They encourage analytical and practical thinking about the requirement.
4. Reduces the lost in translation problem of transferring business requirements to the developer.

So now with my BA hat on, when I am expanding on the requirements for a User Story, I can start walking through the many business rules, user scenarios and use cases using the “Given .. When .. Then” statements.  This always end up uncovering hidden problems or complexities, that may not have been discovered until development had begun.  It is also a fantastic way to keep the product owner or client representative involved, the statements are easy to understand so any business user can create them, meaning that they are setting their own acceptance criteria.  This is very important in a consulting environment such as ours where any misunderstanding of what functionality a user story should actually achieve can have large monetary and client/contractor relationship ramifications.

Now with my QA hat on, the biggest bonus to this approach is that I have simultaneously created automated functional tests, and encouraged TDD behavior from the developers.  This should allow me to focus on the more fuzzy (and in my opinion, interesting) exploratory and usability testing, which is where I can add the most value to the product and the team.  Overall, everyone wins, and most importantly the requirements are delivered seamlessly from the business to the development team.

Resources on this topic:

• Agile Testing: A Practical Guide for Testers and Agile Teams by Lisa Crispin & Janet Gregory
• Lisa Crispin’s blog and follow her on Twitter @lisacrispin
• Brian Marick’s blog – an Agile tester and developer, strongly influenced Lisa Crispin
• Behavior Driven Design (BDD) – the original article by Dan North
• SpecFlow – the .NET BDD tool
• Cucumber – the language behind SpecFlow
• Acceptance Test Driven Development – also see the deck below
• Yahoo Agile Testing Group

When User Stories are not enough

I recently attended an interesting webinar by MKS on why User Stories are sometimes an inadequate representation of requirements.  I thought it raised some excellent points, and certainly got me thinking.

Starting with a refresher on what User Stories were, the presenter Colin Doyle emphasized how they are NOT a requirements document.  Instead they are a placeholder for continued conversation on that particular piece of functionality and used especially for prioritization.  They are the tool through which requirements are communicated and discussed rather than delivered in the form of hefty requirements documents (see this excellent article from Mike Cohn on User Stories).  As Agile prescribes, in teams where face-to-face, daily communication is possible and the Product Owner and key stakeholders are readily available, the User Story format works very well.  Each story follows the INVEST criteria and are first and foremost independent of other stories, and the non-functional requirements or constraints do not dominate.  With each iteration, the product develops incrementally with the gradual evolution and folding back in to the project of the inevitable changes that will arise as the product comes to life.  If there is a need to review the requirements and see the “big picture”, then the User Stories in combination with Test Driven Design (TDD) or Behavior Driven Design (BDD) practices, should provide all the details you need.

Colin Doyle argued the point however that there are 3 key issues with this method, all centered around the scalability:

1. Too many customers for the product resulting in conflicting requirements and a significant effort to understand customer environments and needs.
2. Complex products with significant interdependencies, lots of exisiting requirments and the lack of a way to see the big picture easily.
3. Large organizations where “scaling of face-to-face conversations is an N2 function (Brooks)” and may include offshore or off site teams.

Therefore he recommended the careful introduction of some traditional requirements engineering practices to help solve these issues.  In particular using modeling techniques such as use cases, decision

Use Case Model example

trees or event-response tables to get a handle on the big picture.  This will help the project in number of ways.  Firstly the developers will understand the full scope more clearly and so guide their TDD/BDD test cases and hence their code.  It will also help the Product Owner who may be unable to remain fully informed for large, sprawling products.  These requirements artifacts will also form the basis for a high level dependency analysis from which relatively independent User Stories and backlog items can be derived.  This should ensure that you arrive at a position with nicely traceable project, from the high-level product owner level down to the actual code.  The presenter was not arguing for a bastardization of the Agile philosophy by doing this requirements analysis upfront, he stressed it should be performed in a just-in-time, iterative manner, and the requirements artifacts changed and adjusted as the product develops.

I am receptive this approach.  I don’t think that the Agile community should unconditionally shun traditional requirements engineering practices as “old-school” and no longer relevant.  My concern with the approach is how easy it would be to slip in to a gather requirements up-front process.  The models and artifacts could become weights around the neck of the project requiring constant revision, whilst at the same time being the excuse why something was done a certain way.  I believe that the Agile methodology, with it’s primary emphasis on conversation over documentation, promotes an environment of “ask before you act”, to ensure that the correct path is chosen.  If there is too much documentation available, this can be viewed as the definitive answer, and reduce the amount of communication within the team and clarification with the product owner.

But that is not say I am ruling this out, and in fact I think I will try and incorporate this approach in to the next complex project I work on.  I think that so long as the culture of the team remains inquisitive and conversation intensive, these models can be good aides to discussion, just like user stories.

Failure and the Agile solution

Failure.  Not a great word, and something that genuinely strikes fear in to people’s hearts.  Over the past few of months I have listened to a couple of podcasts that have offered differing views on failure.  This is a topic that has always been at the forefront of my mind, as I always wanted to be someone who was not afraid to fail.  Obviously no-one wants to fail, but if you have the concept ingrained in your psyche that failure is an acceptable part of success, then you are more likely to listen with an open mind and try new things.  But life and work is competitive, and human mentality leaves little room for failure.  I work for a consultancy where the Owners are working every day to win new projects.  Once the projects are won, they must in turn be successfully implemented.  The web application or web site must be completed on time, on budget and meet, if not exceed, the requirements.

So where can failure fit in to the software development process?

Before answering that I will quickly summarize the two podcasts that inspired this article and their differing points of view.

I.A. Podcast – Failure: The Foundation for Success

Jeff Parks interviewing Brad Nunnally

This podcast really emphasizes a need to embrace failure as part of a design and development process.  They cover three key parts to failure recognition:

1) The importance of retrospectives and documenting warning signs to learn from past mistakes.

2) Not to shy away from assigning blame and highlighting the success of others.

3) The importance of embracing failure and keeping an open mind, realizing that everyone makes mistakes

Through a combination of these ideas, Jeff and Brad believe the quality of your work will increase and you will garner more respect and a closer working relationship with your colleagues and customers. Furthermore, the very act of embracing failure will leave you more open-minded.

37 Signals Podcast – Jason Fried’s speech at BIG Omaha 2009

Jason Fried is someone I respect hugely.  He is an entrepreneur who brings a forceful clarity of vision and thought to his work.  His blog articles and podcast episodes are always thought-provoking and centered around forthright, positive action, and the distillation of problems in to simple concepts.  During this podcast he references a previous article he wrote on Signal vs. Noise titled Learning from failure is overrated, which takes a very different view of failure to Jeff Parks and Brad Nunnally.

Jason does not agree with a culture of celebrating failure that he thinks has developed over the last few years.  Critically, Jason’s view on this topic is from an entrepreneurial / business perspective, not a development team perspective, and from this vantage point he see’s embracing failure as absolutely the wrong approach.  If you are embracing failure then you are focusing on the wrong thing.  Jason says that you should focus on your successes predominantly.  If you tried 10 things and 8 failed, you should focus on the 2 successes and try to replicate that, rather than analyze and emphasize the failure.  He is not suggesting you ignore your failings, and obviously lessons should be learnt, but for progress to be made you need to be successful, so that should always be your focus.

So to go back to my earlier question, where does failure fit in to the development process?  Agile would be my answer.  The Agile process encapsulates many of the points highlighted by these two podcasts, and my own beliefs on failure, and enshrines it in a procedural guideline that failure will happen and is just part of the process.  The key tenets of this philosophy in relation to failure are captured in these points.

1) Iterations

The very reason for iterations is that there is an implicit understanding that the first time around not everything will be correct.  The best we can do is strive to complete a requirement as we understand it at this point in time.  At the end of the iteration it will be reviewed and tested as it will be a working piece of functionality.  Feedback will come from the customer and it is either signed off as done, or that changes need to be made, or new stories added to that theme.  There are no failures as such, just a cycle of build and review that will eventually result in the finished product.  This both embraces failure as part of the process but also focuses on the positives and what is right in that first release, and builds from there.

2) Iteration retrospectives

Iteration retrospectives are such an important part of the Agile process and yet one that does seem to overlooked at times.  We were guilty of this in one of our recent projects and I think we repeated mistakes as result.  A retrospective is where the cards need to be laid on the table and a open discussion needs to take place.  Each team member needs to be honest about what they did well and what they struggled with, whether that be a personal issue or one with another team member.  The failings of an Iteration are clear for people to see, but what is most important, is laying out a plan for how to mitigate these problems going forward.  Often you can do this by looking at what has worked well and using those lessons learnt.

See this great article on retrospectives also: http://www.agilegamedevelopment.com/2008/06/when-we-talk-about-agile-we-use-phrase.html

3) Team work

Brad Nunnally in the IA Podcast mentions the flat team structure of Agile projects as a negative when embracing failure because there is no one in a position of overall responsibility to make owning up to failures possible.  I believe this to be an issue with the team in which Brad is working rather than an issue with Agile teams.  Your team in an Agile project is a team of equals.  You should all be pulling in the same direction, and are responsible to yourself and each other to complete your tasks.  There is no wall over which you can throw work.  If work did not get done, whether it was your task or not, it is the teams failing, not the individuals.  Whoever was assigned responsibility for the task will have to be the one that announces the failure, in the daily stand-up or retrospective, but it is the team who bears the responsibility.  Everyone must rally round to dissect why the problem happened and how it can be addressed.  A failure occurs because it was not raised early enough, or it was not addressed when it was raised.  If the problem was never raised by an individual, that can be a case where individual failure has occurred, and is most likely a personal trait that needs to be worked on, such as talking up when you need help, something that can be difficult for some people to do.  Obviously this becomes more difficult if there are disinterested or unmotivated individuals on the team, and if that is the case then we are moving in to the area of HR rather than Agile self-organization.  Overall, working in a self-organizing, flat team of project oriented individuals, should result in a culture of union of purpose where failings are embraced by the team, along with the successes.

So shall I just go out a start screwing things up?

Well, yes and no.  I think there is value in both Jeff Parks/Brad Nunnally’s embracing of failure and Jason Fried’s embracing of success.  I think it is important to have a healthy fear of failure, so I do cringe when using the word “embrace”.  That is being a little too familiar and comfortable with that outcome.  Failure should, and always will be, a prickly and uncomfortable topic, and I don’t think that is a bad thing.  We do not want to fail, we want to succeed.  If you are too comfortable with failure, you may start to confuse progress with consistent failings.  Lets not forget, failure does have a consequence, whether that be a monetary loss, or a disgruntled customer.  Positive reinforcement is needed to make sure that what is working is captured and repeated, and demonstrable progress is occurring.  I think this quote from Fred Brooks (author of “The Mythical Man-Month“) in the most recent Wired (August 2010) says it well:

You learn more from failure than success. In failure you’re forced to find out what did not work. But in success you can believe everything you did was great, when in fact some parts may not have worked at all.  Failure forces you to face reality.

I like that last sentence, “Failure forces you to face reality.”  I absolutely agree, but the nature of reality is that we need to succeed or else we may not get another chance at failing!  So I would say, lets embrace our successes but make sure to face our failings head-on, taking positive action to ensure the same mistakes are not repeated.

My Favourite Podcasts

I have become a firm fan of podcasts over the last couple of years, and listen to a lot in the area of software and web development. So in the manner of blog posts that list things, here is my list of favourite podcasts (in no particular order).

You will see that many of them are focused on User Experience (UX) or Design rather than being straight BA podcasts.  This is because the BA podcasts I have tried have not been nearly as engaging, interesting, or thought-provoking as the UX/Design ones.  Also there aren’t nearly as many of them.  I find the UX side of web development really fascinating.  The intersection between  psychology and user interaction is such an evolving field, and I find that a lot of the concepts I learn from these podcasts are very applicable to my BA’s work and how I approach a project for a client. Anyway, enough waffle, here’s the list:

UIE Brain Sparks – Jared Spool

• SpoolCast – My favourite podcast.  Jared Spool is a godfather of web usability and user research and he interviews various UX and Usability professionals.
• Userability – Jared and Robert Hoekman answer questions from listeners.
• Revealing Design Treasures from the Amazon.   This is one of the best of the bunch, Jared gives a conference talk on the design secrets of Amazon. Genius, and funny.

I.A. Podcast – Jeff Parks

• Primarily about Information Architecture (IA), but a wide variety of guests from different backgrounds and different specialties and perspectives.
• See this episode on Agile and the User Experience.

Boxes and Arrows

• Again an IA focus, but very design centric also.  The best part of this podcast series is they post all the talks and sessions from the IA Summit that happens every year, and there are some really fascinating speakers.
• Check out the key-note speaker Dan Roam from the 2010 IA Summit, I really enjoyed this one – http://boxesandarrows.com/view/ia-summit-10-dan.

Boagworld Web Design – Paul Boag & Marcus Lillington

• I may just like this because it is English and I get to top up my accent, but it is also very relaxed and engaging and I love the split between web news and interviews. It’s also funny.

The Big Web Show – Dan Benjamin and Jeffrey Zeldman

• They have very interesting guests, and it is live streamed.  I think Dan Benjamin is a very natural presenter and has great questions, I listen to his other show also, The Pipeline (see below).  The co-host, Jeffrey Zeldman, is not so natural, however he is a powerful presence in the industry as he started A List Apart and works for Happy Cog and often has poignant things to say, although he doesn’t always say it at the right time, and it can interrupt the flow of the conversation.

The Pipeline – Dan Benjamin

• An interview show typically with web entrpreneurs who are always really intelligent, well spoken, well read, and basically interesting and succesful people.
• Try out this show with Jeffrey Veen (who started Adaptive Path as we ll as a myriad of other successful ventures).

37 Signals Podcast – Jason Fried & David Heinemeier Hansson

• An awesome Chicago company responsible for products such as Basecamp. They are passionate about creating usable products, and have firm opinions on entrepreneurs and start-up web companies who actually have a business model and can make money. Dare to dream 🙂
• It’s not a podcast but check out the “Bootstrapped, Profitable, & Proud” series starting with the interview with the guys from Campaign Monitor
  

Think Vitamin – Keir Whitaker, Ryan Carson, Mike Kus

• I’ve only listened to a couple of these but I enjoyed them. They do get in to more codey speak occassionally, but they are also great designers.

You Look Nice Today – Adam Lisagor, Scott Simpson, Merlin Mann

• Just hilarious. Not web, or design, or in fact focused on anything at all. Three friends shooting the shit.
• Merlin Mann started 43 Folders which is one of the original productivity sites.

TED Talks

• Just because they’re awesome.

Requirements.net Podcast

• The only BA focussed podcast that I still occasionally listen to, worth checking out.

Agile Toolkit – Bob Payne

• This looked really promising when I first found it, but after listening to a few, it always seemed like Bob was interviewing success stories for his Agile coaching, and the discussion was too specific to one company or situation.  It was kind of like listening to a really long in-joke you would never get unless you were there at the time.  However some of the new episodes look interesting so I may try it again.

dConstruct 2009 – Various

• A conference run every year by the Clearleft web design agency in the UK.  They have posted all the talks from the 2009 conference as podcasts and they are really fascinating.

I hope you enjoy these as much as me. I’d love to hear your comments.

Cheers.

Mind Maps – A Love Story

It’s a tacky title I know, but what is really tacky is that it’s true. Over the last few months I have used Mind Maps for such a wide variety of situations, that I thought it deserved its own blog post.

I have found Mind Maps to be an extremely versatile visualization technique, helping me capture and clarify information.  Through the presentation of disparate information objects on one screen, connections between those objects present themselves naturally. I have personally found it also promotes creative thinking.  Because the maps removes the notion of a list or paragraph of text, it instead encourages your brain to not only make connections, but also to think ahead, imagining new and different threads growing from the connected or unconnected objects.

Here are some examples of the scenarios when I have used Mind Maps.

Requirements meetings

This is a BA blog so requirements are the most natural place to start. I have used the Mind Map tool to capture notes in a meeting on requirements and have found it to be very effective. By creating a node for each requirement stemming from a central node of a theme or screen, the notes and comments build around the requirements nodes very naturally and you start to quickly see questions and dependencies between requirements.   Using the relationship arrows, references to previous points can be quickly made, and those relationships jump out at you because of the presentation style of your notes. Also little features such as adding Priority and Star icons let you markup your notes effectively so they can be efficiently acted upon later.

Brainstorming

This is the classic application of this tool. The quick way that nodes can be created, manipulated and connected is perfect for a session where you need to come up with a new idea or creatively work your way out of a situation or dead end. There is a throw-away and casual nature to recording information on a Mind Map.  It feels flexible and malleable, and more of a marker for further discussion. Noting down something on a list creates a more static representation of the information, and, to me anyway, constricts my thinking on topic.

Brainstorm

Workflows – States & Transitions

This was a surprising application of the tool, and I cannot take credit for it either. A colleague was trying to get his head around the workflow and accompanying states and transitions for a touch screen Silverlight application our team had developed.  There was a bug and it could not be nailed down and we needed some way of seeing the steps on the UI and the behind the scenes associations to methodically track down the problem.   Using the mind map tool, combining the structure templates provided to arrive at a fluid and effective visual representation of the workflow.  It was a more “folksy” or ad-hoc approach to a formal UML activity diagram in Visio, but was immediately understandable and allowed everyone on the team to contribute to solving the problem, whether they are tech minded or not. Since then I have used the same method for a Site Map that also showed a fields and associations. I plan to write another blog post on the discussion this raised for me about when to use formal diagramming techniques vs. whatever technique transmits the information most effectively to the average person.

States & Transitions

Problem Solving

Finally, I have used mind maps to flesh out ideas or to start solving problems that are rattling around inside my head. One of my idiosyncrasies is that I am a verbal problem solver, by saying something out loud I start to understand the problem better and so more often than not arrive a solution at that very point of verbalizing.  But for those times when talking out loud is not possible, I have used mind maps as a way to quickly right down the key ideas and connect and move them around, and the results have been very similar.  It gets those problems out of my head and allows easy manipulation which often allows the answer to present itself.

So what mind map tool(s) are you using I hear you cry? Well just one has been enough, and the good news is it is free!  Check out XMind (http://www.xmind.net/).

You can also try these options listed in the Wikipedia entry on Mind Map Software.

The Agile BA / PM – First Impressions

So I am 12 weeks in to my new role as an Agile Business Analyst, so I wanted to give a summary of my impressions, and how the role combines with being a Project Manager and QA part-timer.

1) Documentation

No more paperwork!

This is the biggest area of change for me, and from my perspective a welcome relief.  Gone are the bulky Business Requirements Documents that I slaved over for days, only for the customer not to read, and for the team not to look at again once the review is over.  Agile is agile because it is nimble.  You do not weigh yourself down with hefty tomes, documenting every in and out of the project.  Instead, stories, and scenarios are used.  Work is done firmly at the business level.  What does the business need?  Let the Technical Lead do the interpretation.  Yes you need to be grounded in technical reality when the implementation starts,  but you don’t know why you are doing it unless you have captured the business level goal.  This can normally be captured in a sentence, or short story, and the simpler the better.

2)  Requirements Gathering as a Conversation

Requirements are a continuous dialogue.

The convention of Agile requires that the customer be heavily involved in the project throughout the lifetime of development.  Although we cannot incorporate the customer to the level we would like, we are still delivering working functionality and demos every week or two, so a constant stream of feedback is available.  This dramatically changes the requirements gathering process.  Working from iteration to iteration, as the BA I work ahead of the developers as much as possible, reviewing the stories and clarifying requirements.  However more typically I am working in the moment with developers as requirements questions come up, because they don’t know the roadblocks or lack of understanding until they really get in to working on a story.  So on these occasions, we are having ad hoc meetings with the customer, discussing their needs and working through use cases, that will result in working functionality very quickly, typically no longer than 2 weeks.  The discussion therefore remains fresh in their mind, the decision is captured and implemented quickly, and the presentation of the result is fast.  I have found this to be a very effective way to seek requirements and verify their understanding.  Nothing is ever captured and documented, never to mentioned again until weeks or months later when the product is delivered.  This is why requirements gathering now feels like a real dialogue, a never ending conversation stream connecting the developers to the business, and vice-versa, through myself and the Tech Lead.

3) Project Management

Not Project Manager, Project Co-ordinator.

This is the completely new area for me as I have never been a Project Manager before.  However, once again, Agile to the rescue! The PM role in our Agile projects is very limited, and in fact we call it Project Co-ordinator to stay true to the team ethic of Agile.  We are all in it together and not under the instruction and watchful eye of a manager per se.  The small teams, and heavy involvement I have as the BA means that I have my finger on the pulse of the projects progress.  But more importantly, the iteration development cycle means that we are never falling behind schedule or stressing about keeping Microsoft Project up to date.  We assign stories to be completed in an iteration, based on the number of points we estimate can be completed.  One or two weeks later, we know if we have hit that or not, and we estimate the next iteration based on the last.  Apart from that, I do some burn down charts, however not for all projects, it depends on the customer, as does whether they need some thorough updates as we progress, but really the PM responsibility is limited.  Most critically in this role I feel the need to stay Agile.  Don’t get bogged down in facts and figures and work that does not have business and customer value.  It is a powerful motivator to stay on track, and follow only those critical metric required for the project to succeed and to keep the customer happy.

4) QA as Usability Testing

What is the customer experience?

I have found this area to be the most challenging and perhaps, dare I say it, the least interesting part of the process.  It is a vital aspect to the process, no doubt, however my lack of training or formalized approach to this function means that I maybe create more work and more repetitive actions as I feel my way through the process.  However, I have found it is an excellent opportunity to do some rudimentary usability testing.  I put on my “I am the user or customer” hat and dig in to the fledgling software, asking the basic or simple questions of the developers to see if there is a better or simpler way to do things.  So it is not just Use Cases, bugs, issues, report, it is once again a more fluid dialogue of not only the issues found but maybe a better way to organize a screen or function during the next iteration.

Overall, I am thrilled with my new role. I am learning so much, and I am involved in so many things that I have wanted to be doing for so long now.  I will try and keep the articles coming as I truly define my place as a Business Analyst / Project Manager in the Agile software development world.

Thanks again for reading!

Great slide shows from Pathfinder

I came across these two great presentations about Agile on the Pathfinder blog, which is something I check from time to time being an Agile development shop in Chicago.

The first slide show is about integrating design in to the Agile process.  Something that is not really addressed in the Agile Manifesto, and is something I have posted about before.  It is critical area for Agile BA’s to address because the dive in and deliver functional code approach of Agile is great, but can lead to a very haphazard design with no clear vision.

The second one on Writing User Driven Requirements just really helped bring me back again to always thinking about the user.  I am certainly prone to thinking about business needs, or developer/technology constraints only, but the user should always stay front and center.

The Integration of Design and Agile Development

View more presentations from Pathfinder Development.

Writing User-Driven Requirements

View more presentations from Pathfinder Development.

The Business Analyst and Knowledge Management

Knowledge is valuable

I have read a few articles recently that have talked about the promotion potential of Business Analyst’s, particularly at Laura Brandenburg’s excellent http://www.bridging-the-gap.com.  What jobs are open to a BA? What skills do you have that can open new avenues?  I think this is a very valid discussion as the BA role can seem pretty flat in terms of long-term potential.  What is the career path? Senior Business Analyst? Super Senior Business Analyst?

There are typical answers to this, the most common being Project Manager, but that is one that I find distinctly unappealing.  I think being an Analyst means you are the type of person who likes to get in to the weeds of a project a little too much for you to transfer nicely to a PM role.  In a previous post I spoke about the cross-over between a BA and an Information Architect, and I still believe this is an open avenue, but this may be too “webby” or design focused a step for some people, as well as being a rare field, still growing and maturing and hence difficult to access.

As part of my Masters in Business & Information Technology at DePaul, I am taking a course in Knowledge Management, and it is fascinating.  It is such a fuzzy area and almost a non-subject according to some, however I see a lot of value in it.  It centers around not only how do we collate what we know in to knowledge bases but also how do we identify, stimulate and capture this information from experts within the organization.

Something that seems very clear to me is how a Business Analyst can significantly help in this area, if they have worked within an organization for a period of time.  Over the course of various projects, many interviews have been conducted, problem domains examined and modeled, and a sense of the organizations knowledge centers would have been subconsciously formed.  As the BA who is observing and objectively analyzing how information, data and processes flow within a company, they are essentially tracking the knowledge flow through a company, how it is formed and who are the creators, experts, team players etc. who contribute to it’s formation.

So when you are next creating an Activity Model, or interviewing key stakeholders for a new system, keep in mind that you are also tapping in to a key knowledge resource, that has a broader importance.  If there is a knowledge management initiative at your company you may then be able to leverage this information outside of the main project focus.  But if there isn’t a knowledge management initiative, then maybe this is a good way to propose one and perhaps land yourself with a Knowledge Management project.

Related posts on the Business Analyst career path:

http://www.bridging-the-gap.com/can-i-be-promoted-as-a-business-analyst/

http://www.bridging-the-gap.com/whats-next-what-do-i-do-after-im-done-being-a-business-analyst/

http://www.businessanalyst.com/advance-from-business-analyst-to-business-architect/

.NET developer job

I know this is a long shot but I thought I would post this job that my company has on the off chance that we may find someone, the j0b boards are not providing good candidates at the moment. Leave me a comment if you are interested:

.NET DEVELOPER – Consultancy, Chicago IL – Local Candidates Only

We are a growing, Chicago based consulting company and Microsoft Certified Gold Partner with Microsoft competencies awarded in Custom Development Solutions, Information Worker Solutions, and Data Management Solutions. Local candidates only please, and no corp-to-corp.

Requirements:
• A technical degree in computer science, engineering, or equivalent experience.
• Strong working knowledge of Internet technologies and databases.
• 3+ years of professional programming experience in C#.
• Understanding of the .NET framework, ASP.NET (2.0 and 3.5), ADO.NET, AJAX, and LINQ.
• Test Driven Development experience using Visual Studio, NUnit or equivalent.
• Experience with SQL Server and T-SQL programming.
• Ability to communicate (verbal and written) effectively with a variety of cross-functional groups.
• Time management skills & ability to multitask.

Experience with any of the following technologies is also beneficial:
• Microsoft Patterns and Practices
• Microsoft Enterprise Library
• Microsoft Team Foundation Server
• Microsoft SharePoint Server
• Microsoft Commerce Server
• Microsoft BizTalk Server
• Microsoft SQL Server Reporting

Benefits:
• 401(k) with 4% matching
• Medical and Dental HMO/PPO/HSA
• Flexible scheduling
• Casual environment

Greater compensation considered for exceptional talent.
Please send resume and salary history to the email address above

New job!

On Monday January 18th I will be starting a new job as a Business Analyst / Project Manager, at a small IT consultancy that creates custom web applications as well as offering hosting solutions.  They predominantly use Agile methodologies where possible, however the final approval comes from the client, so if the client wants Waterfall then so be it.  This is a very exciting move for me, and I cannot wait to get started on Monday.

I started this blog in 2008 to track my career change from a recruiter with 10 years experience to a Business Analyst (hence the blog name, see my first post).  My first role however was not ideal, and I knew that going in as it was an Implementation Consultant role for a SaaS product.  Although it involved business analysis type work, such as requirements gathering and extensive customer interaction, it was within a very confined environment.  Essentially the product existed, we were just tailoring where possible and getting the customer trained, live and bringing in revenue.  It was a good starting point but not what I wanted long-term.  I entered Business Analysis with the idea of working on new software product development and release, preferably web applications as that seemed so fluid and exciting.  This new role seems very much in line with what I saw in my minds-eye when I started this career change adventure.

This new job is a combination, they are bringing together the Business Analyst and Project Manager roles.  Previous experience has shown the owners that at present there is not enough work on either side for a full role and that there is also a lot of cross-over.  I will get involved in so many different areas, from requirements gathering, developing and managing a project plan, wireframes, information architecture, testing and so much more I’m sure.  I have a lot to learn.

I will be working my way through the following books recommended by one of the company owners as I get started, and will post a quick review of each as I go:

• Agile Estimating and Planning by Mike Cohn (1/2 through this now)
• User Stories Applied by Mike Cohn
• Agile & Iterative Development by Craig Larman
• Rapid Development by Steve McConnell

So a new chapter opens in my career change, and again I will be blogging my progress.

I would be very interested to hear from anyone who has worked in a joint BA /PM role such as this, and any other suggestions on readings would be most helpful.