4 min read

Waterfall vs. Agile: Choosing the Right Methodology

By Bryce Lord on Aug 26, 2021 2:52:58 PM

2021-q4-blogpost-Waterfall vs. Agile- Choosing the Right Methodology copy

Waterfall and Agile are both process methodologies with very different approaches to achieving the same goal: developing high-quality products. Where Waterfall focuses on strict requirements and planning, Agile provides a more adaptable approach where it's much easier to adjust requirements and timelines as the product develops. Both methods have their pros and cons, hopefully this article will help clear up which one is right for your project!

What is Waterfall?

Waterfall is a linear and sequential process methodology. It breaks up projects into several distinct phases, with a complete product being delivered only after the final phase is successfully finished. An example of these phases may be something like: 

Requirements > Design > Development > Testing > Implementation

These phases are completed in order, where all tasks associated with that respective phase are complete before the next phase can begin. The teams required in each phase can be distinct, and may require only slight overlap between phases. Both the customer requirements and timeline are established early on within the product development life-cycle. The Waterfall methodology really excels when product requirements are strict, and the goal is to provide complete product within a specified timeframe and budget.

Diagram-phases-01

As someone that comes from a background developing manufacturing processes, the waterfall methodology was basically a way of life. Every new product life cycle began with Advanced Product Quality Planning (APQP) and its phases:

Planning > Product Design & Development > Process Design & Development > Product & Process Validation > Production

These processes are followed in order, with a review at the end of each phase by their respective team. In most cases, shortly after beginning production for one project, the planning phase for the next project would already have started, and so on. The strict product requirements, tight deadlines and long lead times to design and build manufacturing equipment lends itself well to waterfall. Lead times for manufacturing equipment can range anywhere from 3 months to over a year depending on complexity, so establishing clear product requirements early is imperative. Any change to the product or process requirements could result in extreme delays to the project.

Pros

  • Project timelines, budget and progress are easier to manage and measure throughout distinct phases.
  • More hands-off for customers after initial requirements and timelines are established.
  • Detailed documentation is more readily available.

Cons

  • Need strict requirements very early on, changes to these requirements can be costly.
  • Less overlap and communication between teams makes collaboration more difficult.
  • The testing phase occurs much later in the project, so any issues found can be expensive and delay projects drastically.
  • Distinct teams, rigid timelines and budget constraints make it difficult to move back to a previous phase if issues arise.

What is Agile?

Agile is an iterative and highly adaptable process methodology. Agile focuses on breaking down projects into small product releases that can then be iterated on to make improvements. These iterations go through all phases of a project simultaneously. This allows a team member to be testing out one feature, while another is designing a different feature. With all of the phases of a project moving simultaneous, having a fully cross-functional team engaged throughout each iteration is imperative. After each iteration is complete, clients can review the most recent release and set priorities and goals for the team in the following iterations. The Agile methodology excels when requirements may need to adapt as the customer's needs develop, and there aren't strict requirements for timeframe and budget.

Diagram-01

Software development is one of the key uses for the Agile methodology. With new product requirements frequently coming up and an on-going timeline for completion, breaking the project down into continually improving iterations is a much better way to control changes. With each new iteration, clients will find new beneficial features they'd like implemented, and these feature requests will be turned into tasks to be planned for future iterations. The average time for an iteration is usually between 1 and 4 weeks, so clients frequently get a look at the current state of the product and are able to evaluate priorities for future iterations accordingly. Agile works incredibly well when requirements are not fully established up front, which is usually the case with software development projects.

Pros

  • Highly adaptable and works well when customer requirements are not completely established up front.
  • Fully cross-functional teams promote higher collaboration than distinct teams.
  • Frequent customer communication helps ensure requirements are being met and customer satisfaction is high.
  • Testing is performed concurrently with development during each iteration, leading to faster identification and correction of issues.

Cons

  • Tracking timelines, budget and project progress is more difficult across multiple iterations.
  • Additional iterations can lead to lengthened timelines and increased budget.
  • Documentation is usually lacking between iterations.

At Praecipio Consulting, we have more than 15 years of experience helping clients big and small become the best version of themselves; if you have questions on Waterfall, Agile, or any other process methodology, reach out and let us know, we'd love to help!

Topics: devops methodology project-management agile frameworks waterfall
3 min read

Agile vs. Scrum - What's the Difference?

By Rebecca Schwartz on Aug 19, 2021 10:03:00 AM

2021-q4-blogpost-Agile vs. Scrum Methology- Whats the Difference?

Organizations are rapidly moving toward new work management styles, especially in the age of digital transformation. If you work in project management, you've probably heard the term "Agile" at some point in your career. Maybe you've considered taking this approach with your teams, and have already done some research. "Scrum" is another term you've most likely heard during your research. Although this is a term used in rugby, it is also a specific methodology teams use to work in an Agile manner. At Praecipio Consulting, we've assisted many teams 

with their move to Agile, using the Atlassian toolset to support and ease their journey. We've also worked with many teams who use Scrum specifically, but many use different frameworks - using Scrum is not a requirement to be Agile. Let's take a moment to understand the difference between Scrum and Agile.

What is Agile?

Agile is a project management style in which organizations use an iterative process to continuously deliver work while consistently receiving and incorporating feedback throughout the process. Flexibility is key, so teams can quickly adapt to market changes and customer needs. Agile has a set of principles and values organizations are expected to follow, laid out in the Agile Manifesto. The Agile Manifesto does not delve into specific practices and activities teams should follow in order to work in an Agile way: it serves as a north star for organizations to align to in their Agile journey. There are a few Agile frameworks teams can use to work in an iterative manner, such as Scrum and Kanban. Agile puts an emphasis on people over processes and tools, and gives autonomy to the people on those teams. With that being said, it is up to the teams to decide which framework works best for the way they work and the work they're delivering. 

