Product Management

When you take on the development manager role, it can feel like you're doing a little bit of everything. Your job is no longer to focus purely on code — and you're not leading your average team. In your day-to-day, you're representing, strategizing for, and even developing with your engineering team.

With all the tasks filling your to-do list, it can be easy to forget: Getting quality results depends on the quality of your leadership. Work isn't just about projects — and you're not a project manager. Great development managers are equally as good at working with people, building culture, and supporting their team members as they are at boosting efficiency and working on all things technical.

To get the most out of your team, here are five tips that every development manager needs to know to get the best from their team.

1. Offer guidance, not micromanagement

Have you ever gotten anything done with someone breathing down your neck? It's not comfortable, and it creates a culture of distrust. In an agile environment, this goes against the principle of having a self-organizing team — one in which each team member takes charge of their own responsibilities and timelines.

A great development manager knows that each team member contributes their own unique work experience and knowledge to a team. Your job description isn't to do other people's jobs for them or boss them around. Rather, it's to ensure the engineering team produces quality products in a timely manner.

You'll get more out of your team by inspiring them instead of telling them what to do. Instead of dictating deadlines, guide your team in the right direction by illustrating the importance of your priority projects.

How will each person's contribution impact the broader company? How will finishing one task early unlock new opportunities for the team? Nudge your employees toward better decisions that they make themselves to build a team that's enthusiastic about their work.

2. Plan with the big picture in mind

While members of your product development team may be diving into the details — writing code, checking off smaller tasks — your job as a development manager is to think big. Development managers play a key role in the agile planning process by figuring out which projects their team should prioritize and how to best complete them.

Instead of just thinking solely about what's best for your team, you need to consider which projects and tasks best align with your company's broader business goals. This will help you build a development team that creates stand-out results for the entire company.

At the same time, you should be fully aware of what's possible for your team to take on. Will committing to one new product up one person's workload far more than others? Does your team have the capacity for more work at all? No matter how many years of experience your team has, they — as individuals and as a whole — need room to breathe so they don't burn out.

3. Keep your technical skills up-to-date

"Manager" may be the brag-worthy highlight of your job title, but that doesn't mean you can let your technical skills go. Odds are, coding will still make up a chunk of your day-to-day — or at least your week-to-week. Even when you're not directly assigned to a software development task, you'll still need to guide your team members through their individual tasks.

To give your team the support they need, you need to be able to speak their coding language. This will help you lead code reviews, take part in technical conversations, anticipate (and prevent) roadblocks, and ensure you're implementing the most efficient technologies. Regularly taking courses and joining a coding community are two simple ways to be a problem-solving champion for your engineering team.

Your technical expertise will help your team stick to your product roadmaps and meet key milestones.

4. Bolster your communication skills

When you take on the development manager job, you become a liaison between your engineering team and other parts of your organization. For example, you might communicate the needs of your developers to senior management or pass on requests from sales managers to your team.

People without a technical background might think you're talking about music if you start talking about C#. Engineers without business management experience may roll their eyes if you start talking about five-year plans instead of an upcoming product launch. Even though coworkers share the same company culture, they don't necessarily "get" each other all the time.

Developer managers are translators who represent their team and deliver messages back to them as needed.

Since you're constantly working with people from different backgrounds, you need to strengthen your interpersonal skills. Get to know how you can best communicate with different people. Which teams prefer email over texting? Who's the go-to contact person for each team? Does anyone listen better when they're not hungry? 🙋

The stronger your communication skills are, the more likely your team will get the resources they need, and the better they'll connect their priorities to your company's.

5. Be available to support your team members

Development manager may be a part-time managerial and part-time technical role, but in this position, you need to be a full-time leader for your team. When you want to consistently improve your team's output, you need to put your top-notch leadership skills into practice day in and day out.

As a development manager, you need to act as a coach of sorts for your team members. Schedule out recurring one-on-ones with your team members, during which you can chat about career goals and pain points on top of current projects. When you have a new hire, chat with them about their desired career path during the onboarding stage.

