As a Solution Architect at Atlassian, my team has had the opportunity to work alongside Praecipio, one of our Agile at Scale Specialized partners, for some time now. We've collaborated to ensure that some of our largest customers received the right level of support and guidance needed to successfully scale their agile practices with Jira Align. In my current role, combined with over 10 years of experience as an agile coach, the biggest challenge I’ve often seen an Agile inspired group attempt to overcome is deciding what practices and ceremonies to standardize on. The question is often asked: How do we stay true to the agile manifesto and empower the people that do the work to continuously improve? 

Rather than just tell you what a given Portfolio, Product Pillar or Business Unit needs to standardize to scale their agile practice, I want to discuss the ‘why’ from the lens of an impacted customer because focusing on the customer impact is how you reduce waste and surface the need for standardization in the spirit of agile. In my observation, below are the top five most impactful areas for standardization to unlock scaled agility.

Top Five Standardization Essentials:

1. Product Quality Principles. This is the working agreement among those that build the product and those that manage the product; examples include engineering excellence practices like continuous integration and continuous delivery (CI/CD), test-driven development (TDD), user experience design and definition of ready before releasing to market. Establishing product quality principles is important because defects make customers very unhappy. They break down customer trust and loyalty, and lead to lost revenue.

2. Retrospectives. These are regular recurring events that surface impediments or opportunities across all teams and at each team level. These are important because problems do not resolve themselves, and teams need to be empowered to improve their ways of working.  This is also how wasteful processes that have not proven to serve the customer’s best interest are surfaced. A poorly run organization is obvious to customers. They want to engage with providers who advance their products and services on a regular basis.

3. Common Work Object Definition. Work objects describe what we hope to achieve and roughly how long it might take, such as epics, features and stories. It is important to clearly define the documentation structure for each work object, the timeframes, and ownership expectations, so that planning and working rhythms can be established. Customers want to receive value early and often. A common work definition enables the organization to break up product delivery and feature enhancements into achievable goals.

4. Estimation System. An estimation system is used to describe the work to be delivered and level of effort or complexity it will probably require, such as story points or t-shirt sizes. It is important to estimate delivery objects because estimation drives meaningful conversations that surface barriers and feasibility. Near term product roadmaps and the ability to deliver on a release plan depend on how well teams can plan their work. Customers establish loyalty when they see a roadmap containing the things they ask for and they actually receive them in a reasonable amount of time.

5. People and Team Structure. This is the way people are organized and grouped together. Agile at scale adoption will result in operational changes and it is important to structure teams around the value stream in a way that maximizes the flow of communication, feedback loops, and market delivery. An organizational structure that is compatible with the agile operational model reduces dependencies across teams, wasteful processes, wait times and impediments. Customers benefit the most from an optimized people and team structure because they are receiving value as quickly as possible with the best quality.  

Now that I’ve shared my top five essential areas of standardization, I want to hear your thoughts on how challenging you believe it would be for your organization to implement them. Do you believe there is a different set of standards that are more impactful to scaling agile practices? Connect with me on LinkedIn and let me know your thoughts!

Interested in learning more? Check out our co-authored whitepaper, The Connected Enterprise: Close the Gap Between Business Strategy & Execution or Contact Praecipio for a personalized demo! We'd love to share the benefits of Jira Align with you and your team.

We’ve compiled a list of the most popular content determined by our readers from all of 2022. With recurring topics like Confluence Optimization, Atlassian Cloud Migration and Agile Transformation, it’s evident that 2022 was the year of getting things done. According to our research, the following resources are our most-loved and viewed throughout last year:

1. Whitepaper: The Connected Enterprise: Close the Gap Between Business Strategy & Execution

Together with the experts at Atlassian, we explore how Jira Align as a platform - when implemented well, can help to improve visibility and coordination so that organizations can adapt more quickly. We dive into how Jira Align provides seamless user experiences that leads to large-scale transformation success, the importance of properly configuring the platform, and how Jira Align helped enterprise clients uncover and resolve issues through real-time feedback loops and faster decision-making cycles.

2. Ebook: 6 Steps to a Successful Atlassian Cloud Migration

This eBook walks you through the steps that organizations should follow to plan, prepare for, and carry out an Atlassian Cloud migration. Learn what to expect before migrating, how to avoid common mistakes during the migration process, and how Praecipio used these six steps to guide Castlight Health through a successful Atlassian Cloud migration.

3. Ebook: How ITSM Drives Business Transformation

As customers continue to demand better products and always-on services from companies, ITSM sits at the center of meeting their expectations and delivering value faster. This eBook walks you through the ITSM practices that are essential for keeping up with today's fast-paced world and accelerating business transformation. Learn how to modernize your IT operations, facilitate collaboration, and deliver new services with agility by leveraging this customer-centric approach.

4. Webinar: Proving Value: How Business Leaders Use Jira Align to Connect Strategy and Execution

In this webinar we define the connection between strategy and execution from the Portfolio to the Program within Jira Align. We guide you from ideation through prioritization, planning for execution, commitment to the backlogs, and tracking progress, investment, and status. By the end of the webinar, Praecipio will demystify how Atlassian, and specifically Jira Align, can help you mature within Lean Portfolio Management.

5. Blog: How to Report in Confluence with the Jira Issues Macro

The Jira Issues Macro bridges the powerful, native link between Jira and Confluence. With it, you can report on Jira in Confluence seamlessly. This one macro can solve many of your reporting needs in Confluence. What's more, you can provide context around the data instead of just straight data. The Jira Macro is a great way to keep team members informed without navigating from Confluence to Jira and back again.

6. Blog: How to Solve Too Many Confluence Email Notifications

In this blog we walk you through all the ways to reconfigure your Confluence notification preferences so that your email doesn’t become clogged with notifications that are not important to you. Free up the space in your inbox and save yourself time later by updating your Confluence settings now using this blog as your guide.

7. Blog: Scrum Sprint Planning: How Long Should Sprints Be?

Teams new to scrum face lots of decisions – one critical decision for teams to perform efficiently is determining sprint length. Every team's needs are different, and there's rarely a one-size-fits-all approach to planning the length and organization of your sprint. While there are arguments for the varying lengths of sprints in scrum, this blog lays out some standard variables that you and your team should consider.

8. Blog: Affects Version vs. Fix Version in Jira: The Difference

Both the Affects version and Fix version are automatically created in Jira out of the box. They are related to Software Development Life Cycle (SDLC) projects and are the foundation of releases in Jira. While they are linked and work in tandem at some points, there is a best practice when using the versions inside of both of these fields. This blog defines what each field is and how to properly utilize them.

9. Blog: Best Practices for Jira Epics

Discover how to make the best use of your Jira instance with Jira Epics. We walk you through what an Epic is and the importance of knowing the various workflows and requirements uniquely available for Epics, how to use these features to get on track with your agile project management, and provide you with some basic do’s and dont’s centered around Epics.

10. Blog: Maximizing Jira Align's Value Prop to Deliver Value Faster

Jira Align is truly a unicorn product that brings teams and information closer together for improved visibility, faster decision-making, and greater agility. When configured correctly and in a way that meets the specific needs of the client, Jira Align helps organizations reach that sweet spot where they connect strategy to work execution and eventually achieve true enterprise transformation. In this blogpost, we dive into what makes Jira Align such a powerful tool and how organizations can maximize this enterprise platform to deliver value faster. 

We're on a mission to help teams execute on the work that matters most, through a customizable approach built on Enterprise Agility, Cloud, App Dev, Dev Ops, and the powerful Atlassian platform and beyond, we can help you GET IT DONE, by removing the systems-level obstacles preventing you from DOING. We hope this list inspires you to take the next step in achieving your business goals. Should you need assistance our team of experts is here to help.

We’re so excited to begin creating more helpful resources this year to help you continue to drive your business forward and add value to your organization’s digital infrastructure. 

Welcome 2023; let’s get things done!

