3 min read

Tips For Setting Up Effective Kanban Boards In Jira | Praecipio Consulting

By Michael Lyons on Sep 8, 2021 3:01:34 PM

Blogpost-DisplayImage-September-2021_Tips For Setting Up Effective Kanban Boards In JiraJira's Kanban boards are great tools for tracking the progress of work being done by teams and for gaining insights into opportunities. Boards are highly customizable and can accommodate numerous types of processes. This flexibility is very helpful for teams that need to track a continuous flow of work in high volumes. If you are new to using Jira's Kanban board or are looking to get maximum results out of using the boards, we have a few tips that can help.

 These tips are meant to help make your Kanban board be as insightful as possible.

Reflect the Work Being Done

Boards are most effective when they are set up in a way that is easy to use, and match a team's work processes. You can add any number of columns to your board depending on how your team works. Statuses from your workflows can be mapped to the columns in any way. The option to customize is very helpful for teams, but it is important to align columns and statuses in a way that the user can efficiently move the work through the board. Designing a board that is inefficient can make the board frustrating to use. 

An effective way to map statuses for a Kanban board is to ensure that each status is mapped to a column, especially those statuses that are along the critical path. This helps the user navigate within the board seamlessly to provide updates on their work and track progress. This also prevents the user from having to take the extra steps to update issue statuses. Mapping each column to a status is by no means a requirement, but it helps to make these statuses available in the board so the user can quickly drag and drop the issue into a new column as work is being completed. 

Filter, Filter, Filter!

Work can add up when your team is very busy! All of this work can show up on the board and make it difficult to use if filters are not used appropriately. Luckily Jira provides a few options for filtering out issues. We recommend leveraging sub-filters and quick filters to help clear up yourboard. Sub-filters can be added to boards to help filter out issues that are older than a specific time frame or that have been moved to a certain status. We like to use sub-filters that filter out any issues that have been resolved or closed for more than two weeks, for example. Quick filters can be built to help filter down to issues that have certain field values or components. End users can interact directly with these filters and can toggle between them depending on the information they would like to see.

Leverage the Backlog

When issues are being created, it's important to discern which items are ready for work and which items are still being vetted by the project team. Boards that do not make priorities clear can cause confusion. For example, if a column has both an "Open" and "To-Do" status mapped, all work items within those statuses will appear in the column. Having so many of these items in a column can make it challenging to quickly determine the items that the team should work on.

Implementing a Kanban board with a backlog can help declutter the board and help users better identify work in the "To-Do" status. This is a feature that can be enabled within the board. All work items in an "Open" status form the backlog and do not appear on the board, while work in the "To-Do" status will appear in the first column. Your team will now know the items that take priority and are ready to be completed. 

Implement WIP Limits

Jira allows teams to set limits on the amount of issues that can be placed in columns. These limits should be based on what the team's work-in-process limits (WIP) are for processes. If the number of items in a column exceeds the maximum, the column will be highlighted. This gives teams insight into where they need to focus their efforts and shows them where opportunities are within the process. 

We are process obsessed: our custom-made workflows are designed by our teams of accredited and experienced professionals. If you have any questions about Jira or Kanban boards, please reach out to us! We would love to help.

Topics: jira blog kanban process process-consulting tips
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
5 min read

Can We Talk for a Moment About Spreadsheets?

By Amanda Babb on Jul 27, 2021 11:14:14 AM

Blogpost-DisplayImage-July_Can We Talk for a Moment about Spreadsheets-

No, seriously: can we please take a moment to talk about spreadsheets? I have a very large bone to pick with them. Spreadsheet is a four-letter word to me; and don't get me started on workbooks! I recognize spreadsheets have their place in the world. I'm always in awe when I see the most complicated and fragile spreadsheet being used to manage a simple set of data to provide "insights" into the business. Even better, a spreadsheet that helps manage prioritization, planning, and execution reporting on a regular cadence. I've seen complex CountA and SumIf formulas, and Concatenate, and pivot tables, and everything else people can throw at them. And while I'm impressed at the craftsmanship, I'm also incredibly frustrated. The time it took to create and iterate on that reporting could have been spent having conversations about the work or checking in with a team or removing blockers. Instead, the extraction, manipulation, and reporting of easily-accessible, real-time data takes precedent. 

