It’s one of the most common applications for managing software projects, but it’s not just for project managers. More and more software developers find themselves behind the wheel on a Jira project, but without the tools or knowledge to make it work best. But with this Jira for developers tutorial, I aim to show you how to make Jira a valuable tool for you and the rest of your team. Whether you’re having to plan a project yourself as a developer, or just want to know more about how to use Jira better, this tutorial is for you.

The truth about Jira

Jira is designed to be a tool for agile project managers. And most of the official documentation is written with this in mind. But the reality is that people use Jira in a variety of non-agile projects—and many of those people aren’t even project managers.

Most developer-targeted Jira documentation is written with the idea that, as a software developer, you’ll mainly just want a nice dashboard to look at the issues that someone else assigned to you. Wishful thinking. In many organizations, developers have to at least occasionally plan projects. And even if you aren’t planning them yourself, knowing how Jira works can help you consult with your project manager to make the best use of Jira.

And let’s be honest. Many organizations don’t make the best use of Jira. The first time I used Jira was in a very large enterprise environment. The project managers just opened up a project using the default settings of a template called Scrum.

The problem was that most people on the team had zero familiarity with agile. Terminology like “stories” and “epics” confused them. No one knew what a “Scrum” was.

Jira based its Scrum template on organizing a project into discrete “stories” with a point value indicating the level of effort required. These are then put into “sprints,” which are short periods of work. Unfortunately, none of us really knew how to do any of this properly, so our sprints disintegrated. This made our entire team look bad to upper management and clients.

We made our problem much worse by adding all kinds of fields into our issues. Filing an issue required facing a form with over 20 fields. We thought we were making our project easier to organize, but we were instead just adding layers of complexity.

We also tried to create some custom workflows and roles to make everything easier, but we ended up with such high complexity that we’d spend a lot of time just dealing with that and not working on the software we were supposed to be building. The most common email our project manager got was “Help, I accidentally created an issue and I can’t delete it!”, or “I can’t figure out how to move an issue into testing.”

Jira done well

These days, I know better. If I’m creating a project from scratch and mainly leading it myself in an environment where agile knowledge and practice is spotty, I keep it simple. Thank goodness that the latest version of Jira has a new template called “Agility.” This template is much simpler and contains significant usability improvements.

In previous versions, adding an issue presented you with a large and unwieldy form with unnecessary fields. Now, you can click to add a task instantly!

Need to add a “testing” stage? I usually do, for things going through QA. Before this version, you had to configure a workflow. Now you just add a column and drag it where you want it.

If this all seems a bit familiar to you, remember that last year Atlassian bought Trello. So this is pretty much like a Trello board. It’s also something that is easy for anyone to understand at a glance.

Another boon is it uses only labels for organization. Previous versions of Jira had a baffling array of options to choose from for organizing things ranging from epics to components. You should only use these when you need them—and usually, that’s never.

Now if you’re using previous versions of Jira, I am very sorry. Getting a simple project going is frankly just not very easy. I usually start from “Task tracking.” This at least has a pretty simple task structure, though adding in a testing stage involves configuring a workflow.

Other versions of Jira have the “bug tracking” template, which is also called “basic software development.” Unfortunately, it’s anything but basic. In this situation, I recommend removing agile-style issue types such as “epic” and “story” unless your team really knows how to do those right.

Jira’s default fields are also an area I simplify. Most just don’t get any use on a no-frills developer-led project.

If your install of Jira is very very old, you may only have access to one other template besides Scrum, which is Kanban. The name has caused all kinds of confusion. Kanban is a system of workflow optimization that predates even agile, and Kanban practitioners have never been thrilled by people using Jira and thinking they’re doing Kanban. Either way, it’s a board similar to the Agility one (though sadly much harder to use).  And at least it doesn’t assume everything is organized into sprints. I definitely recommend the Kanban template over the Scrum one, if you don’t have access to anything else.

But I don’t have admin access to Jira!