Plus 3 Ways Agile Coaches Can Help Businesses Close Their Readiness Gaps 

Almost every organization struggles to some degree with connecting strategy to execution–only 3% of companies say they have done it “very successfully.” 

Something gets lost in translation when the c-suite tries to communicate an organization’s strategy to delivery teams, and then lost again when delivery teams try to communicate progress back up to the c-suite. In fact, in a survey by Harvard Business Review researchers found that only “55% of middle managers can name even one of their company’s top five priorities.” 

The pain points exist in three main areas across a company’s people, process, and technology: Lack of visibility, lack of coordination, and an inability to adapt. 

To help improve all three of those pain points, many teams consider technology like Jira Align, which promises to “connect your business strategy to technical execution.” 

Jira Align is definitely not plug and play, and is not appropriate for every organization. So, how do you decide if your organization is ready for a platform like Jira Align? And how can you, as an agile coach or transformation office team member, begin to close the gaps in order to prepare the organization (and yourself) for this technology?

Let’s find out by looking at eight ways to know if your organization is ready for Jira Align.

Success with Jira Align Requires Agile Leadership

Historically, (including in the most recent State of Agile Report and State of Agile Coaching Report), the main blocker for an agile organization is leadership. So it is no surprise that the first two indicators that a company is ready to adopt Jira Align are also leadership focused.

1. A c-level leadership team with a clear vision for an agile transformation is by far the top indicator that a business is ready for Jira Align. Jira Align can’t put an organization on a path of agile transformation, it can only illuminate the path that the business is already on.
   
   
2. Many organizations have an executive sponsor who believes in the agile transformation and offers support. To be ready for Jira Align, your business needs an executive champion.
   
   What’s the difference between an executive champion and an executive sponsor? The executive champion takes an active leadership role in a Jira Align implementation and the concurrent agile transformation, and is positioned high enough in the organization to make decisions.

The leadership team is the first and most obvious place for you, as an agile coach or implementation lead, to begin to close the readiness gaps for your organization. Work with the c-suite to explain what agile is, how it affects their work, and their role in a successful agile transformation. 

Ask leadership to appoint an executive champion, perhaps a Chief Transformation Officer, who has real authority, can dedicate time, and will build a team to support the change effort.

To help educate others about the need for Jira Align, work with a Jira Align partner to hold a workshop with the organization’s leaders. In a few hours, a skilled Jira Align expert can demonstrate some of the most glaring problems separating strategy from execution, and talk through ways to close those gaps. 

Often, seeing the scope of a problem first-hand–and how the platform can give visibility to that problem–gives leadership much more energy around investing in agile transformation with Jira Align as the technology platform solution.

Success with Jira Align Requires an Investment in Change  

Forrester Consulting’s Total Economic Impact study found that Jira Align has helped customers achieve up to 340% ROI, so it’s clearly worth the investment. But beyond the tool-related investment costs, the organization has to be willing to invest in change, and to have the patience to go through the associated growing pains. 

Indicators three through five, then, are all about an organization’s commitment to change. 

1. Investing in Jira Align is as much an investment in changing the mindset of the organization as it is an investment in technology. The funding for training and coaching (both for agile-at-scale frameworks like SAFe® and in Jira Align itself) should be on par with a transformation. Without training and coaching, businesses will not get the desired results from Jira Align.
   
   
2. The organization must be willing not only to fund the change, they have to also have active change management in place to embrace that change. Successfully implementing Jira Align requires significant shifts in organizational thinking and processes. This will result in significant discomfort across the organization as process changes and mindset shifts are in progress. Working through that discomfort is painful, but ultimately worth it.
   
   
3. Jira Align is designed to align teams throughout the organization. Doing this will likely require teams to change the way they work and the tools they use for that work to standardize data and reporting. Complying with standards will take not only strong change management, but also strong coaching on the why behind the changes.

The whitepaper The Connected Enterprise: Close the Gap Between Strategy and Execution presents some valuable statistics and a model case study to help showcase how much more an organization benefits when its teams know they are building the right things, at the right time, for the right people.

Hold informational sessions such as lunch-and-learn programs around how much more autonomy and creativity teams will have when leadership can see in real time how the work they are doing is related to the strategy. Explore a quick demo of Jira Align’s “why” button, which when properly configured provides all of the context behind each feature, epic, and theme from inside Jira Software, including the business case behind an item’s priority.

Source: https://www.atlassian.com/blog/jira-align/ask-why-to-unlock-organizational-change

If it does not already exist, create a transformation office. Once formed, the transformation teams can begin meeting monthly or quarterly to gauge progress, remove impediments, formalize processes.

Scaling is another coaching opportunity. Introduce teams to agile at scale within their current context.  Discuss how small but impactful changes at the team level can help create standardized metrics that add visibility not only to the c-suite but between teams as well. This automated visibility can eventually expose and decrease dependencies between teams, meaning less time spent in meetings and more time spent creating and delivering value.

Other agile coaching opportunities may include: formalized ways to prioritize programs to achieve strategic goals (e.g., WSJF) and/or lean portfolio management.

Success with Jira Align Requires Realistic Expectations

Before going all in with Jira Align, it’s important to set realistic expectations not only about what the platform does and does not do, but about how long it will take, and how much technical expertise will be required to realize all of its benefits. That brings us to the last three indicators that an organization is ready for Jira Align:

1. To be successful with Jira Align, the organization and its leadership first must understand that Jira Align is not a reporting system. Jira Align is a living system. It is an enterprise agile transformation platform designed to enable collaboration at all levels, every single day. Sure, it has a powerful reporting component. But the greatest value enabling mindset transformation and value delivery are in the live views.
   
   
2. Implementing Jira Align takes time. An initial pilot at the program (team of teams) level can be implemented within 3 months for a single program. A full implementation modeling the firm from Enterprise/Strategy to Team levels will take at least 12 months.
   
   Internalizing the related mindset, processes, and practices will take as long as a typical successful agile-at-scale transformation:18 - 36 months.
   
   
3. Last but not least, the organization will need to bring in training and technical expertise. For Jira Align to work as intended, it must interface smoothly with team-level tools. That’s why it’s critical for the organization to have competent Jira or Azure DevOps (ADO) admins or reliable, dedicated Modern Service Management that can perform that function. In addition, organizations will need dedicated technical expertise to support the configuration and integration into the existing technical ecosystem.

Here’s the third and final place where agile transformation coaches can really dig in and use Jira Align for their own benefit as well as the organization’s benefit. Learn Jira Align well enough to use its built-in feedback loops to coach teams, measure the organization's agile transformation progress, and report on return on investment.

You’ve likely had to learn tools before to support and help teams: from Trello to Miro to Jira Software. Jira Align is no different. What is different, though, is how you can use the live views and reporting metrics inside Jira Align to measure your own success in enabling the organizational transformation.  

You can learn about features such as framework maps that let you map framework implementation activity to the Jira Align implementation, resulting in a visual map of the organization’s progress. Check out a process step Kanban board for all the teams’ work items, from stories to features to epics to themes. View and review the Work Tree using multiple filters such as the Strategy View, Top-Down View from Portfolio, or Bottom-Up from Story. 

Already, 14% of respondents in the 2022 State of Agile Report report using Jira Align. As that number increases, coaches will need to quickly interpret teams’ progress and areas for improvement as easily as they do today, but within Jira Align. Knowing Jira Align provides a competitive advantage within the industry. 

Get Ready for Jira Align

As more and more organizations begin to apply agility outside of just software teams, the need for technology like Jira Align is only going to increase. About half of State of Agile survey respondents say they apply agile practices to the entire application delivery lifecycle. And two-thirds are using Atlassian’s Jira to manage their agile projects already.

Jira Align helps to solve so many problems organizations face at scale, including real-time visibility, aligning every team to strategy, and optimizing for customer value. And, it claims to be the only platform that lets organizations implement and extend any framework at scale, including hybrid and custom frameworks.

