One Language One Team #wethepeople

Process

Process is nothing but a natural phenomenon marked by gradual changes that leads to a particular result. For e.g., Handling of paper, records, etc. by systematically organizing them. Here, I want to highlight need of Lean-Agile Teams by implementing "One Language - One Team" mindset.

Key Process evolution in IT industry

In Software or IT industries, Waterfall model based processes were used extensively for more than 3 decades which focuses on delivering product at once. As IT industry evolved and became competent, demand raised to speed up Time-to-Market and increase efficiency to adapt the changes. This brought up Agile - a iterative based process model and first major process transformation begun in IT industries.

Agile provided different flavors of Agile- Framework like Scrum, Kanban, eXtreme Programming, TDD, BDD, etc to resolve different development challenges to achieve better Time-to-Market and deliver values with agility. From past 1.5 decades, Agile is way of working in most of IT industries and proven effective at team level.

Processes impacting way of working

Changes is SDLC execution process also affects team's way of working and team members mindset. Let us have a look how working of team changes with the processes at glance.

While working in Waterfall, Development Team used to have team members which focuses on a system block/layer like Front-end/UI Layer, Middle-ware/Business Layer, Back-end/Database Layer, Testing, Business Analysts, etc. having responsibility of specific component or task. Generally, Team member of component specific development team used to call as Expert or SME. Waterfall Team model works well and yield appropriate results where requirement is fixed.

This Team behavior also get changed when organization moved to Agile and Development Team is now a Cross-Functional and self-organizing Team having team members who focuses on end-to-end execution of a Product feature or a complete system flow from requirement clarification to development to testing. Development Team member generally called as Full-Stack developer along with participation from Scrum Master to ensure everyone align with Agile processes and Product Owner to provide business knowledge including requirement. Agile Team model works well if there is requirement to increase change adaptability and where documentation is not a priority.

Lean-Agile Mindset Team

Presence of IT is increasing drastically in all non-IT market segments and it is helping them to grow substantially. Innovation and Continuous Improvement are now need of every industry to be competent in market, especially, when world is facing pandemic situation. Hence, organization must improve their way of working to support need of an hour to better support evolution of their product/services. 

On other hand, as organization getting more Agile, the number of Agile teams are also increasing that demands more collaboration and synchronization. What if multiple teams are working on same product or large and complex project? Will Agile slow down the pace? These challenges gave birth to Agile at Scale concept. With the help of Agile at Scale frameworks like SAFe, LeSS, etc, organization somewhat tested success to implement Agile across organization and established co-ordinations between Agile teams. Having said that, only adopting these frameworks is not good enough and organization have to restructure framework as per need while eliminating wastes. Thus, organization must start using Lean-Agile Principal based processes that will help teams to focus on providing greatest value to customer, continuously identify ways to reduce the waste and work together as One Team.

What One Language One Team Must do?

Teams that speaks one language can be grouped together which will yield expected results. Here "One Language" does mean not speaking language but purpose for which they are working or anything that can bind them together so that they can understand each other and grow together. "One Language" can be anything like;

