Have an Initial Conversation to Start an Agile Project

This article was published on Scrum Alliance in Oct 2010

In this article, Prashant Patel and I present:
• The different aspects of this conversation - the parameters that we consider.
• Why these parameters are relevant in the context of Baker Hughes Inc.
• The impact of these parameters on solution delivery

Have an Initial Conversation to Start an Agile Project

The Baker Hughes Product Development Lifecycle starts with discovery and inception phases. The delivery teams start engaging with the customers during the inception stage. By the end of inception, business requirements are understood at a high level and stakeholders from different teams who will be involved in the project are identified. This is when discussions are held for selecting the appropriate solution delivery methodology.

The choice of methodology impacts how the different stakeholders engage with the project. We have seen that in order to improve the chances of success for any project, the solution delivery methodology and the level of commitment needed should be understood upfront by all stakeholders. To that end, it is important that there is representation from multiple stakeholders, including but not limited to business, development, testing, agile coach, project management and resource management.

The stakeholders should be aware of the agile methodology and scrum framework for having this conversation. It is beneficial if they understand the rigor agile brings with respect to solution delivery and how it is different from waterfall.

Parameters

As part of our methodology selection criteria, the team examines the following basic parameters. During this conversation, the parameters and their implications are discussed in detail and a rating is given to each sub-parameter. All parameters need to be rated to consolidate the results, but it is not necessary that all parameters need to be rated favorably as a criteria for going agile; however, parameters with lower scores are considered risks associated with project execution. It is more important for stakeholders to have the conversation, understand their constraints and make a conscious selection of the solution delivery methodology, than the actual number results from this assessment. At the end of inception, the team needs to agree on the solution methodology based on its own judgment.

These parameters are customized to work in our environment and can be discussed in any order of preference. Organizations are encouraged to devise their own criteria based on the guiding principles of agile and assign their own weights to individual parameters.

Collaboration with Business

Collaboration with customers is critical to successfully execute an agile project. That is why it has been explicitly called out in the Agile Manifesto (www.agile manifesto.org) – “Customer collaboration over contract negotiation”. As part of collaboration with business we examine the following:

• Availability of Business/Customer for clarifications
  Some customers prefer to go away after the initial discussions on project scope and requirements and be available only when the complete scope has been developed to check and provide feedback. This approach does not work very well with agile and Scrum teams.  Short feedback cycles of two to four weeks require that customers are engaged throughout the project lifecycle and are available to provide feedback at the end of each sprint. During the sprint planning, teams may identify certain open points, questions and reminders for discussion during the sprint execution. These may also need clarifications from the customer even while the sprint is in progress. In order to meet the sprint commitment, the stakeholders need to ensure that passing on these clarifications to the team does not require too much time.

• Flexibility towards scope reprioritization 
  Agile teams thrive when they can deliver what the customer needs. Their focus is to continue to deliver maximum business value in shortest possible time. This is only possible if the scope is revisited frequently and not cast in stone at the beginning of the project. As part of revisiting the scope, it is essential that the priorities for the remaining work are revisited as well.

• Identification of acceptance criteria
  The stakeholders discuss and agree that the team needs to be given fair visibility and understanding of the scope items at the beginning of every sprint so that they can make reasonable commitments on what can be delivered. For this reason, we encourage the stakeholders to identify the acceptance criteria for each scope item at the time of sprint planning.

Project Constraints

Projects may have multiple constraints that may need to be satisfied. Each organization, group or team may have their own set of constraints that may be evaluated during the conversation – These should be heavily customized depending on the project situation. Below are the criteria that we use at Baker Hughes:

• Outgoing and incoming dependencies
  Dependencies with external teams add to system complexity. Ensuring that the project progresses as required, requires coordinating multiple dependencies. At times, dependencies may impose constraints such as: force special schedule requirements for certain scope items, make a part of scope definition more rigid, and make certain resources available to the team only in a particular time window. A large number of dependencies require allocating a significant amount of effort towards synchronizing the work of different teams. In that case, stakeholders need to discuss how these dependencies would be managed in the context of agile.

• Documentation needsThe agile manifesto calls for “Working software over comprehensive documentation”. Stakeholders need to discuss and agree about the level of documentation that will be created. For agile projects, stakeholders should agree to create only that documentation which will have value and will be easily maintained. Regulatory aspects, which may be relevant to some projects, should be considered too.

• Resource allocation and availabilityFor agile projects, we encourage the team members to be allocated 100% to the project instead of allocating percentages. We also encourage them to retain resources for multiple versions of the product and we discourage teams from changing resources while a sprint is in progress. This helps sustain delivering to sprint level commitments and makes resources own the sprint results and a predictable team velocity.

• CollocationCollocation of team members improves intra-team communication and improves velocity. Multi-located teams can do agile with the aid of communication and collaboration tools.

• Build automationTeams are encouraged to put build automation in place as early as possible during development sprints. If teams do not automate their builds, a lot of time is spent in manual builds and continuous integration cannot be accomplished.

• Unit and System Test automationDeveloping in short cycles and sustaining good quality and high velocity requires that team should be able to test what it develops quickly and effectively. This becomes difficult with manual tests as system becomes more and more complex with each passing sprint and regular addition of new functionality. Creating a good set of automated tests helps in ensuring that system health is maintained even after multiple sprints without sacrificing speed of delivery.