What is Scrum?

Scrum is one of the many frameworks teams can use to work in an Agile manner. It is mainly used by software development teams, and relies on time-boxed iterations called Sprints. Sprints are made up of the work developers commit to completing within that iteration, typically 2 weeks. The work scheduled in each sprint is based on priority and team capacity, and is carefully estimated to ensure teams can commit the work they've delegated to the sprint. This framework is very detailed, and prescribes a set of specific roles and events, including:

  • A Scrum Master, who protects the teams and ensures they are able to do their work without impediments.
  • A Product Owner, who manages and grooms the product backlog ensuring the anticipated work aligns with the needs of the customer and business.
  • The development team who actually complete the work in the sprint.

As I mentioned above, Scrum is a way teams can work if they're on their Agile journey, but it is not the only option. There are other Agile frameworks that may work better for teams.

How Do Agile and Scrum Differ?

Now that we know a bit more about Agile and Scrum separately, it's easier to lay out the differences between the two. Agile is more of a general philosophy that paints a broader picture around working in an iterative, flexible manner. Scrum is a specific Agile framework and is more granular than Agile. Although both rely on iterations: in Scrum they're specifically time boxed and called Sprints. Scrum also prescribes specific roles and ceremonies, while Agile focuses on the overall principles in the Agile Manifesto. Scrum is also more focused on the team level and the delivery of work. Agile can be scaled across an organization using other work frameworks such as the the Scaled Agile framework, or SAFe, as well as Large-Scale Scrum, styled as LeSS. 

With that understanding in mind, maybe you're ready to start your Agile journey! The Atlassian tools, such as Jira and Confluence, are built to support Agile and the specific frameworks. Jira Software makes it easy to get started with Scrum by providing an out-of-the-box Project template. At Praecipio Consulting, we focus on ensuring the Atlassian tools facilitate your Agile journey by implementing best practices and incorporating our extensive experience working with Agile teams. Reach out if you have any questions around Atlassian and Agile - we're here to help.

Topics: blog kanban scrum project-management safe agile frameworks less
2 min read

Can Scrum Masters have multiple roles on a team?

By Lauren Schroeder on Jul 2, 2021 9:15:00 AM

2021-q4-blogpost-Can my Scrum Master have multiple roles on a team?_1

A question that I'm often asked is: Why have so many different roles on a scrum team? If a developer on a scrum team has the experience to act as the Scrum Master as well, is there any harm in consolidating? Short answer: Yes!

Although having one team member covering multiple roles seems more efficient, it can cause more problems than its worth. Before putting a team member in multiple roles, it's important to consider the following challenges.

Context Switching

Statistics show that it takes an average of 25 minutes to resume a task after being interrupted. Jumping between tasks that require completely different mindsets and skills require a huge context shift. Having a developer who is switching between working on code and managing blockers for the team can actually reduce efficiency. It may be more effective to have a Scrum Master working as a Scrum Master for multiple teams. 

Skills & Training

The skills needed to be a successful Product Owner (PO) are different than those needed to be a Scrum Master, which are different than those that make a good developer! The Scrum Master should have a high level of emotional intelligence and act as a leader for the developers. Developers should be subject matter experts, familiar with the best practices and best ways to implement the PO's requirements.

Conflicts of Interest

The Scrum Team is designed to have certain checks and balances – each role is well defined so that they can focus on the subject matter they are there for. When you start consolidating roles, there's a high risk of conflicts of interests. This is very clear when organizations try to combine PO and Scrum Masters – after all, one of the major jobs of the Scrum Master is to protect the team from scope creep, represented by the PO. Additionally, the Scrum Master unblocks the development team if needed, and helps facilitate the scrum ceremonies – an important part of that requires allowing the team to work through issues before utilizing your authority to pull in outside stakeholders. 

It can be tempting to try and combine your Scrum roles, but we strongly recommend respecting the division of responsibility that has been established. 

If your teams are having trouble with their scrum roles, have any question or just want to chat, contact us, we'd love to help!

Topics: best-practices management scrum tips project-management
3 min read

Scrum Master Basics – Part 2 of 3: The Definition of “Done”

By David Stannard on Jun 11, 2021 9:45:00 AM

2021-q4-blogpost-Confluence Atlassian- Understanding the Software-1

This is Part 2 of a series of 3 posts on Scrum Master Basics.  Here is Part 1

I have to admit, I’m biased. As a manager and a business person, I have a vested interest in my teams success. That success is built upon them achieving a sustainable pace of delivering value to paying clients while supporting their personal growth. 

The definition of “done” is a powerful tool. In my journey as an Agile Coach and Scrum Master, I have found that focusing on the team’s definition of ‘Done’ provides tremendous return on effort. If your team jokes about ‘Done’, ‘Done done’, and ‘Done, done, done’ - there is usually a gold mine of opportunity for continuous improvement.

I believe in the strong relationship between defining done and improving a team’s overall well being – I've seen it first hand. Conversely, I see high dissatisfaction within the team, from the Product Owner and people outside the team when there isn’t a clear definition. In the knowledge business, people like to create and provide things that others use; they generally hate building the wrong thing or things that aren’t wanted or used.

Here are a couple of real world examples from teams I've worked with:

1st example from a real demoralized team:

Scrum Team: “We define ‘done’ as the feature being ready for QA to test.”