I’ve been in this situation too. Here, I just keep it simple. I work with my team to talk about how we’ll use the settings we have.  We identify and prioritize just a few customizations that we can ask the admin for. And make sure to allocate time for training people who need specific instructions on using Jira, such as QA or contractors.

Getting the most out of Jira

Even if you’re not in charge of Jira in any way, it’s still a valuable tool that you’ll want to get the most out of, whether by integrating it with other software or using it to optimize your software process.

Integrating your favorite software

These days, many software products have Jira integrations. My favorite ones are those that allow you to pass data into Jira to create issues. At Stackify, for example, they use Zendesk to create issues in Jira. Also, you can easily make issues out of things caught by Stackify itself.

Of course, there is software that will create issues automatically, but I recommend first testing these integrations with a test instance of Jira, lest you flood your product with hundreds of erroneously created issues. Someone I know did this—they accidentally had all warnings in software tests turned into issues. Oh and the issues all got emailed to everyone. And it crashed their email server. Hilarious, unless it happens to you.

Custom tracking

Now as I said before, creating too many custom fields can be a problem. But sometimes a custom field really can be a solution. My general rule is to think about the business case for tracking something. Is the time saved by this solution more than the time spent filling in (or even scrolling past) an extra field? It might be worth it. Treat this as a potential cost and measure the results. If it’s not working, remove it. For example, Stackify created a custom field to track which stage in deployment a bug was found. They use this metric to keep costly bugs out of production.

Filter with JQL

JQL stands for “Jira Query Language.” It’s worth knowing a bit about JQL because it allows you to do to pull data from Jira in a very precise way. Jira’s own tutorial is a great start. I keep a text file with some of my own favorite queries. For example, I can filter for all the items I’ve sent to testing with this:

status changed from "In Progress" to "Testing" by mmcewen

Or when I was working on a Scrum project, I could pull out all the issues I’d resolved for a particular sprint and show how important I am:

project = LOL AND Sprint = "Sprint 2" AND status was resolved by mmcewen

Here’s the way to use these queries—do a search using them, and then see that Jira gives you the option to save the search as a filter. Use the filters to create custom reports.

Reports

Good reporting is crucial for showing off your work to managers, clients, and other stakeholders. If you’re using a board, that itself is a great tool. But Jira also has great reporting options.

Newer versions of Jira have a nice dashboard that shows your options with a description. The dashboard displays commonly used options first. I often use created vs. resolved, which shows how much work a team both takes in (those bugs QA filed!) and finishes. You can use the JQL filters to drill down and show very specific data.

Is Jira your best friend now?

While Jira can be overcomplicated and confusing, it’s also extremely powerful and flexible. With this knowledge, you can use it to organize projects well, even if you’re just using it on a small team without a project manager. Jira also will be a powerful tool to show off your team’s work to clients and other stakeholders.

With APM, server health metrics, and error log integration, improve your application performance with Stackify Retrace.  Try your free two week trial today

Let’s take a look at the current demand and examples of questions you should ask (or be expected to answer) in an interview.

Demand for DevOps Skills

As more companies and infrastructures switch to cloud computing, the demand increases for professionals with cloud-related skills. Peter Danchak, system administrator for Data Recognition Corp, says the rapid growth of the cloud environment continually opens new opportunities for businesses and workers. IT engineers, software engineers, and cloud architects are among those who stand to benefit most.

Among the top skills for DevOps pros are:

• Skills for using configuration management tools, for example, Puppet, Chef, and Ansible.
• Skills with containerization and virtualization tools like OpenStack and AWS.
• Programming skills in languages like Ruby, Python, Java, and Perl.

Sample DevOps Interview Questions

Below are several examples of different DevOps interview questions, grouped by topic.

Questions on the Understanding of DevOps

What’s your understanding of DevOps?

This query looks for the candidate’s understanding of the overall concept. It can include a discussion of DevOps as a mix of software development and IT operations functions. A correct answer here would highlight communication and collaboration between developers and IT operations.

What’s the need for DevOps?

