Tag Archive for: Engineering

2022 Engineering Predictions: Overcoming Three Key Industry Challenges

In many ways 2021 was a continuation of the changes brought about in 2020, a year that’s been described as “unprecedented” and “unparalleled.” In a unique way, 2021 has offered us an idea of evolving innovations and technology on the horizon for teams across industries. These changing conditions will present a variety of new landscapes and will offer unique challenges, opportunities, and more than likely, many surprises.  

As we enter a new year of further changes, Jama Software asked select thought leaders – both internal and external – across various industries for the trends and events they foresee unfolding over the next year and beyond. 

In the first part of our five-part series, we ask Josh Turpen, Chief Product Officer at Jama Software, to weigh in on product and systems development trends he’s anticipating for engineering teams in 2022.  

Read our other 2022 Industry Predictions here: Part Two – Medical Device Predictions, Part Three – Automotive Predictions, Part Four – Aerospace & Defense Predictions, and Part Five – Insurance Development Market Predictions.

Engineering Predictions

Design Trends

Q: What product, systems, and software development trends are you expecting to take shape in 2022?

Josh Turpen: Complexity will continue to increase and supply chain challenges will be a multiplier. The “chip shortage” is a great example. There aren’t too few chips, there are too few of the chips that OEMs are used to. Adaptable OEMs, with advanced product management and traceability, have been able to overcome this challenge. 

Q: In terms of product and systems development, what do you think will remain the same over the next decade? What will change?

Josh Turpen:  Software will continue to outpace hardware development, but hardware will close the gap. Connected tooling, simulation, and a transition to collaborative, JIT processes will enable hardware engineers to ditch the “one big meeting” for a more natural, asynchronous communication flow. 

Q: How do you foresee regulations shifting in product and systems development for engineering teams over the next decade?

Josh Turpen:  I still think my previous prediction (2021 Predictions) is accurate. Regulations are coming for software in a big way. This is the tip of the iceberg.  

RELATED POST: How EN 50128 Establishes Functional Safety Standards for Railway Software

Biggest Challenges

Q: Any major disruptions to product and systems development for engineering teams industry you’re anticipating in 2022?

Josh Turpen: I don’t think it’s a new disruption, but talent acquisition and management will continue to be a major theme for any head of engineering. Those not embracing a distributed workforce are in for serious pain. 

Q: What sorts of process adjustments do you think development teams will need to make to be successful in 2022?

Josh Turpen:  Asynchronous collaboration is critical in a distributed team. If your process and tools cannot keep contextual information and give users what they need when they need it, your team is wasting valuable time and increasing the likelihood of a bad outcome. 



Q: What do you think will be some of the differentiators between a company surviving to see 2030, and those that do not?

Josh Turpen: Companies that embrace a best-of-breed approach to tools, collaboration, and the process will dominate those that don’t.  

Q: Where do you see Jama Software fitting in as the product development landscape evolves, and what can our customers expect as 2022 approaches?

Josh Turpen: Our focus on Live Traceability™ will enable teams to leverage the best tools while maintaining context and enabling collaboration. We get up every morning focused on enabling our customers’ innovation and product success.  

Thanks for tuning into our 2022 Predictions Series! To see some of the incredible products, software, and systems our customers are building with Jama Connect, visit our CUSTOMER STORIES PAGE. 


product and systems development

2020 has been a year that’s been described as “unprecedented” and “unparalleled” – as well as other descriptors probably best left out of our blog. As we close out this year, it’s hard to say what awaits us in the new one. One thing that we can be sure of is that innovation in medicine, science, and technology shows no sign of slowing down.

As we enter a new year of technological advancements, Jama Software asked select thought leaders – both internal and external – across various industries for the trends and events they foresee unfolding over the next year and beyond.

In the final part of our four-part series, we ask Josh Turpen, Chief Product Officer at Jama Software, to weigh in on product and systems development trends he’s anticipating for engineering teams in 2021. You can also go back and read Part I, Part II, and Part III of our 2021 predictions series, which focus on predictions for medical device, airborne systems, and automotive development (respectively).