Scrum Master: This is clearly an anti-pattern to delivering a potentially releasable unit of value. We’re doing Wagile, not Scrum!

Expunge that way of thinking permanently and never say it – ever!  Seek first to understand…

A Scrum Master should always assume that people are rational and therefore behave rationally. Dig into the reason for the definition. Perhaps this was the team establishing a working agreement based upon having a lone QA person and this was seen as a solution not a problem. I bet that they’d love some help that can result from simply asking “what can we do as a team to help you with your workload?See the world from their perspective. They may be transitioning from classical waterfall workflows and the team hasn’t adjusted to the concept of a cross-functional team.

Use the principle of “take it to the team”.

How can we (the Scrum team) help you? Help ourselves?

Scrum Masters also use individual 1-on-1 coaching – How can the team and/or I help you?

2nd example from a real team:

Scrum Team: “We define ‘done’ as the feature being implemented, passing tests, and meeting the acceptance criteria – but we never release anything.”

Finding possible root causes is again key. Problem solving requires an agreed upon statement of the problem and the desired outcome from a change. In this case – it appears that it is potentially releasable, so the team may have a variety of options such as exploring:

  • What is (are) the root cause(s)? Where does the team have the capability?
  • Discussing with the Product Owner as to why value isn’t being released?
  • What if we did a dark release so that we can keep our release ‘muscles’ toned?

Please note that the 3rd bulleted item shifted to exploring possible solutions. 

Two parting questions:

  • When should these discussions occur?
  • Who should be involved?

If you're wondering if Agile is a good fit for your organization, or have any questions on Scrum methods, contact us, we would be delighted to help.

Topics: blog scrum tips project-management agile
2 min read

Scrum Master Basics – Part 1 of 3

By David Stannard on Jun 3, 2021 10:13:00 AM

2021-q4-blogpost-New to Scrum Master Role Guide – Part

Congratulations on becoming a Scrum Master (SM)!

Scrum is a tool that builds teams. It exposes the issues but not the causes and solutions. A Scrum Master helps their team grow through continuous improvement & collaboration. 

As a builder of teams, I’ve often seen smart employees and colleagues return from training and struggle with how to apply their new knowledge. Most often, failure occurs when the returning person takes an approach of telling people what to do and why the current approach is wrong.


Hence this 3 part blog series.

Some of the chief motivations for choosing Scrum are:

  • Delivering potentially releasable value at a regular cadence

  • Being responsive to change instead of steadfastly sticking to a plan

  • Eliminating waste / becoming leaner

  • Collaboration with clients instead of dry, incomplete, ambiguous contracts

In existing organizations, I’ve seen more successful outcomes and happiness when taking the “Start Small” approach. Mike Cohn in his book “Succeeding with Agile” observes “...there can be no end state in a process that calls for continuous improvement...”. 

Therefore, take incremental steps with your team – leave grandiose visions to the C-level. This increases the probability of success, which breeds confidence and momentum while reducing risk and investment. Similar to software development, your emotional stake in an incremental effort is much lower than multiple weeks of time investment; you’ll more easily throw away an approach that isn’t working. Your team learns experientially which requires trying, learning, adjusting, and growing together. Your team is a living system – so probe, observe, and adjust.

The noun “teams” is key. A Scrum Master’s success ultimately depends upon their ability to help them. You will require patience, the desire to learn about how to build teams, and a firm commitment to the values and principles of Agile. 

Assuming that you’re joining an existing team, here are a few concrete actions:

  • You’re about to change the dynamics of an existing team. So Meet the current SM and discuss the transition prior to showing up to the team’s ceremonies

  • Ideally, be invited to the ceremonies: attend – observe and assure the team that you aren’t planning any unilateral changes

  • Gain access to and review your team’s working agreement. Specifically – the definition of ‘Done’ - more in Part 2

  • Study their sprint board – more in Part 3

And remember – as Stephen Covey writes in The 7 Habits of Highly Effective People – "Seek first to understand not to be understood"

If you're wondering if Agile is a good fit for your organization, or have any questions on Scrum methods, contact us, we would be delighted to help.

Topics: blog scrum tips project-management agile
6 min read

All in Good Time with Atlassian’s Team Calendars for Confluence

By Kye Hittle on May 17, 2021 11:23:52 AM

Blogpost-display-image_Team CalendarsAh, a fresh, new month. For so long there was always at least one day where my email inbox was flooded with many, many calendar invites for recurring company-wide meetings, holidays, and deadlines. After carefully clicking “Accept” on each invite, I’d think, “there’s got to be a better way.”

Atlassian’s Team Calendars for Confluence offers a great solution, and it's included with Cloud Premium subscriptions! Let’s take a look.

TEAM CALENDARS FOR CONFLUENCE

 

Image source: Atlassian

What is Team Calendars for Confluence?

The plugin adds a Calendars tab to each space and you can create multiple calendars using built-in or custom event types. Each user also gains a “My Calendars” page which rolls up all Team Calendars they’ve watched. This is centralized, always up-to-date, and customizable calendar management.

Why use Team Calendars?

Clear the clutter. While Team Calendars helps avoid periodically flooding everyone’s inboxes with invites, it also prevents tasking someone to reissue invites to new team members who onboard mid-year. Even those of us who aren’t new can avoid getting peppered with calendar updates when inevitable changes occur.

Visualize. Team Calendars display events as a live calendar, which is a visual metaphor instantly grokked by most everyone. Select between week, month, list, or Gantt-like timeline views. Assign different colors and icons to event types to further visually distinguish your layout. We often see clients using Confluence tables to list out dates. Tables capture the event data but require unnecessary mental overhead to comprehend and can’t be combined with other calendars to spot opportunities and conflicts.

