4 min read

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

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

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

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

What is Waterfall?

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

Requirements > Design > Development > Testing > Implementation

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

Blogpost-DisplayImage-August copy_Diagram-phases

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

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

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

Pros

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

Cons

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

What is Agile?

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

Blogpost-DisplayImage-August copy_Diagram-2

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

Pros

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

Cons

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

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

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

Agile vs. Scrum - What's the Difference?

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

Blogpost-DisplayImage-August-Agile-vs-Scrum-Methology- Whats-the Difference-

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

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

What is Agile?

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

What is Scrum?

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

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

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

How Do Agile and Scrum Differ?

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

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

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

What Exactly is Agile Methodology?

By Courtney Pool on Aug 17, 2021 12:22:47 PM

Blogpost-DisplayImage-August_ What is Agile Methodology-

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.

Topics: kanban process tips agile software-development waterfall
2 min read

Work Should Be Pulled, Not Pushed

By Morgan Folsom on Jul 29, 2021 1:08:14 PM

Blogpost-DisplayImage-July_Work Should Be Pulled, Not Pushed

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.

Topics: blog best-practices service-management culture agile
2 min read

Agile 101: What is a Spike?

By Morgan Folsom on Jul 20, 2021 11:59:24 AM

Blogpost-DisplayImage-July_What is a spike-

A Spike, in Agile software development, is a work item to support future work by the team that can't be performed without more research, design, or prototyping. Creating a spike allows you to dedicate time in a sprint to finding out more information in a defined time-box.

The benefit of using a Spike is that if the work turns out to be either more or less effort than you expected, it won't throw off the team's ability to get all of their committed work completed. No one wants 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 Scrum and trying to manage velocity, sometimes you need 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. 

How do I use Spikes?

  1. Create a ticket to represent a spike in your backlog
  2. Include the Spike in your sprint – Estimate the spike to determine how much effort should be dedicated to completing the spike
  3. Complete the necessary exploration or design during the Sprint to determine the estimate for the original story
  4. Close out the spike and update the original story with the new estimate

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

Looking for more Agile 101? Check out Project Estimation - Story Points vs. Hours Estimation or Why Jira Won't Make You Agile.

And if you have any questions on Agile, contact us, one of our experts would love to talk with you and see if it's a good fit for your organization.

Topics: blog scrum tips agile
2 min read

Are Retrospectives Useful for Non-Scrum Teams?

By Rebecca Schwartz on Jul 15, 2021 11:34:08 AM

Blogpost-DisplayImage-July_Are retrospectives useful for non-Scrum teams-

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.

Topics: blog scrum tips agile
3 min read

Old Is New Again – Conversations Over Documentation

By David Stannard on Jun 18, 2021 11:43:00 AM

Blogpost-DisplayImage-June_Old is new again - Conversations over DocumentationImagine 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? Check out Sprint Planning: How Long Should Sprints Be? or Kanban vs. Scrum: Which One and Why? and contact us, we love to help!

Topics: scrum collaboration documentation agile software-development
3 min read

Does Jira do burndown charts?

By Mary Roper on Jun 16, 2021 3:33:00 PM

Blogpost-DisplayImage-June_Does Jira do burndowns-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 you team is no longer on target to meet its sprint goal. Here, the burndown chart reflects an increase in scope

scope-creep-burndown-chart

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 the work well before the end of the sprint. 

opportunity-for-alignment-burndown-chart

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. 

plateau-burndown-chart

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

Topics: blog scrum data reporting agile
3 min read

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

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

Blogpost-DisplayImage-June_New to Scrum Master Role Guide–Part2TheDefinitionofDoneThis is Part 2 of a series of 3 posts on Scrum Master Basics.  Here is Part 1

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

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

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

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

1st example from a real demoralized team:

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

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

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

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

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

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

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

2nd example from a real team:

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

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

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

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

Two parting questions:

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

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

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

Scrum Master Basics – Part 1 of 3

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

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

Congratulations on becoming a Scrum Master (SM)!

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

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


Hence this 3 part blog series.

Some of the chief motivations for choosing Scrum are:

  • Delivering potentially releasable value at a regular cadence

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

  • Eliminating waste / becoming leaner

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

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

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

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

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

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

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

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

  • Study their sprint board – more in Part 3

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

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

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