What product, systems, and software development trends are you expecting to take shape in 2021? 
Josh Turpen:

I think 2021 is when investments in Machine Learning (ML) and Natural Language Processing (NLP) will start to pay off. We’ve seen an increase in capabilities building to the point that material work can be done using these technologies. Supply the right data and real insights can be delivered.  

In terms of product and systems development, what do you think will remain the same over the next decade? What will change? 
Josh Turpen:

The Digital Thread will continue to be a focus for systems engineers. Connecting disparate data streams into a cohesive view of product development remains a critical, if elusive, goal.   

With more investment in product development more rigor will come. Connecting development efforts to value, reducing product delivery risk and ensuring that budget holders “get what they paid for” will become a prime responsibility for development teams. 

RELATED: What is the Definition of a Digital Thread?

What sorts of process adjustments do you think development teams will need to make to be successful in 2021?  
Josh Turpen:

Focus on systems and processes that deliver value and don’t be afraid to jettison or modify those that don’t. We’ve all been told there’s a “way to do it” and we all read the blogs that claim success with a methodology. Don’t ignore the anecdotes but focus instead on what works for your development and never lose sight of delivering a valuable product.  

What do you think will be some of the differentiators between a company surviving to see 2030, and those that do not? 
Josh Turpen:

Companies that are not focused on product development at scale are in trouble. Their competitors are. 

Where do you see Jama Software fitting in as the product development landscape evolves, and what can our customers expect as 2021 approaches?  
Josh Turpen:

The definition of value, and the verification that the product delivers that value, are where Jama Software will continue to focus. We’ve got some exciting things on the horizon for variant management, test validation, and ML/NLP that I’m excited to get into the hands of our customers.  

Is there anything else you’d like to add about the future of complex product and systems development in the upcoming year and beyond?  
Josh Turpen:

I’m consistently impressed with what our customers are doing. From launching rockets to saving lives it is an exciting time to be in complex product development. I can’t wait to see what customers will build next with Jama Connect! 

Thanks for tuning into our 2021 Predictions Series! To see some of the incredible things our customers are building with Jama Connect, visit our Customer Stories page.  



Product Team

A product team and an engineering team could be viewed as two sides of the same product development coin. So, ask yourself, “Who only uses half a coin?” It’d be like using just one side of your brain.

In a perfect product development world, communications are seamless, specifications are clear, and product and engineering teams work without friction. Except, we live in the real world where life is messy, responsibilities overlap, specifications change, and the way teams interact can introduce friction.

In the rush of product development, it’s important to establish boundaries for each team while also working as a unit and develop processes to head off trouble before it begins. This only gets more complicated with bigger and more technical projects.

The Product Team

Before the first line of code is written, someone needs to own the product and fully understand what’s being built and why.

It’s the product team that should understand the why, inside and out. From ideas that turn into research that guides specifications to conversations with customers, the product team is lining up the rubber ducks in neat little rows so engineers can focus on the technical problems. What do the ducks look like? How do they sound when squeezed? And what do users want?

Product teams tend to dream big, but they must also manage expectations and align goals with those of the overall business. That’s why it’s a good idea to get an engineering lead involved early in the planning process to build cross-team cohesion.

For example, if you’re building the next great blogging platform, maybe your commenting mechanism is the “killer feature” and the engineering team needs to focus on issues like authentication and moderation tools. How much of the apple can we bite off at a time? Such questions circle back to product team responsibilities like the business goals and strategy. Prioritization is the byproduct of open talks between teams to determine what is needed and what can be delivered on time.

It’s also worth noting that tension between teams is a natural and healthy aspect of working cross-functionally. Each team has its own set of internal goals, but those must align with overall strategic goals for the company (or product).

The product manager serves as the CEO for whatever is being built. If he or she asks for the moon, there must also be the understanding of the challenges that await.

RELATED: Realigning Engineering Teams for Remote Work with Minimal Disruption

We’ve probably all been in a meeting where something ambitious is proposed and the engineering team rolls their eyes, thinking, “If we could build that we’d all be zillionaires.” The balance here is one of awareness.

