3 min read

What is Jira Align: A Primer

By Amanda Babb on Jun 30, 2021 4:45:59 PM

Blogpost-DisplayImage-June_What is Jira Align- A PrimerA couple of years ago, in Atlassian's annual flagship event formerly known as Summit and now known as Team, I was in a room full of people for two days providing training on Advanced Roadmaps for Jira on behalf of Atlassian. If you've never attended a live Summit event, the Kickoff Keynote is always a sight to see. One year, Scott and Mike dressed as Daft Punk and mixed music as DJ Kanban (I still nerd out on that one), you see announcements about the expansion of Pledge 1%, and, of course, new product announcements. Jira Align was acquired by Atlassian and announced at Summit 2019. I. Was. Floored. You see, we here at Praecipio Consulting were looking for a larger agile-at-scale solution for some of our largest clients. 

Enter Jira Align

After becoming a SAFe® Program Consultant (SPC) in 2015, I spent a lot of time with clients understanding intake and execution processes and facilitating them through the Atlassian product suite. These clients were either just starting their SAFe® journey or had been the earliest adopters and already implementing SAFe®. After implementing Advanced Roadmaps (then known as Portfolio for Jira) to support SAFe®, becoming the Atlassian University On Demand "voice" of Planning with Advanced Roadmaps, and guiding the course content with Atlassian, I was in love with Advanced Roadmaps. And I still am. Advanced Roadmaps is a powerful data aggregation, roadmap, and scenario planning tool for small- to medium-size organizations either as standalone entities or within an Enterprise organization.

Jira Align, however, brought forth a whole new realm of possibilities. Bringing robust framework expertise and combining it with an easy-to-use interface, Jira Align is THE solution for Enterprise organizations running agile-at-scale. Don't believe me? Atlassian is considered a Leader in the Gartner Enterprise Agile Planning Tools Magic Quadrant as of April 2021. Experience and third-party accolades aside, why is Jira Align so amazing? Let's take a closer look. 

Jira Software Integration

Unlike Advanced Roadmaps, Jira Align is a standalone product hosted either in multi-tenant or single-tenant cloud infrastructure. While there is an on-prem solution, of course, there are a lot of additional considerations if you have to choose this deployment. The connection between Jira Align and Jira Software supports both Data Center and Atlassian Cloud instances. The most critical part of the integration is the Jira Software Epic. Epics can be created in Jira Align and pushed to Jira Software or created in Jira Software and pulled into Jira Align. Keep in mind, when creating the integration, best practice is to isolate Epics into their own Jira project. Bringing in Stories and Sprints is also easier if a Jira project represents a single team. 

Rooms at Every Level

Whether you're just starting out with a single Agile Release Train (ART) or are running multiple ARTs, Jira Align provides the Program Room for each ART. This is the central hub for tracking the current Program Increment (PI) and planning the next one. Sprint Progress, investment runway, intra-ART and inter-ART dependencies, PI Burndown, it's all centralized within the Program Room. This provides Business Owners, RTEs, and Program Managers a clear view of the progress of the work in the PI. 

Jira Align also provides the Portfolio Room and Strategy Room. These rooms provide the progress towards Strategic Themes, Portfolio investments, progress toward long-term goals, and status updates. When properly connected to Epics in the Program room, Teams and ARTs can open the "Why?" tab on the Epic and see how their work is contributing to the overall strategy. 

Everyone's Favorite: Reporting

Jira Align has over 180 out-of-the-box reports. Each layer in Jira Align has a Track section pre-populated with the more popular reports for that section. For example, in the Program section, Jira Align provides Program Increment tracking, Program Increment insights, and Dependency Maps. If you're not sure what type of report you're looking for, simply click the Reports menu and ask a question in the search box. 

For those organizations that need to integrate with other systems or need more robust business intelligence, Enterprise Insights can be added to Jira Align. 

Want to know more? We here at Praecipio Consulting would love to walk you through how Jira Align can support your agile-at-scale transformation. Contact us!

Topics: atlassian blog scaled-agile integration reporting jira-align safe advanced-roadmap
7 min read

SaaS can be SAFe®

By Christopher Pepe on Dec 11, 2020 2:30:00 PM

Blogpost-display-image_SaaS can be SAFe Blog

SaaS is the future

2020 has caused the world to work from the internet. Whatever you used to do in your own data centers can now be performed by vendors, be they cloud or software service providers, better, faster, more securely, and at less cost than you.

The diagram below indicates the trajectory of change from traditional to SaaS (software as a service). Learning how to manage SaaS providers is the new skill that must be learned and introduced into your strategy.

Screen Shot 2020-12-05 at 10.03.18 AM

The hardships of this year have also proven that you need agility in your 5 year plan so that you can change along the way.  The capability to pivot based on circumstances is the other new capability of an organization moving towards a digital and VUCA (Volatility, Uncertainty, Complexity, Ambiguity) future. You have to be agile, not just in IT, but the way you think, act, and react. Leadership has to manage and accelerate this change in culture and behavior, which means scaling new ways of working enabled by technology is the new management paradigm.

Allowing a SaaS provider to manage a core function such as Marketing, HR, or Sales is the norm, freeing you to concentrate on creating unique services that benefit your customers and save time for your staff. 

Scaled Agile Framework SAFe®

No matter what blend of Agile that you are using (Scrum, Kanban, DevOps, AgileITSM, XP, TDD, BDD, etc.), you will need to spread these practices across your business. New ways of working, constant improvement, collaboration, and the elimination of siloes, benefitting from technology, be it your own or others, is the only way to survive. 

Accomplishing this change means a dramatic, and in some cases, drastic, alteration to how things are currently performed:

  • You keep your program office but lose your project mentality
  • Product and Service Owners are the new organizational role with accountable budgets and teams
  • Agile Budgeting replaces annual budgets, and the same occurs to annual reviews as constant and consistent feedback is provided top-down
  • Multi-year contracts are swapped for partners that facilitate your agility
  • The use of technology to keep you in business enables every aspect of your business
  • Staff are not made redundant but instead acquire t-shaped skills
  • Customer focus and shifting left from their request or needs drives your product strategy

Organizations need guidance to make these types of change successfully. Enter Scaled Agile Framework (SAFe®).  The diagram on their website visualizes the breadth of their philosophy and impact on an organization. 

SAFe® is a continually changing set of practices that has blended the technology, people, and business practices into a competency-based model: 

  • Leadership based on agile and lean: empowerment, self-organization
  • Team and Technical Agility: No defects, use of cloud & internet, open-source, SaaS
  • Behavior-Driven Development (BDD): products based on the people use them
  • Test-Driven Development: code, infrastructure, people feedback in short cycles
  • Agile Product Delivery: small changes made often, usually daily
  • Lean Portfolio Management: if it is not helping someone, then you don’t do it, constant improvement, reduced technical and cultural debt
  • Lean Governance: common or standard data models, budgets are based on the value of outcomes and funded accordingly, guardrails guidelines both corporate and regulatory, business continuity and sustainability is a daily way of acting 
  • Organizational Agility: long-term goals but very short-cycle plans capable of pivoting based on breaching a KPI or OKR (Outcome based vital indicators)
  • Continuous Learning Culture: effort is rewarded, management changes to a coaching model from a telling model, relentless improvement is mentored, innovation is the goal

SAFe® is the most ambitious version of this framework's scaling technology, leadership, financial, and organizational practices. It supplies examples, training, templates, and a worldwide community of practitioners. It is not for everyone. It is not a program of introducing Safe® that will make it successful for you but instead a multi-year effort of scaling the way your business does things at every level into a new model. 

SAFe® helps you avoid and overcome these engrained practices:

  • Budgets by department or project become funding for products and services
  • Prioritization of new features or services is based on value of delivery and cost of delay
  • Creating your own software is replaced by using open source or SaaS
  • Data used and kept by your business is standardized for ease of maintenance and change to new services as needed
  • Mapping the way you work end-to-end and ensuring any changes are not localized but instead improve the flow of work and data is the new program office structure.
  • Change Approval Boards or freezes are stopped because you trust the testing and release process that has been enhanced and automated. 
  • Design thinking is encouraged to solve problems
  • Design thinking underpins making things as small and as standard as possible such that any part of your business can use it or improve it
  • Everyone is thinking about what can I do to make things better, do things faster and safer, and how can I save effort or time or money

SAFe® Benefits

  • Increase the velocity of change: ways people work and the software that supports these changes
  • The software lifecycle of Demand-Approve-Develop-Integrate with other code-Unit Test-Performance Test-Submit to Live Approval-Go live is replaced with Experiment-Develop-Test-Go live
  • SaaS + Cloud + Digital is the technology trilogy whereby owning your own technology is discouraged (still allowed where regulatory mandates leave no other option)
  • Complex projects requiring months or effort are replaced by an understanding of what a new service or feature or technical update will provide a customer or staff member and therefore, this is what is created and deployed
  • Technical stability is more critical than new service introductions (think of your customers and how angry they get when things go wrong)
  • Feedback, monitoring, alerting are the trilogy of information collaboration and coordination (no silos)
  • Legacy infrastructure or technical debt is mitigated by using cloud services aligned with your work and customer practices. Technology underpins the way you do things and not just there because!
  • Training on SAFe® culture and practices is top-down and extends to your external suppliers
  • Project Management is now Agile Product Management, coordinated across products and services instead of merely helping a department or team
  • Prioritization based on what it fixes, how it meets a regulatory demand, what outcomes it being in terms of value and customer satisfaction, or how it helps staff perform a function

Doing SAFe® means:

  • You are willing to release small chunks of change daily versus large pieces that might wait months before going live
  • You can monitor the impact of that change in terms of issued caused or customer satisfaction
  • If an issue ensues or satisfaction is not as expected, then you can easily roll-back the change with minimal effort or impact (go back to the way things were before)
  • New skills of negotiating or always thinking of enhancing products via technology are taught in a variety of formats such as hackathons, formal training, a partner working, and management coaching
  • Operating and Strategy long-term plans are replaced by short-term vision plans that are customer and market-centric
  • Centers of Excellence or Software Factories are created aligning how people working based on data and technology mapping exercises with the approved practices of the organization, which encourages:
    • Standard tooling for Enterprise Application/Service Lifecycle Management 
    • Standard data and artifact repositories
    • Use of SaaS providers for core activities
    • Always on testing, monitoring, and alerting across the value chains

A train yard is a frequent analogy to explain software factories and centers of excellence. You need a standard gauge rail for all trains to use, and an aligned place for trains to be monitored and dispatched. This allows trains to move safely across the landscape, delivering people to their locations. Your organization needs to establish the same kind of software delivery practice. This model is what SAFe® uses to foster the fast and safe distribution of technology via an engineered flow of work.

SaaS Safe® tips

  • Create a vision of why SaaS and Safe® are being adopted, underpinned by training
  • Change the language used top-down from project to product
  • Have metrics that make innovation for customers or staff the prime target
  • Developers develop and operations keep things up is the most prominent IT silo. Break this by making product teams that own their product or service.
  • Technology metrics of Defect Rejected Ratio, Detected Defects, Change Time compared to Market release, Value of Delivery versus Effort are viewed on product boards
  • Create fun programs of change such as Kill the CAB, which force the introduction of standard technology components for use by any aspect of the business
  • DevSecOps is not an option but a mandatory requirement: you have to test at every opportunity and use security practices and tools to keep your business safe and compliant
  • Automate what you can as often as you can, but only if this improves the quality and speed of work

SaaS is the way of allowing someone else to perform a function via the use of their technology. Carefully avoiding vendor lock-in will make SaaS a credible option for your business. The transition to remote working has opened up a world linked by technology, and your organization needs to do the same by scaling the thinking and practices of technology to everything you do. SAFe® is a framework proving your business a set of rules that promotes scaling Agile, Lean, and DevOps across your organization. It is a radical alteration of your culture that will take time and leadership to embed successfully.

Whether implementing SaaS, SAFe® , or just generally digitally transforming your company, Praecipio Consulting can help!

Note: SAFe® is a Registered Trademark via ©Scaled Agile, Inc.

Topics: scaled-agile saas safe agile
6 min read

Using Advanced Roadmaps for Jira

By Amanda Babb on Oct 15, 2020 12:15:00 PM

Blogpost-display-image_Scaling Agile copy

As an Agile evangelist and a Digital Transformation-ist, I am asked this question from time to time. My first thought is, "Of course you're Agile...you just don't know it yet," but before I can actually answer that question, I have to understand the process. Every organization and agency in the world takes something, does something with it, and produces an end result. It's the process that is key for you and your organization to understand before implementing the Atlassian tools and specifically, Advanced Roadmaps for Jira (formerly known as Portfolio for Jira). 

At Praecipio Consulting, we call ourselves a bunch of process nerds that just happen to use the Atlassian tools to facilitate work. Think about making a pot of coffee: there are specific steps you have to take in a specific order to be successful. Starting the coffee pot before adding water and coffee doesn't work. Adding water and starting the coffee pot (without coffee) doesn't work either. There's a specific process that you need to follow to produce a pot of coffee. 

When it comes to work, what's the first step? How does the organization take in work? For those running traditional models, you may know this as Requirements. We have an idea that we'd like to propose, gather the requirements, and define the project scope. We then move to Design: expected function and architecture, and then to Implementation: actually putting the requirements into place in a product. In each of those phases, Advanced Roadmaps for Jira can help! 

What is Advanced Roadmaps for Jira? 

Advanced Roadmaps for Jira is a planning and roadmapping tool from Atlassian. It was first released in 2015 and has since developed into a powerful visualization tool for small-to-medium-sized organizations. With Atlassian's dedication to maintaining framework flexibility, it has evolved to become the tool of choice for many organizations, regardless of their self-proclamation. By supporting three estimation statistics (Days, Hours, and Story Points), Advanced Roadmaps for Jira can provide you with the best chance of success for understanding cross-team and organizational dependencies and answering the most important question, "When will this be done?" Purpose-built for Jira Software, Advanced Roadmaps for Jira supports mixed methodologies as well as framework-specific organizations. Add in the concept of multi-layer hierarchies, and you've got yourself a Work Breakdown Structure (WBS) as well as the ability to automatically schedule timelines based on Team capacity or velocity. 

Advanced Roadmaps for Jira adheres to the concept of the Iron Triangle. What is the scope? What is the timeline? Who are the resources (people) involved? Based on the estimated scope of work, the timeline in which I need to get it done by, and the people I have to do it with, will it be available on time? Simply choose the estimation statistic to calculate a schedule and you're off! Well, almost...

Scope: Where is the work being tracked in Jira? 

When creating a Plan in Advanced Roadmaps for Jira, the first thing to understand is the source. After establishing your hierarchy, determine where these Jira Issues exist. Where is work being performed in Jira? Is it in a specific Jira Project? Or perhaps a Kanban board for process visualization? Or across multiple projects? These are the sources for creating a Plan. You can use Jira Projects, Boards, or Filters as the source for a Plan. You can also use any combination thereof. However, aim for simplicity: use a Jira Project or a Board when you are able to instead of a complicated Filter as a source. 

We recommend using Filters as a source only when you need to manage stage-gates in your process. Using the example above, If the Statuses in your Jira Workflow are Requirements, Design, and Implementation, consider creating a filter that excludes Requirements. Just because it's a good idea, doesn't mean we will pursue it past the Requirements stage. In a Plan, we only want to see those things that made it through the stage-gate into Design. It's in the Design stage we will determine if or when we can get it done based on the timeline and people before moving into Implementation. We are not ready to Plan an effort until we've passed Requirements. 

Resources (Teams and Team Members): Who is doing the work in Jira?

While it's a bit chicken-egg, determining who is doing the work is critical to determining scope. In a Plan, we connect Teams and Team Members to the Sources in the Plan. This eliminates the need for clicking or typing or trying to assign a piece of work to the correct Team in a Plan. By connecting these, Advanced Roadmaps for Jira will determine the scope for the Teams and Team Members based on the source of the Plan. You also have the ability to tie multiple Teams to a single source. As an example, if you have two Teams managing their work in a single Jira Project, you can use the Project as a source for both Teams. By adding Team Members to the Teams, you can guarantee assigned work will be directed to the correct Team. However, unassigned work will be divvied up based on the next Team Member's availability. We recommend creating a single source per Team if both Teams cannot be assigned each others' work. 

