collaboration Archives

Tag Archive for: collaboration

Too often products fail due to poorly managed requirements. A requirement is a document that defines what you are looking to achieve or create – it identifies what a product needs to do, what it should look like, and explains its functionality and value. Without clearly defining requirements you could produce an incomplete or defective product. It’s imperative that the team be able to access, collaborate, update, and test each requirement through to completion, as requirements naturally change and evolve over time during the development process.

There are four fundamentals that every team member and stakeholder can benefit from understanding:

Planning good requirements: “What the heck are we building?”

A good requirement should be valuable and actionable; it should define a need as well as provide a pathway to a solution. Everyone on the team should understand what it means. Good requirements need to be concise and specific, and should answer the question, “what do we need?” Rather than, “how do we fulfill a need?” Good requirements ensure that all stakeholders understand their part of the plan; if parts are unclear or misinterpreted the final product could be defective or fail.

Collaboration and buy-in: “Is everyone in the loop? Do we have approval on the requirements to move forward?”

Trying to get everyone in agreement can cause decisions to be delayed, or worse, not made at all. Team collaboration can help in receiving support on decisions and in planning good requirements. Collaborative teams continuously share ideas, typically have better communication and tend to support decisions made because there is a shared sense of commitment and understanding of the goals of the project. It’s when developers, testers or other stakeholders feel “out of the loop” that communication issues arise, people get frustrated and projects get delayed.

Traceability & change management: “Wait, do the developers know that changed?”

Traceability is a way to organize, document and keep track of the life of all your requirements from initial idea through to testing. By tracing requirements, you are able to identify the ripple effect changes have, see if a requirement has been completed and whether it’s being tested properly, provide the visibility needed to anticipate issues and ensure continuous quality, and ensure your entire team stays connected both upstream and downstream. Managing change is important and prevents “scope creep”, or unplanned changes in development that occur when requirements are not clearly captured, understood and communicated. The benefit of good requirements is a clear understanding of the end product and the scope involved.

Quality assurance: “Hello, did anyone test this thing?”

Concise, specific requirements can help you detect and fix problems early, rather than later when it’s much more expensive to fix. In fact, it can cost up to 100 times more to correct a defect later in the development process after it’s been coded, than it is to correct early on while a requirement. By integrating requirements management into your quality assurance process, you can help your team increase efficiency and eliminate rework.

Requirements management can sound like a complex discipline, but when you boil it down to a simple concept – it’s really about helping teams answer the question, “Does everyone understand what we’re building and why?” When everyone is collaborating together and has full context and visibility to the discussions, decisions and changes involved with the requirements throughout the product development lifecycle, that’s when success happens consistently and you maintain continuous quality. Not to mention the process is smoother with less friction and frustration along the way for everyone involved. And, isn’t that something we’d all benefit from?

Learn more about how to write high quality requirements.

In my prior blog post about pair-programming, I introduced the concept and explained why Jama Software adopted it as a practice in our engineering group. While we have seen many benefits from pair-programming, the practice may not be appropriate for every organization or team, and also does not come without costs and challenges.

In the year or more that we have had teams utilizing pair-programming, we have become familiar with the costs and challenges. This has been helpful for learning how to adjust to the practice on an individual and team-level and ensure that its application has been successful.

Costs

At first glance, pair-programming appears to be an incredibly inefficient use of expensive software engineering talent. Organizations that have no experience with pair-programming will often be initially skeptical for the obvious fact that two engineers are working on the same task. The apparent overhead of pair-programming tends to be the primary factor in push-back from engineering management when pair-programming is being considered for adoption.

It is indisputable that pair-programming adds an overhead to development efforts by increasing the man-hours required. However, assuming that pair-programming doubles the cost is a reductive misconception that equates programming with time typing on the keyboard; ignoring the analytical aspects of it.

Empirical studies have yet to quantify the exact costs or benefits of systematic pair programming as compared to individualized work. The most commonly cited statistic indicates that it can add a 15% increase to the time it takes to complete a task over an individual developer working on it.