Technical teams need to be just as ambitious as their product counterparts, and that means understanding a little bit of each other’s worlds to know what’s feasible and what will cause deadlines to crash.

The Engineering Team

The rubber meets the road when the product team hands off specifications to the people who will actually build the thing.

Engineering is the technical team of developers and managers who write the code and create the front end, so the clearer the guidance they get upfront, the better. That doesn’t mean micromanaging from the product team, but it does mean regular check-ins to increase buy-in, build cohesion, and avoid surprises.

Going back to our blogging platform example, let’s say there are some whiz-bang features on the front end that will dazzle users. A product manager might tell engineering to focus on those features. If the product team has done its job, the tech leads can accurately inform them how long it will take to implement the features.

However, they could just as easily warn the product team that there are backend issues to tackle to enable those frontend goodies. There’s no way to have one without the other, and this is another area where the tension comes in, as timelines might have to be readjusted.

RELATED: Learn more about product development strategies for systems engineerings by downloading our white paper.

When teams understand that they’re on the same side, everyone can take a step back to see the full map and make sure they’re headed to the same destination. It’s also where teams who understand each other excel.

Product must comprehend the engineering team’s needs, and engineering must grasp the importance of the product planning that came before. Maybe it’s a matter of a few sprints to see where the marquee feature is in a week. Or perhaps a lower-priority feature that really puts a kink in the line just needs to be delayed.

Either way, the only solution is to drop the egos and hash things out in realistic terms. Again, if product has done the job, both teams should be like looking at the release like a big X on a treasure map and walking there together.

One Team

If all of this sounds familiar, you’re not alone. Everyone in these teams is working under a number of different dynamics.

It could be that product feels it has defined everything so thoroughly that the engineering team can take the ball to the goal after a simple handoff. Of course, that is rarely the case.

More likely, there’s a stream of reviews to comb through and see how things are advancing (which, if you’re using the right solutions, can be handled faster and with less meetings) while moving the goalposts when one side reports a change in the variables.

So, what do you do? Learn to function as one team while respecting each other’s territory. After all, you’re all headed to the same goal. Even if your organization compartmentalizes each side, find a way to cross the streams. For many, the move from Waterfall development to Agile created a more efficient, functional model for developers, and a variation on that theme can serve you here as well.

RELATED: Optimize Engineering Team Collaboration to Streamline Product Development

First, create a great set of fundamentals with your product team by bringing in engineers as early in the planning stages as possible. Ask what’s feasible and go to lunch and dream about unlimited budgets. Integrate the engineering team as best you can, because their insight will save squabbling down the road. Then create specifications that are realistic.

Next, empower each side of the table with respect. Product may want the moon tomorrow and engineering will explain how much lift is needed to get there, so friction is inevitable. In the big picture though, both sides are arguing for the same goal, so keep that front-of-mind and allow room for either side to concede territory as needed. Conflict is normal and necessary, but if one side is utterly powerless and is continuously overrun, the “team” notion falls apart and the idea of collaboration breaks down.

If both teams are aligned, truly listening and making necessary adjustments, there’s no reason even large, complex projects can’t be finished on time and on budget. It takes work, especially if an organization is averse to cross-functional teamwork.

The payoff, though, is happier, more productive teams who share in the product’s success. It’s up to both sides to come to the table ready to cooperate.

Does that mean having certain boundaries? Yes! It’s unlikely the engineering team has done the market research to say whether a feature is desired by users. And it’s equally unlikely that the product team will accept a major delay for technical implementation if it was in the original specification.

Each side has a job to do, but the key is understanding that everyone is marching under the same umbrella in the end. That’s why it’s important to play the role you’re in while listening and accepting the experience and knowledge of the entire team.


Product Development Challenges
Help us personalize your content experience!

Download this whitepaper to learn how to reduce the risk of failing to comply with regulations, and how a single source of truth enables collaboration across distributed teams, increasing insight and minimizing the introduction of risk:
Safeguarding Regulated Products Amidst Growing Complexity: A Frost & Sullivan Executive Brief