This question aims to uncover whether the interviewee knows the features and benefits of DevOps. Angles here include technical and cultural aspects, how it relates to the business at large, and its role in transaction processing. The candidate should be able to discuss the ways it can help a business, such as by increasing deployment frequency and providing continual software development delivery.

Interview Questions Surrounding Agile Development

How are DevOps and Agile Methodology related?

Does the candidate know DevOps and Agile teams must work together to reach common goals? The applicant should know the relevance, similarity, and differences between DevOps and Agile Methodology. The job applicant should also be able to explain how a business can continue to meet customer needs while adapting to fast-changing technology.

What’s the role of a DevOps engineer in Agile development?

This uncovers whether the candidate knows his or her key functions. These include continuous delivery, integration, and automated testing. The job seeker should be able to demonstrate a knowledge of the importance of clear communication and close working ties with Agile development team members. Candidates applying for the position of DevOps engineer should also know the importance of close contact with developers.

Interview Questions Relating to Software Deployment

What’s your experience with software deployment?

This question gets at whether the candidate can freely and comfortably discuss code deployment. It also helps to assess if he or she has experience with integration tools and DevOps tools.

How have you managed software deployment failures?

Failures in software deployment are often inevitable. This question asks how the candidate typically identifies the source of a failure and how he or she reacts to real world breakdowns, particularly with respect to troubleshooting skills.

How do you know if something fails in production?

The biggest reason for this question is to learn the candidate’s approach to monitoring. Since monitoring is essential in DevOps work, planning it and implementing it are crucial.

How can Configuration Management tools help with DevOps?

This question tests the applicant’s experience with different Configuration Management (CM) tools. The candidate should understand the functions, advantages, and disadvantages of CM tools, as well as which ones stand out from the rest.

Asking the Right Questions

Asking the right questions is beneficial for obvious reasons, particularly when it comes to highly skilled roles in the field. It can also help you figure out exactly where a candidate might fit in the mix and complement the skills of your existing team. One candidate may be more proficient with the ops side, while another may have a more balanced set of skills – and the best candidate depends on your team’s needs. Asking the right questions enables you to:

• Compare different candidates in the context of skills gaps within your existing team.
• Gain an understanding of the strength of a given candidate.
• Learn a candidate’s facility with key skills.
• Determine whether an applicant has a deep understanding of the big picture of software development as it connects to ongoing operations.
• Understand the ability of a potential employee to improve and ensure collaboration across teams in the DevOps environment.

Hiring for DevOps Roles

Key best practices for hiring go beyond the interview itself and into the company culture. The short list below offers some insights.

• Trust the employee. According to VentureBeat, a former Netflix exec was frequently asked where Netflix got such great employees. His response? “We hired the same people you hired. We just got out of their way.” This is identical to the response of Toyota execs after GM hired away all their top people, then continued to underperform. Hiring the best and brightest experts on the market won’t work if they’re not brought into a company culture that respects their initiative.
• Ignore the “talent shortage.” According to the same article, the greatly bemoaned talent shortage doesn’t exist. Rather than agonizing over how to hire the very best employees, companies should strive to allow the employees they do hire to implement the strategies they know will work best.
• Focus on the big picture. Rather than sweating whether a developer knows exactly which port Kerberos uses or how to configure a GRE Tunnel in Junos, use the interview questions above to get at whether this is the right person for the job. Does he or she have the initiative, competence, and confidence to take on and complete major tasks? In many senses, a great DevOps employee isn’t very different from a great leader in any other discipline. Details can be learned and adopted, while the key quality is the drive and ability to follow through on necessary tasks.

Additional Resources: Hiring and Interviewing Advice

For more sample questions and answers, tips on hiring and interviewing for development roles in today’s competitive landscape, visit the following resources:

• DevOps Job Interview Questions
• What are some good interview questions for a DevOps position?
• 10 Developer Job Interview Tips To Land The Best Job You Can
• 5 Interview Tips to Help Developers Land Their Dream Job
• Java interview questions
• ASP.NET interview questions
• DevOps interview questions

