We were recently in New York City visiting with one of our customers and I couldn't help but reflect on how far both Atlassian and Appfire have come with the delivery of Atlassian-based solutions within the Enterprise.  Hard to believe, but it's been over 5 years since our first enterprise deployment of Atlassian tools. I'll be the first to admit that in looking back, it was a gamble.

In a recent conversation with Alex Estevez (Atlassian's newly appointed CFO), I explained how over the years Appfire has helped drive Atlassian into the Enterprise. During our conversation, I used the phrase: "our leap of faith".

So, why did we do it? What motivated us to take on the Enterprise in Atlassian's largest market segment (North America)?

Experience - There Simply is no Substitution

We are fortunate to have assembled an amazing team here at Appfire - comprised of engineers and advisers who come from some of the world's largest enterprise organizations. It's that experience, which allows us to fully appreciate the challenges and complexities associated with building product within global, desperate organizations - who struggle to balance the sea of changing priorities, resource restrictions, communication breakdowns and re-orgs. We were there not too long ago.

As I mentioned to Alex... "we came from the Enterprise". Our team was there when all the rules changed and we realized something very real, and very special. We learned that collaboration tools, combined with the adoption of new methodologies would be required in order for the Enterprise to remain competitive, ... or as I like to say "sit above the fold".

To maintain a strong global position, shrinking enterprise organizations were required to:

• Make immediate adjustments in the way they operate day-to-day
• Learn how to work transparently
• Set proper expectations within their organization and make schedules more predictable
• Hold themselves and their teams accountable for the commitments they made
• Introduce a level of traceability throughout their process

There was little doubt in anyone's mind at the time that the rules had indeed changed. The only doubt was whether these organizations could adjust and rely on new tooling and new methodologies to support the required acceleration in product development.

Perspective - It Makes Tough Questions Really Simple to Answer

I'm frequently asked whether or not "Atlassian tools belong in the Enterprise", or "if they're ready"?

When I'm asked this, I like to refer back to a conversation I had with an architect at a large financial institution. At the time, we were working with them on a wide-scale deployment of Confluence. I was sitting in our customer's conference room, filled with project stakeholders, and the architect looked across at me and said:

"... Randall, can you please explain why we're having performance problems with Confluence. I would expect a product, especially an enterprise product to scale out of the box!"

He went on to say:

"... I don't know of a single enterprise product that doesn't scale once installed!".

This is where perspective comes in handy.

My response was this:

"... Really? I know of plenty. Take Oracle for instance. Oracle, (in their own words) make the world's most scalable, dependable, unbreakable database on the planet. Their products have been around for three decades. I personally don't know of a single global fortune company that doesn't rely on one or more Oracle products? I've also worked with several of these fortune organizations and they were just as surprised to find that their out-of-the-box Oracle product wouldn't scale without some sort of intervention."

In fact in a past life, I made a healthy living traveling the US, parachuting into some of Oracle's largest accounts to help with scalability concerns. Did this mean that Oracle at the time didn't belong, or wasn't ready for the Enterprise? Of course not!

Fast forward to today and I see similar things with respect to performance and scalability with Atlassian, as I did while working with Oracle. Customers who have incorrect expectations about Atlassian's products. Missing or missed configuration settings. Untrained users. Customers trying to use the products improperly, falling victim to one or more anti-patterns.

Perspective has taught me to understand that the answer to the question of whether or not a product "belongs" or is "ready" for the Enterprise depends on both the direct and indirect value it provides to the organization.

Atlassian's products help accelerate product development within any sized organization, and because of this, our enterprise customers have found a great deal of value their use. The fact is, each day, Atlassian and Appfire see more and more large organizations adopting Atlassian's tools.

Here are two awesome examples of Atlassian being used within the Enterprise.

Partnership - It's More Than a Word

Appfire wouldn't be Atlassian's largest and leading provider of enterprise solutions in North America if it wasn't for the 400+ amazing Atlassian's who support us each day! Their commitment to their products, their partners, their customers (and ours) - is what gives us the confidence to deliver awesome solutions to the Enterprise day in and day out.

Read more or contact Appfire to learn about how the Enterprise relies on Atlassian and Appfire!

Why? Well, to me a backlog represents your product's future and it's not something that should not be taken lightly. The contents and quality of your backlog are a clear indication of how invested your organization is in the future of your products. When teams embrace their backlogs and invest in them, what they are really doing is securing a place for their products future.

Put simply, products without backlogs will eventually disappear.

Grow it!

In my first post, I wrote about the importance of "building it bigger". A bigger product backlog allows your team to plan ahead of your active Sprint. Looking ahead allows you to make important adjustments to your product, marketing and sales plans, which in turn helps to protect the interest of your product and everyone involved.

Organize and Work With It

My second post described how you can take control of your backlog, organize it, and begin to
"work with it". Within that post I walked you through a process that I use, and have found success with, while managing large backlogs. It also stressed the importance of "seeing" your backlog.

Commitments Made Against It

Although building bigger and working with your backlog are vital to the success and future of your products, so too are the commitments that are made against your backlog.

At Appfire, we help the Enterprise ease into, stabilize, and reach their "Agile Nirvana" by leveraging Altassian tools. While working with our customers, we often witness commitments against the backlog which should never have been made. Commitments, with promises to deliver specific features within your product.

Commitment [kuh-mit-muh nt] noun - a pledge or promise; obligation

It's a common mistake, and even though it's unintentional, unfulfilled commitments can jeopardize the credibility of your product organization.

Don't get me wrong, I'm not saying teams shouldn't commit to delivering features within a release or across a set of releases. No, what I'm saying is don't commit to delivering specific solutions before you are certain they can be achieved. Instead, only commit to delivering headline goals.

For example, as a product owner, let's say you sit down with your sales and marketing team to highlight future releases. Instead of describing in great detail how a new feature will work, how it will function, what it will look like, how the user will interact with it, how many clicks, how many buttons, the exact dimensions, etc. - you should instead simply provide them with a high-level description of the feature, it's purpose, and it's value within the context of your product. By doing so, you are much more likely to set proper upfront expectations and avoid disappointment.

As you get further into your release cycle, and as feature development is underway, you can then begin to unveil and discuss how a feature will function.

Your backlog is a critical component to the success of your organization. Grow it, see it and be mindful of the commitments you make against it!

Atlassian's latest 4.0 release of Confluence is Powerful, Stable and Scalable for the Enterprise.

When it comes to the adoption of new product versions, or change in general for that matter, our customers are not what you'd consider "early adopters", nor would you consider them the "early majority". They typically fit within either the "late majority" or "laggard" segments of the market. They're typically risk adverse. Given their size, distribution, and what's at stake, I can't say I blame them.

Confluence as a Critical Building Block

Most of our customers leverage Atlassian's Confluence as a primary collaboration platform. For some, Confluence acts as a communication conduit between product, engineering, quality, and operations teams. Others rely on Confluence to host information derived during inception or elaboration phases. In all cases, we see Confluence helping to accelerate product development.

Because of the role it plays within these organizations, Confluence is a platform that most consider "critical" to their business, and therefore, they must be vigilant about how and when they apply upgrades to the product. Our customers' current Confluence versions typically range from 12 to 36 months behind the latest release point.

So, you can imagine how shocked I was to learn that we had already received 3 phone calls from enterprise customers the day that Confluence 4 was announced this week, asking if they could be added to the top of our upgrade list!

A Shift in the Enterprise

So why the sudden change?

What motivated these large organizations to call and push for this release so quickly? What could possibly be tempting them to look past their rigid standards and adopt something brand new to the market?

Those of you familiar with Confluence 4's new features might be reading this post and saying to yourself: "Well of course! It's because of the new "@mentions", or "...the new editor", or "...add-ons", or "...no more wiki markup".

Sure, all of these exciting new features are certainly a compelling reason to upgrade, but Atlassian has released hundreds of awesome features in the past. If features were truly the reason, surely we would have witnessed a similar response with previous Confluence releases.

However, that's not what's happening here. What's happening here is a shift!

It's the realization that Confluence as a product, as a platform, as a primary mechanism for enabling collaboration within the Enterprise has matured.

Companies have witnessed a steady track-record of successful, stable releases of the product and they've learned to trust new GA versions of Confluence. IT organizations within the Enterprise don't delay their upgrades for critical platforms so they can starve users of new features. They do it so they can wait for the product to gain market adoption and harden. So that critical defects can be shaken out. So that incompatibilities can be discovered. They do it to mitigate risk.

To me, this shift is a clear signal that the Enterprise has finally found a collaboration solution which provides as much benefit to the teams who manage the tools, as it does to the end users who leverage them.

Atlassian promotes that Confluence 4 is Faster. Richer. Simpler.

At Appfire, we say Confluence 4 is Powerful. Stable. Scalable.

Right now, some of you may be overwhelmed with the amount of items contributed. For many, this may be the largest volume of epics and stories you've ever worked with. Staring at your list, eyes glazed, you might be thinking: What next? How do I organize? How to prioritize? What do I commit to? or even Where the f*** did that story come from? Working with large backlogs can invoke feelings that are similar to staring at a huge sink full of dirty dishes. Am I right?

First of all, don't worry, because you're not alone. It's perfectly natural to feel a bit overwhelmed at first. For many, this is largely due to how the mind copes with large lists of electronic information presented all at once. What we first need to do is pair the list down into smaller, more easily digestible and manageable chunks of information. We need to give our eyes less information to look at, so we can process it more efficiently and swiftly.

Over the years, I've devised a very quick and simple method for working with large backlogs which I'd like to share. When working with our customers, I often mention that the best way to work with a large backlog is to start by seeing it!

It's hard to process or efficiently take action against a list that can contain hundreds (or thousands, as is the case with some of our customers) of stories. To do so, you need to be able to apply various filters against this list in order to manage and quickly take action on the stories contained within. I typically filter stories within backlogs in three ways:

• By Epic
• By Segment
• By Value

Of course, in order for these filters to work properly, you have some work to do.

Associate like Stories with Epics

Your first task is to scan the list and associate each story with an epic. If you can't find a fit between a certain story and an existing epic, you should either create a new epic, or just flag the story so you can review it again after you finish processing the remaining list. Here at Appfire we use Atlassian's GreenHopper, which allows us to flag stories by applying "labels" to them.

When I come across stories that I can't match to an existing epic, I usually label them as "orphans", so I can quickly search and build a list to manage them at a future point in time. During this first pass, you shouldn't add new or modify existing stories. Instead, just focus on this upper-level grouping of stories to epics.

Segment your Stories

Now that you have your stories associated with epics, your next step is to quickly segment them into various "logical groupings" or buckets. By doing so, not only will you be able to quickly isolate one segment from another, but you'll also find that it helps you focus and take action on stories, moving them closer to scheduling. Note that this is not a physical segmentation of data, but rather a logical one, using flags or labels (or whatever feature your tool supports). Personally, I like to segment stories into the following five major buckets:

1. Completed Stories

Stories should be segmented into the "completed" bucket once you're happy with the detail and definition of the story. Although marked "completed", they of course still require action. They require prioritization, estimates, points, and further downstream you'll need to associate tasks.

2. Incomplete Stories

A segment of stories which require additional refinement, or expansion to the actual story, before they can be reviewed by a larger team and have effort or story points assigned.

3. Large Stories

Lengthy stories may be difficult for teams to digest and work with. When you come across stories like this, I often suggest breaking them up into smaller ones. All too often, I see teams struggling to comprehend, assess complexity, define tasks, and assign resources simply because their stories are defined at too high a level. As a Product Owner, it can be difficult to break stories into small pieces. By segmenting them, you can task others within your organization to help you with this work.

4. Sounds like Another Story, Stories

While segmenting your backlog, it's not uncommon to find duplicate or near duplicate stories. When found, you should try to merge these records into a single one. However, if you have a legitimate reason not to consolidate, then at a minimum, you should consider segmenting these stories from others so you can isolate and work with them in the future.

5. WTF Stories

If you stumble upon one of those WTF stories, where you aren't sure how or why it ended up in your backlog, your natural reaction may be to remove the story from your list. Don't delete it. Instead flag or label this record for a future review. It may feel better to reduce your lengthy list, but after some time, you may recall why this story was added.

Helpful Hint: When segmenting your backlog, you may be tempted to author new stories, that your team overlooked while growing it. I would encourage you to simply add a placeholder with a label, so you can return to complete the story at a future date. This will allow you better focus on the exercise of segmenting your stories.

Assign Value to your Completed Stories

As a Product Owner, you need to assign a value to each story within your "completed" segment. I say against the "completed" segment because all other segments will require additional action before it makes sense to assign this value. Of these filters, this in my book is the most important because it allows you to quickly isolate and work with stories in your backlog that have the largest potential impact on the shape (and value) of your product. You should be spending the most amount of time on this set of stories. Your focus and attention should be on them, ensuring that you're doing everything possible to move them from "unscheduled" to "scheduled".

By assigning filters to a large backlog, you can go from being overwhelmed by it, to finally "seeing it"!

While working with these customers, we often focus on better understanding the results of past Sprints. Looking backwards is one of the fastest methods to identify patterns of poor execution or performance, especially with teams who have not yet discovered the benefits of conducting retrospectives.

If I were to sit down and build a blame pie to highlight the top items we've identified while working with customers, at the very top of the list would be this:

The inability to properly triage and resolve issues discovered while working on complex tasks.

When we take a deep dive with our customers to better understand why some stories have been "blown" within Sprints, we typically hear about how "an unforeseen issue crept into a particular task, which forced some individual within the team to invest many more hours than originally estimated to try and resolve it and complete the task."

Sound familiar?

In reality, this isn't really the problem. Identification is rarely a problem amongst teams. We also very rarely find notification to be a problem. What IS a problem however, is how teams move forward when issues like this are identified and raised to the larger group. In practice, we see teams who do a great job of alerting their peers and scrum master of an issue. What we DON'T see are teams reacting to the issue in order to try and resolve it quickly and collectively.

I often refer to this as the "pile on approach". When an issue is identified, the team (or scrum master) should triage the issue in order to determine if other members, or even the entire team, need to try and "pile on" in order to resolve it collectively.

I've been using this "pile on approach" for about a decade with great results. It's not a difficult concept to understand or implement, yet we rarely see it being used by our customers. This may be due to culture or bad habits, or maybe because teams tend to over-commit in Sprints and forget that things happen.

In agile, we succeed or fail in the delivery of a Sprint as a team ... so pile on!

I wasn't surprised.

After all, who better to understand the power and influence that positive emotions have on the performance of individuals and teams, than my fellow Agilers. (Remember: it's individuals and interactions over processes and tools.)

Clear Advantages

Although this was my first time meeting with Dr. Fredrickson in person, I was introduced to her work about 12 months earlier while we were performing research for a new product being developed here at Appfire. In her book "Positivity", which I found deeply insightful and thought provoking, she chronicles the results of some lengthy research she and her colleagues performed around the benefits of being positive.

The results were nothing short of astonishing.

I highly recommend this book, especially to anyone interested in understanding why positive people generally have an advantage (both personally and professionally) over those who live a life plagued by negativity. While designing "Niko-Niko", her book and other publications helped provide validation for some early assumptions.

Niko-Niko: Team Mood Calendar

Niko-Niko is a "Team Mood Calendar" plugin for two of Atlassian's flagship products: JIRA and GreenHopper. It allows product teams around the globe to monitor and analyze the important role that human behavior plays on product development. The plugin helps product teams embrace the human element by providing JIRA and/or GreenHopper users with the ability to easily record, track and trend their team's "emotional tone" across each Project and/or Sprint.

Why Niko-Niko?

• Because there's a direct, one-to-one, correlation between your Mood and your Productivity.
  
  
• Because with visualized mood data you can evaluate and improve how you interact with individuals and teams.
  
  
• Because humans are the most important assets we have!
  • Humans Innovate.
  • Humans inspire and become inspired.
  • Humans learn, adapt, teach & grow.
  • Humans strive to achieve goals.
  • Humans motivate and become motivated.
  • Humans design, create and drive your products to market.
    
• Because products get better when your people, your humans, are at their best!

Positive Results

In the coming weeks, I look forward to re-connecting with Dr. Fredrickson to share some results gathered from customers using Niko-Niko. I'm certain that after her experience at Agile2011, she'll be excited to see the impact human behavior has on Agile teams around the globe.

Positive energy is contagious, it's powerful, and it's all around you. So what are you waiting for?

My colleague Mick Flanigan and I traveled out to Utah to attend Agile2011. We were fortunate to have spent the days leading up to the event with two of Atlassian's finest: Nick Muldoon, Product Manager of GreenHopper - Atlassian's Agile Project Management Solution and Edwin Wong, Product Manager of Bonfire - Atlassian's Rapid Agile Testing Solution. I couldn't think of a better way to embark on this historic conference (Agile turning 10!), than in the fine company of these guys. Not only do the four of us share the same passion for Agile, but we also all firmly believe that Atlassian's offerings allow customers to embrace Agile more flexibly, and at their own pace, than any other products on the market.

Alleviating Challenges Common with Agile Adoption

Personally, I've been practicing a form of Agile since 2001. Prior to that, I traveled the globe for one of the worlds leading medical device manufacturers helping them to enable lean across the organization. I've experienced a tremendous amount of tools in that time and I'm lucky enough to have gained a unique perspective that spans a variety of roles. From an engineer developing product - to an architect designing product. As a manager responsible for a worldwide distributed team - to a product owner tasked with ensuring that the needs of a growing marketplace are met. Today, I help lead a talented team here at Appfire to deliver Atlassian-based solutions and training for enterprise organizations who fuel innovation, drive markets and create product that have a meaningful and lasting impact.

At Agile2011, I spent time with Agile practitioners, both new and old, from all over the world. As I sat down with each to discuss their own unique experiences with Agile and ALM tooling, one subject came up over and over again: Agile adoption proved to be more difficult than their company had expected.

When asked, each listed a variety of factors that attributed to their poor adoption. Here are some of the most common:

Improper Training

Many organizations expect that their teams will "just learn" Agile, or will "pick it up on their own". As a result, they often neglect to plan or budget to provide professional training to everyone who's expected to transform. This always bewilders me. You've made the choice to change your core methodology, to shift from something that's been deeply rooted into the fabric of your product development organization for years, and you thought that everyone would "just pick it up"? Several people who I sat down with at Agile2011 had been practicing a form of waterfall for almost two decades. When I discuss Agile adoption with anyone, the first thing I mention is the change that it represents in individual behavior for everyone involved. Behavioral changes are best made in unison, not in isolation. A strong foundation, will drive your Agile transformation.

No Management "Buy In"

I applaud companies who attempt Agile. It doesn't matter if your primary motivation is to produce better quality product, to release more frequently, to gain advantage over competition, or just because all the cool kids are doing it. ;)

There are pockets of small teams everywhere who make the decision to try Agile on their own. Many of them do it right. They start with training. Next, they execute a Proof Of Concept (POC), developing something that can be measured against their previous methodology. Small adjustments are then made and maybe the POC gets repeated. For the first time, they look at their product roadmap as building blocks instead of one large product. Finally, they begin executing their product development in Sprints. Success!

However, there's a common pitfall that we see all the time. Many teams neglect to involve executive management. As a result their tactical implementation can conflict with their overall strategy. This is a much larger topic that I'll blog more about in the weeks ahead.

Tool Rigidity

Of all the points raised during my discussions at Agile2011, "tool rigidity" was by-far the most highlighted topic.

You might be thinking:

"Hey, it's Agile, the tool doesn't matter, right? It's right there in the Manifesto: Individuals and interactions over processes and tools."

Although I'm a big supporter of this statement, I'm also pragmatic and I strongly believe that if your tools aren't working with your methodology then they're working against you!

Many of the folks I met with felt that the tools they initially adopted were "too rigid" - mainly because Agile was the only methodology they supported. You couldn't work with some teams who were trying to adopt, while others were still using their existing methodology.

Another area of concern was that their initial tools "lacked integration capability" which was required to tightly integrate within their environment. Many of the tools available today lack commercial integration points or interfaces which enable the product to be integrated or extended for custom use within an organization. If you want a tool to fail in the Enterprise, lock it down.

As a result, I spent a lot of time at Agile2011 explaining how Atlassian's tools where different - how they're focused on the engineer and the acceleration of product development rather than on the product owner and their role to define a product. I boasted about the ability of the tools to support agile and non-agile methodologies concurrently. I described how easily they can be integrated with other tools within the Enterprise, listing off dozens of real-world examples. I spoke about the 'openness' and 'plug-ability' of each of the Atlassian tools.

I've said many times that Agile is a transformation, not a proclamation. You need a tool (and a tool provider) who understands and embraces this. You want a product that provides you with the ability to "ease into Agile". Atlassian is that provider and their products yield remarkable results.

When we coach agile teams, the first things we want to see are: (a) how many Sprints have been planned ahead of the current (active) Sprint, and (b) how many unplanned stories are in the backlog. Combined, those two metrics usually provide a good indication of whether a company subscribes to the myth.

Small Backlogs Make it Difficult to Plan Ahead

Product teams that have a small backlog often have a hard time planning ahead of their current Sprint. We like to see our customers planning between three-and-five Sprints ahead of the current (active) Sprint. Your next two Sprints will ideally be planned in detail, with further Sprints remaining at a high-level.

When we hear customers say things like: "...we haven't finalized the plan for our next Sprint", or "...we didn't want to publish our next Sprint plan because it might set improper expectations", it's likely because their backlog is far too small. The real reason they don't have future Sprints planned out is because the exercise of planning is frustratingly difficult when you don't have a clear idea of what your product team is going to be working on.

Harboring the Myth can be Dangerous

This problem often goes unresolved within teams. I've seen cases where it's lasted for years (many generations of a product). As humans, we find ways to busy ourselves for the next Sprint. At the last minute we'll devise a plan to execute against. There's no doubt that the plan will include some items that we feel are important to the future of the product. Maybe some "technical debt" that's been building? Maybe we spend a Sprint cycle prototyping something that the team has been looking to introduce? That's how we justify it away from being a non-productive Sprint.

Harboring this myth for an extended period of time has a significant and long-lasting negative impact on your product. The longer you harbor this myth:

• The more likely it is that you will delay the release of your product.
• The more expensive it will be to produce your product.
• The less innovative you will become.
• The more likely it is that you'll allow your competitors to win more customers.
• The less informed your product team (especially Sales and Marketing) will be on the future roadmap of your product.
• The less informed your customers will be of your future plans for functionality which impacts their use.
• The greater the chances that your product will not make it another generation.

Your Summer Project - Help Build a Bigger Product Backlog

With this myth in mind, we've prepared a summer project for you. Ask the following questions about your product, and encourage all of the members of your team to participate - including engineers, support, marketing and sales:

• Think about the features or functionality that do not exist in your product today, but should.
• Look closely at your competitors. Review their features and compare them to yours. Analyze what they're saying about the direction of their product and determine if that direction also makes sense for yours?
• Review what analysts and experts are saying about your products and your industry.
• Ask your customers what they would like to see in your product. Your customers are often your best idea generators. You know who they are, where they are, and usually all you need to do is ask!
• If you have partners who OEM, distribute or integrate your product with theirs, ask them for their feature input.

The bottom line is that your PO is not solely responsible for building your product backlog. It's the job of the entire product team. If it looks like your team is harboring this myth, then it's time to take on our summer project and help grow your backlog!

Building a bigger product backlog allows your team to plan ahead of your active Sprint. Looking ahead allows you to make important adjustments to your product, marketing and sales plans, which in turn helps to protect the interest of your product and everyone involved.

Is your team effectively planning, or just harboring a myth?



So where do Atlassian and Appfire fit into all this?

One word: Acceleration!

Gaming is like any other product development. If you can accelerate your process by compressing your design, development and test cycles, and still deliver a quality product to market, you'll have the ability to produce and sell more for less. I know it sounds simple, and in theory it is.

But how? Companies have been trying for years to accelerate product development. Organizations are in a constant state of tuning and tweaking their processes to reduce cycles wherever possible. Yet the results are often disappointing, especially when you consider all the effort invested.

This is where Atlassian and Appfire can help!

Atlassian - Focused on Engineers

Atlassian has developed an outstanding suite of tools centered around the amazing humans who build your products. Atlassian's products help teams to design, develop and test software more rapidly ... and they do it in a way that is so simple, it's almost magical!

At their core, these tools were built to help eliminate the cycles that each engineer is separated from his or her IDE. They've been designed and integrated in such a way that product developers can spend less time drafting countless emails and attending long status meetings and more time where they should be: designing and authoring code.

Also, unlike some other competitive products on the market, Atlassian has designed their suite to focus more on the needs of the actual engineer, rather than the business or product owner. Beyond that, they've also taken the time to carefully understand the needs of engineers specifically within the gaming industry. This wise investment has resulted in some of the most advanced features now contained within Atlassian's products. Today more than 150 of the world's leading gaming companies leverage Atlassian technology. To me, it's no coincidence that these companies happen to also be the most respected names in the industry - the ones driving innovation, defining boundaries, and setting pace!

Appfire - Focused on Acceleration

At Appfire we're proud to be America's leading Atlassian enterprise solutions provider. Widely regarded as experts in Atlassian's software products for the Enterprise, our customer base spans all major markets including Technology & Electronics, Internet & Software, Banking & Finance, Retail & Food, Engineering & Aerospace, Automotive & Travel, Health & Biotechnology, Entertainment & Media, Telecommunications, Universities & Academia, Government, Science & Research, Consulting & Services, Professional Associations, and of course: Game Developers!

We develop Atlassian-focused products and provide expert enterprise services which enable some of the world's most advanced product development teams to quickly innovate, develop and drive their products to market.

If you're ready to learn more about how Atlassian and Appfire are helping our customers accelerate their product development, contact us today.

Game on!

These early warning signs help to keep you on track with the rapid changes you face throughout your Sprint. However, if left unchecked, you could end up in a situation where instead of completing your Sprint, you're simply trying to salvage it.  

Regardless of the tools you use to keep track of your Agile projects, there are a few leading indicators that you can easily track on a daily basis. If I had to pick only three, they would be:

1. Required Tasks to Complete Today
2. New Issues Created Today
3. Human Emotion

Required Tasks to Complete Today

When a Sprint first begins, your team knows exactly how many tasks have been allocated. Your Sprint duration (length in days of your Sprint) is also well known and defined before the start of your Sprint.

If you were to take the total number of tasks allocated and committed-to within your Sprint plan, and divide that value by the number of days that remain in your Sprint, you would find the average number of tasks you need to resolve each day in order to complete your Sprint. Of course the actual number you complete each day is highly dependent on complexity, so you shouldn't expect your team to follow this exact value on a daily basis.

When coaching teams through their Sprints, or looking back and helping them to make adjustments during a retrospective, I'll often shine a spotlight on this value. In almost every "blown" Sprint that I've witnessed in my 10 years of working with Agile teams, this value was on a steady rise early in the Sprint. Had they been monitoring this value, the Sprint teams may have been in a position to make early course corrections.

Most of the customers we work with today are using Atlassian's GreenHopper as their Agile tool of choice, and fortunately for them, the product contains a number of helpful "burnup" & "burndown" charts to easily monitor ongoing progress with respect to task completion.

New Issues Created Today

Let's face it folks, no matter how much planning you put into your Sprints, none will go exactly according to the plan you've drafted. For most, you'll see a number of new issues (defects) created throughout your Sprint. The vast majority will be entered as your quality organization begins to test the ongoing effort within your Sprint.

This chart is from an Appfire customer running GreenHopper. This view is a section of the "Issue Burndown Chart"

Early access to your software is key to providing an early preview of the quality, and in-turn identifying whether or not any adjustments are necessary. For many organizations, we find that a large contributor of these new issues during a Sprint are unplanned events or "Business As Usual" events. These are typically production or field-impacting issues. Monitoring these as they occur is the most effective means to governing your existing Sprint activity. Paying attention to these values also allows you better plan for future Sprints.

The example below, depicts a two-week Sprint that is four days from completion. Throughout the Sprint, we see zero new issues being created. However, with only a few days remaining in the Sprint, we see a sudden / sharp increase in "newly created issues" (the blue line). If our team wasn't paying attention to this value, it would be extremely difficult to make the necessary changes in our daily plans to address them.

Human Emotion

Here's something that we see time and time again: Sprints that have been properly planned and are tracking according to plan, right up until the end of the Sprint ... then, for some "unknown" reason, the Sprint takes a turn for the worse and is eventually blown.

While attending retrospectives of these Sprints, we'll often hear issues raised which point towards circular circumstances (excuses) that have zero actionable items. In almost all of these cases, it's human emotion that's at play, and it's what has driven the Sprint to it's non-completion.

Humans run on emotion and there is a direct, one-to-one correlation between your mood and your productivity. Left unchecked and your Sprint could be repeatedly blown.

To keep track of your teams emotions, Appfire has developed Niko-Niko, a Team Mood Calendar plugin for Atlassian's JIRA and GreenHopper.

What leading indicators are you tracking in your Agile practice?