It is time for our seventh episode of Interviews with Agilists. In this episode, our guest is Dmitriy Nefëdov, head of the Project Management Office at Magora Systems, an international IT company with extensive experience in IT outsourcing.
Dimitriy and his team of 60+ developers (Back-end Developers, Front-end Developers, iOS Developers, Android Developers, QA Engineers) and 8+ Project Managers work on different kinds of projects. Most of their projects are complex bespoke web and mobile b2b or b2c software. Some of his latest projects were social media apps, a safety alerting app for the construction industry, a restaurant POS system. An average team that works on one project consists of 5 to 12 members.
This is Dimitriy’s Agile story.
Q: What is your role in the team?
A: It always depends on the project, the client's involvement, and expertise required for the best outcome. We are always here to help our customers whether there is a need to fulfill either a classic waterfall approach or a new classic agile of Scrum, Kanban, or hybrid. If we speak of the majority of the project I would define the role as "Project Manager + Scrum Master".
Q: Is your team on-site or is it a distributed team?
A: At Magora we work with both on-site and distributed teams.
Q: It is not an easy task for a large team to stay synchronized, especially for a distributed team. How do you cope with this challenge?
A: To keep everyone in sync we use a certain set of tools and activities that help to keep everyone on the same page not only within a single team but company-wide as well.
If we speak of the team work on a specific project then the toolset is almost always to include the following:
- Daily stand-up meetings
- Planning sessions
- Brainstorming sessions
- Internal demos
- Ongoing Slack communications with a separated and topic-dedicated channels
I personally profess an ideology of complete transparency and visibility by which I mean that since a team is dedicated to one cause everybody needs to know what happens and see what their teammates and customer do. I always include a whole team CC'ed to the project related email threads with a customer. Thus everybody sees and knows what was conveyed to a customer, what were the replies and why we came to a certain decision. Everybody is free to ask, discuss, disagree, suggest what they believe is right for the common good.
If we speak of the company and all the other teams we have, we always encourage knowledge sharing. For that, we always hold meet-ups and do project presentations to let everybody share their experience and news of what the teams are working on, how great what they do is, what obstacles they are facing, how they are dealing with issues, which solutions were implemented to achieve the goals client and us are having for a project. It is truly motivating and inspiring.
Q: When did your Agile journey begin? To be precise, when did you start practicing Scrum within the teams in your company and what was the implementation like?
A: For my team, it all started three years ago. At that time we got an innovative social media app project which was born to be developed in an agile way.
We started by introducing the basics of Scrum framework with two weeks iterations and correct role assignments. With the evolution of the project and its team, we were continuously evaluating what we had been doing and how we could do it better. Thus we came to either keeping the canonical Scrum for some period of time or shifting to more of a hybrid approach at some points.
Q: What was the biggest challenge your team experienced during “the transition phase”?
A: The key challenge was to educate our customers and explain the values and benefits the agile approach was offering. There were always the attempts to change the sprint scope or timings midways, and it took additional effort for me to once again explain and persuade the decision makers that how we do it is not less important than what we do.
Q: Have you incorporated any practices from other agile frameworks in order to adjust Scrum to your workflow?
A: Mostly lean and design thinking were the ones we incorporated.
Q: Do you use any additional techniques such as TDD, BDD, etc. in the development process?
A: Yes, we use Unit testing, Test-driven development (TDD), Continuous integration, Behavior-driven development (BDD), Pair programming. The positive effects are:
- The increased speed of delivery while maintaining the high quality of the code and end-user functionality implemented
- Less detached QA effort
Q: Do you have a template for writing user stories?
A: We do use a combination of a flow diagram, 'As a ____, I can ____ so that ____' template, and Business Rules description.
Q: And how does your Definition of done look like?
The DoD is different for each project and depends on what is being evaluated as Done:
- Feature (user story or product backlog item)
- Sprint (collection of features developed within a sprint)
- Milestone (potentially shippable state, fewer requirements)
- Release (potentially shippable state, full requirements)
To give an example, please see below a template for a feature DoD:
- Unit tests are ready, XX% covered
- The acceptance criteria are added to the compliance matrix
- Acceptance tests are associated with acceptance criteria in the matrix
- Acceptance criteria met
- Conducted integration testing
- Regression tests are prepared
- Regression tests are automated by 80%
- Tested functionality does not contain Blocker, Critical bugs
- The issue ticket is closed in the task tracking system
- Latest description added to the SRS
Q: Does your team estimate tasks? Any advice on how to avoid situations like underestimating or overestimating tasks?
A: Yes, we do. There is always a room for some unclarity or emergency along the way. To mitigate any of such risks there is always a risk time added to estimates of a task that is most likely to consume more time if it plays out wrong.
A good way to stay balanced in giving the correct estimates is to make it within a transparent planning session with a planning poker if possible. Thus any of the team members can ask for or even provide you with the clarification on how much the task could actually take with a sensible justification behind it. With this in place, the team is building mutual trust and aid the common goal achievement.
Also depending on the project and the pricing model we either do the estimates in hours or story points, both of which have their pros and cons.
Q: How do you track the progress of your project?
A: We use Sprint Burndown and Cumulative flow charts. Along with that since we almost always have the budgets limited, all of our Project Managers keep track of expenditures and current balance, making a comparison on how well the team is delivering the results.
Q: Which Scrum events do you conduct?
A: We conduct all events (Daily Scrum, Sprint Planning, Sprint Review, Sprint Retrospective, Backlog Grooming). The minimum is the dev team and Project Manager - if they perform a hybrid role -, however, we always invite the stakeholders to take part in most of the activities. If there is a limited availability for the stakeholders, the 'must' minimum are the Sprint Planning, Demo and Retrospective, Backlog Grooming.
Q: When can you say: “Well this Sprint Planning meeting was a success!”?
A: First, the estimated Sprint scope should comply with the capacity and velocity of the team, leaving a slight room for risks playing out.
Second, the team confirms that the Sprint Plan is achievable and matches everybody's understanding of how and when the increments are to be delivered.
Third, the daily midway check-ups indicate that we are moving at the right pace, or if the risks played out, we evaluate how the buffer reduced the delivery flaws.
Q: Is there anything you would like to share about your Sprint Retrospectives?
A: Prior to each Retrospective meeting there is an anonymous form available for filling in, where every team member could share their thoughts on what went well and what should be done differently next time.
The key focus is to reveal any flaws in the process or team actions that may or have affected the increments delivery.
Each comment given in the form or voiced at the meeting is being logged to the Retrospective MOM with a suggested solution in a SMART way.
Q: When it comes to your team, what are the most important benefits of using Scrum?
A: The transparency and visibility for everybody involved. The team begins to feel and profess the idea of mutual responsibility for the results delivered and that every personal input and effort matters a great deal. The communications become precise and swift, the teamwork itself gets more consistent and everybody is more likely to run an extra mile when they feel they can. All the above-mentioned results in the better result delivered in shorter time frames.
Q: Are you satisfied with the effect of Scrum on your team’s productivity? Is there a way to measure the change?
A: It has brought more joy and satisfaction with how we do things and with the quality of the products we deliver to our customers.
As for how to measure it, I would say that by Burndown and Cumulative flow charts dynamics analysis and Estimated Plan/Spent Fact comparison I can get the quantitative data, while through customer care interviews and the team feedbacks at retrospectives the valuable qualitative side of things is revealed.
Q: How has Scrum affected the quality of the products you make?
A: From the customers perspective, it did great in terms of visibility of how we are getting to the desired results and what helps most. The customers have more options to be there with the team and get their hands on the product that gets better shaped with each Sprint.
The personal dedication and responsibility, mutual support and integrity made the team focus on the results more than on giving the right estimates. As the result, we see faster-delivered and better-tested deliverables by the end of each Sprint.
Q: Let’s not forget about the clients. Has the collaboration changed since you are practicing Scrum?
A: Scrum provided us with more tools to engage the clients with the product we are working. When they start taking part in the activities we have, have access to the tools we use, they understand the whole picture and the value of their input for the end-result of our work.
Q: Was there ever a time when you thought that Scrum was not a good solution for your team?
A: I would say that it is hard to find such a case. The only time it turned out to be not a good solution was not about the framework itself, but about the way people tried to implement it - just for the sake of formality.
If you'd like to share your Agile story on the VivifyScrum blog, click the button below to find the interview.
Disclaimer: The interview has been edited for clarity and style.