Agile development Archives

Tag Archive for: Agile development

Jama Software’s VP of Product Development, Jeremy Johnson, was recently a guest on The Product Launch podcast, hosted by Sean Boyce. In this episode, Balancing Discipline and Agility in Product Management, Johnson and Boyce discussed the following topics:

The benefits of a non-technical background in being effective in product management
How understanding the functional areas of an organization will help you be a better product manager
How to perform product management effectively in a complex environment with a team
The importance of effective process in ensuring that product management is done well
How sharing responsibility on your product team can affect increase agility and consistency
The Jama Connect value proposition and how their customers benefit from using it
The importance of receiving feedback direct from customers
How to move faster in product development by being more thorough with your product design and testing process

It was a great discussion and we don’t want you to miss the important content that was covered. Below is a recording of the podcast, and an abbreviated transcript.

Balancing Discipline and Agility in Product Management with Jama Software’s Jeremy Johnso‪n‬

Sean Boyce: Hello, and welcome back to the Product Launch Podcast. As always, I’m the host, Sean Boyce, CEO and founder of NxtStep. I would like to welcome my guest to the show today, Jeremy Johnson. Jeremy is the VP of product management at Jama Software. Hello, Jeremy, how are you? And thanks for being on the show.

Jeremy Johnson: Doing well. Thanks, Sean. I appreciate it.

Sean Boyce: Absolutely. We’re excited to talk more about your expertise and product management and an expert level is such that you’re effectively managing currently at Jama. But before we get there, if you could fill in some of the background for our listeners to take us to how you became the VP of product management at Jama.

Jeremy Johnson: Sure, absolutely. So I think really as many, if not most people in product management, I really got into product management by accident. Came here more from a sales and marketing background, had interests since I was very, very young in technology, but didn’t take the typical path through engineering background which tends to be dominant. But got into product management, spent most of my career in product management and in particular product management in general and product management leadership that is. And came to Jama just about one year ago after spending about 12 years in enterprise environmental health and safety software. Really drawn to Jama for a few things. It was a good transition for me, really very interesting product, really very strong market position. And the interesting nuance with Jama is that we work with some of the most innovative companies in the world on their product development.

Jeremy Johnson: So we’re working with companies in aerospace, in electric vehicles, and medical devices and those kinds of industries, and we’re integrated within their product development process. So not only is there a very high level of engagement and satisfaction from a personal work standpoint with the work that we do at Jama, but from us, it feels like an extended family with all of these other companies that we have at least some part of their process to get these innovative products to market. So it’s a very, very interesting company and it’s a very interesting space. And so that really drew me to Jama. I have a personal interest in the automotive space and really brought me here just over a year ago. I was just starting to kind of match names with faces and things right when the pandemic hit. And so that added, of course, an interesting twist to this new endeavor. But it’s been an interesting journey and it’s really a fun place and an interesting challenge from a product management standpoint.

RELATED: 3 Ways Products Became More Complex in the Last Five Years

Sean Boyce: Thanks for sharing your background. It’s interesting to hear you talk about it. And we’ve talked about this before, how you got into product management and I agree. I find the story is fascinating for where we all come from to get into product management. I feel like that’s also telling of the role. Really helps to round out the skillset per se. You had mentioned from a sales background as opposed to a more traditional technical or engineering background, if you will. I would be curious to hear your perspective on that a little bit as well too, because other people… This is a common question that I get quite a bit from aspiring product managers and existing product managers in terms of how important is it to have that technical expertise to be effective in the role.

Sean Boyce: Obviously, you’ve done quite well at it and you come from that sales background. It’s always been my perspective that, to me, one of the most important things a product manager can do is really capturing the essence of the challenges and problems of the customer and making sure that those problems get solved in the product. And I can only imagine that having a sales background can really help when it comes to those things because obviously you spend a lot of time interacting with customers. But anyway, I’d love to get your perspective on that topic because I know that one’s talked about a bit.