Moreover, by adding Team Members to your Teams, you can determine the hourly capacity of each member. We see this most frequently used when specific job functions are split across Teams (e.g. QA or Design). By default, Advanced Roadmaps for Jira calculates 100% capacity at 40 hours per Team Member. If you need to split capacity across Teams, simply adjust the Team Member's capacity to 20 hours (50%) on one Team and 20 hours (50%) on the other Team. By using the Auto Schedule function in a Plan, you can then recalculate the timeline based on the change in capacity. 

Time: When will it be done?

This is where the power of Advanced Roadmaps for Jira truly shines. By using Releases (aka Versions), the Plan can calculate your probability of completing the effort on time. The Plan can also calculate when an effort will be complete based on Scope and Teams. For example, if I estimate my effort will take 4000 hours and the Team has a capacity of 200 hours, it will take 20 weeks to complete the effort. If my Release finish date is in 10 weeks, I will be off track by 10 weeks. The Plan will highlight this in red. 

Don't think of Releases as traditional "software releases". Instead, these are milestone dates for a specific Jira Project or across multiple Jira Projects. They can be calendar quarters, fiscal quarters, or even a specific date-driven event. By designating the Finish Date of a Release, you are determining the amount of time the organization has to complete a specific (or the entire) scope of work. 

Dependencies and Scenarios

Critical Path is a common concept in a traditional WBS. These larger milestone issues drive the entire schedule. If one moves, the rest move as well. In Advanced Roadmaps for Jira, we can manage this via Dependencies. By linking issues together, the Plan will schedule work using a finish-to-start dependency. Issue 1 must be complete before Issue 2 can start. Moreover, since items at the lower levels of the WBS drive the size and duration of the critical path, you can visualize a schedule slip based on the progress of the lower levels. 

Not sure you're ready to commit to a specific Plan? When trying to understand the "What if?" in each Plan, you can enable Scenarios. The Initial Scenario (default name) is used to understand current state: what the are Teams currently working on, the progress, schedule, and release dates. Creating additional Scenarios allows you to Plan for best-case or worst-case scenarios. What happens if I add capacity to the current scope of work? Will I be more likely to hit my Release (aka milestone) dates? By adding a Team to a Scenario (thus increasing capacity), you can Auto Schedule just that Scenario to determine if there is any impact to the overall schedule and any milestone dates. If you like what you see, you can update Jira Software from that specific Scenario and any other Scenarios will update based on the underlying Jira data. 

Want to know more? 

As an Atlassian Platinum Enterprise Solution Partner, Praecipio Consulting can help you determine the best way to leverage Advanced Roadmaps for Jira to support your intake, planning, and execution processes so that your organization can become more Agile. We have extensive experience in the entire Atlassian product suite and implementing Agile frameworks that provide a great foundation for your organization or agency. 

Topics: scaled-agile homepages agile advanced-roadmap
2 min read

How to Know If Your Organization Is Ready to Scale Agile: Tips & Best Practices

By Amanda Babb on Sep 28, 2020 12:15:00 PM

How to know if your organization is ready to scale Agile

Are You Ready to Scale Agile? 

You are an Agile evangelist. You have championed the shift to Agile at your organization and have coached several teams successfully. Your organization is delivering quality product faster to your internal and external customers. But there's still a struggle to coordinate across different parts of the organization. And you get pulled into meeting after meeting to coordinate across teams. As a result, your most successful teams are expressing frustration with each other and, and now, quality has slipped. Something has to change. 

You've heard about scaling Agile. You may even have an idea of some of the well-known frameworks, such as SAFe, LeSS, Scrum@Scale, etc. But are you ready? Is your organization ready to scale Agile? 

Organizational Readiness

While this is not an exhaustive list, ask yourself and your organization these questions to assess your readiness to scale Agile. 

  • Which framework is best for your organization?
  • Do you have management and executive buy-in? 
  • Do you have funding for external training and certification?
  • Can you group teams together to support strategic initiatives?
  • Can you identify your change agents and champions?
  • Can you identify a set of teams to pilot the change?
  • How much time are you willing to commit to the change?
  • How much time do you have to commit to the change? 
  • How much time are you willing to commit to continuous learning? 

Iterate Your Framework Implementation

Just like the scaled Agile frameworks themselves, you approach their implementation iteratively. One of our clients chose and implemented SAFe for a single program and scaled iteratively. They started with one Agile Release Train and in three years scaled to four Agile Release Trains with the intention to launch an additional train before the end of the year. They also reorganized the Trains once they realized they were no longer organized around value and instead were structured in a traditional resource-management way. 

The implementation of SAFe within this client's organization, while it had a specific start date, was implemented iteratively and over time. It also took the backing of management and executives and a devoted set of change agents willing to take the steps for scale.

We here at Praecipio Consulting have assisted our clients in their journeys to scale Agile. Let us know how we can help you take your first step. 

Topics: blog scaled-agile best-practices tips safe agile
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
5 min read

Jira Align vs. Advanced Roadmaps: The Difference

By Amanda Babb on Sep 15, 2020 8:15:00 AM

How Jira Align compares to Advanced Road for Jira

As organizations continue to scale Agile practices, our team at Praecipio Consulting is frequently asked which Atlassian product will best support the effort. Principal Consultant, Brian Nye, put together a great webinar describing the differences between Advanced Roadmaps for Jira (formerly known as Portfolio for Jira) and Jira Align. As Praecipio Consulting has expanded our Jira Align practice, we'd like to take a moment to compare and contrast these products to help guide you in making the right decision for your organization. 

Your Agile and Digital Transformation Journey

Your organization can't talk about your Agile transformation without talking about your digital transformation and vice versa. After all, the Atlassian products are meant to support Agile frameworks as well as your digital transformation. Many organizations have embraced remote work as a result of the global pandemic and have fundamentally shifted toward online planning, roadmapping, and execution management. 

Your organization may also use non-Atlassian applications to manage planning and roadmapping. You've chosen to integrate these products with Atlassian for execution management. While this may be a great solution in the short-term, I challenge this as a long-term solution. Many of the frameworks guiding agile-at-scale exist because we're trying to bring strategic planning closer to actual execution and back again. Ask your organization the hard question: does maintaining these integrations follow the organization's digital technology vision for the future? 

Advanced Roadmaps for Jira (formerly Portfolio for Jira)

Available as an App for Data Center/Server Deployments and packaged with Jira Software Cloud Premium, Advanced Roadmaps for Jira (Advanced Roadmaps) is a great way to bridge the gap for small- to medium-sized organizations. If you currently have fewer than 500 agile team members executing their work in Jira Software, Advanced Roadmaps for Jira can provide visibility within and across teams. First, define the hierarchy above the Jira Software Epic. We use Initiative most frequently when deploying this for customers because of the reference documentation from Atlassian. However, you can choose whichever naming convention you'd like as long as there is a corresponding Issue Type. For example, create an "Initiative" Issue Type and link it to a Hierarchy level in Advanced Roadmaps called "Initiative." We also strongly recommend the Initiative Issue Type live in a separate Jira Project from all other execution work. This helps your Agile teams focus on the current backlog of work while the Initiative moves through its own review, decision, and backlog refinement process. 

Creating a Plan is as simple as defining your source data (Jira Projects, Boards, or Filters), tying the sources to Teams, and choosing Releases from your source data. Honoring the Iron Triangle of project and program management, you may either choose to have the Plan dictate your schedule or, when planning for the next business quarter, you may choose to drag and drop the Gantt-style bars to schedule work. There is also an option to blend the calculations. Meaning, if a Sprint already exists and is pre-filled, let the Scrum Board be the source of truth. Have the Plan calculate any Empty Sprints going forward. The same is true for Releases and Teams: the Plan can auto-schedule a Team or a Release based on the relative rank of the backlog in the Plan. 

If you're looking to understand the impact of shifting priorities, you can enable Scenarios in a Plan. This will allow you to pull the source data from Jira Software and blend it with additional planning while maintaining the current execution schedule. You can add new Initiatives, Epics, and Stories, as well as adjust Release Dates, and observe the impact of adding, removing, or reassigning Teams to work. If you have the Server or Data Center App, you can group Plans together into a Program to understand the overall health of multiple Plans and Releases in a single view. 

Jira Align

As its name implies, Jira Align brings strategic planning and execution together in a single product. Pulling execution data from Jira Software and blending it with Agile-at-scale frameworks, Jira Align ties your strategic vision to tangible work and is best suited for organizations with more than 500 Agile team members executing their work in Jira Software. Instead of trying to define a hierarchy, Jira Align provides a pre-set hierarchy with flexible language. Whether you're running SAFe, LeSS, Scrum@Scale, or your own model, Jira Align's seamless integration with Jira Software provides visibility across multiple Portfolios and Programs. 

Jira Align comes in three deployment options: multi-tenant Cloud, single-tenant Cloud, and on-premise. While we recognize the allure of an on-premise solution, Praecipio Consulting recommends either the multi-tenant or single-tenant Cloud deployment. This provides the robust functionality of the product without the additional IT infrastructure management as well as managing routine maintenance such as upgrades. Jira Align also comes in two licensing models, Standard and Enterprise, billed monthly per user. Standard provides your organization the ability to run Programs (also known as teams of teams) whereas Enterprise adds the Lean Portfolio Management and financials into the mix. In addition, each Jira Align seat comes with four Jira, Trello, or integrated users. Another key difference between the two license levels is integration. With Standard, you can integrate a single instance of Jira Software with Jira Align. This is perfect for the organization that is large enough but lacks maturity in their Agile-at-scale framework. Enterprise provides unlimited connectors, which in the case of some of our clients, allows them to avoid the pain of merging multiple instances of Jira Software before deploying Jira Align

The Jira Software Epic is the lynchpin of the integration. Teams will still work with Epics, Stories, and Sub-Tasks within Jira Software whereas Product Managers, Release Train Engineers, Portfolio Managers, and Executives work within Jira Align. The robust permissions within Jira Align also focus the right role in the right data. A Program Manager may care about the execution of the program, whereas the executive wants to understand how you're tracking to the annual corporate strategy. By aggregating and rolling data upward, Jira Align provides health and status monitoring of quarterly, yearly, and long-term goals. With over 180 out-of-the box reports, every role at every level can access the right information at the right time to ensure your organization's success. Jira Align also has Enterprise Insights, an optional App, to take business intelligence to the next level. 

Which one is right for my organization? 

The first questions to answer while you're evaluating either tool are around Agile transformation maturity, digital transformation maturity, and user discipline both across and vertically in the organization. Because both options rely on teams to perform their execution work consistently and with good data integrity, either product can be a blessing or a curse. 

  • How long have your Agile teams been executing within an agile framework? 
  • How long have your Agile teams been executing within Jira Software? 
  • How consistent are your teams across the organization? 
  • Do your teams and your business understand one another and communicate well? 
  • How well has your Jira Software instance been governed since it was deployed?
  • How much chaff do you have in Jira Software? 

While this is not an exhaustive list, implementing either Advanced Roadmaps for Jira or Jira Align requires you to ask tough questions of your organization. Praecipio Consulting can not only help you assess your current state, but we can also provide guidance and recommendations to accelerate your digital transformation. If you are ready to take the next step in your digital transformation and Agile journeys, let's chat!

Topics: scaled-agile jira-align agile advanced-roadmap marketplace-apps
3 min read

Agile 101: Why Jira Won't Make You Agile

By Morgan Folsom on Sep 2, 2020 12:15:00 PM

Why Atlassian tools won't make your organization Agile

It's no secret that here at Praecipio Consulting, we love Atlassianwe love Agile, and we especially love using Atlassian tools to Agile ends. The Atlassian suite (Jira, in particular) has been built to reinforce a lot of the concepts that are core to functioning in an Agile way, which is one of the many reasons that 83% of the Fortune 500 use it. So, setting up Jira is often one of the first steps companies take when they want to adopt the Agile framework. 

However (and this is a big one!), Jira, or any other tool, should absolutely not be the first step in your Agile transformation. 

Here's why:

Tools Won't Change Mindsets

If you've ever happened upon the Agile Manifesto, then you might guess where I'm going here. The very first line of the Agile Manifesto reads:

"Individuals and Interactions OVER Processes and Tools"

Agile is not something that you "do" to an organization by giving your developers Jira and having daily status updates that you call stand-ups. Rather, an Agile transformation is the process of rethinking how you deliver value to your customers from the ground up. It might sound like a big undertaking, and that's because it is! There's a good reason that "transformation" is the word we use to describe this process (I could insert a cheesy metaphor about butterflies, chrysalis, etc., but I think you get the idea). Now, while part of successfully running an organization means identifying tools that help your employees do their jobs well, the function of your process and tools is to support the individuals and interactions. 

Sure, we can use Jira to enforce some good Agile practices, but if teams don't know what the practices are or care why they're doing it, you won't get the same value out of them. The tools should be enforcing values that have been established, keeping teams from veering too off-path, but they are simply not an effective way of establishing values in the first place. 

Jira's not broken, you're just not Agile

While Jira can be customized to do almost anything you want, there are some structures in place that enforce Agile best practices. There are small things that work perfectly if your teams are well-aligned to best practices, but are huge headaches if you've got bad practices.

The most common example of this that I see is the struggle to manage sub-tasks in Sprints. Many teams use Sub-tasks to break down stories and bugs into smaller pieces of work. However, Jira will not allow you to close a Sprint if you've got stories with open sub-tasks. From a process perspective, this makes sense - your story isn't done until all of the work is done, which means you don't get credit for a story until it, and all of the work beneath it, are Done. Teams fight against this, wanting partial credit for the story that's not been completed. Ultimately, the problem here is not Jira - Jira is enforcing a good practice. The problem is the underlying process - maybe the team hasn't had the discussions about the Definition of Done, or they are getting pressure from above to complete a certain number of story points in a Sprint, or QA is not part of the team, so they're hitting bottlenecks along the way, etc. 

Examples like this come up often. Jira will enforce some fundamentals, and your failure to meet those minimum lines can make it look like the tool doesn't work for you. We can see another example in this hotly-debated blog titled Jira is an antipattern. This article posits that the use of Jira is a good sign that an organization's off-track, and while we explicitly disagree with the thesis, it highlights effectively why Jira cannot be the driver. Trying to use a tool to drive your Agile transformation can easily make it look like the tool is the problem, obscuring the underlying changes that need to be made. 

Ultimately, Jira is a great tool for supporting those Individuals and Interactions the Agile Manifesto highlights, but it is essential to remember that's just what it is: support. Trying to use Jira to drive your Agile transformations sets your teams up for failure if you're applying those rules and structures before even explaining what their purpose. 

When we say we love Agile, we mean it. If you'd like some guidance in your journey to Agile transformation and how to properly set your teams up for success with Jira, get in touch with the Praecipio Consulting team

Topics: jira blog scaled-agile jira-software agile
5 min read

Common Agile Myths: Everything's Made Up and the Points Don't Matter

By Amanda Babb on Aug 14, 2020 4:00:00 PM

2020 Blogposts_Everythings Made Up and the Points Dont Matter- Common Agile Myths

Type "Agile myths" in your favorite search engine and you'll be amazed at the plethora of results. Especially those that say, "Top myths busted!" While I consider myself an Agile evangelist, I'd like to take a moment to discuss the harsh reality that many organizations face day-to-day. Agile is not a new concept, but the term is. The Agile Manifesto codified the term and working agreements in 2001, but I (and other evangelists) argue that it existed way before the term was formalized then attached strictly to software development. 

Iterative Development of Complex Systems

"I felt exactly how you would feel if you were getting ready to launch and knew you were sitting on top of 2 million parts — all built by the lowest bidder on a government contract." - attributed to astronaut and U.S. Senator John Glenn 

There were three Apollo missions before a person was ever placed in a rocket to (eventually) go to the moon. February through August of 1966 saw rocket, heat shield, and in-orbit fuel performance tests before a person set foot in the capsules. After the tragedy of Apollo 1, three more unmanned missions were flown before NASA decided to try again. It took an additional four Apollo missions before Apollo 11, and the iconic first step happened in 1969. That giant leap didn't happen with Big Up Front Requirements. It happened with teams of teams working together, iterating, retrospecting, and making adjustments. Isn't that Agile and moreover Agile at scale? 

How many other times in history did we as humans nail something the first time? The Wright Brothers didn't just magically produce an airplane that sustained controlled flight in 1903. Carl Faberge didn't create imperial eggs immediately upon his return to St. Petersburg in 1872. It's not called WD-1, it's called WD-40. Agile is how we've developed some of our greatest inventions, art, and human achievements. 