It won’t be long before your organization is asking to implement Jira Align. Start getting them–and you–ready today.

After helping organizations implement Jira Align for almost seven years now, I've seen first-hand the challenges that they’ve faced in unlocking the product’s full potential. At the same time, I’ve also had a front row seat to the transformative power of Jira Align within those organizations whose leadership teams were truly committed to the agile transformation journey and were willing to shift their mindsets. 

In this blogpost, we’ll take a deep dive into what makes Jira Align such a powerful tool and how organizations can maximize this enterprise platform to deliver value faster. 

More Than Just a Reporting Tool

Jira Align is truly a unicorn product that brings teams and information closer together for improved visibility, faster decision-making, and greater agility. When configured correctly and in a way that meets the specific needs of the client, Jira Align helps organizations reach that sweet spot where they connect strategy to work execution and eventually achieve true enterprise transformation. 

Unfortunately, many companies make the mistake of buying Jira Align primarily as a reporting system. Jira Align is so much more;  it’s a living system and enterprise agile platform designed for daily collaboration at all levels. The powerful reporting component is only a small part and in fact, the least important for real success. 

Understanding the Layers of Jira Align’s Value Proposition

To unlock your organization’s agility with Jira Align means understanding the layers of the platform’s value proposition and how these different components work collectively together to drive better business outcomes. Let’s take a look at each layer and how they build upon each other to make Jira Align they dynamic enterprise tool that it is: 

1. Basic Technical – Jira Align is a platform that allows organizations to visualize teams’ work in the form of stories, features and epics (and related concepts of dependencies, risks, etc.). This is the first layer where work is organized in a way that it is tied to strategic vision and investments.  

2. Performance Improvement – The second layer looks at the data generated by Jira Align and the story it tells to business leaders about performance and how to improve it. Many organizations fall into the trap of focusing only on performance metrics provided and get stuck in the second layer.  This happens because most leaders mistake utilization as a proxy for value delivery

3. Value Visualization – Jira Align is designed to measure value flow through the enterprise modeled in well-defined epics, features and stories. Organizations that reach level 3 never again question “Is a Jira Align license worth the cost?”  because they shifted their mindset from doing stuff (utilization) to delivering value (delivered features) on cadence.

4. Outcome-based Thinking – Jira Align’s objectives are one of its most powerful and flexible features, allowing outcome-based thinking at all levels. They are a prism through which to view progress against a specific desired outcome. To fully employ Align's outcome-based thinking requires also understanding how to model portfolio epics, features, strategy, themes, and more in a way that they are tied to short and long-term goals. Organizations that reach level 4 are much farther along than most of their competitors in their journey to enterprise agility. 

5. Leadership Feedback Loop – The pinnacle of a Jira Align implementation is achieved by evolving through the previous levels while being led by an executive champion(s) and their team(s) that are committed to a true agile enterprise transformation. With this approach, Jira Align becomes the focal point of a feedback loop where leadership can see true transformation  and their teams’ mindset shifts are reflected in Jira Align’s value-delivery metrics.

What It Takes to Implement Jira Align

For companies to realize Jira Align’s full value, it requires clarity and commitment to agile transformation, as well as in-depth experience from an Atlassian Solution Partner. Praecipio has helped hundreds of organizations build agile practices and scale their operations through our proficiency across a range of frameworks including SAFe®. As an Atlassian Specialized Partner in Agile at Scale, our experienced agile practitioners have proven success in enterprise methodology and change management providing Fortune 2000 customers with an accelerated path to enterprise agility with Jira Align. 

Looking for more Jira Align resources? Check out this related blog post on Jira Align, in which we walk you through how to successfully implement Jira Align, tune into this on-demand webinar on how to use Jira Align to connect work execution to strategic vision, and explore our Jira Align Insight Report, co-authored with our friends at Atlassian for a deep dive into the tool that can help you share the benefits of Jira Align with your team.

You can also book a technical call to discuss your organization’s specific needs around Jira Align and how to accelerate your agile transformation journey.

As organizations continue to scale Agile practices, our team at Praecipio 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 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, road mapping, and execution management. 

Your organization may also use non-Atlassian applications to manage planning and road mapping. 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 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 can not only help you assess your current state, but we can also provide guidance and recommendations to accelerate your digital transformation. For a detailed look into how Jira Align can transform your organization, read our recent whitepaper. 

If you are ready to take the next step in your digital transformation and Agile journeys, let's chat!

Happy (almost) New Year! Like most people, I was happy to close the door on 2020 and am ready to move past 2021. Thankfully, 2021 brought some relief, but even still it was another challenging year. While I'm grateful for the growth both professionally and personally that each year provided, I have high hopes for 2022 and that it’s not “twenty twenty, too”.

Every new year provides us the opportunity to retrospect on the previous year and plan for the new one. I, for one, do not make New Year's Resolutions. Several studies show that only 8% of New Year's Resolutions are successful. The reasons for failure range depending on the group of people surveyed. Athletes, for example, have a fateful day: the second Saturday in January. Whereas others may see a slightly longer time frame before failure (the second week of February), it's disheartening to set and fail at a New Year's Resolution.

Each of the studies (of which there are countless) seem to agree on the success factors: setting smaller, attainable goals in shorter time frames. For those Agile evangelists out there, this sounds VERY familiar.

Setting SMART Goals

The first step in setting any attainable goal is to think SMART: Specific, Measurable, Attainable, Relevant, and Time-Bound. Roughly 55% of New Year's Resolutions are health-related. Let's look at one of the most common examples: "I want to lose weight."

When we hold this basic statement against the SMART standards, it fails. And, to be honest, so will you. Instead, let's reframe this within the SMART framework: "I would like to lose 20 pounds by May 31."

This fulfills all the SMART criteria of setting a good goal. Now that we have a good goal, how do we attain it? Let's look at our Agile frameworks to help us fulfill our goal of losing 20 pounds by June 30.

Set Yourself Up for Success: An Iterative Approach

If you've ever tried to fulfill a New Year's Resolution, you know there are tons of factors that can impact your results. Weather, holidays, birthdays, sheer lack of desire...any or all of these can impact your ability to attain your goals. Instead, break these down into incremental smaller goals and measure your attainment in shorter timeframes. Think of your big goal as an Epic (the what) to be broken into Stories (the how), and you will attain that goal.

The Epic: 20 Pounds in 5 months

The Stories: 4 Pounds per Month

See? Doesn't that already sound easier? But you need to take it even further. Thinking of each month as a Sprint, you should set yourself a Sprint Goal for each month. How are you going to build better habits to lose the 4 Pounds per Month?

• Walk 30 minutes twice per week
• Reduce meal delivery service to once per week
• Cook a vegetarian meal once per week

However, the critical thing to remember is not to start your first week with all three. Remember, you're trying to set yourself up for long-term success. It should look something more like this:

• Walk 30 minutes twice per week by the end of January
• Reduce meal delivery service to once per week and continue to walk 30 minutes twice per week by the end of March
• Cook a vegetarian meal once per week, continue reduced meal delivery service, and continue to walk by the end of May

Instead of starting all three goals at the beginning of January, gradually iterate into them. Spend the time to focus on a single, smaller attainable goal to build the habit.

Meet Your Goals: Measurement and Retrospective