Jeremy Johnson: Yeah, absolutely. I think from a skillset standpoint, it’s certainly still beneficial to have a strong technical aptitude and still have a strong technical interest. But I definitely think coming from a sales background, if you’re a good, strong salesperson, any strong salesperson has to be able to listen to what the customer’s needs are. Has to be able to empathize with customers. Has to understand the process they go through. How do they make purchases? How do they go about their business? What are the things that keep them up at night? And those are a lot of the same core questions that product management has to understand and has to really ask themselves. Just the tool set that we have to react to those are different, right?

Jeremy Johnson: We have more ability to shape the product, see where the product needs to go. We’re in a sales background, you’re trying to shape whatever I can sell today, principally to the customer to fit that need. But I think the basic questions still stand. And so that’s really one thing that I think is key. And I even take it a step further in a lot of respects where I think the best product managers are ones that can see not only the customer, but can also see challenges through the lens of all of the different components of the company. So you understand, support and what they do. You understand how things go through finance, you understand all of these things that really ultimately impact the overall customer journey.

Jeremy Johnson: And from a sales standpoint, you tend to get that visibility, right? You work through the contracting process, you understand how leads come in through marketing. You understand some of the back office things when you have a challenge to work through with the customer. So having a very holistic view of the company, how you work and how you interact with the customers in more of that broad, again, that broad customer journey, that’s a very, very strong asset for product managers to have.

RELATED: Strategies for Remote Engineering Teams

Sean Boyce: I’m glad you mentioned it in that way. I don’t hear it said as often as it probably should be. You’re absolutely right. I’ve always felt very similarly to, as you described where I think effective product managers need to know enough to be dangerous with all of those various functional areas, because it’s not just about the tech and it’s not just about the customer, right? We’re doing everything as a team. All of those roles are important and they all play a critical role in order to make sure that everything’s kind of going to plan, right? And we’re bringing a great product to market and we have happy customers and the process is working. So it’s important to take a vested interest in all of these things. And the other way I describe it from time to time too, there’s always 50 things to be done at any given point in time, it’s a matter of figuring out, what are those top things and making sure you’re spreading the love around a little bit to make sure that you’re not leaving anyone in your team, even if it’s not your immediate team in the dark.

Jeremy Johnson: Yeah. That’s absolutely right.

Sean Boyce: Awesome. Next thing I was going to ask you about, what you alluded to as part of that response as well too was kind of the product development process at Jama, right? So you have a team of product managers under you. Curious to learn more about from the perspective of ensuring that product management is being conducted effectively as your team grows and becomes more complex and then also as you have a product as complex as yours as well too, which is a lot of moving parts, a lot of intricacies to it, a lot of variables, all these types of things. There’s a lot to have to manage and that’s at an even more significant level than just being a sole product manager within a small software team. So if you could talk to us a little bit about what your product development process is like and how you ensure that, that’s conducted effectively at Jama, that would be awesome.

Jeremy Johnson: Yeah, absolutely. And we definitely do have, I would say, some unique challenges or some unique things that we manage through. And I think some of that is pretty consistent with what a B2B software company looks like. And particularly when you work with large enterprise customers, that adds a layer. What I would say is kind of the third layer for Jama Software is most of our companies are highly regulated, they’re focused on safety, automotive customers that are looking at functional safety of their designs, medical device companies that are looking at the safety and efficacy and FDA compliance and things like that. And so we have to have a very rigorous process in order to best align with those types of companies. And so we still maintain that agility. This is said a lot, but I think it’s important to reinforce that for us, agility is a mindset and a philosophy, it’s not a process.

Jeremy Johnson: And so we have to have a level of structure and rigor in our process to make sure that we go through certain gates in research, calculating return on investment, making sure that we have strong alignment with our customer requirements. Make sure that the way that we’re developing and delivering is not going to be disruptive from a change management standpoint. So we have this uniqueness of customers wanting us to move fast, but not too fast. So the way we really accomplish that or part of the way that we accomplish that is really looking at how we actually physically separate our teams and the way that we work in some cases. We have a portion of our team that’s focused on things that necessitate a quick response. From a true process standpoint, they’re Kanban, and they still have that agility.

