Getting started is a real experience and a paradigm shift. Make sure you are motivated, think big and start small. Select from your list of projects, one of those that cause you problems and for which you want to find a solution. Organize your team by finding volunteers who share the same issues as you, or engage the team you usually work with to experiment a new framework. Get started without asking any questions. It’s a way to get moving to:
- Solve your problems
- Move from a process way of thinking to a result way of thinking (finished product at each iteration)
- Give meaning back to your actions daily
- Be an actor in your days
In an Agile team, there is no hierarchy and the roles are preferably rotating in order to avoid creating bottlenecks. Set up a reassuring framework, without challenges to start and avoid any pressure on the team.
Secondly, you will take pleasure in Agility and opt for this organizational system to motivate your teams, innovate on your products, bring your networks and applications out of obsolescence…
In a few years, the agile movement and technologies have turned the way of organizing teamwork in the field of software development and even beyond. However, even if we see more and more Scrum Masters, Product Owners in the advertisements of recruiters, once inside the team, we see differences in interpretation in the implementation , compared to the roles defined in the Scrum Guide. As an Agile Coach, I offer you a reading grid of an organization based on the Scrum frame of reference, a train of thought to detect potential dysfunctions and help your team progress.
Agile Organization vs Roles and Tools
Some questions are useful for evaluating how well a team is functioning. Be careful, the answers you can get to these questions are only partial, instantaneous indicators. What I can sometimes interpret as a problem a priori for a team, may not be one. This may even be a response to another deeper problem, or to cultural habits that are not necessarily conscious or unsuited to the context.
So here are some questions I ask myself to understand the organization of a team
- What is the mission of the team? What are its short and medium term objectives?
- How often does it deliver products or services to its users?
- What are the latest results obtained, the the team’s latest successes?
- What is its place in the organization and its dependencies to decide or to do?
Then, inside it, we identify the postures and behaviors, then we check if they are indeed those expected in the definition of each role
- Who are the voices of users and organizational interests on the team?
- How are the priorities defined?
- How do team members work on a daily basis? Are they very self-sufficient and independent or do they constantly work with each other?
- What rules and standards apply? Are they enforced? Challenged ? If yes, how ?
Regardless of any reference to an agile method or framework, these questions already reveal a lot about an organization, its strengths and weaknesses and its adaptation to the context, its agility in short.
After that ? Before proposing any change, it is a question of respecting the existing one, as well as the past which led “naturally” to the present situation. This collective acceptance makes it easier to commit to change. The first lever is not “what to change to”, let alone what tool to put in place. Change starts with people’s interest. By accepting the idea of change. Which will then translate into movement.
Any change in an organization is part of a continuity.
Also, the definition of roles will be a beneficial first step, by clearly setting out how each member of the team is doing to move the organization towards its mission.
Product Owner, a pivotal role in the organization
When it comes to developing products, the first concern is to align those who use the product and those who manufacture it. Scrum defines the Product Owner role as a single person’s responsibility to represent users to the team, and to empower the team with what is potentially of the most value to end users. One person is few, some will say, and it represents a lot in the culture of an organization. From experience, this is just enough to make effective decisions on behalf of users and their multiple representatives, when the team needs them. As a Coach or Scrum Master, one of the first actions is to legitimize the role of the Product Owner in the organization and to ensure that the person occupying this role is sufficiently comfortable in the suit, by offering him my support.
This requires a clarification of the role of Product Owner and changes in practices vis-à-vis the stakeholders who must perceive and then appreciate the benefits before we can allow ourselves to think that a change has indeed taken place. Let’s dig a little deeper into the practices…
Break down the value
Beyond sharing what to do with users and developers, alignment is also about value. What has value for users according to the Product Owner, should also have value for developers (and vice versa). Except that as long as the users or customers cannot concretely appreciate the result, it is only a question of hypotheses. And the Product Owner can sometimes be wrong about the interest of a feature, just as users can be wrong about the idea of the entire product. Developers can also be mistaken about a technical solution, underestimating the difficulties in its development or its operation, for example.
Also, rather than betting big by committing a large amount of work and realizing the discrepancies too late, it is advisable to proceed in small steps, in an iterative and incremental way. This provides the ability to adapt and align frequently. As a Scrum Master, I make this “doubt” visible, I formulate the possibility of being wrong, whether you are a Product Owner, Developer or Coach. This motivates to move forward little by little, not only to build, but also to learn and eventually change. Even if we would have liked to know everything before starting…
Move at the right pace. At a sustainable pace.
With Scrum, the coordination of the activities of the various stakeholders takes place at a constant pace. The duration of the sprint is initially fixed between 2 and 4 weeks. This development cycle must be fast enough (but not too fast) to limit waste (waiting time, lack of feedback, unnecessary specifications, etc.). The same goes for meetings: short, but not too long. The role of Scrum Master is to present the rules of time management to the team, to the stakeholders, and then to enforce them. It is in this sense that we qualify the Scrum Master as an orchestra conductor, even if he is not the leader of anyone. It sets the tempo and harmonizes all the scores in accordance with common values. This results in the sequence of sprints during which the stakeholders, the PO and the team carry out the activities of defining and sharing the hypotheses before starting, building, integrating the elements of the product and delivering a result (preferably in the same sprint), then verification of the expected impact in the lives of users. This is to adapt the content of the following sprints. This short timing requires reducing the size of the elements to be produced so that they are suitable for users and developers.
The Scrum Master clarifies the roles: his own, that of the Product Owner, that of the development team, those of each of its members, up to the roles of the stakeholders. Its overall objective is to facilitate interactions between everyone, to maximize value creation by the Scrum team. We can qualify the Scrum Master as a Sheep Dog, in the idea that he protects the team from disturbances and reduces the risk of not achieving its objectives.
The anchoring of roles and attributions
Organizations and individuals are quickly appropriating the roles of Product Owner and Scrum Master. But quickly unfortunately does not mean “easily” and even less “suitably”. What is often observed in teams is the need to define and definitively assign roles to each of these members. This often happens early on, for teams in formation, or as soon as the team has difficulty working together. If it helps achieve goals, OK, but if it compartmentalizes, limits, and slows down working together, watch out! This theme of working together and self-organization is at the heart of agility. It has become essential for many organizations and deserves at least a new dedicated article…
Roles in the flow
One way of thinking is that for a certain task to be done well, at a lower cost and in the shortest possible time, it must be assigned to the person who specializes in this type of task. We can call this practice the “push” mode. For this to work, it requires several things. There is at least one specialist person with the means, skills and sufficient availability to carry out the task. The person in charge of distributing the tasks has all this information in order to solicit the best placed person according to him. Last but not least, this person knows enough about how to best perform the task to attribute it to the best know-how. This role very often corresponds to an imaginary local optimization ideal with undesirable effects on the overall dynamics and the motivation of individuals.
Another mode of operation is that each team member takes the tasks that are offered in a queue. What is quite common for Support activity streams, to quickly respond to user calls/requests, is less common in development teams. Maybe that would leave out tasks that were too difficult or too uninteresting or lower the quality directly related to everyone’s skills. This “individualized pull” mode does not facilitate collective stepping back either. The workflow that we want to be continuous can become variable, tense and blockages frequent.
Finally, another mode of operation, recommended by Scrum, defines that it is the whole team that decides on all the priority elements to be carried out and achievable during a short period of time, i.e. the next sprint. . This causes a level flow of value creation, which reflects the interest of making the system evolve gradually between two stable states to better control changes as a team. The sprint development cycle is thus intended to be sustainable for the team and train the entire organization. The main measure of advancement is to have a product or software that works, with increasing value for users.
A possible evolution of this last mode is to align the deliveries of small elements of value at the request of the customer and potentially several times per sprint. OK, as long as you control the flow and the rhythm is sustainable.
Beyond the initial explanation, the challenge of the evolution towards such or such mode is that all the roles in the organization derive a certain individual benefit from it and that the practices make sense for the achievement of common objectives.