While attaining your goal is binary (I did it or I didn't do it), the key to success is to measure against it and retrospect on a regular cadence. Instead of obsessing over the pounds per month, measure against the smaller goals.

• Walk 30 minutes twice per week
  • Mark on a calendar when you walked each week
  • Use a fitness tracker and specifically call out when you walked each week
• Reduce meal delivery service to once per week
  • Set the day of the week to have food delivered (e.g. Thursdays)
• Cook a vegetarian meal once per week
  • Mark on a calendar when you cooked a vegetarian meal
  • Set the day of the week to cook the meal

Each week, take a moment to review your calendar or your app or however you track these items. However, do not beat yourself up if you missed a week. Really dig into why the miss happened. Was it a particularly stressful day and ordering delivery was easier? Was the weather too cold or snowy or rainy that week? Either way, you don't have to "make up for it" the following week: simply try again.

As you engage in 2022, remember you don't have to start on your resolutions right away either. If you've failed every year in January, then shift your goal to a February start. After all, the definition of insanity is doing the same thing over and over and expecting a different result.

Interested in how you can apply similar logic to meet your business goals and increase your ROI on projects? Reach out and our experts would love to help.

What is a spike in agile software development? 

A spike, a term often used in SAFe, scrum and other agile frameworks, is a task designed to answer a question or gather information, rather than produce a product. An agile team will choose to include a spike in their sprint to support or prepare for future work if that work requires more information before it can be started. In short, a spike is an opportunity to research, test or explore the unknown before work begins. Creating a spike allows your team to dedicate time in a sprint to finding out more information in a defined time-box – or a set amount of time. 

Why Should I Use Spikes? 

The benefit of using a spike is that it helps agile teams anticipate and prepare for the amount of work they will need to do to accomplish a task. For example, if the work turns out to be either more or less effort than you expected, it could throw off the team's ability to complete the work they committed to. In other words, a spike helps scrum and agile teams with estimation and prevents them from falling behind on sprint goals. 

Who Typically Initiates a Spike?  

Anyone on a scrum or agile team can and should initiate a spike if they feel they are not prepared to begin a specific task or story. Typically, if a team member takes on a task and recognizes that they need more information before they can begin, they can create a spike to help them prepare. It can be frustrating to find out mid-sprint that a story is much more work than you thought because you didn't really know what it required yet. When running in sprints and trying to manage velocity, it helps to build in room for uncertainty. It may be that there's a piece of work that needs to be completed, but we're not really sure how much work that's going to take. In these cases, using spikes can be a huge help. 

Related Article: Sprint Planning: How Long Should Sprints Be 

How do I use spikes in Jira?

One of the ways to manage spikes in Jira, is to establish them as their own issue type and then, once solved, convert that issue type from a spike into a story when you are ready to begin work. You can link it back to the spike using the JIRA issue links for record keeping. To start your first spike, follow these steps: 

1. Determine who on your team will take on the spike
2. Create a ticket to represent a spike in your backlog
3. Determine the amount of time, or time-box, that you are willing to spend on your spike 
4. Complete the necessary exploration or design during the sprint to create an estimate for the original story
5. Close out the spike and update the original story with the new estimate 
6. Convert your issue from a spike to a story 

Using spikes in your sprints can make your teams more reliable – by giving you a better idea of what's going on, with less pressure to know everything up-front.

Looking for more guidance on your agile transformation?  Contact us, one of our experts would love to talk with you and see if it's a good fit for your organization.

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

What is Waterfall?

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

Requirements > Design > Development > Testing > Implementation

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

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

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

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

Pros

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

Cons

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

What is Agile?

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

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

Pros

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

Cons

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

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

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

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

What is Agile?

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

What is Scrum?

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

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

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

How Do Agile and Scrum Differ?

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

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

Any person who's worked in or around software for any length of time has likely heard of Agile. Since the release of the Agile Manifesto in 2001, Agile has quickly spread through the industry, and even companies who aren't fully Agile sometimes claim to be, if only to check the box. Still, despite this popularity, we regularly receive confessions from people who admit that they don't fully "get" what Agile is, often from teams outside of software developers who want to know if Agile can help them too.

The Elevator Pitch

"Getting" Agile is a multi-step process, but knowing the elevator pitch is a great place to start. Agile is an iterative approach to software development and project management, with iterative being the keyword. Its primary focus is on delivering value incrementally, with those increments being faster, more frequent, and with fewer strings attached than some traditional approaches. Agile also acknowledges, accepts, and even encourages that risk and change are likely to pop up and need mole-whacking along the way, allowing for real-time course-correcting as needed.

This short description can help people navigate through many of the superficial conversations around Agile. If you want to impress though, knowing the details is the next step.

The Details

To really understand what Agile is, it helps to first understand why Agile is. Agile's origin is in software development, and its inception was a direct response to the rigidity of existing development methods like Waterfall. Despite this, its existence is not at all meant to be a critique of Waterfall, which is a valid methodology that still has uses in several scenarios; rather it's an answer to the "But what if...?" questions that plague so many projects, such as: 

• What if I discover more requirements after development has started?
• What if we don't catch a big problem because we waited too long to test?
• What if we need to ship to market faster or more frequently?

Answering these questions is difficult in a Waterfall environment, and failure to answer them can be costly. This can be especially true in software, where conditions and criteria frequently change, and rapidity and innovation are critical factors in winning over users. Enter Agile, whose principles allow teams the flexibility needed to answer these questions as they arise while still meeting product and stakeholder needs.

While some interpret this flexibility as Agile having no rules, this could not be further from the truth! The Agile Manifesto itself includes both key pillars and guiding principles, which every organization purporting to be Agile should follow. Amongst the guiding principles are those that are arguably more nebulous, like "Working software is the primary measure of progress." Still, many are undeniably rules and not suggestions, such as the principle requiring the increments mentioned above: "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. "

Beyond that, there are also rules associated with each particular Agile framework to adhere to as well.

You see, while "Agile" is the overarching methodology (or philosophy, some argue, an ongoing debate), the actual "doing" is often guided by the numerous frameworks within Agile, with more popular frameworks like Scrum, Kanban, eXtreme Programming, and the Crystal Method leading the charge. Of course, that's not to say that one can't simply follow the principles of Agile without needing a specific framework -- you absolutely can! -- but development teams may find it easier to work within a framework. Aiding this ease is that each framework has taken the Agile principles and hammered them into specific actions, ceremonies, and practices for teams to follow, reducing the need for teams to develop their own.

Knowing the pitch and the details is essential to understanding Agile, but "getting" Agile requires that you take it one step further and apply it outside the business.

The Real World Example

As mentioned, Agile is an iterative process that seeks to frequently deliver value while still allowing for the winds of change. One of the reasons Agile can work so well is, if you think about it in the simplest of terms, because most people do Agile every day.

No, seriously!

I recently moved and learned again how ever-present Agile is. I prepared for the move with a soft plan and a general goal in mind: get everything packed and ready by X date. I even took an incremental approach to it, regularly moving smaller and more manageable items over to the new house in the weeks leading up to the move. As is frequently the case, though, life had different plans, and I found myself scrambling to finish hours before the movers' arrival (see: winds of change). I could have chosen to stubbornly stick to my original plan, risking either an incomplete project or a financial blow from having to delay, but I instead chose the Agile approach. I reprioritized and adjusted my goal, focusing on readying the most vital components and shifting lower priority items to my next increment. 

And just like that, you're Agile!

So now you can quickly explain Agile to someone any time it comes up, dazzle them with a few specific details, and even deliver an analogy or two to help set it in. The final step? Contact us to find out how Praecipio Consulting can help you make it work for your teams.

Pushing work is generally considered to be the process by which someone will finish their work and then hand it off to a teammate, regardless of whether or not that teammate is ready for it. This type of behavior is commonly referred to as "Throwing something over the fence" - 

though it can also elicit comparisons to seagulls, pigeons, or other mischievous birds who come in, drop something unfavorable, then turn and fly away. The clear implication is that a person who pushes work typically does not pay attention to nor care what happens after it leaves their hands.

Pulling work, on the other hand, is generally considered the action by which someone will finish up what they are currently working on, then go out in search of the next work item. Typically, there is a known stack of work that person can pull from, ideally ranked by highest priority. The implication in this case is that the person has completed their current work (or is blocked) and has the bandwidth for new work.

Which work environment would you rather be a part of?

Ignore Salt-N-Pepa: don’t push it.

In our experience, teams that have built a culture of pulling work see two main benefits: a better working environment and more accurate metrics. As described above, a push-heavy culture can result in friction, frustration, or even animosity between teammates. Perhaps just as detrimental, a push-heavy environment can actually skew the data and give misleading insights.

When the culture transitions to becoming pull-heavy, the seagulls – and their unfavorable somethings – disappear! Teams are better able to manage their workloads, and the data become clearer and more useful.

A simple way to begin establishing a pull-heavy culture is to add neutral zones at the points of handoff in your process. These neutral zones represent areas where no team is adding value – rather, the item is finished with the previous part of the process and awaiting the next part. An example would be a “Ready for QA” column. When the development team is done with an item, they can move it to the Ready for QA column. QA can then manage their own workload and pull the work into their process when they have the bandwidth to do so.

This change is likely to generate new insights and improve the way your team is working. For instance, it should now be possible to determine when an item is actually being worked on as opposed to idly waiting for someone to pick it up. This can better inform managers how throughput can be increased. Additionally, it becomes easier to focus on high priority items, as lower priority work should remain in the neutral zones until the high priority work is completed. Having a team lead periodically prioritize work in the neutral zone will further improve the process as team members can simply select the first work item that meets their skillset.

Create a more autonomous and less frictional environment for your team: focus on pulling work through your process, not pushing it. 

If you're curious on transforming your team's culture and create the ideal environment to get work done, contact us, we'd love to help.

If you work in tech, you've most likely heard of the term "Agile". Agile is a framework typically used by software and project management teams to deliver better quality work to customers in a more timely manner. Depending on the way organizations approach their journey to becoming Agile, there are various methods they can use to get there. One of the most popular Agile frameworks is Scrum, which proposes teams lean on time-boxed iterations, called Sprints, to complete their work. At the end of each Sprint, Retrospectives are to be completed. Retrospectives are meetings where Scrum teams discuss how to improve the way they work; they are typically held every 1 or 2 Sprints. They give the team a chance to come together and discuss what they liked, what they disliked, or what they felt could've gone better during the Sprint.  Many teams neglect to complete this step, even though it is one of the most important items teams can leverage if they're aiming to truly be Agile. Thinking about Retrospectives and their benefits made me realize how useful they can be for all teams, not just Scrum teams. 

Retrospectives and Non-Scrum Teams

Retrospectives are great for non-scrum teams in that they push teams to look back and reflect on the work they've completed. This reflection is key for future work, as teams can avoid past mistakes or time-eating efforts that negatively affected the efficiency of their last project. They can do the same for the items that lead to success in their previous projects so the team can consistently deliver their best work efficiently.

Additionally, retrospectives are great for promoting team unity and trust across the team members. When team members can openly share their honest opinions about how the team is doing, team communication improves, leading to better quality work and better relationships between team members. Any team can benefit from this, no matter how the team goes about completing their work.

Consistent reflection and analysis of completed work are excellent tools, even if the team isn't using Sprints and your work isn't necessarily time-boxed. At Praecipio Consulting, we hold retrospectives after the completion of every engagement. Looking back on the wins and losses, I can't help but feel a sense of pride amongst my team members on the work we delivered. Setting aside this time for the team to come together and communicate with one another allows our delivery teams to grow and bond with one another. Not to mention, the work we produce increases in quality and the processes behind that work become more efficient. 

If you are curious about Agile, and would like to see if it's a good fit for your organization's needs, contact us and one of our experts will get in touch.

Imagine a world where businesses can concurrently develop next generation manufacturing processes while designing products based upon the as-yet-non-existent implementation medium. Imagine that they can do this all while reducing time-to-market and allowing the continued benefit of exponential growth in complexity every 18 months. Add a twist of “design-anywhere-build-anywhere” – and serve shaken; not stirred. Perhaps in software, the analogy might be "develop applications on a language being implemented and SDKs that will also be created concurrently – trust us, it will be fine." At the same time, many graduates from engineering colleges were learning that the soft skills of communication and collaboration had higher impact to their success than the hard earned technical skills.

In the early 1990s, an organization is asked by several of its clients to help them address time-to-market pressures. The result: in 1992 Don Carter published a book founded upon a transformational approach called Concurrent Engineering based on consulting experiences. One impact that I remember well was the increase in actual conversations amongst the various constituents - breaking down the barriers between the silos was a key component of this philosophy. Coincidentally, the quality of results increased too, along with client satisfaction.

Back to the future... Literally!

There is even more pressure on businesses to reduce time-to-market, and there are few signs that this will change or needs to change. No time for creating voluminous documentation in semi-isolation that can't capture all aspects and are often subject to interpretation by the reader. The division between hardware and software development has blurred. In fact, hardware designs are created, modeled, emulated, and the proposed implementations are verified using specialized high level languages prior to implementation. The abstracts are subsequently decomposed into manufacturable entities while continuously confirming no unintended loss of the design intent using specialized tools such as formal verification tools. 

Businesses are and must continue becoming Agile – businesses are greater than having Agile development organizations. So the adoption of Agile, Scrum, and other practices continues unabated. There are even early discussions of what’s beyond these Agile practices that are standing the test of time after several decades of adoption. 

Two important aspects of the Agile Manifesto are valuing “Individuals and interactions over processes and tools” and “Customer collaboration over contract negotiation”. It was increasingly common pre-COVID that these teams were distributed geographically and even culturally. So while tools are a part of the solution – the need to communicate well and often has never been more important. This practice is standing the test of time.

A closing note to Scrum Masters who help teams live the benefit of the cross-functionality objective: Your Scrum teacher and Agile coaches have provided you with lots of reference material about building teams and communications. Now is a good time to revisit those references; one of my favorites is “Crucial Conversations” by Kerry Patterson et al. The book addresses situations with perceived high stakes, diverse constituents, and possibly highly emotions.

Looking for more Scrum tips? Contact us, we love to help!

Good reporting capabilities are essential to Agile teams using Jira Software - and for good reason! Data visualization tools are essential for promoting good communication and collaboration. One of the most sought-after reports is included in Jira Software out of the box: the burndown chart. Read on to learn how Jira makes it easy to generate and share the burndown chart with your team and stakeholders. 

The Inputs

1. A Scrum Board: In Jira, the burndown chart is accessible through Scrum boards only.
   • To create a scrum-type board, follow these instructions from Atlassian. Column mapping is a key configuration point, as it's the basis for the burndown chart. 
2. An Estimation Statistic: Determine how your team will measure work, and set an estimation value on each of the issues in your sprint.
   • Jira accommodates for Story Points, original time estimate, issue count, or any custom field, provided that the custom field is a numeric custom field type.
   • We know that this can be a sticking point for your team and asked our Principle Amanda Babb to shared her thoughts about Scrum Team time tracking to help you along the way. 
3. An Active Sprint: Once your sprint starts, begin to review your team's progress. 

The Interpretation

Once the sprint starts, you can review the burndown chart along the way to understand the amount of remaining work in a particular sprint and gather feedback on the sprint itself. Below are a few scenarios that the burndown chart captures:

Scope Creep:

Scope creep is often unavoidable, so it's necessary to understand when they occurred especially if your team is no longer on target to meet its sprint goal. Here, the burndown chart reflects an increase in scope.

Opportunity for Alignment: 

It's important for the team to collaborate and land on an estimate for each work item in the sprint - not so much for the actual estimate itself but more for the shared understanding based on the requirements. This is often seen in both over and under estimates on the burndown chart. Below, the burndown chart reflects where some work was overestimated; the team is on track to complete the work well before the end of the sprint. 

Plateaus: 

Plateaus on the burndown chart are typical when you have a team who is either new to Agile as a whole or new to working together. It's an indication that the team got off to a good start early on, but didn't carry the effort through the remaining work items. 

Ready to learn how Jira Software can help your Agile teams collaborate and communicate while working in Agile sprints? Drop us a line!

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

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

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

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

1st example from a real demoralized team:

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

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

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

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

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

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

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

2nd example from a real team:

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

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

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

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

Two parting questions:

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

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

Congratulations on becoming a Scrum Master (SM)!

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

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

A sprint retrospective is, in practice, a meeting scheduled after every 1-2 sprints in which the team comes together to discuss how to improve the way they work. The meeting can follow several formats, with the most common consisting of each team member sharing what is working well, what isn’t working, and any new ideas they have to improve. Some examples of takeaways from the meeting might be “Our daily standup is helping to keep everyone on track,” “We need a better process for reviewing tickets after QA is finished with them,” or “Let’s try estimating with story points instead of time values.”

Retrospectives were introduced to make sure the team is constantly in communication about how to improve. This process is commonly known as a feedback loop, and is one of the hallmarks of any good Agile process. Feedback loops have been discussed as one of the most important parts to becoming successful, either as a team or as an individual, a claim backed up by copious amounts of business literature full of research and examples on the topic. A prime example of this can be found in Talent is Overrated by Geoff Collins. While not a perfect book by any means, Collins does a wonderful job of explaining the importance of feedback loops. The argument posits that the way humans improve at anything is to do the thing, look back on the thing and analyze it, figure out how to improve performance of the thing, then do the thing again. The retrospective helps teams to do the middle two parts of that process.

Here are some tips for running a successful sprint retrospective:

Get on a consistent cadence

Doing retrospectives too often will lead the team to resent them. Doing them not often enough will greatly reduce efficacy and result in an inability to put into action the ideas brought up in the meeting.

Prepare ahead of time

Before the meeting, encourage team members to spend a half hour thinking of what is working well, what isn’t working so well, and ways to improve. That way the team can most efficiently use everyone’s time when they come together for the retrospective.

Bite off what you can chew

Instead of trying to implement all the new ideas after every retrospective, focus on determining which ideas are the quick hitters: those that have a big impact, but are easy and quick to implement. By adding the one or two best quick hitters each week, the process will evolve at a sustainable pace. Over time, the team will likely run out of quick hitters, giving you a chance to implement the more intricate ideas. 

Are you making the most out of your teams? If you need assistance with Agile, get in touch, we'd love to help.

When we're in the process of creating a product, we want to see the end result. We have a vision of what the product will look like and how we want to get there, so it's tempting to try to get the product running as quickly as possible. However, if and when the product breaks or needs to be updated, we are going to be responsible for fixing it. With that in mind, we look toward Test Driven Development (TDD). 

Nobody likes folding laundry. It takes time, and not everyone appreciates the results (at least not initially). The next morning is a different story: When you wake up to a crisp stack of folded shirts, choosing an outfit is easy - there's no rummaging through a laundry bin and you know exactly what's ready to wear. Sometimes, an initial time investment such as folding laundry, can help us out in the future.

Testing the Feature

We could test manually, going through our list of features and testing each feature to make sure the product is operating as intended. Or, we might write automated tests once the product is finished. But like rummaging through a laundry bin, working through this retroactively can be complicated and we may miss important information.

Many developers use TDD to prevent dealing with this "laundry". Instead of writing tests during the QA phase of development, developers write automated tests before anything else. Imagine a developer adding a new feature to software that allows the user to change the color of the background. The developer first writes an automated test to check whether the background color is changed once a button is clicked. The test may initially fail. They would then add the functional code and use the automated test to make sure the feature works.

Why would a developer want to spend extra time writing tests before building a product?

First of all, TDD keeps development simple and goal-focused. Features are added only when they can pass a specific test. This means that the developer has to make sure that each feature is necessary and the objective of that feature is clear. With no objective, it's impossible to write a test to pass your objective.

The TDD time investment leads to time savings in the future. Although it takes more time to include automated tests in the initial development of a product, there is potential for time savings in the future. When a product breaks, it's clear which part of the code is causing the failure. This means that QA may go more smoothly as bugs or product upgrades arise.

Conventional development vs. Test Driven Development. Using TDD requires an initial time investment but can lead to time savings long-term.

Of course, TDD processes aren't the best for every team. When there are too many possible test cases (often seen in GUI development) it can become impossible to write tests for every functional situation. Like any set of processes a team uses, think about what makes sense for your situation. Does the product have finite requirements? Has QA testing used eaten away hours of time due to buried bugs? Making an early time investment can keep things orderly. Even if your sock drawer is destined to be a mess, think about how you're building your products.

Want to learn more about testing? Book a technical call with an expert.

TL;DR: No!

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

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

Product Owner

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

ScrumMaster

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

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

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

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

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

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

Overall, not great!!

So what should I do then?

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

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

Looking for more information on Scrum best practices? Check out Sprint Planning - How long should sprints be?

DIY or DIE!

For those of you watching from home, I have been on a home improvement journey for quite some time. Applying an Agile mindset to home improvement (or really anything I do) is one of my passions. Even at my most recent Women in Agile meeting, we discussed applying Agile concepts to daily life and feeding these back into building a great resumé. One of the principles of the Agile Manifesto reads: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. We all know this applies to Agile development practices, but it also applies to IT Service Management. Specifically, Incident and Problem Management. For me, it applies to my recent home improvement adventure. 

Strong fences make great neighbors

My neighbor and I spent the better part of a Saturday fixing our mutual fence. You see, I have two dogs: Leonard and Howard.

Both are rescues. Leonard is eight and was "free to a good home" while Howard is four and was adopted from my county's animal shelter. Both dogs have been with us since their puppyhood and, as any dog owner will say, they are the BEST. DOGS. EVER. Except when they're not. This was not the first time my neighbor and I had to work on the fence. Observe one of the troublemakers in his natural habitat. 

This epic saga started in May of last year. I would diligently fix loose boards, prop items against the fence to "patch" holes, and monitor their outdoor activity while I was awake (awake being the key word here: 3am barking and fence-patching sessions are no fun). I supplied my neighbor with fence planks because, well, they're my dogs. We fixed the section above and let the others lapse until a series of shenanigans prompted my neighbor and I to spend our Saturday replacing three additional sections. My neighbor and I became united in making sure my two didn't escape. While my neighbor "doesn't care" that my dogs are in his yard, my (very good) boys take the opportunity to break out of his fence and wander the neighborhood. Howard usually comes back, but Leonard meanders through the streets, swims in pools or the lake, and generally causes mayhem until I can coax him in my car to come home. 

Not in my back yard...

Before this latest patch, I was determined to find the root cause. Previous to May of last year, this was not a problem. My puppers would frolic in the backyard and simply bark at other dogs in the neighborhood as they walked by. I made sure they were let out several times per day to make sure they were relieved in addition to daily walks. While I was traveling, they were also well-taken care of and monitored. What changed? 

Root cause analysis is, simply put, problem solving. While it is widely used in sciences and engineering, it is also a key element of IT Service Management Incident and Problem Management. When reacting to an incident, the team must restore functionality as quickly as possible. Upon resolution, root cause analysis helps us understand why. It then prompts us to ask, "Is there an action I can take to prevent this from happening again?" Incident Management leads to Problem management and through root cause analysis, we can move from a reactive organization to a proactive organization. 

Of the many techniques of root cause analysis, my favorite is the "Five Whys". It is the simplest technique: ask why until you've identified the root cause. Not like a petulant child, however. Asking the first why should be easy, then continuing to ask well-curated questions based on the previous answer helps you determine the root cause. I applied this to my situation: 

• Why do I have to replace parts of the fence? 
  Because the dogs are chewing through the fence.
• Why are the dogs chewing through the fence?
  Because they can access the backyard whenever they need.
• Why can the dogs access the backyard whenever they need?
  Because we installed a dog door.

HA! I found it. The root cause. And it didn't even take me all five whys. 

Any root cause analysis technique does not stand alone. There exists a plethora of other techniques. Pareto charts determine that 80 percent of your problems are derived from 20 percent of the causes. An Ishikawa (fishbone) diagram looks at measurement, materials, methods, machines, management, and mother nature. Scatter plots let us look at correlation and causation. Was the dog door the root cause? The existence of a dog door doesn't change the behavior of my boys. Having access to the backyard doesn't make them chew through the fence planks. Did we ask enough questions to actually identify the root cause? Did I also consider a Pareto analysis, an Ishikawa diagram, or a scatter graph to understand why I was constantly chasing my boys through the neighborhood? 

I stopped at three whys: "I have a dog door."

What happens if I keep asking why? 

• Why did we install a dog door? 
  Because Howard wasn't fully potty trained. 
• Why wasn't Howard fully potty trained? 
  Because I didn't take the necessary time to train him. 

AHA! My Ishikawa diagram identified "management" as the issue. My Pareto identified the 80 percent as my time to train my puppers. My scatter plot showed the amount of time spent correlated to the amount of dog-induced shenanigans. I would add these to the post, but won't because...reasons. More importantly, I simply kept asking, "Why?" until I identified the root cause. 

Actions speak louder than words

Now that I have a root cause, what is it that I can do to prevent this issue from recurring? When looking at Incident and Problem Management, Atlassian products such Opsgenie and Statuspage can ingest, aggregate, correlate, and trigger the creation of Jira Service Management issues. With Confluence, we can create specific root cause analysis templates to be shared with our customers and stakeholders. However, it's up to our techniques and processes to help us determine the actions we need to take going forward. 

For me and my puppers, it's simple. 

1. Take at least 30 minutes out of my day for dedicated doggie exercise
2. Reinforce good behavior while in the yard
3. Lock the dog door overnight (no more 3AM "let me sing you the song of my people" moments)
4. Finish replacing the aged planks on the fence

By taking these actions based on my root cause analysis, I should have this solved quickly with redundancies built in. My puppers will be safer and happier, I will have a beautiful new feature of my home, and the three of us will have less stress day-to-day. Using root cause analysis techniques, and Agile mindset, and drawing from IT Problem Management, I can easily solve this problem and any additional ones around my home.

BRB, gotta run and get some more fence planks.

In today’s business environment, high-speed implementation is a must. This applies to all products and services. Suppose you were using an application and got stuck because of a bug: after reporting the bug, you expect the team to fix it as soon as possible. If not, your next move is probably going to be switching to another service.

Software companies want teams working together providing quick and on point solutions to save time and resources, which can only be accomplished by the involvement of all of the teams working on a project. That’s why companies are opting for testing with Agile teams, since it allows for a greater collaboration across teams on a project. 

Agile allows a key collaboration between testing teams and developers which can’t always be accomplished with traditional approaches. It enables testers to share their perspective from the start of the sprint planning; this leads to less bugs during testing and creates a better possibility for sprint delivery dates to be met on time.

Let’s dig a little deeper to understand what this means.

The objective of Agile/sprints/scrum 

Agile methodologies were born as an alternative to traditional software development approaches, like waterfall methodology. 

The following images show the big difference between agile and waterfall methodologies. (Source)

On one hand we can see that the traditional approach (Waterfall) aims to understand user needs and develop a product. After development, testers test the product and report bugs before deployment. The development team then works on them and fixes any errors using the best possible solution. This is progress through phases, one starts only when the previous one ends; this does not create an opportunity for proper feedback or collaboration between testing, developers and users teams.

On the other hand, Agile is mainly focused on performing constant, small deliveries of the product in order for the customer to be able to see how the product advances through the lifecycle. This gives the opportunity for testing to take on a bigger role and to get involved at an early stage of product development and throughout all the lifecycle of the product.

Agile has four important values:

1. The focus should be more on individuals and interactions instead of processes and tools

2. Working software is more important than comprehensive documentation

3. Customer collaboration is more vital than contract negotiation

4. The process should respond to change rather than follow a plan

Testing in sprint planning: The goal of sprint planning

During sprint planning, the team discusses which stories they will focus on in the upcoming sprint based on aspects like priorities, time frame, feasibility, etc.

The whole team involved in the development of the product should be involved, and if additional expertise on specific backlog tasks is required, then stakeholders can also be part of it.

Sometimes, during this meeting, the testing team can take a secondary role since the main focus tends to be on the development of the stories; this is understandable since it will set the start of the sprint. However, the testing team's' perspective can lead to some serious benefits for developers.

Why testing should be involved

One flaw of working in traditional testing (i.e. Waterfall methodology) is that during the test case design phase, although testers receive the requirements, most of the time they don't get access to the software they will test until it is time to begin the test execution phase.  It is well known that there is usually a big gap between what a requirement specifies and the actual software developed. 

This leads to a huge time investment on the testing side to reach out to both developers and users to define how the product works and how it should work in order to define the correct test scenarios and test cases.

Agile methodologies give testers the opportunity to be involved in the development of the product from the get-go. Testers can be involved in the design of the software by working closely with developers to assess and advise on testability aspects.

An Agile tester should understand the relevance of technical skills. A tester is always prepared to contribute to the technical discussions of the team. Their contribution may extend up to code reviews, user stories grooming, and understanding requirements. The Agile Software Tester gets to work with the developers when they are performing unit testing and share the perspective of testing from a tester's point of view instead of a developer's. The tester can work collaboratively and productively with the product owner and the customer to form acceptance criteria from the sprint planning itself. 

Before any user story is sent for development, the tester and other team members can discuss the complete user story with the team members to find out what the customer wants. Having testers collaborate with developers from the very beginning of sprint planning helps to achieve more accurate estimations and to ensure that everyone has some testing tasks as part of their responsibilities

Great testing teams know they need to become an extension of the customer and end user. Testers need to understand the customer's needs: an Agile tester should be able to describe the feature as well as the customer.

Drop us a line for expert advice on testing and all things Agile, we'd love to help your teams achieve their true potential.

"How many hours are in a Story Point? Pink. Because penguins don't like ice cream." -Amanda Babb in every conversation about hours and story points. 

While I use this example as a cheeky way to say the two methods of estimation (hours and story points) don't coincide, the reality, of course, is much more complex. Business and product teams typically think in terms of dates and schedules. Development and operations teams typically think in terms of level of effort. That's not to say story points and dates do not nor will ever coincide, it's a matter of how to speak each other's language. 

What is a Story Point?

Our Dragon of the West, Christopher Pepe, explained it well:  humans are terrible at numbers. That's why we have so many ways to express things without using numbers. For example, I have Big Dog (Leonard) and Tiny Dog (Howard). Tiny is small in comparison to Big Dog. However, at 50 pounds, he's not small compared to, say, a Chihuahua. This is what we call relative estimation in the agile world. This thing is larger or more complex than the other thing over there: it will take a larger level of effort to complete. 

Computers, on the other hand, are wonderful at numbers. It's part of the reason we invented them. In Jira Software, a story point is simply the numerical expression of a relative estimate. When we need to understand the level of effort of more than one thing, we aggregate the relative estimate into a total level of effort. This is known as the commit in a velocity chart. As we complete work, we burn down the level of effort until we understand what's left. At the end of a sprint, we determine whether we met our commit or not. The completion of the work over several sprints determines our velocity. From there, we can reasonably predict the level of effort we can complete during a sprint. 

Why can't a team estimate in hours? 

It's not a matter of can't. At Praecipio, we've seen many teams succeed well in estimating their level of effort in hours. However, this involved a significant effort to run time studies on routine tasks for the team. In a time study, an outside party will watch a person do a task and time it. Then watch them do it again...and again...and again. Then, the outside party watches another person perform the same task several times. The outside observer will continue with this until they feel they have sufficient data to make a reasonable assumption (read: average) of the time it takes to complete said task. Rinse and repeat for all tasks all personnel complete in a day and through out the week. 

Estimating in hours works well in repetitive work environments. The same tasks must be completed the same (or similarly enough) throughout the day and week. However, when we're thinking about software development, we all know this is rarely the case. What may seem like a simple feature request can become a significant effort when looking at how the new feature interacts with the rest of the services, modules, or products. Yes, we've done something similar before and it took four hours. But what has changed since the last time we implemented something similar? What else have we deployed? Did we change our methods? Are we integrating this with another system? Have the APIs been updated or changed? How many releases have been performed since the last time we did this? 

The shoulds and shouldn'ts of tracking time in Scrum

Why are teams being asked to track time when they estimate and understand level of effort in story points? In a word, Money. Under complex financial and regulatory practices, most businesses report quarterly earnings to regulatory bodies and markets. The best way a business has to gather and report this information is through complex financial systems that aggregate data from inputs across the organization. One of the more critical inputs? Time tracking. So how should we and shouldn't we track time in a scrum team? 

• You should establish the minimum time guideline such as 15-minute or 30-minute increments
• You should not expect accuracy down to the minute for a given task
• You should expect the team(s) to continue to estimate their level of effort in story points
• You should not make the team switch to hours to estimate their level of effort
• You should centralize where the team should track time
• You should not expect the user to log in to multiple tools to track time
• You should download our Lean Budgets White Paper which details different ways of managing the data and provides a solution in Jira Align
• You should not expect to implement a fundamental change in financial tracking and reporting across your organization without help

At Praecipio, we have implemented several solutions to this problem across industries and with all sizes of organizations. For help regarding how your teams can balance time tracking, scrum, and financial reporting, feel free to reach out to us! 

"Individuals and interactions over processes and tools"

It's an important line from the Agile Manifesto – one that establishes that the focus when trying to work in an Agile way is the people. However, we often see this used as a justification to provide inadequate tools to teams. In a well-run Agile organization, you shouldn't have to think about the tools - they should support the work that the team needs to do without getting in the way. Organizations often make the mistake of implementing tools to make teams work in an Agile way. However, tools are in and of themselves not enough - the people and processes behind them are what makes a business go.

However, this doesn’t mean we should ignore the tools we use, opting for whatever’s cheapest, easiest to setup, what we’ve always used, or something that’s “good enough.” Rather, we should take the exact opposite approach and select our tools purposefully, deliberately identifying the tools which best empower employees and promote processes. Because of this, there are two properties of utmost importance when considering a new tool: the tool should allow our team to run with the process that best meets our team’s needs, and the tool should help our team members work better together.

To fit the first of these criteria, the tool should be customizable in a way that allows your team to use your own process. Much of enterprise software today shoehorns teams into predefined configurations and settings which the tool manufacturer thinks are best. This leads to frustration, difficulty in using the tool, and potentially costly transitions to new software. In our experience, every team is at least a little bit different, and even two teams that want to implement the same fundamental process will find they have a few differences they would like reflected in the process. Because those differences tend to arise from the uniqueness of your team, they are important to capture in the tool in order to give your team the tools that best meet your needs.

Further, a good tool will promote communication and collaboration between teammates, inside or outside of the tool. Information tends to get lost when team members do their work in one system but communicate that work in another. For this reason, an ideal product will allow for conversations to take place within the product, ideally directly on the work item those conversations are referring to. Historical conversations should be preserved to allow for a look back on what decisions were made and why, and the tool should have options for how users are notified of important communications. Further down the collaboration path, handoffs should be made simple if not automatic, and any approvals should be doable within the tool. Finally, high-level or detailed status reports should be visible and accessible by any team member who needs or wants to see them.

These two crucial properties are two of the reasons we like Jira. Atlassian’s strategy for a long time has been to develop applications to meet the 80% of needs that are shared by most teams, such as collaboration features, malleable processes, and easy visibility of work, while allowing the remaining 20% of needed functionality to be determined by individual teams and sourced in the Marketplace. The result is a product which delivers good performance out of the box, but can be optimized to meet the needs of any team.

Consider the role that Jira plays in Agile. A large portion of the functionality is built in: Kanban and scrum boards, backlogs, issue types, workflows, and sprint reports. However, the software is customizable to the point that it works equally well for teams that have a quick, simple process with a few issue types and teams which have a complicated process with several rules, handoffs, and types of work. It doesn’t matter to Jira whether your version of Agile requires multiple manager sign-offs before it’s done or if your team lives on the edge, skips QA altogether, and goes straight to production. The point is that the software fits your process, not the other way around. Regardless of process, there are several mechanisms for the team to stay in touch along the way. Every issue can be commented on and allows for @-mentions to draw attention quickly. Email notifications are sent out at times decided by the team, not at arbitrarily defined times decided by the tool’s developers. Progress is simple to see on a board, and every user has access to generate reports or build dashboards to collect information relevant to them, reducing the need for repetitive status reports.

Most organizations will purchase a tool, kick it around for a few years, then junk it because it “doesn’t work right” or “doesn’t make sense for us.” Don’t let this happen to your organization. Pick your tools with care and optimize them for your team. And if you need help, talk with the experts, and get great advice!

Nearly a decade ago, as an intern at a now-defunct startup in Austin, Texas, I got a question from a developer that haunted me for years after because I didn’t have a clue how to answer it:

“Michael, why is it that only the developers have to jump through the hoops of estimating our work, spending hours in sprint planning and retrospective meetings and making sure every hour of our day is accounted for and attached to a work item?”

After incredulously wondering how anyone could possibly question the divine and holy agile methodology that I had been zealously learning and implementing that summer, I realized that the developer had posed a wonderful question. Why was it that we only had these requirements for developers? Why didn’t we impose this same process on sales or HR or accountants or any other part of the business? Why wasn’t anyone asking upper management for a timesheet that said exactly what they had worked on every hour that day? I’ve thought about this question for a long time and have built up an answer, or rather a few answers and some capitulations, over the past several years of agile work.

First, development work is hard to understand. Even for developers it’s hard to understand, but for those without computer engineering degrees or years of experience, it’s nearly impossible. How do you explain to someone that developing a section of code that does something seemingly trivial is actually exceedingly difficult and can take several hours?

Second, the work is invisible. You can see code, sure (even if you can’t understand it), but you can’t really see data fetching, processing, rendering, or anything else going on behind the scenes. Coupled with the difficulty of understanding development work in the first place, this poses a serious issue for people trying to understand what’s going on in that bullpen. In contrast, people can see a sales call, an HR training meeting, or an accountant’s spreadsheet and understand quickly and intuitively the value that it brings to the business.

Which brings us to our third and perhaps most important point: it’s important for the business to know what development projects cost. Part of what product managers should be doing is understanding the economics of a given feature, bug fix, or other development effort: how many hours did the team spend writing, testing, rewriting, and deploying this code, and how does that translate to cost?

In my mind, these three reasons sufficiently answered why the business typically loves these processes and imposes them on development teams. But, they didn’t do a good job answering why other teams didn’t tend to have the same processes, often seen as restrictions, imposed on them. After all, isn’t some sales and accounting work invisible and hard to understand? Isn’t it important for the business to understand the cost of HR work? 

Because of this, I’ve come to firmly believe that there are several processes, standards, actions, and overall contributions, usually all attributed to the amorphous “agile”, that every team and business could benefit from. Stand-up meetings, among teams of 15 or less, can be a great way for the team to understand what everyone is working on, reduce duplicate work, and quickly squash problems. Kanban boards (or any similar variants) are wonderful for seeing all of the work in progress, matching different team members to their respective strengths, and prioritizing and organizing ongoing projects. Sprints, or at the very least increments of time which demand continuous planning and feedback, will certainly expose problems and bring about process improvements for a given team. 

It turns out the developer who asked me that question years ago was on to something. The business tends to pick on development teams because their work, in most offices, is the hardest to understand, the least visible, costly, and they’d like to get a better understanding of what’s going on. However, many agile practices would clearly benefit teams across the firm, including and especially those outside of development. Here’s to hoping we see businesses move in that direction in the coming years.

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.

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.

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. 

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. 

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

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

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

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

All brains on deck

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

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

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

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

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

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!