RELATED: How to Realign Engineering Teams for Remote Work with Minimal Disruption

Jeremy Johnson: They’re taking feedback in either from a quality standpoint or a small enhancement standpoint. And they’re working very, very quickly to meet customer needs and in a very more typical agile way, I would say. Then we have a portion of our team that is focused on larger roadmap projects. And that’s really where we get into this level of rigor, where we have a fairly strong, structured process from a research standpoint, calculating the return on investment based on customer interest and the cost of that investment. We go through gates with the chief product officer and these get formally approved and put on the roadmap. And there’s various measurements and tracking very closely the progress on those projects. I would say for some people that would come into that environment, probably drive them crazy. And there’s a lot of rigor and a lot of things we watch. But again, because of this type of company, because of these type of customers, excuse me, it’s really necessary.

Jeremy Johnson: They expect that. They frankly have that level of rigor in their business. And we have to align as close as possible with the way they expect things. All the way down to our processes are actually ISO certified to the same standard that, for example, our automotive customers use for functional safety. So we’ve gone and gone through the process that’s audited regularly. We have a compliance department in our product development team that helps us and ensure alignment of our release process. So it’s tremendously rigorous compared to somebody that truly has that agility. Now, the balance though continues and particularly from my team is looking at continuing, how do we innovate? How do we find things that we can deliver to customers quickly? How can we adapt the product in that fairly rigorous environment? And so it does put an additional level of… pressure’s probably not the right word, but responsibility on the product management team.

Jeremy Johnson: And we’re also fortunate enough to have a specific group for user experience and product design. And in my opinion, frankly, even today in 2021, that’s still an underutilized and under-appreciated discipline within the overall product group and in particular, enterprise software. And we ask that team to really do a lot in their research, working with customers, helping simplify things when we introduce them, helping really map out how we can incrementally deliver something that can add tremendous value to the customer when it’s delivered in whole, but do it in such a way that it delivers incremental value and doesn’t have the same level of change management concerns that would really disrupt our customers. Because again, they’re simply highly sensitive to that.

Find out more about balancing agility and discipline in the product development process by listening to the full podcast here.

Download our eBook to learn about encouraging product development success with strategic team collaboration.

DOWNLOAD NOW

One of the biggest challenges for companies at the enterprise level is remaining competitive in a climate full of innovative entrepreneurs and nimble startups. A company that has been around for decades, and has entrenched hierarchies and bureaucracies, risks falling behind up-and-comers who have the flexibility and culture to remain nimble.

But size doesn’t have to be an impediment to implementing Agile teams. Even global behemoths can use Agile principles to remain on a path of growth while still responding to customer needs like a startup.

In an article for Harvard Business Review, authors Darrell K. Rigby, Jeff Sutherland, and Andy Noble look at several different companies that have implemented Agile methods successfully and review what worked, what didn’t, and how companies can launch Agile teams that work — and position themselves for a more competitive market going forward.

Challenges and Benefits

Scaling up Agile offers enticing benefits to leaders who face a constant barrage of challenges from energetic, nimble startups. What leader wouldn’t want a more responsive, adaptive organization?

But turning Agile teams into a reality can be tough for companies with clearly established hierarchies and slow-moving bureaucracies. It’s one thing to know that organizing multidisciplinary Agile teams would be beneficial; it’s another thing entirely to clarify which functions are suited for Agile principles and how many Agile teams to launch.

Not All Functions Have to Be Agile

Leaders looking to scale up Agile need to recognize that not all functions have to be organized into Agile teams. Agile teams are best suited to functions related to innovation — and indeed, the methods first caught on in IT departments. Operations such as purchasing and accounting may not be the best place for Agile teams.

