4 min read

Waterfall vs. Agile: Choosing the Right Methodology | Praecipio Consulting

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

Blogpost-DisplayImage-August copy_Waterfall vs. Agile- Choosing the Right Methodology

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.

Blogpost-DisplayImage-August copy_Diagram-phases

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.

Blogpost-DisplayImage-August copy_Diagram-2

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

Blogpost-DisplayImage-August-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 Morgan Folsom on Jul 2, 2021 9:15:00 AM

Blogpost-DisplayImage-June_Can my Scrum Master have multiple roles on a team-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

Blogpost-DisplayImage-June_New to Scrum Master Role Guide–Part2TheDefinitionofDoneThis 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

Blogpost-DisplayImage-June_New to Scrum Master Role Guide – Part 1 (2)

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?

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. 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 Software to demonstrate a predictable velocity. QA wanted credit for test complete in Jira Software to demonstrate a continuous flow. Release Managers wanted credit in Jira Software 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 Software and tying work from code complete through release 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 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 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 Software, 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 will need a Workflow. The Workflow can be simple, however, we recommend using a Ready for Production Status in the workflow. When integrating Jira Software 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 Release Issue Type. 

How do we know which stories and bugs are tied to the Release? 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 Software 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 is as simple as adding a Fix Version to the work as well as the Release issue. 

Once the Release issue has been deployed to Production, always go back and release the Version in Jira Software. 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 Software and Bitbucket Pipelines. The 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 Software. 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 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 Software. 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 one 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 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 in Atlassian 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? We here at Praecipio Consulting have extensive experience with both Release Management best practices and the Atlassian suite of products. Contact us to find out how we can help you manage your releases more effectively. 

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

Can a Product Owner also be a ScrumMaster?

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: blog process scrum workflows project-management agile
2 min read

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

By Morgan Folsom 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 blog optimization tips integration project-management jira-core merge jira-service-management
4 min read

Turn Your Next Project into a Promotion

By Christian Lane on Oct 1, 2020 1:15:00 PM

Blogpost-display-image_Do These Things to Leverage a Successful Project Into a Promotion

Make this next project the one that gets you noticed.

Kate Cornell was in a tough spot. Her fast company growth exposed a weakness. Her project management tools were a collection of cobbled-together solutions that were never purposely developed for case management or tracking complex projects. As a result, the team was fragmented and communications were inefficient, making work difficult to track. 

There had to be a better way. When the problem was presented to the management team, she was tasked with figuring it out.

Smartly, she knew that she needed some specialized help in not only choosing a platform but configuring it to meet the present and future needs of the company. After vetting multiple vendors, she chose Praecipio Consulting, a Platinum Atlassian Partner known for their strategic approach and ease to do business with, not to mention their expertise around the Atlassian platform.

katie aci blog post

In her role as the Director of IT Project Management for ACI Worldwide, it’s her responsibility to make sure projects like these are executed well. The company depends on it - careers depend on it.

Thankfully, this project was an enormous success. In a double win, the company was able to save significant costs and the Atlassian technology stack is exactly what they needed.  

Now that the project is complete, we asked her to reflect on the process and what she would recommend to others faced with a similar challenge.

Tell us about the vendor and how they performed for you. 

“I knew from the get-go that this is a project we needed help with. We used our previous CRM-based system for 10+ years, and there was an incredible amount of data that needed to be migrated over. But what impressed me most was their ability to ask questions and gather requirements. You can tell they had lots of experience. They led us in directions we didn’t know we needed to explore.”

What did success look like?

“I’m calling the project a huge success - first, because the solution works well. The data moved over, and we finally have everyone on the same tool. It’s nice to have a framework that is purpose-built for what we need. We’re able to move faster and with more efficiency than ever before. What I’m most proud of though is the broad adoption among our team. It’s hard to break out of your routine and use something new. Going through a necessary learning curve is difficult and cumbersome, but our team bought into the long-term vision and saw the value immediately.

What advice would you give project managers that want to fast forward their careers with a project like this?

Don’t operate in a silo. Design an escalation process so that when you get stuck, you can bring in other stakeholders to work toward a solution. Transparency is key. Managers don’t like surprises. They understand challenges will arise and usually, they are willing to help. But make sure you have a plan to execute and not just a problem with no solution. 

Set realistic expectations. I want my managers to commit to running at a rate of speed they feel is appropriate considering they have multiple projects. If we are managing the business correctly, everything is not an emergency. I can wait an extra two weeks if it means the project is done right the first time. 

Clearly define done. Ambiguity is a productivity killer and it can ruin relationships. The best managers we have err on the side of over-communication versus under. Making sure all relevant team members are aware of progress milestones, have an opportunity to provide input, and understand how this project fits within our overall mission is how it should be done. 

Be predictable and reliable. Successfully handling projects that deliver on time and within budget earns you a reputation as someone who delivers results. Our best managers are the ones that use company resources wisely and think one step ahead of the task at hand. This strategic mindset gives managers comfort knowing that they don’t have to worry about micromanaging.

Praecipio Consulting's take on how to leverage a successful project:

In our experience, we have seen how production-based project managers have climbed the ladder of success. One common theme? They make others around them better. Getting the most from your team and developing the talent of tomorrow has far-reaching implications for any company. At Praecipio Consulting, we are in the business of making our clients more competitive while helping them realize cost savings through better processes and better technology. IT project managers that have an upward career trajectory tend to not get caught up in technical jargon and can talk to the C-suite in terms of ROI and how the project fits into the strategic plan.

One thing all experts agree on is that communication between management, engineers, vendors, and even other third parties will mitigate the risk of a project losing momentum or failing. If your communication skills can match your ability to motivate teams and deliver technical projects, you’ll be asked to take on more and more important projects and be rewarded accordingly.

If you're interested in the game-changing solutions that Atlassian products can bring to your business, let's chat!

Topics: enterprise project-management atlassian-products atlassian-solution-partner
2 min read

Does a Project Manager fit into an Agile World?

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 are in charge of planning the project, creating a schedule and timeline, executing each phase, managing budgets, serving as the liaison among all stakeholders, and also troubleshooting and maintenance in addition to other activities. As such, a Project Manager(PM) must be very organized and detail-oriented. A PM also needs 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.”