• EmpowermentAn empowered team performs faster and better, and is more accountable for its results as compared to teams that have not been empowered to make certain decisions regarding their work.

• Product Owner empowermentDuring the conversation, a product owner is clearly identified and expectations from the role are discussed. For agile projects, it is important that the stakeholders empower the product owner to make quick decisions on the project scope and provide direction to the team about what needs to be done in the project. The product owner is also empowered to decide on the priorities of the items in the product backlog.

• Scrum Master empowermentA Scrum Master is also identified clearly to help the team in removing impediments. The stakeholders and the product owner should empower the Scrum Master to act in the interest of the team, represent the team and say “No” to disturbances.

• Team empowermentThe stakeholders empower the team to go into agile and Scrum with an understanding that they are empowered to provide fresh commitment at the beginning of each sprint. Since the details for many items in the scope may be discovered while the project is in project, initial estimates of the team are only based on the visibility of the team into the requirements at the beginning of the project. Stakeholders discuss and agree that these estimates may be revised later on in the project as the team gains more visibility on what needs to be done.

More of the same

To be able to deliver new functionality in short cycles, it helps if the team members are well aware of the business domain and technology.

• Team’s acquaintance with business domainThe stakeholders discuss about the team’s awareness of the business domain and if it has executed similar projects in the past. If business domain is not well understood by the team, the gaps are identified and team is coached during the project.

• Team acquaintance with TechnologyThe stakeholders also discuss the need for the team members’ acquaintance with the technology. At times the technology itself may be new or the team members may not be acquainted with advanced concepts that might be used in the project. In such cases, or where there are gaps, the team should be coached. This might involve planning for additional technical trainings for the team and/or on the job coaching by experienced technical staff.

Team characteristics

Fast- paced agile development requires giving importance to “Individual and Interactions over processes and tools“. It becomes crucial to assess if the team is well suited to perform in an agile setting.

• Team sizeThe stakeholders discuss about number of developers and testers that will be on the team. If there are too many people in the team, it impacts the team’s focus and activities (such as daily scrum meeting, making a sprint goal commitment) start taking longer time. This is attributed to the number of possible communication channels within the team, which increases substantially with team size. Based on our projects at Baker Hughes Inc., we have laid down the appropriate range from five to ten, with five to seven being the ideal range.

• Agile coaching and awarenessSince the organization is new to agile, it is recommended to have an agile coach associated with the team to guide the team members with agile and Scrum. In the context of Baker Hughes Inc., the delivery organization’s Program Management Office helps the teams with agile coaching.

• Number of sub-teamsThe stakeholders discuss the internal structure of the team. If the project is too big, sub-teams may be created to keep the size of each team below ten. As of now, none of the agile projects have had to have multiple sub-teams.

Project type and execution

These parameters, in addition to the ones specified earlier, help apply agile to situations where it will yield advantageous results for the organization compared to other methodologies. During the conversation stakeholders assess the project type and try to identify the benefits expected by using Scrum and agile in the project.

• Type of project and Need for changeIn our organization, we encourage use of agile for projects for significant enhancements, entirely new development and initial prototyping of a new concept. These projects are considered more suitable as they typically have an initial scope to start with, which can be refined over a period of time. Projects that are of production support (continuously changing scope – that cannot be controlled) and minor enhancements (having very low effort estimate) are not encouraged.
  
  The stakeholders also discuss the need for scope change in the projects and how agile will benefit the customer in such a situation. In cases where the scope is more or less understood and not much change is expected, the project could be executed in iterations. And in other situations, the scope can evolve as the project progresses making agile more suitable for the project.

• Project durationContrary to the perception of many people, agile works best when the duration of the project spans multiple months. Such duration provides the team an opportunity to inspect and adapt their ways of working. It also provides the customer an opportunity to get the most value through regular reviews of the functionality delivered.

• Mission criticalityThe stakeholders deliberate whether or not the requirements of the project have any tolerance for defects. In the ideal world, the team should deliver defect-free product at the end of each sprint. However, in the practical world of agile, the product evolves over time and there is always scope for perfecting the product over time. There are some exceptions though where there is no room for errors, in the delivered product – examples include life-critical healthcare applications, really expensive applications (like ones used in space programs) and so on. Having executed agile projects in such situations ourselves, we do not say that agile cannot or should not be applied in such situations. We say that in such situations, it is important to realize that quality needs to be given a prime importance and extra measures need to be put in place to validate the product before its Deployment.

• Resource availability for Sprint zeroIn our organization, we execute a sprint zero (we call it the formation sprint) for each agile project to build an initial product backlog and do the groundwork for executing the project such as plan number of iterations, set up the initial infrastructure and prepare a statement of work. To execute the sprint zero properly, it is necessary that the resources needed are made available. This means allocating key team members to the project and making the necessary hardware, software and tools available to them.

Conclusion

Agile and Scrum can be applied to vast variety of projects and situations. To execute projects well using agile, the need for collaboration and understanding between the customer/business and the delivery organization cannot be underscored. Basic preparations are needed in this regard and this conversation goes a long way in ensuring that happens.