However, the authors of the Harvard Business Review article point out that once Agile teams are launched in some functions, they will, by necessity, interact with other parts of the business. These fledgling Agile teams risk creating friction with departments still operating under traditional top-down hierarchies and existing bureaucracies. In order to keep both parts of the business functioning and positioned for success, leadership itself needs to understand and adopt Agile approaches.

Bosch, the German multinational engineering and technology company and an early adopter of Agile methods, attempted to implement a “dual organization” — that is, the company deployed Agile teams across the newest, “hottest” initiatives while keeping traditional functions operating as usual. But this implementation didn’t have the transformative effect the company hoped for, so it tried again in 2015. This time, members of the management board were divided into Agile teams, and the project evolved from an annual project to a continuous process. Now, Bosch has a mix of Agile teams and traditionally structured units, but nearly all areas have adopted Agile values and are more collaborative and adaptive.

Read this blog to learn more about Agile software development practices for regulated industries

A Blueprint For Implementing Agile Methods

Implementing Agile methods across the organization requires a different perspective and outlook from the traditional top-down, project-focused approach used by leadership in the past. In fact, the very nature of those old systems runs counter to Agile principles.

The authors highlight several keys to successful Agile implementations:

Scaled, gradual launches: With rare exception, the companies that succeed with implementing Agile teams do so by proceeding gradually. They may start with an initial launch of teams best suited to the methods, evaluate the success of those teams, and then role out new teams across functions that make sense.
A taxonomy of teams: “Taxonomy” is just a way of classifying teams and functions. This system follows Agile’s modular approach by classifying different components of the business and then integrating them. For instance, a company could identify three functions — customer experience teams, business process teams, and technology systems teams. It would then create a cross-functional team from these functions — one designed to solve one specific problem.
A transition sequence: Leaders should identify those initiatives that offer the greatest value and the most learning and then position them for launch by making sure the team is ready to begin. The authors offer a checklist of attributes of a team that’s ready to begin, including focus on a high stakes major business opportunity, commitment to Agile values, principles, and practices, and support from senior executives.
Strong buy-in from top leadership: Whether the company completely reorganizes to start over with Agile teams or begins by implementing Agile in a few functions and letting it spread organically, none of the implementations would succeed without full support from top leadership. Leadership should be committed to addressing impediments and driving the adoption of the team’s work.

To learn more about common problems with Agile and how to solve them, check out our webinar, “How to Avoid Common Pitfalls of Agile for Embedded Systems.”

No Limits

In practice, there is no limit to how many Agile teams a company can implement across the organization. Agile teams can even work in “teams of teams,” where each smaller team is responsible for one small initiative that feeds into a larger initiative. And as Agile teams gain traction in the company, more traditional functions can adopt Agile methods and implement teams as well. Agile methods have been implemented in sales, marketing, and even HR functions.

Scaling up Agile is at once intimidating and enticing, but those companies that implement Agile teams successfully see major improvements to their businesses. Not only do they respond and adapt more quickly to market changes and competition, but they often see better financial results, greater customer loyalty, and higher employee engagement. For those enterprise level companies struggling to keep up with a rapidly changing market, scaling up Agile offers a way to stay competitive now — and far into the future.

Download our whitepaper, Agile for the Enterprise, to learn more about successfully implementing Agile in regulated and governed industries.

This is a guest post from Jason Swoboda, general manager of the medical device engineering firm, Velentium. It originally appeared on their blog.

Medical device developers face a common challenge: Harnessing the best ideas from the Agile methodology on projects that, because of their regulatory environment, appear to demand a classic waterfall model.

It’s not that the classic waterfall model is bad. Among other advantages, it’s a very clean way to visualize and map a complicated process. But anyone familiar with the debates surrounding development models is aware that, as with all models, the waterfall model has limitations. One of the first and most frustrating limitations that developers frequently encounter with the classic waterfall model is its demand that requirements be nearly complete before design can start.

“I can’t move forward until you deliver complete requirements,” the developer says to the end user.