Scrum versus Kanban Agile

Let's take a step back and look at the two most popular frameworks of Agile: Scrum and Kanban. Instead of boring you with the typical definitions, instead, let's look at why teams and organizations think they choose one over the other. 

Scrum

"I am guaranteed to release product to my customers every two weeks."

Potentially shippable product does not mean it's in the hands of the customers. It means it meets the team's definition of done. It may have to be deployed into an integration or stage environment before production for further integration and testing before being released. 

"We don't have to estimate capacity, we just estimate the work."

Scrum (and Agile in general) is about predictability. If you delivered an amount of work this sprint, you should be able to deliver a similar amount for "the next sprint. If your velocity makes wild swings from sprint to sprint, there's a larger problem. A good team plans their sprint delivery based on their past performance. Which leads to another one...

"There is no long-term planning, just short-term execution."

Scrum is where long-term product planning meets short-term execution. Products and product features are extremely long-lived if they are the right things. No one wants to spend time and money on things that customers won't use or don't work.  

Kanban

"We do Kanban because Scrum takes too much time."

Kanban was born from lean manufacturing. There is always a daily standup at the beginning of the shift. In best-in-class manufacturing, there is also a weekly meeting for metrics and a monthly safety meeting. In order to be successful, your Kanban teams should be taking almost the same amount of time!

"Kanban isn't planned or managed. Just executed."

The Kanban backlog is just as refined as a Scrum backlog. Based on classes of service, the team plans their work each day and throughout the week. For example, work in the "standard" class of service is defined as start to finish in the calendar week. 

"Our team isn't a software development team."

I waver on this one. Unless you are pure customer service (think call center), you likely have larger projects you're trying to complete. 

So what?

Given all of the above, it's safe to say there is definitely no single right way to be Agile (although there are LOTs of wrong ways!). As an organization, there will likely be growing pains while you try to figure out how teams work best. 

Agile is not a thing you do. It's not a software development framework. It's not a 40-hour skill. Or a two-week sprint skill. Or even a Program Increment skill. It's a mindset...nay...I would argue it's a lifestyle. Agile is all around us if you open yourself to it. 

 

Looking for more tips on how to be Agile? Check out Agile Batch Size: An Ode to Laundry or The ABC's of Agile. And if you want to know more about how to successfully implement Agile in your organization, reach out to us

Topics: blog scaled-agile enterprise kanban scrum tips agile
1 min read

Is Going Agile Worth It? The Wall Street Journal Says So!

By Morgan Folsom on Jul 29, 2020 12:15:00 PM

2020 Blogposts_Is Agile Worth It- The Wall Street Journal Says So

Agile is one of the hottest trends in the business world right now - but is it actually worth it? (short answer: Yes!). The Wall Street Journal recently published an article that discussed the importance of cultivating an agile culture for enterprises who want to move forward with their business and survive the pandemic. Check out how our client, ACI Worldwide, has made impressive improvements in their process, pivoting to the Atlassian suite to manage their work across the board, in this Wall Street Journal spotlight. 

https://partners.wsj.com/atlassian/built-for-change/aci-worldwide-paying-agility-forward/

Not only did these changes help ACI Worldwide increase its enterprise agility, but it also successfully prepared their organization to quickly shift focus and resources during a constantly-mutating global pandemic. 

Give the article a read and let us know what you think!

Topics: scaled-agile enterprise service-management safe agile
3 min read

What is Customer Centricity in SAFe 5.0?

By Rebecca Schwartz on Jul 10, 2020 12:15:00 PM

2020 Blogposts_What is Customer Centricity in SAFe 5.0-

SAFe 5.0 puts a greater focus on the customer, placing them at the heart of all decisions around the product or service the business delivers. Although the technical and functional aspects of a product are key, the satisfaction of the customer ultimately decides the true fate of the solution. If the customer continues to have a positive experience, your business can continue to grow and thrive! In the updated SAFe 5.0 framework, Scaled Agile elaborates on Customer Centricity, which puts the customer at the center of all business decisions that guide an organization to not only meet customer needs but exceed them as well.

What is Customer Centricity?

Customer Centricity is the mindset that the business must adopt to provide a positive experience for the customer. With every decision business leaders make, how those decisions impact the customer must be at the forefront of their minds. For this reason, the organization studies market research and user insight to ensure they truly understand the customer's pain points and develop solutions to address them. Customer-centric organizations take new approaches to solving customer problems by using empathetic design, i.e. putting themselves in the shoes of the customer. In turn, the organization can fully engage with the customer and build long-lasting relationships with them. After all, this is what we try and capture in User Stories; however, in SAFe 5.0, we're capturing this information at every level of the organization to build the right solutions.

Why is Customer Centricity important?

Customer Centricity is important because customer satisfaction is the key to developing a business and maintaining it. If your solutions and services fail your customers, your business will also fail. This new focal point also matters because it allows organizations to get direct feedback and input from the customer. Listening to their ideas and opinions allows businesses to tailor the solutions to their exact needs, which increases company profits, attracts new customers, and enhances current customer relationships.

How does Customer Centricity Affect Me/My Organization?

As an individual and as an organization, this piece of the framework may change your mindset and the entire company vision when it comes to creating solutions. When in the decision-making process, whether on your own or collectively as an organization, the outcomes that affect the customer will need to guide those decisions. As an individual working on client solutions, you may sometimes get requests that aren't necessarily best practice. Using Customer Centricity, you can consult user and market research to arrive at a solution that is best practice while also satisfying the customer.

 

Our Thoughts on Customer Centricity

At Praecipio Consulting, we are excited about this emphasis on Customer Centricity, as we love providing an exceptional customer experience. While working on our projects, we gather customer feedback daily to ensure we're moving projects in the right direction. With this, we're also able to revise on an iterative basis, meaning changes are made consistently throughout the project, instead of piling up and causing delays at the end of the project delivery. We also find that this approach allows us to truly be customer-centric, as we are constantly engaging with the customer and strengthening our relationship with them. Internally, we keep a close eye on the updates to SAFe so we can practice it successfully, as well as guide clients through the changes as well.

 

If you are looking for more guidance on the SAFe's recent update and why it matters to increase your business agility, check out this post

Topics: scaled-agile safe customer-experience
4 min read

Where Do Business Analysts Fit Into The Agile Organization?

By Morgan Folsom on Jul 8, 2020 12:15:00 PM

2020 Blogposts_Where do Business Analysts fit into an Agile organization-

One of the hardest parts of an agile transformation (outside of, you know, changing up the entire way that your organization produces value), is aligning existing organizational structures to new Scrum team roles. This process is absolutely essential, and you must take into consideration both the current role as well as the personality and interests of your team members. 

This blog post will focus on how you can specifically map Business Analysts (BA) into your new Agile organization. Changing someone's job title requires sensitivity, and not every BA will exactly fit the description as outlined below. So, be sure to work with the individuals in your organization to find exactly where they should be. Don't forget that one of the key tenets of Agile is fast feedback and iterations! You may not find the right mapping the first time around, but some people will likely shift around as teams figure out how they work best.

What is a Business Analyst (BA)?

Let's start with the basics - what do BAs actually do? Before you can figure out where they'll go in the organization, let's start with establishing what role they serve. 

According to CIO.com, "Business analysts (BAs) are responsible for bridging the gap between IT and the business."

What this looks like can vary across companies and industries, but the BA role generally involves analyzing data to determine requirements, deliver recommendations and reports, and evaluate existing processes. Successful BAs are often very detail-oriented and effective communicators, which can make them an asset to any team. 

What are the roles in a Scrum Team?

Looking at Scrum teams, in particular, there are three primary roles:

  1. Scrum Master (SM): The Scrum Master supports the team members, unblocking them when necessary, and holding them to their commitments. Scrum Masters are the protector of the team – they ensure that the Product Owner and the organization respect the dedicated scope that the team has agreed to. 
  2. Product Owner (PO): The Product Owner owns the product (wild, I know!). They incorporate customer and organizational feedback to manage and prioritize the backlog of the team. 
  3. Development Team: A self-organizing team of developers that are responsible for determining the best way to implement the requirements of the Product Owner

So, where do they fit?

Let's compare. Which of the above Scrum Roles sounds most like a BA? Someone who has experience analyzing data and translating it to requirements will likely be well-prepared for...doing the same thing for a Scrum Team! Generally, where we see BAs succeed the most is when they take on a Product Owner role. 

Much of the work is the same in these two roles, with a focus on data-based decision making and effectively communicating requirements. A Product Owner must be able to clearly communicate their goals to both the team and to internal and external stakeholders. Additionally, these communication skills are also necessary for the process of gathering feedback from customers. 

On the other hand, we generally see less success in mapping BAs to Scrum Master roles, or (even worse) trying to have a BA function as both a Scrum Master and PO. The shift from product and data focus to people-focused work can be hard for experienced BAs, but it's definitely not impossible. 

Again, when trying to align your existing team members to scrum roles, being open to feedback and change is important! You are dealing with people, so even if on paper your BA is a good match for a PO role, if they are expressing interest in something more like a Scrum Master, your teams will benefit from leadership being open to this kind of shifting. 

Looking for more help in your agile transformation? Check out The ABCs of Agile or What’s the Difference? Agile Coach vs Agile Consultant! And if you are an enterprise looking to scale your business in a way where you still have financial control, learn How Jira Align Helps Enterprises Embrace Lean Budgets

Topics: scaled-agile business-teams
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
2 min read

How to Pay Down Technical Debt with an Agile Approach

By Chris Hofbauer on Jan 14, 2020 5:05:00 PM

Technical debt is a silent killer in many organizations today. A common misconception is that technical debt can be found in software bugs. While having bugs in your software is definitely one example of technical debt (and could be the most expensive), it is not the only one. Other technical debt comes in the form of work that was never completely finished, old code that is still in use, or even the systems and tools being used in the organization. These could have stemmed from taking short cuts or not delivering what was promised and then getting lost in the backlog. Whatever technical debt your organization owes, it is best to identify it as soon as possible and begin to pay it back before it is too late. 

Understanding Agility

Over time, productivity begins to give way to backtracking and putting out small fires. This causes deadlines to be missed or delayed, which again can lead to more shortcuts, patches, and workarounds. This causes the snowball of technical debt to continue to build momentum, which increases the concern for security threats. Anytime these shortcuts are made, there are crucial steps in the work process that are missed; one of those being documentation. Keep in mind - The less technical debt your organization has, the more agile they will be. Being more agile allows team members the ability to dedicate time to the items that are most important. 

Importance of Documentation

Documenting each step in your process and the work that was done, or not done, is extremely important in any organization. It's common for work to get done quickly and often not finished all in one sitting. For that reason, it is extremely important to not miss documenting all details of your work. Each step in the process should be described in enough thorough detail so that you or anyone else can pick up right where you left off. Having to go back and figure out what was done is not only frustrating but causes a decrease in productivity and additional missed deadlines.

Agile Approach with Jira

Paying down your technical debt can be better managed while taking an Agile approach using Jira software. One of the first and most important steps when beginning to pay down technical debt is to identify and bring transparency to it. Jira can be leveraged to shine that light on your current debt and give greater control over who this debt belongs to. Setting up your dashboards but using the power of the filters and the gadgets provided through Jira can help immensely. The average age chart and the pie chart are some of the most frequently used filters and gadgets. These help show all of the issues that have not been addressed over a period of time, which lead to an ever growing backlog. 

How to Pay Down Technical Debt

The road to paying down your technical debt can be a long one for many organizations and can be bumpy at times. However, it can be one of the most liberating and impactful undertakings your organization can take on. It's important to note that avoiding technical debt is not always realistic; however, it is crucial that it is controlled and kept from spiraling out of control. If you need help identifying technical debt in your organization or interested in learning how to configure Jira for more transparency, check out an old (but relevant) webinar Agile Best Practices with the Atlassian Toolset. Of course, you can always contact us to give you a hand. 

Topics: jira atlassian blog scaled-agile tips agile
5 min read

Agile Home Improvement Using Atlassian Tools

By Amanda Babb on Aug 13, 2019 11:59:00 AM

This year, my husband and I decided to FINALLY spend some money on the house. We started our conversation about home improvement at the end of 2018, thinking about “the list”: need, want, nice to have. We went through the exercise of writing separate lists to compare and prioritize. Quite frankly, I was surprised at how similar they were. We quickly realized there was a need to actually organize and prioritize instead of working on notebook paper, fridge magnets, and the occasional sticky note.

Trello vs Jira Software Cloud

When we were planning our wedding in 2015, we used Jira Software Cloud. We had a Kanban Board with tasks and actions. My husband, while enjoying the fact we had a list we could access from anywhere, struggled to actually transition the cards through the workflow. With my travel schedule what it was before we got married, I was constantly calling and texting because there were no updates on the Board. He especially hated the WIP limit I added to the In Progress column. He called it the "stop nagging me" column. In the end, it wasn't too terrible. It gave us a chance to talk about each others' annoying habits: my constant need for status updates and his inability to ever finish anything (wink). While it made our marriage stronger, it also taught both of us we needed something a little more lightweight to manage our home. 

This time, we’re using Trello. We have fewer cards and use checklists to manage the work. We still have a backlog, but it's concise and doesn't scare my husband with all the agile terminology. 

Screen Shot 2019-04-05 at 2.22.48 PM

Screen Shot 2019-04-05 at 2.20.44 PM

New Back Door with Dog Door? Check. New Ceiling Fan. Check. New Floors? Hmm...we have to research those. Floors can get pricey pretty quickly. While our budget wasn't tiny and we decided to install them ourselves, there are always hidden costs. We added a research column with a few requirements: budget, material choice, finish, and installation method (floating or glue-down). We finalized the budget and away we went. We chose a dark finish engineered bamboo (heh. get it?) and determined we could afford to do the whole house minus the wet areas (Kitchen, Master Bath, and Spare Bathroom). Several monies, a week for delivery, and a week to let the floors acclimate, we were ready to build. 

Bamboo* as the Foundation

*Not the treelike grasses of the family Poaceae. But working with Atlassian Bamboo during my day job got me thinking about continuous integration and continuous delivery while we laid down our floors. My husband and I created the project and plan. Our project name: Floors. Our Plan: LDHB (Living Room, Den, Hallway, Bedrooms). Our repository was the 90 boxes of floors stacked pallet-style. Our repository was centralized so we can both pull from the materials as needed. Our trigger for our build: moisture barrier and underlayment installed. 

The real fun was determining the Tasks. This was my first floor. While I understood the fundamentals, I needed some guidance to make sure I laid them down correctly. While he tackled the large areas, I was solely responsible for the Master Bedroom. My husband, who has laid over a dozen floors over the last few years, gave me the tasks:

  • Start in the corner of the longest wall
  • Insert spacer at the end of the board next to the wall
  • Insert two spacers for each board down the wall
  • Stop both tasks once close to the end of the wall

Pretty simple. However, my first floor required feedback. To be honest, I failed my first build based on feedback from my husband. I kept running the tasks without stopping for cuts at the end of each row. I had to remove some of my work, adjust, and rework the tasks: 

  • Start in the corner of the longest wall
  • Insert spacer at the end of the board next to the wall
  • Insert two spacers for each board down the wall
  • Stop both tasks once close to the end of the wall
  • Measure for cut piece
  • Cut piece
  • Install cut piece
  • Grab additional boards

IMG_3837     IMG_3835

IMG_3836

While it took me a little longer to get it right, the results are pretty spectacular. I was surprised at how easy it was to get into a rhythm. Once I had the right tasks, I could repeat the build relatively quickly and solicit feedback less often as I made fewer mistakes. 

Home Improvement Retrospective

Once we finished the floors, it was time for a retrospective. After all, we both learned new skills whether they were physical skills or communication skills. And you can't have Home Improvement without the Improvement. 

What did we do well?

  • Coordinated the Jobs and Tasks to make sure work was divided
  • Clear responsibilities as to who can and should do what
  • More experienced teammates provided good feedback for less experienced teammates

What could we have done better?

  • More cleaning ahead of the start date (SO MUCH DOG HAIR)
  • Earlier feedback based on the Tasks to prevent the first failed build
  • Planning for food (although our local restaurants and DoorDash drivers made a mint from us)

What actions can we take going forward?

  • Ask for feedback earlier in the entire process
  • Explain "why" each other prefers a specific technique or method
  • Freezer meals or Crockpot meals set up during the day

Continuous Improvement 