Click to download this informative whitepaper and learn how to up-level your risk management practices:
Conquering the 5 Biggest Challenges of Requirements

Click to download this informative whitepaper and learn how to enable testing earlier in the process to reduce risk:
Verify, Validate, Trace, and Test

Download this whitepaper to learn how to reduce the risk of failing to comply with regulations, and how a single source of truth enables collaboration across distributed teams, increasing insight and minimizing the introduction of risk:
Safeguarding Regulated Products Amidst Growing Complexity: A Frost & Sullivan Executive Brief

Click to watch this informative webinar and learn how to establish effective review cycles across distributed stakeholders:
How to Streamline Reviews and Collaborate with Remote Teams, Customers, and Suppliers

Click to dowload this info-packed ebook to improve collaboration and alignment across key stakeholders:
Guide to Optimizing Engineering Team Collaboration

Dowload this ebook to learn the importance of tracing requirements without the headaches and risks of a traceability matrix in Excel and set your organization up for future success:
The Jama Software Guide to Requirements Traceability

In this webinar we address how to solve some of the key challenges teams face when integrating hardware and software requirements, risks, and tests, with a document based or legacy tool approach:
Managing Product Development Complexities Across Hardware and Software Teams

Dowload this whitepaper to learn how to manage projects more effectively and efficiently using collaboration, traceability, test coverage, and change management:
Successful Product Delivery

Dowload this eBook to learn the business value of better requirements, the four fundamentals of requirements management, and finding the right level of detail in requirements:
Best Practices Guide to Requirements and Requirements Management

Dowload this eBook to gain insights to help you thoughtfully consider potential requirements and test management solutions. Plus, get tips on how to get the buy-in you need to undertake the kind of change necessary to succeed with complex product development:
Selecting the Right Requirements Management Tool: A Buyer’s Guide

As part of an ongoing series, we’re looking at insights and trends uncovered within the Harvard Business Review Analytic Services study, “Bridging The Gap In Digital Product Design.”

Earlier this decade, a video encouraging kids to learn coding and featuring some of the biggest names in tech — including Bill Gates, Mark Zuckerberg and Jack Dorsey — went viral.

Released by the non-profit Code.org, one of the main messages of the video was that if more schools don’t start teaching coding and digital engineering principles, millions of the best tech jobs in America could eventually go unfilled.

These vacancies would be created by the explosive growth of technology across all industries and the finite number of qualified engineers to execute on company visions. Unfortunately, many companies are experiencing this strain now.

For instance, in the recent Harvard Business Review Analytic Services study, “Bridging The Gap In Digital Product Design,” one quarter of organizations creating smart products identified hiring and training hardware and software engineers as a major challenge.

Since Jama Software has been home to a number of excellent software engineers throughout the years, we wanted to share some of the lessons we’ve learned about what it takes to recruit, train and retain talent.

To do that, we talked with Laura Stepp, who has worked in human resources at several of the world’s top companies, and is now Jama Software’s Vice President of People.

Jama Software: In the recent Harvard Business Review Analytic Services study, companies say hiring and training engineering talent is one of the biggest challenges today. Are you surprised by that?

Laura Stepp: Anyone in high tech would tell you it’s a highly competitive marketplace for the right kind of skilled talent. In the US, we don’t produce enough engineers.

Also, technologies move quickly. For example, consider the idea of a connected product. That concept or word didn’t exist a decade ago. So you have all these people who were trained as engineers, but they were trained for a different world. And right now, the world is changing quite fast, so you need engineers that are comfortable with learning really quickly.

JS: What kind of value does finding the right engineering talent mean to an organization?

LS: There’s the technical skills, which are key, but more people are also realizing that you have to hire an engineer that is interested and willing to work in the way that you do. There is a methodology layer: Do they subscribe to Agile, or do they only know Waterfall?

And then I would say the third area people are probably screening for, certainly in start-up environments, is absolutely cultural fit. So, in addition to the way they engineer, there’s also the question of whether that engineer enjoys the way in which we operate as a company, meaning the values that drive our behavior. Is this an engineer that likes to collaborate or one who likes to work off in their cubby hole? And which way works best for our team?