“I can’t clarify requirements any further until we see a first-pass iteration of the product,” the end user responds.

“But I can’t develop an early version of the product without knowing what I’m supposed to make!”

At this point we no longer have a waterfall model; we have an eddy. We’re caught in an infinite loop and we haven’t even made it out of phase one.

The waterfall model is laid out the way it is because, when it works, it helps developers minimize waste and forestall misunderstandings. Clean labels and discrete phases should also, in theory, ease workloads for documentation, oversight, compliance transparency, and process improvement reviews. But actual conditions rarely conform to these convenient patterns. When they don’t, we’re confronted with a choice: attempt to force conditions to fit the expected pattern, however frustrating and inefficient that may be… or adapt on the fly as best we can.

Learn how to avoid common pitfalls of the Agile methodology in embedded systems by watching our webinar.

That’s why the Agile methodology is so appealing: it offers options that anticipate and prevent the bottlenecking and potential crisis points to which static development models are normally vulnerable. But which approach is right for medical device development?

Velentium believes that if you become too attached to any one model — even one that has “agile” in its name — you’re no longer “agile” by definition. Rigidly adhering to a single approach for every effort by definition cannot be flexible, speedy, and nimble.

At the same time, Velentium is also a company whose principles dictate their practices. So, here’s their guiding star: take a continuous deployment approach to projects. Focus on delivering value as early as possible, and then adding value iteration by iteration until the project is completed. They shed light on their development practices in the text and models below.

Velentium’s Iterative Development Process

As we develop sequentially around these quadrants, the first question to ask is: What’s the smallest slice of the final product we can build that contains a basic version of the most important functions of the whole? (Randy Armstrong’s “Know Your Why” is really helpful here). The answer will guide us through our first rotation. Then, as we prepare for the next turn around the spiral, we determine which of those functions would be the most valuable to expand first. What’s our next benchmark? Which additions will enable testing we can’t meaningfully conduct yet? What does the end user need to see first? What will help clarify requirements or refine project scope? If the project were unexpectedly cut short immediately after the next iteration, what would be the most valuable functionality we could implement by then? These are the questions that will guide our decision-making for what to do at the outset of each development round or sprint.

This process involves key stakeholders, to whom iterations are shown for feedback at regular intervals. Development proceeds in partnership, with open lines of communication and process transparency.

If you overlay this process atop the classic waterfall model, it looks like this:

It still starts with the requirements. We want them as complete and as clear as possible. But we don’t let compiling them exhaustively impede forward momentum, and we don’t expect them to remain static for the duration of the project. Instead, we anticipate changing needs due to evolving market conditions, new research or regulations, and clarification achieved through the development process itself.

We’ve found it’s important to chart the course as well as you can, start moving, and be ready to incorporate new data and updated information into a dynamic master plan as you go. So, in the midst of lingering unknowns on requirements, we move ahead to early design. We let design (and design feedback) inform and complete our requirements.

Then, when we move from requirements and design to implementation, what we or our clients learn during implementation may cause us to revisit requirements and design, and so forth. As we move through iterative development — always seeking to deliver value early and add value often — we loop through project phases in progressively longer loops, all the way into validation. We never want to get bogged down any individual step. At the same time, we don’t want to miss an opportunity to add value because we’ve arbitrarily “moved on” from a previous phase: we believe those decisions should be governed by project scope and cost/benefit analysis, not workflow theory.

To learn more about implementing the Agile methodology into your process, download our white paper, “Agile for the Enterprise: 5 Steps to Helping Teams Move More Effectively.”

Development teams need the most effective solution to manage product development complexity, but can’t afford to restructure their entire process and workflow.

That’s why integrating leading product development solutions like Jama Connect™ and Jira Software is the best answer. We recently explored some of the benefits of bringing the two solutions together in a recent webinar, “Managing Hardware & Software Product Development Complexity with Jama & Jira,” and wanted to share a few of the advantages with our readers.

The Document Dilemma