Crowd-source your calendars. Team Calendars allow any user to add and edit events, keeping calendars comprehensive and accurate. Most calendar systems don’t allow this or it’s too cumbersome. In Confluence, it can also be restricted when needed.

Let’s TAke Control of Calendars

At Praecipio Consulting, we’ve helped organizations use Team Calendars for an incredibly diverse set of use cases. Here’s how we suggest you get started. 

Corporate holidays and time off (vacation, medical leave, volunteer time off, etc.) are often some of the first calendars created since they have major impacts across the organization. Keeping these events in context with your day-to-day planning in Confluence increases their visibility and prevents conflicts.

Holidays and time-off are just the tip of the organization-wide event iceberg. Take a look at your work calendar and you’ll see lunch & learns, committee meetings, submission deadlines (expense reports, timesheets, benefits enrollment, etc.), social events, and more. Centralizing all of this in Confluence can result in a major productivity boost and a calmer work life.

Next, each team should consider the events unique to their work and create logical calendars to match. Marketing teams need to keep content creation, campaign schedules, and ad runs coordinated. Dev and product teams always need to have their release schedule handy. Client-facing teams may need to schedule around their clients’ external schedule of milestones, holiday, and deadlines. IT and service desks will need to keep support professionals informed of planned maintenance and outages. Each team will find they have many calendars and events to keep track of – and they’ll likely do a better job when using Team Calendars versus the invite model imposed by most calendar systems.

PRO TIPS

  • Designate a single calendar as the official organization holiday calendar. Have all other teams add it to the Calendars tab in their spaces. It’s inefficient (and dangerous) to have many different “Acme Co Holiday” calendars! Remember, Team Calendars makes it easy to reuse calendars and combine the calendars into one view! Many organizations choose to have this calendar live in a Human Resources space.
  • If you use Jira to track time-off requests, you can setup Custom Event Types which display these requests from Jira on the calendar to avoid duplicate data entry!
  • Use the Custom Event Types which allow Team Calendars to display live sprints, releases, and more from Jira. Using JQL you can specify exactly what’s displayed on your calendar, automatically updating as Jira changes.
  • If you are working with a client and they can provide an .ics file (usually available as an export option from most calendar services), you can quickly import hundreds of events into a Team Calendar so you can keep tabs on their events.
  • If there’s an existing calendar system you cannot migrate to Team Calendars, you may still be able to display the calendar feed within a Team Calendar. See subscribing to third-party calendars. Examples include Outlook/Exchange, Google, Teamup, Opsgenie, and PagerDuty.

Using Your Calendars

Now that you’ve got calendars setup, you’ll always find them under the Calendars tab within your Confluence space. This tab rolls up all calendars in the space (including calendars linked from other spaces) so you can see holidays, time off, deadlines, and happy hours all in one place. 

But wait! There are additional convenient ways to access your calendars!

  • Embed a calendar into a Confluence page with the Team Calendars macro
  • Link to an existing calendar in another space so that it shows up in your space’s Calendars tab (example: most spaces will likely link to the official corporate holiday calendar)
  • Each Confluence user will see all of the calendars they’ve watched in their My Calendars page
  • Integrate Team Calendars into your personal calendar in Outlook, iPhone, etc. Share these instructions with your users!

MORE TIPS

  • Embed a calendar(s) into your weekly team meeting notes (automate this with a template). Many of our customers have reported dramatically decreased schedule conflicts when the calendar is right there, being reviewed regularly.
  • When viewing calendars in a space’s Calendars tab or all the calendars you’re watching in the My Calendars page, you can temporarily filter out unnecessary event types by unchecking the boxes displayed to the left of the type under its calendar. If you want to hide an entire calendar, click the menu (…) next to a calendar name and choose Hide Events.

Caution

Like all Atlassian tools, it’s easy and intuitive to get started with Team Calendars. Here are some more considerations to make it an even smoother journey.

Calendar Names. A Confluence space’s view permissions are used to determine calendar visibility by default. Team Calendars does not enforce unique calendar names. For admins and others who belong to many Confluence spaces, having 27 calendars all named “PTO” makes it hard to find the correct calendar. We recommend including the space name or key in each calendar name. For example, “PTO - IT Help Desk” and “PTO - Marketing.” 

Beware when deleting custom event types. Deleting a custom event deletes all events assigned that event type. Move events currently categorized under the event type to another event type before deleting.

Migration considerations. Atlassian does not officially support Team Calendars migration but you can export and import each calendar manually to move your calendars. Custom Event Types are great but if you’re migrating to a new environment, make sure you are using the latest version of Team Calendars in both environments, otherwise custom event types may be lost.

Help is here! There’s an entire section of documentation for Team Calendars. If you need Team Calendars licenses (or are looking to migrate to Cloud Premium, which includes Team Calendars), need to migrate your Confluence environment, or need assistance with any part of the Atlassian suite, get in touch with us!

Topics: atlassian blog confluence teams tips project-management confluence-cloud
2 min read

Queues vs. Dashboards in Jira Service Management

By Rebecca Schwartz on Apr 26, 2021 10:15:00 AM

Blogpost-display-image_When do I use JSM queues vs. dashboards-When it comes to understanding the progress of work in Jira, Atlassian has some great options natively within Jira Service Management. Queues are available in each Service Management project in Jira and Dashboards are available in all Jira products. These features give users important insight into what teams are working on, but how do you know when to use which, and why? Having easy access to the progress of work in the system, as well as some of the stats that go along with the quality and completion of the work, is essential for any team's success. Below, I'll discuss the functionality of Queues and Dashboards in Jira and when one should be used over the other. 