As in all hiring — it doesn’t matter if it’s engineering or other — the more specific your requirements, the smaller your source pool.  Some of the best talent pipeline successes I have been a part of have been programs open to the entry level engineer with support for developing and grooming them over time.  This is a fantastic way to also improve diversity within the team.

Laura Stepp, Jama’s Vice President of People.

JS: What are some things you think companies can do to improve their standing with prospective engineers? 

LS: Companies need to be committed to establishing and then ensuring they are a workplace defined by integrity and safety. Ethical conduct and practices is good for everybody. And then, of course, you need to have good pay and benefits and strong managers.

When it comes to ethics and safety, if you get a rotten spot or a bad group in an organization, they can really have a large negative impact long-term.

We’ve seen some tech companies get taken down by just this issue, which is they underinvested in good-old-fashioned ethical operation, open-door culture, respectful workplace training and manager expectations. Organizations can pay a very heavy price if they underinvest here.

JS: What about retaining talent?

LS: Finding the right kind of human chemistry on a team is good, but also working with a “no jerks” rule can also be really important — especially if you want to hire millennial and female engineers, in my experience.  And trust me, people will be quite happy to share their horror stories with their friend and online which absolutely impacts a company’s talent brand.

Also, because engineers know how to keep their skills fresh, they learn from each other more than almost anything. So, I’ve found having a mentor who’s the senior engineer that will work well with or teach others is something people are thankful for.

JS: Having solid engineering leadership sounds really important too.

LS: It is. Engineering leaders set the tone and establish practices or expectations. They provide support and time. And while engineering is release driven, if they’re so obsessively release driven that there’s no time for the white space stuff, you can get yourself in a virtuous or demotivating cycle quicker than you think.

It’s those engineering leaders who do think about people stuff, not just technology, who have the more sustainable organizations.

JS: Do you see any trends in the next five years in terms of hiring engineers or hiring in general that people should be aware of?

LS: If products are getting more complex, then we’re either going to have to train in school or grow at work individuals who have more versatile skill sets that cross boundaries and can think in an integrated, holistic way about how the complexities come together.

More and more we’re going to see people who are either architects, systems or integration engineers. Because those are roles that inevitably connect things together.

You’ll have specialists but you’re also going to have people who are orchestrating the ridiculous complexity of producing products and trying to get everything to come out at the right time.

JS: Anything else we’re missing?

LS: There is an interesting theory that the problem with education right now is the jobs we’re training people for today really aren’t going to be the jobs of tomorrow. So how does education have to change?

It feels to me like education needs to build more practical skills and basic professional skills in addition to a learning mentality. Students today will need to learn how to adapt as much as they need to build some specialty capability. I think a lot of schools are trying to do things like internships or collaborative, work-education combinations that create a more useful end product and leave the student with some adaptable skills.

Read more expert analysis on the hiring and training challenges companies designing connected products are facing with the report, “Bridging The Gap In Digital Product Design.” The report also features insights from nearly 300 innovators from a variety of industries, including manufacturing, technology, healthcare, financial services and more.

As Jama grew, our Engineering department began to change overnight. Teams were outputting consistent velocities, we had upped our abilities technically on how we measured areas such as performance and quality, we began 8-week planning cycles, we doubled our Engineering team and we had a strong roadmap to follow but for some reason it didn’t feel right. Identifying what that was exactly is where the challenges began. Why was it that we’ve come so far as an Engineering team but didn’t feel we had reached the Agile utopia we were seeking?

So What Were the Issues?

