The BA & Beyond conference is a two day programme enabling business analysts to share their experiences and find inspiration in their daily work. The conference was an intense mix of talks and workshops, providing space for inspiring people to share their stories. After each talk, the attendees had the possibility to engage in conversation during a Q&A. The sessions were very interactive and really empowering. This second edition of the BA & Beyond conference was held during two days in Brussels and Amsterdam. Various topics were discussed, such as visual facilitation techniques, «How to Make an Agile Project Succeed», business analyst behaviours, or «The Inner Architecture of a Performer». What follows below is an overview of some of these talks.
Table of Contents
- When BAs go BAD - Christina Lovelock
- The 7 hidden layers behind agile techniques: Ever wondered why we use post-its during retrospectives? – Pieter Van Driessche
- You are doing it wrong: The truth about user stories – Pieter Hans
When BAs go BAD - Christina Lovelock
Christina Lovelock has built BA teams in several public sector organisations including the NHS, ranging in size from 5 to 120 Business Analysts. She currently leads the BA practice at the University of Leeds. She is active in the BA professional community in the UK, attending and regularly speaking at local and national events and conferences.
Christina’s talk was purely soft skills related and depicts the sort of behaviours shown by business analysts when they face difficult situations. Some typical BA behavioural mistakes are triggered by the way they see themselves in the team. For instance, a BA could feel as if he or she is not part of the team: there are de facto less analysts than developers in a team which can lead to an «Us VS Them» mentality. It is also sometimes difficult to build a BA community, and being sandwiched between IT and the business can sometimes lead to negative self perceptions such as «I am just a BA» or «Neither the PO nor the developers understand me».
Understanding that the BA is as much a member of the team as the others and that he or she is not the only one accountable for the communication between IT and Business, leads to better collaboration and is a great step towards agility, allowing all team members to be more confident and positive. Whatever your role in a project team; collaboration, transparency and confidence - in yourself and in your team mates - as well as clear communication are key factors to succeed together.
Another difficulty in the BA role is providing the right level of detail in your analysis. Indeed it is sometimes difficult to have the right level of focus on the right things. Moreover, being a good BA is also about sharing knowledge, tools and techniques. Talking with other analysts and contributing to the practice are important aspects of the job.
Of course all those behaviours and feelings don’t just apply to business analysts but also to every team role: scrum master, developer, product owner, tester. This talk gave us the opportunity to identify and name some feelings we can face as business analysts while giving us the keys to find solutions to the difficult situations we could face.
The 7 hidden layers behind agile techniques: Ever wondered why we use post-its during retrospectives? – Pieter Van Driessche
Pieter Van Driessche has worked in IT for over 20 years and did most of the common software jobs: developer, analyst, team lead and project manager. He experimented with cultural change management for 2 years, after which he returned to IT because of the faster speed of change. He has been an agile coach for almost 15 years and coaches all kinds of teams in all kinds of organisations: software, operation or marketing teams, in Belgium and abroad, in small and large organisations.
This talk was a great eye-opener about a simple thing we all do every day in our scrum teams: sticking post-its! Although this has become a very common habit, we might not know why post-its are used during scrum meetings and especially during retrospectives. Below are some insights.
Thanks to post-its, all participants get the same space. Post-its give everybody a voice, everybody can express themselves without fear. Moreover, post-its give a real chance to introvert people.
Team objectives and peer pressures
By giving post-its to everybody attending the retrospective, peer pressure encourages everybody to participate and everybody will stick at least one post-it. And the more post-its we have, the greater the outcome we build. This fact is closely linked to our comfort zone. Although it is sometimes difficult to say what we really think, the post-its and the peer pressure force us to get out of our comfort zone by expressing ourselves, finding solutions and being confronted with our team mates. Getting out of our comfort zone promotes continuous improvement, and that’s what we all want.
The physical connection
Moving post-its on a white board allows us to make abstract things tangible. As a consequence, we are more involved in our daily work as we, and the others, can see our progress in a physical way.
You are doing it wrong: The truth about user stories – Pieter Hens
Pieter Hens has been working for over 15 years in a software product development and analysis setting. He has taken up roles as a business and functional analyst, project manager, coach and team lead in projects of various sizes. He currently specialises in the full range of software product management: product strategy, discovery and development.
User stories are part of the root of our projects, we use them on a daily basis to achieve our goals, however the user stories are sometimes wrongly used, leading to counterproductive effects. Here are some myths about user stories.
The analyst writes the user stories and the dev team implements them
Writing a user story is not the BA responsibility, elaborating a user story is a team effort and everybody in the team is eligible to write user stories. Writing the user stories together reduces risk of misunderstanding. Before implementing a user story, all team members should agree on and understand the user story content.
We don’t need documents or models anymore
User stories have to be backed up by documents and models. A user story alone is not enough, we need a context and the big picture. User stories are not meant to replace documents, they are meant to tell stories.
If it does not fit the ‘As a [role] I can [do something]’ - template, it is not a user story
Having a template for the user story is a good way to ease the understanding of the common goal. Having our requirements standardised simplifies the processes. However, not all user stories fit the same strict template. Even though a template is important, we should focus less on the template and more on the content itself.
I learned a lot during these two days and the conference gave me new insights and tools to deal with my work every day. This great experience also gave me the opportunity to talk and share knowledge and information with other business analysts. It was really inspiring.
The slides for these presentations can be found on the website of BA&Beyond.