What are queues?

Queues are groups of customer requests that appear in Jira Service Management projects. They are used by service desk agents to organize customer requests allowing the team to assign and complete customer requests quickly and efficiently. There are a few helpful queues that come with your service desk, but Jira Admins can also create custom queues if the ones in place are not the correct fit for the team. 

What are Dashboards?

A Dashboard is a page of reports and data visuals related to issues in Jira. Dashboards are customizable and can be tailored to meet the needs of various users throughout the organization. Individual users often create their own Dashboards to easily visualize what outstanding work they specifically need to get done. Teams can use them to see their overall progress of work. Management can use them to get a more high-level overview of the progress of work across the entire organization. Gadgets make up Dashboards and are often based on Jira filters or JQL. They typically come in the form of charts, tables, or lists. Dashboards are available no matter what kind of Jira project you're working in.

When to use queues vs. Dashboards?

Queues are great for agents and other folks who need to work on issues in a service management project. If queues are broken up by SLA's and/or priority, they help agents determine which issues are most urgent and need to be worked on ASAP. Then, agents can easily grab issues from the list and begin working on them. Queues don't give you any stats or overall status on work that's in progress or has yet to be completed. It's simply a way for those working on Jira tickets to organize them and decide what to work on.

While queues are limited to a single project, Dashboards can be used across multiple projects. They give more information on the work and can provide more details such as the time from creation to resolution, how many issues of a particular type were submitted in a given time period, and which agents completed the most issues. Dashboards are perfect for users who need to get an overview of what's going on, but don't necessarily need to work on the issues. Since Dashboards are meant for viewing Jira data, these pages are perfect to give higher-level users an insight into what's going on with the outstanding work. Using gadgets, these users can see where improvements need to be made if, for example, SLAs are continuously breached. They can also be used to see what works well for your teams. 

You have questions?  We have answers!  Contact us to schedule a call with one of our Atlassian experts.

Topics: jira atlassian blog tips service-management tracking project-management jira-service-management
5 min read

How Do You Manage Releases in Atlassian Jira?

By Amanda Babb on Apr 16, 2021 11:05:00 AM

Blogpost-display-image_How do you manage releases in Atlassian-At a recent Atlassian Community Event, I was asked to present on a topic of my choice. After some thought (and to be honest, a poll to our Client Delivery team), I decided on Release Management using Jira. It's a frequent topic of discussion with our clients: how can I understand what will be or is released? Also, what changed between what was in Production to what is in Production now?

I've seen many complicated solutions and I've seen many simple solutions. However, your team, your company, or your organization has to hash out the following: 

  • What is your definition of "Done"?
  • What is your definition of "Release"?
  • Are these two things in conflict? 

Definition of Done versus Definition of Release

As you may already know, in Scrum, "Done" is when the Product Owner accepts the story as complete, meeting all acceptance criteria, and packaged into a potentially shippable increment. While I agree with this definition, at the same time I challenge the phrase, "potentially shippable." This is where you, your teams, your operations teams, and your product managers need to have a conversation. Does "Done" and "Released" mean the same thing across your organization?

In one organization, they had four definitions of done: Done, Done-Done, Done-Done-Done, and Done-Done-Done-Done. In reality, they were defining the QA, deployment, and Production Release processes with the four separate definitions of "Done". This was also directly related to their use of Jira Software and how to demonstrate success to management. Notice I said success and not progress. The Teams wanted credit for code complete in Jira to demonstrate a predictable velocity. QA wanted credit for the test complete in Jira to demonstrate a continuous flow. Jira Release Managers wanted credit in Jira for integration activities before deploying to production. Operations wanted credit in Jira Software for the production deployment. As you can imagine, this was relatively messy in Jira and tying work from code complete through managing the release in Jira to Production was excruciating.

While Done may be clearer to your organization, "Release" may not be as clear. Different parts of the organization will have different definitions of Release. For a team, "Release" may mean the code has been deployed to a QA environment. For Operations, "Release" may mean deployment to Production. In the example above, "Done" and "Release" meant the same thing among the teams, QA, and Jira Release Management, but not Operations. Nor did it mean the same thing across the organization. Without clarity across the organization, tracking and managing Releases in Jira Software becomes nearly impossible. Clearly defining "Done" and clearly defining "Release" across the organization can drive organizational alignment. Once you understand these two concepts, you can manage these Jira releases in Atlassian using the following two methods: The Release Issue Type or Bitbucket Pipelines.

Method One: The Release Issue Type

Within your SDLC projects in Jira, create a new Issue Type called, "Release." This lets the organization know that, while code is complete, there are additional items that need to be fostered through the process. These may include documentation, release notes, a hardening sprint, or anything that can foster work from code complete to Production. The additional items can be managed as Sub-Tasks of the Release to understand the scope of work needed to move it through the process.

As with any new Issue Type, the Release in Jira will need a Workflow. The Workflow can be simple, however, we recommend using a Ready for Production Status in the workflow. When integrating Jira with Jira Service Management, the transition to Ready for Production is a perfect time to automate creating a Change Request. Your Operations team can review the change request with a link back to the Jira Release Issue Type.

How do we know which stories and bugs are tied to the Release in Jira? Do we link all the work to the Release Issue Type? No. I mean, you could, but why take the time to do that? Is it really a value-added activity for traceability? Is there another way to tie these things together that could be quicker and easier? The answer: Yes.

