In his previous blog, Dennis van der Salm, senior Pega architect at BPM Company wrote about pair programming. Want to go one step further in collaborative application development? Then mob-programming might be a good option. Especially when the topic you are going to work on is in a discovery phase, it can be a great option. In mob-programming, it is not two people who work on coding an application, but an entire team.
New technology, new team, new way of using it
During a project I worked on a few years ago, we did mob programming sessions, without calling it that at the time. We had to create a new application, with a largely new team. The technology was new and the way users were going to use the application was new. So, we bought a big television from the department budget, I connected my laptop to it and while we were brainstorming with the whole team, I struck up programming in Pega. Developers, superusers, business analysts, testers, product owners and people from operations together made sketches on whiteboards and had conversations. During development, feedback came directly from the whole team based on which we could immediately improve the requirements, design, code and quality.
Greater mutual understanding
So, we didn’t work all week of course, but mostly on Fridays when the office was quieter. At that time, it just seemed like the right thing to do. Get the best feedback as quickly as possible and make sure everyone gets the same knowledge. Only later did we discover that this way of working had some unexpected positive side effects. In our team, we had several people who never programmed: business analysts, subject matter experts and a product owner. But we also had superusers, very experienced people from the business who were placed in teams to bridge the gap between business and IT. As in many organisations where business and IT are separated, people don’t know much about each other’s work. Sometimes the business gets frustrated that IT takes a long time to implement a seemingly simple functionality. But by engaging in mob programming, the businesspeople on the team get more understanding of the programmers and the developers get more knowledge of the business. Through mutual understanding and more knowledge, you arrive at better solutions. They find out that sometimes something small takes a while because it is complicated to tell computers what to do. This really created more mutual understanding in the end, which greatly improved cooperation.
Is pair programming a panacea? No. Is mob-programming a panacea? No. They are both valuable tools that you can use to tackle challenges effectively. Try experimenting with the tools, try to master them and use them in the right context.
Want to know more?
In future blogs, I will explore this topic in more detail. I look at efficient versus effective working, role-based versus skill-based working, and different programming styles. Do you also feel that cross-departmental processes could be more efficient and better and want a quick initial insight into the possibilities? Feel free to contact us!