We're both feeling pretty confident now that we've tackled a relatively large home improvement project together. Trello's lightweight, flexible interface helps us better communicate and prioritize the needs versus wants of home improvement. Either one of us can add items to the backlog and we have: new interior hardware, update window treatments, etc. This way, each month we can evaluate our budget and either take on smaller improvements or hold off and make a larger improvement after a couple of months. 

Do you use any of your 'work' tools to manage your 'home' life? Contact us to share your use cases!

Topics: blog scaled-agile bamboo devops kanban culture jira-software trello atlassian-products agile
2 min read

Sprint Planning - How Long Should Sprints Be?

By Morgan Folsom on Jul 30, 2019 12:33:00 PM

Teams new to Scrum face lots of decisions - one key decision for teams to perform efficiently is determining sprint length.  

Scrum and Sprint Definitions

Scrum is an Agile framework that gives teams guidelines on how to complete their work. It contains sets of roles, ceremonies, and considerations for how your work is completed. 

A sprint is a concept in scrum that represents a time box - a short amount of time the team has committed to complete the work. Sprints can be as long as you want - however, it's most common for sprints to be between 1 and 4 weeks. Teams running scrum need to decide what makes sense for them.

What we often see is that team's first instincts lean toward the extreme: Either 1 week sprints or 4 weeks sprints. While there are arguments for the varying lengths of sprints, here are some common questions that you and your team should consider: 

Planned vs. Unplanned Work

If you are a scrum team that has high variability in your work, longer sprints may give you a necessary buffer. If you've got a one week sprint (with 1 of your 5 days already dedicated to ceremonies), even one or two unplanned pieces of work can prevent your team from completing the committed scope. 

On the other hand, if the team has unplanned work with a lower level of urgency, shorter sprints give you the opportunity to include the work in your sprint planning within a shorter time period. 

Time Dedicated to Scrum ceremonies

How much time per week should be spent doing sprint planning, retrospectives, backlog grooming, and demos? Shorter sprints mean more time is spent in these meetings. If you do not have dedicated roles (scrum master, product owner) this becomes even more essential. 

What we see in 1 week sprints is that teams can lose a full day (twenty percent of the sprint!) of each sprint to demos, retros, and planning. The shorter your sprints are, the more often you're having these ceremonies. 

Scope and Size of Tasks

Is your work small enough that it can be completed in the sprint length? If you are often not completing work in 1 sprint, a longer sprint may make sense (or you may just need to work on improving properly sizing your tasks).

Feedback cycle

How often do I want to see and evaluate completed work? Is it acceptable to go 4 weeks without a demonstration of the work that's being done? Do you need to know every week? Sprint length determines how often you'll see sprint demos and complete sprint retrospectives. 

Inspection and Adaptation

There's no one-size-fits-all answer to sprint length, and iteration is the key to scrum - so don't worry if your first choice doesn't work for your team. That's what your retrospectives are for, after all!

For more background on how we do agile, read our case study on how Praecipio Consulting takes on agile transformation

Topics: scaled-agile scrum
2 min read

Kanban vs. Scrum: Which One and Why?

By Suze Treacy on Jul 23, 2019 1:48:00 PM

Are you looking for ways to make your work more flexible and efficient, but feeling late to the Agile transformation party? Well, fear not! It's OK to be fashionably late to this Agile shindig!

Out of the many Agile Development frameworks out there, Scrum and Kanban are arguably the best known - similarities include their focus on continual improvement, and minimizing waste; breaking down large pieces of work into manageable, bitesize chunks for efficient delivery. However, it's important to understand the differences when looking to choose which style of working is right for you and your team.

What is Kanban?

Kanban, a workflow visualization tool, was first developed in the 1940s by Taiichi Ohno, for Toyota. Faced with a lack of productivity compared to their American rivals, the aim was to find a way to optimize productivity alongside their cost-intensive inventory of raw materials. A continuously improving process, Kanban uses boards with team-determined limitations to limit WIP (work-in-progress), identify and eliminate bottlenecks quickly and improve efficiencies among the team. Formal training is not required for teams to get started in Kanban, and, given that Kanban boards are intended to be used by everyone on the project, there is less need for cross-functional team members - it's easy to get started with Kanban quickly!

What is Scrum?

Although the history of Scrum is not without its controversies, it is widely understood that Scrum was developed in the 90s by Jeff Sutherland and Ken Schwaber, to present at the OOPSLA conference in Austin, Texas. Sutherland and Schwaber borrowed the term "Scrum" from Takeuchi/Nonaka's paper ‘The New New Product Development Game’ - comparing a team sport like rugby with success in the 'game' of product development. Scrum is far more structured than Kanban - with commitments to short iterations of work, team members have designated roles and responsibilities (product owner, scrum master, team members), with clear priorities identified by the product owner. High visibility engages and increases team accountability, while daily meetings enable blockers to be identified and dealt with quickly; sprints (and potentially shippable increments) are generally being delivered every 2 weeks. It is this lithe process which allows Scrum teams to quickly adapt to change, maintaining and building upon team efficiencies in future sprints.

Which method is right for me?

The long and short answer is that there's no right answer for everyone. The best thing you can do for your team is to learn more about each framework and give them both a shot. It isn't always easy to break old habits; the road to a true Agile transformation can be long and daunting - we'd love to help you get on your way and show you how Jira can enable you to optimize your Agile processes; email us at contact@praecipio.com for more information. In the meantime, learn how Praecipio Consulting helps our clients conquer the Agile transformation using Atlassian tools, so they can drive business results, and innovate.

Topics: blog scaled-agile kanban scrum
3 min read

Agile Coach vs Agile Consultant: The Difference

By Praecipio Consulting on Jul 9, 2019 12:17:00 PM

Agile has become quite the buzz word within the software development community. Some of the most successful software companies are known for how Agile they are and how often they can release code in production. However, before becoming Agile in software development, these companies first embraced and implemented the Agile framework across the entire organization–not just with the technology team, but with HR, Finance, Biz Dev, Legal, etc. And this isn't something that they accomplished overnight. 

Becoming an Agile organization, which can take a minimum of six months to achieve, involves undergoing a massive organizational transformation – redesigning everything, from strategy, processes, teams, governance, and work culture. This is why many companies decide to hire experts when they are implementing this methodology. Not only is it an enormous undertaking, but being Agile is instrumental for the future success, sustainable growth, and continuous improvement of an organization in an increasingly complex marketplace. 

So, when you are ready to bring in the right help for successfully achieving and sustaining Agile within your organization, you may be wondering if you should hire an Agile Coach or Agile Consultant. Before understanding the differences between Agile Coaching vs. Agile Consulting, you should ask yourself:

  1. Is our organization already Agile or are we trying to be?

  2. How mature is our team?

  3. What are our pain points?

  4. At the end of this engagement, what does success look like?

Now, let's shed some light on the differences between an Agile Coach and an Agile Consultant:

Agile Coach - A Subject Matter Expert

An Agile Coach plays a similar role to the one a teacher plays in school. They studied Agile methodologies and have been trained on how to teach those methodologies to others. Agile Coaches help train all teams within an organization and manages the implementation process in order to carry out a solid transformation. The coach works closely with each team and walks them through the steps of fully embracing and adopting the Agile framework. Instead of actually doing the work for the team, Agile Coaches equip their students with proper training, education, guidance, and resources so that they can successfully implement and sustain the Agile methodology. Working with Agile Coaches is typically a longer engagement. 

Some of the most common reasons for hiring an Agile Coach are:

  1. Organization is new to Agile methodologies and needs guidance (i.e. companies undergoing Agile transformations)

  2. Scaling Agile, working across all teams or at the enterprise level

  3. Improving performance, visibility, and predictability (portfolio planning)

Agile Consultant - A Business Consultant 

An Agile Consultant, on the other hand, is a practitioner. As the word practitioner suggests, he or she puts the Agile framework into practice by using their extensive experience with Agile to navigate roadblocks and quickly resolve any problems that are preventing the organization from achieving their desired results. Unlike the Agile Coach who provides guidance, the Consultant actually does the necessary analysis and problem-solving to put your organization back on track for success before handing the reigns back over to your teams. Essentially, an Agile Consultant provides a more short-term solution.

The most common reasons for hiring an Agile Consultant are:

  1. Problem-solving: You realize the problem is beyond your teams' capabilities and you need a specialist.

  2. Your organization is not seeing the effective outcomes associated with the Agile methodology. 

  3. You want advice on what issues need to be resolved and how to quickly tackle them.

Difference Between Coach and Consultant

Now that you understand the key differences between an Agile Coach compared to an Agile Consultant, you are one step closer to hiring the right expert for your organization and even that much closer to accomplishing a sustainable Agile framework. Even though a Coach and a Consultant play different roles, they are both equally essential in promoting cultural change and overcoming the obstacles that come with successfully embracing, implementing, and practicing the Agile methodology. 

Is your organization undergoing an Agile Transformation? Learn how our approach empowers organizations to achieve a successful Agile transformation in a sustainable and scalable manner, which drives business performance and propels our clients to be disruptive, innovative leaders in their industries.

Topics: blog scaled-agile process digital-transformation agile
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
4 min read

Using Scrum and Kanban Boards to Improve Communication

By Praecipio Consulting on Jun 12, 2018 11:00:00 AM

The ability to 'see the big picture' and have a clear understanding of the work teams complete is something our clients ask for often. With a product like Jira Software, anything is possible; however, there are tools within the project management software platform that are built specifically to help users stay in the know and track project statuses. 

Out-of-the-box, Jira comes equipped with three powerful task boards that teams and managers can use to manage projects and gain better visibility into the work being done: Scrum board, Kanban board, and Agility board.

Tracking issues on a board will open up views into the work that you're looking for and they are simple to set up.

Step 1: What do you want to see?

Step 2: Board Selection

Step 3: Share and Use 

Step 1: What do you want to see?

It's common for organizations have a lot of issues in Jira, but do you need to see all of them, every day? Probably not. The first step in setting up a board is to understand what it is you want to see. Boards can be built to import every issue from every project, or by a JQL filter, which can display a very specific set of results. Using a filter is traditionally more useful and manageable. Either way, it's important to understand the scope of your board to make sure that when you're looking at it, you are only seeing the items that are important to you. You can use one, or a combination of these approaches. Keep in mind that an issue can live in multiple boards, and any updates that are made to an issue will appear on any board where the issue is displayed.

Step 2: Board selection

Jira offers three boards that you can choose from (assuming that you are on Jira Software): Agility, Kanban, and Scrum. Even though they seem very methodology-specific, choose the board that works best for you and/or your team - and it's not just for software or development teams.

Kanban Board

Kanban is all about continuous flow. With this in mind, there are a lot of different uses for this board such as a team that is not practicing scrum or a project manager who wants to visualize the work happening on their project. Recently, Atlassian added the ability to have a backlog option for Kanban boards which will allow you to specify a status that would represent work that it's quite ready for prime time.

Pro tip: Define your swim lanes to organize your work. By default the swim lanes will be set to look at priority but there are a variety of options to split your work into meaningful views.

Scrum Board

Scrum promotes commitment to a subset of work for a specified time period. The Scrum Board focuses on looking at your backlog of work and pulling issues into sprints which the team will focus on completing in a specified period of time. If your team has a sizable task that they are trying to parse into manageable chunks of work, this may be the board for you as it allows users to focus only on the subset that you've committed to for that period of time.

Pro tip: Check the "Days in Column" option found in the "Card Layout" section of the board configuration to ensure your work flows appropriately. 

Agility Board

Agility boards are the newest boards in Jira Software. They're perfect for teams that want to quickly jump in and get started and don't require any complicated configuration. This is a great board selection for projects that may be looking at a single issue type or if all issues follow the same workflow. 

Pro tip: If your Jira Project is for simple task tracking, use a business project and use an Agility board. Its simplistic design is perfect for the Executive with too little time and no "technical" skills.

Step 3: Share and Use

Now that you've chosen (and hopefully created) your board, make sure to use it as a communication tool. Too often we see boards created but not used during meetings with team members. There is a lot of power in seeing the work displayed for the team so everyone can have a complete understanding of what the progress looks like on a continuous basis. The more you use the boards to communicate progress, the better the information will be as its submitted to the board.

Pro tip: It's important to note that when you share the board with others, you need to make sure that your filter is shared with those who will need to view the board. 

Now that you have a better understanding of what the boards can do for you, go out and create a few for your teams. Experiment with different board views to see what works best. If you're still not sure, contact us! We help teams in every industry make the most of their Atlassian tools and business processes.

Topics: jira blog scaled-agile process-consulting consulting-services jira-software
4 min read

Stay Agile with Jira and Confluence

By Praecipio Consulting on Jun 12, 2018 11:00:00 AM

As a marketing professional, I had a limited exposure to Jira before I joined Praecipio Consulting. Praecipio Consulting is an Atlassian solutions partner, and now, I eat, sleep, and breathe the Atlassian toolset. But before I really knew what it was, I used Jira Software to collaborate with a distributed team on a project. It was an interesting experience using Jira, because this was a ticketing system for 'IT guys and coders,' not for precious marketing professionals - right? I had been happy - or at least at peace - with using Microsoft Project, Sharepoint, One Note and Excel spreadsheets, along with Customer Relationship Management (CRM) and marketing automation software. But when I saw my first kanban board, and how easy it was to create, organize and visualize work in process, I thought this was a great way to begin an agile marketing shift.

While I'm still getting used to an all Atlassian world, I'm excited to share with you how ticketing software, originally designed to track software bugs, along with other Atlassian tools, have shown me a path towards an agile marketing future. So, here's my 101-level guide to using agile methodologies and tools to manage marketing projects.

Marketing Tasks = Jira Issues/Tickets

Think of your marketing activities as Jira Issues. For example, say you're hosting a webinar next month. Login to Jira, create a new epic for the webinar, give it a name, provide some additional details (the sky is the limit, you can customize the kind of information you want to capture) and click save. 

But wait. A webinar has a lot of subtasks within it: you also need to set-up a landing page, attach a form, create thank you emails and internal notifications, schedule the speakers, write a script, create the presentation, setup dial-in info, and a lot more. You can add all of those tasks, too, under the webinar ticket and create a nice, tidy place to track all activities. And, just like marketing automation tools that let you automate repetitive actions, you can create a Webinar Issue template that generates all of these recurring tasks each time you plan a new webinar, saving a lot of time and repetitive work.

There's a lot of work up-front to set up your tasking, but once you've done it you can continuously improve and become increasingly efficient and fast only making small adjustments.

Tracking Assets and Tasks 

Now that you have a task list of marketing activities, you have to create the actual assets. You write email and web page copy. Your designer creates beautiful graphics. Your digital folks create tracking links and create a home for all this precious content to live. Confluence gives you a place to create or simply store these assets in a single repository. And you can link the individual tasks from Jira to these pages in Confluence, giving you immediate, bidirectional access between tasks and the actual work product. This is pretty handy and makes team collaboration a breeze.

Again, you have to do some advance planning and preparation to make this work seamlessly. But it's worth the effort in the long run.

Using a Kanban Board

With marketing activities and their related subtasks entered into Jira, and a place to house your marketing assets, you can start managing a project. What should the team be working on first? Where are we on the case study copy? Is Elaine finished with the banner ad artwork? A Kanban Board lets you see where these tasks are in their lifecycle, from "Backlog" to "In Progress" to "Complete" (you can customize these labels, as well). At a glance, you can see how much work is done, how much is in flight, and what's coming up. Do you think the white paper project is more important than the brand guidelines update? Move the brand guidelines to the backlog and focus on the white paper.

With a Kanban board (and even other boards, like Scrum and Agile), you can adjust your work priorities instantly, making it easy to see who is doing what and when it will be done. Ultimately, agile boards help teams improve communication and collaboration.

Plan Alignment

Kanban boards are super cool, as are scrum boards. Portfolio for Jira, too, can help you create a marketing roadmap to visualize all your projects over time and track resource availability and capacity. Once you've got your marketing ducks in a row, Portfolio will allow you to not only visualize a plan the way you've designed it but also create variations. That's pretty dang neat! Admittedly, there's a lot of work required to make the best use of this tool. But again, once your organization is actually organized, your project management can become amazingly powerful and useful.

Now what?

Now, we've learned that Jira is a powerful tool that welcomes all - not just software and IT teams. And if you didn't know about Confluence or any of these awesome planning tools, you owe it to yourself to consider them for organizing your marketing plan. If you're interested, start by checking in with your IT or software development teams. Chances are, they are using Jira and possibly Confluence right now. There's your starting point. And if you want a demo, or to purchase licenses, or need help getting started, let us know!