Even long-time users of Jira forget about Versions. If used properly, Versions can provide every team the status, progress, and any known issues in a single view in the Release Hub. This is true for all development activities AND the Release issue. By adding the Fix Version of the intended Release, every part of the organization can see the progress of the Release. Because JQL supports Versions, all items tied to a Fix Version can be displayed in other places such as a Dashboard or a Confluence page. With a little up-front discipline during backlog refinement, or sprint planning, or even big room planning, managing a release in Jira is as simple as adding a Fix Version to the work as well as the Release issue.

When managing Releases in Jira, once the Release issue has been deployed to Production, always go back and release the Version in Jira. Anything that is not in a "Done" status category can either move to the next Version or be removed from any Version entirely.

What if a story or bug spans multiple Releases? There is still only one Release issue per Version. However, I would also challenge you to take a look (again) at your definition of Done versus your definition of Release. Are you actually completing the work or are you pushing it forward again and again because there's a problem? In the next backlog refinement meeting and/or retrospective, ask why this continues to happen. Really dig in and understand whether the work needs to be moved to an Epic, de-prioritized, completed in the next sprint, or abandoned altogether.

Method Two: Bitbucket Pipelines

Using Bitbucket Pipelines still requires your organization to have a conversation defining "Done" and "Release". However, the entities that support these definitions are different when integrating Jira and Bitbucket Pipelines. The Jira Release is managed through the Pipeline and requires little human intervention. Instead, we work with a series of Workflow Triggers and automated deployments to determine where the Release is in its process.

You still need to create a Version in Jira. You still need good discipline during backlog refinement and sprint planning to ensure work is tied to the correct Version. You may also choose to halt the automation just before deployment to Production based on your Change Management processes. Clarify the process before implementing it in Atlassian.

After your Version is created and work is tagged with the Version, add Triggers to your development workflows. For example, you can automate a transition from Open to In Progress based on the creation of a Branch in Bitbucket. You can also automate a transition to Closed or Done once a Pull Request is merged. Triggers in Jira Workflows keep people focused on the work instead of Jira. But where Bitbucket Pipelines really shine is everything that happens after code is merged. Separate Pipelines can be created per environment. For example, if you need to manually deploy to production, a Pipeline can automate the process through build and deploy to a staging environment after it passes all checks. Commits, build, and deploy information is visible in the Development Panel of the individual story or bug. You can even quickly understand failures and receive additional information by clicking on the failure. For a specific Version, as long as work is tagged, you can aggregate the overall health of the Release in the Release Hub by viewing the Version. Status, success, warnings, and errors are available in a central location. If everything looks good, simply click a button and deploy to Production. Alternatively, if the staging deployment is successful, automate the production deployment in the Pipeline as well.

Which Release Management in Jira is right for you?

At Praecipio Consulting, we believe the answer is: "It depends." Regulatory compliance, risk tolerance, product uptime requirements, etc., may dictate which Jira Release Management method is right for your organization. And, to boot, the answer can be different for different parts of the organization. However, the critical first step to implementing release management using Atlassian Jira is to have a conversation. Are your definitions of "Done" and "Release" at odds with one another? What do they mean from a process perspective? Is there room for improvement in those definitions? If you can answer those questions you’re well on your way to having effective release management in Jira.

We here at Praecipio Consulting have extensive experience with both Jira Release Management best practices and the Atlassian suite of products, which we are happy to share with you to help you achieve more effective release management with Jira.

Topics: atlassian blog bitbucket process-consulting scrum tips project-management jira-software
3 min read

Can a Product Owner also be a Scrum Master?

By Morgan Folsom on Apr 12, 2021 10:21:00 AM

Blogpost-display-image_Can a Product Owner also be a Scrum Master-TL;DR: No!

Can one person hold both the Product Owner (PO) and ScrumMaster(SM) role in an Agile team? It's a question that a lot of companies starting their way through their Agile transformation will ask themselves (and us!). The Scrum team has three specific roles: Product Owner, ScrumMaster, and (most importantly) the Development team. It's clear why the question of combining SM and PO comes up so often - trying to figure out where current roles fit into the new dynamic can be a challenge for an organization, especially if your teams are now smaller and you don't have enough resources to fill the role of an SM and PO for each team. 

However, combining these roles is the biggest disservice you can do for your Agile teams. It may seem like a small tweak to the model, but given the functions of the two roles, you are setting up your teams for failure. Let's start with the definitions of these two roles so we can see why that is. 

Product Owner

The focus of the Product Owner is on the Product, as you might have guessed by now.  According to ScrumAlliance.org, "The Product Owner defines the what--as in what the product will look like and what features it should contain." The PO is responsible for maintaining the product backlog, and are responsible for communicating with stakeholders internally and externally to identify what the development team is working on. In their day-to-day, they are responsible for creating and prioritizing backlog items and communicating with the team expectations and acceptance of complete work items. 

ScrumMaster

The focus of the ScrumMaster is the team. "The ScrumMaster helps the Scrum Team perform at their highest level. They also protect the team from both internal and external distractions. ScrumMasters hold the Scrum Team accountable to their working agreements, Scrum values, and to the Scrum framework itself", as defined by ScrumAlliance.org. Where the PO is focused on What, the SM is focused on Who and How.  Arguably, the most important part of this definition is the emphasis on protecting the team. Internal distractions often come in the form of scope creep – new scope being introduced once work has already been committed to. In Scrum this often looks like new stories or bugs being introduced in the middle of a Sprint, and the job of the SM is to prevent this from happening as much as possible.

While I'm sure that we all know that some scope creep is inevitable (unless perhaps you're inhabiting the perfect utopia of business environments, in which case, I'll keep an eye out for my invite), but it can get out of hand quickly if there is no one on the team who is able to push back against the business. 