Agile Tips - The Purpose of a Sprint Retrospective

By Michael Knight on Jun 1, 2021 10:15:00 AM

Blogpost-Display image-May_Purpose of a Sprint RetrospectiveA 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.

Topics: blog optimization process process-improvement sprint agile
2 min read

Test Driven Development

By Lauren Schroeder on Apr 28, 2021 11:15:00 AM

Blogpost-display-image_Test Driven DevelopmentWhen 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.

Test Driven Development-1Conventional 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? Check out Could Testing Be the Missing Link for Effective Agile Transformation.

Topics: blog best-practices plan testing development agile
3 min read

Can a Product Owner also be a ScrumMaster?

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

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

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

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

Product Owner

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

ScrumMaster

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

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

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

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

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

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

Overall, not great!!

So what should I do then?

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

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

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

Topics: blog process scrum workflows project-management agile
7 min read

Root Cause Analysis: Leonard, Howard, and the 5 Whys

By Amanda Babb on Mar 10, 2021 9:50:40 AM

Blogpost-display-image_Root Cause Analysis- Leonard, Howard, and the Five WhysDIY 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.

 IMG_4511IMG_4512

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. 

IMG_4507

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. 

IMG_4508

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.

IMG_4509

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.

IMG_4510

Topics: blog confluence plan problem statuspage incident-management itsm women-in-technology agile opsgenie jira-service-management health-check
4 min read

Do testers need to be in sprint planning?

By Marcelo Garza on Mar 3, 2021 11:30:58 AM

Blogpost-display-image_Why do testers need to be in sprint planning-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)

wCXkvvXwQxlBYxwzr_327Yp6iURV_I96Tp1aH_7sZ_o-nN_WgAHqwLsCGZhKraLYAj96nyay0z6VH3GqeZvv7HdSwF1OCGvp

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.

Topics: blog testing tracking collaboration agile software-development
3 min read

Should scrum teams track their time?

By Amanda Babb on Feb 5, 2021 8:03:49 AM

Blogpost-display-image_Should scrum teams track their time-"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 in a previous post. 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 Consulting, 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 Consulting, 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! 

Topics: blog plan process scrum lean-budgets agile
3 min read

Individuals and Interactions Over Tools Doesn't Mean No Tools

By Morgan Folsom on Feb 1, 2021 11:00:00 AM

Blogpost-display-image_People & Process over tools doesnt mean no tools-1"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!

Topics: jira blog best-practices tools atlassian-products agile
3 min read

Why does it seem like only developers have to estimate their time and effort?

By Michael Knight on Jan 21, 2021 10:20:00 AM

Blogpost-display-image_Why does it seem like only developers have to estimate their time and effort-

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.

Topics: developers agile
7 min read

SaaS can be SAFe®

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

Blogpost-display-image_SaaS can be SAFe Blog

SaaS is the future

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

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

Screen Shot 2020-12-05 at 10.03.18 AM

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

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

Scaled Agile Framework SAFe®

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

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

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

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

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

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

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

SAFe® helps you avoid and overcome these engrained practices:

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

SAFe® Benefits

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

Doing SAFe® means:

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

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

SaaS Safe® tips

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

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

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

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

Topics: scaled-agile saas safe agile
6 min read

Using Advanced Roadmaps for Jira

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

Blogpost-display-image_Scaling Agile copy

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

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

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

What is Advanced Roadmaps for Jira? 

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

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

Scope: Where is the work being tracked in Jira? 

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

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

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

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

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

Time: When will it be done?

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

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

Dependencies and Scenarios

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

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

Want to know more? 

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

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

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

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

How to know if your organization is ready to scale Agile

Are You Ready to Scale Agile? 

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

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

Organizational Readiness

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

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

Iterate Your Framework Implementation

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

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

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

Topics: blog scaled-agile best-practices tips safe agile
2 min read

Does a Project Manager fit into an Agile World?

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

Project Manager Role in Agile Framework

Project managers have a wide range of responsibilities when working on a project: they are in charge of planning the project, creating a schedule and timeline, executing each phase, managing budgets, serving as the liaison among all stakeholders, and also troubleshooting and maintenance in addition to other activities. As such, a Project Manager(PM) must be very organized and detail-oriented. A PM also needs to have great people skills because, at the end of the day, this person is responsible for leading the team and communicating with all involved parties.

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

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

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