Topics: jira blog scaled-agile best-practices confluence marketing collaboration agile
4 min read

Agile Batch Size: An Ode to Laundry

By Praecipio Consulting on Jun 4, 2018 11:00:00 AM

One of the most difficult concepts to explain in agile is the concept of Batch Size. It's a principal tenet of Lean Product Development and is an ACTUAL principle in SAFe (# 6 to be precise). However, when we work with our clients to evaluate their practices and processes, we see product backlogs in the scrum boards of hundreds of items. In one case, a client used the concept of a Groomed Sprint to define what part of the Backlog had been groomed and prioritized by the Product Owner, Scrum Master, and Team.

What we have here, folks, is a failure to right-size Batch Size. 

I've been thinking about this for a while. What is the best non-Agile example of Batch Size? It wasn't until I discussed it with my husband for the 4th time in two days that it clicked: laundry. 

Laundry is something we all need to do, but don't enjoy. And work is that way too. Sometimes we have a great laundry day: it's not on the floor, it's not stinking up the bedroom(s), it's moving through without being the only thing we accomplish that day. It's a good laundry day. Sometimes, though, it's a horrible laundry day. It's been put off so long that it's almost overwhelming: it's everywhere and is likely the only thing that's accomplished that day. Picture this: it's laundry day at your house. Individual piles are consolidated into a Big Pile. The Big Pile is sorted into smaller piles according to color, fabric, and cleaning products. The smaller piles begin to make their way through the system one at a time. 

I know what you're thinking: Amanda, we all know how laundry works. Bear with me. 

A smaller load of laundry requires less time per batch to both wash and dry. If you've ever flown into a blind panic when realizing you need clothing for the next day and have washed a single set of clothes, you know what I'm talking about. It takes less time for the washer to fill, agitate, rinse, and spin than the extra large load. In addition, it takes much less time to dry a single set of clothes than a whole dryer full of jeans. However, this is wasteful. It wastes energy and water and time because you still have that Big Pile you have to deal with at some point. And you know you do and you will. At some point. Before your husband decides to drag three laundry baskets across the house. And they're full of jeans and work shirts. <sigh>

Thinking about the above scenario another way, instead of lumping everything together into the Big Pile, why don't we pre-sort? Doesn't that make a smaller batch size and make it easier to flow through the system? Yes, but also no. Pre-sorting does take some of the handling out of consolidating laundry into the Big Pile by making smaller batches. However, those small batches can add up to a Big Pile if not adequately moved through the system when they're ready. 

What if, instead, we right-sized the batch? What if, based on the color, fabric, and cleaning products, we put the batch through the system when it was determined to be the right size? Not so big that the Big Pile must be broken into smaller batches to flow through the system, but not so small that we're wasting resources including, the most precious resource of all, time? It's time to right-size your laundry. Just as it's time to right-size your work. 

Within any agile framework, this is the essence of throughput. When requirements come to the Team in a Big Pile, the Team must break the Big Pile into consumable smaller batches. These batches must also be prioritized: clothing needed in the next day, versus clothing needed next week, versus something you've worn once and likely won't wear again for a few weeks or until a special occasion. Just as we prioritize our laundry, so too must we prioritize the backlog. What is the immediate need? What can wait a few weeks? What is a nice-to-have? Note: in the extended metaphor, nice-to-have is dry cleaning. Not something you need, but sits on a hangar in your closet, is reassessed as an outfit every three months, and ultimately placed back in the closet in favor of the clean laundry. So too should those nice-to-haves be removed from the backlog to be addressed every once in a while to see if there's a current need. Either put them back in the closet or donate them. Deprioritize items in the backlog or remove them altogether. 

How can you tell the batch is the right size to move through the system? Much like laundry, it's trial and error and feedback into the system. You didn't come into this world knowing how to do laundry. And there have been plenty of times that you've accidentally thrown a red sock into a load of whites or bleached something in your darks or even shoved too much into the washer only to have to run the dryer three times to get it adequately dried. So what did you do with this information? You learned from it. In fact, you retrospected on what you did and learned from it. I see what you did there, Amanda. So too will the Team learn from each batch of work that flows through the system. Within a retrospective, the Team should look at their batch size estimates and make adjustments for future work. This allows the Team to establish a predictable velocity with which to plan future work. Much like you've figured out how to do laundry efficiently over time (hopefully). Either way, it all comes out in the wash. 

Topics: blog scaled-agile process-consulting consulting-services
12 min read

Project Estimation

By Praecipio Consulting on May 21, 2018 11:00:00 AM

Work smarter, not harder. Easier said than done.

However, in agile software development, there are some things teams can do to begin working smarter and more efficiently. 

Many companies still estimate the amount of time a project will take in hours. But this approach, typical of the waterfall methodology, can lead to cost overruns and missed deadlines. "(Humans are) terrible at estimating how long something is going to take. We're just not good at it," said Christopher Pepe, Chief Technology Officer at Praecipio Consulting. "But what we are good at is estimating the relative sizes of things." And so he makes this point in his story above on story points vs. hours, and why companies should adopt this agile concept of planning and managing development projects.

But first, what is a story point? According to Dan Radigan in his article The secrets behind story points and agile estimation, "Story points rate the relative effort of work in a Fibonacci-like format: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100." Story points provide an abstract way of understanding how complex a project is, and how much work a project will take. 

In a comparison between agile and waterfall time estimates, Steve Cooke at Swarm Online writes "The reasoning behind using points rather than hours, is that it might be difficult to estimate in units of time at speed. Also, the speed at which the team can deliver points of effort will depend on the skills of the individuals in the team. Team A might not be as fast as Team B but the relative size of the stories remains the same."

If you want to know more about how using story points could help your team with project estimation, reach out to us today. 

 
 
 
Video Thumbnail
 
 
 
 
 
 
 
 
 
 
 
2:53
 
 
 
 
 
 
 
 
 
 
 
 
Topics: blog scaled-agile process-consulting
3 min read

The Good Place: Dysfunction in the Agile Organization

By Praecipio Consulting on Oct 13, 2017 11:00:00 AM

By Amanda Babb, principal of Process Delivery

It’s been a great first week of the fall season of television. Some of my favorites have been rebooted, my alma mater was featured on a t-shirt, and one that I’m obsessed with has sparked a bunch of corollaries with what we do at Praecipio Consulting.

If you’ve seen a show called The Good Place, you know what I’m talking about. It’s a Sartre-esque comedy where Hell is other people. But there’s an architect. The Architect is responsible for developing the most diabolical experience (torture) for the four anti-heroes to make them question why they’re doing what they’re doing and why they’re doing it with the people they’re doing it with.

Cue the Agile Dysfunction discussion.

There is one key distinction between The Good Place and the real world, however, and it's the capacity people have for learning. If given the opportunity, the Team and The Architect can learn and, more importantly, learn from one another. In The Good Place, a Team is not allowed to self-organize, nor are they afforded the time to perform retrospectives. The Architect doesn’t know why the plan isn't working and hits the reset button. The Architect, while gathering data on every failure, does not take the time to perform a retrospective with the rest of the organization and ends up with a mutiny. We at Praecipio Consulting too often see dysfunction in organizations as a result of lack of learning. A mistake or failure is subject to the reset button, not discussed, analyzed, and ultimately acted upon to create a better way to work. 

The Architect gets frustrated and continues to reboot the four members of the team for multiple iterations. In the hundreds. The Architect dictates the constraints. The Architect dictates the other people involved. The Architect dictates roles. The Architect records results. The Architect resets the scenario every time something goes wrong much to the dismay of his own cast of players. 

Teams self-organize and question the mission. Teams figure out the solution. They work together to understand their situation while choosing to do what’s right regardless of direction. Sometimes with disastrous results: flying shrimp, mutant giraffes, a clam chowder fountain. All of these combine in a chaotic sequence forcing one of the main characters to finally stand up and admit being wrong. The team is not the villain. The team is simply questioning the nature of their reality and determining whether or not they can push the boundaries. 

I’m not saying there’s a villain or a hero in this narrative: the Team is not smarter than The Architect. They both have strengths in the scenario. The Architect’s frustration is our own everyday frustration: why won’t the Team just do what they’re supposed to? And the Team frustration is our everyday frustration: why does The Architect think we can’t understand what’s actually happening?

This is not to say The Architect is the villain either. There is a plan. This plan has been presented, approved, and is being executed. Small changes are presented each time the reset button is hit: let's try it again, but this time, add a member to the team. Let's try it again, but this time the main character is "The Best Person." Let's try it again, but without introducing any of the team members to one another in the beginning. And again. And again. And again. Because The Architect is a strong leader, the rest of the cast and crew continue to follow the direction of the plan, but without input for the next iteration. 

"The definition of insanity is doing the same thing over and over and expecting different results." - Unknown

This is the number one dysfunction of agile organizations: the lack of a retrospective at any level. This is the first agile ritual that disappears at the Team, Program, or Portfolio level. How can the organization learn and grow without a moment to reflect on what it learned? By removing learning from the organization, you have removed trust, innovation, and efficiency. 

If you think you're in The Good Place, take a moment an perform a retrospective. You may actually be in The Bad Place. 

Topics: blog scaled-agile process-consulting training
2 min read

Jira Reports & Dashboards

By Praecipio Consulting on Apr 21, 2017 11:00:00 AM

Expert led, hands-on Atlassian training

This course is for those who are new to Jira dashboards and reports. You'll learn how to use Jira's out-of-the box reporting and dashboard capabilities to view and assess progress and bottlenecks within projects. In hands-on exercises, you'll create and configure a project dashboard and learn how to configure dashboard gadgets. You’ll also learn how to read Jira Agile reports, configure a wallboard, and create a multi-project dashboard. The course discusses dashboard best practices and pitfalls and how to ensure your reporting reflects the right metrics at the right time. This course should put you on the path to using one of Jira's core strengths: displaying project status visually on fully customizable dashboards.

High-level topics

  1. Overview of each of the major Jira and Jira agile reports - the purpose of each, how to use, how to read and interpret the data
  2. How to create a dashboard and populate it with gadgets
  3. How to create a dashboard that tracks multiple projects
  4. How to configure gadgets so they display data as you need
  5. How to create and use a wallboard

Who should attend?

Agile project managers, scrum masters, technical managers, Jira system administrators, or anyone looking to learn more about Jira dashboards and reporting

Level: Introductory

Suggested prerequisites

Familiarity with Jira Agile, Jira Query Language (JQL), and basic Jira functionality

Course objectives

After attending this course, attendees should be able to:
- Identify and describe the purpose of the most commonly used reports in Jira and Jira Agile
- Create a dashboard, populate it with gadgets and configure the gadgets 
- Read and interpret Jira and Jira Agile reports 
- Create and use a wallboard 
- Create a dashboard that tracks multiple projects

When

Friday, April 28th 2017 from 10:00 AM to 2:00 PM (CST) 

Where 

Praecipio Consulting - 5918 West Courtyard Drive Suite 450, Austin, TX 78730

As an Authorized Atlassian Training Partner and Atlassian Platinum Enterprise Expert, we deliver value-added instruction and expertise to help you increase your knowledge of and throughput with the Atlassian product suite.

 

Topics: jira atlassian scaled-agile training jira-software
2 min read

2017: The Year of the Human

By Christian Lane on Jan 19, 2017 11:00:00 AM

It's only a few days into the new year, but already we see the latest tech crazes for the next 346 days in the headlines: DevOps, ITSM, and SAFe. With Atlassian, the world's industry leaders have had great success in these frameworks (many with our expert help) and technology is producing the most ground-breaking things in human history. Everybody wants to put a proverbial man on the moon with their next release, and these are the proven methods to do so. 


But one integral factor in the equation remains- beyond products, beyond methodologies: human beings. Behind each of these revolutionary web applications, overseeing each of these cutting edge processes, are our most important resources: our team. We must automate our technology to give us more time to collaborate with each other; to facilitate the tribal knowledge sharing that allows a community – a business – to thrive and grow. 

In a recent presentation, Praecipio Consulting partner, Christopher Pepe remarked on the paramount asset of human knowledge within organizations. Behind each great innovation is a team who did their work to the best of their ability to reach this next level. People are the ones who make DevOps, ITSM, and SAFe the successful frameworks they are. People are the ones who developed Puppet, Splunk, Tempo and Atlassian to help us do our jobs more efficiently. We choose and configure our tools in the most advantageous way to give us both the best competitive edge and to, ultimately, free up our resources (our people) to come up with the next, history-making idea.

Each of these products and frameworks enables us to be more efficient. To build things faster, better, and smarter that help us (and others) do the same. With that time we save - be it programming an application to triage errors to give back support time, or an app that helps you order groceries for pickup so you have an extra hour to spend with your family. The things that will move our industries (and our world) to the next phase are being created by the companies that configure their tools to give them that time. We know - we've helped them.

Everybody says they will give you your greatest technology ROI. When we say that, we mean that we're sending the best team in the world to help YOU be the best team in the world. We have the knowledge and the expertise to put your proverbial man on the moon - whether that's breaking the Fortune 500 or doubling the size of your new business in a year. Our clients and partners (like DocuSign, Splunk, and Tempo) are a testament to our commitment to delivering this ROI to you at exponential rates. We don't just care about you getting a functional product - we want to see you use it perform optimally so you can go back to what you're passionate about. 

Give us a shout and let's talk about your most valuable resources- your team- and how we can get you the technology solutions to focus on their best work. We're ready to help you get to your proverbial moon. 

Topics: atlassian blog scaled-agile devops itsm
8 min read

4 Phases of Agile DevOps | Atlassian

By Praecipio Consulting on Aug 15, 2016 11:00:00 AM

As Development and IT Ops teams look to be more efficient, decreasing their time to market and increasing product support, DevOps has become the predominant industry solution. There are many resources that paint a picture of the ideal processes for Development and Operations working harmoniously together- but how do we actual get there? Where should we start? 

We need to begin with the end in mind. Our end goal is to deliver customers the software they need as fast as possible. The software industry is faster and more dynamic than the businesses of physical products. We need to get our customers features so they can give us crucial feedback while beating our competitors to market. The faster release development goes from concept to code, the quicker we can make customer happy. DevOps is a broad term with a variety of meanings, but at the end of the day, it seeks to increase the collaboration and automation between Development and Operations so we can get more frequent and higher quality releases into the hands of our customers.

When it comes to collaboration and automation, a focus on process and the use of the Atlassian suite are the best way to get there.

 The infinite loop of developing and supporting products that customers need and want with DevOps and the Atlassian Suite.

Image source: Atlassian 

Selling DevOps

The pain of hectic firefighting and troubleshooting make the need for DevOps obvious on the frontline, but getting alignment and investment at the organization level can be pretty difficult. Successful implementation is going to require buy-in and support from a variety of stakeholders and many levels. Before we can get our hands dirty, we need to convince everybody to spend the time and money to get these processes and tools in place.

Here are three ways to get the ball rolling:

One for the Book Club: Phoenix Project

Everybody has those business books that revolutionize the way they manage their work and companies. The Phoenix Project by Eugene Kim narratively addresses and exposes the gaps in processes between teams and points to a DevOps prescription to unblock cross-team work. We highly suggest recommending it to your teams, as it's a great way to get everybody on the same page and really see the value of DevOps.

Build a Business Case

At the end of the day, businesses exist to make money. To invest time and effort, we need to calculate the business return. The 2016 DevOps report from Puppet Labs does a brilliant job showing the financial reasons to adopt this shift.

The ROI of reducing excess work with DevOps according to 2016 DevOps report from Puppet Labs

Image Source: Puppet Labs

Phase 1: Go Agile

To get the real benefits of DevOps, it requires a shift in mentality and how we manage work through our teams. As we break down our requirements into smaller individual user stories, we can flow the work through the features through the process faster. By having the structure, ceremonies and processes in place to accommodate smaller pieces of work, we can get our customers the features they need and incorporate their feedback to iterate the next, improved release faster.