Based on what you learn, you can brainstorm ways to support their professional development. You don't have to pay for their bachelor's degree to help them succeed. Connect them to mentors, send them to conferences, recommend them for speaking opportunities — your options are endless (and simpler than you may think).

Offering support on both current projects and in long-term career goals is your chance to invest in your employees. It'll help them become better workers — and they'll feel valued, too. Did you know nearly half of employees leave their jobs to gain new skills? Keeping your development team at its best in the long run requires you to help each employee grow.

Lead your team as an effective development manager

Leading your development team to success takes an unbeatable blend of people skills, technical skills, and leadership skills. In your multi-faceted role, your ability to communicate and align your team with the rest of your organization is invaluable.

With Easy Agile Roadmaps for Jira, you can make team alignment simpler by dragging and dropping any Jira issue on a visual timeline. Watch our demo today to see how this tool can help your engineering team shine!

If one thing is certain in product development (or in life), it’s that time is always passing, and there are always tasks to be completed. There’s no more straightforward way to calculate both of these critical metrics than a simple burndown chart.

Burndown charts help agile teams visualize time vs. task completion, which means the amount of work left compared to the amount of time planned in the development of a product or a specific sprint.

In this post, we’ll explain what burndown charts are, the benefits of using them, and how they are used by development teams. We’ll also explain the difference between burndown vs. burnup charts, product burndown charts vs. sprint burndown charts, and share helpful tools for integrating critical metrics in Jira. Now let’s slide down that y-axis!

What is a burndown chart?

A burndown chart is a visualization of how much work is left to do and how much time there is to complete it. Visible to everyone, this graphical representation predicts how much work the team plans to complete within the allotted time. Burndown charts are also used to measure how quickly an agile team is moving through and completing customer user stories. They are excellent for keeping the team aware of any scope creep.

Let’s look at what each part of the graph represents. The amount of work remaining is shown on the vertical axis. The time that has passed since starting the project or sprint is displayed on the horizontal axis. So, the x-axis is the timeline of the project or iteration, and the y-axis is the work that needs to be completed.

The total amount of work to be done on the project is at the top of the y-axis on the left, and the endpoint on the far right of the x-axis represents the final day of the project or specific iteration. The start and endpoints are connected by the ideal work line, a straight line that shows what the team hopes to accomplish within a predetermined time frame. Another line, the actual work line, shows the amount of work that remains and how quickly the team is actually performing.

Actual work line vs. ideal work line

A burndown chart shows both the actual work line and the ideal work line. Both lines begin at the start point at the top of the y-axis. As the project or iteration goes on, the actual work line will oscillate around the ideal work line, depending on how the team is progressing.

If the team stays on schedule, the actual work line won’t deviate much from the ideal work line and remain decently straight. If the team hits a lot of time-sucking roadblocks during the project or sprint, the actual work line will be more of a wild squiggle, and it may not reach the x-axis endpoint before time is up.

The benefits of using burndown charts

Burndown charts are helpful in a few key ways. These charts:

• Provide a visual representation of the progression of work completed over time.
• Keep product owners informed of development progress for a product or specific sprint.
• Keep the whole development team on the same page about how far along a product is.
• Are regularly updated as work is completed and as time passes to show product progress in real-time.
• Provide advance notice if a product is not progressing fast enough.
• Capture clear metrics that can be reviewed during retrospectives.

Burndown chart vs. burnup chart

A burndown chart tracks how much work remains by starting at the tip of the y-axis and tracking downward toward where the endpoint meets the x-axis as time goes on and work is completed.

A burnup chart does the opposite. The start point is at the bottom corner of the graph to the left most of the x-axis. A burnup chart’s ideal work line and actual work line track upward as work is completed and time passes. Toward the top of the y-axis is another horizontal line representing the scope of the project, such as the number of story points needed to complete. If the scope becomes larger, say if story points or sprint backlog items are added, the scope line rises to account for the elevated goal.

