Author: admin

Why is a multi-skilled team better than individual teams of specialists?

 

A multi-skilled team also known as cross function team consists of experts from different functions across various levels and skillsets who work towards accomplishing a common goal.

Working as multi-skilled team the individuals behave as ONE team and think collectively and collaborate creatively to accomplish the goal. This team love to self-direct and self-manage themselves, since each individual may bring different perspective and different solutions for potential challenges to a given task. This team can easily multi task because of the nature of multiple skills that exist within this team. The team makes their own rules and decisions with the help of a facilitator. Multi-skilled team is often compared to board of directors of a company, which is group of individuals with various backgrounds and disciplines are brought in order to help the organization or address various challenges.

Of late, multi-skilled teams become very popular, because of their ability to increase productivity by reducing the time to market of a new product development, their area of influence in an organization because they constantly engage with multiple communities of practice and their willingness to coordinate and integrate with various stakeholders within an organization.

 

Multi-skilled teams differ than individual teams of specialists in several ways:

• The individuals in multi-skilled teams are tagged to their respective business unit, but they perform in a different team, where they don’t have to compete with their peers who do the same job function.
• The team members trust and motivate each other work with a sense of urgency for making a positive impact.
• A leader who is a good facilitator and who can influence the team in a positive ways is need for multi-skilled team to demonstrate continuous improvement
• The team acts with a degree of freedom and have both authority and accountability for the results they produce.
• Management provide outside support to this team by providing the resources, guidance, direction and informal feedback as needed.
• Open communication exists within the multi-skilled teams to establish an atmosphere of transparency.
• Multi-skilled teams may eliminate the phase wise development approach and increases the focus on specific work item(s).
• Multi-skilled teams also minimize the need to blame different groups in the organization, since this team consist the necessary skills to build the product increment from end-to-end.
• Multi-skilled teams respond quickly to changing market and business needs than their individual counterparts.
• Cross learning is one key advantage of forming multi-skilled teams; since this team contains individuals with various specializations. They learn together, play together, win together and fail together.
• Multi-skilled teams often display their progress through big visible information radiators in the organization.

There are various challenges in setting up new multi-skilled teams

• Team members may be still carry their traditional mindsets even they become part of the cross functional teams.
• The team members may be halfhearted to take up additional responsibilities that re needed as a part of being multi-skilled team
• Sometimes, it is difficult to manage some immature individuals who cannot work without direct supervision, manager their performance appraisals and motivate the people.
• Everyone in the team should have Team member first attitude and they should be willing to perform outside their specialization areas to accomplish the end goal.
• Multi-skilled teams often have to deal with conflicts due to various differences of opinions, but with effective facilitator in place, these conflicts can be subdued.
• There are apprehensions that, there is some limited growth in cross functional team compared to individual groups.

 

A leadership role in setting up cross functional team will be some of the following

• Setting the board objectives before the team is formed.
• Define collective roles and responsibilities
• Establish team principles so that the multi-skilled team set their own ways of working
• Deploy the right resources and logistics to support a multi-skilled team
• Try to establish channels of continuous improvement

Developing Working Agreements

 

Working agreements are guidelines developed by the teams as to how they must work together to create a positive, productive process. Working agreements describe positive behaviors that, although basic, often are not automatically demonstrated in team processes. For example, an agreement might be “We all agree to participate fully.” Agreements are the group’s power tool. Elements of the working agreement should be posted (written out on a chart or board, or giving in a hand-out) for easy reference throughout the team process. They may be set upfront to establish a ONE team culture, and something to refer back when things get rocky within the team.

 

 

Working agreements:

• Develop a sense of shared responsibility

• Increase members’ awareness of their own behavior
• Empower the facilitator to lead the group according to the agreements.
• Enhance the quality of the group process.
• They are created by teams when ScrumMaster facilitate the meeting.
• They are preferably, created/reviewed during the Sprint 0 of every release.

 

Agreements work well when:

• They are important to the team
• They are limited in number
• They are fully supported by each member
• The members are reminded of agreements during process checks
• The members are reminded of agreements when they are broken

 

Some Examples of Working Agreement Guidelines are: –        Show respect. Don’t interrupt; let people finish what they’re saying. It’s OK to disagree with each other. No personal attacks, attack issues, we debate the merit of ideas, not people. –        Contribution. Everyone has equal voice and valuable contribution. –        Standup. Strictly adhere to the stand-up time –        Meeting. Be on time, end on time, have an agenda –        Be transparent. No hidden agendas. Get to the point, don’t beat around the bush.  We will give feedback, we will receive feedback, and we will act on feedback. –        Impediments. Road blocks should be addressed to the team –        We make commitments as a team.  We will be held accountable to our commitments. – we work as a team to make a commitment and deliver on it. –        Incomplete stories are not good – it is better to help get an existing story to “done” than to start another story that can’t be finished in the current sprint.

 

