There has been a huge amount of research and development into how teams are formed to tackle software projects. There are different versions of these new teams; some practice Scrum, some use Kanban, and the word Agile is thrown around a lot!
Most of these methodologies we know today were formed as a response to a high failure rate among software teams. The Standish Group’s 1994 report titled the Chaos report famously recorded that a mere 16.2 percent of software projects were being completed on-time and in-budget. This led to a number of new and innovative ways of looking at the development process, including Scrum in 1995 and extreme programming in 1996.
Generally, these techniques are now collectively described as Agile methodologies because they all hold similar values: Putting teams first and ensuring that they can respond to the changes which occur during the development process rather than following a rigid plan.
Agile methodologies can bring huge benefits to teams that adopt them. Teams work more collaboratively, which leads to better solutions and an end product that is far more likely to meet the users needs, and the receiving of positive feedback and criticism can lead to an increase in motivation among team members.
However, one thing that can often be missed when an Agile methodology is adopted is a high-level, or strategic, plan. Without a strategic plan the team can start to get off track, focusing on things that are not the most important to the business or missing things that are. Or the team can lose its sense of achievement after completing sprints or milestones if the flow of work feels like it just keeps coming.
I am certainly not proposing that we do away with Agile, but I think there is a stage of planning within our Agile processes that we often miss: the strategic, or long-term, plan. By incorporating a collective strategic plan into the Agile process, we can help mitigate the risk of getting off track or losing motivation within our development teams.
The Strategic Plan
A strategic plan is a very high-level summary of what the goals and expectations are for a business over a long term. Good strategic planning should cover a wide breadth without going into unnecessary detail—it should be as lean as possible.
The main aims of strategic plans are to develop a shared understanding, dispelling any false assumptions people might hold, and to identify goals, priorities, and stakeholders. As such it feeds perfectly into the other Agile processes, for example, sprint planning.
In addition to being lean, it should be iterative. When I first came across strategic planning, I thought it went against the principles of the Agile Manifesto: It seemed pointless to spend time planning when Agile is designed to be flexible for when plans inevitably change.
But the strategic plan is neither a guide nor a contract for the project; it’s an abstract summary, and hence it should have the same flexibility that the rest of the project’s assets have. The plan should be revisited periodically to see how the vision, priorities, and goals have changed.
It is important to keep the strategic plan actionable. The actions that this plan will lead to will be different for each member of the team. Forcing the alignment of stakeholders, driving development, or sparking cross-department collaboration are a few examples of the actions that should come out of a good strategic plan.
A really helpful tool in realizing strategic planning in your teams is the project roadmap.
The Project Roadmap
A roadmap details the journey a team or business wants to take in the coming months or years. Roadmaps can be created for specific products or projects but are just as effective when looking at the business as a whole.
They focus on defining goals or ambitions. This helps gain a shared understanding of what the expected outcomes should be over a period of time. Additionally, within the roadmap, large problems are broken down into milestones. This helps with the prioritization and organization of tasks.
In order to create valuable strategic plans and roadmaps, it is important to gather as many ideas and perspectives as possible. That’s where the cross-functional team comes in.
Cross-Functional Teams
A cross-functional team is exactly as it sounds: a team of people who normally perform different functions, or roles, within the company. Teams can include software developers, managers, designers, marketing specialists, or customer service representatives. The value comes from having many different perspectives and sets of experience.
It is important that during meetings everyone’s input is sought because each individual will be able to approach the problem in a unique way. Since the development process iterates through each of the roles in a company, so should the strategic plan. To make sure that everyone is given the opportunity to contribute, each functional group should be given time to conduct, where they will receive information from others, and to participate, where they will provide information and insight. This ensures that the plan is multifaceted, meaning that it will be more comprehensive and all-encompassing than a plan that is focused on a single agenda.
Ingredients of a Strategic Plan
When conducting a strategic planning session with your cross-functional team, there are five stages that can be helpful to look at:
Goals and Success Factors
Goals, or expectations, are things that your business wants to achieve: the ideal state of your products or services. They will not necessarily be specific to the end customer, but rather they should consider the business as a whole.
It can be helpful to break each goal into smaller chunks of work. One way of doing this is by looking at it from the perspective of each department or function within the team. Each function will have a different set of actions to contribute to the team so it can realize its goal.
Along with goals, success factors should be written. Success factors are metrics or observations that will indicate whether the goal has been achieved or not. These will be specific to the goals that they intend to evaluate and can be different for each member of the team. It is important that success factors not be like contracts; they should not have set estimations at this stage. Instead, the success factors should identify metrics that can be used to tell whether a goal has been achieved.
An example goal might be to develop better customer engagement with a specific persona, or type of customer. This goal is very vague but can be broken down into some tasks.
Designers can investigate how the look and feel can be improved to suit the customer, customer support can evaluate how they can better advise or guide them, and the technical team can introduce new features that meet their needs. An obvious success factor would be to evaluate the sale or use of the products/services for this type of customer.
Stakeholders, Customers, and Transactions
Stakeholders are the people, or groups of people, whose input must be sought when realizing a goal. During strategic planning, stakeholders should be identified by analyzing who needs to be involved in the process of realizing the goal. The identification of stakeholders is one of the most important stages of a strategic plan, because goals cannot be met without working collaboratively with all parties who are invested in the outcome.
When identifying stakeholders it is important to note their relationship to the goal so that everyone understands who is responsible for each part of the process. Additionally, the whole team should know who the stakeholders are when working together on a goal so that each team member knows who they should be reporting to or receiving input from.
Some stakeholders will be involved only in certain stages: Some will be leaders, while others will be relied upon by the rest of the team. The business should aim to reach a shared understanding of the goal among all the stakeholders.
Customers and transactions go together; the customers are the end users, and the transactions are any exchange that must occur between the business and those end users. If the customer is identified early, then it makes it easier to ensure that the product or service is being designed and developed according to the correct user needs. Identifying transactions can also prompt discussion on the infrastructure from the perspective of both technical and people management.
Coming back to the customer engagement example, stakeholders could include teams of software developers, designers, and customer support as well as some members of management. The customers will be the persona that is being targeted, and the transactions will be the marketing of the product or service and the ongoing engagement between the business and customer.
Architecture and Infrastructure
This stage will carry a different weight, depending on the goal. It involves evaluating any changes that will need to be made to the existing architecture or infrastructure to ensure the goal is successful. This incorporates both technical and business infrastructure, so it can include things like data storage or members of staff.
A lot of projects fail, or are delayed, because the infrastructure is not evaluated early enough in the process, so it is an essential stage in the formation of a strategic plan.
In our example goal, the system might need to be upscaled to cope with higher throughput or data collection. Also, the customer support team may need to be enlarged or provided with some training.
Priorities and Challenges
Goals should be prioritized so that there is a shared understanding of what is most important to the business. This discussion can often be difficult because different team members may have differing opinions on the prioritization of goals. Ultimately, the important part of this stage is having a shared understanding of what order the goals should take when starting development.
The challenges that may be faced when reaching a goal are mostly unknown at this stage; however, there are often common challenges that can be foreseen. By discussing possible challenges the team may be prompted to perform further research or training, change the development process when tackling specific parts of the goal, or seek consultation with experts.
A challenge that might be faced in the customer engagement goal is a misunderstanding of the needs of the target customer. This could be mitigated by performing research and requirements elicitation.
Release and End Users
This is another step that is multifaceted. There can be a technical release or deployment that occurs throughout the process, a business release when new features or products become accessible to users, and marketing releases when the attention of potential customers is sought. Some goals suit an incremental release if they can be easily broken down into parts that work independently.
As well as the release, it is important to figure out how the goal will be evaluated with regard to the end users. This might be different from the success factors mentioned above; it aims to find out if the end users are engaging with the new product or service well. A powerful technique to use for this is A/B testing.
The example goal would likely involve multiple releases, including a few new features and design changes. Using A/B testing the team could evaluate how the target customer is engaging with the new content in relation to the old content.
Add Strategic Planning to Your Agile Development Process
Agile development methodologies are great at helping us achieve our goals. However, if they are not paired with effective and collaborative strategic planning, then they can often lead to our getting off track or losing motivation. It is really easy to incorporate strategic planning into an Agile development process by using cross-functional teams and roadmaps.
Published on Java Code Geeks with permission by Timothy Ness, partner at our JCG program. See the original article here: The Role of Roadmapping and Strategic Planning in Agile Project Teams Opinions expressed by Java Code Geeks contributors are their own. |
