Staffing the first team
Product Owner
Everything starts with an idea. A good rule of thumb is that there's a problem significant enough that it is worth solving. Before coding even a single line of code, make a hypothesis of the possible solution. Then validate it as fast as possible. For example Lean Startup practices might serve you in doing this. Having a Product Owner (PO) might be a good idea. PO can start collecting potential product feature ideas and requirements into a Product Backlog.Architect
When you are pretty sure that you have an idea worth implementing and you start creating a team, maybe the first person to recruit is the architect. Someone who will have an overall technical vision about structure of the solution.Coders
Next you probably want to add a few more coders to speed up the development. In the early phase of the product lifecycle it's tempting to divide the responsibilities so that there's a single person responsible for a part, but I would advise against doing so. It will limit the shared code ownership and most probably create bottlenecks. All parts of codebase should be familiar to more than one person.Design and testing
Depending a bit on the case, next I would get a designer or a tester. If the solution needs to be operated by a user, I'd go with designer. If most of the magic happens in the backend and no-one cares how butt-ugly the product is, then first concentrate on making sure things work. Don't get a tester, but a person who is familiar with testing and can create automated tests. But testers think differently than coders, so better get one onboard.Now you probably have quite standard software development team. Either get someone who has prior knowledge about agile software development to act as scrum/kanban master or select a person from the team that is most interested to learn the topic. With the help of this person the team will start an exodus to become a self-managing, self-organising cross-functional team that turns Product Backlog items into working software.
Scaling up
Splitting
Natural way to scale is to increase the team size by recruiting more and more coders and maybe domain experts. Once the team is so big that regular meetings like daily scrum are no longer efficient, it's time to start thinking about how to split the team.When you split the team, think carefully how the new teams divide the responsibilities. Let the tech people decide what suits them best. When you have the second team, make sure that also contains all needed competences, including test automation.
Centralized competences
Some roles might not be needed full time in the development teams. It might make sense to centralize these to a different team that can support multiple dev teams. Architecture and design can be such skills that they can be in a common team.When the work is divided between multiple teams it is also a sign that your operations need to raise to a new level of professionalism. It is a good idea to recruit someone to take ownership for the documentation. Security is also more important and maybe worth having someone concentrating on it. And since there are multiple teams (possibly) working on the same codebase, someone should spend a bit more time on setting up proper integration and deployment practice. Also it is worth thinking about how the teams coordinate and synchronize their work. Some scaling framework could be beneficial. For me Scaled Agile Framework is the most familiar. It also provides guidance on how to plan and execute things when you have multiple teams and also implement continuous improvement.
Get going
When you have recruited people to fill more than one development team and staffed another team has some centralized capabilities, it is time to plan how you shift the gear. This part requires a bit more effort on planning and discussion. I find it practical to have a person write down instructions that offer not too much, but enough details about how the new setup works. Then it is time to just agree on starting day and get going. Execute the initial plan, stop to reflect how did it go, adjust and repeat. That's how iterative and incremental practices work.Tools
There are some tools that have become almost industry standard for supporting agile software development. Some tools have a lot of different features integrated to them and can handle a big part of the development pipeline. But I will give here an example of pretty traditional setup.
Backlog handling
For handling the Product Backlog, a pretty easy choice is Atlassian Jira. You can create and prioritise backlog items, track bugs and follow progress. If you are using Scrum, Jira offers possibilities for having burn down charts for your sprints. You can also easily visualise the workflow with kanban board and customize the columns to reflect your development process steps (like coding, code review, testing, etc.)Version Control
The only version control tool that I would recommend is Git. There are multiple commercial tools that you can use that offer different additional benefits. Here are a few: GitHub, BitBucket, GitLab. Access rights control to the source code is probably the main thing, but maybe next in line is the possibility to use pull requests. Instead of pushing things straight to master you should consider a workflow that fosters shared code ownership and transparency. Code should be reviewed by someone else than the writer before merging.Continuous Integration
Some Continuous Integration (CI) system will help you to automate your process. If the code needs to be compiled, the system will do it. In addition it can start the execution of automated tests, usually starting with unit tests. Some examples of CI systems are Jenkins, Drone, Bamboo, CircleCI, TeamCity and Travis.Static Code Analysis
For static assessment of your codebase quality I would recommend adding a tool like SonarQube to your pipeline. It can help you measure how readable your code is and how good your test automation harness is. It will cover also security vulnerabilities.Deployment
Then you probably need some place to deploy your solution. Either you invest in hardware or you use cloud services. The most common public cloud platforms are AWS, Azure and Google Cloud. If you are using containers, you can orchestrate them with Kubernetes. If you can spend a bit more bucks, you can use an enterprise solution like OpenShift.Documentation
Quite a standard way to build and maintain living documentation is through Confluence. Pages have version control and editing is very similar as in Wikipedia. They can be exported in multiple formats, such as pdf, word or html.Possible pitfalls
Recruitment
If creating awesome applications and products that users love would be easy, everyone would do it. But it's not so simple. For starters, there's a shortage of skilled workforce. This means that people who know the craft also know their value. And since the whole world is getting digital, there are lots of companies that are willing and able to fight for the talent and offer high salaries and different perks. So, even if you can recruit a team, you might lose members because some other company 'buys them out'.
Culture
Another thing to understand is that the results that an organisation is able to produce are a lot more dependent on how well the people work together than how good the individuals are. It doesn't mean that you can achieve great results with mediocre people. But it does mean that even with highly skilled persons you can fail miserably if they don't get along. Culture makes a huge difference. If people feel safe to show their vulnerability and admit mistakes, everyone will benefit. With retrospectives and conscious continuous improvement efforts teams and teams of teams can raise to a whole new level of performance.
Edit 1: Added some sub-headers for easier navigation of topics.
Edit 1: Added some sub-headers for easier navigation of topics.
No comments:
Post a Comment