If the scope of a sprint or project changes due to unexpected developments or stakeholder insight, which is bound to happen over the course of development, these changes are represented by the scope line. This can make burnup charts a slightly more adaptable tool.

Both burndown and burnup charts track a team’s velocity, workflow, and progress. A burnup chart’s scope line takes into account the evolving nature of software development and how the goalposts can move over the course of a project, which makes them ideal for tracking a project as a whole. While they are both effective tools, a burndown chart could be better utilized during a sprint because the number of tasks in a sprint is less likely to change.

Product burndown vs. sprint burndown chart

There are two different kinds of burndown charts. A product burndown chart shows how much work remains for the entire project, whereas a sprint burndown chart shows how much work remains in a specific iteration.

A product burndown chart collects a larger amount of data. It represents everything that needs to be completed on a product during the specific time requirement agreed upon at the beginning of the project.

A sprint burndown chart helps Scrum masters visualize how fast the agile team gets the work done and how much work is left to do during a sprint. It shows the Scrum team’s progress by displaying how much work actually remains instead of time spent. Over the course of a sprint, the chart will slope downward across the completed story points.

If the burndown line on a sprint burndown chart is not tracking downwards by the time you reach the middle of the sprint, it’s a sign that the sprint is not going well, and it’s up to the Scrum master to get the team back on track.

Working on your next product plan? Learn about common agile planning mistakes and how your team can avoid these common pitfalls.

Burndown charts in Jira

Broken Build’s Agile Reports and Gadgets include burndown and burnup charts for both Scrum and Kanban.

The application is designed for Jira, so you can integrate reporting in real-time. Having access to immediate metrics helps teams spot bottlenecks and dependencies, so they can be addressed sooner rather than later. The application lets you export charts and customizable reports to share with team members and stakeholders or to review during retrospectives.

How Easy Agile can help your team

We’re passionate about helping agile teams work more efficiently and effectively while always putting the needs of the customer first. We create products specifically designed for Jira users, including Easy Agile TeamRhythm, Programs, Personas, and Roadmaps.

Try Easy Agile TeamRhythm to build simple and collaborative story maps in Jira. Our tool will help you transform your product backlogs into an impactful visual representation of the customer journey. It’s the highest-rated story mapping app for Jira, trusted by over 120,000 users at companies like Amazon, Twitter, Starbucks, Rolex, and Adobe.

Do you know the difference between agile vs. waterfall, and have you considered which is best for your business?

Don’t go chasing waterfalls — unless you’re seeking a project management methodology. 😁 The waterfall method is a common framework teams have utilized for years. But it isn’t the only way of doing things, and it may not be the best way, depending on the needs of your team.

In this post, we’ll cover the differences between agile and waterfall methodologies, including the pros and cons of each. We’ll also share a potential alternative called the hybrid method, which can provide the best of both worlds for certain teams.

Build a visual roadmap timeline of your Jira issues

Easy Agile Roadmaps

Try Now

Agile vs. waterfall

When it comes to agile vs. waterfall, these methodologies don’t share a lot in common. In many ways, agile is the answer to the limitations of the commonly used waterfall method. However, there are definitely still pros and cons to each framework.

Let’s dig into both of these methodologies in more detail.

The waterfall methodology

We’ll start off with the waterfall approach since it’s a little easier to explain. While the idea of a waterfall may sound majestic and bold, the waterfall method is fairly traditional and straightforward.

The waterfall model is used to describe traditional project management, where a project plan is laid out by a project manager before work begins. Project requirements and tasks are planned in advance and given to the team, who then work on one task and then the next until project delivery.

Tasks are completed in the order they were laid out in the original plan. The sequential order of tasks cascading from one to the next is what gives waterfall project management its name.

Waterfall is a widely used project management methodology, but it does have its limitations. The strict approach helps teams know what to expect through every step of a project, but it isn’t very adaptable, and it can lack input from the team as a whole.

This lack of flexibility has hindered modern teams. It makes it more difficult to switch gears if and when you need to. A predetermined plan doesn't leave much room for change, and it misses out on adapting to invaluable feedback from both stakeholders and customers.

