Agile work cul­ture

Before founding Integral Vision a decade and a half ago, I was a UX designer in Synergon's Business Solutions division, participating in a multi-year software development process. I have treasured that experience ever since; so much that it has a definitive impact on the thirteen years of Integral Vision. It was a unique situation: at first, I was involved in the visual update of the user interface of an earlier application, which had been developed in a waterfall model. In the end, the application itself failed badly.  Regardless of all the effort and the all-nighters before the deadline, and despite the fact that no expense had been spared in bringing in reputable developers, with that team, we were not able to deliver  a working product. After some faltering, the head of the division decided to shut down the whole project, and asked Zoltan Csutorás, a.k.a. Csuti to put together a new team to rebuild the product.

I was lucky: Csuti included me in the new team. Instead of working with already existing client interfaces, this time I had the opportunity to design new ones from scratch. After a dynamic development process, our product was successfully implemented at the Hungarian Defence Forces.

Agility then and now

The project was organized in an agile approach, following Scrum methodology.

Csuti sought to maximize adaptability throughout the whole project. He also asked the management to ensure that the team had someone from the client side who was familiar with all the details of the document management in the Defence Forces.

The core of the development team was a group of experienced developers who have been working together for many years. My role was limited to the first few months of the project; once the main functional designs were completed and the core design patterns were established, my involvement came to an end.

We talked a lot about why we were working the way we did and what we expected from the agile approach. Many of us were familiar with little literature that was available in English at the time. We were so committed to the subject that Csuti and István even translated one of the foundational works into Hungarian. I still send this book as a first read to our newcomers at Integral Vision.

Below is the summary of the main principles whose power I have experienced whilst developing the  document management software. 

1. Getting to grips with the domain

It is crucial that the topic at hand is well-represented in the team. It's best to have someone with a deep understanding of the area, who has a direct relationship with the developers. The connection between the product owner and the developer team is key. There is no such thing as a "customer requirement" that developers "have to implement". Instead, there are business goals; and solutions are sought to meet them. The emphasis is never on "what to develop?", but on "why should we care about this issue". Why is this development important for the product? Why did the topic arise, and how does it contribute to reaching the end goal?

If the product is about document management, I need to be able to put myself in the role of a signer, a case manager, or even a receptionist. I need to understand why the system works the way it does.

The product owner does not communicate inquiries. Instead, they focus on the needs, make the business goals understandable, and teach the developers how the stakeholders operate in their own organization. In our case, this knowledge was provided by the presence of Endre, who has worked in the Defence Forces for several decades and knew all the ins and outs of organizational records management. A retired Lieutenant Colonel, he was not only was he familiar with the subject in general, but he also knew the workings of the Defence Forces.

The lead developers were István and Laci. The former's open-minded attitude and curiosity attracted everyone, while the latter's directness and friendliness strengthened trust with the team. István focused on the business side of the product and Laci on the technological details of the development.

We started to outline hypotheses about the concepts, which Endre and I constantly tested and refined. The common conceptual space allowed us to focus on verbal understanding rather than unnecessary documentation. No one was given an assignment; instead, there were use cases, and the developers concentrated on a single collection of topics at a time (epics).  The technological details were fleshed out during the sprint. Pair programming was commonplace, domain-driven software design and test-driven development approach prevailed in the team. The topic was “alive” for everyone, with many vivid conversations while clarifying a process. We were standing in front of the whiteboard, and I was drawing up my umpteenth interface design while discussing conceptual details with two other people. István, as lead developer, played an integrative role, focusing on preparing the ground for the developers. He was trying to scale down the development complexity, and I was trying to simplify the user experience as much as possible. Sometimes, István also took the initiative and went with an untested idea if something wasn't quite clear. In such cases, there is always a risk of refactoring, but it was more important to move forward. We never had to wait for anyone to finish what they were doing. There were always enough live topics hanging in the air to keep everyone busy all the time. 

We renamed the concepts related to domains and user interfaces over and over again, and in doing so, our conceptual space became clearer. István was brilliant at asking relevant, in-depth questions to Endre, returning to the “why” again and again. In doing so, he achieved that the during the development of the software, we were not slavishly replicating the current modus operandi of the organization, but rather aimed for a desired organizational process. To be able to do so, we needed to see clearly what level of organizational transformation was realistic, and what would be too ambitious a goal. It was amazing to see how much a well designed software can bring into the life of an organization.

* In Integral Vision, new enquiries are jointly qualified. This allows everyone to express whether they are interested in the topic, and defines who gets involved in what. However, it is often a major difficulty challenge that although we have a good relationship with our customers, their product owner is not an integral part of the development team. In our model, our account managers try to bridge this gap by organizing regular meetings involving both the customer and the developers.

2. The process is more important than the end result

Better results can be achieved if we berak down the workload into sprints, and set smaller targets at a time.  Trying to have everything perfectly planned at the beginning of a project works against the learning process. And the best results are achieved when people with excellent skills from different fields are able to work together towards a common goal.

The development of the document management software involved an agile evangelist, a technology innovator, a lead developer committed to domain driven development, a senior developer with well-connected mentoring skills, a UX designer, and an enthusiastic junior trainee.

* At Integral Vision, we work on many products simultaneously; there are currently no permanent teams , but there is a common agreement on how these can take shape. There are pairs or trios that work well, and new colleagues can join any of them.

3. The power of connection

The most effective team is where the members represent a wide range of skills, and each contributes to the common good by maintaining their own focus. This requires a lot of discussion, shared thinking and an enabling, accepting and supportive atmosphere, as well as a critical approach. Tolerance for mistakes, the willingness to learn, and enthusiasm can best be created in an environment where the people are interested in each other, and where there is a connection and human compatibility beyond the scope of work.

Summary

Shortly after finishing my contribution to the development of the document management software I left Synergon and founded Integral Vision. What I experienced in that team remained with me ever since, and many of the principles and ideas about collaboration that I still represent in IV today, originated there. If someone had asked me at the time about the most important things I would take with me, I would have said: agility, Scrum and community. Looking back now, I would say that the most valuable experience what I learned to appreciate there and then are: focusing on small changes and experiencing the process in a positive way, rather than emphasizing the end goal. I am grateful to the people who made it possible for me:  István Marhefka, Zoltán Csutorás, Laki Illés, Endre Gyenis, Kristóf Józsa, Zoli Imre, Janó Gerevich, Dani Szél.