Modernization: Preparing the team

So far in this series I have established that the following are all necessary components of the modernization project planning process:

• code bases that will provide value when modernized to a future state

• a team that can effectively work in that enterprise environment

• all the information the team needs to start a brief onboarding course so team members are empowered and enabled to work

• a place to track work progress that teams outside of the product team can review if they have questions

At last, you’re ready to start building the team. However, there are some small things you can put in place to help reduce the team’s learning curve and help them work well together.

Project onboarding

A complex migration across a portfolio of applications will take some time. During the project, attrition will happen either by choice (people will want a break), by design (cycling out expensive external resources), or by staff changes.

Materials must be available so new team members can get up to speed quickly while having key information that allows them to fit in with the team.

While documentation is essential for knowledge transfer, there are a few things to bear in mind when creating documentation for development teams:

• Make sure the documentation is specific, sufficient and succinct.

• Do not presume that everyone has read everything.

• Interactive sessions can be very effective at reinforcing pertinent information.

Build the right kind of training

When you review the current and future states of the technology, experts should be established in both areas. Following the review, the Project Lead and Wise Sage (these concepts were introduced in this article) should work with these experts to put together clear and concise onboarding training which should cover the following:

• the value this modernization project provides to the enterprise

• a quick summary of what the application does

• relevant technical details around

  • the application’s current state (this will vary based on the modernization goal) 

  • the desired future state for the code/configuration/runtime

• enterprise-specific things a developer might need to know to start working (e.g., active directory groups required to use tools, links to open support tickets, etc.)

• subject matter experts to engage with questions

• a quick review of the storyboard (see below)

• an overview of the Developer Contribution Guide (see below)

• the tone of how the team will work under the direction of the Project Lead

This content could be packaged or consumed as a Confluence/Wiki/README page, but people don’t always read this sort of documentation. You could also try recording a whiteboard session where the concepts are explained. Or, if you have the right platform, create a brief self-service training class. Maybe there could be a short 1:1 session with the Project Lead and new team members after they have consumed the materials to make sure everything is clear.

Whichever you choose, it’s key to not to go overboard. There is no need to hire a team to build this or invest in expensive training software. This is the type of thing the Project Lead and Wise Sage can put together in a few hours and team members can consume in an hour or less.

As a side note, this process can also help flush out bad actors. If the Project Lead and a new team member are butting heads during this process, this could be the right time to reconsider that member’s place on the team.

Establishing technical principles and practices

When it comes to technical execution, everyone might have a slightly different way of doing things. Sometimes having some guidance up front on how code can be written will not only result in new resources getting up to speed easier, but will reduce disagreements and conflicting options.

I was once on a product team where the branching strategy for the code was not defined. Rather than just pick something and move on, we decided to settle this as a group. It ended up turning into a religious debate that spanned multiple meetings, over multiple hours, and ended up with a developer leaving the project in frustration. Establishing this up front would have saved a lot of time. Those who resist can simply choose not to join the project in the first place.

Create a developer contribution guide

Building on the last point, the Project Lead needs to sit down and create a developer contribution guide. This should cover as many decision points as possible without stifling creativity too much.

Examples of things to cover include:

• branching strategy

• process for pull requests

• basic naming conventions for methods and test cases

• security strategy (perhaps include some config)

• configuration style (i.e., YAML files which include the environment name)

Good reference material for a contribution guide include the book Refactoring by Martin Fowler which provides excellent guidance on improving an existing code base and, for pure coding standards, Clean Code and Effective Java outline excellent practices teams can follow. 

Here is an example of a coding guide by Google: Google Java Style Guide.

Tracking work and communicating progress

Things are starting to fall into place. But there is one thing still missing: a place to keep track of what's getting done, how it aligns to value and when it will be completed.

This is key to make sure things get done, and also to communicate progress to different personas across the enterprise. But beware. People who are not part of the project can potentially derail it from the sidelines if they feel it's not going in the right direction.

A “story” tracking board is required at this point. There are plenty on the market (e.g., Jira, Trello, Monday) and the enterprise most likely already has one. The product does not matter provided it supports breaking larger goals down into manageable tasks that can be delegated and tracked.

Atlassian explains this really well using the concepts of stories, epics and initiatives. Here is a simple summary, starting from the developer task level and moving up to the level of The Client.

• Story: Short requirements or requests written from an end user’s perspective of what needs to be built and how to prove/test that the work was successfully completed.

• Epic: Stories logically grouped together into a larger body of work for the team to deliver.

• Initiative: Epics grouped together that have a common goal of adding a specific business value to the users of the application or those operating the application.

A benefit of breaking up the work in this way and publishing it in a tool teams can access (e.g., Jira) is that personas from other silos can have insight into what is going on. In an enterprise environment, there are different personas who can affect the outcome of a software project. Excluding members of these teams could later result in project derailment or slowdown. 

Sometimes this form of access alone can reduce status meetings and stand ups (all of which consume valuable working time). It also provides a record of what the team has committed to, which can come in handy should there be questions or issues around the team's priorities from silos that have not been involved with the project but can affect the outcome (e.g., audit and governance).

Managing changes in the path

Any changes to this structure (initiatives and timeframes) need to have the input of the Project Lead and be validated by the Client. If problems arise (e.g., unrealistic timelines or scope changes that require difficult-to-obtain resources in the enterprise), the Sponsor will need to step in to help resolve the issue.

In the next article, I'll get into some code refactoring strategies in more detail.