All brains on deck

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

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

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

A project manager can add value by managing key aspects of every project, overseeing budgets, risks, etc., especially on large scale projects for enterprise organizations. Having a project manager also frees up the scrum master to focus solely on his or her core functions.

Project Manager vs Agile management

agile project manager

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

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

Jira Align vs. Advanced Roadmaps: The Difference

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

How Jira Align compares to Advanced Road for Jira

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

Your Agile and Digital Transformation Journey

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

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

Advanced Roadmaps for Jira (formerly Portfolio for Jira)

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

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

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

Jira Align

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

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

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

Which one is right for my organization? 

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

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

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

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

Agile 101: Why Jira Won't Make You Agile

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

Why Atlassian tools won't make your organization Agile

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

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

Here's why:

Tools Won't Change Mindsets

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

"Individuals and Interactions OVER Processes and Tools"

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

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

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

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

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

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

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

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

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

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

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

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

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

Iterative Development of Complex Systems

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

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

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

Scrum versus Kanban Agile

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

Scrum

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

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

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

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

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

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

Kanban

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

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

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

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

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

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

So what?

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

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

 

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

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

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

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

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

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

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

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

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

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

Why Now Is a Perfect Time to Start Daily Stand-up Meetings

By Michael Knight on May 1, 2020 9:15:00 AM

2020 Blogposts_DistanceLearningAndAtlassian copy

Many software development teams have done well with the stay-at-home orders since they are accustomed to the work-from-home lifestyle. One factor for their success with remote work–both before and during the shelter-in-place–is the daily stand-up meeting, which forms part of the Agile movement in software development, primarily because development work is invisible and hard to understand.

What is a stand-up meeting?

As many employees have moved to remote work over the past few weeks, work-related information has become less visible and harder to understand since people are used to quickly hashing things out in-person at the office. But that's where the daily stand-up meeting can help.

A daily stand-up meeting is typically a 15-minute daily meeting, usually held mid-morning, in which all members of a team come together to discuss what they’re working on, preferably while standing up (this helps promote the 15-minute limit!). Each team member can follow this simple script to give their team members an update: 

  1. What they worked on yesterday
  2. What they’re working on today
  3. What, if any, problems they’re facing

This daily check-in helps the team stay on track, avoid any rework or duplicated work, and tackle problems quicker. The idea with this script is not to outline every single thing you've worked on but instead provide a high-level overview to ensure that the team's focus is in sync and that everyone is aligned with the team's objectives.

How to run a productive stand-up meeting

Here are a few best practices to keep in mind for leading a successful stand-up meeting:

  • Follow the work being discussed on a Kanban board or a similar variant. Visualizing the work item gives context about what it is, who it’s assigned to, and current workflow status. 
  • Limit all side conversations to roughly 30 seconds to allow everyone a chance to get through high-level communications.
  • Make sure to follow up after the stand-up with questions or conversations sparked by information in the stand-up.
  • Take the 15-minute time limit seriously. Actually standing up during the meeting tends to help with this.
  • Hold the meeting every day, regardless of whether you think there are many updates to give or not. This helps the meeting become routine, improves the quality of the updates, and keeps the team in sync.

And the final benefit? Standing! Chances are we’re all sitting down a little bit more than we need to be at the moment – meaning this is a great time to embrace the spirit of stand-ups!

If you in need of more resources on how to help your teams with remote work, here are some great WFH tips. You can also tune in to our upcoming webinar on to leverage tools like Jira, Confluence, and EazyBI to keep your teams connected and productive when working from home. 

Topics: blog best-practices teams community culture agile
2 min read

How to Pay Down Technical Debt with an Agile Approach

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

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

Understanding Agility

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

Importance of Documentation

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

Agile Approach with Jira

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

How to Pay Down Technical Debt

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

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

Agile Home Improvement Using Atlassian Tools

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

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

Trello vs Jira Software Cloud

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

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

Screen Shot 2019-04-05 at 2.22.48 PM

Screen Shot 2019-04-05 at 2.20.44 PM

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