Check out The Culture Issue of our BuildBetter magazine for tips on integrating DevOps, APM, and the developer.

Definition of Pair Programming

As the name implies, pair programming is where two developers work using only one machine. Each one has a keyboard and a mouse. One programmer acts as the driver who codes while the other will serve as the observer who will check the code being written, proofread and spell check it, while also figuring out where to go next. These roles can be switched at any time: the driver will then become the observer and vice versa.

It’s also commonly called “pairing,” “programming in pairs,” and “paired programming.”

Pair Programming Advantages

There are several compelling reasons you should consider this strategy:

• Two heads are better than one. If the driver encounters a hitch with the code, there will be two of them who’ll solve the problem.
• More efficient. Common thinking is that it slows down the project completion time because you are effectively putting two programmers to develop a single program, instead of having them work independently on two different programs. But studies have shown that two programmers working on the same program are only 15% slower than when these programmers work independently, rather than the presupposed 50% slow down.
• Fewer coding mistakes. Because there is another programmer looking over your work, it results in better code. In fact, an earlier study shows that it results in 15% fewer bugs than code written by solo programmers. Plus, it allows the driver to remain focus on the code being written while the other attends to external matters or interruption.
• An effective way to share knowledge. Code Fellows talks about how it could help programmers learn from their peers in this blog post. It would allow programmers to get instant face-to-face instruction, which is much better than online tutorials and faster than looking for resources on the Internet. Plus, you can learn things better from your partner, especially in areas that may be unfamiliar to you. Developers can also pick up best practices and better techniques from more advanced programmers. It can also facilitate mentoring relationships between two programmers.
• Develops your staff’s interpersonal skills. Collaborating on a single project helps your team to appreciate the value of communication and teamwork.

In sum, it helps your programmers learn from each other while coming up with programs and applications with better code quality and fewer bugs.

Alistair Cockburn of Humans and Technology and Laurie Williams of the University of Utah – Computer Science Department have come up with a bullet list of benefits:

• Fewer mistakes are introduced into your code because a lot of errors are caught as they are being typed. This level of continuous code reviews gives rise to fewer bugs in your code.
• You have shorter and tighter code.
• Two people can solve the problems that crop up along the way faster and quicker.
• Your developers learn more about things that are specific to the applications that they are working on as well as software development in general, best practices, and other areas.
• You have more people who know how the new program works. This means that if one of the pair leaves the company, it will not kill the project.
• Your team develops better interpersonal and social skills. Team members can learn to communicate with each other, work together, and share information.
• Your team members are more satisfied.

Why is Programming in Pairs Better than Code Reviews?

Code reviews are a process wherein another programmer takes a look at your code to find something that needs improvement or find defects in it. It combines testing with quality control to ensure that everything in your code is good. This helps you ensure that your code is improved.

However, it is challenging to find somebody to review your code because people may not want to look at another’s code and understand their reasoning just for the sake of checking its quality. Most of the time, code reviews happen when somebody else tries to add some functionality to your code, or fixes bugs. But by then, you, as the original programmer, might not even be around to appreciate the code review.

With pairing, it is like having somebody review your code instantly and regularly. It is a higher form of code reviews. Two people have to be there and understand the program being written. And if one sees problems with the other’s code, then it can be instantly corrected. You also have fewer chances of having bugs written into your code. Code reviews are not as proactive as you have to wait until the code is completed — bugs and all — before somebody could take a look at and correct it.

Challenges of Pairing

The common problems observed when it comes to pair programming include the following:

• The pair should be equally engaged and be participative for the duration of the task. Otherwise, there would be no benefits.
• People who have not tried it may think that it will double the cost because you are putting two programmers on one project. However, this is a misconception that needs to be clarified. On top of the fact that pairing, done right, will only result in 15% slowdowns in terms of the individual output, it actually speeds up the coding process and ensures better quality code, which lessens the chances that the program would have to be redone.
• Pair programming should also be a programming out loud process, where the pair is verbally detailing what it is doing.
• It’s not something that you can force your team to do. It’s highly social and interactive, so you should be able to detect pairs that may have problems with each other, such as clashing personalities or even problems with personal hygiene.