Project managers 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 traditional command and control project manager; the project manager role is pretty much covered between all the existing roles there are.

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. 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 project manager in an Agile setting? Is there nothing a project manager can do to add value to an Agile project? 

An Agile organization can–and does–function without a project manager. However, there is 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 regards to budget and risk management, as well as coordination between multiple scrum teams.

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.

Project Manager vs Agile management

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
6 min read

How Jira Align Helps Embrace Lean Budgets

By Amanda Babb on Jul 1, 2020 2:30:21 PM

2020 Blogposts_Lean Budgets in SAFe and Jira Align

Hopefully, you've followed my posts and webinars on Portfolio for Jira, as well as how to manage Lean Budgets in Atlassian and its ecosystem. We released a White Paper providing a solution for mid-sized organizations that have embraced SAFe® and want to also incorporate Lean Budgets concepts within the Atlassian technology stack. After all, one of the most critical pieces of adopting an agile mindset is to break the cycle of traditional Project Cost Accounting. 

Project Cost Accounting and agile frameworks (regardless of the flavor) are in direct conflict with one another. Moving teams to work in a Project Cost Accounting model does not work in agile frameworks. Instead, we move work to teams. When we scale agile, regardless of the model, all we're doing is connecting the overarching strategic initiatives to execution. Also, we're all still trying to figure out how to understand the costs associated with the work. SAFe® offers the seductive allure of Lean Budgets. Simply define the Enterprise budget and allocate it to the Portfolios to do what they will. Wait, what? Just hand over $100,000,000 to a Portfolio for the year and trust that they'll make the right decisions? As Yogi Berra once said, "In theory, there's no difference between theory and practice. In practice, there is." 

Lean Budgets Guardrails

While the Atlassian tools and ecosystem are not intended to be the financial system of record for any organization, one key part of Lean Budgets, which is called out several times in the Lean Portfolio Management competency in SAFe® 5.0, is to provide Guardrails. The four Guardrails are as follows: 

  1. Guiding investments by horizon
  2. Applying capacity allocation to optimize value and solution integrity
  3. Approving significant initiatives
  4. Continuous Business Owner engagement

© Scaled Agile, Inc.

The Atlassian tools, and specifically Jira Align, are uniquely positioned to provide the Guardrails for Lean Budgets. By adhering to the SAFe® Core Values of Transparency and Program Execution, Jira Align provides complete aggregation from the corporate strategy, including Mission, Vision, and Values, all the way through team-level execution and back up again. This includes Allocation, Estimate, and Actual comparisons based on the Program Increment. Mind-blowing, right? 

While you will have to wait for the full solution (details are coming soon), here are a few tips to assist you in your journey. 

Create a Strategic Snapshot

Your organization has a well-established Mission, Vision, and Values. They're likely plastered all over your organization's intranet or when in an office, you'll find them displayed every 25 feet down the halls. Add these into the Enterprise Room in a strategic snapshot that aligns with your fiscal year. Break down the Mission, Vision, and Values into long-term, annual goals and establish your Strategic Themes. Add those into Jira Align to start tying execution to these items.

Screen Shot 2020-06-24 at 10.03.55 PM

Themes are an entity in Jira Align. Think of them as an Issue Type that drives the rest of the hierarchy. However, one of the key strengths of Jira Align is ensuring, at every level, the entity is tied to execution. In SAFe® the key execution entity is the Program Increment (PI). Even if a Theme straddles several PIs, you must commit to the timebox of the PI. This drives the entire organization to say, "This thing is important to us, and this is how and when we plan on executing it." While at first, you may have no idea, you can always go back and add the information after the fact. 

Determine Theme Allocation for the PI

While you may not know the exact dollar amount while planning the budget, you've likely done the SWAG for the fiscal year. SWAG, of course, stands for Scientific Wild Ass Guess. As you're determining your Themes and Portfolio Epics for the Fiscal Year (or just your Themes), you will likely have a high-level idea of how much of the pie you will allocate to each Theme. Since they are also ranked by highest to lowest priority, the allocations should follow suit as well. If a Theme is ranked number one, it should have a higher percentage allocated than, say, Theme number 10. Theme allocations can be updated as your organization moves through the budget cycle. Jira Align will do the calculation for you as you determine the overall budget. 

However, to truly succeed at Lean Budgets in Jira Align, you must determine the budget for the PI. Again, as you're working through your organization's budget cycle, you can start with your SWAG. For example, if you have an overall budget of $100,000,000 for the fiscal year and your PI cadence puts you at 12-week PIs, then allocate $25,000,000 per PI to start. By tagging your Themes with the PI(s), you can start to understand the dollars, as well as the overall level of effort, needed for a specific PI. As you get closer to final budget approval, continue to refine these numbers. 

Determine a Blended Rate

While I've proposed a series of different methods for translating Story Points to dollars either via Cost Per Story Point or Total Cost of Solution or Monetized Opportunity Cost, the fact remains that we live in a time-based world (sigh). And our best method for translation still comes from determining a Blended Rate. In Jira Align, once you've determined the Blended Rate for the PI, you simply enter it into a field and the magic starts to happen. But how do we determine a Blended Rate? 

Remember, a fixed Team equals a fixed cost. Take the combined salary of the team members, divide it by workweeks, then divide it by work hours. You can skip a step if you remember the exact number of working hours are in a year, but that number will vary based on your geolocation. You can always adjust as needed based on PTO policies and holidays to determine the Blended Rate. From there, Jira Align takes over once you're in execution mode. 

Budget, Estimate, and Actual

In the Portfolio section of Jira Align, you can quickly access a report called Investment versus Actuals. Wait, what? It's that simple? I click a button, and I can compare plan, actual, and variance? That can't be right. 

To be honest, it truly is that simple. However, if Teams aren't fostering good data in Jira Software and if RTEs, Program Owners, Epic Owners, and the like, aren't making the connections in Jira Align, you will end up with junk. This leads to frustration, as well as low adoption levels of the solution. Take a deep breath, and remember Principle #1 of SAFe ®: Take an economic view. Just like any other tools your organization uses, you must adhere to the process and commit to the facilitation of that process within the tools. 

