It’s been a while since we last talked to fellow agilists as part of our series of interviews (summertime and all). We are kicking off the new season with Victor K. from SCAND, a software development company based in Belarus.
Victor is a Scrum Master and Project Manager for a cross-functional team of 20 working on outsourced software development projects. He gave us an inside look into the Agile practices of his team and how this approach helps them and their company as a whole deliver better products for their clients.
So, without any further ado…
Q: What kind of projects does your team work on?
A: The whole team works on a couple of projects simultaneously. It may look like a non-standard approach, but we are considering it as one of our challenges.
So, for now, we are working on a couple of projects related to the blockchain — Ethereum, crypto-based payments, banking software, stock front-end and back-end, etc.
These projects are all pieces of one big puzzle and, in conjunction, they should become a bleeding-edge software with crypto, anonymous orderings and payments, cryptocurrency exchange, elements of crypto-banking (without complete processing like standard banking cores), and even crypto-stock elements.
The way ahead of us is a long one but we are already making significant steps.
Q: How does your team stay synchronized with other teams in your company?
A: In addition to standard ways of communication, we use JIRA and messengers such as Skype and Telegram. There are also weekly Friday meetings that allow everyone to prepare a thesis and discuss it with members of the other teams. Also, we have Pitches — non-formal discussions regarding certain burning technical problems and ideas. If someone has a complex and far-reaching issue to discuss, pitches are a good chance to do it.
Q: When did your team start using Scrum or Kanban?
A: Many years have passed since we started using Agile for the first time. I started creating burndown charts around 7 or 8 years ago.
Q: What challenges did your team experience when transitioning to a new way of work? What was your team’s biggest impediment while implementing agile practices?
A: Once we started using Agile, we made all the mistakes imaginable. First, we tried using Agile in a dogmatic way... Fortunately, it took only a couple of weeks for us to understand that the key to success lies in its flexibility.
Thanks to that, today we can successfully adapt practices for our needs.
Because businesses typically don’t want to waste their time on “unimportant stuff”, it was a real challenge to acquire stakeholders and businesses willing to play along. Once this problem was resolved, we faced another one, stemming from the actual progress we made. Whereas before we had no adequate feedback, we now faced clients who wanted their propositions to be implemented “before yesterday”. It resulted into a 'do not touch our sprint plan until it’s finished' strategy.
A bit later, we found the right balance. As a result, for the last five years, we have been using Agile whenever possible, except in some trivial cases. In other words, these days we are comfortable with our process and our customers can witness our constant growth and progress.
Businesses are so satisfied with our work that they often delegate some parts of product ownership to us. Of course, they still participate in meetings, but instead of putting pressure on the team, they just add their propositions to the Backlog for the next planning round and, let the specialists to do their job and successfully complete engineering tasks.
Furthermore, today we are in constant contact with the end users. Direct communication with users helps us get real feedback and we are able to analyze all the use cases and point out reasons for some change.
All of these lead to better changes to the product.
Q: Have you incorporated any practices from other agile frameworks in order to adjust Scrum or Kanban to your workflow?
A: Whether we are talking about continuous integration, pull requests and code review, tests coverage — we like it all! We don’t use pair programming that often, but we definitely take advantage of it when dealing with particularly puzzling issues.
Q: Does your team use any of the techniques such as unit testing, continuous integration, pair programming and such?
A: Our favorites are:
- Unit testing
- Test-driven development (TDD)
- Behavior-driven development (BDD)
- Continuous integration
From time to time, we use other techniques such as pair programming. Nevertheless, we do not start any new (sub)project without continuous integration, code review and unit testing.
Q: Why has your team chosen these techniques and which positive effects have you noticed?
A: We use them because they are extremely practical, especially when dealing with projects bigger than 10 KLOCs (KLOC - a thousand lines of code).
Pull requests and code reviews give us hope that stupid mistakes will not get moved into master. You have to agree, there is nothing worse than having half your team punch you for a typo in the commentary.
Still, code review provides some significant benefits: it allows you to answer questions like ‘Why is this code so complicated?’ or ‘What about approach XXX?’
In other words, it allows us to find the best possible solution.
Continuous integration and delivery are really efficient — all you have to do is merge code into the proper branch and, thus, everything is deployed. We use it together with continuous deployment so that a simple push makes not only compile-time artifacts, but also updates components’ repositories, builds docker images and much more.
It is so efficient that, sometimes, our engineers do not want to make dedicated installations.
What is more, the docker image with the software inside is already configured in AWS, so you can just use it. The old-style installers are part of box products and desktop/mobile applications, and browser extensions.
We even have an internal joke about unit tests:
If your decision includes using sticks and ropes, you should have 3 types of tests: a) for ropes; b) for sticks; c) integration tests.
Actually, it is not just a joke. There were plenty of situations when it saved us! Nobody likes making real unit tests, but everybody likes having them around.
When a customer does not know what they need, we use test-driven development. First, we describe what exactly we should have: and it is definitely code (e.g. tests). Once the tests are created, stones are stabilized and we are able to build another well-formed rock.
In the case the customer knows what they need, we are dealing with user stories or “behaviors”. Thus, we have a good starting point to develop story-based pieces, show them to the customer at an early stage, before assembling it into a final code.
We are using other methods as well, but not dogmatically. We do not use them every day as we do with the aforementioned techniques.
Q: Do you have a Definition of done? How does it look like?
A: Not always, but very often. Mostly, we are using DOD and DOR. Occasionally, it might be something more formal like, ‘All priority blocker and critical tasks from backlog are completed and we have no blocker and critical issues’. Or it might be a “feeling” that the product is ready for use from the customer’s side, which may sound like, ‘No, please, do not fix all these bugs; just tell us how we can move around them’.
- The task
- must be assigned to a version or/and milestone (described in JIRA),
- should contain Epic, budget and relevant components affected,
- should be released on a specific environment and/or version,
- should meet the Acceptance Criteria, if specified.
- Unit, integration and regression tests are passed.
- Task passed manual testing
Q: Does your team estimate tasks?
A: Yes. As the result, we have Sprint Backlogs.
Q: If you estimate your tasks, how often do you underestimate or overestimate them? How do you cope with those situations? Any advice on how to avoid these situations?
A: In practice, we are dealing with three cases:
- team is very optimistic and underestimates the task;
- every developer works at his/her own pace;
- when we deal with overestimation, we have chances to do low-priority tasks from the current sprint.
The first case is the worst one. We either need to make the sprint longer (which is impossible), or drop some planned options from it. Both cases amount to planning errors. To solve such errors, we add “gaps” to the underestimated cases. Then, we use Retrospectives to correct estimates for upcoming Sprints. As the result, the issue is limited to the first Sprint only (or for cases when a new person comes to the team).
The second situation appears in case tasks are swapped. For example, the efforts of one teammate are sensitive to the efforts of another teammate, as they have swapped their tasks. In this case, we have to adjust our plans at the next Scrum Meeting if necessary.
Overestimation cases appear from time to time. Nevertheless, it means we have time to roundup underestimated tasks, and in this way, some non-dramatic overestimates can even be useful.
Unfortunately, cases of under/overestimation are still a pain.
Q: Do you use any techniques to estimate tasks?
A: Generally, estimates are imprecise almost to the point of being pointless in case they are done without research of the business area and proper discussions.
We believe that the best approach before we start making efforts is to have a discussion about the technical details and any blind spots we might anticipate. In addition to the estimation itself, it is a good practice to give thoughts as to why the required steps are to be taken over the estimated period of time.
Q: How do you track progress of your project?
A: We use the Burndown chart. Also, we use backlog visualization indicating which stories are completed, which are in progress, in QA, if there are any regressions and so on. For stakeholders, the sprint burndown chart is not important; they like spreadsheets with completed backlog tasks.
Q: What kinds of Agile meetings do you conduct? Who is present at these meetings?
A: We have created a hybrid methodology which suits us best.
We conduct Planning Sessions and Backlog refinement regularly.
Sprint Review is done a bit different than described in the Scrum Guide.
Sprint Retrospective is scheduled once every few Sprints.
The Sprint Planning/Retrospective are necessary for the Development Team, which is why we do them regularly. But because Daily Scrum is optional, we use it from time to time, usually when we need to intensify communication (e.g. for integration purposes).
Stakeholders might or might not participate in meetings of the Development Team. They are interested in demos at the end of the Sprint and they are actively participating in filling of the Backlog.
Q: When do you consider that the Sprint Planning meeting was a success and how do you achieve it?
A: When at the end of the Sprint, the team delivers what was promised (or at least a required part of the plan). At the Planning Session, the whole team considers what needs to be done and must agree on the Sprint Scope. Even if there are just a few people who have estimated their task, each team member must provide a feedback and say if the task is doable or not.
Q: What do your Sprint Retrospectives look like? What is your main focus during the Retrospective meetings, what do you look to achieve? Do you use any technique to track and remove impediments?
A: During the Sprint Retrospective, we list all the issues pointed by team members, we discuss their priorities, and then discuss them. Once we get an idea of how we can solve such issues, we assign a mentor for the task and he/she takes responsibility for reporting the status at the next Retrospective.
Q: What are the most important benefits of using Scrum when it comes to your team?
A: For the Development Team, these are laminar waves in development. It allows us avoiding situations like ‘we need this ASAP, tomorrow morning in production’. For stakeholders, it means predictable, efficient and high-quality solutions.
Q: How has Agile affected your team’s productivity? How do you measure the productivity change?
A: We can determine our productivity by the number of tasks solved and bugs found during a Sprint.
Before, 80% of our productivity was made up of “urgent demos”, “critical features to be added tomorrow” and similar stuff. As the result, product development was very slow and inefficient (in worst cases, 8 out of 10 team members were not involved in the product enhancement).
Today, 99% of productivity is dedicated to the product’s added value.
Q: How have the Agile practices affected the quality of the products you make?
A: The quality improved considerably.
What is more important, the continuous feedback we receive from clients allows us to make further improvements to quality and add only important things. It stops us from wasting time on unimportant wants. We have achieved the right direction both from our clients’ and from the development sides.
Q: Has Agile affected your collaboration with the clients? In which way?
A: It became faster and more regular. Customers see regular product growth and they involve the Development Team in collaboration with business to make their product better. In addition, we can avoid implementation of wishful requirements and, from our part, improve quality of the product by adding proposals and discussing them extensively with both business and end users.
Q: Name one or more situations when you thought that Agile wasn’t a good solution for your team. Why do you think that happened?
A: We experienced failure with Agile in the past, with some of these failures being on us and others not as much.
For us, regular collaboration is seen as the cornerstone. If we have no way to work with clients and their users regularly, if we deal with a lot of managers in the communication chain, or the chain itself works badly — it is really difficult to follow Agile practices.
By the way, the result of the Sprint should be a demo/new version. Feedback is critical to us. Sometimes, tearing down walls can be a hard thing to do.
Of course, fixed budgets and attempts to write all-inclusive product bibles before the development starts are also problems. Nevertheless, it is exactly the lack of good communication that turns any development approach into a nightmare, Agile included.
You can share your Agile story with our readers. Real people. Real stories.
Disclaimer: The interview has been edited for clarity and style.