Our experience has shown that this additional cost is minimal in comparison to the benefits it provides our teams; better quality, better understanding of the code, and lower risk. It is these benefits that allow us to become more agile in the long-term. In this sense, pair-programming is a strategic investment in the software and the team charged with improving and maintaining it. Despite increasing the time to complete a task, pair-programming also aids in reducing the count of bugs not caught during the development process, and improving the extensibility of the system over time.

Pair-programming, just like any other Agile Software Development technique, is one that should be applied to the appropriate situation. While pair-programming provides a great way to ensure better design in the codebase and lower the risk associated with having one person responsible for a system, it is not the right instrument for every task.

Poorly applied pair-programming leads to the worst-case outcome of doubling the time needed to complete a task. In order to use pair-programming effectively within your organization, it is important to be cognizant of situations where it is unnecessary and can be an unproductive use of knowledge workers.

Challenges & common pitfalls

There exist some common situations & indicators of non-performance for pair-programming that are important to bear in mind. Being mindful of these circumstances can help identify necessary adjustments to make pair-programming more successful within your organization.

Situational issues

Pair-programming is NOT the right tool for every task

When a task is simple enough, such as a dev-chore, a defect writeup, or a spike, pair-programming is not always appropriate. Adopting pair-programming in all cases is not efficient and can severely limit the productivity of a team and increase the costs of development efforts exponentially. When a Scrum team discusses new development work, is it important to identify whether or not pair-programming would be beneficial for a particular task. Being dogmatic in applying pair-programming is never appropriate. A good rule of thumb is that pair-programming is best applied to production code that needs to be maintained.

Pair-programming is NOT right for everyone

Pair-programming is an activity that takes place outside of the comfort level of some engineers, and it cannot be forced upon them. Deciding to engage in pair-programming needs to be a mutual decision of the scrum team, and the practice needs to be open to criticism within Sprint Retrospectives for potential refinement. It is best to gradually introduce the practice, as with every Agile concept, for those who are tentative on the idea.

There can also exist other issues within a team that make pair-programming a difficult undertaking. Pair-programming puts two engineers in very close contact with one another, and can be problematic if relationship issues, or personal hygiene issues are present.

Remote pair-programming

Pair-programming benefits immensely from team members being co-located. When teams do not share the same workspace, difficulties such as delays in coordination, the integration of technical tools, internet connection speeds, and the possible need for additional technology to support pairing are introduced. Remote pairing can add immensely to the existing overhead cost of pair-programming.

Indicators of non-performance

Lack of engagement

Both engineers must be actively engaged throughout the pairing session in order to gain the benefits of pair-programming. To mitigate potential distractions, some pairs agree to not check their phones or emails during the session, leaving that for breaks. Many also use the Pomodoro Technique, to ensure that energized work and breaks take place at regular intervals during a pairing session.

Silence

If the driver is silently typing code without consulting the navigator, or the navigator is not providing insights, then something is awry. Pair-programming is about active and candid analysis of the existing code and all new modifications being made to it. This is best performed through conversation.

“Watch the Master”

“Watch the Master” is a scenario that often occurs when one person in the pair is more experienced that the other. A common situation for this phenomena is a senior engineer working with a novice engineer. The senior engineer may skip what they think to be unnecessary explanation, while the novice engineer may feel to timid to ask questions or challenge the approach taken, deferring to the senior member of the pair. This is similar to the aforementioned problem of silent disengagement, and does not provide the benefits of mentoring that pair-programming provides.

Side-effects

Loss of Confidence

When first being introduced to pair-programming, some engineers feel that they lack the same understanding of their work than what is produced when they work as individuals. This is a circumstance that is especially common for the novice programmer in a senior-novice pair.

It is important within a pair-programming setting for each participant to be honest about their understanding before moving onto the next major phase. This loss of confidence is in many ways a side-effect of pair-programming’s primary effect of reducing strong code-ownership in favor of collective code-ownership.

Lack of confidence can also indicate of a lack of trust for their counterpart in a pair. As individuals work together, it takes time for trust and mutual confidence to build. Pair-programming can be a great exercise for improving rapport between team members, but it takes time and effort.

Lack of code-ownership