Bamboo* as the Foundation

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

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

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

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

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

IMG_3837     IMG_3835

IMG_3836

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

Home Improvement Retrospective

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

What did we do well?

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

What could we have done better?

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

What actions can we take going forward?

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

Continuous Improvement 

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

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

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

Agile Coach vs Agile Consultant: The Difference

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

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

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

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

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

  2. How mature is our team?

  3. What are our pain points?

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

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

Agile Coach - A Subject Matter Expert

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

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

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

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

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

Agile Consultant - A Business Consultant 

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

The most common reasons for hiring an Agile Consultant are:

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

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

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

Difference Between Coach and Consultant

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

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

Topics: blog scaled-agile process digital-transformation agile
3 min read

Could Testing Be the Missing Link for Effective Agile Transformation?

By Praecipio Consulting on Feb 20, 2019 7:03:00 PM

NOTE: The following is a guest post by Tricentis Director of Product, Ryan Yackel.

A modern testing platform is a critical, but often overlooked, element of successful agile transformation. Could QA (Quality Assurance) be the missing puzzle piece in your quest to deliver higher quality software faster?

The pace of software development is accelerating, and technology teams face increasing pressure to adopt agile development and continuous delivery models so that their businesses can more quickly respond to customer demand.

But your first-mover advantage will suffer if you are first to market with mediocre software.

If you fail to deliver high-quality digital experiences at the pace today’s users demand, you risk alienating customers. In the case of defect-ridden software, poor user experience, or a catastrophic bug, you risk losing significant market share and damaging your reputation.

Software Testing

In the rush to beat the competition to market, organizations are transforming software development and delivery processes. But too often, business leaders fail to prioritize QA transformation, and QA teams are stuck using ineffective legacy solutions that were built for outdated waterfall environments. The reality is that as long as your testers are using legacy QA tools, your transformation will remain incomplete.

Legacy QA tools like Micro Focus Quality Center cannot accommodate modern development workflows. (Year over year, Micro Focus Quality Center (HPQC) has been among the least recommended testing tools for agile teams in VersionOne’s State of Agile Report.)

Legacy tools do not integrate with open-source automation tools, which limits testers’ options for accelerating test cycles and makes it impossible to integrate QA into continuous delivery pipelines. This means QA teams lack visibility and are not able to test new code as it is written. Development is further delayed when developers cannot quickly access test results and mitigate issues QA has found. As a result, releases are delayed, and quality inevitably suffers.

When testing occurs at the end of a development sprint, bugs are often embedded in the code, where they are significantly costlier and more time-consuming to correct. As a result, the myth of the QA bottleneck persists. Or worse, the QA process is rushed, and organizations end up with defect-ridden releases that fail to provide the high-quality experiences their customers demand.

Development and QA

If you can integrate quality into agile and DevOps processes, instead of treating it as an afterthought, testing can occur almost simultaneously with development. When a tester finds a bug, he or she can alert a developer to address it right then, instead of after lines of dependent code have been written on top.

With the right approach QA can help speed development by helping developers identify potential defects early. That means that QA is no longer pressured to complete testing quickly as the last step in a sprint. With a truly agile testing approach, QA can become a strategic enabler of business success, rather than a bottleneck.

Integrated Testing

Successful agile organizations have adopted modern test management tools like Tricentis qTest to successfully integrate testing into modern development and delivery processes. Tricentis qTest offers a real-time Jira integration and centralizes test automation management across frameworks and tools – including out-of-the-box integrations and a robust API for test automation management. qTest also offers testers in DevOps environments a single platform for unifying tests that run through continuous integration with other tests.

Contact us to learn more about how we can help you accelerate your agile transformation by modernizing testing.

Topics: blog best-practices devops testing digital-transformation agile software-development tricentis
4 min read

Stay Agile with Jira and Confluence

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

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

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

Marketing Tasks = Jira Issues/Tickets

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

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

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

Tracking Assets and Tasks 

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

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

Using a Kanban Board

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

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

Plan Alignment

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

Now what?

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

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

Praecipio Consulting is an Atlassian Platinum Partner

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

atlassian-platinum-solution-partner-enterprise

In need of professional assistance?

WE'VE GOT YOUR BACK

Contact Us