In the past, Microsoft Excel or Word may have done a passable job at housing requirements and specifications. However, even those who believe those types of tools were once effective have long since realized that they are no longer practical when it comes to complex product development.

It’s likely you’ve been there — staring at a worksheet with 100+ rows and 10+ columns of data. In an effort to add clarification, you also have a Word doc with a list of specifications. You send the documents via email for your team to read through, and then attempt to comprehend and submit actionable feedback that will impact the outcome of the entire project.

You dread getting the responses back because you know everyone has a different method for submitting feedback and version control will be a nightmare. Even with tools like SharePoint or wikis, collaborating via documents makes it impossible to get timely and actionable feedback from multiple team members in a way that maximizes efficiency.

The Answer: Database Solutions

Database solutions like Jama Connect and Jira Software ease the pain of managing complex product development.

These solutions are purpose-built to help you execute specific pieces of the product development lifecycle, and are known to outperform competitors in those functional areas. Here’s a quick glance at how the two platforms complement each other.

Jama Connect
Answers the questions: What are we going to build? Why are we building it?
Areas of focus: The upstream definition process — making sure you’re doing the right things to successfully build the right product.

Jira Software
Answers the questions: How are we going to build it? When are we going to do it? Who is going to do the work?
Areas of focus: Task tracking and making sure those tasks are being completed.

Integrating Jama and Jira Creates a Juggernaut

Bringing together Jama Connect and Jira Software allows you to work in the solution that best fits your workflow, not the other way around. They are both flexible solutions that adapt to your process — whether that’s Waterfall or Agile or something in between.

They can also be used together in a variety of industries and applications, from semiconductor to medical, from aerospace and defense to automotive, and even IT organizations building strictly software projects.

Jama Connect is used for business objectives and epics (i.e., requirements), as well as status and relationships in the stories phase. It puts all the content in one location so the versioned document dilemma you’ve experienced disappears. Within the system, you can:

Collaborate with ease using communication and review capabilities
Seamlessly capture and manage decision history and version control
Ensure requirements are tied to test cases with coverage analysis upstream and downstream

To complete the loop, Jira Software tracks tasks and progress. It’s the bidirectional synchronization between the two systems that allows you to maintain consistency and alignment throughout the development process.

Defect Management: An Integration Use Case

The integration between Jama Connect and Jira Software is also a powerhouse when it comes to defect management.

In addition to capturing requirements and specifications, Jama Connect also employs test management and houses the tests planned to validate those requirements and specifications.

If tests fail and will create a defect as a result, that information is passed to Jira Software for those defects to managed and fixed.

Furthermore, team members who work in Jama Connect can change the priority of a defect in that system. The information is then available to team members who work in Jira Software. Team members working in Jira Software can continue doing their burn downs and execution, with visibility into where the defect originated and what high-level requirements might be impacted.

By integrating best-in-breed solutions, day-to-day users of each specific software don’t have to bounce back and forth between different tools or change their workflow or process. Yet they can still benefit from sharing the necessary information between both solutions.

A Closer Look

We get many inquiries about Jama’s integrations, and most frequently they involve Jira Software. To hear more about the key benefits of using these two first-class product development solutions, watch our webinar.

The role of a project manager is a tough one. Between balancing schedules, deadlines, compliance and budgets, you’re constantly being forced to shift and adapt to avoid obstacles along the way. But one of the hardest parts of the job is undeniably managing stakeholders and their priorities.

Most of the time, the bigger the project, the more stakeholders involved. This can be a major challenge when each stakeholder has a different agenda and definition of success.

So how do you keep the project moving and keep everyone happy? Well, there is no silver bullet here, unfortunately. But we’ve come up with a set of guidelines that can help you manage stakeholder priorities and mitigate conflict.

Identify Key Stakeholders

This may sound obvious, but a huge source of conflict can arise if all stakeholders aren’t identified and looped in from the very beginning. All the legwork that happens prior to a project will have to be redone if new stakeholders pop up along the way. This can mean pushed deadlines, budget increases and generally unhappy stakeholders. Make sure that you’ve identified, and communicated with, everyone who may have a dog in the fight early in the process.