• Programming Language - Multiple teams using same programming language (like Java, C#, Python, etc) to develop different features. For e.g., C# to Develop UI layer, Business layer and Database layer is used to develop multiple products or features by 2 or more teams, and all together called as "One Team" capable of executing anything using C# language. Thus, here "Language means C#".
• Technology Stack - Same technology stack (like Microsoft, Java, Cloud, DevOps, Automation, Big Data, etc) consist of multiple different tools to complete one end-to-end flow or segment. For eg., Different DevOps tool like Azure DevOps, AWS Pipeline, Hybrid DevOps implementation consisting different open source tools to implement DevOps cycle. These teams together form one team capable of implementing full DevOps cycle using any tools. Here, "Language is DevOps".

If a team member within the team is expert or highly skilled in one tool or programming language then s/he should share their knowledge within team in such a way that other team member benefit and develop capability to perform same task. Every team member is dedicated to execute cycle of "Plan-Build-Test-Release-Measure-Validate-Learn", defining progress as delivering great value to customers, bring Innovation and work together for optimization, reducing risk and reducing waste. As part of implementation, Teams must set ground rules which are not limited to;

• Share Agile event cadence: Every team must agree on same Agile team practices like Sprint weeks, Definition of Ready & Done, Retrospective, etc in a cadence.
• Share Technology vision: Every team will define and abide with technology best practices like Coding guidelines, Branching strategy, Architecture blueprint, etc to develop system
• Plan together: Team should follow Business and Technology vision to develop backlogs and work plan together. Team should be aligned with Release plan. Release independently wherever possible.
• Improve Collaboration: Collaborate frequently and at regular interval. Use collaboration tools like MS Teams, Slack, etc which helps to increase information sharing, resolving dependencies and ambient awareness of each other’s work.
• Retrospect together: Retreat and retrospect time-to-time. Self-manage and brainstorm on system improvements. 
• Trade-off: Adapt agility and team members should be in position to move to new roles to service most critical work streams. Multiple teams can move team member as per bandwidth and emerging priorities. Consider below two scenarios where Trade-off can be done. 
• Bandwidth Trade-off: Sometimes, team completes work items within sprint before time and team member left with some bandwidth. As per Agile practices, Scrum Master and Product Owner works together to have work item for available team member. Work item might be from future sprints, if planned already, or from backlog of specific release. If there is none, team member's either asked to perform peer programming or learning. However, great values can be achieved if bandwidth added in "Trade-off" bucket so that another team can consume this bandwidth to achieve their current sprint goal.
• Deep Skill Trade-off: Sometimes, team want deep skill resource to solve complex problem and team lacks or have less such bandwidth to complete a story or task within sprint. In these cases, other team can swap available deep skill team member for a sprint with other team such that both teams will be in position to accomplish their respective sprint goals. 
• Share knowledge: Team should learn together and share knowledge with each other. Participate in Design thinking sessions and engage in innovative solution to solve business challenges.  
• Demo & feedback: Team should provide demo on work done with other teams in regular intervals. Also, share feedback received from customer with other team so that same can be utilized to improve overall performance.   

Conclusion

There is nothing like Perfection while doing Lean-Agile. It has different ways to implement it and it varies from organization to organization. Company leadership team must adopt Lean-Agile mindset way to increase agility, innovation, and continuous improvement from core of organization.

At the end, the Lean and Agile together will thrive. It improves operating architecture and organizational models to enhance coordination between agile teams. Also, it helps to achieve faster Time-To-Market and results into great values.

Domain Low Code Architecture (#DLCA)

TECHNOLOGY

Technology is the sum of technique Skills, Methods and processes. Advancement of technology is generally known as Modern Technology. Modern technology is all about agility, speed and efficiency. 

From 2020, the era will be of Data and Low Code which will take pace. Here, I am showcasing how Domain Low Code Architecture (#DLCA) can be implemented to achieve Agility, Time to Market, Shared Business Rules to ease development of sub-domains\customized Apps within organisation and easily turning new idea into action.

KEY ARCHITECTURE ASPECTS

These are 4 pillars stand on Lean-Agile ground which will help us to build Low Code Domain Architecture.

1. Domain Driven Design
2. Clean Architecture
3. Single Source of Truth
4. Low Code

Domain Driven Design aka DDD is a broad concept and it is challenging to come up with brief definition, as Eric Evans had to write a book with 560 pages in 2003 on this. :) 

Domain-Driven Design is the idea that a forward-looking software system can be built on domain model that has a rich understanding of the processes and rules of a domain. DDD secure the domain model, in domain terms, through interactions with domain experts and protect corruption of Domain knowledge by other domains, etc. In DDD, sub-domains are created in large or complex domain. These sub-domains are called as Bounded Context. Identification and classification of Bounded context is done by Context Mapping. Also, Ubiquitous Language, UL, is used for communication between software developers and domain experts as a common language which means UL needs to be build that embeds domain terminology into the software system. Building blocks of DDD also includes classifying objects into Entities, Value Objects, Service Objects and identifying the concept of Aggregates. As any other model, system should evolve DDD model implementation as best possible fit and not as perfection as they say “perfection is the enemy of good”.

Clean architecture drives to organize system that supports Agility (easy to change), Understand-ability and Scalability (easy to grow). 

Every architecture emphasizes on below characteristics to develop a system.  

·       Independence of frameworks: Use frameworks as tools, rather than forcing you to cram your system into their limited constraints.

·       Testable: The business rules can be tested without the UI, database, web server, or any other external element.

·       Independence of the UI: The UI can change easily, without changing the rest of the system. A web UI could be replaced with a console UI, for example, without changing the business rules.

·       Independent of the Database. You can swap out Oracle or SQL Server for Mongo, BigTable, CouchDB, or something else. Your business rules are not bound to the database.

·        Independent of any external agency: Business rules don’t know anything at all about the interfaces to the outside world.

Single Source of Truth (SSOT) is One view of data that everyone in a company agrees is the real, trusted number for some operating data. It is practice of structuring information is such a way that every data element is mastered in one place and any possible linkages to this data are by reference only. The information is arranged and defined such that there is no duplication and overlaps.

     Low-code is a modern way to build and continually improve business applications that better matches the business agility. A low-code model enables developers of varied experience levels to create applications using a visual user interface in combination with model-driven logic. This means that those closest to business problems can be empowered to quickly turn ideas into action, with simplicity of minimum possible code.

Domain Low Code Architecture (#DLCA)

Low code is not just Drag and drop visuals but writing or having minimum possible code. In DLCA, we emphasize on making service and database layer such a way that it can be shareable between different sub-domains at ease.

Below is snippet of Domain Low Code Architecture based on above four pillars on Lean-Agile ground.

Following are agile bucket catalogs to build DLCA system.

• 
  
  
  • Open Source Domain Services: Open source is not a synonym of “Free” but things available for public use. It might be free or can be consumed on subscription basis. It is one way to contribute in evaluation of domain which just keep evolving for good. Thus, being a Domain leader, we can identify which artifacts, application, data or APIs, can be exposed to other world and encourage shared community for development and innovation in domain. For example, a health data having age, gender, region, symptoms, season and diseases can be used for Data analytics which can help medical scientist to study at which age a increase in diseases has been recorded in specific gender category. An organization can capitalize by commercializing these open source artifacts.
  • Shared UI Components: Must have system’s operations like Authentication, Logging, Controller layer for service call, etc can be decoupled from system and developed as isolated component like DLL, Nuget package, etc such that it can be consumed by any other system within domain irrespective of platform i.e., consumable by Web, Mobile or Desktop applications. For example, a controller or abstract layer class that used to call API service can be created as a component and which can be absorb by any system followed by calling component function which them make a call to service layer. Naming convention at all levels (for e.g., namespace, class, etc) of these components should not have any sub-domain specific name/key words until and unless component is sub-domain specific like abstract layer to call sub-domain service layer. Yes, sub-domain specific component is also published as shared UI components so that for Domain aggregates can consume it and system has SSOT.
  • Low Code Frontend: Minimum possible code to generate front end UI. No business rule and service call logic should be written in front end UI solution. Business rule and service call logic should be absorbing or inherits from shared UI components.
  • Shared Core Business Rules: Some Domain business rules are same across sub-domain which called as Core business rules. For e.g., calculation of VAT, etc. These common rules should be deployed as shareable within domain. Every system must not write their own version of core business rules. Shared Core Business Rules will restrict them to do and will save extra effort to rewrite same logic again within domain.
  • Shared Data Services: Master data like Exchange rate, etc. is common across domain. Such data should be available to all sub-domain to consume from one source and Shared Data Services will do the same. Shared Data Services will allow any sub-domain system to access these data as read-only.
  • Shared Services: Notifications, File operations, http/s calls, etc are some common services that every system must have in todays era. These services can be placed at Shared services for sub-domain systems.
  • Sub-Domain Services: This is classic sub-domain microservices. However, some microservices can be made available for access to other sub-domain. It might be possible that some sub-domains want to consume specific information of other sub-domain within domain then it should be accessible for them.
  • Domain Database layer: Domain Database layer will be based on services catalog and support domain service layer. If database is deployed at cloud then it is very easy for scalability which drives to customize sub-microservices architecture and make a single database for 2 or more sub-domain given partitioning, data access rules, etc are in place.
  
  

A large or complex domain run multiple customized small systems to support their sub-domain which results extra development work for every common component that already implemented somewhere within domain and not to mention running considerably extra data processing to merge or save at Domain level database. For example, in a large or complex domain where one sub-domain is not communicating with another sub-domain. In this scenario, they will end up writing their own system logic and that can be controlled by them. This duplicate effort can be saved by implementing Internal open source catalog by using already developed component within domain like, sharing same tax calculation across sub-domain will ease down tax data correction at different data levels.

DLCA can help organization to Capitalize on already built components, foster culture of Open Source within domains, Encourage sub-domains to work as OneTeam and Maintain Single Source of Truth across domains that can lessen redundancy and confusion.

Employee Advancement

PEOPLE

PEOPLE is the first word of Agile Manifesto (individuals and interactions over processes and tools), it is part of core values of many esteemed organization across the globe, its the PEOPLE who build organization and PEOPLE who are important than CLIENT. 
Every organization strive (or always trying) to become top employer to work with. We believe in talent, skill and capability of those with whom we work daily.
Here, I have learned and trying to suggest how we can keep our people connected for always.

Adroit Asset -

Adroit Asset means People who are Skillful or Multi-Skilled or having Niche Skill Set.

An Adroit Asset is one, who adds lot of accolades to the team or to the project\department. Below are some of the qualities they have:

• Nurturing team with right knowledge by knowledge sharing, brainstorming, new ideas, encouraging to raise questions, etc.
• Delivers with high quality
• Better Team Collaboration
• Building healthy competitive environment by challenging to achieve more and more

Why organization losing Adroit Assets?

There are various surveys and studies conducted on employee leaving an organization, and below are 3 most important reasons which are identified and confirmed in top 5 root causes-

1.        Lack of opportunities for advancement
2.        Unsatisfied Compensation / benefits
3.        Unsatisfied with Leadership

This whitepaper will try to resolve above reason#1 – Lack of opportunities for advancement.

Several IT players like Accenture, Cognizant, Wipro, Infosys, etc are seeing higher attrition rate i.e., above 20%, which is substantially increase than they have ever planned. 

Mindtree VP (People Function), Anish Philip, says “The percentages don’t matter. It’s the quality of attrition that does”

When high performer and proven skill set asset decides to leave organization, it does not only impacts quality but also affects negatively on team morale and more other aspects. 

Why it is important to retain or stop talent from leaving organization?

Disadvantages -
There are trade off when Adroit Asset leaves organization .

1.           Effort and time in Hiring process is exhaustive.
2.           Cost

o   New talent at same level will cost more given market relevancy of the role.

o   Time to be Productive - On-boarding and induction

o   New Time Investment in setting up Team Collaboration and teamwork

o   The Work Institute found that employers have paid more than $600 billion out of total turnover costs in 2018 for talent hiring or on-boarding, and it keeps increasing every year.

Advantages of keeping Adroit asset

•         Better customer confidence in delivering for long time projects
•         Improved productivity
•      Improvement in Employee satisfaction and engagement
•          Increase in Brand reputation

What can be done to retain Adroit Asset and provide opportunity for advancement?

External talent search requires significant time and cost to find the right fit.

Providing internal talent a chance for career advancement by posting job on internal job portal where every one within organization can see available job opportunity and submit request for the same.

As highlighted above, there are no expenses on 3^rd party engagement for talent search, connect and getting performance feedback of talent is easy given they are from organization.

Effort of initial screening of all searched candidates will be saved including managing their visit to organization premises.

Cost will be saved, in general, if we hire new talent from outside then we had to give new talent significant hike, like >=30%, whereas on advancement it starts with >=18% and also we can backfill their positions by resource which will cost less eventually.

Knowledge transfer from current level can be well planned as compare to transfer during notice period and it will be available at all the time if they are within organization.  

Conclusion

Providing first preference to our internal resources will give us -
1. A competitive edge on motivating and retaining talent within organization. 
2. An equal chance to our own people for advancement will be available

Eligibility criteria may vary for applying next level opportunity based on organization vision and/or processes. However, bottom line is to give them chance to grow whenever it is available within organization before forcing them to look outside.