First and foremost, we called ourselves an Engineering Team, which meant that we were all in this together and operating as the collective whole, however when you really observed what was going on you saw static individual teams focused on only their projects. This became clear one day when I was in a meeting with Product and was told that the “top priority project” needed protection to get it out the door. I put it in quotes because at that time I thought there were multiple priority projects but no clear communication on which one was higher than the other. I then decided to test this with my team. In 1:1’s I asked a sampling of my team members, not on that project, what they thought was the top priority. The way in which I received the answers told me we had an issue. Half of the people I asked didn’t know and thought that what they were working on was a priority project, the other half answered correctly but with a very guarded response, as if they were going to be judged if they got it wrong. I then asked one key question to some of them, “Do you feel empowered to help that priority project if it needs it”. The answer was “no”. Not because they didn’t want to do the right thing, but because of the pressure they felt to get back to the project they left and get it on track again. The teams felt they were being measured on hitting certain sprint goals even if the business made the decision for them to do something different that affected it. We needed to get to a model that allowed teams the flexibility to protect our priorities without a feeling of guilt for those ones they left.

Teams believed that with more measurement came scrutiny. I started hearing comments that teams felt the business cared about velocity numbers more than the value being delivered from them and because of this they were more focused on how to make their burndowns look good, rather than taking chances and shifting during a sprint if that affected how the burndown presented itself. Hearing this cut to the core of my being because I wanted teams to take chances, innovate and change the sprint if it no longer made sense. Why continue to build in a direction when you know it’s the wrong path? Also, I know that there is always a story to tell behind burndowns regardless of how they look. I’ve had plenty of teams show me poor burndowns, but then the explanation as to why, is where I find the true value of a burndown, because the team iterated and learned something about the project that forced a shift. This is what we needed to reward the continual learning and change to reach the overarching goal as we drove to the end of the project, not every burndown’s success.

Another issue was around Engineering Priorities. Some examples include items such as infrastructure improvements, removal of tech debt, automating certain processes or refactoring problematic areas of the code that slow us down. We tried our best to recognize these issues within our team and tell teams to budget a certain amount of time out of their sprints to take this on. This “peanut butter” approach seemed like the right way to go but it was very apparent progress on those items was slow, or abandoned all together, because it was too hard to balance those priorities with the project work teams needed to get done. More often than not, a team would begin their sprints, find new work because of discovery and this additional work would overrun the time we allocated for the Engineering Priorities. Now in this model we make projects out of them and Engineering gets a budget to form a team and take these on every cycle. This brings more focus instead of the context switching within a sprint from project work to something that may not be related.

Cross-pollination of technologies, team processes, best practices and overall learning about the application was low. We had our Agile ceremonies and other meetings to talk about these in a cross-functional setting, but in the end teams would go back and continue to practice what they always had done. As a smaller engineering team I had newer employees tell me they didn’t even know their peers that well on other projects. This just seemed strange given we’re all within a small vicinity of each other. So why not give teams a chance to change up their team composition based off of people they wanted to learn from, processes they wanted to try or technologies they wanted to learn?

Self-Selecting Teams

I Wasn’t Alone

After feeling this way for some time and hearing more and more feedback on how teams felt I began to wonder if it was just me or did others see it. I needed to see if Product felt this way, so I reached out to Derwyn Harris, one of our co-founders that’s in the Product team. Over lunch we discussed what we saw happening with the teams, challenged ourselves on what we thought we wanted out of the teams and talked about teams self-organizing around projects they could make the most impact on. The conversation was all laid on the foundation of empowerment and autonomy with the goal of increasing quality and decreasing lead time. In the end we walked away with a common goal and understanding of what we saw and what we wanted to change.

But wait, there’s more! Cristian Fuentes, one of our Engineering Managers, was also thinking of a way to further protect our team’s priorities to get work out the door, and Shane Patrick, our Sr. QA Manager, was building momentum around a centralized QA Team to help offload regression cycles from the other teams to protect project work. All of our ideas, thoughts and observations were coming to a head, which made it very clear that there was time for change at Jama.

“WE” Weren’t Alone

There was also validation in the industry of others trying models like this and having success. Two of the major players were Spotify and Valve, each doing something a little different but again built on the goal of empowering their engineers to make choices. Using these as case studies to gain confidence in our direction was key.

It Wasn’t Easy

