Whenever advocating change, it helps to understand the mindset of all the people who will be affected by it. At its essence, agile software development is about change. Because I have been a software developer all my life, I have always looked at agile and the change it effects from a ‘programmers’ mindset.
I recently was reminded that software is not just created by programmers - there are other people that add just as much value to the process that are looking at it from a totally different perspective.
Suggesting a particular approach without keeping in mind these perspectives is one dimensional. One such perspective to keep in mind is that of the Business Analyst.
I recently got an opportunity to email with my friend Angie Doyle who shared some of her insights on the perspectives a business analyst has regarding agile in general and moving a team to a physical board.
The email started from my side as follows:
Yesterday I had a long discussion with our team about considering moving from a digital board to a mixed physical / digital board. I feel that doing so will change the face to face communication during stand-ups, make capacity of the team clearer and may make flow more visible. I could see during the discussion that one person in the team seemed concerned - it was the BA.
On probing what was concerning her she was worried that in moving to cards we would loose the ability to track outcomes and agreements that the team made with itself or with other teams to user stories. The digital board was serving as a repository to this up to now.
Below are some of Angie’s insights on this question…
Traceability
Traceability is a big concern for BA’s. They are worried that they won’t remember where a requirement came from and who they should chat to when the requirement changes.
Loss of information
Losing valuable information is also a concern for them. When you only work on physical boards, BA’s seem to assume that the team will no longer be using acceptance criteria, screen mock-ups’ etc. because there is nowhere to keep all the paperwork. I have worked with teams where we only worked on physical boards – I would write the acceptance criteria on the back of the cards and staple screen mock-up’s/ models that we had drawn together to the back of the card. I am not going to lie… it made the cards really heavy and they fell off a lot. That being said, the team loved it that way because everything was instantly available.
Making collaboration harder and better
The only challenge was when the team took the card off the board – it made collaboration between developers a little bit harder and a little bit better, because then they had to sit next to each other. I also kept track of all the acceptance criteria in an excel spreadsheet and attached pics of the mock-ups/models, just in case anything went missing.
Passing audits
If I was asked for “documentation” on what was being released, I would send out the detailed excel spreadsheet. I also hung onto every single card (I didn’t worry too much about tasks) and kept them all in a box. I passed all my project audits this way.
Producing just enough
She might be concerned that she won’t have anything to show if someone asks what the acceptance criteria for a particular story was. She might also be concerned that she is losing her place to store documentation. Which also says to me that she is possibly producing too much – you can’t stick 20 pages attached to a user story up on a board that easily…
Team documentation vs analyst documentation
She may be producing a lot of “working documents”. These are models (process models, concept diagrams, etc.) that a BA might complete in order to understand the problem, or help her break down the epics into smaller stories. These are not usually shared with the team as they are “working papers”. Many BA’s would not want to lose those models – just in case they need to go back to it later (not sure how mature the team is – in less mature teams, BA’s want to keep it for CYA scenarios). If she can’t put it in the tool, there won’t be any traceability back to her working papers – which is the “proof” that she analysed something well.
Worried about being blamed
Yes – BA’s are very worried that lack of analysis will be the reason that an Agile project fail – and that they will take the blame.
Figure out where she can still store her “working documents” as well as the acceptance criteria (although if you are still using a digital tool along with the physical board you could just keep it in there).
Digital and physical board combo’s
I often work with mixed physical/digital boards. The product backlog is usually in a tool (I like excel, I like other tools a lot less). While the sprint backlog is shown on the physical board (with the detailed acceptance criteria, etc. stored in the tool).
The physical cards correspond to the same story in the digital tool – i.e. the physical card will have the same user story title, the user story and the story number from the tool. When the team starts working on the card, they will refer to the tool for the detailed acceptance criteria, etc.
I usually also show (on a separate physical board) the stories I have in mind for the next 2 sprints or so. This ties in with the roadmap and release plan (which are also hopefully on a physical board somewhere). If anyone needs the detail associated with the card (e.g. screen mock-up, business rules, etc.), they can refer to the tool.