While it was published in 2014, I still reference an article when discussing data and reporting with our clients: This Weekly Meeting Took Up 300,000 Hours per Year. Yes, you read that right: 300,000 Hours. Per. Year! A single team extracting data, then aggregating it across several teams, then teams of teams, then programs, then everywhere else, all to be reviewed in a 30-minute executive meeting where the conversation was, "Are we on track? Yes? Great."  <sends weekly update deck to recycle bin>.

I hold no ill-will to the spreadsheet warriors out there. Instead, I view it as a simple case of "We've always done it this way." Well, what if I could show you a different way? What if, through the power of Atlassian, I could provide you real-time analytics? What if I could show you how to integrate Jira with a Business Intelligence solution? Or provide Program and Portfolio Management including planning and execution data in Advanced Roadmaps or Jira Align? How many hours would that save you or your organization when providing in-depth analytics to executive management? I promise you, this is all possible. 

Individual Team Metrics: Scrum and Kanban

Individual Team metrics are available for both Scrum and Kanban Teams under Reports in a Jira Software project. For Kanban Teams, both the Cumulative Flow Diagram and Control Chart provide flow metrics for the Team. While it may have been a while since you've taken a statistics class (if at all...I confess I tried hard to avoid them), spending ten minutes reviewing these reports will provide information on bottlenecks, flow trending, and backlog growth. Adding Quick Filters to your Kanban Boards will allow you to drill down into a specific subset of data on your board. Want to focus on Stories or Bugs only? Create the Quick Filters. 

Scrum Teams have nine (yes, NINE) reports available on their boards. Are you using the Burndown during your Daily Standup? Can you predict your release of an Epic or Version based on the throughput in those reports? Have you reviewed the Sprint Report to see what was added or didn't complete during the Sprint and asked why? The Scrum Reports will tell you what is happening during the Sprint (or happened, during the Retrospective), but it's up to you and the Team to ask why it happened. 

Need additional assistance to understand what these metrics are telling you? There's a training class for that. Praecipio Consulting is happy to help!

Program, Product, or Teams of Teams Metrics

Client: "Hey, Amanda, we're pretty good on the individual team stuff. Is there another way we can aggregate team data together?" 

Me: "How much time you got?" 

Three solutions come to mind for this one:

First, let's talk about Advanced Roadmaps for Jira. As always in the Atlassian tools, flexibility is key. When creating a Plan in Advanced Roadmaps, tying the work to the Teams by pulling in the scope of work is the first step. Whether it's a Board, a Project, or a Filter, aggregating data across multiple Teams, then tying the source to the execution team, provides you predictable velocity and capacity planning as well as execution reporting. 

  • You want Progress? You got issue count and story point or time-based progress.
  • You want to predict a milestone (read: release) date? You got milestone dates.
  • You want dependency maps? You got dependency maps.
  • You want to look at the Plan in a capacity view or a release view or a specific timeframe? You got custom views. 

Sharing all this information from Advanced Roadmaps in Confluence is amazing. While native in Confluence Cloud Premium, you can download and install the free app from the Atlassian Marketplace for Data Center. If you would prefer to simply share a link to the specific view of the Roadmap, that's available to you as well. 

Second, EazyBI. We constantly hear of clients looking for a more robust way to cube and concatenate data across their Jira instance. However, our clients tend to revert to what's comfortable: the spreadsheet. Instead, using an OLAP analysis and multi-dimensional calculations, EazyBI can provide the complex reporting when Jira's native Reports and Dashboards just won't do. EazyBI started as a purpose-built solution for Jira: it recognizes Jira's data structures and surfaces field data you may not be able to work with in native Jira. Since it's a unidirectional sync, EazyBI will not change your Jira data either. EazyBI can also integrate with other data sources including (sigh) a spreadsheet. 

Third, Jira Align. Here at Praecipio Consulting, we love Jira Align. The Program Room brings together all the information from multiple teams, i.e. an Agile Release Train. Every bit of data from Jira Software is aggregated to provide a clear understanding of the pace of the Train. The Program Board, the current implementation Roadmap with risk indicators, the investment data, the actual execution data, all of it is available in the highly-configurable Program Room. Burnups, Burndowns, progress by Epic, this is all available in Jira Align. In fact, there are over 180 reports available in Jira Align. And if that's not enough, Jira Align BI extends the already-robust reports into your existing visualization tools or your enterprise data lake. 