How to Effectively Pair Your Programmers

The best way to approach pairing is to partner two programmers and have them share a computer. Make them work together to architect, code and then test their codes in a genuine sense of a partnership. While the ideal setup would include two programmers who are equally skilled (expert – expert or novice – novice), you can also use pair programming for training and educational purposes (expert – novice).

The pair should be able to decide how to split the work, and it is advisable that they should switch roles often.

Additional Resources and Tutorials

For further reading on pair programming, including helpful tutorials, visit the following resources:

• Extreme Programming – Pair Programming
• Pair Programming Tutorial Video
• Pair Programming Tutorial
• Try pair programming
• Rethinking Pair Programming

Definition of Scrum

Scrum is a software product development strategy that organizes software developers as a team to reach a common goal — creating a ready-for-market product. It is a widely used subset of agile software development.

The word scrum also is used in rugby to define a play where players struggle against each to gain possession of the ball. The goal of a scrum in software development is to perform at a high-performing level like a rugby team does in a scrum.

How Scrum Works

In a rugby scrum, all the players literally put their heads together. When it comes to software development, a scrum can be characterized by developers putting their heads together to address complex problems.

• Scrum software development starts with a wish list of features — a.k.a. a product backlog. The team meets to discuss:
  • The backlog.
  • What still needs to be completed.
  • How long it will take.
• Scrum relies on an agile software development concept called sprints:
  • Sprints are periods of time when software development is actually done.
  • A sprint usually lasts from one week to one month to complete an item from the backlog.
  • The goal of each sprint is to create a saleable product.
  • Each sprint ends with a sprint review.
  • Then the team chooses another piece of backlog to develop — which starts a new sprint.
  • Sprints continue until the project deadline or the project budget is spent.
• In daily scrums, teams meet to discuss their progress since the previous meeting and make plans for that day.
  • The meetings should be brief — no longer than 15 minutes.
  • Each team member needs to be present and prepared.
  • The ScrumMaster keeps the team focused on the goal.

Image via Wikimedia Commons

Who is in the Scrum?

In rugby, the forwards are involved in the scrum. In software development, three roles are defined in the scrum framework:

• The scrum team does the work. It is the individuals who are working together in the sprints to produce the products.
• The scrum master is part of the scrum team makes sure the team works in compliance with the scrum rules. This is not a manager.
• The product owner represents the customer. This role prioritizes the backlog and coordinates the scrum teamwork. The product owner is a role similar to project manager in more traditional project management frameworks.

Benefits of Scrum

Rugby players try to gain control of the ball in the scrum and move it downfield. Software developers use scrum to move their projects quickly. And the benefits trickle down to software developers:

• Developers who want the freedom to make decisions thrive in scrum teams. Team morale tends to be high.
• Each sprint produces a product that is ready for market even though the project is ongoing. The highest priority requirements are addressed first so a high-quality, low-risk product can be on the market.
• The incremental process shortens the time to market by about 30 percent to 40 percent. Because the product owner is part of the scrum team, requirements can be delivered as they are needed.
• Scrum projects often realize a higher return on investment (ROI). This is attributed to:
  • Decreased time to market.
  • Early and regular feedback that prompts course corrections early when they are less costly.
  • Defects that are fewer and less costly.
  • Projects failing early and quickly when it’s less costly.
• Reviewing each sprint before the team moves on to the next sprint spreads testing throughout development.
• Project focus and goals can change with evolving business goals.

Disadvantages of Scrum

While a rugby scrum may get rough and bloody, software developers shouldn’t have to worry about that. Nonetheless, scrum is not for all developer teams or software development projects. There are disadvantages to implementing scrum projects:

