Michelle is a Business Analyst who's worked as a technical consultant for over seven years. Her industry experience includes having worked on large enterprise applications across multiple industries and multiple domains. Interests include UX, design thinking principles, business process improvement for efficiency and the systems engineering discipline.

Michelle is a Business Analyst who’s worked as a technical consultant for over seven years. Her industry experience includes having worked on large enterprise applications across multiple industries and multiple domains. Interests include UX, design thinking principles, business process improvement for efficiency and the systems engineering discipline.

Following on from her popular first post (find here) Michelle rounds our her “Musings” with a few more killer points for you to consider, when thinking of applying Agile practices to your life as a Business Analyst…

How to conduct and facilitate useful retrospectives?

One of the best ways of keeping your team motivated and engaged in retrospectives is to mix it up a bit:

  • Environment – Hold it outside in a park or a coffee shop
  • Themes –
    • Use of Happy/Sad faces to show how people are feeling
    • Have the team draw how they’re feeling and then over the course of the project see how these change/don’t change – creating a mood scrapbook
    • Use analogies – Moving house example (What are we going to take with us? What are we going to leave behind? What do we need in the new house?)

Another motivation tool to boost morale within the team is to provide showcases to the development team, demonstrate what you’ve achieved.

Invite guest facilitators in to the retrospectives – this puts you (the regular facilitator) in amongst the rest of the team, see if you can gauge any differing responses to what you’ve previously observed. You’ll be surprised at how the team may open up more to you when you’re not facilitating the session.

The 6 thinking hats (looking at something from all different view points) model – Have the team put on the different coloured thinking hats and get their feedback on how the last iteration went. Example sourced from Orchard.

One of the main reasons retrospectives aren’t taken seriously is when action items for improvement are not assigned owners therefore never implemented. Some practitioners suggested making these transparent throughout the course of each iteration. So similar to your log of work and backlog list the action items and show progress. Then at each retrospective re-visit what was raised. Additionally, it is also important to limit the action items so that its achievable. If there are a mass amount that get raised, spend time with the team on how to best prioritise these.

Another example mentioned was have each member of the team write on a sticky notes at least 5 bad things that occurred during the course of the iteration and 5 good things. Have them stick them up on the wall and review them anonymously or even better look out for trends in responses.

Conduct regular Scrum of Scrums. This can benefit an individual development team by seeing what others have developed or by seeing what improvements they’ve implemented to help serve them and where they are at within their own iteration cycle. It is for this reason that when you have multiple development teams it is good to have the same iteration lengths in order to benefit from ‘Scrum of Scrums’. Example sourced from a team at SBS.

Observe and analyse time wasted. Have the team identify where most of their time was spent – were they busy clarifying requirements with busy stakeholders? Was the team waiting on specific decisions to be made? During the course of the iteration where were the bottlenecks? This is a very interesting data trend to review at the end of the project if documented well at every retrospective. Example sourced from a team in Suncorp.

Retrospectives should be no longer than about 1 hour including any showcases the team may want to share.


What is Agile? What makes a company Agile? What isn’t Agile?

One of the key questions to ask an organisation who assumes they are agile is – at what point do you stop delivering value? This is only really the tip of the iceberg though, agile is so much more than just about providing value, its about being adaptable to change, being flexible with differing expectations its about teamwork. When a member of the team gets assigned a user story card remember the C’s for success:

  • Card – The card itself is simply an index card used for planning and prioritisation
  • Conversation – Where the actual requirement is communicated, in most cases there isn’t a single conversation, its an ongoing conversation that unfolds over time
  • Confirmation – When the customer tests.  It allows us to confirm that we have implemented the requirement properly

Let’s talk about teamwork for a moment, the roles in an agile team, although specific, the team should see delivery of value or an outcome as a team effort. For example, when the testers get inundated with test cases to complete as a BA or a Developer, don’t just sit there waiting for that tester to be a bottle neck, get in there and help them out. A developer knows who to test, as does a BA. This is a primary example of where you need to be adaptable.

Governance – without it, the project is essentially going to fail. This is extremely important for ‘Flow’ to occur. There needs to be invested sponsor and/or business owner involvement for Agile projects to succeed.

What about feedback and adding value not just with the outcomes you produce but what about adding value to how you’re going about delivering those outcomes and value. Feedback and constant communication from your stakeholders and team members on the ‘what’ and the ‘how’ will lead you to your goal.