Even though we had all this momentum from a leadership perspective we needed to make sure our teams understood what we were trying to do and why, gain alignment and test our theories. Derwyn created a Circle of Influence diagram to help us identify key stakeholders in the process and their overall support for it. A lot of conversations began with team members to get their feedback, and concerns, that helped us refine our approach. All of this happened over the course of a couple of months, because we knew we needed to make sure this was the right thing to do for Jama and our teams. A successful rollout required patience, listening and a build-up to buy-in.

Let’s Do This!

Now that you have some of the backstory let’s roll into how the teams formed around our priority projects. As of right now, we have an 8-week planning cycle that we plan for. Within those 8 weeks we run sprint lengths of 2 weeks. The goal of this planning cycle is not to load up all the sprints, because we all know that’s impossible and so much changes early on that rearranges your later sprints anyway, the goal is to provide enough clarity so the teams can have solid direction and know the release goals their striving for.

First we need to know our priorities. Product utilizes a process to help calculate this called Weighted Shortest Job First. This method combines a number of different criteria to help us evaluate a project’s importance. We use this method not only on roadmap features, but also on our Engineering priorities. It’s not an exact science but it gets us close.

Once those Product and Engineering priorities have been identified we provide one list for the teams to look at. This helps to bring clarity on the priorities and highlights ones we need to protected so we can get them out the door. Protection comes in different forms but simply put, if there is something a priority project needs, or if there is something that could potentially interrupt that project, teams around them are empowered to figure out creative ways to absorb those risks and keep them on track.

For us to get a good idea for the size of the projects they must also have an estimated duration in sprints and potential roles needed on the project to make it successful. For example, Project Unicorn could take up to 2 sprints to accomplish and it needs 3 Engineers and 2 QA Engineers on it to make it successful. This helps to recognize if a project is staffed appropriately and also exposes potential future scenarios for teams to roll off onto other projects.

Team members then get three votes after the Product Managers, or potentially a Technical Leader of the project, have had a chance to pitch their ideas to the teams. We are now doing this in a Science Fair format before the 8-week planning day. Once they have heard all they need to about the projects, they get to place their #1, #2 and #3 votes on the ones they are the most interested in, or feel they can provide the most value to the business. Once this is done the results tell us a variety of different stories:

  • Were teams able to staff the priority projects so they could be successful?
  • Did team members choose to move away from a project because they could influence higher priority ones?
  • Did we pick up Engineering projects that help with our efficiencies? (Examples: removing technical debt, shoring up infrastructure, increasing automation, etc.)
  • What were the projects that didn’t get chosen and why?

We then record the results and input them into a spreadsheet so we can further evaluate the choices. The goal is to not only make sure the top priorities are staffed, but we also want to do the best we can to place team members on projects that they have chosen (more to come on this). What’s fascinating is the number of scenarios and possible team combinations that you can form by reviewing the choices.

After we’ve done our best to predict where team members next tour of duty might be we open it up for collaboration and discussion. There may be more concerns that we didn’t think about, or other dependencies identified after self-selection has finished, but we try to get as close as we can so people know who they’ll be planning with when we roll into the 8 week planning day.


Self-Selecting TeamsThe Results

We are now in our fourth 8-week cycle utilizing this process. We continue to evaluate, change, iterate and find better ways of utilizing this model. Here are some observations after practicing this for a while now.

Priority projects are getting picked up and staffed with the talent they need to succeed. Through the first three 8-week cycles we staffed a lot of projects, and sometimes it was questionable if we were taking on too much. Because of this Product Management wanted to make sure we were not spreading ourselves thin, so we’ve started to implement WIP limits to meet our teams capacity and self-select on fewer projects. At the time of this post we will be starting our first cycle with these limits in place.

Cross-pollination is happening. Team members are learning more from each other. Some may be back end developers getting exposure to the front end, or just different technologies all together. Others may be on teams that are trying new processes such as Mob programming and pairing techniques that follow them to their next team. Agile techniques such as retrospectives, planning, estimating, etc. that are done differently from team to team are being shared. And knowledge of the application as a whole is increasing as team members with diverse experience of the application come together to solve common goals.

