The single biggest problem we have seen in development teams is the lack of an established philosophy and process for managing the day-to-day work of the developers and ensuring they are delivering business value. The confusion that stems from the lack of process ends up hurting the team's performance and making stakeholders.
We also see a lot of teams designing their own informal processes, not stopping to consider more established Agile methodologies because they are often deemed too complicated or "heavy". Workflows such as Scrum and Kanban, however, have been battle-tested by hundreds of thousands of development teams all over the world - they have been working in the wild for years.
At Nebulab, we believe in adopting a well established practice, trying to follow it to the letter, and only tweaking it after experience. The end result of this approach is a workflow that leans on the shoulders of giants, but also works for your unique needs and challenges. It will not only save you time, but also improve the quality and quantity of your team's output dramatically.
When it comes to Agile development, the two most popular choices are Scrum and Kanban, so let's take a look at the structure, pros and cons of each methodology.
In Scrum, the most important concept is the sprint, a fixed-length iteration during which the team commits to delivering a certain amount of work. The content of the sprint is defined upfront along with business stakeholders (represented by a Product Owner), the Scrum Master and the development team.
Estimation is central to Scrum: the development team estimates the effort required to complete each item in the sprint. The team's velocity is then judged at the end of the sprint, and the following sprint is adjusted accordingly. Scrum does not mandate an estimation technique, but a popular choice is planning poker, where every feature is estimated by the entire team.
The focus on velocity and the separation of responsibilities provide transparency to business stakeholders and protect the development team from scope creep and unreasonable expectations. This makes Scrum an excellent choice in large projects, as the process ensures business goals are respected but executed in a way that is sustainable for the developers in the long term.
On the other hand, Scrum creates a lot of overhead, requiring you to designate a Product Owner and a Scrum Master, and to plan for all the Scrum ceremonies. This can be very taxing for small companies, where resources are limited and there is an absolute focus on delivering business value with the smallest possible cost. Scrum also makes it harder to work in environments where priorities are constantly changing, such as a startup that needs to quickly incorporate and validate assumptions.
Kanban is a methodology for managing human processes first introduced by Toyota in their assembly line. In a Kanban project, there are no sprints, only a continuous flow of features that are constantly being defined and prioritized by business stakeholders and/or the development team. The development team then simply picks and executes on the next item in the backlog.
Contrary to Scrum, there is no designated Product Owner or "Kanban Master": the entire team owns the kanban board and is collectively responsible for ensuring the process is being followed. There is also no estimation involved - instead, the team defines the maximum number of items that can be in each column/status of the kanban board. If a column contains too many items, then the team must work on freeing up the column before new work can be started.
Kanban can be adopted without too much overhead, and the way it requires team members to collaborate can make it the perfect option for tight teams that run high on confidence but low on time. The focus is entirely on getting things done as quickly as possible, eliminating all ceremonies that do not directly help achieve the end result.
However, Kanban also provides less transparency into team velocity and delivery dates than Scrum. This can be hard to digest for business stakeholders, especially in large and established organizations where a high level of planning and estimation is required for coordination and budgeting.
How we do Agile
If you are already using an Agile methodology, we will use that as a starting point. If not, we will coach you and your team on Agile principles and practices and the value Agile can create for your business. We will go over your current process or lack thereof, identifying issues and lost opportunities, and choose the best methodology for your organization.
We will follow the process for a defined trial period, then we'll discuss what went well, what didn't and how we can do better moving forward. The output of this discussion is a list of improvements that can be applied to the process. At this point, the trial begins again.
This tight feedback loop ensures that no inefficiency goes unnoticed. In the end, you will have a development process that works for you and supercharges your productivity!