Waterfall Pros

• Clear goals and objectives are provided at the outset.
• There’s a straightforward structure that’s repeated project after project.
• It’s easy for team members to understand what’s expected of them.
• There’s less general pressure on employees.
• It’s easier to learn the ropes, especially for new employees.
• Information is easily passed on to all team members.
• Success is measured by the completion of tasks, which provides faster gratification.
• Budgets can be more accurately predicted.
• The end result of a project is decided from the beginning, so the journey is clear for everyone involved.
• Most planning is led by one person.

Waterfall Cons

• The process is not as flexible as agile approaches.
• It’s difficult to foresee roadblocks and dependencies that could delay work.
• Work is not always evenly spread out across the team.
• Project overload is possible.
• Short-lived teams may ignore conflict for the sake of getting to the end of the project.
• It’s difficult to change directions or the scope of deliverables once a project begins.
• There’s less customer involvement throughout project or product development.
• Stakeholders may not see progress until the end of a project or until a final product is complete.
• There isn't an early testing phase to ensure a project or product is on the right track.

The agile methodology

Agile is an iterative approach that puts emphasis on testing and adapting. It uses early feedback and stakeholder involvement to determine the best possible path forward. There’s still a plan with agile, but it isn't rigid or strict, and it leaves plenty of room to adapt and grow along the way.

Easy Agile Roadmaps: The simplest and most flexible roadmapping tool for Jira

Try Now

The plan evolves as new information is acquired to ensure the end result meets customer and stakeholder needs. Adaptability plays a big role in agile practices, and that’s what has drawn so many teams to the methodology. The ability to adapt in the face of change is a sought-after strength today, given the pace at which change is occurring across technology, the economy, global markets, and more.

Agile Pros

• The entire team is involved in the planning.
• Feedback is central to the process.
• Customers and stakeholders are involved.
• The customer journey is top of mind when a decision is made.
• The team can adapt as new information is acquired.
• Changes can be made along the way to avoid roadblocks or stalled work.
• Each team member's capacity (workload) is continually assessed to prevent burnout.
• Long-standing teams continue to learn how to work together.
• Processes are continually improved upon throughout every phase of the project/product.
• All voices on a team, no matter the role, are heard when it comes time to gather retrospective feedback.

Agile Cons

• Agile techniques and terminology can be tough to grasp.
• It can take teams a while to learn proper agile methods.
• Agile teams may not get the support they require from management and business owners.
• Not all team members may buy into the agile framework, presenting a disconnect across the team.
• A lack of documentation can make the details unclear.
• Budgets can become unpredictable if it turns out the project/product needs to go in another direction.
• The scope of a project/product can continue to grow (scope creep).
• The many agile meetings take up a lot of time.
• It’s harder to find new employees who are experienced with agile methods.

Agile is a broad term that covers a number of different frameworks that utilize agile practices. Lean, DevOps, Kanban, and Scrum are all various forms of agile that fulfill different needs.

For example, the Scrum framework involves repeating sprints that are commonly used by agile software development teams. If you haven’t heard of Scrum before, this might be a lot to take in. 🤯

A Scrum takes two weeks, beginning with sprint planning, when the product owner makes prioritization decisions about which backlog items (tasks) should be accomplished in the upcoming sprint. From there, the team works on the specified tasks, guided by a Scrum Master who leads daily standup meetings to keep everyone informed of project/product progress. Lastly, a sprint review and sprint retrospective occur at the end of the sprint to ensure the team continually evolves and improves.

Easy Agile User Story Maps: Achieve smoother sprint planning & easier backlog refinement.

Try Now

Interested in learning about other popular agile methodologies? There are so many to choose from! We covered 8 popular development methodologies in a previous post.

The hybrid methodology

Does the choice need to be agile vs. waterfall? You might be thinking, can’t we put all of these benefits together? The hybrid agile approach can offer the best of both words for some teams.

