In the second part I dealt with practices which help us to get a grip of the reality which is often far away from an ideal situation as described in literatures. I have shown that access to a domain expert is often not enough to prepare a prioritised backlog, and that this takes some time. In our situation, this stage is called HLD and its goal is not just the backlog but a shared vision of the solution. From the factual point of view, we seek to contain related topics in separate modules using the DDD (domain-driven design) technique to enable isolation of any potential changes. In order to attain the planned objectives, we make use of feedback as much as possible in the form of a "walking skeleton", and the Definition of Done concept. Complexity is not necessarily being complex in terms of technology or domain, it may also be induced by the problem of size such as that of a team, which is the topic to be detailed today.
The importance of proactive communication to keep a shared goal
The bigger the project, the more important it is to communicate. Not only in the beginning, but throughout all of the project's duration. Not only within a team, but also among the teams. The ideal size of an agile development team is 7 +/- 2 people. Major enterprise projects will exceed this number without any problems. In such a case, agile work will not do without a number of teams working in parallel. We support parallel team work especially by emphasising the "ceremonies" in the field of planning, mutual communication and integration - that is where the agile scaling task steps in.
Scaling is attained by creating a governance model built on decomposition of delivery into subareas referred to as functional wholes. A functional whole is under the responsibility of a respective team led by a team leader who assumes the accountability as an owner of the area.
What has proven itself good at PosAm is a team core model, the cores consisting of team leaders who have defined HLD in liaison with the solution architects, and continue to be responsible for maintaining interdependencies at sub-area interfaces (API contracts, technological pre-conditions etc.).
The communication among team leaders must not be limited to the preparatory stage only, but needs to be supported in the course of implementation sprints or scheduled releases. Teams are required to share information concerning changes in order to be able to accommodate to these changes and understand their impacts.
An ideal place to make such arrangements is a release planning meeting before launching a new system release, which may be as short as a couple of hours but as long as a couple of days too (in the case we are preparing a sequential release from scratch or a major change with a scope of 2-3 team-months for a large existing system). There is no need to worry about planning being something bad. Without planning and a reasonable degree of formalism in fixing agreements, unnecessary losses may occur in terms of money and time. This does not mean that the plan will not change, on the contrary. The greatest significance is not in its binding nature but its ability to communicate goals and their interdependencies in time.
Agile organisational design as a tool to delegate responsibility
The agile approach also carries with itself a stronger feeling of ownership. It is not merely about the person of the team leader (scrum master), who also bears a formal responsibility for the functional whole, but it is also about setting up all the team’s motivation. What the agile techniques give us most is a higher level of transparency of information concerning the status of tasks. This leads to better communication among team members and faster action when someone needs help.
At PosAm we seek to strengthen team performance also by creating team cores who work together on projects in a long term. While this is difficult in the settings of a company providing custom development services, it provides better conditions for knowledge transfer and supports a mind-set along the lines of Pink's motivational theory of Autonomy, Mastery and Purpose, the perception of the mission in one's work.
Custom solution rather than DevOps for agile delivery
The projects implemented by PosAm are mostly accepted by a customer's operation in the end, and we provide a third level of support. Therefore, we regard the introduction of DevOps (linking developers and operation specialists) in the original sense of the word as pointless. In our projects we consider the Ops to be the administrators of middleware technology the software solution is to run on. Formerly, such a specialist would join a project for a definite period of time and then leave. Nowadays we strive to make these specialists multi-occupational and employ them on a continuous basis especially in the area of automating deployment and configuration management. In this way, we want to achieve the most automated form of the deployment, monitoring and logging process. This enhances the team’s solidarity and cohesion in addressing any technical incidents at the interface between the software and the infrastructure. An interesting effect is a higher level of project activity automation, streamlined commissioning, and better monitoring coverage.
I do not want to conclude this article by evaluating where we at PosAm stand at the moment in the adoption of agile development. We have introduced many elements, while our approach to this topic is pragmatic. We take what works, but without obliterating the old well-known truths, being true independently of any names given to a development management method for the time being.
What I was dealing with in the previous parts:
Riaditeľ vývoja softvéru firstname.lastname@example.org