Related to the loss of confidence one might have about pair-programming is the perspective that it erodes code-ownership over implemented features. Code-ownership is a nuanced concept, that has both meaning to engineerings and managers.

Code-ownership can be a source of pride for the engineer who implemented a feature as an individual contributor. For managers, knowing the sole point-person for a portion of the code base is is useful when trying to put out fires. Letting go of these landmarks in favor of a team-focused ownership concept can be a tough cultural change for an engineering group.

Two engineers being responsible for the code output of a user story may at first glance seem as though it reduces accountability and responsibility. Reducing accountability or responsibility is NOT one of the goals of pair-programming; instead it is a tool to increase accountability of the entire team by moving the needle towards collective code-ownership.

Pair-programming, at least in the case of Jama, was a way to push us towards a culture of collective code-ownership, where every member of the team feels both responsible and capable of contributing towards the progression of the software, rather than particular individuals. Having one engineer too tightly coupled to code they have written in the past is an organizational anti-pattern and a risk to the business.

What’s next?

For many engineers & software engineering organizations, pair-programming is a novel way of working that turns the commonplace individual-contributor mode of working on its head.

As I explained above, adopting it as a practice is not without it’s challenges. If you are still convinced after reading this post that it is something you would like to try, do so on as small of a scale as possible. You might first try pair-programming on an individual level with a fellow team-member, and then branch out by trying it at a scrum-team level. If you are feeling very confident, you might even try mob-programming, an approach that involves the entire team.

On a chance bus ride down MLK to our Jama office a few months ago I happened to share a seat with a colleague in our Engineering Department, Bryant Syme. He had only been working for Jama for a few months and to be perfectly honest I hadn’t spoken to him much yet. We talked a lot about recent events in the office, but also talked about some of his previous work experiences. This is the first time I had ever heard about Mob Programming and the many potential benefits it can bring to a team of engineers. It planted the seed for me to introduce it to my own team and eventually start evangelizing it to the rest of our department.

What is it?

Mob Programming is a style of paired programming, but with the entire team involved instead of two developers. Every person involved in the story should be in the Mob Programming session and actively contributing, including Product Managers, DevOps and QA Engineers.

Think of Mob Programming as a tool for getting through larger, more obtuse stories and epics. The team will crowd around a single screen with one person driving and will talk through everything from acceptance criteria and design decisions, to implementation of the code and even test cases.

Mob Programming has many benefits:

Shared ownership over decisions.
Better quality code.
Ability to break through large tasks easily.
Team bonding through working together.
A great way to teach other team members various skills.

This style of work doesn’t need to be limited to programming. It could also be great to work on any project, from writing a document to planning for future work, to doing performance testing.

The tenets of Mob Programming

The main tenets of mob programming that everyone should follow are:

Use one keyboard and screen
Use a private room
Select a time keeper to rotate who is on the keyboard every 15 or 30 minutes.
Everyone gets time at the keyboard, even non-programmers.
Take a story from start to finish, or in other words: from planning to coding, to testing, to done.
Take breaks when you want.
A session should span an entire workday.

Each of these tenets are flexible and should be discussed with the group before starting. One thing I’ve had a lot of luck with so far is pausing the timer to do whiteboard planning, for instance. We also usually take however much time we need at the beginning of the session to sketch a rough plan of what we are going to do, in order to stay on task as people switch around.

One keyboard and screen

This allows the team to concentrate without the distraction of e-mail, chat applications or other work. Team members may come convinced that they will need to work on other activities since there won’t be enough to help with when they aren’t at the keyboard. I had such an encounter with one of my teammates who was certain that there would not be enough for him to do. You will need to remind them that this is not a normal meeting and that you need their full attention. In the case of my teammate, I conceded that he could bring his PC as long as he kept his attention on the task at hand. He agreed and ended up being so engaged that he rarely, if ever, looked at his own screen.

One rule you can bend here is that research on one screen can be boring for the team to watch and help with. This is an appropriate time for other team members to use their own PCs to help do research (as long as everyone is staying on task).

Use a private room

This moves the team to another space both physically and mentally, and also prevents outside distractions. Other teams should respect that you have shut the doors and should not interrupt you. But if you are interrupted, team members should volunteer to chat with that person outside of the room to allow others to keep working.

