Your ability to change methods depends on your control (or influence) in this area. But you should of course first want to understand why you are seeking to changing methods or frameworks, i.e. the benefits — and how you will measure success.  Agile can reduce risks associated with product development in that, if properly applied, it helps the business to quickly validate that their needs are met, based on working software that can be demonstrated earlier vs. traditional projects.  The business may also appreciate that there is a lower cost of changing requirements. At the same time however, the final scope under agile are arguably less certain.  We can provide some good sources of information for understanding basic Agile principles and application in Scrum projects — contact us for more information.

Same initial considerations apply here as in the previous situation, EXCEPT you should carefully consider how many individuals are engaged in delivering products for the same value stream, many priorities and dependencies between teams/areas, typical ramp-up required, and typical validation and deployment requirements at the end of projects.

When you have multiple teams engaged in product delivery and some of these other requirements, deployment requires more planning and engagement between the teams and members, and priorities across teams must be well-established and vetted. Agile can still work if you have well organized and coordinated project leadership managing the programs, and using Scrum of Scrums during the project. However, it is not the usual case to have such finely-tuned attention and coordination in these cases, which is why we recommend that a scaled agile approach be used. The Scaled Agile Framework (SAFe) provides a holistic, end-to-end process for efficient product deliver. From managing business and technical requirements to core agile team development to final validation and deployment by system teams. Other scaled agile methods are available but we recommend SAFe at this time as it is more widely established and refined from practice.

Response pending

Consider your response to the general indicators of a healthy Agile Scrum process – and your challenge areas.  How are these being impacted by distributed teams?  Distributed teams can complicate the collaboration aspects which Agile requires.  We have found benefits in considering the following approaches:

• Forming team around a core that is co-located or where members are on closer time zones to support better collaboration and the ability to attend daily Scrum / standup, and other agile ceremonies.
•  Enable sub-teams to meet in their respective time zones and have sub-team members meet a few times separately to sync. This is similar to the Scrum of Scrum approach.
• Reduce dependencies on specialized roles within the team. Progress is greatly facilitated when fewer divisions of roles exist (e.g. QA and Developer), which generally is less agile to begin with but common in practice. If team members can wear both hats, they are likely to be able to pair up and reverse roles without time zone delays, and the build and deliver loop is shortened.
• Try to reduce multiple managerial reporting relationships on the same team.
• If nothing else, the team should be discussing challenges in this area in Sprint Retrospectives and identifying how to best organize itself under the circumstances.

One would do well to evaluate the following factors:

• Is the team  consistently meeting it’s commitment?
• Has the team attained a relatively consistent velocity?
• Are business needs well-represented in the priorities resulting in timely delivery of value to customers (external or in some cases, internal)?
• Is the team seeking to improve on an ongoing basis – does the team meet regularly to evaluate outcomes and how it might improve?
• Is there evidence of high quality the the product being delivered?

Response pending

Response pending

Response pending

Response pending