Okay, so why can't they be the same person?

By definition, the role of the ScrumMaster is to protect the team from the Product Owner (and the stakeholders that they are representing). Blurring the lines between these two roles mean that there is no one to push back when scope is added last minute, or ensure that the team is sticking to Scrum best practices, despite heavy workloads.

The most common outcomes that we see when these two roles are combined are:

  1. Tons of scope creep. Just, loads of it. All over the place.
  2. Sprint commitments are consistently not met because the team is being asked to do more work than they've agreed they are able to. 
  3. Product Owners assign out work to the team , as they are now "Managing" the team. 
  4. Buggier products –  after all, if I'm a developer trying to get through more work than I've acknowledged I can do, quality is inevitably going to suffer

Overall, not great!!

So what should I do then?

In a perfect world, you should have a single ScrumMaster per team, and Product Owner per product. This means that Product Owners can span multiple teams, if the teams are working from the same product backlog, but ScrumMasters are dedicated to a single team. If you don't have enough resources to commit to this model, in the short term, a ScrumMaster could potentially span more than one agile team - but I would say no more than 2 - after all, one person can only attend so many Scrum ceremonies while also being available to unblock their teams. 

However, the long term success of your Agile transformation means that it's time to start planning to fill those roles. Combining these roles will almost certainly decrease the effectiveness of your move to agile, as your teams are left unprotected and (likely) overworked. 

Looking for more information on Scrum best practices? Check out Sprint Planning - How long should sprints be? or Agile Batch Size: An Ode to Laundry

Topics: process scrum workflows project-management agile
2 min read

Should my Jira Service Management instance be separate from Jira Software?

By Praecipio Consulting on Jan 29, 2021 2:04:24 PM

Blogpost-display-image_Should my Jira Service Desk instance be separate from Jira Software-As companies grow either organically or inorganically, many are faced with the decision of whether they should consolidate or keep their Jira instances separate. Today I'm going to address one specific flavor of this conundrum that I am often asked about, specifically with regards to separate instances of Jira Software and Jira Service Management. Some organizations choose to have separate instances for Jira Service Management and Jira Software, but I am here to tell you that is probably not necessary!

Although Jira Software and Jira Service Management are different products, there is no need to keep them separate. The most efficient companies use both in a single instance, so that teams can collaborate much more easily. As organizations adopt DevOps or start to think about it, one of the first things that is looked at is how IT interacts with the development organization. If these two groups are working in separate Jira instances, collaboration and clear understanding of ownership and handoffs is much more difficult. For example, It is much easier to link an incident that was submitted to the service desk to an associated bug if all of those tickets live in the same instance. While you can link to tickets in other instances, that requires users be licensed in both and have a clear understanding of where the work lives. Working in a single instance removes the need for potential duplicate licenses and ensures teams can communicate clearly. 

Occasionally teams use separate instances due to security considerations. However, in almost all situations your security concerns can be addressed by project permissions, application access, and issue security. There are few cases that Jira's native security features won't account for. 

Finally, let's look at this from a user experience perspective. One of the most prominent complaints that we see as organizations undertake their digital transformations are that users have to keep track of too many tools, a pain that I've felt in my career as well. Trying to remember where to log in for a specific subset of your work can be a headache. If your Jira Service Management and Jira Software instances are separate, they'll have two separate URLs that users have to navigate to. Signing into multiple locations and using different URLs adds an extra step where there need not be one.

Since you've already made the great decision to use both Jira Software and Jira Service Management, you might as well reap the benefits of the easy connection between the two so your teams can focus on what matters, rather than managing their tools. 

Are you looking to merge your Jira instances? Contact us, we know all about how to do that, and would love to help.

Topics: jira atlassian optimization tips integration project-management jira-core merge jira-service-management
3 min read

Does a Project Manager fit into an Agile Framework?

By Marcelo Garza on Sep 18, 2020 10:15:00 AM

Project Manager Role in Agile Framework

Project Managers have a wide range of responsibilities when working on a project: they oversee planning the project, create a schedule and timeline, execute each phase, manage budgets, serve as the liaison among all stakeholders, and also troubleshoot and maintenance, plus whatever other tasks that get added to their plate. As such, a Project Manager (PM) must be very organized and detail oriented. They also need to have great people skills because at the end of the day, this person is responsible for leading the team and communicating with all involved parties.

The Project Management Institute describes the role of a project manager as someone who acts as an agent of change. Someone who “makes project goals their own and uses their skills and expertise to inspire a sense of shared purpose within the project team.”

PMs serve as leaders. Aside from ensuring the project is delivered on time and within the agreed-upon budget, they also encourage their teams and inspire their clients. They need to solve problems as they arise with strong critical-thinking capabilities while also possessing strong communication skills to ensure everyone remains informed, motivated, and onboard.

A good PM delivers a final product on time, on budget while meeting or exceeding client expectations. Tracing projects back to business goals is becoming increasingly necessary for project managers.

All brains on deck

The Agile framework focuses on self-organization and team empowerment rather than defining specific roles, which is why there is no need for a Project Manager in the traditional sense; the role is pretty much covered between all the existing roles.

Anyone who's ever taken an Agile class or training has heard of the defined roles of scrum master, product owner, and development team in the scrum framework, which makes no mention of the Project Manager role. Personally, I have taken five Agile classes from different places and never once have heard the word “Project Manager”. So, where does this skill set belong? Is there really no use for a PM in an Agile setting? Is there nothing they can do to add value to an Agile project?

