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.
Modernization series
저자 소개
Luke Shannon has 20+ years of experience of getting software running in enterprise environments. He started his IT career creating virtual agents for companies such as Ford Motor Company and Coca-Cola. He has also worked in a variety of software environments - particularly financial enterprises - and has experience that ranges from creating ETL jobs for custom reports with Jaspersoft to advancing PCF and Spring Framework adoption in Pivotal. In 2018, Shannon co-founded Phlyt, a cloud-native software consulting company with the goal of helping enterprises better use cloud platforms. In 2021, Shannon and team Phlyt joined Red Hat.
채널별 검색
오토메이션
기술, 팀, 인프라를 위한 IT 자동화 최신 동향
인공지능
고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트
오픈 하이브리드 클라우드
하이브리드 클라우드로 더욱 유연한 미래를 구축하는 방법을 알아보세요
보안
환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보
엣지 컴퓨팅
엣지에서의 운영을 단순화하는 플랫폼 업데이트
인프라
세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보
애플리케이션
복잡한 애플리케이션에 대한 솔루션 더 보기
오리지널 쇼
엔터프라이즈 기술 분야의 제작자와 리더가 전하는 흥미로운 스토리
제품
- Red Hat Enterprise Linux
- Red Hat OpenShift Enterprise
- Red Hat Ansible Automation Platform
- 클라우드 서비스
- 모든 제품 보기
툴
체험, 구매 & 영업
커뮤니케이션
Red Hat 소개
Red Hat은 Linux, 클라우드, 컨테이너, 쿠버네티스 등을 포함한 글로벌 엔터프라이즈 오픈소스 솔루션 공급업체입니다. Red Hat은 코어 데이터센터에서 네트워크 엣지에 이르기까지 다양한 플랫폼과 환경에서 기업의 업무 편의성을 높여 주는 강화된 기능의 솔루션을 제공합니다.