• There is a danger of scope creep if stakeholders keep adding functionality to the backlog. This could be encouraged by the fixed deadline.
• Scrum works best with small teams of experienced software developers. They need to be able to work quickly.
• Scrum teams do not work well when the scrum master micromanages their work.
• Losing any team members can hurt the progress of the project.

Scrum Best Practices

Teamwork wins rugby games and helps software developers create quality products. To get the best quality out of scrum:

• Define requirements just in time to keep product features as relevant as possible.
• Test and incorporate product owner feedback daily.
• Sprint reviews with stakeholders need to be regular.
• The scrum team needs to use the sprint retrospectives to improve how they work.
• Conduct face-to-face conversations to reduce miscommunications.
• Trust the teams to do the best job possible.
• Allow the teams to self-organize around people’s skills, work styles and personalities.
• Don’t burn out the team members. Respect the balance between their personal and professional lives to ease stress.

Additional Scrum Tutorials and Resources

Instead of joining a local rugby league, check out the following agile framework resources and resources dedicated to the Scrum framework:

• Scrum Alliance
• 15 Scrum Boards for your team
• Scrum Guides
• Scrum Community Blog
• Scrum Questions
• Scrum subreddit

Definition of Regression Testing

Regression testing refers to the process of testing a changed or updated computer program to make sure the older software features – which were previously developed and tested – still performs exactly as they did before. One way to think about software regression is to think about somebody who implements a new air conditioning system in their home only to find that while their new air conditioning system works as expected, the lights no longer work.

Regression testing will often involve running existing tests against the modified code to make sure that the new code did not break anything that worked before the update. Regression testing can eliminate much of the risk associated with software updates. In addition to running existing tests, testers might tweak existing tests by introducing different secondary conditions as variables.

The Importance of Regression Testing

With the increased popularity of the Agile development methodology, regression testing has taken on added importance. Many companies today adopt an iterative, Agile approach to software development. For example, the great many software as a service (SaaS) providers will regularly update their features or add new functionality to their offerings with each software update. To ensure their core product remains unaffected by new feature additions, these companies will perform regression testing.

Regression testing is a fundamental part of the software development lifecycle. ProtoTech Solutions illustrates the concept nicely with this graph:

The Challenges of Regression Testing

While regression testing is a vital element of the QA process, there are a number of challenges it brings.

• Time Consuming: Regression testing can take a lot of time to complete. Regression testing often involves running existing tests again so testers might not be overly enthused at having to re-run tests.
• Complex: Another thing to consider here is that as products get updated, they can grow quite complex causing the lists of tests in your regression pack to grow to a huge amount.
• Communicating Business Value: Regression testing ensures existing product features are still in working order. Communicating the value of regression testing to non-technical leaders within your business can be a difficult task. Executives want to see the product move forward and making a considerable time investment in regression testing to ensure existing functionality is working can be a hard sell.

Regression Testing Best Practices:

As you and your team perform regression testing, there are some best practices to bear in mind.

• Regularly Update Your Regression Pack: A regression pack is a collection of test cases that are performed as each new software update is completed. The scripted tests included in a regression pack are created with the requirement specifications of older versions of the software in mind. Random or ad-hoc tests may also be included in the pack. It is a good idea to keep your regression pack up to date. Regression testing can be time-consuming, the last thing you need is to include tests that check whether an older feature which has been removed is still working.
• Focus on Highly-Trafficked Paths: Highly-trafficked paths are the most frequent use cases for your application. They will include the basic functionality of your application and most popular features. You should know your core group of users and the typical features and interactions they are most reliant on. Your regression pack must include tests that ensure this core functionality is working as it should.
• Re-Run Successful Test Cases: Tests that have previously identified bugs and defects are also worth including in your regression pack. Alternatively, tests that the program passes consistently are good candidates for archival.
• Automate: Automated regression testing can make the process much more efficient. Running the same tests over and over again can result in testers becoming bored and losing motivation. The quality of their work might suffer as well as motivation dips. Automated regression testing can free up your testers to work on the trickier case specific tests. Automation software can handle the more tedious tests. Another consideration here is that testing software can be re-used so, even though there is an initial outlay, are making efficiency gains on an ongoing basis meaning your testing software will quickly demonstrate ROI.