Here are some helpful ideas to help your teams go more Agile: 

  • Get Up, Stand Up | Simply doing stand-ups doesn't mean you're all the way agile, but it's a great way to get our teams into the mindset. Keep them short and reduce the headaches of status updates and emails. Fill everybody in on what you did yesterday, what you're doing today, and what pesky blockers are in your way. It's facilitates more agile and responsive team collaboration and support (the heart of DevOps).
  • Iterate Everything! | Speed up that Agile transformation, breaking down your waterfall projects into smaller sprints so you can always reprioritize and adjust as needed. Start with your software teams and spread out to your IT Ops projects and even marketing projects. Start in your own department: find the planning spreadsheets with those idealistic due dates, set up a backlog, and start sprinting!
  • Agile Boards | Once you're planning and executing in sprints, track and visualize it on a Jira Software board. Avoid those dreadful status meetings and send out the link to the board to keep everybody informed. Also, throw some wallboards up around the office so everybody can see your team killin' it. 

You'll know you're a lean, mean, agile machine when your software teams are cranking out stories in a steady cadence of sprints. Over time you'll see that velocity stabilize - then you can accelerate!

Phase 2: Get with Gitflow 

Git and Gitflow is a great way to help our dev teams increase velocity. As we're working with smaller stories, we need to be able to collaborate effectively with on our code base so we're not stepping all over each other. Version control systems of the past aren't going to be able to keep up with our blazing fast development teams. Bitbucket and the underlying technology of git are going to let our teams build user stories and merge them into the code base without wasting time messing with annoying versioning issues and costly code conflicts. 

  • Start with the Basics | Start by learning (allthethings) about how to effectively manage your branches and build in code quality with Atlassian's Git Tutorials and the Git Getting Started guides. Share them with your team so everybody's on the same page and knows the difference between a commit and a pull request.

  • Move to Git | If you haven't made the cutover to Git quite yet, get your team and managers onboard by sharing the benefits and how it will help ship more code. Once folks are convinced, learn why Bitbucket is the Git solution for professional teams and helps with pull requests, branching strategies, permissions and scalability. When it's time to actually move all that code over, see how we helped Splunk get git and 4 times the number code reviews completed. 
  • Start Branching | With the tools in place, it's time to start branching! Learn more about some common workflows to better handle branches here. Utilize those pull requests to build in code quality as you go. Eventually your Dev team will be humming with full Gitflow and your Ops teams will be in love with the clearly designated branches.

  • Automate, Mate | The marvelous integration between Bitbucket and Jira Software lets us automatically update the Jira issues based on what's going on in Bitbucket. Developers don't need to switch context anymore to keep the ticket up to date, and the whole team gets an accurate idea of what's actually going on. Check out our Automation Webinar to learn more about the powerful workflow triggers that make this possible.


The Gitflow branching strategy shown above utilizes different branches for specific roles like hotfixes and releases to help manage larger and more complex projects. 

 Image Source: Atlassian

Phase 3: CI/ CD

The next phase is how we define the crucial handoff between Dev and Ops. When our units of work and code changes are smaller, we're going to need to deploy more often to get those features to our customers. Before we ship it to the ops team and production, we need to ensure quality as our individual features come together. This is where good Continuous Integration/ Continuous Deployment practices along with Atlassian's Bamboo are vital to successfully shipping our product. Catching bugs and issues before they go to production is going to help both the Dev and Ops teams sleep better at night.

  • Learn about Bamboo | For on-prem Atlassian users, Atlassian's Bamboo is the CI/CD solution that allows professional teams to build their CI/CD pipeline. You may be using Jenkins or other open source teams, however the deep integration points and improved build management make it the right choice for professional teams.
  • Integrate with Jira | Once you have Bamboo up and running, leverage the integration between Bamboo and Jira Software.
  • Bitbucket Pipelines | If you're an Atlassian cloud user, Bitbucket Pipelines is a new, powerful solution in Beta that lets developers build, test and deploy directly from Bitbucket. Developers have the power as they can define the environment and tests for their specific branch with YAML file style configuration.
  • Dockerize Everything! | Docker and containerization is the latest craze sweeping the IT world as teams look to deploy applications to any environment faster and easier. Check out our Docker +Atlassian webinar to learn more about how. As partners with Docker, we love to helping teams harness this cutting-edge technology.
  • Automate Testing | Automating testing with tools like Charlotte, QA Symphony, and Zephyr (which integrate with Bamboo and Jira) gives your development team an even more agile edge. Get efficent, high-fidelity testing to expedite the finding and squashing of bugs to ensure your next iteration is the best version.

Phase 4: Harmonize with Support

Once the story is shipped, the process does not end. Now it's time to keep the product working and collect that vital feedback we need.

  • Check out our webinar, DevOps with the Atlassian Suite, for a full picture of how development and operations are going to work in harmony.
  • Set up a product feedback service desk in Jira to really hear your customers and integrate directly with development teams.
  • Learn how to set up your Service Desk teams for success with our ITSM webinar.


By implementing the right DevOps tools and processes, you'll see the faster shipping of higher quality and better supported releases. As your Development and Ops teams continue to execute these lock-step processes, you get more agile by good practice. Take the steps to start implementing DevOps today by contacting us to get up and sprinting.

Topics: jira atlassian blog scaled-agile automation bitbucket bugs continuous-delivery bamboo branching devops docker distributed-version-control-system process-consulting qa-symphony sdlc selenium software sprint testing version-control-system workflows tracking continuous-integration cloud development integration it operations release-management marketplace-apps
7 min read

Seen It, Solved It: Jira Service Desk for ITIL

By Praecipio Consulting on May 4, 2016 11:00:00 AM

Growth Through Change 

"Organizations that do not or cannot evolve will not last." In the business world, change is constant and necessary, especially when it comes to meeting the dynamic needs of customers. ITIL, or Information Technology Infrastructure Library, is a methodology that helps organizations effectively manage change while putting the customer at the center of the process. ITIL prescribes processes to ensure the customer's needs and requests are handled with ease – from acknowledgement of an issue through the application and evaluation of the solution. One of the greatest values of the ITIL methodology is that it embeds continual improvement into the process. The ITIL framework can be leveraged by anyone, including non-technical teams, to better manage change and serve customers. Atlassian's fastest growing product, Jira Service Desk, facilitates ITIL adoption in an organization by encouraging traceability, collaboration, and reporting. 

As business process experts certified in ITIL, we leverage the ITIL methodology in unison with Jira Service Desk to institute best practices for our clients. Here are 5 real-world examples of how Praecipio Consulting helped our clients implement lasting organizational change by embracing key ITIL concepts of automation, visibility, knowledge base, change management and evaluation, and continuous improvement. 

Automation

"Using service automation to streamline both simple and more complex workflows of course impacts the overall efficiency of the organization... it also allows for a much better end-user experience for everyone at the company." - ITIL beyond IT: What is Service Automation & Service Relationship Management?

Problem: A major utility company powering the U.S. Eastern seaboard was manually reporting security equipment issues and coordinating with external vendors to fix the issues. This manual process was prone to errors and didn't allow for tracking of service level agreements (SLAs), which would determine which vendors were breaching their contracts. The company was using spreadsheets to track these crucial assets and their maintenance. The spreadsheet system was inefficient and created duplicate versions – leading to confusion, frustration, and waste. Furthermore, the spreadsheets could not track SLAs for Acknowledgement or Resolution for vendors.

Solution: To reduce redundancy and enforce SLAs, our experts implemented Jira Service Desk for the major utility company. By replacing their spreadsheets with Jira Core and Jira Service Desk, we helped them add a level of automation to their workflow. This reduced waste of time and resources, allowed for better communication with third-party vendors, and created a clear path for escalation. The custom configuration we created for the company maintained their security, while also allowing vendors to be a part of of the conversation. Furthermore, reporting features from both Jira Core and Jira Service Desk allowed for a central point of truth. The utility company could check the status of service tickets and see how well vendors were adhering to their SLAs. Through the process of improving their security equipment reporting and vendor coordination, the company found other areas of improvement and have chosen to continue working with us to maximize those workflows. 

Visibility

"It can be very difficult to know the health of your service desk, run reports, and find way to improve your support if you don’t have the right data." - The ABCs of Jira Service Desk: measuring success

Problem: A major U.S. waste management company wanted to adopt a more structured reporting system, replace an old enterprise software application, and incorporate the ITIL framework into their organization. The company's goal was to standardize tools in order to improve communication and rally around a consistent project management methodology. The waste management company desired a suite of tools with the ability to integrate functions across IT service areas, leading to better service for the end customer.

Solution: In addition to implementing several other Atlassian products, our experts helped the company leverage Jira Service Desk to achieve their business goals. We helped them create a central application with the ability to distinguish request types through a structured workflow. This included a more robust user interface to better triage issues and send them to the appropriate teams. The ability to categorize requests and label them with levels of urgency allowed the company to have better reporting, leading to improved enforcements of SLAs. 

Knowledge Base

"[A knowledge base] gets [customers] the help they need at the speed they’ve become accustomed to – i.e., in the time it takes to swipe around on their phones – and it frees service desk agents from stressing out while anxious customers wait on hold or answering the same question over email for the 10th time this week." - 4 tips for getting started with knowledge management

Problem: A large, private U.S. university wanted to revamp an old software application and replace it with a more robust and dynamic knowledge base. The university's goal was to increase usability for both their students and faculty regarding technical and campus-related questions, deflecting tickets by providing requesters with FAQ's and other resources to help them self-serve to find their answers. 

Solution: Our experts helped the university leverage Jira Service Desk and Confluence to achieve their goal. Combining Jira Service Desk with Questions for Confluence (a Confluence add-on that provides a knowledge base inside the already powerful wiki tool) allowed the university to implement a centralized knowledge database. Jira Service Desk allowed for better help engagement using queues and other helpful functionalities. Questions for Confluence empowered external users to help themselves by accessing a database of pre-answered questions, without tying up service desk agents with redundant problems.

Change Management and Evaluation

"Listening to your customers is the single most important thing you can do for the health of your company." 5 tips to transform your IT team from zero to superhero

Problem: The largest provider of support services to general and multi-specialty dental groups in the United States needed the ability to receive and respond to client feedback in addition to handling client issues. They did not have a clearly defined process for patients to interact with the organization and to raise issues. Their marketing team was searching for a new software tool that would manage feedback in a way that led to issue resolution and change management. The team's ideal tool would be able to enforce and report on multiple SLAs through issues submitted via the company's public website.

Solution: Our experts helped the dental corporation adopt Jira Core and Jira Service Desk to manage issue tracking and change management. With Jira Service Desk, the company was able to cleanly sort through client feedback and create a workflow to address issues that arose. Beyond managing client feedback, the dental corporation also used these tools for clinical tasks, billing, and other activities that needed life cycle tracking. In addition to tracking, the Atlassian tools helped the organization evaluate the effectiveness of their changes and quantified the improvements made – empowering all teams, not just marketing, to better serve their customers. 

Continuous Improvement

"With a single-product approach, configuring an SLA or modifying a workflow is easy, because they share core processes." How Jira Service Desk approaches ITSM 

Problem: A major U.S. insurance company was using three different software applications for code management, issue tracking, and service desk management – leading to inefficiencies and miscommunication. Their use of three separate applications resulted in duplicate tickets and the inability to enforce SLAs across the organization.The insurance company wanted to improve these processes and embrace ITIL's practice of continuous improvement. 

Solution: Our assessment encouraged the company to adopt a single application, Jira Service Desk, to provide a single source of truth. With Jira Service Desk, there was a common point of collaboration for issue management. This reduced duplicate tickets and saved valuable time and resources. Leveraging entities, workflows, and issue linking, we helped the insurance company align their processes to make reporting and enforcing SLAs easier, more efficient, and more effective. By strengthening their ability to track what changes are needed and to act upon those needs, we helped them develop a cycle for continuous improvement.  

ITIL for One, and ITIL for All 

"Just because one service desk streamlines the IT and service departments, it doesn’t mean that other teams can’t also benefit from them." - 5 tips to transform your IT team from zero to superhero

These real-world examples from our clients highlight how ITIL and Jira Service Desk can help organizations evolve and change – without the growing pains. ITIL concepts of automation, visibility, knowledge base, change management and evaluation, and continuous improvement aren't just for IT teams. These powerful ideas also provides immense value to other parts of any organization, technical and business teams alike. At Praecipio Consulting, we excel at leveraging the ITIL methodology and Jira Service Desk to help organizations do what they do better. Want more proof? Contact us to learn how we can help your organization evolve and do your best business. 

Topics: jira atlassian blog scaled-agile automation business confluence process standardize workflows traceability collaboration continuous-improvement integration it itil itsm jira-service-desk operations reporting white-paper
2 min read

SAFe Cheat Sheet: A Guide to Scaled Agile Framework

By Praecipio Consulting on Feb 23, 2015 11:00:00 AM

No matter the size of your organization or your industry, the end game of any company is to deliver the highest quality product to customers at the greatest market value, with the lowest cost of production. This school of thought drives the Agile methodology of software development, pushing for faster delivery of better products with the least amount of risk, and has fueled the scalable Agile solution for enterprise-level organizations: Scaled Agile Framework (or SAFe). Operating under the principles of Agile development, SAFe aligns the development and initiatives of all levels of the enterprise company- from agile teams to executives- for accelerated value delivery at a reduced risk. Leveraging short feedback cycles organized into sprints and release trains, the cost of deployment decreases as deliverables have clearer direction and requirements to ensure a better fit for purpose. 

How does Atlassian support SAFe?

What are the core values of SAFe?

 

How does Atlassian support SAFe?

The Atlassian product suite was created (and is continually innovated) to support best practices in the Software Development Lifecycle. To that end, the use of products like Jira Agile, Confluence and Jira Portfolio integrate to bring maximum traceability to every release, enabling teams to hit their deadline and their budget with the highest quality product. With Atlassian, you unlock the power of SAFe, leveraging Jira Agile, Confluence and Jira Portfolio to achieve the following objectives (and much more): 

Want to learn more about SAFe?

Ready to learn more about how Scaled Agile Framework brings best practices and greatest results to your enterprise organization? As Atlassian Platinum Enterprise Experts, we at Praecipio Consulting are here to help! First, check out our recent webinar on SAFe, Agile in the Enterprise, presented by Senior Solutions Architect, Certified Scrum Master, and soon-to-be SAFe Program Consultant Amanda Babb to get a more complete introduction to implementing Agile practices at the Enterprise level. Next, contact Praecipio Consulting to begin introducing SAFe to your company. We can assist you with anything from Atlassian product licenses, implementations and configurations (to get you the right tools for the job) to customized consultations and trainings on SAFe. 

Deliver your highest quality product and the lowest cost of deployment with SAFe, Atlassian and Praecipio Consulting!

Topics: jira atlassian blog scaled-agile best-practices confluence enterprise sdlc jira-software safe marketplace-apps
2 min read

Here Comes the Product Owner: Wedding Planning with Atlassian

By Praecipio Consulting on Feb 13, 2015 11:00:00 AM

When Praecipio Consulting Senior Solutions Architect and Certified Scrum Master Amanda Babb got engaged over the new year, her first thought (after "Yes, I'll marry you" of course) was that this was an affair for the Atlassian tool set. With family members on both coasts and Amanda and her fiancé residing in Texas, she knew Atlassian would be the trick to best practices in MDLC (Matrimony Development Life Cycle). "There was never a question." says Babb. "From the moment we got engaged, I got a Cloud instance." Establishing a Kanban board that will take Amanda and her family from gathering information about venues to the nitty-gritty tasks like purchasing the cake slicer, this Scrum Master feels confident in an on-time, on-budget release of an October 2015 wedding.

 

Amanda Babb, Sr. Solutions Architect & Bride-to-Be

With Jira, Jira Agile, Confluence, and Team Calendars in her arsenal of planning tools, Amanda began on-boarding her family, including Project Stakeholders, Mom and Dad. After spending time showing her parents how to use the tools, they were able to begin collaborating and creating tasks. "The first thing my dad did was create a bug in Jira called Fat Elvis or Skinny Elvis and how many," Babb happily shares, noting that they have ultimately decided not to have their wedding officiated by an Elvis of any kind. Aside from fun with naming conventions, her family has enjoyed the ease with which they can view and add to wedding details, as often these large-scale affairs get bogged down with endless email chains, binders and internet bookmarking. With Atlassian, Amanda is able to share everything from a budget table for tracking deposits to multiple wedding registries and even bridesmaid dresses. Like most Scrum Masters, this bride's biggest "blocker" is adoption, often having to remind her family that, "it's in Confluence!"

