The way we do it
How do we actually work
Applications and software have become a blood stream of todays businesses.
Software development is the heart that brings life to your business initiatives, while individual developer’s competences and efficiency are the heart of the software development process.
Our teams will work hard to help create the first prototype and then continue to implement the entire solution, including the associated continuous integration and delivery pipelines.
From start to finish
We’ve got you covered
Getting the right balance of agility and operational stability
Technically strong multidisciplinary teams
Much more than just a pair of developer hands with technical knowledge
Strengthening, stretching, balance, and aerobic exercises are the very foundation for sports, while individual developer’s competences and efficiency are the heart of the software development process.
Capability to develop software is key to good health of your organization, just as general fitness level is key to your physical health.
It starts from the heart
But it’s all about the team
When times are tough, we know who we can rely on – the people in our inner circle. In the software industry, the circle is also known as the inner loop, and is about the team, making architectural decisions, choosing branching strategies, sharing knowledge and code ownership, developing systems that are test and automation friendly.
Software teams, just like teams of athletes, call for cohesion, communication, and collaboration, it is just that software teams deal with more abstract equivalents of ‘dropping the ball’ – development speed, system’s maintainability, performance, scalability, just to mention a few with long-term consequences.
It is widely demonstrated that playing at home generates an advantage for the local sports team. In fact, clubs have become community assets due to the atmosphere that comes from the crowd and that adds the extra special thing to an event. Software development has a crowd of its own – the users using their applications, the systems running their software and business stakeholders supporting their endeavors – that is part of the outer loop.
The outer loop deals with developing an efficient mechanism for deploying software artifacts on-premises or in the cloud on a regular basis. Continuous integration and delivery, especially when fully automated, provides critical feedback to the development team, allowing them to learn what works and what needs to be changed or addressed. All stakeholders will have a clear picture of the current state of the developing system.
No feedback without CI/CD
Begin by identifying broad concepts and represent the ideas using Azure DevOps work items: Epics and Features. While the business and development teams continue to cooperate by adding more details and producing user stories, the tool will keep track of all discussions and attachments, as well as the whole history of changes.
To estimate the work, story points, an example of a relative measure, are used. We usually make them just precise enough to help us decide what to include in the increment and what to split… During planning sessions, business stakeholders can use Excel to analyze and perform quick what-if calculations. After that, the winning scenario is ‘published’ to Azure DevOps.
Azure DevOps iteration backlog is used to break user stories into tasks, further discuss and estimate the work to do during the iteration. The team commits to complete the stories at the beginning of the iteration which typically takes 2-3 weeks.
The team delivers a working software at the end of each iteration. We use Azure DevOps repositories and pipelines to automate integration and delivery from day 1.
We keep the backlog and estimates up to date continuously. This enables us to use charts such as ‘story points per iteration’ and ‘product increment burndown’ from Azure DevOps dashboards. As a result, project finish date is forecasted with engineering confidence.
We use Azure DevOps visual boards instead of post-it notes to track work in progress. The boards are Kanban-style with four columns – New, Active, Resolved, Closed – which is adapted when needed.
The team is focused on stories assigned to the iteration. In addition, iteration stories are ordered by priority so that the most important stories are put at the top. Priority, together with card colors and tag colors, help the team members to know which tasks should be completed first.
Ideally, each team member works on no more than one task at a time, so we set work in progress limit for Active column to be the same as number of people in the team.
Our process does not require the team to have a certain number of members, nor does it require members of certain roles. However, we’ve found it very important for the team to have a senior developer in a team lead role to facilitate the communication and to keep an eye on architecture, review pull requests etc.
Tasks are not assigned to team members by project manager or up-front. Instead, each team member chooses tasks to complete next and coordinates with the team during daily meetings.
We don’t expect every team member to be able to do every task alone. On the contrary, we encourage knowledge exchange which also happens when two devs work together.