Teams are aware of the top priorities and have conversations around how to protect them. Because of this we feel more aligned as a team and are willing to accept project impacts if a team shifts off of theirs to assist in getting the higher ones out the door. The process increases fluidity in our teams to do this when we need to.

Still Working Out the Kinks

We’ve come a long way as a team with this model but are still evaluating and adjusting as we go. We’re far from perfect but I’d like that to be our goal. Here are some areas we continue to refine and recognize:

Not everyone receives a project they voted on. Because we don’t have infinite skill sets amongst team member’s certain projects may require someone with deep domain knowledge or technical skill because without them certain projects would cause risk. The good news is, this has only happened to a very small number of people, for the most part the majority of people get to be on a project that they picked. However, we try to remain sensitive to those that didn’t receive their pick so we can make sure we’re giving them their pick next time we run through our project selection. Long story short, no guarantees depending on business priorities. We have to keep the lights on, right?

We’re trying to “gauge happiness” by sending out surveys asking questions to our engineers. We did our first one in March and if you’re to look at the answers from a 10,000 foot view things look positive, and I do believe the results are exposing a level of happiness, however I’ve retrospected over the survey with my team and the next round we’re going to be more explicit on the questions we were asking, as they were too subjective and open for interpretation. Regardless, we’re trying to measure how people feel in this new model and are paying attention.

We’re getting better at trying to define Engineering Priorities and the value behind them. We want to do a lot of “good stuff” but also realize we only have so many people to do it with. We have to be careful with what we choose, so we can get the biggest bang for our buck.

Metrics, metrics, metrics. We have abandoned some of our metrics because we weren’t sure of the value they were giving us and instead felt more administrative. But we still have to prove the process is working so we’re continually reviewing how to best measure and represent epic lead time and quality measures. Also we still use agile Velocity and Burndowns to see how teams are doing, but those are only snapshots in time so we try to make sure we’re keeping our eye on the prize which is overall health of our projects as they reach completion.

We continue to evaluate work in progress project limits to find the magic number the teams can handle. This model is built to have fluidity in it so we must make sure we protect that as much as possible and aren’t spreading ourselves too thin.

How Do I Get Started?

Maybe this process sounds good to you and you want to try it out, but how do you know if it’s right for your company? I’m sorry to say that I can’t answer that for you. Only you know your culture, problems you have and how this could potentially help you solve them. But what I can do is provide you with some potential thought points for you to think about as you determine if this will work or not.

What problems would you be solving by trying something like this? Make sure you have a clear understanding of these by sharing them with your peers and leadership so you can validate them. This is the start of the buy-in process. If others around you identify the same issues you already have momentum.

Have clear goals that you’re trying to achieve. For example, our goal was to empower our employees to make choices which in theory should decrease epic lead time and increase quality. We’re still measuring these as I pointed out earlier but we are seeing results.

How flexible is your company? Do you already work in a company that’s Agile and accepting of change or do you work in a regulated environment that is change adverse because it may introduce too much risk and uncertainty? If it’s the second, rollout will be slow and painful so find ways within it to make very small, incremental changes that in the end align to your goals.

I mentioned this briefly in the “what problems are you trying to solve” paragraph, but felt it is important enough to give it focus. Make sure you have leadership support. It was key at Jama that we had this from our Engineering and Product VP’s as well as the Director of Product. Without their willingness to let us turn the world upside down and try something different, the idea would have died after initial conversations. They’ve been instrumental in giving us the freedom to implement this while also being very involved in its success.

And last but certainty not least, do you have TRUST? Trust from the business and trust from the people around you? If we didn’t have this, I don’t know where we’d be today. For example, imagine going to your Product Management organization and saying “Hey, those static teams that you’ve relied upon for the last few years, we’re going to blow them up and allow them to do what they want based off of priority”. Talk about a scary message to accept, but we were trusted by those around us that we have the talent and understanding to do the right thing.

So what are you waiting for? Don’t get bogged down and accept your problems that in the end lead to low morale and poor quality products. You’ve hired smart people to do great things. Empower them to do so regardless if it’s something like this model or another idea you have. Be brave, give it a try, iterate on it and change your organization for the better!