Enterprise Business Intelligence Integration

You may already have a Business Intelligence solution. Quite frequently at Praecipio Consulting, we hear our clients mention PowerBI, Tableau, or data lakes such as Hadoop or Snowflake. These powerful solutions are likely already embedded in your organization. And there's probably a SME out there just waiting to assist. Enterprise organizations usually have an integrations team to help connect Jira and other data sources. In fact, we worked with a large organization to consolidate Jira instances to better connect data to their business intelligence platform. In just 12 short weeks, they were able to analyze and report on their current execution progress simply by being able to feed consolidated Jira data into their business intelligence platform. 

At Praecipio Consulting, we have extensive integrations experience across a wide-range of technologies. We can recommend Atlassian Marketplace apps as a fit-for-purpose solution or we can work with third-party integration engines to help you map data for enhanced metrics. 

Take a moment to step back and really examine your use of spreadsheets. While, again, they have a purpose in this world, to a hammer, everything looks like a nail. The spreadsheet is dead. Long live the spreadsheet. 

Topics: atlassian blog best-practices kanban scrum reporting support-live-music eazyBi jira-align advanced-roadmap business-intelligence
2 min read

Should Stories & Bugs Follow Different Workflows?

By Joseph Lane on Mar 31, 2021 10:07:00 AM

Blogpost-display-image_Should stories and bugs follow different workflows-The short answer: Not really. Stories and bugs are both software development items by different names. As such, the vast majority of activities and controls that we model for a story are applicable to bugs. The key distinction between stories and bugs often comes down to data. Bugs should include Affects Version/sSteps to Recreate, Expected Behavior, and Actual Behavior. How and when we require this data relies on what practices we're observing.

For teams using Kanban practices where there is a Backlog status and a Ready for Development status, the transition to Ready for Development can be used to capture required data based on issue type. In this simple case, we would have two transitions from Backlog, Ready for Dev and Ready for Dev - Bug. For each transition, include a transition-specific screen to capture the appropriate fields.  Example: SDLC Ready for Dev - Bug Transition Screen will include: Affects Version/sSteps to Recreate, Expected Behavior, and Actual Behavior in addition to any other fields needed in both cases. Then, leveraging your workflow conditions allow the Bug issue type to only use the Ready for Dev - Bug transition. All other issue types can default to the Ready for Development transition by explicitly checking that the current issue type is not a bug.

The considerations above work well in workflow cases where you have gated controls as a function of status change. This might apply to teams that include requirements definitions and design efforts within the story or bug life cycle (as might be the case with Waterfall). Additionally, this logical approach allows for workflow reuse which in turn decreases administrative burden and increases process consistency.

Scrum teams view Ready for Development a bit differently. Good Scrum practices dictate that product owners will refine their backlog as items are prioritized upward. Refinement provides all functional details necessary for the scrum team to be able to work the ticket including validation of bug reports and associated details. Once prioritized, the development team will review stories and bugs at the top of the backlog to make sure they understand the requirements. The work is considered Ready for Development at the moment it is accepted in to a sprint.

I hope this explanation helps you avoid unnecessary workflows!

Topics: blog best-practices bugs kanban scrum workflows software-development coding
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
5 min read

Agile Home Improvement Using Atlassian Tools

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

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

Trello vs Jira Software Cloud

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

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

Screen Shot 2019-04-05 at 2.22.48 PM

Screen Shot 2019-04-05 at 2.20.44 PM

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

Bamboo* as the Foundation

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

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

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

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

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

IMG_3837     IMG_3835

IMG_3836

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

Home Improvement Retrospective

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

What did we do well?

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

What could we have done better?

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

What actions can we take going forward?

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

Continuous Improvement 

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

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

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

Kanban vs. Scrum: Which One and Why?

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

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

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

What is Kanban?

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

What is Scrum?

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

Which method is right for me?

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

Topics: blog scaled-agile kanban scrum
2 min read

Here Comes the Product Owner: Wedding Planning with Atlassian

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

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

 

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

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

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

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

 

HAPPY VALENTINE'S DAY!

Love,

Praecipio Consulting

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

Rapid Board for Kanban

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

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

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

What’s the Rapid Board?

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

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

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

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

Work Smarter

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

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

Keep Issues Moving Across the Board

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

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

Upgrade Jira & GreenHopper

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

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

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