Rotate who is on the keyboard every 15 or 30 minutes

Decide on a good time interval at the beginning of the meeting. I recommend 15 or 30 minutes depending on how many people are in the group, but other time increments are also fine. I’ve found that a group of 4 or less people works best with 30 minute intervals, wheras 5 or more works best with 15 minute intervals. Its just enough time to get some work done, but also enough for everyone to rotate through in the large group.

Bring a timer with a loud alarm. I usually use the Clock App on my iPhone and turn the sound way up. When the alarm goes off, whoever is at the keyboard should immediately take their hands off and let the next person rotate in, even if they were in the middle of typing. The thing to remember here is that it’s not about one person working while the others watch, as it is about everyone working on the same thing. Whoever else rotates in should easily be able to pick up where the last one left off.

A clock that resets itself is also ideal, since you don’t want to forget to start the timer.

Everyone gets time at the keyboard, even non-programmers

Whoever is helping should have a chance at the keyboard, even if they are in a QA, PM or DevOps role. Remember that everyone is working on the same task and watching and directing what the driver is doing, and it should not matter much who is on the wheel. It’s ok to be a backseat driver in this situation.

Participation also keeps everyone at full attention! Keeping the same person or only developers will become boring for others in the room if they never get a chance to participate.

Take a story from start to finish

Even when coded, the story isn’t finished, it still needs to be tested! Work on your test cases as a team. Personally, I am a QA engineer and getting other team members to help work on making quality test cases is very validating and helps us be less black box.

Whatever is required to get that story into the “Done” column should be done during this session. In addition to getting higher quality code, test cases and automation, this also tears a lot of walls down between roles. A lot of our developers often don’t have much of an idea for what DevOps or QA engineers “do”. This is a perfect chance to get cross-team collaboration and boost how your team works together!

People are allowed to take breaks when they want

Bathroom breaks, coffee breaks, lunch breaks should not be discouraged, but be warned: people will want to keep working, so mandatory breaks may be needed!

Mob programming can also be exhausting, if someone needs a few minutes to take a breather, they should be allowed to simply leave and come back when needed.

A session should span an entire workday

This one has been difficult to schedule a lot of times. So far we have managed to schedule one full day and several half days of mob programming. Most literature I’ve seen on the topic so far recommends the full day, if possible, though. If individuals need to leave for meetings or other commitments, there should still be enough people left to absorb their absence.

Conclusion

Mob Programming is a great tool that can be used to effectively chop down and complete large stories and epics. Remember if you are trying this, review the tenets with your group, such as sticking to one screen and one keyboard, as much as possible.

This is also great for bringing other team members up-to-speed with certain design patterns or tools. Someone who never uses the command-line or has never dealt with a certain language before will likely get a chance to learn a lot.

Everyone in the room should be involved, don’t limit it to just programmers, or others will get bored and not be as engaged. Remember to invite everyone in your team to the session, including the Product Managers, QA and DevOps Engineers.

And of course remember to have fun! Odds are your team will have a blast and work just a little better together than before the experience.

Within Jama, we pride ourselves on “drinking our own champagne” — using Jama to build Jama. It’s a rare occurrence in software development that you get to design and build the very product that is core to how you work, one that makes your everyday tasks more pleasurable. Our product development organization uses Jama to manage our requirements, capture product and design decisions, and flesh out product ideas and build backlogs. The communication and collaboration features in Jama are key to keeping our engineering organization aligned with the product and business departments.

While we all work in Jama, our engineering teams use an agile scrum methodology and their day-to-day sprint planning and execution is managed in JIRA. Core to our workflow is the seamless synchronization between Jama and JIRA. We’ve used our original JIRA connector for this purpose, but when we launched the Jama Integration Hub, based on the Tasktop Sync product, a far superior tool, it naturally became a priority for engineering to make the switch.

Rolling out the Jama Integrations Hub at Jama