A hybrid model blends the valuable techniques provided by both waterfall and agile frameworks. For example, you might begin with a set of agile sprints for prototyping and gathering feedback, followed by a single plan of action associated with non-agile techniques. It can be the best of both worlds, and it can serve as a stepping stone while a team attempts to make a complete agile transformation.

A hybrid approach often comes into play with agile project management and other non-traditional agile uses. Agile was originally designed for software development, but teams in all sorts of industries continually adopt aspects of agile. The agile methods observed by software developers don’t always work for other types of teams. Agile can be a difficult transition to make, especially when teams are used to things being done another way.

An approach that meets your needs

When choosing which approach is best for your team, business, or enterprise, take time to consider the needs of the team as well as your customers and stakeholders. Agile may be a tough transition to make, but if you believe the benefits will enhance your processes and help your business long-term, it might be time to make the switch. A hybrid approach can help you get there gradually without as many disruptions to your current processes.

Easy Agile is passionate about helping teams work better using  agile tools designed for Jira. If you want to learn more about agile and other methodologies, follow the Easy Agile blog. It’s filled with how-to guides, tips, and strategies — and if reading content isn’t for you, we have a podcast too! 📢

“Agile” is a simple word that means quite a lot today. What was once resigned to software developers and product development is now commonplace in many businesses, and agile implementation is showing no sign of slowing down.

It all boils down to this: Businesses today must be able to adapt fast.

The rigid approaches that worked for years don’t fit our rapidly changing business landscapes. Businesses of all shapes and sizes need to continually adapt to changing requirements, the changing needs of a global economy, cultural shifts, and evolving technological advancements.

It’s clear that agile is the way of the future, but how do you implement such a massive change across an organization, especially enterprises? Do you need a top-down approach, a bottom-up approach, or something in between? Let’s take a closer look at the benefits of agile and how to choose the best agile implementation approach.

Are you practicing SAFe®?

Bring the SAFe® Program Board into Jira

Try Easy Agile Programs

Why switch to an agile approach?

We’ve covered the benefits of agile in detail in our Beginner's Guide to Agile Methodology, but let’s recap some of the key points and why so many businesses are choosing to make the switch.

Agile practices focus on an iterative approach that continually adapts to new information and circumstances. By contrast, traditional project management generally adopts a waterfall approach — the project manager lays out a plan at the beginning of a project that the project team is expected to follow to the letter.

The problem with the traditional project management process is that it leaves little room to quickly grow and evolve. Agile project management and agile software development, on the other hand, need feedback and iterations at every turn. Agile teams test early and often to ensure they are on the right path, and they make adjustments in real-time.

The benefits of agile methods are far-reaching — that’s why we love it! Though it may take time to implement, agile is a worthy investment for any future-focused organization.

Additional benefits of agile:

• Managers can more easily account for the capacity of individuals and entire teams.
• The team can better manage work in progress (WIP).
• Everyone can clearly visualize the prioritization of tasks.
• Bottlenecks or roadblocks are addressed before they halt progress.
• Wasteful processes are eliminated or changed to improve efficiency.
• Multiple voices are included in the decision-making process.
• Teams can make iterations on products or projects in real-time.
• Stakeholders, customers, and end users are involved in your processes.
• Teams can provide continuous delivery to customers and stakeholders.
• Collaboration and teamwork improve.

With Easy Agile Programs you can equip your distributed or co-located teams to implement the Scaled Agile Framework® (SAFe®) without leaving Jira.

Join a demo

Agile implementation: Top-down or bottom-up?

So, you believe in agile and you’re ready to make it happen, but what’s the best approach? Do you implement it from the top-down or bottom-up? Let’s find out!

A top-down approach to agile implementation starts with those in charge. It often begins with management or business owners who hear about the benefits of agile and want their business to adopt agile practices. The problem is, when an idea only comes from the top, it can catch the rest of the organization off guard. If those in charge don’t give enough notice or provide all of the necessary resources and time to implement new ways of working, employees can become resentful and push back against the change.

