How can agility begin for a team in a large organization? Here is a field report.
The first approaches for agile working in large organizations are often based on concrete methods. You may have heard a lot of good things about agile practices and therefore try to become agile by using one of the most commonly used methods like Scrum or Kanban. So, at this point, it is mostly about the benefits of an agile workflow and rather not yet about questions of attitude or culture.
I accompanied this step in a major German bank in a test team for a while. My assignment was to “make a test team agile”. Because both the test team and the higher-level project team were inexperienced with agile methods but should work agile. Furthermore, the organization was dominated by strongly classical process flows – as well as they were established in the banking world for good reasons.
The major project was positively disposed towards agile procedures and wanted to create new product innovations in short cycles. A reasonable basis for an agile test team.
The team had a size of about 10 persons and was organized independently in the project. So, there was a business team, several development teams and a test team in the overall project. An experienced Agilist might assume that the whole project team was still at an early stage of agile maturity and needed to be picked up.
Fortunately, the team was technically experienced and competent. This was a reasonable basis for not having to deal with technical issues as well. And so, we started to deal with the basics of team organization.
Self-organisation in the team
The people in the team were used to hierarchical project structures and had mainly gained experience with authoritarian project managers in previous projects. So, it was challenging to experience the first steps of self-organization together:
- We had to find the framework within which the team could and should move freely and independently.
- At the same time, we had to present, coordinate and demand the demarcation from other teams.
Here, I was particularly challenged as a temporary project manager and coach and had to establish processes with other teams, which allowed a start into as independent teamwork as possible.
Systematic procedure in short cycles
From the first day, we proceeded in short cycles. This was not a change for the team because they were used to thinking in software release cycles. So, people found it intuitive and logical. We just kept shortening the work cycles step by step. Thus, iterative procedures without a noticeable change were established practice.
Prioritize work according to the benefit for the customer
Prioritising the work was not a new topic either. The team had expected the project manager to prioritize, and so the matter was clear to the group: there is a predetermined prioritization. For now, by whom!
So, it was my job to ensure the process of external prioritization by the internal customer. So, for the time being, I took over this role to the customer.
Setting aims and making them visible
We put big effort in setting achievable goals for the team in the iterations and making them visible internally and externally. This greatly facilitated communication with other groups. There were clear expectations in all directions. We were also very transparent – we visibly communicated what was and was not possible. Nothing was “hidden”.
Focus on the next stage
With the cyclical approach and the clarity of the goal, it was at the same time self-evident that we would be most concerned with the content of the next iteration.
Continuous Improvement
Continuous improvement through constant reflection on one’s working methods was more difficult. Procedures once discussed were considered “fixed”, changes to them were considered a waste of time, not only by team members – but also by people outside the team.
The implementation of this was almost impossible in the given time. Here the readiness was not present, because the attitude (“the mindset”) for it was not there yet. I could not communicate the benefits of this to the team members in a sufficiently comprehensible way. Unfortunately, we had to postpone the topic at that time and thus only took up apparent improvements.
Customer in focus
As already described at the beginning, we were still organized as a separate specialist team in the team structure at the beginning. This meant that although we had a lot of customer contact with the test order, it was subordinate to the business analysis and development in terms of processes. We were not a multi-functional agile team, as one would have wished. The organization had not yet reached that point.
Although we were able to establish early involvement and thus productive work with the business customer, it was a slow development process overall.
If you want to name these first steps of an agile way of working with a method, then it was most likely a “Kanban” approach that we had followed. Because we had put a lot of emphasis on the following principles, among others, and used some practices of it:
Source: www.LEANability.com
After the first weeks of being amazed by the procedures, many in the team had got used to the new systems and ways of thinking. There was no longer so much discussion about whether this was right or wrong. Instead, one could observe that there was talk about how to use this way of working and what could be improved.
This created an agile team – admittedly, in early development maturity. But the start was made, and the team and my planned successor could use it even without me.
Some time ago, I received the following message from a team member at that time: “… yes, I like to remember the times back and your advance with the Daily … even though it was annoying at first, it was constructive. I was able to establish this with my new employer and a new project, following your example 😉 …“
Are you also on the verge of the “agile age”? We at Coverdale will be happy to support you. Just contact me at bf@coverdale.at.
Recent Comments