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 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 when they can learn what they want, work on what they want and share knowledge with each other. From time to time there is a project demo presented to the wide audience and whole company can be introduced in what each team does 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 incrementally growing project quite quickly and Waterfall was not a right methodology 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-organizing team and not to rely on a Project Manager the whole time but to take the full responsibility for the project.
Educating our clients about how this will work also was 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 these techniques and which positive effects can you name?
A: Writing unit tests allow them to collect feedback about they work quickly. We strongly recommend the developers should test their own code before passing the module to a tester. Unit tests fit perfectly here.
We use the pair programming in two ways:
- when we train juniors
- when there is a more complex module to develop
When it comes to a continuous integration it is very helpful in order to provide tasks to a testing team quicker (and of course the feedback from a tester to a developer) 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.
- 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
- The specification must be updated (when needed).
- Unit tests work OK.
- 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 the good practices from various methodologies and created a hybrid methodology which suits us best.
We do Stand-up meetings (described as a Daily Scrums in Scrum, but sometimes scheduled twice a week, depends on a project). We conduct the Planning Session, Backlog refinement as a standard. Sprint Review is done a bit different than described in a Scrum Guide. Sprint Retrospective is scheduled once per a few 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 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 a feedback if this is doable or not).
Q: What do your Sprint Retrospectives look like?
A: During the Sprint retrospective, we do a few exercises to find out the issues and solve them quickly. We usually use a big blank piece of papers, sticky-notes, colorful 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 noticed, place them on the wall and vote (using stickers) to the most important ones, which needs to be solved as a priority. We normally choose 3, up to 5, topics, discuss how to solve it in details 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 covering the production teams by paid tasks and we can see that the average value increases.
Having the feedback from the client quicker 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, timeframe but also the scope (even on a high level) described before the project starts. They must be educated along the way that the primary project goal and vision might change, and the agile methodology allows them to have a fixed budget, fixed time but not the scope.
Clients idea and vision will change along the way, especially on longer projects. We need to keep on reminding clients to focus on the backlog more because not all tasks/stories can be done in the agreed timeframe.
If you'd like to share your Agile experience with our readers, click the button below to find the interview.
Disclaimer: The interview has been edited for clarity and style.