Based on the historical Velocity of the individual Teams in a Program, the Blended Rate, the Teams' Burn Hours, and the Theme Allocation, Jira Align will calculate the Estimate (original estimate at the start of the Program Increment) as well as the Actual (actual completed stories in each of the Sprints). This is where the Team discipline comes in. If Teams do not estimate work, move cards across the board, and close Sprints, this fails. You cannot calculate the roll-up, or if you do, it's wildly inaccurate. Thus, the comparisons are out of whack, and when compared against the financial system of record, you find that you've spent your time and money on Theme number 10 instead of Theme number one. 

Want to know more? 

In the coming days, Praecipio Consulting will release a White Paper detailing the solution to managing Lean Budgets with Jira Align. We look forward to your questions and feedback. Lean Budgets is still an emerging concept, and while we have a solid solution, we'd love to know how your organization is currently managing or where you are in your digital transformation journey with the Atlassian tools.

Topics: blog scaled-agile teams tips lean-budgets project-management jira-align safe
4 min read

How To Run D&D Campaigns With Trello

By Luis Machado on May 29, 2020 12:45:00 PM

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
3 min read

How to Make State Business Services Better, with Automation by Atlassian

By Atlassian on May 28, 2020 5:31:07 PM

Moving through processes faster, improving service responses, and reducing unnecessary workloads are three great ways to make state business services better, less costly and more efficient. Digital project management, service desk, and knowledge management tools can provide these benefits and more with powerful yet easy to use automation features. Here are 3 ways that the Business Services Division of Secretary of State departments can use automation to improve job satisfaction, reduce costs, and at the same time boost the state’s economic development, with Atlassian solutions.

At Atlassian, we help teams of all shapes and sizes work better and more efficiently with an integrated and comprehensive set of tools, services, and playbooks. For this example, we will look at the automation capabilities within three of our tools: Jira Core, Jira Software, and Confluence.

Make Workflows Move Faster with Jira Core

Jira Core is designed for managing projects and keeping teams organized. Workflows are one of its most powerful features. From simple to complex, you define the workflows to match your process, tasks, and tracking needs. As tasks move through the workflow, built-in automation makes the process faster and easier. For example, you can have new business license applications automatically routed and assigned to the appropriate team member based on current workload, expertise, or any other criteria. Make things simpler and reduce confusion by hiding fields that are not necessary for the current application or status. Modify field permissions and restrictions to ensure the right people act on the right things at the right times. Or generate automatic email notifications to key stakeholders when applications change status, including external addresses such as the person who submitted it. By automating workflows, you spend less time on administrative tasks and more time on strategic ones.

Create Automatic Reminders for Open Issues with Jira Service Desk

Jira Service Desk is ideal for delivering exceptional services, and issue tracking is a core component. You can see and collaboratively resolve issues based on your defined set of priorities. Sometimes your team gets really busy, perhaps with an unusual flood of queries or new applications, causing them to overlook a few open issues. In a manual world, these slipups may not come to light until a detailed status review meeting or the originator complains, negatively impacting service targets and satisfaction ratings. Automating reminders eliminates this risk. For each different status you can easily specify how long an issue can remain unchanged before a notification is sent, in minutes, hours, or days. This simple trick keeps things flowing and ensures that the team processes issues in the proper order and timeframe. It also serves as the baseline for some pretty great team performance analytics.

Use Page Templates to Improve Operations with Confluence

Confluence provides a team workspace for collaborating and organizing work. Confluence page templates are essential building blocks for reducing duplication and enhancing compliance. There are many ways to choose templates, whether provided by Atlassian right out-of-the-box, available from our extensive marketplace, or created for your specific needs. Staff get a jump start on their work by using a template instead of starting from a blank entry. For example, a meeting notes template starts things off quickly by automatically bringing forward open action items. Add your agenda, record discussions and decisions during the meeting, and update action items as they are worked on. These are a tremendous boost for remote or distributed teams, too. Teams collaborate more easily and stay on the same page at the same time—with each team member seeing the updates in real-time. Team members each have their own to-do lists generated from these and other meeting notes, giving them a complete and up-to-date view of what they need to work on.

Automation makes things work faster, improves response times, and results in higher job satisfaction. State business services departments can leverage Atlassian’s powerful, easy-touse automation to enhance productivity, respond faster, and help fuel their state’s economic development.

Topics: jira atlassian blog automation confluence government project-management atlassian-products
6 min read

Comparing Project Management with American Football

By Nicholas Redwine on Sep 3, 2019 1:43:00 PM

As the summer comes to a close here in America, another season arises upon us that encapsulates the fall and winter seasons for the better part of 6 months. That fun and exciting season is American football ladies and gents! A nationally televised spectacle that brings together all types of people and backgrounds to witness the output from an assembly of individuals striving to capture a "W" or win for their respective team(s) and organization(s).

With the exception of the direct national spotlight, the aforementioned statement sounds a lot like what Project Management entails. If we take into consideration the end-to-end phases of both Football teams and PM teams, we can see there are frameworks and disciplines that run parallel to accomplish the "finished product" (which is ultimately what the end-user or fan actually sees).

Below, is a side by side comparison of the phases and how similar they are in relation to one another:

project-managementScreen Shot 2018-08-09 at 2.17.50 PM

Project Management Framework Phases & Explanations
Football Framework Phases & Explanations

Project Initiation

The first phase of the project lifecycle. This is where the project’s value and feasibility are measured. Project managers typically use two evaluation tools to decide whether or not to pursue a project. Product Owners are key stakeholders and generally have a vision that he/she has to convey to the scrum team.

Talent Assessment & Utilization