When we launched this initiative there was much to learn about the Integrations Hub and how it fit into our agile workflow at Jama, so we decided to take an incremental approach to the change. We have a number of scrum teams so we set out to migrate them one at a time over a course of a few sprints, allowing us to incorporate learnings from each migration and refine the process and our usage of the Integrations Hub. The nice thing about the process of switching to the new Hub is that you can migrate your teams and workflow away from our original connector incrementally, so the two tools can work side-by-side until all teams are completely migrated over to the new Hub.

We started out by engaging with one of our own implementation consultants, Matt Mickle, to learn about the Hub and the migration best practices. We mapped out our own agile development workflow, and the Jama- and JIRA-specific workflows that would be integrated. We created a timeline and created documentation that we would refine as we discovered more best practices for our specific needs. We also set up a migration support team and escalation process in the event we ran into any issues post-migration.

With this important up-front planning we knew what a migration looked like, how long it would take and how it would affect the capacity of the team during the migration process. In a truly agile way we had enough to start our incremental approach.

What we learned in setting up the Jama Integrations Hub

After we started the first team migration to the Integrations Hub we discovered a few issues which we quickly resolved, and then added new efficiencies to the migration process (more on that below). We also quickly learned that if we wanted to take full advantage of the Integrations Hub’s templates we needed to clean up our existing JIRA workflows. Up to this point, we didn’t have a consistent JIRA workflow, nor a naming convention. Remedying this problem as part of the migration process had the added benefit of establishing consistency across our teams and actually made our own JIRA administration much easier. Once we cleaned up our JIRA workflows we were able to take advantage of the Integrations Hub’s templates, adding a Story Template and a Defect Template, which gave us huge efficiencies. Now migrating a project, or even setting up a new project, is a matter of simply creating mappings from our existing templates.

Another lesson we quickly learned was the timing of all the various steps involved in migration. Our goal was to have a streamlined process for migrating teams to the Integrations Hub with little downtime. We determined that we could creating the Jama and JIRA filters needed for the Integrations Hub’s mappings the day before the migration, saving time waiting for a schema refresh. Huge amount of time saved!

Our next challenge was scaling the migrations and administration of migrated teams in the Integrations Hub. We already had a few tips from Matt Mickle about consistent naming of mappings in the Hub. We came up with a naming convention that incorporated the team name, item type, and the type of mapping. That way we could just simply look at the mapping names to know what they were instead of having to open them up to see what they were mapping and which team they belonged to.

A better workflow makes for a better product

Today we have all the scrum teams in engineering migrated over to the Integrations Hub. We have a well-documented Hub set-up process and naming conventions. Our JIRA workflow for migrated projects is now consistent across teams, which we found actually improved our Jama workflow, too.

We also understand the Integrations Hub a lot better now and can take advantage of all the new features with each release from Tasktop. For example, the ability to scope mappings by project, introduced in the Jama Integrations Hub 4.3, is a very useful feature and allows for more flexibility in how we structure projects in Jama.

The biggest win for our team, though, is that now that we now that we have integrated our Jama and JIRA workflows we have better insights into our product development process via a transparent workflow from product requirements through test results. Moreover, the integration of the data from each tool allows us to seamlessly jump into each system without paying the tax regularly associated with switching between tools, losing context, and waiting for data to synchronize across systems. This is a big time saver for our engineering teams and makes it seem like a single interconnected workflow instead of separate systems that we’re using.

Tips for a successful migration to the Jama Integrations Hub

Map out your end-to-end development workflow. While we use JIRA, the Hub also integrates with Version One, Rally, and Team Foundation Server. Include in your mapping how your development tool workflow meets your Jama workflow.
Utilize Integration Hub templates. The Hub’s templates are a huge time saver and ensure a consistent process.
Use consistent naming in your filters and mappings. This makes managing several teams and mappings much easier and allows you to scale your integrations with your development tool.
Make your development tool workflow consistent. Once we did this we found it was much easier to scale our integration and actually helped bring more order and consistency to our own JIRA workflows across teams.
Document your migration procedure. We created a checklist to ensure a repeatable and consistent process which could be improved over time.
Create your filters ahead of the migration. By creating the needed filters for the Integrations Hub mapping the day before the migration and then refreshing the Jama and JIRA schemas within the Hub, it made our actual migration process much faster.
Work with your Jama Customer Success team. For us, inside of Jama, this meant having someone from consulting and support available to assist. For you as a customer, we recommend working with your Jama Customer Success team to quickly deal with any issues as they come up. Once you’re through the first few migrations the process will get faster and easier.

