|
I used to practice Scrum with a physical board. We often faced problems when working with distributed teams or just when going into a meeting room. So I decided to implement a SaaS service to provide an online board, but after speaking with Agile coaches it appears they don't like this virtual solution because it breaks the real interactions promoted by the Scrum framework. Why would they say that? I think it's better to have all of the team involved and informed. |
|||||||||
|
|
Which one is better? The one that works better for the team. That is the entire point of Scrum. Enable your teams to organize around practices and tools that work for them, and stay out of the way. It really doesn't matter what your Agile coaches like and don't like. Their opinion can be used as a basis in your team, but the bottom line is to use what works. Try one board for a few iterations and talk about it during your retrospectives. If it doesn't work, change it. Be agile. Adapt. My vote in this instance is always for an electronic board and a projector or large monitor in a public area. |
||||
|
|
|
The point of having scrums is to facilitate intra-team communications. From that point, having a physical board is beneficial because it forces people to be in the same room and communicate face-to-face. Remember that something like 75-80% of communication is composed on non-verbal cues, so if you are trying to do things virtually when you don't have to you are making the communications less effective than they have to be. If you have a distributed team that can't physically be in the same place then you have to find ways around the limitations inherent with that kind of setup. If this is the case for you may just have to acknowledge that you don't have a perfect situation but are dealing with it as best you can. The caveat is that when I say "they can't physically be in the same place" I mean that as a rule of thumb they would have to drive or fly or take a train whatever to get to where your board is rather than walk. Improving communications on a project is well worth a little inconvenience. |
|||||
|
|
I've worked on teams using both methods, sometimes at the same time. Others have mentioned the reasons for preferring the real world scrum board being about physical interaction and in-person communication. Personally, I prefer virtual scrum boards for several reasons. First, as you mentioned, distributed teams or even simply working from home days. In those cases the team members have no view of a physical scrum board and, more importantly can't update the scrum board themselves. They have to ask another team member to update the board for them and that just takes more engineering time away from that person. Plus, this almost always results in once a day updates from that person instead of having the continuous sprint status that the board is supposed to convey. Also, tracking and historical views of the project are much easier to deal with using a virtual scrum board. When using physical boards, at the end of a sprint, all the cards get taken down and either tossed in a pile that nobody ever looks at or they're thrown away. How are you then supposed to look back at anything deeper than your point velocity when all your story/task level tracking is gone? Reporting in general is just easier with a virtual scrum board. One of my teams now uses a physical board and I have to go in every day and copy the points remaining from the board into an excel spreadsheet so that I can generate a burn down chart. In a virtual board situation, the data is all there and, depending on the system you're using, can constantly generate burn down based on the board at any time of the day or night. So for all the talk of fostering in-person communication, I think the cons of a physical board outweigh the pros. You're still going to have your daily scrum standups for that in-person interaction. You're going to display the virtual board to the team during the standup. Heck, you can even set up a place where the virtual board is displayed 24x7 that team members can still gather around. |
|||||||||||||
|
Why Agile Practices Generally Favor Face-to-Face Solutions
According to one Wikipedia entry, 2/3 of all communication is non-verbal. In an agile context, this means that in-person interaction generally provides higher-bandwidth semantic communications between team members than a comparable exchange over telephone, email, or instant messaging. In addition, the Agile Manifesto values individuals and interactions over processes and tools. One reason for this is that tools should support the organic, emergent behavior of the team rather than forcing the team to build its processes around a specific tool-chain. In fact, in a related post I said:
None of the foregoing means that virtual story boards are bad, or that they shouldn't be used. However, one certainly needs to be cognizant of the trade-offs inherent in using a virtual story board, and take care that the tool is not used in place of interactions or processes. Why Virtual Solutions Are AdaptiveA physical board will generally increase interpersonal interactions, and create spontaneous communications opportunities around the story board as people update it or view it. If given the choice, I too would recommend a physical board over a virtual board in the abstract. Having said all that, I think you are right: in your specific case, a virtual story board is necessary tool to keep your distributed team informed and engaged. However, the reason it's valuable isn't that it's electronic or virtual; it's useful because it increases communications bandwidth, project visibility, and task synchronization within the team. It addresses a concrete logistical issue; as such, I'd certainly consider it adaptive. |
|||
|
|
I've used both, sometimes at the same time. It's pretty much a truism that it depends on your situation. If your team meets the following criteria, you should go for the physical board:
It's easy to scribble down "revamp landing pages", but without data like "date of creation", "created by", "card #", it becomes difficult to manage and extract useful reporting. A virtual board or ticket tracker can be really helpful if you can't meet those criteria, and has additional benefits that aren't really possible regardless of your discipline. It helps with reporting, allows for centralization of online conversations and it helps you keep necessary files and link to references. A best of both worlds approach is to have a large TV screen to display the board during scrum meetings, and someone operating the computer to sort the cards in real time. |
|||
|
|
|
I prefer a physical board for several reasons: It's (usually) easier to change your process. Want to add a code review step? Just add a column. That's easy in some virtual products but a pain in some. It creates a focal point for standups. unless you have a really big screen where you have your standup, a physical board makes a great point to gather, discuss what's in progress and any blockers and talk about risks. People actually update it! In every team I've been in that's used a virtual board, people update it very infrequently (typically in a rush before standups after the Scrum Master has had to go and ask them to do it) so it doesn't always have a good picture of what's going on. It communicates to other stakeholders more easily. My CIO is unlikely to open a virtual board but will have a look at our physical one when he walks past. Equally, if I see him looking at the board, I'll usually go over and we can have a chat about how things are going. Even if he did view a virtual board, we'd miss out on those informal chats. That all being said, my team is co-located. In a distributed environment, I'd be using a virtual board (as well as kicking and screaming to get my team co-located!). |
||||
|
|
|
If you cannot do it manually with cards, pens and a wall then no system will help you. Traditionally a lot of document hand-balling was done and people lost the art of communicating. Coaching the team to "really communicate" is hard work and should be the starting place. Once you are successful with a physical wall done, you may want to consider virtual walls to help improve productivity especially when used in an ALM solution. Thus, put in a virtual wall for the right reasons. |
|||
|
|
|
It is true that if you cannot cope with physical board, virtual one will not solve your problems either. Firstly it is a good start to do everything on physical one, also it keeps budget small. Later on when you will get bored of all the waste physical one creates, you can switch to the digital one. But keep in mind that it can cost you slightly more and of course it will need some sort of software to run with. I recommend reading some of the ideas from pratical use in my blog post about virtual boards here. |
|||
|
|
