We’re ending this year with another interview with a fellow agilist. Jason Garber, COO and Co-founder of PromptWorks LLC from Philadelphia was kind to answer all of our questions and to share his team’s experience.
PromptWorks is a software development company that collaborates with clients from different industries around the world. A lot of their clients are in finance, health and life sciences, and IT, but also in energy, education, retail, manufacturing, and professional services. For their clients, PromptWorks build web applications, cross-platform mobile apps, backend systems, APIs, kiosks, IoT and machine learning platforms.
Q: What is the size of your team and who is a part of it?
A: About 35 engineers, designers, project managers, and administrative staff work at PromptWorks. My team is operations, but I get to join project teams made up of full-stack developers, UX researchers and designers, project managers, business analysts, and QA automation engineers.
Q: What is your role in the team?
A: I'm on the executive team, but given our high rate of growth, I often find myself filling in as a product owner, account manager, or even developer!
Q: How does your team stay synchronized?
A: Slack is the backbone of our inter- and intra-company communication. Shared channels make it easy for us to instantly connect with whole client teams and collaborate in between seeing each other. We value face-to-face communication a lot, so we use Zoom video conferencing and in-person meetings whenever possible.
Q: Let’s move on to the “Agile questions”. When did your team start using Agile practices?
A: We started with Agile before we were even a company! As freelancers, we kept product backlogs in PivotalTracker, planned sprints, and gave our clients demos of working software even as we were unrelated teams of 1-2. So when we formed the company, we followed Agile and XP principles from the get-go.
Q: What was the biggest impediment while implementing agile practices?
A: Our biggest challenge is educating clients about our Agile process and integrating with their teams when they have their own concept of "agile" or Scrum.
Q: Have you incorporated any practices from other agile frameworks in order to adjust your workflow?
A: We constantly remind ourselves that the point of Agile is to always be reflective and open to changing your process to make the team work better, not rigidly holding yourself to something someone else says is right.
Q: You say your team uses Pair programming, Unit testing, Test-driven development (TDD) and Continuous integration. Why has your team chosen these techniques and which positive effects can you name?
A: These techniques have been part of our DNA from the beginning. We feel that through pair programming, our code is at least twice as good. Unit testing is just a given for us.
I just had a perfect case for TDD while pairing with one of our newest engineers yesterday. She wrote the code, then I encouraged writing a test. We wrote the test and both thought it was good, but then I suggested simulating TDD by commenting out the code we wrote. To both our surprise, the test didn't fail! I'd say testable code design is the more powerful benefit of TDD done well, but even clumsy TDD has benefits.
Q: What does your user story look like? Do you have a template?
A: Our user story is just "As a... I want to... So that...". We use a template in Pivotal that has that story format, acceptance criteria written in gherkin, and usually an InVision live embed to the wireframe/mockup.
Q: How does your Definition of Done look like?
A: On bigger projects, we write acceptance criteria, because it's so easy to be excited about what you accomplished and forget that there's more to the story.
If more was expected than what was put in the ACs, then we had a failure in communication and need to create a new story for the extra expectations, because the story was probably estimated using the developer's expectations. It's not a good pattern to let the Product Owner inflate stories to encompass everything conceivable.
Q: When you estimate 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: We might have an intuitive sense of under/overestimation, but it's not something that should be tracked. Estimations are only useful for planning, so if the team is consistently "underestimating", that just means velocity - which is totally relative anyway - is just a low number. At the extremes, it could be a problem (3 points per sprint?), but in general, as long as you're adamant that points have no inherent value, it's all relative.
We look for velocity to settle into a nice, consistent average, whether that's 10 points per iteration or 100. Consistent underestimation doesn't matter as long as it's consistent.
Where you get into trouble with high or low estimates is when the team composition changes. Velocity is only a predictor of that exact same team, so more or fewer people or different humans doing the estimating can take awhile to get to a new average velocity.
Q: Do you use any techniques to estimate tasks such as Planning Poker?
A: We do sometimes use planning poker scrum cards, but most of the time we're not quite that formal. Planning poker is just a catalyst for discussion. Our teams have such good internal dynamics that they get right to the discussion without always needing the poker mechanism.
On new teams, though, it can be very helpful until they all get on the same wavelength.
We do a different kind of estimation in our discovery process when quickly trying to estimate a big backlog. Assigning T-shirt sizes to features helps us quickly figure out whether the project will take 12 weeks or 12 months. Then we run a Monte Carlo simulation to give us a distribution of the time to complete.
Q: How do you track the progress of your project?
A: Usually we can eyeball progress through the sprint, so we use a backlog burndown to show progress toward a milestone and, more importantly, how scope changes affect that milestone.
Cumulative Flow Diagrams are useful when we want to diagnose a specific problem, such as stories sitting finished but not delivered for too long, but we don't usually need to look at them and they're too confusing for clients.
Q: Which meetings do you conduct? Who is present at these meetings?
A: Daily Scrum, Sprint Planning, Demo/Review and Retro are all done with the whole team. Backlog grooming is just between the Project Manager and Product Owner to get the backlog ready for sprint planning.
Q: When do you consider that the Sprint Planning meeting was a success and how do you achieve it?
A: Sprint Planning is a success when everyone knows what's coming up, everyone feels comfortable with the acceptance criteria, and there are very few questions about stories during the sprint that could have been anticipated.
Working on a story will always bring up implementation questions no one thought of, but there shouldn't be questions around the scope of the story, its sizing, or priority.
Q: What do your Sprint Retrospectives look like?
A: The PM facilitating picks a motif (plus, minus, delta; start, stop, continue; etc.) depending on what they think the team needs. We have 5 minutes to write and post sticky notes and then we group and discuss. Many of them are just good to acknowledge, but where there's an action item, the PM records and delegates it.
All the good things
Q: What are the most important benefits of being Agile when it comes to your team?
A: The most important benefit of Agile is that there aren't death marches because we underestimated or because we worked on less important things first. Everyone knows what everyone else is working on and can elevate issues quickly so nobody's spinning their wheels or architecting in the wrong direction.
Q: How has Agile affected your team’s productivity?
A: We've never known anything else! Compared to our peers in software consulting, though, it seems like we're a more productive team.
Q: Has Agile affected the quality of the products you make?
A: Absolutely! The whole process feels more precise with less wasted time, less rework, and less uncertainty on what to work on next.
Q: Has it affected your collaboration with the clients?
A: Not particularly.
Q: Any downsides you’d like to mention?
A: There were times we thought Agile wasn't a good solution for the team, so we downshifted to Scrum. It happens when there is no backlog or the client is changing priorities often. It's not an ideal situation, but sometimes when we're still working out an MVP scope with the client, it's necessary to track what we're working on, even if it's not coming from a prioritized backlog.
Thank you, Jason!