Our team would be interested to hear from you about how you’re managing workflows between teams, whether you’re using Jama or not yet using Jama. Do you have integrations between the various tools that your business, product and engineering teams use?

Employee engagement is becoming a buzzword in many enterprises today. According to the talent research firm Bersin, 79 percent of businesses are very worried about engagement and Gallup research shows that only 13 percent of employees are highly engaged at work. I recently wrote an article for CMSWire in which I discuss the essential elements to employee engagement.

I believe this problem stems in part from how organizations approach the delivery of vital products and programs which are core to their business. Many executives forget that building products and managing projects has always been an inherently social process. Humans have a fundamental desire to feel connected to one another when they work and to know their work makes a significant contribution.

Recent social business technologies have been recognized for their ability to drive productivity. McKinsey estimates employee productivity can be increased 25 percent through adoption of social technologies and establishing a “networked enterprise.”

It starts with bringing the entire organization together around the collective mission. Social business technologies can be instrumental in reversing the trend of focusing only on tasks because they can provide the Big Picture for every employee, often in a highly visual format.

Using social apps to foster a sense of inclusion for employees is more than just deploying a piece of software. It represents a significant cultural shift at the organization. It’s about changing from a mindset where any extraneous information beyond the task itself represents the potential for distraction, to a more enlightened perspective where employees can be not only trusted with these insights, but encouraged to seek them out.

Read the full article here and tell me your thoughts on employee engagement in the comments below or find me on Twitter.

The following is the first of a five part series excerpted from our whitepaper Top Four Frustrations of Software Engineers.

Anyone who works closely with software engineers understands it takes a big brain to do what they do, even if it’s never really understood exactly what they do or how they do it. But just because you spend the bulk of your time in an obscure world of ones and zeroes, it doesn’t mean you don’t love being empowered to discover uniquely creative ways of solving complex problems.

You simply want a firm grasp on the problems you’re tasked with solving and to be allowed to solve them your way.

But when your team is mired in a poor product delivery system, you and your team likely spend too much of your limited bandwidth deciphering unclear requirements or seeking further explanation of insufficiently described problem statements.

In today’s increasingly complex product  delivery workflows, smoothly handing-off work from one life cycle stage to the next requires  clear cross-team communication. But handoff difficulties too often become bottlenecks that  stall your productivity, especially within delivery environments where teams are siloed and communication lacks efficiency and transparency.

You need complete visibility into the requirements document as it shifts and into every phase of the product roadmap, as well as real-time insight  into the related activities of all delivery team members. When that’s the reality, you become a creative problem solver, empowered not only to develop innovative solutions to the challenges your product’s tasked with overcoming, but also to feel passionate about your work while doing it.

Although the challenges mentioned thus far relate specifically to just a few of the many tasks typically required of a software engineer, together they speak in broader terms about a fundamentally flawed product delivery system.

Fixing it requires an entirely new mode of communication, which demands a comprehensive solution to some of the most common challenges:

A “Task” Mindset With No Context

When problem statements fail to provide a thorough description of what needs to be solved, you become a taskmaster. All too often, you’re “tasked” with a specific request, such as “Change this drop-down menu to a list with radio buttons.” Of course, you can handle that, but why are you being asked to do so? What’s the larger problem? By providing the proper context, such as “The drop-down menu makes the user experience too cumbersome,” you’re enabled to creatively address the bigger picture instead of simply completing a task that’s really just a Band- Aid. To address the challenge, you need complete visibility into what is being built from Day One.

Endless Rework

Poorly defined requirements lead to incomplete solutions—a situation that results in unnecessarily reworking the same requirements, definitely not the best use of your time and talent. What you need is a proactive, inclusive system of collaboration that lets you weigh in on the requirements early in the product delivery life cycle.

Legacy Code

