On our most recent episode of Map Talk, host Allison Williams sat down with Mapcom’s Parker Pierce and Kyle Palentino to discuss our adoption of Agile development methods, what that means for our product roadmap, and when you can expect to see new features and functionality. We also chat about their home projects and how they’re stepping up their fitness routines with their bonus time while working from home.
You can listen or read a copy of the transcript below!
Episode Transcript
Allison Williams: Thank you guys so much for joining me today!
To kick everything off, will you guys go ahead and introduce yourselves, what your current role is here at Mapcom, and your areas of expertise.
Kyle Palentino: I’m Kyle and I’m currently the Scrum Master and Agile Delivery Lead at Mapcom. [I] started out in the Product group with Parker as a Product Analyst and before that I recently served active duty in the Army as an Officer. What kind of led me towards Mapcom [was when I was] in the army, I was doing geo-spatial analytics. I was doing Space Operations and managed a bunch of teams ranging from six individuals to 40 [in] comfortable and not so comfortable situations. So, [I’m] pretty familiar with project management methodologies [and] working with teams in environments where we have to pivot really fast and embrace change. That’s what really led me into the Agile space, specifically with Scrum and leading KanBan being a part of that as well.
Parker Pierce: I’m Parker Pierce [and I am] currently the manager of the Product team here at Mapcom. My current role functions as a player and a coach. As a coach, I set strategic direction for Mapcom’s full suite of products and I guide our Product Managers and professional development. Then as a player, I serve as the product owner for our Web Console, RevGen, Pinpoint811 and integration engine products. My background is in computer science, so I come from a software development life cycle background and have experience in running projects through different frameworks.
AW: As I’m sure everybody is aware; we are quarantined here in Virginia so we’re all spending a little bit of extra time at home. Has there been any projects that you guys have been able to check off an ongoing to-do list, or how have you guys been keeping busy?
PP: We bought a treadmill and put that together. Getting that up the stairs was an adventure. Then as a big project I taught all three of my kids how to ride their bikes!
KP: Similar to Parker there, I’m spending more time with my wife and I have also been building up my home gym. I installed a pull up bar, got a box, got a bunch of other things and weights to throw around, so every once in a while to try to sneak in a little workout midday, which is nice because I wasn’t able to do that if we were in the office.
AW: Kyle, for those who are listening that might not be as familiar, can you talk a little bit about what Agile development looks like and how it works?
KP: There’s a lot to Agile and I think I’m always going to be a student of this. For me, and to quote somebody who came before me, I think a real good bumper sticker for Agile in general is that it’s not just for software development. It is delivering quality and value at the speed of market no matter what market you’re in. [This enables] continuous improvement of the product in your organization. I think it’s an interesting area to try and define how it works because I think there are no two similar flavors of Agile. Trying to study up on how this business maybe was waterfall before and how they’ve transitioned – that transformation looks different for everybody.
At Mapcom, we’ve really worked hard to adopt a framework that focuses on forming self-organizing, outcomes-oriented teams that focus around value areas. There is want to focus in while also empowering them to determine the what, the how, and what they’re going to be doing to deliver those products.
Ultimately, I think we’ve been able to embrace change in the landscape from the client side as well as in the market sectors. It’s also helped us to really pivot and respond in this time where we’re a bit more distributed, a bit more remote, and communication lines are a little different. It’s really postured us in a way to deal with change, not just in those regards, but also with the pandemic. It’s an interesting aspect of Development and I think we’re doing a good job so far with our transformation and our journey.
AW: Parker, we’ve also adjusted the way we look at features and enhancements here at Mapcom, working in tandem with those in development to build a roadmap that also reflects our Agile framework.
How does this adoption of Agile help you and your team plan for new products and features?
PP: Thanks, Allison. I think adopting Agile has helped us in [numerous] ways. To step back [to] what Kyle was saying about how we adopted Agile here, we had to learn as we [went] along. I think, maybe, that’s something that other companies could learn from as well. When you go from not doing any sort of Agile development to changing over, there’s definitely a learning curve you have to be prepared for and be okay with. We definitely had some initial phases that were a little bit of a start and stop. Going back and learning things over before we really found our footing, which is okay. That ties right into the principles of Agile, that you’re learning quickly – the idea of failing fast, adapting quickly, and moving on. [Also], you can learn from those failures instead of taking months and months before you find something out and then apply that knowledge. We’ve adopted Agile in that way where we learn faster.
Really where I see my team and the product team and the two key advantages we have is, first of all, we have much more visibility into exactly what development is doing and when they can deliver. Previously, there wasn’t much visibility [and it] was very hard to determine six months, eight months from now, how many of these enhancements that we talked about with development are going to get done. It was very hard to see that week to week progress and then in addition to that, we have much greater freedom to adjust our backlogs to meet the current needs of the market as they change. Every industry is moving fast these days and six months or eight months is a very long time to wait to have to adjust. We may have planned something six or eight months ago and we thought it was important at that time and maybe it was. Then by the time six or eight months comes along, something else jumps up that is actually more important to our customers, but we weren’t able to adjust to that quickly.
Now, with our particular flavor of Agile we do two-week sprints. After every two-week sprint, we’re demoing what we’ve done, we’re readjusting that backlog, and resetting that priority. That’s really allowed us to move fast. We can hear from a customer and they might see something and then just a few weeks later, we might be able to show them, “Hey, this is already here. It’s already working for you”, as opposed to, “Hey, you got to wait till this next full cycle of six to eight months of development.”
Those two insights together have been critical to allow our team to provide value so much faster than we could before. Prior to Agile, it was really hard to accurately project that out, to take a specific feature that a client wanted and say this is when you’ll get it. It was it was very much “Hey, we’re targeting that within six or eight months later, we don’t know.” Now we have much tighter visibility there and to adjust the plan as new information becomes available. Even with changes in the team, if people leave or people come on, we can account for that so much better. Now that we’re running with Agile, the landscape has changed drastically, and I think we just have so much more confidence in what we’re doing.
AW: We’ve touched on this a bit, but with the introduction of these new ideologies, the introduction of a Scrum, and integrating a new team, can you expand on how this has enhanced both Product and Development as we’re moving into Agile Development?
KP: From a tactical perspective we’ve really adopted, or at least rallied around, two specific lightweight frameworks. Before I get into the Scrum piece, I do want to mention for some of our legacy software that’s been out there for a while and our clients are still using, what we’ve been able to do to help stabilize a lot of the work we’re doing there is with Kanban.
Kanban is another big framework in the space of Agile. It really touches into lean practices. Kanban is able to help us visualize the flow of inbound work items, whether those are defects, enhancements or specific nonfunctional requirements. The reason why we went that way was to help integrate a team of teams, if you will. We have certain developers and product managers who are focused in on our desktop products and a couple that were focused in on integrations and web [products]. Essentially, Kanban has helped bring those teams together to really parse out and visualize the workflow and nest those together. We could see those inter-dependencies, communicate, see where the bottlenecks are, [and] what’s holding us up and to help evolve.
Scrum is a little bit different. We really focus the Scrum framework around the newer product development. That’s where Parker and I have really been working [together] with the other half of our development team. We’ll get into a little bit here. Scrum has allowed us to take a lightweight approach to having a team deliver value in the best way that they see fit. It helps us solve complex problems with a simple solution and in increments, like the two-week iterations that Parker was talking about. What Scrum allows us to do is to take a lightweight framework, add to it, but not to take away from it. We have our ceremonies, you always hear about the daily stand ups, the reviews – those are really beneficial. As Parker was talking to, we’re able to pivot and change because we’re able to be right next to the stakeholders, give some demonstrations, get some feedback for a product backlog. We really shorten that feedback loop from where he was saying six to eight months, right into the two-week windows. That gives us more certainty to plan for the next two weeks, with a more tentative plan being quarters out or years out for the Product Roadmap. That’s really helped us plan not just the Product side, but also the Development side, and ultimately it’s helped create really good chemistry within the Technology department.
It’s really instilled the idea of joint ownership and work. We’re all in this together, we’re going to solve this together, and you’ve made commitments every two weeks to these items. We’re going to push forward and do our best to solve them and communicate while doing so. To touch on a point that I think Parker had made earlier, we had to be growth-minded and a learning organization to figure this out from the start. At the end of the day, I think that’s helping not just improved morale with the team, but also our velocity and our development practices substantially.
PP: I think it’s a really important point for those out there who might be thinking: “Hey, will Agile work for us?” As I mentioned before, we had some fits and starts where we tried to implement “Agile” through our entire development organization but what we learned is that there are different flavors of Agile that may work better for different sets of work. Kyle alluded to that. Our application support really fits better for the Kanban method, but as we looked at Scrum and as we implemented that, we saw that that those principles fit perfectly with building a product from the ground up with a fresh team.
It forced us and helped us [to] learn new habits. We’re doing things differently. As Kyle said, that accelerated professional growth of everyone on the team from me and Kyle to the developers, to our QA folks as well. When we started implementing those Scrum ceremonies, refining the backlog, estimating effort, planning for future sprints, we were all growing and there were definitely some growing pains. I think that’s something to have teams plan for and to accept that they’re going to come. People are going to have to learn where their role fits, where their boundaries are within the Scrum team. A product owner can’t be a developer, a developer can’t be a product owner, usually.
The cool thing about Scrum is you can float a little bit between those roles when it’s necessary. The whole team is working together to come up with a solution. There’s no one person who only does the one thing, everyone’s a multi-functional team. However, you do want people to lean into their strengths and lean into what their role should be. For a product owner, we always say the product owner is the what person: “What should this product do? What do the customers want? What’s going to bring value? What’s going to give them joy when they use this product?” Then the developers and the tech team are the how people: “How should this product work? What’s happening under the hood?”
There’s a little bit of cross talk there, where because of my background, I might be able to suggest a how. A developer who is very focused on building and on what the customer sees, they can make suggestions to the what. Learning where that line, [where] that boundary is, it took a while and there was some friction there. But I think that’s where, just to talk about Kyle here a little bit, he’s functioned as the Scrum Master to help everybody learn that proper balance. It’s been really cool to see, to have the team come together, and to see these principles in action and help us all learn and grow.
Lastly, the sprint reviews have been critical to the team’s success and visibility to the rest of the company. That’s one complaint that we always had around Mapcom, “Well, what’s [Development] and Product doing?”
It wasn’t like there was any intentionality or trying to hide what we were doing. But other organization like Sales, Marketing, [and] Operations just weren’t quite sure when something was going to be done and when they could see what [we’re] working on.
The sprint reviews are a line in the sand, a meeting that we put on the calendar and invite our stakeholders to. We have to be accountable for that, to be ready for that, and then it gives us the opportunity to demo. As Kyle mentioned about building team morale, it builds morale to say, “For the last two weeks, here’s exactly what I did and now you can see [it] at work.”
The stakeholders that we are presenting these sprint reviews to give us good feedback. They’ll say, “Hey, the way you designed that GUI, the way it operates, I can see where you’re headed, but I don’t know if that works if I’m looking at it from a user perspective.” That feedback loop is so tight and they’re a true stakeholder then. They’re being heard, and they feel like they’re being heard, and it’s a regular process.
Just to finalize, we had to get there through a learning process. We didn’t just read a book and go okay, this is the exact methodology or the exact framework we need to use, and it’s going to work. We went out and we knew we wanted to implement Agile. We got some Agile coaching and thankfully we got a good Agile coach that let us know, “Hey, Agile doesn’t look the same everywhere, you need to figure out what works for Mapcom.” Thankfully, we’re able to do that through the process of learning and growing and being open to that sort of process.
AW: Ultimately, the roadmap will be evolving alongside our clients’ needs and the industry as a whole, moving us away from previously held hard deadlines. How does that switch up help those we’re servicing those in the industry?
PP: In a way our external stakeholders, our customers, they benefit from the Agile framework in a similar way to our team. We can provide more specific updates on when the features they want will be available. They have greater visibility into what we’re doing week to week. We don’t disappear for months at a time and then show up to say we [have] a new version for you. They’re involved in this process. Then we can demo that process every couple of weeks and show them that progress.
They really like that they can see how our teams [are adjusting] to their feedback much more quickly than we used to. Whereas in the past, it was very much a “Hey, yep, we heard you and [we] will put that in as Enhancement Request”, and then we might not answer them again for months.Then they’d come up and say, “Hey, I saw a new version come out. Where’s that enhancement I put in?” And we’ll say “Oh, well, we didn’t get it in. Sorry, we didn’t get a chance to tell you.”
Now, with this particular team and the Scrum team, we’re able to show them what’s actually going in every sprint. If there’s something they particularly want, they can either see it happen quickly or they’re being notified every couple of weeks that [this item] is still in the backlog, and where it is in the priority list. In some cases, we’ve had them request something and then two weeks later, they see it demo-ed, which is a huge change from anything Mapcom has done before. Several months or more would go by before they got anything from us. But now they request something, and if we see that it adds value to the entire customer base and really moves the product forward, we can put that in quickly. I attribute that to us learning Agile and implementing it and turning into real customer benefit.
KP: Because we’ve been able to focus in on the most valuable aspects – development for our clients and those quick feedback loops that we’ve established with the reviews – we’ve been able to embrace change from a project management perspective. You can think of it like we maybe have an idea of what the known unknowns are, because we’ve been able to forecast a little bit, but then there’s a lot of unknown unknowns that come out of the work we do. That’s the benefit here in terms of getting value back to our clients a lot faster. Parker’s efforts in designing a more Agile minded roadmap has kept us focused around these value areas.
We’ve been able to really, and this is from a team perspective when I say “we,” have really shifted from outputs to an outcomes focused outlook on success. I guess you could say, tangibly speaking, what we’ve been able to do here as we continue to grow [over] the last couple months, we’ve really begun to align our two-week sprint goals towards outcomes. We always ask ourselves, where do we want to be at the end of the sprint? Are we prioritizing the greatest value first to support the Product Roadmap and vision?
Then we have those discussions in the refinement session. The team has made a lot of those improvements through these reviews and the retrospectives. To speak briefly on the retrospectives, which I think are really important here to that growth aspect, you’re looking more at the product, right? How do we refine the product? Are we delivering the right thing? Whereas the retrospective is really looking at the team, our process of delivering that product and the idea here is empiricism, right? It’s much more of a “Hey, we don’t know what’s going to happen in some cases.” Let’s look at things in three specific ways. This helps with the client, helps with the stakeholders in the company in terms of transparency and where we are. How’s the sprint doing as a team? Is the team delivering on the goal that we’ve set forth? We’re inspecting that process and then we’re adapting immediately thereafter. That I think is that the catalyst that’s really changed the mindset of the team. It’s begun to really change the organization’s view on development as a whole from maybe a more dogmatic mindset that might have been in place a couple years ago.
PP: Just to add to how the Product Roadmap has changed here at Mapcom – I think we also learned what a roadmap is and how you handle it. I think to some degree, both internally and externally, people were viewing a roadmap as something that was set in stone, or something that you worked out at the beginning of the year, printed it out, laminated it, and then that’s the roadmap. But what we’ve seen is that the roadmap is much more of a living and breathing document and that goes into the Agile framework. That this is the roadmap and we’re doing everything we can to make sure we’re planning that in the long term view of customer value, but then as you move along and start to march down that roadmap, things change, and you need to be able to adjust. Agile really provides the ability to do that.
AW: Awesome. We have talked a lot about Agile and roadmaps in the questions leading up to this, can you guys put this into a real-life example of what this has looked like here at Mapcom?
PP: As we examined our current offering around the locating task – and for those of you who don’t know what locating is, when people are digging an excavator or a homeowner or someone wants to dig, they can call an 811 agency. Then a ticket goes out to everyone who might have something in that area buried. [This is called a] locating request, where someone goes out and paints or marks [the ground] so that nothing gets destroyed. That’s an extremely important task that every utility or communication service provider needs to do, and it can be a tough problem to wrangle if you don’t have a good system for it.
We’ve offered some tools around [locating] in the past but we realized that our offering didn’t just need an update, we needed a totally new product. We needed to change the way that we handle the data, the way that we serve up the data to users, and the way that we communicate back to the state agencies. Everything needed to change. Because of that, [now] was a perfect opportunity to implement a new Agile team and to use the Scrum principles to do that. We formed a team, we chose the right individuals for that team, and we hit the ground running.
I took on the product owner role of that team, doing a lot of customer listening, putting together a vision for this new product, setting use cases, and making sure that whatever we thought we needed to build on day-one is the right product. Then continuing that process of that listening to what customers are saying when we demo for them. The development team took that vision and they put together a technical plan for how we could fulfill that vision. Then when we got started. We had an initial Sprint Zero, stormed the team together, and just grew.
We learned a great deal and we’ve delivered a working Version One of that product, we call that product Pinpoint811. We’re pretty proud of what we’ve been able to do because it’s really been different to everything that Mapcom has done in the past. The way we’ve done it was also different. It’s not just that the product we delivered was different, it was the way we got there was different, and now we’re continuing to grow that product. We know it’s not everything we want it to be yet, but we know we have the team in place and we have the right framework to get there.
It’s been a wild ride. There’s been everything – learning and professional growth. There’s been some arguments among the team. There’s been, like I said earlier, adjusting to those right boundaries and roles. But thankfully, we were able to get past that, learn from that, and grow. The team’s coming together even more and I would say the team that the Pinpoint811 team at Mapcom is tighter than any other team Mapcom has. We work together so closely and there’s no silo, which is another huge benefit of Agile. Within that team, all different roles and people with their different skills don’t have to be sequestered in their little cubicle, if you will. Everyone’s there together, working.
It’s funny that you know, Kyle mentioned earlier it’s like changing the tires on a car as it goes down the highway. You’re hurtling along down the road and you’ve got to change things. Agile, if done correctly, lets you do something as difficult as that may seem. You can do that on the fly, you can make these big adjustments and then continue to deliver value to your customers.
This has been an exhilarating experience. We’ve applied these Agile principles, we took what we learned from the book, from the coach, applied it in the real world, and then here we are. It’s been really cool and I’m looking forward to continuing that, taking on more products, and delivering even more value through it.
What’s Next?
- Take an in-depth look behind the scenes at Pinpoint811 and it’s inception, here.
- See Pinpoint811 in action on our on-demand replay of a recent Pinpoint811 webinar.
- Sign up to get alerts about new Map Talk episode here.