Common Concerns: What to do when someone in the group is breaking an agreement?

 

ScrumMaster, is the custodian of the working agreements, he has the right to question when someone is breaking the agreement.

 

Working Agreement Ground Rules Examples

 

1. Ground Rules Regarding Logistics
   1. Date, time, location
   2. List of participants (if different than team0
   3. Purpose of the meeting
   4. Order of business to conduct
   5. Ending time of meeting

 

1. Ground Rules Regarding Behaviors/Attitudes
   1. Each person should be prepared for the meeting
   2. Each person should come to the meeting on time
   3. The meetings will start and end on time
   4. As a team we will value the diversity of team members
   5. We will support the team concept and process
   6. We will work to maintain positive team dynamics
   7. We will make decisions by consensus (we will work out impasses by reverting to a majority rule after _____ amount of time and discussion)
   8. Each person will participate in the meetings
   9. Each person will keep track of their own work and the team’s compiled work. (Or, our team has a designated record keeper)
   10. Each person will listen and have an open mind.

 

1. Ground Rules Regarding Conflict and Team Member Exit
   1. Each person will be dedicated to openly discussing issues and conflicts openly with the team.
   2. If a team member is engaging in behaviors or attitudes that disrupt the work or climate of the team that person will be given a “warning” and an opportunity to change the disruptive behavior/attitude.
   3. This warning will be given up to ____(3)  times.
   4. If after the first warning the team member does not end the disruptive behavior then the instructor (T.A.) will be notified and notified after each subsequent warning.
   5. If the behavior continues after the ___ (3^rd) warning, then the team member will be asked to leave the team. This team member will no longer receive a team grade for the assignment.
   6. The team member who has been asked to leave will acknowledge that they must now meet with the instructor of the course to work out a potential arrangement. (Instructors should have an idea of what types of arrangements they are willing to make with team members who have been asked to leave their team).

Working agreements thinking grid

Who manages the team in Agile?

Forming agile teams are one the most important fundamental step in driving the team structure. The theory says Agile teams are small, stable, cross functional and self-organizing. These teams are structurally different than their waterfall counterparts. The waterfall teams most often are formed based on the organizational structure and hierarchy. The management often cascades work from top to bottom and also set the pace of urgency to increase the productivity in the team. Whereas in agile, the team sets its own pace, direction, schedule that fits into the larger organizational product roadmap.

In waterfall, Managers use command and control to drive teams towards the project goals. The manager look to the priorities that were set, track the progress and evaluate the performance of developers and testers in the project.

Agile teams are formed on the basic assumption that they have to start self-organizing from the day one. While this assumption may not be true in practice, it is the goal for every agile team to become fully self-organized after some point of time. Self-organizing team self-manage and self-direct themselves rather than waiting for instructions from their managers. The team follows a whole team approach to make decisions. The team makes commitment to the Product owner on how much they can work during a specific time period and tracks their own progress daily by looking at the burn-down chart. The team has a collective ownership over the deliverables they make at the end of the sprint.  The team is expected to build product increments of high quality consistently at a sustainable pace which has highest business value. High performing agile teams are usually tied up with great degree of mutual trust and candor. The management must also trust the team to get the job done. There is no one needed to micromanage the team on a day-to-day basis. The managers indeed can stay away from the team and provide the right support and help the team in reaching their goals. There should be constant and informal feedback cycles between different team members and management to understand each other improvement areas.

A facilitator like Scrum Master must help the team to deal with the dependencies and interfaces with the external agile teams and management. The Scrum Master is an influential leader who influences the team in a positive way rather than commanding the team. The Scope creep and feature creep may be prevented, if the team constantly collaborates with the team. The team and Product owner have to indulge in constant 2 way negotiation, which protects the development team from getting swamped with unrealistic workload and at the same time it also helps managing the expectations of end customers and senior management.

An Agile team may be given lot of Autonomy on how they should work. They may not require managers for mess with them on their daily work. Lot of support of the managers might be needed from outside. As long as the team finishes work by the deadline within certain constraints imposed, it is entirely up to the team to determine how it should work. One of the important points that worth mentioning are, for Scrum teams, the teams may not get any credit for the partial work. Even if 99% of the work is one on a user story, the team cannot demo it until it is done 100%, so the team will not get a credit point corresponding to that specific story. An Agile Manager goal may be to enable team to solve its own problems. An Agile Manager can become a team coach in helping the team to learn from their own failures, removing organizational impediments and giving frequent feedbacks. An Agile manager may also harness key important metrics coming from the team and product owner and reflect it back to the team to understand what the team takes away from it and make the team suggest an action plan for the same.

All in all, an agile team must be nurtured to manage themselves and make decisions themselves for meeting the product development goals. Key leaders in an organization must offer outside support for the team’s success. Agile teams have produced some of the greatest software products on the earth and the team contribution may significantly impact the quality and user experience. It is one of the key responsibility of the management of the organization to understand the anti-agile patterns within the team and remove them to make them fully self-organizing.

When is the right time for my company to go Agile?

Going agile may not be end goal for any company, agile may be only treated as an enabler to address business problems. If you see any of the following symptoms in your organization, consider going AGILE way, strictly with quantitative goals to accomplish.

 

Rapidly changing external business conditions:

The future of any organization is greatly influenced by its knowledge of social, economic and technical environment it operates. Moreover, the target market cultural shift towards globalization makes companies vulnerable to many challenges. It is important that companies must have to convert these challenges into opportunities to move forward; otherwise it poses a serious threat to their survival. So if your software products are highly competitor intensive and is continuously losing market share to your competitors products, something has to change in the way you produce those products. Added to this chaos, if your external business environment is changing at a faster pace where todays product road maps are redundant by next month, you should probably think of going “Agile” way of product development.

 

High time to market:

Time to market (TTM) is critical for any business in the current highly global competitive environment. Does you software development team frequently move the release dates? Are your customers frustrated by your development team’s inability to deliver on schedule? Do you see most of the time lost in communication between the teams, management and stakeholders? If your team’s software development cycle takes longer than that of your competitor, think of going AGILE. You never know, your competitor might be already in AGILE, because it was time that can make drastic difference to drive profits to the company.

 

Less Business value being generated

Business value is something which the information technology or the software product development team adds to the core company business it serves to the customers. Many organizations expect their software products to generate competitive edge in the market. Business value always varies with the company’s core business priorities and its product line. It could be organization transformation towards strategic initiatives or producing the finest operational excellence that is needed. Business value may also only be limited to what the customer want NOW, and not 6 months ago. Sometimes there is a business value in adapting to the new organizations processes and skills. If your company is not producing the business value that is needed, think AGILE way of working.

 

Low quality products produced.

Low quality may always be a pain to the company, since it generates lot of rework. Moreover, it damages the company reputation in the external market.  In today’s software product development, more emphasis is given to the user experience and creating rich UI’s. Poor quality may affect the bottom-line of the company in several ways.  It may affect the customer satisfaction, loyalty, sales and profitability. Most often in software product development, team perceive that it is OK to deliver the product increment with known defects, however this kind of perception really kills the good will of the customer in long run. If you see any of these kinds of issues repeating in your software development team, consider embracing AGILE. Agile preaches lot of good engineering practices, if implemented in your organization; it will help teams delivering better quality products.

 

Low customer satisfaction scores

Customer satisfaction score is one of the most crucial factors to drive product sales in any business. Customers may not be happy if the outcome of the product development is not as per their expectations. Few parameters which may impress customers are product usability, higher quality, delivering highest value functionality to the users more often and quickly and generating the economic value that matches the customer expectation. Dissatisfied customer often cease to use or purchase products or services without waiting for corrective action by the organization. Taking the feedback from the customer on a regular basis in the form or survey or user interviews is very important. If your customer satisfaction score started trending downwards, then you may have to buckle your seat belt and start looking at Agile way of product development.

 

High cost of responding to changing priorities

One of the most distressing things about in running a successful business is how you really deal with the changing business priorities. The priority list seems to change constantly and new work flows at an alarming rate. In addition, the priorities also grow at a rapid pace and mutate around every moment. In waterfall SDLC, the customer has to wait until the whole product fully developed to see something working. Any feedback or changes that need to be incorporated in the final product is too much of work and very costly resulting in most of functionality of the product redundant. If you notice similar frustration in your customer, try AGILE.

High turnover and low employee morale:

If your organization suffers from high employee turnover and low employee morale, it will have negative affect on the performance and productivity of the organization. Many researchers have in depth studied the root causes of these issues. The answers are not very simple and straight forward. Some negative factors that seem to have contributed to this situation are lack of transparency and openness in an organization, managers may be showing favoritism and creating unfair work environment, fear of manager retaliation, company sets the long terms goals to everyone and forgets about them or change them in middle, and management is not reachable to the employees or not open to take feedback. There are lot of costs that a company has to incur if they see high turnover and low morale. The costs related to rehiring, customer deliverables may be of poor quality, company loses of knowledge gained by experienced employees. If you had to encounter similar hell like situations in your organization, rethink about changing the way you work and deal with employees.

 

No room for continuous Improvement.

When your team is always in a firefighting mode, they hardly gets any time for realizing what went wrong in the past and take the corrective step. There may be several reasons which could be root cause for such a situation to arise. For example, the team was swamped with too much work, by the management and they hardly have any time to look back. The team might have inherited too much of technical debt, which they have to clean up upfront before they start the real product development. The team is often bothered by customer with too many changes resulting in lot of rework. The team hardly might have any time to focus on what they want to do, because they were often disturbed by managers to do the things their way. In case, if any of these items surface in your team, try going AGILE way, because it strongly embraces the continuous improvement framework.

What is Velocity?

To refresh our primary school physics basics, Velocity is a vector quantity that refers to “the rate at which an object changes its position”. If a person moves back and forth rapidly, always returning to starting position, it would result in a Zero Velocity. In other words velocity is not only the Speed at which someone moves, but it is also the direction that matters.

 

1. What does velocity measure? 

• To relate the concept of Physics velocity in software product development environment, Team Velocity is the run rate at which a development team delivers the product backlog and the way team accelerates (or decelerates) velocity during the product development.
• Velocity will gives us an idea about, the value delivered until now in terms of story points and teams ability to deliver certain number of story points within certain time frame
• In simple terms, Velocity is the amount of story points a development team capable of completing/completes in a Sprint.
• Usually, Mean Velocity is calculated by averaging the velocity of first few sprints, to understand the strike rate at which a team can complete the rest of the product backlog.
• Velocity is the number of story points completed by a team in iteration.

 

2. Why is velocity important?

   Velocity is important due to several reasons listed below

• Velocity helps the team become more predictable.
• It also aids in predicting when all features from the backlog will be implemented.
• It can help the team to find out the next release date based on set of finite number of user stories.
• We can look at the team’s trend for an indication whether the team is getting slower or faster and act accordingly
• Velocity can be employed as a lagging indicator for understanding various root causes of several issues the team is facing like removing critical impediments, motivation that drives the team, training the team in areas of improvement, delete user stories, providing effective resources to the team, increasing product owner involvement with the team etc..
• For a new team, Velocity will increase for the first few teams and even out later. Velocity may not be forever fixed.
• Keeping the team composition and sprint duration constant, Velocity is a great metric to understand the team progress.

 

3. How to measure velocity? 

• The underlying principle of measuring velocity is to find out how much value a development team is delivering to the business. Velocity measures a team’s ability to turns user stories into new working software in a sprint.
• A new team getting into Scrum, initially adopt anyone of the 2 ways of sprint planning, Capacity Planning and Velocity Planning.
• The new team can plan for their total team capacity and pull certain number of stories into the sprint with all necessary buffers. After each sprint, velocity is measured. After 3 sprints, the average measured velocity can be used to predict the velocity for future, and there by completion date. The team may also take a guess of their velocity during the first sprint planning and adjust accordingly until the average velocity is discovered.

Scenario: Our team delivers 10 user stories. The sum of the story points equals 53. Our velocity is then 53. If, in the next iteration, our team delivers 25 story points, then our average velocity is 39, or (53 SP + 25 SP) divided by 2 iterations = 39 SP.

• Partially completed stories do not count towards Team Velocity. Velocity is all about finished, accepted and delivered user stories. Partially completed stories will not deliver working software to the customer, who creates a false sense of accuracy and they generate no business value to the customer.
• There are some advanced mathematical methods available to calculate velocity when team composition and number of team members are changing every sprint.

 

4. Pitfalls when using velocity as a measurement

• Velocity is nothing until a history is established.
• Velocity is a backward looking lagging indicator and it will not show the good things coming in future.
• Velocity should not be used as a cane to punish the team.
• Do not compare Velocities of two teams to find out the better-performing team
• Bugs and maintenance work may also be considered part of velocity estimation.
• DO not measure Velocity to draw awkward conclusions about a team, project or Organizations

What is the job of the business analyst in Agile?

A Business Analyst role existence is the one which is often challenged in Agile team in conjunction with many other roles like development team, Scrum Master and Product Owner. However there are various reasons to believe that a business analyst is a key member of the team and can add significant value to the cross functional agile team.

The business analyst is a persona on the team who:

1. Establish a communication channel with Product Management and Development team
   The business analyst in Agile team is responsible for understanding and communicating the holistic end-to-end business transactions impacted and its functionality with the Product Owner and development team. Often a business analyst is also one of the cross functional team member in an agile team. In several cases, especially for a distributed team, a business analyst back fills a busy Product owner role for the team. Hence she is often called as Proxy or Supporting Product Owner. She is the center of communications in agile teams who are remotely located and who don’t have the availability of the real Product Owner. She works with the real Product Owner to understand the big picture and cascades the same to the development team. The business analyst also acts as a two way communication channel between the Product Owner and brings the customer feedback to the team. The business analyst sometimes explains the Product vision to the development team and explains the business purpose behind working on a specific feature. It is very much essential for the business analyst to foster a shared understanding with the entire team. The business analyst also negotiates with Product Owner on behalf of the team with respect to delivery timelines.

2. Evoke requirements breakdown
   A business analyst in Agile team decompose the heavy requirements into small manageable pieces and write them in the form of user stories. He also write acceptance criteria and makes wireframes to make it easily explainable. He also manages dependencies between user stories with the help of Product Owner. She will also be engaged in managing the product backlog like grooming the backlog, prioritizing and refining it as per the changing market needs. She ensures alignment and realignment of business priorities with the development team.

3. Helps team in requirement analysis
   The agile team business analyst work day to day with the team and clarified requirements, acceptance criteria, accept final stories and coordinate with other business people. She communicates with various people by facilitating agile ceremonies such as iteration planning, kickoff etc. She also acts as a major stakeholder in all estimation sessions and numerous ad-hoc discussions. She focus on keeping the team up-to-date in making any changes to the stories as per the changing customer priorities and having their questions answered. She also makes an impact by attending agile ceremonies by guiding the team to make the best decisions, by making required data available. The business analyst largely contributes to the development team success.

4. Perform test validation
   Agile business analyst may have a deeper understanding in the system functionality as well. She also understands the various screens business flows and how end users really work with the application. She is also aware of negative flows, validation controls, colors and fonts and screen layouts and response times. In agile teams, she may also help the team in performing test validation to check the test cases are comprehensive that matches with the application functional flow and give feedback. She also review the ‘Definition of Done’ produced by the team and give appropriate feedback. She also reviews the necessary user documentation produced by the team and understand if it is concrete that helps the end customer in understanding the application flow.

What is Scrum?

• Scrum is a process framework which was being used to manage complex product development post 1990.

• Scrum Guide contains the definition of Scrum. Ken Schwaber and Jeff Sutherland developed Scrum and they are the co-authors of Scrum guide.

• Scrum in software development lies under the broader umbrella of Agile which is a light weight framework guided by Agile common manifesto and principles used for developing and sustaining complex products. It is a framework within which emphasizes the business value delivery, within which people work on complex adaptive systems being highly productive and creative.

• Scrum focus on incremental and iterative software development in time boxes that embrace inspect and adapt cycle based on feedback received from the stakeholders. It also warrants the need for tighter collaboration among individuals to promote stronger team work throughout the development cycle to deliver greater business results.

• Scrum may not be perceived as a process or a technique used for developing products, rather, it is cofounded on the principle of empirical process control theory which asserts that knowledge comes from experimenting and experience and making decisions on known set of results, thus making the approach to optimize predictability and control risk.

• As per Scrum Guide, Scrum is:

• Lightweight
• Simple to understand
• Difficult to master

• The Scrum theory operates on three principles; Transparency, Inspection and Adaption.

• Scrum framework mainly consists of 5 values; Focus, Openness, Commitment, Courage and Respect.

• Scrum advocates 3 roles; Development Team, Product Owner and Scrum Master.

• A Scrum Team performs 4 events as per the recommended time boxes in Scrum Guide; Sprint Planning, Daily Scrum, Sprint retrospective, Sprint Review.

• An optional event in Scrum is Product Backlog refinement.

• Scrum recommends 3 artifacts; Product Backlog, Sprint Backlog, Potentially Shippable Product Increment

• Other miscellaneous artifacts that are part of Scrum are “Definition of Done”, “Burndown Chart “

• The rules of Scrum bind together the events, roles, artifacts, governing the relationships and interaction between them. The rules of Scrum define various parameters to nurture normal development teams into hyper productive teams.

• The time boxes in Scrum are termed as “Sprint”. Every Sprint has a defined Sprint Goal for the development team to accomplish.

• In Scrum, the Product Owner has the exclusive authority of cancelling a Sprint, if the Sprint Goal is redundant.

What are some of the common problems with Scrum adoption?

During the recent past, it has been a rat race that many organizations wanted to go the agile way of working, irrespective of their ability to change and work towards being agile. Often, organizations try to adapt to Scrum (since it is one the most popular framework in agile), but fail miserably due to several reasons. Some of the common problems are listed below.

1. No support from the senior executive Leaders
   Often, senior leaders may be willing to go the agile way, but they turn negative after they fully understand the effort it takes for an organization to become truly agile. Senior leaders like CIO must be willing to issue mandates and follow up on the transition regularly and provide necessary support whenever their help is needed. It is also likely that senior leaders may not be capable of naturalizing the effect of job losses, if any, during the agile transition. Sometimes, senior leaders do not communicate enough with the employees during the change, this provokes employees make their own assumptions and falling apart without supporting the change.

 

2. Existing Organizational Structures and Hierarchies
   Existing structures sometimes may play the spoil sport in scrum adoption. The biggest pit fall is the organization leadership tries to tweak Scrum to force-fit into the existing organization structure and hierarchy. Some of the tweaks that are like to happen are; Manager jumping to role of Scrum Master still using command and control, individuals work into silos without a team concept, the Product Owner is someone who is pushed into the job without knowing his roles and responsibilities.  Few times, you will also notice that Scrum Master will be controlled by managers. The existing process overhead in the organization may be too much for the team to carry on every sprint. No one really bothers to simplify the existing processes to the extent that the team starts self-organizing and delivers working software. The teams selectively apply scrum principles and eliminate the one which are difficult to adapt given the circumstances. The Product owners are often overridden by someone sitting up, and they become very weak at making necessary decisions for the team and stakeholders.

3. Distributed teams
   Scrum works well for co-located teams, however there are costs associated to adopt Scrum to distributed teams. Distributed teams are today’s reality, however it is recommended that organizations must make teams that are co-located teams and make them accountable for the results. Senior leadership face a stiff resistance in breaking the distributed team culture, since managers below do not trust the remote teams completely. They also fear that they lose control over delivery, if someone located near, are not involved in the day-to-day delivery. Perhaps the biggest challenge with distributed team is that they don’t behave as ONE team. It is very much important that frequent contact among the team members, may be very effective, even though it is electronic. To make scrum adoption successful, it is a prerequisite that organizations must invest in high fidelity communication equipment infrastructure to enable smooth communication between the distributed teams. Added to that, organizations may also understand the necessity of tools for continuous integration, code reviews, unit testing and automation. Scrum may not work well if tools that improve the quality of the product are not in place. The desired results may be disappointing until the necessary tools in place to helps the teams to become distributed teams hyper productive. 

4. Regional Organizational culture
   Regional culture always plays a dominating role deciding the Scrum adoption. Most of the agile cultures like India, Vietnam, Thailand, Philippines, China, Japan, Malaysia, and Singapore struggle to adapt Scrum as per Scrum guide. These cultures are particularly inclined towards hierarchy status and titles. When promoting agile methods, which warrant high transparent team breakouts, it is very difficult to keep the team hit the ground running, since most of the times the team hesitates to speak up. In some Asian cultures the word “Servant Leader” has a negative meaning of lesser social status. Added to the chaos, imposing performance appraisal bell curves also make people to show case their individual heroism than the team work.

5. Unavailability of human skills
   There is a dearth of agile skills in the open job market. Since the demand is ever growing exponentially, scrum/agile practitioners are wanted everywhere. Especially, skills like servant leadership and effective facilitation are some of the rare skillsets which very few individuals possess. The supply of Product Owners who are responsible for the ROI of the product too is very less given the high demand scenario. There are many organizations that might be a using ScrumBut, those similar experiences and skills may be of little/no use in the organizations who truly want to go the real agile way. The availability of Enterprise Agile Coaches with necessary experience in the open job market is also diminishing, which prompt some organizations to compromise on the quality.  Agile methods also embrace the need for specialized skills like test automation, build automation, devops. These skills are very much in demand in the marketplace, and so every organization out there is competing to attract people with these skills.

Suggestions to overcome common problems:

1. Executive management need to understand that, being Agile may not be the right end goal for any organization, in fact agile is an enabler for accomplish business goals.
2. Engage enterprise Agile Coaches with significant experience in facilitating the right outcomes. Fully leveraging these coaches will make a huge difference to organizations rather than trying to solve these issues with internal staff.
3. Executive management need to understand that Agile transformation is a major organizational change and not merely project level coaching. So every support functions in an organization need to support agile transformation.
4. Lot of executive support and direction may be required for agile adoption, to push the change top down the layers and they have to continuously monitor the progress and remove organizations impediments that surface time-to-time.
5. The past transformation approaches show that, some organizations take a top-down approach while others take bottom-up, however, the results show that no single approach works perfectly, it largely depends on how organizations absorbs the change within its culture.
6. There needs to localized strategies made for every country culture, given the regional cultural differences, to make the agile transformation successful, while keeping the end goal same.
7. Not having the right human skills in an organization, may impact the agile transformation significantly. It is important that organizations keep their skilled people on standby, before they start the transformation.
8. Do not force-fit agile into the existing organization structure and hierarchy, in fact there are many organizations out there, who tweak agile frameworks that fit into their existing structure and hierarchy, which is the biggest pit fall.

Types of Testing in Agile

What is the difference between unit testing, integration testing, and user interface testing?

Every test has its own level and place in the Agile team’s Definition of Done (DoD). The DoD is the exit criteria which exists at multiple levels like User Story level, Sprint Level and Release Level.

Unit testing:

• Unit testing is the basic building block of Extreme Programming (XP). Unit tests are written to verify that our functions, methods or classes work as expected. The desired set of inputs is given to a unit of code to check if it returns proper values as per the design.
• Unit testing exist at a User story level DoD and Unit test cases must be written for every User Story.
• Unit tests are written and bundled along with the code repository and checked in into the respective folder.
• The build also compile the validity of unit test cases before getting executed.
• All unit tests should be code reviewed before checked in into the repository
• It is not a good idea to release code with unit tests,
• It is always important to check if the code has 100% coverage of unit tests.
• Tools like SONAR may help developers to understand the unit test code coverage, along with cycomatic code complexity.
• Unit Tests is also useful to handle exceptions in a try, catch block.
• Tools like JUNIT can be used for writing unit test cases.
• Unit tests also minimizes the technical debt remaining in the design and the code

Example of Unit Test Case:

// In Java, We write unit test case first to add two numbers;

public class TestSum {

public void testSumPositiveNumbersOneAndOne() {

Sumer sumer = new SumerImpl();

assert(sumer.add(1, 1) == 2);

}

//Write the corresponding interfaces in method and define a class within in it.

interface Sumer {

int sum(int a, int b);

}

class SumerImpl implements Sumer {

int sum(int a, int b) {

return a + b;

}

}

 

Integration testing:

• Integration testing is a process when two or more software components or units are integrated, the combined testing that is done to verify the interaction between them to expose defects which deviate from the application desired functionality.
• This testing may exist as a part of Sprint level or Release level of DoD and it depends on the product hierarchy.
• The components are tested as a single group or organized in an iterative manner.
• All functional requirements tested, including both positive and negative tests, with the number of tests based on size, complexity, and risks
• All interfaces between units must be tested so that defects do not slip through
• All quality risks covered according to the agreed extent of testing
• No unresolved major defects (prioritized according to risk and importance)
• All defects found are logged and reported with priority assigned to it.
• All regression tests automated, where possible, with all automated tests stored in a common repository
• There are 4 main integration test approaches are followed as per ISTQB; Big Bang approach, Top Down approach, Bottom Up approach and Sandwich Hybrid approach

 

User Interface Testing:

• User Interface Testing confirms the correctness of the application’s user interface and it will point out any valid deviations as per the UX coding standards.
• This testing may exist as a part of Sprint level of DoD
• It involves testing the UI and comparing the result with the expected output and its ability to replicate the same accuracy several times, by providing various inputs and checking the output.
• This testing handles various events related to mouse, Key strokes, toolbars, drop downs, menu bars, images, validation controls etc to check if they react as per the specification or not.
• This test can even check for object states and date fields in various numeric formats.
• This testing also checks the data integrity, usability and reliability of the output.
• This testing can be performed both manually and automatically depending on technology being used.
• This testing can be tested manually based on the application knowledge and domain knowledge of the tester.
• This testing can be done automatically by using various tools based on the capture and replay of user actions. Examples of commercial automation tools available in the market are Selenium, Robert Framework, AutoHotKey etc.

Techniques for gathering user stories

 

Product Hierarchy of Agile Software Development:

The Agile Product software hierarchy is developed top down. The starting point is to map out every one of target customer’s missions and define all. The Product Hierarchy has been broadly divided into various labels based on the position they sit in the hierarchy.

There are various names like Idea (Theme), Initiative (Vision), Feature, Epic, User Story and these are often interchangeable. The lowest level artifact is always: a User Story.  Stories need to be developed as a part of the Release Planning. Stakeholders and P.O. agree on what features/epics will be developed in a release cycle. If it isn’t in the release cycle, the team will only provide high level estimates.

Every initiative starts with a product vision documented in black and white. The vision describes why the project is being undertaken and what the desired end state is.

The vision addresses 5 questions:

• Who will buy the product? (Target customer)
• Which customer needs will be address?
• What are the critical attributes for success?
• How does it compare against existing products? What are the unique selling points?
• What is the target timeframe and budget?

A good Product Vision aids in creation and organization of product backlog and determine “minimum viable product” which is critical to achieving the business benefit.

 

PO plays a vital role in dealing with the Product Hierarchy. The PO acts as a funnel between the business stakeholders and development team to collect the requirements, prioritize the requirements and convert them into work items (aka User Stories).

Few Techniques which are Product Owner may use are for gathering User stories are :

 

1. Market Research

It is a very important strategic step in execution to gather the information about the target customer requirements. It is also a key factor to remain competitive over competitors. It also provides important data points to identify and analyze the market size, market needs and various customer demographics..

It may also include opinion research about individuals in an organization for various interpretations using statistical and analytical tools and techniques available for efficient decision making.

 

2. Surveying Users

 

Kano Analysis

 

Kano Analysis is one of the surveying technique under which features of a product are categorized into 3 sets

 

1. Exciters/Delighters à Features a user don’t know she wants, until she sees it.
2. Linear à The more of it, the better
3. Mandatory/Baseline à Must be present in order for the users to be satisfied.

 

To assess whether a feature is baseline, linear, or exciting we can:

 

• Survey a small set of users (20-30). We ask two questions
  • A functional question: How do you feel if a feature is present?
  • Example: If you receive your monthly bill through email, how do you feel?
  • And a dysfunctional question: How do you feel if that feature is absent?
  • Example: If you receive your monthly bill through snail mail, how do you feel?

 

• We will choose and answer pair based on the responses and aggregate the results.

 

In the Product roadmap, we will include the entire baseline set of features, some amount of linear features and Leave room for at least few exciters.

 

 

3. Expert Opinions:

 

1. Theme screening

 

Identify 5-9 (approximately) selection criteria for what set of features are important in the next release an follow the following steps,

 

• Select a baseline feature likely to be included in the next release understood by most team members
• Assess each candidate feature relative to the baseline theme
• The features with the highest scores in the decreasing order are picked up for the release to work on.

 

1. Theme scoring

 

• It is very much like theme screening but selection criteria are weighted
• Need to select a baseline reference feature for each criterion. It avoids compression of a category.
• Each feature is assessed against the baseline for each selection criteria with the ratings given below in the table

 

Much worse than reference	1
Worse than reference	2
Same as reference	3
Better than reference	4
Much better than reference`	5

 

• The numbers are aggregated to rank them in order. The first few highest ranked features are picked up for the release.

 

 

 

 

4. Mathematical calculations

 

Relative Weighting

• Assess the impact of having a Feature from 1 to 9
• Assess impact of NOT having it from 1-9
• It then calculates the value of each story or theme relative to the entire product backlog. This gives the relative value of that Feature.
• We need to estimate the cost of each Feature. Calculate the cost of features relative to the other features in the entire product backlog.
• This gives the relative cost of that story or theme
• Priority is given by (Relative Value ÷ Relative Cost)

 

5. Prioritization Techniques:

 

 

MoSCoW Method:

 

A MoSCoW is an acronym of MUST Have, Should have, Could have and Want have.

 

Must Have

• Business goal/benefit is not accomplished without the story
• Product cannot go to production without it.

Should Have

• The purpose would be accomplished but an undesirable compromise or work around would be needed

Could Have

• The purpose would be accomplished but a desired improvement would be lost

Want but Won’t Have

• Often called “gold plating.” A story which extends functionality beyond what is necessary for the purpose or for which there is unclear benefit

 

• The Must Have Features are features need to be present for the software to be able to accomplish the purpose of a release
• This defines what the minimum level of success for the team in a particular release. If any must have story is not delivered, the release is a failure
• If all stories are “must have” in a feature / epic, the release is in danger
• Organize into piles by MoSCoW rank. Move the “Won’t Haves” out
• Force rank each MoSCoW category based on highest level of business to lowest, if known