Today it’s very rare for a development team to work on a greenfield project. Given the reality that virtually every new software release must be developed to operate harmoniously with legacy code, you’re routinely presented with unique challenges—which become major process hindrances when you lack sufficiently supportive documentation. The solution hinges on having access to a central information repository that provides comprehensive insight into what has been documented and decided upon.

Shifting To An “Embrace Change” Mentality

Why do defects continue to be added to the backlog every time a test fails? Because when you’re focused on immediate tasks, with deadlines looming, issues that should be addressed as part of the current iteration get bumped down the priority list. Or requirements change and you (and other engineers whose work is impacted) aren’t made aware. Fixing the situation means implementing a system that not only ensures you’re informed when requirements change, but that also tracks cross-project relationships and displays how new information impacts the entire product team.

Read the second part of the series, Top Frustrations of Software Engineers: Task Mentality.

Download the full whitepaper, Top Four Frustrations of Software Engineers & Tips to Avoid Them

Note: The following is an excerpt from our Forrester Consulting commissioned report, The State of Modern Product Delivery. Read the full report for key insights on the current trends and challenges in product delivery.

Diversity of opinion is good, except when it gets in the way. Differing priorities compound the difficulties of product development when they lead to conflicting signals. Product development teams often find themselves caught in the middle, negotiating uneasy compromises between parties that see the customer problem differently. As with most forms of counseling, getting the issues on the table and clearly communicating goals goes a long way toward resolving conflicts.

The customer often lacks a consistent voice. Different functional groups will see the customer problem in different ways. None is completely correct, yet often each group sees its issues as the most important. The reality is that no product is complete until all perspectives are fairly represented. Getting the issues on the table to make the choices clear helps defuse the conflict and create healthy discussion.

Executive leadership may need to arbitrate. One of the benefits of active executive participation in product development is that misalignments, once spotted, can be quickly resolved. Differing priorities are often the result of organizational misalignments that are beyond the scope of the typical product team. Engaging executives, on the right level and the right time, can resolve the conflict before it affects product delivery.

Confused priorities lead to confusing products. Customers become frustrated with inconsistent solutions. When services or support offerings don’t align with the product they have purchased, dissatisfaction sets in. Ensuring a consistent customer experience goes far beyond the product itself.

Read the full Forrester Consulting report on The State of Modern Product Delivery complete with key recommendations.

Jama co-founders Eric, Derwyn and Sean collaborate with the dev team in one of our earlier offices

In the early days, there were three of us: Eric Winquist, Sean Tong and me. We were setting out to do something that we knew was needed in our industry, to build a truly collaborative tool that people would use to build really complex things. We had big ideas and a not so big office. As we moved into our first space, we were faced with a question of distribution: two rooms, three people.

One would have been ok, three would have been ok, but two rooms posed a problem. Making it worse was the fact that the smaller room was also the room with large bright windows looking out to some moderately good office park landscaping. Ultimately it was warm and inviting while the other room felt more like a glorified entryway. So the question loomed before us as we stood there awkwardly, each with a used laptop in hand. Who would get the small room with the windows?

It was too early in the start-up to make a decision based on hierarchy – that didn’t yet exist. We were peers embarking on a grand journey that was built on trust and respect. As the company evolved, that would happen naturally, but we weren’t there yet.

In the end, we did what any sensible start-up would do. We figured out how to cram three desks into the small room. The desks barely fit and getting in and out was awkward but it worked. The close quarters brought us closer together and enabled us to collaborate on the fly. Also, we now had a big empty room to fill with grand ideas – to stand up and talk things through when we hit roadblocks.

Since that first office, Jama has been in 8 different spaces. In each instance the first thing we’ve done is set about making it feel like home. Whiteboards are always a must, couches, computers (chosen by the user), and open spaces to think and explore. We’ve never considered cubed walls and offices only recently have been used (with glass walls).

Instead of two rooms we now have two offices, and a lot more than 3 people. The tone struck in the early days of our inception has remained resonant through our growth. Open and collaborative remain the key tenets fostered in that early decision to focus on being a team before anything else.

Derwyn during a visit to an early Jama customer in Germany