An Agile organization can- and does- function well without a Project Manager. However, there is a huge potential for a PM skill set to add value to an organization, specifically on large projects. I have worked in QA Testing across various complex projects for the past five years, and it is clear to me that a PM can greatly impact both the journey and outcome of the project in regard to budget and risk management, as well as coordination between multiple scrum teams.

In an Agile environment, a Project Manager can add value by managing key aspects of every project, overseeing budgets, risks, etc., especially on large scale projects for enterprise organizations. Having a Project Manager also frees up the Scrum Master to focus solely on his or her core functions. 

Take, for example, the below chart from Ken Rubin and his article “What Happens to the Project Manager when Doing Agile Development with Scrum?”  While the PM role no longer exists in a traditional sense, you can see how the tasks and roles normally assigned to them still exist within the system, but are spread out throughout the team. As a result, the person who would normally act as the PM, can work very well as the Product Owner, the Scrum Master, or on the Development Team, depending on his or her background and specific skillset.

agile project manager

If you are looking to scale Agile principles within your organization, our team at Praecipio Consulting has you covered. Feel free to reach out to us with any questions!

Topics: blog scaled-agile project-management digital-transformation agile
4 min read

How To Run D&D Campaigns With Trello

By Luis Machado on May 28, 2020 11:07:00 AM

2020 Blogposts_How Jira helps your team work remotely copy 3

It’s 2020, and the reality for a lot of folks has seemingly changed overnight. Working from home, remote meetings, a whole slew of new tools to learn and master. It’s a strange new world, and not just for our professional lives but our personal lives as well. So how do we make the change? How can we adapt to this new frontier?

I’ve been playing games with friends on the internet for several years now, way before social distancing practices became the norm. Even though we live hundreds of miles apart, I can still lead a group of close friends through the dark, dangerous lairs and pitting them against frightening creatures, all for glory and the pursuit of the almighty gold coin. There are a plethora of tools available that allow people to play tabletop games without the table, such as Roll 20, D&D Beyond, Discord, Skype, among several others. But there is a distinct lack of tools available for the person running the game, the game master, the dungeon master, the decider of fates, and facilitator of adventure to keep it all organized.  

When running a game there is A LOT to keep track of: monsters, treasure, characters, towns, plot points. If you’re using an old school pen and paper, you’re going to need a mighty large binder. Naturally, the desire to digitize this content has led to some creative methodologies. The one that has stuck with me is using a site that falls right within my wheelhouse: Trello.

At its core, Trello is a tool that helps you manage lists for collaboration. You create a list and then populate it with cards. The title of the card shows up in the list, clicking on the card lets you see an expanded view with more detail. You can also add custom labels to create color codes.

I first came across this idea from a post on Reddit called "DMing with Trello". This method gives you easy access to a board for the DM (as in Dungeon Master!) screen to have frequently referenced rules and definitions handy, a way for tracking combat, and board for managing campaign-specific content.

Campaign Content

dd1

While I'll breakdown how I manage my campaigns, how you organize your lists can vary. I started with making a list for the town Daggerford, where the players interact with each other. Each special location within the town has is its own Trello card. These locations, like a blacksmith, inn, or tavern can be listed for easy reference and the numbers in my list correspond to locations indicated on a map. The use of the built-in labels lets you categorize cards within a list, and the sorting view lets you filter the list with a specific category. So, if I’m looking for just blacksmiths, for example, I can filter the list for just that category.

dd2

dd3

Clicking on one of the cards brings up a larger, more detailed view where you can keep your notes.

dd4

Cards can also be formatted using markup to let you get as fancy as you want.  You can also extend functionality if you’re using Google Chrome by installing a browser extension: Trello Card Optimizer.

dd5

Combat Tracker

dd6

The combat tracker is a series of lists. The first list is where I set the turn order (top to bottom). Each subsequent list is a round of combat, numbered accordingly, and the players and monsters are all cards. You can arrange them all in turn order and then advance them to the next round when it’s their turn by clicking on them and dragging them to the next list. 

Keeping track of combat can be particularly tricky in an online situation. Using Trello gives you an easy, straightforward way to do it.  In this setting, I use the labels for various statuses and ailments. Poisoned by a snake? Petrified by a basilisk? There’s a label for that! Lastly, I keep a card or two at the top of the initiative list for easy access to the music links I use.

DM Screen

dd7

Last, but not least, is the DM screen. Set up in a similar manner to the campaign content, this board offers you the ability to quickly reference game rules that you frequently have to look up. How does grapple work again? What happens when a character is blinded? All these questions and more can be answered here, and you don’t have to worry about accidentally bending or tearing your rule book between sessions.

The DM screen is available as a public board that you can copy to your own account, allowing you to customize it to suit your game. I highly recommend using the Trello Card Optimizer with Chrome because it adds a lot of visual organization to your cards and board. 

Now get out there (and by "out there", I mean exploring the world of Trello from your home), and take a shot at organizing your game. As a final note, when the time comes to reunite with your players for an in-person session, you can travel light with just a laptop and have all your hard work available at your fingertips.

For more information on Trello and the Atlassian suite of products, reach out to your favorite Dungeon Master...er...Platinum Solutions Partner. Happy gaming!

 

 

Topics: collaboration project-management trello atlassian-products

Praecipio Consulting is an Atlassian Platinum Partner

This means that we have the most experience working with Atlassian tools and have insight into new products, features, and beta testing. Through our profound knowledge of Atlassian environments and their intricacies, we can guide your organization as you navigate these important changes.

Atlassian-Platinum-Solution-Partner

In need of professional assistance?

WE'VE GOT YOUR BACK

Contact Us