Adoption of Agile Mindset in the Dynamic Organizations
Anirudh Zala
Agile Delivery Lead | Scrum Master (CSM?, CSPO?) | Technical Program/Delivery Manager
In this article, we are going to discuss my firsthand experience of best practices (challenges, solutions, concerns) while instilling an Agile culture/mindset in dynamic organizations.
The article mainly sheds light on:
1. What Are Dynamic Organizations?
These are ITES organizations with the capacity of 50 to 300 employees/consultants/associates having validated business models. They are sustainable and hungry for growth.
1.1 Dynamic Business Model
These ITES organizations serve in various product and tech segments, doing bespoke projects, offering dedicated resources for hire, and providing consulting as well.
1.2 Dynamic Tech Stack
Additionally, these organizations use various tools and technologies (such as Microsoft, Open-source, Mobile, etc.) to build various products and services
2. Agile and Scrum Training
The overall goal of the Agile adoption was to instill agility in members through encouragement and not enforcement. Hence training sessions along with assignments were planned.
There were approx. 300 members in the organization in various departments from which IT staff were 250 while the rest were in HR / Admin departments. In 1st month there was just observation of various teams along with various meetings to better understand their working style, workflow, culture, pains, and gains.
250 IT team members were further divided into Product teams, Project teams, and Service teams as shown in the below picture.
From them, roughly 200 members were considered for training. Rest were already working under other frameworks/methodologies where Scrum could not be made applicable.
The above 200 people were divided into 10 teams of 20 members each to further provide training and assignments.
3. Shared Product Team
In dynamic organizations, product teams are often shared between one or more products. Hence following points are to be kept in mind while planning training.
3.1 Mindset Shift
While working on multiple products, mindset plays an important role because team members often need to switch contexts. This becomes much more important when product domains differ.
Therefore, it is advisable that in shared product teams, at least the domain should not be changed. If tech-stack also remains almost the same, then it would be the best.
If different domains are a must, then necessary training needs to be arranged.
3.2 Allocation of Efforts
Another challenge that you could face is how to allocate efforts in shared products, especially for the tech team as they could face dynamism in any one product during execution. Hence allocation needs to be predetermined before planning sprints in both products.
PO and Dev team should also be flexible with such allocation to keep execution smoother.
3.3 Team Dynamics
Team dynamics are important while working in shared product teams. You may face various challenges and address them one by one.
Due to different product types, some members may face easy to work with while some may not, hence proper care must be taken to mitigate such concerns before they became a bottleneck in execution and eventually hamper productivity.
For the QA team etc. prioritization can be challenging because while working on shared products, often they find that they receive tasks very late from both teams and they may face severe challenges to complete them on time, even if sufficient time is allocated during planning. Since all the members of both product teams may exactly not be shared, certain members may not have visibility of both teams. In such a scenario, both teams must be coached about time management, prioritization, coordination issues, etc.
In a shared product team, onboarding could be lengthy in comparison to a single product because of the nature of complexity, diversity, and domains of the product.
Therefore, it is advisable that if anyhow teams are to be shared between two or more products, it is better to keep the whole team the same so that fewer issues could arise.
However, there is one advantage of such a setup, it is that Scrum teams of both products can exchange valuable information, skills, experience, etc.
3.4 Scrum Adaptation
Finally, it may also require a little bit of Scum adaptation, so that ceremonies can run smoother. Some of these adaptations are:
4. Shuffling Across Teams
In Agile organizations, there is a high chance of shuffling teams as and when required because of the short period of products, projects, and services. As an Agile company, we need to take care of a smoother transition of members especially when it comes to the execution process/methodology.
It is quite possible that even though the whole company is Agile, different teams might be using different methodologies and/or frameworks. Such as product teams using Scrum, project teams using Kanban, and Service teams using some hybrids one or no-process at all.
领英推荐
In such an environment, the following points need to be kept in mind.
4.1 Understanding Existing Methodology
It is important to talk to people and teams about what methodology they are using, and what are their pains and gains to understand what is being followed to collect valuable data and insights.
4.2 Methodology Training
Based on the above, a custom training plan can be crafted based on transition. For example, the transition from No process -> Kanban -> Scrum requires more time and effort of training as all of them have their pros and cons.
4.3 Mindset Shift
As discussed above, mindset shift plays an important role while jumping from one environment to another, especially from No process -> Kanban -> Scrum, hence sometimes just some theoretical sessions are not sufficient, instead, some mock-up sprints can be run to give a practical idea of Scrum. It is also important to convey the value of Timeboxing, ROI, Cost of delay, etc.
In new sprints, teams can choose less work to create adaptability between each other.
4.4 Team Dynamics
Same as discussed in 3.3
4.5 Cultural and Behavioral Changes
Due to the cross-culture of various methodologies, new team members may face various behavioral challenges such as being present in various Scrum ceremonies and following them passionately (this challenge can be faced by members coming from No-process or Kanban methodology) or not being able to work and deliver in timeboxing unlike in Kanban where there is no timeboxing instead, just process efficiency is expected.
Project and Service team members may not have worked closely with Sales, Marketing, Research, etc. hence while working with the product team, they may also face mindset and behavioral challenges as these teams may have different mindsets and cultures. So proper care should be taken while conducting training.
Moreover, it is also advisable not to shuffle members and the team frequently, otherwise, they may not provide their best, and they may start facing psychological safety issues.
5. Scrum and QMS Harmonization
Many organizations nowadays avail ISO9001-2015 certifications (aka QMS or Quality Management System) to serve the client better. It promotes the adoption of a process approach called the PDCA cycle while developing, implementing, and improving the effectiveness of a quality management system. Thus, enhancing customer satisfaction by meeting customer requirements.
There is also a misconception that QMS is related to Waterfall etc. It is a generic standard in all departments (hence complementary to agile).
We can see below that the 7 principles and PDCA cycle perfectly fit with Scrum as shown in the above two figures:
There is a table with some of the required ISO9001: 2015 clauses for agile software development to the corresponding Scrum practice.
6. Scrum Everywhere
Finally, Scrum is defined as “A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.”?
As an Agile company, we asked questions to us whether “Can this be improved? Can it solve obvious mistakes?”
And we found that Scrum is not limited to software development. For example, top management can define their next corporate strategy using Scrum. For that,?
Different departments as shown below also started using various Agile frameworks. That is to say
* HR, Support, and Admin departments adopted Kanban while
* Rest have started to use Scrum
*?HR & Administration
* Sales, Pre-sales & Support
* Content & Marketing
* Executive Team
* Product Development
One thing to keep in mind is that the company shouldn’t force everyone into a timebox/deadlines and other expectations that don't fall within the framework; it may create unnecessary pressure on those teams who cannot utilize Scrum to the full extent.
However, Scrum should absolutely be ACCEPTED by anyone within the organization that has any relation to the development team.