Not Invented Here syndrome (NIH) is the guilty pleasure that tempts engineering teams into creating bespoke approaches to problems that have already been solved. Even having your eyes opened to the temptation doesn’t immunize you from it. So, how do you know whether a bespoke solution warrants the effort or if it’s just plain hubris?
The San Antonio Riverwalk
Alley project managers Margaret Schneider and Andrew Short attended the Digital PM Summit 2016 and the subsequent Digital PM Workshop in October in San Antonio, Texas. They brought back many useful insights and have spent the past month discussing those lessons with Alley’s PM team. We took a few minutes to chat about how their experiences at the conference shaped their views of their current roles and the PM team as a whole at Alley.
What did you do at the conference?
Andrew: The first two days were seminars and breakout sessions, and the third day was a workshop with PMs from around the U.S. and Canada. The attendees included a lot of people from client-facing agencies, as well as a good number of PMs who worked in-house. So it was really interesting to share information with client-based PMs and also to see how their project management works internally.
Margaret: I’d say it was 50–50 people who were in-house versus people at agencies. And that’s what we came for, that’s why we attended this conference: We wanted to know how other people were addressing questions we all face that are specific to digital project management.
How was the workshop?
Andrew: For the workshop, they organized us into groups to work on one single project and then had us compare our approaches. I learned the most there. They organized the project-manager groups on the basis of how each PM approached product development: Agile, waterfall, or a hybrid combination of the two. We were Agile.
Margaret: We had multiple groups per section. There were 2 Agile groups in our section, a few under waterfall, and the most under hybrid. Each group had between 4 and 6 people. Andrew and I were on a 4-person team together. Our other teammates built sites and apps for health care.
Andrew: They presented us with Oberlin College’s Arts and Science website as an example and gave us specific goals for what to rebuild in a 12-month period. We had to establish a budget, considering aspects like how they want to engage an audience, how they want to showcase articles, things like that. One interesting thing to note: At the end, the budgets for the two Agile teams were almost identical. Both Agile groups based their budgets on executing the project in 2-week sprints, and we had similar estimates for how many people we needed to complete this in 12 months. The waterfall and hybrid groups were all over the place in terms of budget and time frame. Most of those groups seemed to really undershoot the budget. After comparing the same project using different methodologies, I was reassured that we’re using a more accurate approach here at Alley.
Margaret: Throughout the workshop, it seemed like the waterfall teams were posting budgets that seemed unrealistically low, and it seemed like they were also cutting out features that the client wanted. It reinforced for me that scrum works and kanban works and those approaches help us deliver what the client wants.
Andrew: From the teamwork perspective, too, it was interesting to see how scrum can really reduce how hectic things can be. A lot of teams stood up and were drawing all over the walls and were frantically trying to figure out their plan, while our team had a really reasonable discussion about who we needed in each role and how long it would take. Then we came up with our budget and talked about our agencies’ approaches while we waited for everyone else to finish.
Margaret: I think Agile is a framework that gives you the steps that you need. With Agile, it’s not like you’re planning out every single piece of the puzzle at the beginning. One thing that I noticed with teams with other methods is that they focused on some concerns that I would consider to be a little more trivial or shibboleths, things that they had found in their experience mattered, but that to us were smaller-picture. Agile really lets you focus on the product and what’s important to making that product. It felt like some other teams got lost in the weeds.
How were the sessions?
Andrew: The seminar on team-building made the biggest impact on me. Margaret and I walked away from that session with a lot of knowledge about team-building and reassurance that we’re on the right track at Alley. The session covered company culture and the importance of getting really constructive feedback while keeping the team’s morale high. Afterward, Margaret and I were talking about the narrative of projects, especially the narrative arc of huge projects. You all learn it together. You all figure out how the project is going to go, the structure of it, and then you see how your team fits into that and you put faith in your team to carry out the project while you serve as support. You can set the tone by praising good work, asking what’s going right, seeing how you can address problems, and making it a safe space for developers to work. That’s important to me. It’s key to make sure everyone stays together.
Margaret: Much of this reinforced what I already thought was important. We take coaching seriously at Alley, and learning ways that other agencies use that was useful. Since we’re distributed, however, some of the suggestions may not work for us. For instance, one suggestion was a fun role-playing scenarios using LEGOs called LEGO Serious Play. I thought it was interesting because it would be one way to help team members with different communication styles find common ground—that’s something we care a lot about at Alley. It’s hard to set up a role-playing scenario like that when our team isn’t in the same room, but that speaker, Garci Inigo from Cossette, had a lot of other ideas that we’ve found directly applicable to our distributed team.
Any last takeaways?
Margaret: Hearing other people discuss their client relationships made me feel really good about what we have at Alley. We have really strong relationships with our clients, and we treat them all with great care. Everyone has their own approach, but hearing others’ experience with more tenuous connections made me realize how solid we are with our clients. We have a lot of agency to create change within our organization, too, and that’s a really positive thing. We can react nimbly to shifts in the marketplace and in any organization.
Andrew: My biggest takeaway was how happy I am with the way that Alley works, both from a project-management point of view and in terms of our company culture. It sounded like some issues other people faced were already solved by our approach and existing culture. It made me appreciate how we have a really solid framework in place for how we approach technical issues. We have such open communication, too—I know everyone by face and name even though we’re across the U.S. It really makes team-building easy, and it helps people take control of their own work. And knowing that experts are recommending best practices that we’re already using is reassuring to me.