If there are many stakeholders in a project, it’s often beneficial to identify high-priority and secondary stakeholders. Naturally, those who are high priority will hold more weight and have more pull than secondary stakeholders.

Remember, not all stakeholders will be directly involved in the work. There may be others who are directly impacted by the project and its outcome. And those people need to be involved, too.

Identify Priorities and Potential Conflicts

Having a kick-off meeting is a great way to identify the different interests, priorities and perspectives of each stakeholder.

If all goes well, each stakeholder will have similar goals and priorities and the project can move forward with perfect alignment. The reality is, though, that there will likely be a variety of perspectives and wish lists, and they may be competing.

Should this happen, a good way to start prioritizing interests is by asking each stakeholder, “How does this support our business objective and company goals?” If the answer is that it doesn’t, or that it can’t be clearly tied to a business objective, it falls towards the bottom of the list of priorities.

Having these conversations early in the process helps us avoid future conflict and uncertainty about the project, and gives us a better shot at completing the project successfully and on time.

Mitigate Conflicts as they Arise

Understanding and addressing stakeholders’ needs and concerns early in the process decreases the likelihood of problems arising further down the line.

However, things happen. Priorities shift. Budget gets slashed. What’s the best way to deal with it? This is where your interpersonal skills make their debut for effective conflict resolution.

Many conflicts can be simply handled by clear communication and a review of the goals and priorities set forth in the planning phases of the project. Re-aligning goals and commitments is often enough to mitigate a conflict, especially when they’ve been clearly defined and documented.

As a project manager, you’re often able to block and tackle to prevent conflicts from arising. Managing expectations is a big part of the job, and your communication skills can be the difference between success and failure.

For example, when something related to the project inevitably changes (like budget or resources) or you run into unanticipated problems, be upfront and clear as soon as you know that things have shifted.

It may be tough to deliver news of setbacks to stakeholders, but having these conversations and realigning commitments with everyone involved is the best way to avoid friction and frustrations.

Want to learn more about being a pro at project management? Check out our eBook “Project Management Best Practices” for 21 tips on taking the pain out of project management.

After learning about the Agile Fluency Model at ProductCamp, I began to wonder where Jama Software’s product-development organization fell within the framework. While I could see evidence of our fluency in the first and second levels, I was uncertain about our competency in aspects of the third level.

At Jama Software, Agile Software Development practices have been in place for several years. In the past few, we have made a series of investments in both our engineers and the broader organization.

In particular, we’ve focused on refactoring workshops, continuous integration, test-driven development, pair-programming, collective code ownership, and DevOps culture. We ship software at a cadence that makes sense for the various markets we serve. Some markets have a tolerance for monthly releases, whereas others operate on a biannual schedule in accordance with their regulatory environments or risk tolerances.

Jama Software’s Approach to Agile Software Development

One practice we’ve adopted, which is consistent with a three-star team, is we have a system of self-organization within our engineering group. Engineers are free to move to different projects and focuses as their interests change. At the same time, we provide strong support for gelled-teams, which consist of individuals whom enjoy working with one other and have gained an efficiency in doing so in particular areas of the product.

An important tenet of a three-star team is that business experts have permanent memberships. So each development team on a consumer-facing project works with a product manager to represent customer and business needs, for instance, or a UX designer to ensure a feature meets design quality. However, those individuals aren’t embedded or collocated with the team. Instead, business experts often work with multiple teams at the same time.

Though we don’t fulfill the criteria of having dedicated business experts and designers embedded on our teams, at this juncture in Jama Software’s growth, it’s appropriate we operate this way. While we’re certainly no longer a neophyte startup, we try to stay lean in our operations. This ensures team members at all levels of the process have a better understanding of what we’re building and why. Practices such as including the engineering team early in the user research process, and brokering out what exactly is going to be built, is an important counter-weight to the direct embedding of an individual for a specific project.