On the other hand, when agile implementation comes from the bottom-up, leadership can push back. Teams and team leaders may want to improve their processes and adopt new ways of working, but they may not get adequate support or resources when they need them. It can take time to convince those in charge of the benefits of agile, which can take away from the time needed to actually learn and implement agile practices.

A hybrid approach

The good news is you don’t need to pick just one. The best approach for your business may turn out to be a hybrid approach. The more people you have on board, the better.

Agile implementation is easiest and most effective when as many people as possible buy into the process. It’s best if you have buy-in throughout multiple levels of your organization, from employees to managers to owners to CEOs.

Push-back on change is quite common in organizations, no matter the industry. It’s important to have people throughout the company who believe in the value of agile, are passionate about agile processes, and are excited about the possibilities agile presents.

Choosing an agile framework

As you implement agile principles, you’ll need to choose the framework that works best for your team. Depending on the needs of your team and organization, you may choose to adopt one framework or establish a mixture of frameworks.

Below, we’ll outline a few popular agile methodologies.

Scrum

Scrum is a strange word that’s very popular as a software development process. It’s a series of events that revolve around repeating sprints. One sprint (or Scrum) begins with sprint planning. The product owner reviews the product backlog, which represents all of the work that needs to be completed. They choose which items/tasks are the most important for the upcoming sprint and move those tasks into the sprint backlog.

Next, the development team, guided by the Scrum Master, works over a two-week span to complete the sprint backlog. Each day, the team meets for daily standups, which allow the team to go over what was accomplished over the previous 24 hours and discuss any possible roadblocks that stand in the way of the team completing work.

Lastly, the team completes a sprint review to gather feedback from stakeholders. They also conduct a sprint retrospective to discuss what went well and what didn’t over the course of the sprint. The insights are carried over into the next sprint to help all team members keep improving.

Wow! 🤯 That was a whirlwind explanation of Scrum. If you want to understand the process in more detail, we cover Scrum in a number of other guides, including the difference between Kanban and Scrum and guides to Scrum sprint planning and Scrum retrospectives.

Kanban

The Kanban framework is a visual process that helps teams manage the amount of work in progress. It allows teams and team leaders to see an at-a-glance view of what’s currently in progress and what’s on the horizon.

A Kanban board has three sections: to-do, doing, and done. Tasks flow throughout these sections one at a time to ensure no one is taking on more than one task at once. This ensures focus is always put on work in progress, no one gets bogged down with too many tasks, and potential bottlenecks are discovered before they impede productivity.

Chances are you’ve seen a Kanban board in action in some form or another. Trello is an example of an interactive Kanban board. The Kanban framework can be used on its own or paired with other frameworks, such as Scrum.

Lean

The lean methodology focuses on eliminating waste to improve efficiency. Lean follows five main principles: identify value, map the value stream, create flow, establish a pull system, and seek perfection.

Lean aims to waste less time by ensuring processes, communication, and the transfer of products or services run smoothly. When waste is eliminated and time is optimized, businesses can reduce costs. Efficiency is paired with a continuous improvement mindset, which helps teams work better together and deliver ever-improving products and services.

➡️ Learn more: Understanding Lean Agile and the 5 Lean Principles.

These are only a few popular agile methodologies. To learn more, read our article on 8 Software Development Methodologies Explained.

Seamless agile implementation

Agile implementation works best when people at all levels of the organization buy into the agile transformation. A top-down approach means the leadership is on board, but it forces employees to adopt a new way of working, and they may not be comfortable with the change. When it’s the other way around, employees, team members, and team leaders will struggle to implement agile without the support from those in charge and the people who allocate resources. A hybrid approach is often ideal, where as many people as possible are excited about and invested in the transition.

With the right tools, agile implementation becomes even easier. Easy Agile is dedicated to helping teams work better with agile. We design products that highlight the customer journey and allow teams to collaborate with each other seamlessly.

Easy Agile Programs is simple to use, collaborative, flexible, and it integrates directly with Jira. You can contact our team at any time to learn more about our suite of Jira products!

Join a demo

Try Free for 30 days