On the topic of teamwork another quality that Agile brings to the table is not segregating IT and the Business, rather, it brings the two together. The team is no longer classified as the IT Team and Business Team instead it becomes the Value Team.

Agile = ART (Accountable | Responsible | Transparent) You’re empowering individuals and working better as a team.

How to engage and facilitate better in workshops

This is the model in which you should approach your preparation and planning when facilitating your workshop:

  1. You (Do you need to research up on anything? How are your public speaking skills?)
  2. Environment (What kind of room will you need? Do you need a room? What style of room would you need? How long should the workshop be?)
  3. Processes (How is your workshop structured? Will you be following some kind of method or model? Have you designed it so that you’re engaging your participants with activities?)
  4. Responses (How will your participants react? Important to consider this)

Consider the below scale – your choice of language can have quite an impact on your audience:


Screen Shot 2013-12-09 at 9.50.28 am


By asking people questions, your drawing them in and involving them however on the other end of the scale you’re pushing people away by telling them what to do and not giving them a choice.

How do you better engage participants? Have the group split into small teams and work on activities then gradually build up to working in larger groups then have them work on something individually to mix things up a bit. In essence by slowly increasing the range at which an individual needs to participate it makes them more comfortable to want to take part.

Rules and housekeeping – The facilitator suggested working with the participants to come up with their own set of rules together right up front.

The Validation technique – If there are two parties who are maybe disagreeing in a workshop, as the facilitator you need to give both participants a chance to speak and prove their case. There can be times where they think you shouldn’t be involved … DO NOT LET THEM TAKE CONTROL OF YOUR WORKSHOP. This would be the best time to use the Validation method. Repeat what each person is saying to them but in a way that says you are trying to understand them and you want to confirm that your understanding is correct. This is also a good tool when you have someone in the workshop who likes to go on and on and on about a topic and you just don’t have the time. Turn around and validate what they’re trying to say in a summary point … ’So is what you’re trying to say that ….’.


Behavioural Product Planning

Behaviour Driven Development: Feature > Scenario

SCRUM: Theme > Epic > Story > Task

Behavioural Product Planning: Epic > Feature > Story > Scenario

***Note. Features must yield ROI in a release


When attempting to use BPP the following exercise can be used alongside the Business Teams/Product Owner/Architects:

  1. List out a set of features on separate sticky notes | Do this along with the business
  2. Placed a set of cards with the following numbers on them in a horizontal line – notice the pattern

Screen Shot 2013-12-09 at 9.50.41 am

3.  Have your architects place the features under each one of the numbers above, where the numbers signify effort values

4.  Now have your product owner take charge with everyone around and re-order/change where the features go based on value add. Note a product owner will want to push everything to the highest of value but by having the tech team in the room it can start discussions such as ‘Well if that means a lot more to you than say this feature here well something’s going to have to give and that could be time … or another feature …’ What are the trade offs if any? This is the time to work through this together


So in summary, would I recommend attending the next Agile Tour? Definitely. Will I be attending the next Agile Tour? Definitely. The sense of community you witness and experience on the day just draws you in and makes you want to be a part of this Agile phenomenon. Although small in nature, the conference still swarmed with energy and dare I say it’s popularity is sure to grow at exponential rates which may in turn sway my opinion for future tours but for now I thought the day couldn’t have gone better. The only real disappointment I can share is probably the fact that I couldn’t attend all of the sessions I wanted to as some were on at the same time but given the ‘networking’ nature of the whole day there’s numerous avenues and opportunities to meet outside the conference anyways either via user groups or meet ups for example.
Suffice to say, I’m officially hooked on this notion of not having to know everything up front (we’re only human after all), trialling as a means of discovering and the camaraderie that Agile brings about in people. If there’s one thing I will say to anyone who’s interested in introducing Agile into their organisation is firstly knowing the answers to these question upfront:
– Why Agile and not any other philosophy?
– What is your current situation?
– What is your objective (future situation)?
– What benefits are you going to get by following an Agile framework?
– Can you benefit in using other paradigms?
Agile teaches us that there is no one method for solving a problem, it should be tailored to the situation at hand and by asking yourself the above questions your well equipped to making the right decision before proposing Agile, semi Agile or the reasons why Agile is not feasible to your organisation. An organisation must accept, embrace and commit to the behaviours that Agile presents before it can be adopted successfully.