What is the Difference Between Regression Testing and Retesting?

Regression testing should not be confused with retesting. Regression testing is performed to ensure updated code has not caused any existing functionality to break. Retesting, on the other hand, refers to tests that are performed when a test case has identified some defects. Once the defects have been fixed, the tests are performed again to ensure the issues have been resolved.

Retesting is a higher priority than regression testing because issues have already been identified. Regression testing is focused on identifying potential issues.

Regression Testing Tutorials and Tips

Because regression testing can involve varying types of tests, there’s no single, clear-cut method for performing a “regression test,” per say. However, there are plenty of valuable insights and informative tutorials for incorporating regression testing practices into your overall SDLC. Check out the following tutorials and guides for more insights on selecting test cases, creating and executing a regression testing plan, best practices, and more:

• How to Conduct Regression Tests
• The Challenges Posed by Regression Testing
• Rapid Testing For Rapid Maintenance (an older, but still valuable article)

Agile. You can’t avoid hearing it wherever you go even though “agile” means different things to different people.

In some shops, agile means extremely small sprints that are continuously deployed, sometimes multiple times per day. For others, it means the same old waterfall-style development, but they have burndown charts, daily stand-up meetings, and maybe someone with the title of “SCRUM Master.”   Regardless of how teams define agile, their common goal is increased velocity meaning faster product delivery and better ROI.

Agile development and agile support go hand-in-hand.  Agile development can only save you so much time if you’re wasting time on the backend trying to pinpoint errors and correct them.  I don’t know any developers who look forward to rework.  And they don’t exactly look forward to going to IT with their problems because IT doesn’t want to hear them.  IT is busy.  That means, you have to do more application support in addition to everything else you’re already doing in the same number of hours.

As you well know, building great software means more than just creating cool or useful features.  Users want a great experience.  And yet there you are:  You’re developing code and hopefully releasing it often but your shrinking development cycle may not account for the proper level of load, acceptance and other testing because management thinks you should spend all of your time coding.  But because you know software has to be properly tested, you hope and pray your application will behave well in production after launch. Sometimes it does, sometimes it doesn’t. Sometimes it works for a while and then fails at an inconvenient time. When your application fails, you have to find out what went wrong, quickly.

Leverage agile support to improve application quality and delivery

Agile support is similar to agile development in that it requires a simple plan for quick execution and accomplishing goals.  When you make agile support a part agile development, you can achieve higher levels of quality and get to market faster than ever before if you do it right.  I recommend three things:

#1:  Plan for Support

#2:  Don’t Over-Architect or Under-Architect

Many times, a SCRUM master or project manager will take the time to plan The World’s Greatest Application Architecture full of logging, well-calculated scalability and a high focus on easy maintainability.  But, because neither project deadlines nor budget requirements are infinite, The World’s Greatest Application Architecture ends up being little more than a pipe dream because at the end of the day, unless you are writing and selling software toolkits, business stakeholders don’t really care about software architecture.  They care about features that sell.

#3:  Have a Disaster Plan

Even if you haven’t done what I suggest in points #1 and #2 (Plan for Support and Don’t Over-Architect or Under-Architect), you should know what to do when things go south.  This is where I often see developers hiding under their desks curled in a fetal position and begging for their mommies. Things have gone to hell, the boss is furious, and the phone won’t stop ringing.

Be ready to reproduce. So often, I see developers who don’t know how to troubleshoot a bug. Sometimes it just comes down to common sense: Get the steps to reproduce and use some basic tools to observe and troubleshoot the issue. You’d be amazed how many times my query, “have you used an HTTP proxy tool to inspect the results of the request” is met with a blank stare from the developer who is assigned to an Urgent production bug. I feel this aspect of development is often overlooked, and needs to be exercised often, just like any muscle.