So what does Babb's fiancé Doug think about his bride-to-be's planning with Atlassian? "He likes that it's streamlined communications." Babb reports. "Since we have opposite work schedules, it makes it easy for him to respond quickly. All I have to do is mention him in a comment!" Once Amanda and Doug have become husband and wife, their Atlassian instances will continue to play a role in their marriage. Babb intends to continue using the products for household projects, increasing transparency and communication between the couple leveraging a shared knowledge base. 

On this Valentine's Day, Praecipio Consulting wishes Amanda and Doug (along with all the other Atlassian lovers out there) all the best! May your collaborations be harmonious, your issues quickly resolved and each of your iterations better than the last.

 

HAPPY VALENTINE'S DAY!

Love,

Praecipio Consulting

Topics: jira atlassian blog scaled-agile best-practices calendars confluence kanban jira-software
2 min read

Jira Portfolio Cheat Sheet

By Praecipio Consulting on Jan 13, 2015 11:00:00 AM

For projects big or small, Jira Portfolio helps you plan it all! With the ability to pull work in progress in from Jira or push the work breakdown structure into Jira, Portfolio makes managing projects a breeze. With a little set-up and some good old-fashioned planning sessions, your organization can quickly view release schedules, track estimates and actuals to business strategy targets, and manage resources in one place. 

Setup is key with Jira Portfolio. Simply choose your plan type, then work right to left: Configure, Reports, Releases, People. Once you have the business strategy and available resources, then populate your Backlog. Importing an existing set of issues from a saved filter in Jira requires only a few clicks. Or, if you prefer, create your plan and push individual initiatives, epics, stories, and defects into a single project or multiple projects. For those that are truly Agile, plan and push Epics into Jira, then allow the teams to develop and estimate Stories. Synchronize your plan and you're able to predict releases and inform stakeholders.

Push 

Dial in your plan before work begins. Add level of effort estimates and link Epics and/or Stories together to create dependencies. Then let Jira Portfolio inform you of a missing skill set, plan your sprints, or predict the release schedule. 

Pull

Mitigate risk and communicate with stakeholders with ease. Importing in-flight work provides stakeholders with more accurate release schedules based on current work efforts. Mitigate risk by seeing how new work and dependencies affect the overall schedule. Flex resources across teams to fill skills gaps. 

Choose 

Which of the five key capabilities of Portfolio Project Management are you trying to manage: change, risk, resource, pipeline, or financial? Let the capability determine whether a push strategy or a pull strategy works best. The answer may be to use both strategies in the same plan. 

Learn more about Jira Portfolio and get an in-depth demonstration in the tool with our Introduction to Jira Portfolio webinar.

Topics: atlassian blog scaled-agile best-practices integration marketplace-apps
6 min read

Top 12 Jira Questions of 2014

By Praecipio Consulting on Dec 29, 2014 11:00:00 AM

On December 3rd, we went where no Praecipio Consulting webinar has gone before: We answered your Jira questions live! Between pre-submitted questions from webinar registrants, online Praecipio Consulting followers, and real-time queries from viewers, our resident Jira expert Christopher Pepe fielded the questions you most wanted answers to. We were thrilled by your response to the call for questions and feel the answers to be so helpful that we decided to share them with the Jira-using public at large! From new Jira users to experienced technical leads, here are the top Jira questions and answers for your inquiring minds.

 Q: We have yet to find a way to enter our estimates in a manner that gives us valid burn-down charts on agile projects and would like advice. The process we use is as follows:

  • Issues are entered into Jira (into the backlog) with a high level estimate.
  • When we get into a sprint, we'd like to create sub-tasks that reallocate the hours in the original task (e.g., a story is entered with 40 hours, then the team determines that there will by 6 hours of BA work, two 8 hour development tasks, 8 hours of QA, 2 hours of documentation, and some PM work that can be logged against the main story).

Presently, we see the subtasks showing as additive and in the scenario above it ends up looking like there are 72 hours. How would you recommend that we solve this?

A: (6:04) The way Jira handles time tracking, all of your time is rolled up, so your time is double-entered. Take the original hourly estimate, delete from parent ticket (as it misses the intent of the time-tracking) and either a) don't include time estimates in the original story or b) make your stories into epics and give all sub-tasks (tests, bugs, etc.) time estimates that roll-up to give a more accurate picture of time tracked. It's also worth noting that, as people are generally not the best at estimating time, one could utilize story points to track time and establish velocity across your Agile team. For example, this new feature will take x amount of time based on x amount of sprints (compared to previous tasks of the same type). 

Q: Can we delete Statuses from already published Workflows? 

