Processes and Tools in Support of Individuals and Interactions
"Individuals and interactions over processes and tools" (http://agilemanifesto.org) - the first value in the Agile Manifesto is a reckoning of the issues stemming from the current state of affairs and a call to action to re-focus on what turns out to be the most important fact - that especially in software development (but maybe not only...) each person operates differently, but more so that a person will operate very differently in different teams and environments.
Just to clarify - this isn't a new idea and concept. But with agility we bring it to the fore and make it explicit. And this then allows us to shape our environment, culture, structures and processes accordingly.
The drive for the realization of this value turns into concrete guidance and best practices like working in small teams, having informal and sometimes impromptu working sessions/meetings and adopting lightweight tools like story maps, experimentation canvases, Kanban boards, etc. Add to these the focus on techniques meant to increase the effectiveness of the team e.g. retrospectives, continuous improvement canvases, conflict resolution techniques, personal face-to-face collaboration.
Now, as much as the individual is critical to the realization of this value, the main unit under watch here is still the team.
The essence of the agilist is that of the selfless individual dedicated to the success of the team beyond the personal image, heroics and individual achievements. And rather in terms of team player, mentor, coach or partner to all others on the team.
At this point, the processes and tools come into focus as instruments suitable or rather suited for purpose in the support of the team and each individual part of it.
Part of the continuous improvement cycle, the team is constantly looking for better ways to deliver value. A team that starts with a physical Kanban board on the wall and finds that they need additional support that's available in a tool like JIRA or LeanKit, should experiment with such tools and find the ones that will help them achieve higher states of agility. Caution is required not to qualify any changes in direction as failures. These are all natural experiments part of the continuous improvement cycle, that could result in rolling back a process or tool that turned out to simply be non-value to the team.
There could be several reasons why some teams will require more sophisticated tools, physical or on-line, depending on the structure, environment, organization, geographical distribution, product at hand, etc., etc.
There is a balancing act between not categorizing teams using on-line tools are "more advanced" but also forbidding teams to investigate processes and tools that could enhance their efficiency.
Larger organizations should resist the urge to "standardize" on a specific set of tools, and force these on all their development teams. Inherently assuming that (a) all teams need to become proficient at using the tools and (b) qualifying the teams that would struggle with them as "problem" teams or "challenged" teams.
My ask of you is to seriously consider these thoughts. Do I really care more about people than about specific processes and tools? How can I provide them with the right amount of tooling and instrumentation that suits their organization? How do I help the Leadership of the organization buy into the new perspective and move away from the traditional, process-oriented mentality?
Please do leave a comment and share your thoughts here below.
Thank you!
Hence the agile approaches and methodologies are much more detailed in describing objectives and principles than providing specific and direct predefined processes and tools to be re-used over and over again with little to no adaptation to the current conditions.
Because of this shift there is a lot of FUD (fear, uncertainty and doubt) in the industry, and newcomers to Agile are concerned with the "lack of direction" and the "lack of structure" in the new world.
Because of this shift there is a lot of FUD (fear, uncertainty and doubt) in the industry, and newcomers to Agile are concerned with the "lack of direction" and the "lack of structure" in the new world.
Just to clarify - this isn't a new idea and concept. But with agility we bring it to the fore and make it explicit. And this then allows us to shape our environment, culture, structures and processes accordingly.
It's our job to constantly reaffirm and reassure everyone that we are very focused on processes and tools. But we regard these as instrumentation for the agilists and agile teams, to support them and provide them with the ways to experiment, learn, deliver and continuously improve according to the agile mindset and principles.
Wherever the initially adopted framework - for example XP, Scrum, Kanban, etc. - starts to impede any of the aspects mentioned above here, the team and its leaders have the duty to closely inspect the situation and adapt to the newly discovered conditions and challenges.
Wherever the initially adopted framework - for example XP, Scrum, Kanban, etc. - starts to impede any of the aspects mentioned above here, the team and its leaders have the duty to closely inspect the situation and adapt to the newly discovered conditions and challenges.
Now, as much as the individual is critical to the realization of this value, the main unit under watch here is still the team.
The essence of the agilist is that of the selfless individual dedicated to the success of the team beyond the personal image, heroics and individual achievements. And rather in terms of team player, mentor, coach or partner to all others on the team.
At this point, the processes and tools come into focus as instruments suitable or rather suited for purpose in the support of the team and each individual part of it.
Part of the continuous improvement cycle, the team is constantly looking for better ways to deliver value. A team that starts with a physical Kanban board on the wall and finds that they need additional support that's available in a tool like JIRA or LeanKit, should experiment with such tools and find the ones that will help them achieve higher states of agility. Caution is required not to qualify any changes in direction as failures. These are all natural experiments part of the continuous improvement cycle, that could result in rolling back a process or tool that turned out to simply be non-value to the team.
There could be several reasons why some teams will require more sophisticated tools, physical or on-line, depending on the structure, environment, organization, geographical distribution, product at hand, etc., etc.
There is a balancing act between not categorizing teams using on-line tools are "more advanced" but also forbidding teams to investigate processes and tools that could enhance their efficiency.
Larger organizations should resist the urge to "standardize" on a specific set of tools, and force these on all their development teams. Inherently assuming that (a) all teams need to become proficient at using the tools and (b) qualifying the teams that would struggle with them as "problem" teams or "challenged" teams.
My ask of you is to seriously consider these thoughts. Do I really care more about people than about specific processes and tools? How can I provide them with the right amount of tooling and instrumentation that suits their organization? How do I help the Leadership of the organization buy into the new perspective and move away from the traditional, process-oriented mentality?
Please do leave a comment and share your thoughts here below.
Thank you!
I do agree that merely imposing tools on all the teams across the organization is not going to help improve efficiency. While it is important to recommend, it should be left for the team to move over gradually, having them to understand the benefits of such an adoption. It is not true either that all the teams using fancy tools are great agile teams. It is ultimately the individuals and interactions and their drive to accomplish team goals that yields the results. This is what we have seen working wonders with no disregard to tools and processes. Therefore a balanced approach is recommended based on the team’s culture and agile maturity level for using right tools and processes.
ReplyDeleteThank you, Kalyani! Really like this idea of balanced approach - to consider both the strategic concerns, through the recommended/supported tools at the enterprise level, but also the team's culture, maturity and context in general.
Delete