This phase is where coaches and internal staff line up and evaluate the current talent (player's) and incoming talent they have for the upcoming season in oder to develop schemes and strategies that will be implemented towards the upcoming season. In relation to Project Management, the Head Coach would serve as the Project Manager defining the team and the direction they should go. Assistant Coaches would be more of the Product Owners with them needing to coach their player's (scrum team) specific techniques and the fine details of the schemes in to fit execution. This will involve many hours of building play-books, film repositories, team drills and sessions to help build examples in order to convey clear, concise messages.

 

 

Project Planning

Once the project receives the green light, it needs a solid plan to guide the team, as well as keep them on time and on budget. A well-written project plan gives guidance for obtaining resources, acquiring financing and procuring required materials. The project plan gives the team direction for producing quality outputs, handling risk, creating acceptance, communicating benefits to stakeholders and managing suppliers.

Offseason Workouts

This phase is the most important as it broken down into smaller meta-phases which put into action team chemistry, focus and preparation that will guide them to the start of the season. Here, many resources are compiled/executed in order to mold them team. This includes strength and conditioning (winter & summer), nutritional diets, film-study and wellness (recovery & massages). All of which are under a close watch with analytics playing a huge role in the development and growth of the athletes. In the NFL, there is a practice period called OTA's (Off-Season Training Activities) where the team has mini-practices that are built for speed and efficiency and in college, Spring Football which essentially is the same concept where development is further evaluated to determine if the team is capable to match the derived schemes with the personnel they have long-term.

Project Execution

This is the phase that is most commonly associated with project management. Execution is all about building deliverables that satisfy the customer. Team leaders make this happen by allocating resources and keeping team members focused on their assigned tasks.

Practice & Game Day

Just like project management, this is the phase where the strategies and playbook installations are put to the test with full-blown practices up to 2x/day to refine and simulate what actual game speed and tempo would be. This allows the coaches and team to have a concrete idea of what they envisioned vs what they're actually able to execute. Furthermore, this is an area that allows coaches to further determine how effective the off-season development was and if the proper adjustments were made from the previous iterative-shortened cycles of the previous practices. This essentially moves to " Game-Day" where the players and coaches are able to showcase to the world and those watching the product that they've come up with for the start of the season.

Project Monitoring and Control

Monitoring and control are sometimes combined with execution because they often occur at the same time. As teams execute their project plan, they must constantly monitor their own progress.

To guarantee delivery of what was promised, teams must monitor tasks to prevent scope creep, calculate key performance indicators and track variations from allotted cost and time. This constant vigilance helps keep the project moving ahead smoothly.

Film Study & Adjustments

Many variables play into the season that are realistically expected but not hoped for. Issues such as injuries, player conduct, chemistry and coaching can contribute to negative/positive outcomes and performances. Being able to monitor this with rigorous film study and culture curation can absolutely help soften the blow of negative outcomes but also serve as a roadmap in the continuation of success. Much like project management, key indicators must be addressed and preventative maintenance must be accomplished in order to keep the momentum towards the end goal. Many bumps may occur but this is where flexibility and team focus are paramount. Usually coaches and players alike will remind themselves and others of the long-road they took to get to this point and the importance of team camaraderie. In a sense, there could be another project spun up in the middle of the season that could be supplemental to the primary project which forces a huge amount of flexibility. Although the odds of executing are high in failure rates, there have been numerous teams that have gone on to conquer and eventually have a winning season and sometimes a season resulting in the ultimate goal of a "championship"

Project Closure

Teams close a project when they deliver the finished project to the customer, communicating completion to stakeholders and releasing resources to other projects. This vital step in the project lifecycle allows the team to evaluate and document the project and move on the next one, using previous project mistakes and successes to build stronger processes and more successful teams.

End of Season

The end of the season marks the end of that particular team. In football, and sports in general, no (1) team is ever the same. Off-Season trades, Retirements, Drafts and coaching changes in the NFL are always a guarantee and the same goes for college with the exception of graduation, transfers and recruiting classes from High School to College. These variables all play into the development of a new team with new goals for the new year.

The summation of the season is literally defined by the W-L (Win-Loss) column. It doesn't matter about what was in between or participant trophies but rather if the team delivered. And that is much like Project Management, " What did you deliver?" A "W" (win) or "L" (loss) for your spectators/customers?

Ready to tackle an Atlassian project? Contact Praecipio Consulting to learn more about our expertise across a wide array of management methodologies, and deep knowledge of the Atlassian toolset. Or take some time to view our webinar Agile Project Management with Atlassian and Tempo to learn how to seamlessly manage projects and portfolios in one place. 

Topics: blog practices project-management
4 min read

Project Cost Accounting in Agile: Balancing Tradition and Innovation | Part 3 of 3

By Amanda Babb on Apr 16, 2019 10:33:00 AM

Third of Three

This is the third (and last) of a three series blog. Our lesson began where you learned that the Secret of Project Cost Accounting in Agile is Nothing. Then we reminded you to Never Forget Where You Came From and in this blog, we show you how to balance tradition and innovation.

The student becomes the teacher. At least, that's how it starts in Kung Fu Panda 3. Master Shifu is retiring and asks that Po, the Dragon Warrior, takes on the project of continuing the training of the Furious Five and other recruits in the Valley of Peace. Much like the agile organization, this causes some initial pain and confusion as everyone tries to settle into their new roles. Meanwhile, a new danger lurks on the horizon: Kai, a once-brother-in-arms of Master Oogway, is intent on revenge against the Kung Fu masters of China. He begins to collect them as jade trinkets as he marches toward the Valley of Peace. His defeat can only come at the hands of someone who has mastered Chi.

Change in an Agile Organization

Change in any organization is inevitable. Change in an agile organization is inevitable as well. However, that does not mean that change means the complete ramp-down of the resources tasked with delivering value to the customer. Nor does this mean that investment is so inflexible that it must be maintained indefinitely for a specific Value Stream. Instead, the value delivery of the Team or Team of Teams changes: support the solution until the next set of Epic-level initiatives are ready to be implemented. In Lean Budgets, the funding of a Value Stream changes based on the solution value delivery and the needs of the customer. What will it cost to operate and maintain the solution? Who bears this responsibility?

Empower Value Stream Content Authority

In project cost accounting, the resources are ramped down or the entire project is handed-off to "Operations". The funding between the development of the solution and the maintenance of the solution is moved between cost centers. As we know from Lean, handoffs are considered a form of waste and, quite frankly, messy. The Furious Five are pummeled by the training equipment as Po frantically shouts out conflicting orders and information based only on what he thinks the way the school should operate instead of trusting himself. He forgot to "Empower value stream content authority." In many organizations, this same confusion, enmity, and pain is the same: Go ahead, Operations, and maintain the thing you've only been involved in for a short time and make sure you don't mess it up. What if we instead maintained a Team or Train to operate the solution and instead moved funding to another Value Stream? The solution remains the same: defeat the enemy (in this case Kai), but the solution context changes in favor of a village of pandas...er...an emerging technology.

lean portfolio cost accounting in agile

Trains are Fixed, but Shifting is Possible

As stated previously, if the Trains are fixed, the costs are fixed. Development and maintenance of a particular solution should then remain fixed. Only when a new set of Epic-level initiatives are given the green light and prioritized, should the Value Stream funding change to accommodate the solution. The Train itself costs $50,000 per PI (as stated in the previous posts) and shall continue to cost that as they maintain the solution. Infrastructure, new equipment, development platform management systems, licensing, etc., are what becomes variable. And this is where we can draw on the techniques that project cost accounting provide. Because these Epic-level initiatives are introduced at the PI boundary, this is also where, if needed, an additional Train can be launched or a train may shift from Value Stream to Value Stream.

Balancing Tradition and Innovation

Wait, what? Didn't we just say that if the Trains are fixed, the costs are fixed? But we're launching another Train or we're moving a Train? Doesn't that mean that the costs changed? Absolutely. This is where Po learns that teaching a bunch of Pandas traditional Kung Fu techniques is not the right solution. He maintains a healthy respect for the traditions of the past (project cost accounting) while balancing the needs of the future (lean budgets). If we launch another Train, what really has changed? We've simply added to the fixed costs for the number of PIs it takes to create and deploy the solution. Instead of $50,000 per PI, we've doubled to $100,000. The additional $50,000 is moved between the Value Streams. In the above diagram, this is demonstrated in PI 3. The funding is still part of the same overall pie, but current priorities mean that launching another Train will enable a different Value Stream to deliver on those priorities. Content authority is still empowered at the Value Stream and Epic-level initiatives are still prioritized within the Value Stream. If value is not delivered, funding can shift back to a different Value Stream the next PI. Po and the Pandas are able to defeat Kai because the investment shifted from the Kung Fu training school in the Valley of Peace to the Panda Village. The work was moved to the Train, not the Train to the work.

Simple... in Theory

While the concepts we've discussed throughout this series are simple in theory, they are difficult to manage in practice. As Yogi Berra once said: "In theory, there is no difference between theory and practice. In practice, there is." Stay tuned. We here at Praecipio Consulting have some great solutions that can turn this theory into practice leveraging the Atlassian tool set.

Topics: scaled-agile project-management
8 min read

Project Cost Accounting in Agile | Part 2 of 3

By Amanda Babb on Apr 5, 2019 12:00:00 PM

Second of Three

This is the second of a three series blog. When we last left our intrepid writer, we learned that the secret of Project Cost Accounting in Agile is Nothing. Fixed Teams means Fixed Costs. Fixed Teams means predictable velocity. In Kung Fu Panda 2, however, there is a danger lurking on the horizon: Lord Shen (a peacock) believes in a prophecy which leads him to destroy all pandas in China. He also yearns to regain the respect of his family by conquering China with a new weapon. In many organizations, Lord Shen is the dreaded spreadsheet: the ability to modify project costs based on resource leveling and moving Teams to the work.

Embrace the Past

Let me make this clear: tools are only as effective as the hand that wields them. Lord Shen took gunpowder, used in the making of fireworks, and developed cannons to defeat China. Something that was devised to bring joy to the masses was changed into something destructive which, had it not been for the fortitude of Po and the Furious Five, could have ended disastrously for China. Let's take a look at why project cost accounting can lead us to further victory by embracing our past while securing our future.

The Agile Team Seeks Balance

The Agile Team seeks to maintain balance: deliver the right functionality at the right time producing as much value for the business as possible. Scrum Master, Product Owner, and Team must work together to understand and provide the value. When business value is monetized, it becomes an easy value to track as a KPI, but hard to predict. What did we get for the $260,000 of labor costs we incurred for the team? In fact, what did we get for the $2.6m of costs we incurred for the Agile Release Train (Team of Teams)? If we were able to make revenue on the effort, then the math is simple: subtract the revenue from the costs and we see our net gain or loss. But we all know that actual financial management in any organization is decidedly more complicated. At least in the United States, there are tax breaks for Research and Development, differences between capitalizable and operational funding, and other financial aspects that many people who are much smarter than me spend their careers managing. Is there a way of reconciling our past models with our current and future state of agile? Can we gain the inner peace Master Shifu states Po (and by proxy, the audience) have yet to attain?

PI Boundary

There has been a debate raging on in the agile community around this concept for a few years. While I do not have all the answers with respect to this topic, I have a few ideas. One organization in particular comes to mind where this worked beautifully: a Value Stream with four Agile Release Trains (ARTs) was given their annual investment of $100m to be spread across seven Strategic Themes. The owners of each Strategic Theme came up with a series of initiatives and prioritized them against one another at each PI Boundary. Since Train costs are fixed at the Program Increment (PI) Boundary, if an initiative was completed, its cost was removed from the $100m pool. Any additional variables such as number of Sprints if an initiative was completed mid-PI were accounted for at the PI boundary as well. Simple, elegant, decentralized.

Lean Budgets

However, there was still the need to understand how much of that chunk of money remained at each PI Boundary and whether additional funds could be allocated to another Strategic Theme or another vertical within the company if money was left over. In Kung Fu Panda 2, Po, upon being confronted with a pack of wolf bandits sees a symbol and flashes back to his youngest memories: he's seen the symbol before, but cannot grasp the importance of it. He only knows it's something to pay attention to. Much like when, in SAFe, we discuss the concept of Lean Budgets. We instinctively know this is something to pay attention to, but we still cling to project cost accounting as our method of reconciliation. Below is an example of Lean Budgets in SAFe. 

Project Cost Accounting in Agile past and future

https://www.scaledagileframework.com/lean-budgets/

Value Stream

The Lean Budgets concept strives to balance governance and empowerment while providing a simple funding model for a given Value Stream. A Value Stream is the organizational structure that provides a continuous flow of value through solutions to the customer (aka the Execution Engine). For example, a Value Stream can be a factory or a hospital. It can also be a development organization - as long as it is focused around solution delivery to a customer. Many organizations struggle to define Value Streams and instead loosely group teams together under a resource manager or other traditional reporting structure and call it an Agile Release Train. While effective on the surface, it complicates coordination across efforts. It's not until a common solution and purpose is defined that the organization can move forward. Lord Shen, as a common enemy across districts, aligns the Valley of Peace and Gongmen City. The teams come together with the needed resources to eventually defeat Lord Shen, but not without trials and tribulations. It is not easy to align an organization to value delivery just as it was not easy to eventually defeat Lord Shen.

If Teams are Fixed, Costs are Fixed

As I stated in the previous post, if Teams are fixed, costs are fixed. If Trains are fixed, costs are fixed. The only funding needed to produce a solution is to cover the cost of the Train. And the cost of the Train should be predictable through a PI. Assuming a single Train in the Value Stream, if each project team costs $260,000 per year, then a Train with 10 teams costs $2.6m per year. Divide the cost of the Train by the number of Sprints in the year (26), then multiply by the number of Sprints in the PIs (typically five), $50,000 is needed for the Train in the PI. Provide the Value Stream $50,000 and watch them work.

Once a Value Stream is defined, Lean Budgets then states it is important to "Empower Value Stream Content Authority." Storming Ox and Croc sit, defeated, in Gongmen City prison. It's only when the Furious Five and Po join them and demonstrate their ability to win a single battle that the two become empowered enough to try and save their city. Before this initial battle, there was no plan other than escaping Lord Shen. The Stretch Goal was to also destroy his cannon. There was no meticulously created work breakdown structure. There were no step-by-step dependencies. There was a single solution the Train needed to implement: learn Lord Shen's plan, escape Lord Shen, regroup to create a plan to defeat him. Our Train (Storming Ox, Croc, the Furious Five, and Po) completed their objective and stretch objective simply by understanding their value and executing on a single purpose.

Project Cost Accounting Starts with the Goal

If, as an organization, we instead try to use project cost accounting, we hinder the Train's ability to provide value. Project cost accounting starts with the goal: defeat Lord Shen. To defeat Lord Shen, we need all three Kung Fu Leaders from Gongmen City: Thundering Rhino, Storming Ox, and Croc. If we have all three, we can defeat him in a day and move onto the next project...er...battle. Three resources for eight hours = 24 resource hours. At $50/hour (our typical cost per hour), $1200 to defeat Lord Shen. This leaves the Furious Five and Po to defend a village from wolf bandits who, in fact, are Lord Shen's minions. The solution does not address the problem as a whole: Lord Shen is the root cause of the battles thus causing the Teams to move to the work. As we move through the story, it took the entire Train to defeat Lord Shen in just one battle and had Po and the Furious Five team members had content authority (knowing what Master Shifu knew about Lord Shen), they might have been able to save Thundering Rhino.

Evidence = Value Delivery Priorities

There are three other parts of Lean Budgets we haven't addressed: Provide objective evidence of fitness for purpose; Approve Epic-level initiatives; Exercise fiscal governance with dynamic budgeting. Let's take objective evidence first. The System Demos and DevOps model addressed in the Program Level of SAFe provides the organization the ability to provide objective evidence. Is it working code in production with dark features toggled on? Yes. Value has been delivered to the customer. Did our intrepid warriors escape? Yes. They were able to escape Lord Shen. However, what happens if value was not delivered? What happens if it takes another PI to deliver the solution? Taking the foundational approach from the project cost accounting model, we have to fund the Train for a second PI. Instead of $50,000 to deliver the solution, it is now $100,000 ($50,000 per PI times two PIs). However, if the cost of the Train has already been accounted for, this is a simple shift in priority, not a movement of funding. You don't have to find another $50,000. Instead, you negotiate whether it makes sense to continue the effort or abandon it based on other value delivery priorities. The path to inner peace starts to become clear.

Approve Epic-Level Initiatives

This ties beautifully into the next part of Lean Budgets: Approve Epic-level initiatives. As we established, the funding is there. If after evaluating the fitness for purpose, the choice is to abandon the effort, the Trains and Teams do not disband. Instead, the work changes as priorities shift toward the next Epic-level Initiative - moving the work to the Teams and Trains. The costs remain constant: only "how" changes, not the "what". The Epic-level initiative is still to defeat Lord Shen: it is the approach that changes for Po and the Furious Five ultimately giving them the flexibility to deliver the victory to China. The Teams and Trains shift to the new strategy and work toward the solutions continue.

Fiscal Governance with Dynamic Budgeting

Lastly, we address the final step on the path toward Inner Peace: Exercise fiscal governance with dynamic budgeting. Much like achieving inner peace, this is not something that is achieved quickly. The recommendation from SAFe is this is addressed semi-annually whereas project cost accounting re-evaluates every work effort once complete. If the effort is small (e.g. 1 month or two Sprints), the allocation of funding to the Team or Train must be evaluated off-cadence meaning mid-sprint or mid-PI. Depending on the internal procurement procedures, this can become a Herculean effort for Business Owners, Epic Owners, and oft times, the Team or Train. It is an unnecessary distraction and thoroughly disrupts the execution. Remember the Kung Fu Leaders of Gongmen City. The first battle with Lord Shen was lost when defined to a specific Team without the proper resources and an unrealistic estimate of the level of effort. Subsequent battles also proved project cost accounting failed the Team: the Furious Five were imprisoned, Po was injured and near death only to be saved by a soothsayer showing him the truth of his past.

Using Agile to Secure the Future

Po reached Inner Peace by embracing the tragedy of his past and letting go. However, we have to remember the lessons we've learned throughout the story. Understanding our past makes us better prepared to embrace our future and win battles. Project cost accounting is a great model when running an organization that is aligned to cost centers. But by realigning cost centers to Value Streams, the burden of project cost accounting is lessened and planning processes can become more efficient. When aligning to the quintessential tenet of agile, trust, you, too, can achieve inner peace.

Topics: accounting scaled-agile roi program-increment lean-budgets project-management
5 min read

Project Cost Accounting in Agile | Part 1 of 3

By Amanda Babb on Mar 28, 2019 5:13:43 PM

First of Three

If you've read my other blog posts or watched one of my webinars, you should be familiar with my tendency to intertwine somewhat unrelated concepts together. I like doing this because it gets folks thinking: thinking about serious business and process things in a totally different context. This is the first of a three series blog. Today's topic: The secret ingredient is nothing.

pandaSecret Ingredient

In DreamWorks Animation Kung Fu Panda, Po states to his dad, Mr. Ping (a goose), that he doubts he is his son. Mr. Ping looks at Po very seriously and announces he has something to tell Po. Po, at his most vulnerable, and by proxy, the audience, expects the Big Reveal: Po the Panda is not the son of Mr. Ping the Goose. Instead, Mr. Ping reveals the Secret Ingredient in his Secret Ingredient Soup: nothing. This leads to Po's epiphany that he in fact is worthy, is the Dragon Warrior, and, with the Furious Five, can defeat Tai Lung. Po has had the ability all along and nothing can stop him if he believes in himself.

Project Cost Accounting

Most organizations work with what is called a Project Cost Accounting model. If an effort provides the most value to a specific cost center, the cost center is responsible for estimating costs as well as the length of time for the project. While other costs such as rent, infrastructure, licensing, etc., are factored in, the most expensive resource is the people. The Project Cost Accounting model respects capacity management and resource leveling. If we need to release something in six months (26 weeks) and it will take 26,000 hours: 26,000 hours at 40 hours per week for 26 weeks is 25 people. Multiply the hours by the average cost rate ($50/hour) and the effort will cost $1,300,000 plus "other costs" such as infrastructure and the like. The Project Manager asks for the funding from the specific cost center and the project moves to execution mode (moving the Teams to the work). In reference to Kung Fu Panda, Master Oogway states that Po shall be the Dragon Warrior much to the dismay of the Furious Five and Master Shifu. No effort to dissuade him shall be heard. Raise your hand if you've ever started or managed a project that has left you feeling slightly dazed, incredulous, or rather disheartened.

Iron Triangle of Project Management

So you embark on your quest...er...project. Master Shifu tries to train Po using the traditional methods that were successful for the Furious Five. This leads to hilarious confrontations between the two as little progress is made and Master Shifu resents his time spent with Po. Much like Master Shifu tries to fit Po (and the team) into his model, the Project Cost accounting model adheres to the Iron Triangle of Project Management as well as several other assumptions. The other assumptions include: skill set is equal across resource types, resources are fully dedicated to the project, resources are in place on day one of the project, and work starts day one of the project. We know this is not how it plays out in the real world. Skill sets differ based on experience or technology, resources are usually split between multiple efforts, hiring and onboarding processes delay resource start dates, and work will start on the first day, but not everyone will have work to start on the first day.

An Agile Team is Fixed

The fact remains the Project Cost Accounting model is flawed when managing agile development teams. The strength of the agile Team is their ability to self-organize and create a predictable Velocity. Even before Po joined the Furious Five, Tigress, Mantis, Crane, Viper, and Monkey became legends throughout the Valley of Peace by working well together. An Agile Team is fixed: the number of resources should not change. Project cost Accounting comes into direct conflict with agile planning: because my team of six people is fixed, I will only ever be able to get 240 hours out of the team per week (40 hours per person per week). If the project is estimated at 26,000 hours, it will take 108 weeks to complete and exceeding the release timeline by over a year and a half. While an agile Team removes the assumptions of equal skill sets, dedicated resources, day one start, and day one work start, the 6-month deadline is still real.

Agile Team Dynamics

Tai Lung is headed to the Valley of Peace and he will arrive within a specific timeframe. The Furious Five (plus Po as a noob) then head off to defeat Tai Lung before he reaches the Valley of Peace. As we know, the confrontation does not go well. The team slinks back to the Valley of Peace bruised, broken, and defeated in more than the physical. In-fighting, blame, distrust: there's a reason as adults we relate to kids' movies. In this moment, Po is "that guy". Po's mistakes put Tai Lung's defeat at risk and prolonged the timeline. It also impacted the entire Valley of Peace and allowed danger to further encroach on the innocent. Raise your hand if you've ever felt the same during the course of a project.

If only we had thrown an army at Tai Lung! We could have easily defeated him before he arrived in the Valley of Peace. This incorrect assumption based on Project Cost Accounting then destroys the trust of the PMO in the agile organization. The dynamic of the team as it comes together only by playing off each others' strengths and weaknesses and acting as a team.

Don’t Disrupt the Team

Once the Team is set, it should not be changed based on Resource Leveling or Project Cost Accounting. Instead, moving smaller pieces of work to the Team results in greater throughput. Prioritizing the smaller pieces of work correctly to fit a deadline is critical as well. Po's training was very disruptive to the Furious Five and Master Shifu's Inner Peace. However, once the Team organized and defeated Tai Lung, they were able to save Kung Fu in Kung Fu Panda 2 and expand the lessons learned by Po to a whole village of pandas in Kung Fu Panda 3. The same can be said of Agile Teams or Teams of Teams. Adding a person to a Team to a Train or adding a Train to a Solution Stream based on Project Cost Accounting will disrupt the predictable velocity of the Team or Train and will likely discourage them from innovating or taking risks. The same goes for removing a Team or Train. Adding resources as dictated in Project Cost Accounting will cause disruption and will not allow you to vanquish your enemies...er...complete your project any sooner.

More Secrets

The Secret to Project Cost Accounting in Agile is this - There is no secret. If you follow the concept of an Agile Team, Project Cost Accounting and ROI in an agile framework is simple. If Teams are fixed and Agile Release Trains are fixed, resource costs are fixed. SAFe embraces this within Lean Budgets. It simply requires the organization to completely change how project financials are planned and reported. Stay tuned for next week’s blog, part 2 of 3, where I’ll share more secrets of Project Cost Accounting in Agile. 

Topics: accounting scaled-agile roi project-management
5 min read

Top 5 Ways Jira Portfolio Increases ROI

By Praecipio Consulting on Oct 15, 2014 11:00:00 AM

Your organization is made up of many moving parts- from team members, to products, to stakeholders. Everyone has different project management needs, and the larger your organization, the greater the need for best practices in project management. Nobody knows project planning and tracking better than Atlassian, who continue to build industry-favorite SDLC tools like Jira and Confluence to enhance your team's collaboration and visibility. This year, they raised the bar even higher with the release of Jira Portfolio. You can track real-time adjustments to product releases and analyze use of resources in one central location to determine the best course of action every time for reliable delivery.  

At Praecipio Consulting we are excited to offer our Atlassian expert services around Jira Portfolio, bringing you this revolutionary product from licensing to implementation, configuration, and training. As businesses around the world begin to catch on to the robust planning power of Jira Portfolio, Praecipio Consulting helps you get the maximum return on your SaaS investment. So, how does Jira Portfolio increase your ROI? Here are just a few ways...


5. INITIALIZE YOUR INITIATIVES

Seasoned users of Jira know about using the epic designation in Jira Agile to collect user stories from multiple tasks under a larger project heading, but now you can expand your business narrative with initiatives! An initiative aligns epics and corresponding user stories to link together all the moving pieces of your business processes. Unfamiliar with Agile practices? Use Initiatives to give each team a vision for their part of the story- whether you're the one developing the product or the one marketing it. Each team's actions in Jira track back to Jira Portfolio under the larger initiative plan to give PM's and stakeholders an accurate overview of how the initiative is developing to ensure an on-time delivery. Get all your resources from all involved teams on the exact same page with initiative-setting capabilities in Jira Portfolio.

Before Jira Portfolio: Countless cross-team meetings to convey initiative vision and goals

After Jira Portfolio: Epics and stories streamlined by initiative to keep your teams aligned under the same vision and goals

 

4. THE RIGHT PERSON FOR THE RIGHT JOB

Who has time to work on the project? Who has the required skills? Finding answers to these questions used to take significant time- time that could be spent moving ahead on your project- that is, until Jira Portfolio. Now it's easy to search resources by availability and skill set to assign the right person to the right job. Never again have to guess whether your assigned developer has UI/UX experience- just check Jira Portfolio and see! Not only can you find the perfect person for the task by filtering searches for specific skills, but you can view their availability to determine if they have the bandwidth for your project. If only online dating were this easy!

Before Jira Portfolio: Mismatched assignees who may (or may not) have the skills needed to finish the job right, and on time

After Jira Portfolio: Find the perfect fit for the job by viewing resources' skills and availability 

 

3. EASY ESTIMATION

So, you've found your Mr. Perfect Developer or Mrs. Right Marketing Resource. How much time will it take these team members to complete their assignments? With Jira Portfolio, your resources gain the ability to project the time they need to get the job done. By documenting these estimates in Jira Portfolio, PM's get a percentage breakdown across teams and users for the most accurate, up-to-date forecast of your project timeline. User friendly charts and percentages automatically generate based on the estimated time required, showing you the workload make-up of your project. And, with report export capabilities, the only thing PM's have to do is press print and hand over the beautifully accurate and informative analysis to project stakeholders for easy and always available project tracking. 

Before Jira Portfolio: Imbalance of time allocation per development phases; Searching multiple locations for data then keeping fingers crossed in hopes that the search provides an accurate forecast to stakeholders

After Jira Portfolio: Each phase gets the time it needs; One central location with reporting options that allows you to see your progress in a single glance 

 

2. SCRUM AND KANBAN- YOU GET BOTH!

Your methodology is personal to your organization. Often, teams within the same company, teams operate using different processes. Jira Portfolio meets the process needs of every team with options for Scrum and Kanban. Using Jira Portfolio's iteration-based scrum scheduling abilities, your project moves through a workflow based on completion of one to several week-long iterations. Need continuous scheduling ability? Jira Portfolio has you covered with the Kanban-style scheduling that organizes the stages of your workflow to align with a traditional process workflow, moving to the next step once the previous one has been completed and closed out. Jira Portfolio provides a project planning tool to fit any process methodology in your organization.

Before Jira Portfolio: Different methodologies requiring different software for different teams, preventing cross-team collaboration and centralized reporting for PM's

After Jira Portfolio: One SaaS to rule them all! Any methodology, or even multiple methodologies in the same organization, achieve the same traceability and process maximization

 

 

1. LET'S GET REAL

Perhaps the most exciting feature of Jira Portfolio (but really, how can we pick just one?) is the ability for real-time planning and forecasting. While this is nothing new for Atlassian users, Jira Portfolio takes it one step further, allowing administrators to project timelines based on resources, dependancies and completion of iterations. Need to spend more time in testing before release? Update your date fields, and the project tracking timeline adjusts to re-schedule your release date accordingly. How much time could you gain by adding an additional resource to a phase? No need to guess- just add the resource and Jira Portfolio shows you, based on the resource's availability and role, the new timeline to reflect the extra team member's projected contribution. Those who love to ask "What if?" Jira Portfolio allows you to explore different scenarios to determine your best course of action before making the call. 

Before Jira Portfolio: Guessing at deadlines and making partially informed decisions 

After Jira Portfolio: Real-time forecasting of scenarios to get your best course of action every time

Atlassian's new Jira Portfolio bring robust, flexible, dynamic scheduling capabilities to your organization for best project management practices. This exciting Jira add-on delivers big results, streamlining your organization's numerous projects for supreme visibility and providing thorough, accurate reporting. Masters of best technology and business practices, Praecipio Consulting is here to bring Jira Portfolio to your organization! A one-stop shop for all things Atlassian, we provide implementation, configuration, process consulting, training and anything else you need to get your organization using Jira Portfolio with best-in-breed practices. 

Ready to learn more about Jira Portfolio and how it revolutionizes business practices? Join us on November 5th for our Introduction to Jira Portfolio webinar, which includes a live demonstration of the application and a Q&A opportunity with Praecipio Consulting's Atlassian Expert Consultant, Amanda Babb. Contact us to learn how Jira Portfolio can maximize your project planning and how Praecipio Consulting sets you up for your greatest success.

All images courtesy of "Dilbert" by Scott Adams

Topics: blog best-practices optimization process-consulting training consulting-services portfolio-management project-management marketplace-apps

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-enterprise

In need of professional assistance?

WE'VE GOT YOUR BACK

Contact Us