A:  (9:26) Historically no (and I believe that's still the case). You have to copy the workflow and modify, or rebuild. Then map it back to your workflow scheme, deleting the status.

Q: We are creating different issues-types for different entities, User Story, Task, Test, Bug, etc. Does having these many different issue types create complication? Is it convenient to keep track of these issues? For Ex. 1 User story might have 3 Tasks, 2 Tests and 4 Bugs, isn’t that creating linking issues or traceability issues?

A: (10:42) This is a big question and the answer is really our whole business at Praecipio Consulting, as we seek to model your processes to Jira for connectivity across all systems. Creating an efficient data model in Jira can be challenging. You're taking the right approach in thinking about how to model your data. I can't advise you without knowing more about how you operate, but recommend you think about making your Stories into Epics in Jira Agile, and then add your Tasks, Tests, and Bugs to the Epic. That really simplifies the issue linking.

Q: Is there a quick way to see an issue's priority when looking at it on a board besides filtering it?

A: (13:54) Yes, the priority is shown by its icon. Hover over to see what it is. Agile packs a lot into a little space

Q: Is there a way to automatically move an issue to a different workflow when the issue type changes. Like any Post-Function?

A: (15:29) Jira will automatically do this. It means that your Workflow Scheme needs to have different workflows configured for the issue types. If workflows have different custom fields, Jira will force you to go through a mapping stage. No post-function is needed!

Q: What options for Pass Through Authentication exist? Are Add Ons the most often used method? Are there other ways of doing this without paying hefty prices? 

A: (17:44) Add-ons are really the only way. There are REST authentication resources so if you can control intercepting the username and password you can hand them off to the application, but if your mechanism isn't HTTP based its hard to get the token in the users browser. Atlassian's Crowd is a popular choice, providing a single-sign on platform for authentication through multiple avenues.

Q: Beside custom fields, what other system configuration items can cause poor system performance? Permission schemes? Notification schemes? If so what are some best practices for these? 

A: (20:35) The short answer is: lots of schema. Custom fields, complicated workflows and the like can contribute to slower performance. Finding bottlenecks is challenging. Many layers of monitoring is the best approach (Maybe you don't have a big enough thread pool or your disk access speed is too slow.) to make sure you can see what the JVM is doing. New Relic offers simplified yet robust monitoring capabilities for these purposes 

Q: When entering a custom field, what is the best practice for configuring the field for specific issue types/projects versus a global context (all issue types/projects)? We have custom fields that will only be used for one or two issue types and a subset of projects, but we have configured them as all issue types/all projects. Is there a downside to this configuration?

A: (24:35) I encourage new admins (and even seasoned ones) to use global context and focus their energy on designing screens and related schema to get a project to operate as expected. Context makes it hard to track down why a field isn't showing up or some odd behavior that's occurring.

Q: How can I make an issue editable when the status is already closed? Also, I am unable to add a transition from a closed issue to another status. 

A: (27:25) You should be able in the workflow editor to create a transition from closed. Jira may be blocking this, since closed issues are uneditable. The default workflow that comes with Jira, if copied, wouldn't allow you to edit a closed issue- so the properties associated with the workflow are copied too. You'll need to edit your custom workflow and delete this property or create your own. 

Q: Can we add more fields in ‘Test’ Issue-type, like currently there are Test Step, Test Data and Expected Result. Can we include columns for Module, Test Scenario, etc.?

A: (30:18) Yes you can add more fields by modifying the Screens and maybe Field Configurations. You may need to create your custom fields first too.

Follow-up: (in the Zephyr panel shown in the issue) No, that is not configurable. You should tell Zephyr that you'd like it to be.

Q: Can you fix the Jira header to stay at the top of the page when scrolling?

A: (37:26) There isn't a way in the Jira UI, but if you go and inspect the element, you will find that the header bar is just a div (and stuff inside it) that you can target with CSS or Javascript to fix the hold. In Javascript, present it to Jira by creating an add-on and install. This helps you control the context and action. If you only want it on issue view, you'd add the Javascript to the field configuration. Having this function as an add-on helps future system admins know that it's an individual, customized feature that can be found and identified.

(If you listen to the webinar audio, you also hear our Jira Expert cat weighing in on the subject as Christopher Pepe translates.)

Q: What are the benefits of a federated Jira instance?

A: (41:06) Atlassian has several resources on the benefits of managing multiple instances through federating. The only places where we really see people federate instances is in industry mandates (ex. industry permissions for viewing data) or when different groups within an organization need individual ownership. In this case, you'd create application links between the two instances to allow reporting from one instance to another; the pitfall is that you can only get results from one instance at a time. 

When it comes to Jira, there is so much to know and learn! At Praecipio Consulting, we bring our Atlassian expertise to Jira and the entire product suite through our webinars, trainings and full service offering. Still have Jira questions or want to apply our experience to your instance? Find out how we can answer your questions and get you your best instance by contacting Praecipio Consulting. 

Topics: jira blog scaled-agile best-practices training configuration consulting-services integration
5 min read

Paying for Mistakes: The Cost to Fix a Software Defect and How to Avoid It

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

In 2002, a study by NIST reported the U.S. Economy spent $59.5 billion annually fixing software defects. Less than a decade later, Cambridge University found the cost to have risen (in 2007 to 2011) to a global cost of $312 billion per year. With technology becoming an ever-growing presence in our society- from smart phones to smart cars- the pressure to build infallible software is at the forefront of companies' minds. A software defect, which can be caused by omitting even one character in pages of code, can have far reaching repercussions.

These kind of non-conformance expenditures spent repairing software defects impact your Cost of Quality, costing your company profit and maybe even your professional reputation. Customer satisfaction fuels the reputation of businesses, and even a small software defect can translate into billions of dollars in lost revenue when people become frustrated over non-functional or mis-operating products. 

"To err is human." So, how do we reduce software defects caused by user error?

With the Atlassian product suite, you have security with well-documented, well-reviewed process capabilities- You just have to begin with the end in mind. This should be the mantra for any software development effort. To start, gathering clear requirements in Confluence will allow a team to have a single point of truth when in the early stages. Developers, QA, Stakeholders, Product Owners, Scrum Masters- everyone should be involved in the process. Before kicking off a new project, ask yourself:

  • What are we trying to create? (e.g. a new feature, an enhancement to an existing product or offering, a cleaner UI)
  • Why are we doing this and why is this a need? 
  • Who are the end-users and how will they be using the product?
  • Where in the application will this sit? (e.g. Is it middleware? Is it database transactions? ) 
  • When can we release this? 

These 5 questions can get ideas flowing. Recommendations regarding this phase include creating user profiles to help determine acceptance criteria. In Agile, the creation of user stories helps here too. By beginning with the end in mind and leveraging Confluence, there is no question as to what the expected function of the product is and what is considered done.

Once the requirements have been reviewed and agreed upon, now is where we start tasking. Within Confluence, selecting text and creating Jira tickets is easy once the applications are linked. These issues should be created with the mindset that after an iteration, the issue is complete and potentially shippable. 

Fail fast... then fix it!

These checkpoints in the SDLC process have the opportunity to make or break a deliverable's release, reducing extra costs to the company. Depending on the phase in which the defect is introduced, and how long it takes to catch, the losses can quickly add up. Finding an architecture issue in the construction phase will cost 10 times as much than if it were caught in its starting phase. A requirements issue found in post-release can cost up to 100 times as much to fix than if identified from the beginning. How can you ensure you're shipping a defect-free product that won't cost your company profit or credibility?

Take a moment to think about what potentially shippable means. These items have been developed, tested, re-tested, merged, and are ready to meet the outside world. With a click of a button in Stash, these items can be merged with the Master Branch and are now available for use. But to get to this point, the Scrum Team must have had some way to develop and test and merge and flag issues without affecting the Master Branch or Production System. Here's where integrating Jira, Bamboo, and Stash come in handy. You can create a feature branch, develop against it, and merge it with everyone else's branches to ensure there are no defects. Bamboo will see the new branch and build. Fail Fast. Within a short period of time, the team can see what they did (or didn't do) to make sure the units are potentially shippable- troubleshoot, fix, then merge again. When a build fails or a branch doesn't merge, defects can be filed in Jira and added into the Sprint. 

Accidents will happen.

Even with multiple checkpoints in place for accuracy, a user may spot a defect. In this case, leveraging Jira Service Desk can provide immediate feedback to customer service regarding the problem. By providing a way for customers to communicate their issue immediately, you are able to respond to their complaint- preserving the reputation of your business and gaining important information on what went wrong (so you can avoid it next time). Everybody makes mistakes- it's how (and how fast) you fix them that leaves a lasting impression with customers. 

Limit Defects, Avoid Loss, Increase Productivity

With the Atlassian product suite, user errors that create defects in software are identified and weeded out before your deliverable ships, allowing you to continually increase profit and get solid results. Best practices in robust tools like Jira, Confluence, and Stash help your organization achieve traceability and thorough documentation through continuous integration. Leveraging administrative and reporting functions, including permission setting and customized workflows, you can track project development and identify blockers in real time to mitigate profit loss. Atlassian further stacked their product line to increase visibility and keep deliverables on time and defect-free with their new offering, Jira Portfolio

Million dollar profit or million dollar loss? The omission in a single character in one line of code can be catastrophic to your deliverable, so early detection is paramount. Atlassian helps you catch those bugs before they turn into an infestation and with our extensive knowledge of best practices and process optimization around the product suite can maximize your defect defense. Learn more about how Praecipio Consulting can help you avoid those costly errors. With the money you save, you can treat your team to an Atlassian training course!

Topics: blog scaled-agile best-practices bitbucket confluence process-consulting roi consulting-services jira-service-desk marketplace-apps
2 min read

Jira: Not Just for Software Development

By Praecipio Consulting on Aug 17, 2012 11:00:00 AM

Jira’s an issue tracking application, but its core flexibility and strengths mean it can become much more than a tool limited to a development group. Jira’s incredibly adept at helping teams track and accomplish tasks. Jira also has a masterful ability to manage life cycles - and it’s found great success in numerous use cases.

Use Cases

The following use case guides are meant to explain a bit of the details related to using Jira for a specific use case. The info you’ll find in here highlights much of what we’ve learned from working with clients in a variety of different industries, as well as our internal expertise and use of Jira.

For each of these use cases, we’ll attempt to highlight:

  • Particular Jira functionality specific to the use
  • Related plugins we’re aware of
  • Customization and tweaks
  • …and sometimes a sample file to help get you started

General and Non-Software Uses

Agile Software Development

Project Management

HelpDesk / Support / Trouble Ticketing

Test Case Management

This can be done by using either of the following approaches:

Requirements Management

Change Management

Topics: jira atlassian blog scaled-agile austin automation business efficiency enterprise issues management process services technology value tracking change cloud collaboration computing continuous-improvement incident-management information integration it itil itsm operations
1 min read

Lean Thinking- Reducing Process Generated Waste

By Praecipio Consulting on Jun 18, 2012 11:00:00 AM

Lean thinking allows organizations to determine value, and organize their value creation processes in a specific sequence. This fundamental understanding of the value stream allows organizations to dived their work processes into:

  • Value-adding activities
  • Required non-value-adding activities
  • Non-value-adding activities

It’s important to note that while organizations can specify an associated value with a process; value’s inherently determined by the consumer – your organization had better have a clear understanding of what that is.

Lean thinking also affects the flow of your production processes by emphasizing a continuous product flow, pulled through by customer demand – ensuring that nothing’s built until it’s needed, and what’s built is in fact needed by its end-user. As Lean thinking’s applied to your specific business model you’ll  inherently perfect your product through the constant process of identifying and removing waste.

Lean + Agile = Better Business Practices

We prefer to look at Agile as more than just a methodology, but also as a way businesses can reduce process – generated waste and non-value-adding activities.

Think of a value system instead of a process. Software development’s too difficult to waste time pouring over things that don’t matter, and it’s extremely inefficient for the organization at hand. From this viewpoint we can apply lean thinking to Agile development.

To effectively understand the meaningful roles these approaches can have, we must first examine their application. From this point of view, Lean represents a set of principles that help guide our ideas and insights about Agile. Lean thinking should be viewed as a set of value-maximizing principles that don’t change over time, and Agile development as an application of principles to a particular situation. Agile principles are specific to each environment and should change to fit the task at hand. Here it’s easy to see how Lean thinking concepts expand upon and improve the framework of Agile methodology.

Topics: blog scaled-agile automation bpm business efficiency management optimization practices process process-consulting value continuous-improvement lifecycle operations
3 min read

The ABC's of Agile

By Praecipio Consulting on Jun 7, 2012 11:00:00 AM

The Agile school of software development’s currently one of the most accepted methodologies for improving productivity. Targeted mainly towards IT managers and CIOs, Agile methods promote an interactive approach which have the ability to help flatten your organization’s cost of change curve.

The Manifesto for Agile Software Development was first introduced in 2001, and outlines the foundation of Agile in twelve principles:

  1. Customer satisfaction by rapid delivery of useful software
  2. Welcome changing requirements, even late in development
  3. Working software is delivered frequently (weeks rather than months)
  4. Working software is the principal measure of progress
  5. Sustainable development, able to maintain a constant pace
  6. Close, daily co-operation between business people and developers
  7. Face-to-face conversation is the best form of communication (co-location)
  8. Projects are built around motivated individuals, who should be trusted
  9. Continuous attention to technical excellence and good design
  10. Simplicity- the art of maximizing the amount of work not done- is essential
  11. Self-organizing teams
  12. Regular adaptation to changing circumstances

Cost of Change Curve

First introduced by Barry Bohem in 1981, the cost of change curve represents the exponential increase in cost as it relates to making a change during the normal development phase of a product. This means that as your product moves farther down the developmental pipeline it becomes more costly to make changes and remedy errors.

That’s a good argument for Agile since it ensures you leave the current production phase with a product that’s as close to perfect as you can make it – particularly because Agile methodology calls for testing and up-front integration which translates to rapid production and minimal initial design. Since the test code’s written before functional code and automated test suites are built around the evolving code, developers are allowed to make rapid and aggressive changes.

The ability to make these changes is one of Agile’s key features and the result is a reduction in the amount of product errors late in the development phase, reducing the cost of change. Even if your organization enjoys a rather flat cost of change curve, Agile ideals can be applied to reduce the cost of change throughout the software life cycle.

Scrum

Scrum’s another widely accepted approach to implementing the Agile philosophy, which includes both managerial and development processes. This approach relies on a self-organizing, cross-functional team supported by a scrummaster and a product owner. Scrum makes your organization Agile by ensuring quick progress, continuously creating value, and by keeping projects on track. The most important concepts of Scrum are:

  • Product backlog - A complete list of requirements that are not currently in the product release. Typical backlog items include bugs and usability/performance improvements.
  • CI - Also known as continuous integration; allows for scrum teams to continuously integrate their work. This will often happen on a daily basis.
  • User story – Describes problems that should be solved by the system being built.
  • Scrummaster - The manager of the Scrum project.
  • Burndown chart - The amount of work remaining within a sprint, i’s updated daily, and also tracks progress.
  • Sprint backlog - A list of backlog items assigned to a sprint, but not yet completed

Kanban

Kanban means visual board – and that’s just what it is, a development process that revolves around a board to manage works in progress (WIP). A Kanban board includes “lanes,” each denoting different phases a project might take. It moves WIPs across the board and deploys them into production when they reach the done column. Since Kanban development practice revolves around WIP management each state of progress is limited to a set number of projects. Organizations able to leverage this high frequency of delivery typically enjoy a large financial benefit.  The most important concepts of Kanban are:

  • Swim lanes - The horizontal lanes of a Kanban board represent the different states in which a WIP or task can exist.
  • Backlog - A list of backlog items awaiting deployment, but not yet completed.
  • Stories – A particular user need assigned to a development team.

Atlassian and You 
Atlassian specializes in robust, easy-to-use, affordable internet applications that seamlessly integrate Agile and Lean methodology  with your business processes to support your organizational goals.  Simply put, success breeds extraordinary performance – and  extraordinary performance breeds success. Atlassian’s suite of products are designed to boost your organization’s performance by providing tools that are easy to use, allowing your business to build its own solutions.
Topics: jira atlassian blog scaled-agile central business confluence efficiency issues management process process-consulting scrum technology texas value tracking change continuous-improvement greenhopper incident-management information it lifecycle operations
8 min read

Jira: Best 11 of 2011

By Praecipio Consulting on Dec 30, 2011 11:00:00 AM

2011 was an epic year for the Jira Family including two massive releases, the launch of a new product – Atlassian Bonfire – and the introduction of Atlassian OnDemand just to name a few things. Atlassian’s Ken Olofsen had a tough time whittling this list down to just 11 things, but “did his best” to use a “traditional 4-4-2 formation“ (see primer on jersey number relevance) to highlight his “Jira Best XI” for 2011. So, here’s Ken:

The Keeper

For anyone who’s played the game, you’ll know that goalkeepers are a special breed and sometimes a bit looney – no offense to Michael Knighten or any other ‘keeps out there.

Keepers are typically the older veteran who is wildly popular with both the team and the fans, and for our team this is no exception:

No. 1 – User Timezones

JRA-9 was not only the oldest, but also the most voted feature (454 votes), we added to Jira in 2011. And we didn’t just add timezones support, we took timezones to the next level by making it clear for distributed teams to see when other teammates are either sleeping or on the job.

The Defense

A solid foundation is the key for any winning team, so it was important for the Jira team to bolster the back line and build a platform for success:

No. 3 – New Installers / Upgraders

At the heart of the back four we have the new installers for Windows and Linux. Not only did we add simple way for administrators to setup and configure Jira, we inculded an unattended installer and automated upgrader for pain-free Jira deployments going forward. On top of that, we even provided a self-updating plugin manager, database config tools and enhanced importers.

 

 

The other anchor in defense, Application Links are the glue holding all your Atlassian tools together providing aggregated activity streams and key integration capabilities.

For example, connecting Jira to Confluence allows quick issue creation and linking of Jira issues from Confluence. In fact, with the recent release of Confluence 4.1 Jira issue links will instantly autoconvert in the Confluence editor:

 

No. 2 – Admin Overhaul

In addition to adding LDAP & Active Directory support, centralized user management, and a new visual workflow designer; we revamped the Jira Administration interface to make it easier than ever to manager your instance. A new project-centric administration screen makes it simple to see how each project is setup, so you can make changes quickly.

 

No. 4 – Jira on the Bookshelves

Four new books hit the shelves this year providing an excellent array of resources for Jira admins and plugin developers:

 

          

The Midfield

As the engine room of the team, the midfield is where the heavy lifting happens. We added a number of key features and enhancements to make Jira even more powerful than ever.

No. 6 – Visual Workflow Designer

Jira’s versatility is rooted in it’s powerful workflow. That’s why I was personally very excited to see the acquisition and integration of the Visual Workflow Designer making it easier than every to create and modify workflows on the fly:

 

 

 

No. 7 – Activity Streams

No one can quite “bend it like Beckham”, but Jira Activity Streams are incredibly flexible and configurable.

Each team member can dial in their personal activity streams to keep tabs on the specific systems, people and activities that are important to them. They can also vote, watch and comment directly from their dashboard, or drop custom streams into their favorite RSS reader.

No. 8 – JQL Search Change History

Jira Query Language set the gold standard for advance search within issue trackers. In 2011, JQL blossomed into the prototypical “two-way player” by adding historical search capabilities. Use the “WAS” operator on everything from status to assignee and uncover changes made “BY” certain people anytime in the past. Great for building killer dashboards, ad hoc reporting or just sleuthing around Jira.

No. 10 –  Issue Creators

The spark at the center of midfield is the “creator” who gets it all going. Jira has no shortage of ways to create issues – the web, your browseryour IDEemailremote APIs, applications like Confluence, and more. In 2011, we introduced Jira Mobile Connect for collecting user feedback and crash reports from your mobile apps and the Jira Issue Collector for creating issues from your website:

 

And just wait, 2012 promises even more!

The Forwards

Leading the attack, the forward line is always part of the action and usually the ones making the real difference. In our team, the strikers come from our popular add-ons, GreenHopper and Bonfire:

No. 11 – Rapid Board

After spending a few months in the “GreenHopper Labs”, we finally unveiled the Rapid Board. Based completely on JQL, Rapid Views introduce a new way for agile teams to view issues in Jira and work through their daily tasks.

 

No. 9 – Session-Based Testing

Atlassian Bonfire is the newest member of the team and is already blazing a trail for exploratory testing. We all rely heavily on automated testing, but with the growing emphasis on usability and user experience, many software teams are spending more time manually testing applications.

Bonfire’s session-based testing evolved out of our own need for better tool for managing our agile testing efforts.

 

Off the bench

 

Every strong team needs the support of a deep bench, and ours knows no limits:

No. 12 – The Jira Ecosystem

This year the Jira ecosystem exploded, bringing the list of Jira add-ons – plugins, applications and integrations – to over 400!

No. 14 – Slick New Emails

Email notifications got a nice refresher ensuring we find out exactly what happens, as it happens, on any device.

2012 and beyond

The Jira team has been working very hard to make all of our customers, new and old, as happy and successful as possible. And with Jira 5 on the horizon, 2012 promises to be even more exciting for the Jira Family.

On behalf of the entire Jira Team, I’d like to thank you for being part of our success. Happy New Year!!

 

PS. Don’t forget to check out the Confluence Starting XI for 2011. While no match for this Jira team, it’s quite impressive as well.. 

Topics: jira atlassian blog scaled-agile twitter cloud development greenhopper email-notifications marketplace-apps
3 min read

Rapid Board for Kanban

By Praecipio Consulting on Oct 19, 2011 11:00:00 AM

GreenHopper 5.8 is now available, delivering a huge win for everyone: the new Rapid Board.

A major innovation for GreenHopper, the Rapid Board’s a flexible new board for managing and reporting on work in progress. The Rapid Board also provides multiple project support, which alone satisfies a whopping 255 votes - the most requested feature in GreenHopper’s history!

What’s the Rapid Board?

The Rapid Board provides a new way to view issues in GreenHopper by creating Rapid Views.  Creating new Rapid Views is simple:

  1. Save a Jira search
  2. Layout status columns
  3. Set Swimlanes & Quick Filters

This brilliant simplicity calls upon the most powerful search in issue tracking: Jira’s Query Language (JQL). The power of Jira’s advanced search is behind every aspect of the new GreenHopper Rapid Board. The Rapid View, horizontal Swimlanes, and button Quick Filters are all based on JQL search parameters:

This means large teams can collaborate on a single Rapid View, while individuals can use Swimlanes and Quick Filters to see just the issues that matter most to them.

Work Smarter

The new Rapid Board has several smart features in the background. Atlassian’s focused this first release of the Rapid Board on Kanban-specific features, and will continue to work on features for Scrum and all types agile teams as the Rapid Board evolves.

  • Kanban presets: an Expedite swimlane, 3 Quick Filters, default columns (To Do, In Progress, Done), and issues ordered by Global Rank.
  • Permanent links mean ‘what you see is what they get’ when emailing or IM’ing URLs – and include not only you exact view, but also the selected issue or report.
  • Keyboard shortcuts let you perform any issue operation, including selecting an issue and ranking actions, without touching a mouse.
  • Drop zones indicate the available transitions when moving an issue.
  • Column headers stay with the board when scrolling down the page, so there’s no need to scroll back up to find information or take action. 
  • Issue cards have gotten an uplift: avatars show up indicating the card assignee, and the number of days in current status are indicated by dots across the card.
  • Columns can have both a min and a max constraint: limit the amount of work in progress (WIP) for each column to keep the team moving things along.

Keep Issues Moving Across the Board

We’ve added a new Control Chart to show the mean cycle time and trends. Control Charts, along with the “time in status” dots across issue cards, help teams spot outliers and understand which issues spend a long time in flight. 

The Rapid Board views are also available as gadgets, so it’s easy to display this information on a Jira dashboard or a Confluence page. GreenHopper 5.8 is a huge step forward in understanding your teams work andcommunicating priorities and progress to the rest of the org. If you aren’t yet using GreenHopper or you want to see the new features in action, check out the short overview video.

Upgrade Jira & GreenHopper

GreenHopper 5.8 is available today, you’ll just need to upgrade to Jira 4.4.3 to take advantage of all the great new stuff! After you upgrade Jira, search your Jira plugin manager for the latest GreenHopper release.

Topics: jira atlassian blog scaled-agile kanban upgrade control greenhopper jql rapid-board
1 min read

Christopher Pepe to Speak at DevChatt

By Praecipio Consulting on May 24, 2011 11:00:00 AM

Christopher Pepe, head of our Atlassian practice, will travel to Chattanooga this weekend to present at DevChatt – a tech-focused conference for software developers and technology enthusiasts. His presentation – “Jira and Greenhopper for Agile Development” – will focus on how plugins are greats ideas but not the only ideas, how there aren’t any silver bullets, and how to use Greenhopper more effectively for Agile. Be sure to check it out – Christopher will knock your socks (or flip-flops) off.

Jira and Greenhopper are customizable Atlassian tools used for a variety of things. They excel at issue tracking and task/project management. If you’ve never heard of Atlassian, you should know they recently received a $60 million investment from Accel Partners, the same folks who invested in the likes of Facebook and Etsy – meaning it’s likely Atlassian will become a household name in the technology scene in the next five years.

DevChatt’s Chattanooga location is quite relevant in light of the city’s recent achievement: the fastest internet in the US. In 2010 the Electric Power Board (EPB) of Chattanooga released one of the nation’s first fiber-optic SmartGrids, giving commercial and residential customers 1GB-per-second internet speeds. Because of this, there’s a wealth of opportunity and entrepreneurial spirit in the up-and-coming Tennessee city – making it the perfect place for a collaborative conference like DevChatt.

Follow Christopher on Twitter, or meet him in person this weekend. Hope you enjoy DevChatt!

Topics: jira atlassian blog scaled-agile facebook internet issues management partners project smartgrid tracking utilities greenhopper
2 min read

Confluence for the Gaming Industry

By Praecipio Consulting on Dec 7, 2010 11:00:00 AM

Atlassian’s Confluence is a key supplement to its Jira product. Confluence acts as a powerful project management component, breaking down information barriers within the development environment and keeping everyone on the same page. With an extensive list of plugins and Microsoft Office integration, Confluence can improve information sharing extensively – especially when working in tandem with Jira.

This post assumes the reader has a reasonable understanding of Confluence (if it’s unfamiliar to you, check out Altassian’s intro video). The post highlights how Confluence – as a component of Atlassian’s Agile approach – can streamline game development. Check it out:

Idea central. Confluence can easily serve as a repository for group ideas – and more importantly, offers more structured brainstorming. This is very important in pre-production environments.

Project central. Configuring Confluence to serve as a central portal for project information makes it easy for team members to get current project news from one place. In a hectic production environment, having a page that pulls in the data you need is great.

Personal homepages. Each Confluence user has their own homepage, and can easily write about what’s happening on their team, in their project, etc. This is much easier than navigating a wiki, and also allows developers to find team members with specific expertise.

Permissions. It’s important for all companies to have a mature permission scheme when it comes to file access. Confluence offers thorough permissioning options, so developers can feel confident in the integrity of their work.

Flexibility. Confluence and Jira are each flexible enough to be used differently by different project teams. One team, for example, may use Confluence to track milestones while another might use it to schedule individual tasks by the hour. Tom-ay-to tom-ah-to, it’s improving each team’s productivity by fitting their unique needs.

Documentation. Documenting applications is of course a critical part of the development process. Confluence makes documentation effective by making it searchable, ensuring users have access to up-to-date information on the fly. That’s extremely valuable since game developers need quick access to tech specs about game branding/design scheme/etc.

That’s how game developers are leveraging Atlassian Confluence to streamline project management in the development environment. And once again, it’s worth noting that much of what’s covered above applies to business of all types – not just those in the gaming industry. Check out our Confluence blogs to learn more about how Confluence (and other Atlassian tools)  can boost your operations.

Special note: We mentioned this in a recent post, but if you’ll be attending South by Southwest (SXSW) in Austin in March 2011, stop by our booth at the SXSWi Trade Show. We’ll have a Confluence (and Jira) demo live, and have our developers behind the table.

Topics: jira atlassian blog scaled-agile confluence management project show sxsw trade documentation homepages integration microsoft

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