Staying flexible with Agile Methodologies

As we continue to progress as an organization, there will be some practices of a three-star organization that we’ll strive to achieve for the benefit of our own agility. As I mentioned above, we release on a monthly cadence to our hosted customers. For our on-premise clients, we follow a six-month schedule. While Jama Software has a release schedule that may appear longer when compared to consumer market applications, “move-fast and break things” isn’t a mindset that would be appreciated by the companies using our product.

Jama Software builds a solution for customers developing complex, mission-critical products, many of which are regulated. Bugs in our product development platform can lead to bugs in their products, which can result in both financial and fatal consequences. Many of the companies with this kind of regulatory overhead engage in mutual validation of our product when new releases are made available, and only bring them into use across their organizations once it has passed internal controls.

To this end, while continuous integration is an important part of our engineering ethos, and we would like to reap all the benefits of continuous delivery, it’s unlikely that we will push updates of our product to customers multiple times per day.

For software companies making use of Agile Methodologies, it would be a disservice to consider their application an all-or-nothing situation. Applying the practices appropriate for your business context is the most pragmatic approach. However, it’s also important to continually challenge traditional methods of project management to gain the benefits provided by Agile.

One suggestion for those who want to up their game in Agile is to choose a practice and focus on integrating it into your process until you achieve mastery in it. Just as with software development, process improvement is a practice best undertaken with incremental and steady approaches.

For more insights into adopting Agile practices across your organization, check out our on-demand webinar, “Agile Product Delivery Connects Your Business with Development Teams End to End.”

It is no secret that Agile methodologies have changed the way software teams organize and have had an even greater impact on the speed and flexibility of the product cycle. In the old days, software was developed in silos between independent teams and put together at the very end. This resulted in clunky, redundant programs that had many errors that had to be reworked. Early versions of Microsoft Windows with tens of millions of lines of extra code is the classic example of a poor development process.

Today, Agile software development has taken over. Agile teams build their products in concert with one another and have visibility into everyone’s progress. Feedback is constant and any problems or duplications are discovered before the product is ready to launch. That allows a much more elegant product to emerge in a much shorter amount of time.

Most people associate the Agile method as a practice followed by software teams. This is changing thanks in large part to the overwhelming market for smart, connected products. Case in point, look at the automotive industry. It’s no secret that it is undergoing a revolution. Between radical technological innovation, new safety standards and shifting consumer attitudes, manufacturers must rethink and adjust their strategy. These changes have made automotive development much more complicated, forcing design teams to understand these complexities and adapt, adhering to new safety regulations such as ISO 26262, and prove compliance. As a result, there is a far greater need to use modern tools and technology to further evolve how they align teams, verify functional safety and ensure they are building the right products.

Applying Agile development to hardware requires a few basic parameters. First, everyone needs to be on the same team to see plans, progress and calculate the physical effects of one part on the rest. The high-costs associated with hardware development means it is especially important to have transparency. Altering a product once the architectural decisions are completed does not mean erasing a few bits of code and rewriting them. Instead, you are in the world of atoms and you may have to order new parts, apply heat to weld or add more microchips. All these add expenses and end up affecting the final price, and impact your bottom line. Applying Agile development processes will inevitably lower the price for hardware devices and result in more profit for the companies or lower prices for end consumers.

Hardware Agile development includes seven steps, as software Agile development does. Yet, the process is slightly different. Hardware Agile development starts with a design interface and moves on to a low functionality emulator. That is followed by a medium and finally high functioning emulator for the team to see. There are two layers of full functionality prototypes and finally a fully integrated testable device. The team shares an open platform to get to the product they are seeking.

The manufacturing process itself has also improved by leaps and bounds in recent years. Ever since Motorola developed its Six Sigma standard, companies have endeavored to upgrade their manufacturing speed, quality and accuracy while reducing price. Agile development is the next stage in this process as all team members can contribute to productivity improvements on the manufacturing line.