Our Agile interview with Vivifyscrum

One of our Project Managers, Kate Witko has recently had an interview with brilliant Vivifyscrum about the Agile methodology implemented in our company. They discussed the reasons why we turned Agile, the challenges we have met during this transition and the benefits coming from the methodology. You can find the full interview

This week’s Interview with Agilists features Kate Witko from HeadChannel, a London-based bespoke software development company. Kate is the PMO Manager at her company, splitting her time between the Project Management Office and individual projects.

She is currently working on a project where she plays a dual role of Scrum Master and Project Manager. Besides her, the project involves 10 other people – business analyst, back-end and front-end developers, testers and a software architect.

In fact, it’s best that you hear about the project from Kate herself.

Q: What kind of a project does your team work on?

A: My team is currently working on a project for a brokerage and manufacturing business. The aim of the project is to create an order processing system which would not only allow purchases, sales, and invoicing to be carried out by the customer services and accounts team within the client company, but also accommodate the handling of complaints and collections, auto creation of specification documents and stock monitoring.

It also required a suite of inquiry options and bespoke reports to provide the necessary information to aid efficient running of the business.

Q: How does your team stay synchronized with other teams in your company (if there are any)?

A: Developers know each other well. They discuss various challenges among themselves. We also have a few common libraries with reusable elements used in our project. In addition, we introduced a Developers Day where they can learn what they want, work on what they choose and share knowledge with each other. From time to time there is a project demo presented to A wide R audience and the whole company can be familiarised with what each team is doing at the moment.

Q: When did your team turn to Agile?

A: We started to look at Agile methodologies about 4-5 years ago. It became more and more obvious that there is a need to allow controlling changes and scope in a more user-friendly way. Clients wanted to see the course of the project as it was developed incrementally and the Waterfall approach was not the right to stick with.

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: The first challenge was to understand the framework, roles and responsibilities. But the biggest challenge was to train the team to be a self-organising team and not to rely on a Project Manager the whole time but to take full responsibility for the project.

Educating our clients about how this will work was also a challenge but implemented successfully.

Q: Have you incorporated any practices from other agile frameworks in order to adjust Scrum or Kanban to your workflow?

A: We adopted a few XP practices, e.g. pair programming and continuous integration. We also practice unit testing.

Q: Why has your team chosen this/these techniques and which positive effects can you name?

A: Writing unit tests allows them to collect prompt feedback about their work. We strongly recommend that the developers should test their own code before passing the modules to a tester. Unit testing is a perfect fit for this.

We use pair programming in two ways:

• when we train juniors
• when there is a more complex module to develop

When it comes to continuous integration, it is very helpful in order to provide tasks to the testing team quicker (and of course feedback from testers to developers) and shorten the time-to-market.

Q: What does your user story look like? Do you have a template?

A: We usually use the standard user story template:

As a < user >, I want to < some goal > so that < a reason >.

Q: What does your Definition of done look like?

A: We use DOR and DOD.

Sample DOD:

1. The task must:

• be assigned to a version (described in JIRA), epic, budget and relevant component

• be released on a specific environment (if hot-fix: prelive env.; if a task: test env. before it goes to a client on demo env.)

• meet the Acceptance Criteria

• be documented in Enterprise Architect

1. The specification must be updated (when needed).
2. Unit tests work OK.
3. Task passed manual testing.

Q: How often do you underestimate or overestimate tasks? How do you cope with those situations? Any advice on how to avoid these situations?

A: It really varies. We underestimate or overestimate tasks sometimes. We tend to check the time spent, not only on a single task level, but also on the epic level. The epic budget usually stays in the agreed-upon frames.

We are learning to estimate better on a daily basis. We split the tasks into small chunks, estimate as a team (or pairs of developers), take the lessons learned into account and use PERT calculations to avoid issues with estimates.

Q: How do you track the progress of your project? Do you have a Sprint Burndown chart or a Cumulative flowchart?

A: Yes, we use a Sprint Burndown chart.

We also prepare a report where we list all epics and present the used/left budget of a currently agreed scope as a bar graph.

Q: Do you conduct all of these meetings with your team – Daily Scrum, Sprint Planning, Sprint Review, Sprint Retrospective, Backlog Grooming?

A: No. We decided to choose best practices from various methodologies and created a hybrid methodology which suits us best.

We do Stand-up meetings (described as Daily Scrums in Scrum but sometimes scheduled twice a week, depending on project).

We conduct the Planning Session and Backlog Refinement as a standard.

Sprint Review is done a bit differently than described in the Scrum Guide.

Sprint Retrospective is scheduled once per several Sprints.

Q: When do you consider that the Sprint Planning meeting was a success and how do you achieve it?

A: When the team delivered what was promised.

At the Planning Session the whole team looks at what needs to be done and the team must agree to the Sprint Scope (even if just a few people estimated a task, each team member must provide feedback if this is doable or not).

Q: What do your Sprint Retrospectives look like?

A: During the Sprint Retrospective, we perform various exercises to find out issues and resolve them quickly. We usually use a big blank piece of paper, sticky-notes, colourful markers and other tools. We have some fresh fruits and something to drink, so it is a nice and comfortable atmosphere to work on what we wish to improve.

One of the technique is to list all issues each team member has noticed, place them on the wall and vote (using stickers) for the most important ones, which need to be resolved as a priority. We normally choose between 3 and 5 topics, discuss how to address them in detail and assign one person responsible for closing the issue in a scheduled time frame.

Q: How has being Agile affected your team, its productivity and your collaboration with clients?

A: The team feels more responsible for the project and team members work more closely with each other.

On the productivity side of things, we can see by the number of tasks solved and bugs found that the teams are more productive. We also measure the production teams by paid tasks and we can see that the average value increases.

Having prompt feedback from the client allows us to continuously adjust the goal and the vision of the end product together with the client. They can easily collaborate with us on the backlog and, in the end, they get what they really need and want. This has resulted in noticeably happier clients.

Q: Could you name a situation when you thought that Agile wasn’t a good solution for your team?

A: Clients still want to have a fixed budget and timeframe but also the scope (even on a high level) described before the project starts. They must be educated during the course of the project that the primary project goal and vision might change, and the agile methodology allows them to have a fixed budget and time but not fixed scope.

Client’s idea and vision will change along the way, especially on longer projects. We need to keep on reminding them to focus more on the backlog because not all tasks/stories can be done in the agreed timeframe.

If you’d like to share your Agile experience with VivifyScrum’s readers, click here to find the interview.