Still celebrating National IT Professionals Day with 3 months of free Premium Membership. Use Code ITDAY17

x

Agile

Agile software development is a set of software development methods in which requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. The agile philosophy promotes adaptive planning, evolutionary development, early delivery, continuous improvement, and encourages rapid and flexible response to change. Agile methods break tasks into small increments with minimal planning and do not directly involve long-term planning. Iterations are short time frames involving a cross-functional team working in all functions: planning, requirements analysis, design, coding, unit testing, and acceptance testing. Working software is the primary measure of progress.

Share tech news, updates, or what's on your mind.

Sign up to Post

Technology teams care about budget, time limits and iterative production, that’s why product designers should be politicians and act fare.
8
Build and deliver software with DevOps
Build and deliver software with DevOps

A digital transformation requires faster time to market, shorter software development lifecycles, and the ability to adapt rapidly to changing customer demands. DevOps provides the solution.

Deploying our service is a grudge match between customer benefits and customer pain. In one corner, rolling out fixes (yay!) and delivering new features (double yay!). In the other corner, training on new features (boo – sounds like work), and change management processes (more work).


We put a great deal of effort into optimizing these processes, so it’s important to share how we think through these optimizations. For now, I’ll narrow focus on the issue-fix aspect of the deployment process, and in later blogs I’ll cover new feature delivery.


The fine printBefore I start, a quick disclaimer: what I’m about to describe is subject to change. We’ve been a fanatical agile shop for nearly seven years and we believe change is an important principle of the agile approach. So, if you’re reading this in 2017 or later, please understand that we might have tweaked some of these details. OK, now for the good stuff…


Bug zapping

You might not be surprised to hear that bugs are occasionally found in our service (I know, the horror!). Nobody likes bugs, so we need to address them as soon as possible. And because our service uses a number of telecommunication providers to make text messages flong (on my iPhone, anyway), phones ring, and other third-party communication channels do their thing, managing the infrastructure related to these providers requires constant effort. In short, we need to be able to release and deploy fixes FAST.


Keep those cards and letters coming

It also might not surprise you to hear that our customers ask for new features (the audacity!). From July 1st to Sept 30th, we received 133 service enhancement requests – that’s 2+ per business day. The product managers who handle these requests interpret them into new features and then work with our engineers to build them.


So far, so good – and in theory we should be getting these features into your hands ASAP. But these features are product changes: while the customers who asked for a change are willing to take on any additional testing and training work to get their new features, customers who don’t intend to use the new features don’t want that burden imposed on them. That means we need a process that doesn’t force new features on customers too quickly.


Balancing the need for speed

Okay, so we can probably agree we want fixes fast and features not too fast – how can we possibly strike this balance?


First, by using deployment speed: we deploy at least weekly, if not more frequently. Our core sprint work uses a continuous delivery process which we deploy on a weekly schedule so that we can seamlessly deliver non-critical fixes at that cadence. We can also generate and deploy critical fixes in between these weekly deployments as necessary to address issues like zero-day vulnerabilities.


Second, by using feature flags: deployments include the latest feature developments, but some features are not quite ready for your use after just one sprint. And as previously mentioned, your user base might be confused if new buttons and features show up every week. So we use feature flags/toggles on our new features so that we can conditionally turn them on when we’re ready to release them. That allows the new fixes to get out the door without having new features show up. (We’ll talk more about feature flags in another blog, but those of you who are new to xMatters might want to check out our Early Access Program if you want to play with new features faster).


Third, through thoughtful communication: because fixes can cause behavior changes in the system, we have implemented a new communication process to advertise the parts of the service we worked on so customers can keep an eye out for any unexpected behavior. Our support notes are designed to provide this information (here’s a sample from the deployments leading up to our Rogue release). Those notes work in conjunction with the scheduled maintenance posts on our status page to ensure this information is delivered by the latest technologies.


Using these three mechanisms, we can offer the best mix of quick fixes – without forcing training and change management on our customers.

0

How many times a day do you open, acknowledge, or close an IT incident? What’s your process? Do you have a process depending on the incident, systems involved, and other factors? New Relic Alerts gives you options for how you interact with notification channels for sending alerts.


Alerts is a new tool to manage your alerting policies and integrate with team communication tools like xMatters, HipChat, Slack, and more—so you can immediately let the right people know when critical issues arise.


We’re pleased to announce that xMatters is an official notification channel in New Relic Alerts.


With the new integration, New Relic provides a notification channel that you can use to manage your xMatters integration and communication plans easily. You can also use custom payload webhooks to control how the xMatters alert is delivered.


xMatters allows you to automate and structure communication as events unfold during a deployment or service outage. New Relic enables you to manage alerting policies and integrations, while still providing industry-leading insights.


How it works
With New Relic Alerts, you can choose the communication tool and easily set up the integration.



xMatters has a similarly easy interface for setting up an integration with New Relic.



Reaping the benefits

New Relic integrates with xMatters to replace manual steps in incident management processes:

  • Notify resolvers based on escalation rules, on-call schedules, skills, and location
  • Enrich notifications with insights from New Relic and other tools in the IT toolchain, to provide actionable content and increase resolver efficiency
  • Configure response options that trigger other xMatters integrations and drive workflow for tasks such as creating tickets, updating consoles, sending additional notifications, and initiating chat & conference-call collaboration all with context from New Relic alerts
  • Use the xMatters mobile app to quickly look up who’s on call, receive & respond to notifications, and engage other teams to minimize time to resolve service disruptions
  • Continuously improve operational processes with reporting & analytics
  • Allow stakeholders to manage subscription and notification preferences for proactive communications during service disruptions


xMatters is now available as a New Relic Alerts notification channel. Please visit https://www.xmatters.com/integration/new-relic for more information.

0

When the s#!t hits the fan, you don’t have time to look up who’s on call, draft emails, call collaborators, or send text messages. An instant chat window is definitely the way to go, especially one like HipChat.


HipChat is a true business app. And while it’s tempting to call it a chat application, it’s much more. It’s persistent, searchable, and loaded with extras like group chat, video chat, screen sharing, and airtight security.


So if you’re busy doing other things when a nasty incident ticket starts hogging space on your screen, how quickly and effectively can you get into HipChat? That’s where we come in.


Combined with xMatters, this integration allows individuals to collaborate with the correct on-call resources via HipChat to coordinate and resolve incidents faster. xMatters leverages your group on-call schedules and rotations, escalation rules, and user device preferences to quickly engage the right resources into a targeted HipChat room.


Linking HipChat in your toolchain


Integration xMatters with your monitoring, ITSM, incident management, and communication tools enables you to share data across your entire incident resolution toolchain. Using the xMatters integration, you can open a HipChat room directly from JIRA Service desk or another ITSM system without leaving the ITSM environment.


When you send invitations to collaborate from HipChat, they reference key data from monitoring tools or service management systems. All this data enables your resolution teams to quickly get up to speed and act.


Within the targeted HipChat room, members can use slash commands to see who is on call from a specific team, invite additional resources, and make updates to a service management ticket or StatusPage listing. xMatters eliminates the need to switch back and forth between systems, so your team can resolve incidents instead of worrying about record keeping.


Here are a few other things you can do with the xMatters HipChat integration:

  • Automatically assign a JIRA issue to the responder
  • Record HipChat activity back into a service management ticket
  • Use slash commands to add comments to a service management ticket or StatusPage


Adding HipChat to your xMatters instance is easy. Just visit our Integrations Directory!

0

Dramatic changes are revolutionizing how we build and use technology. Every company is automating, digitizing, and modernizing operations. We need a better, more connected way to work together as teams so we can harness the insights from our systems and drive effective collaboration.


Just a few years ago, we were all looking around and asking each other the same question. Fortunately, some people are figuring it out and providing some guidance on how DevOps processes can improve all areas of business, from development and operations to monitoring and incident management.


Here are a few examples from our customers.


Pacific Life has transitioned its monitoring from a human-operated system to an automated one. Leaders had to overcome employee anxiety over losing jobs and providing direct access to customers.


Intermountain Healthcare, Utah’s largest nonprofit healthcare provider, has connected systems to provide telehealth first-response technology and major incident management processes.


Dealertrack is the leading provider of on-demand, integrated digital solutions designed to enhance the efficiency and profitability for all major segments of the automotive retail industry. Thanks to a combination of monitoring, management, and communication tools, Dealertrack has improved their time to resolve issues and product development speed.


So we know that dramatic changes are needed in how we build and use technology. And yet, a 2017 survey of DevOps maturity shows that only 36% of organizations have good knowledge sharing between development and operations.


The DevOps experts who know

Where can you go to hear how experts are solving these complex problems?


We're bring the Agility 2017 Tour to a city near you, where you can hear from experts and pick their brains regarding how they’re improving business and trends you should be preparing for. It's a great opportunity to hear from more than just talking heads.


Agility 2017 starts in San Francisco on June 13, then moves to New York on June 20, Chicago on June 22, and London on June 29. Besides the customers listed above, we'll be including New York City Health + Hospitals, Forrester, The Telegraph, O2, Tesco, Moogsoft, Cherwell, Praecipio, and others.


You'll also hear from our own experts, including CEO Troy McAlpin and CTO Abbas Haider Ali. They will be discussing:


  • The need for a better, more connected way to work together as teams
  • How to harness the insights from systems to drive collaboration
  • And in doing so, naturally preventing incidents within the normal flow of work


Reserve your seat at a free Agility 2017 event near you before they all disappear!

1
Read about the ways of improving workplace communication.
1
 
LVL 7

Expert Comment

by:Brian Matis
Comment Utility
Great article, Oscar! This is a topic becoming incredibly important to me. I love how many new sorts of techniques and tools there are for fostering improved communication, but it's definitely in a major transitional period. There are so many options! I've had to figure out things like what type of communication preferences different people have, to try to make sure I'm using the one that they prefer. Like how some people prefer email and rarely check chat, whereas others can be the exact opposite! Exciting times for sure...

I also love your mention of team building activities. One idea I've toyed with is using cooperative style board games, such as Pandemic. Wondering if anyone else has tried things like that?
0
Find Your Happy Place. Every company and every work group has their own culture. If you are considering starting a new job here are some good engineering/culture questions to ask a prospective employer.
1
 
LVL 6

Expert Comment

by:Mikkel Sandberg
Comment Utility
Great article Marlon!
1
Comunicación con notas
"In order to have an organized way for empathy mapping, we rely on a psychological model and trying to model it in a simple way, so we will split the board to three section for each persona and a scenario and try to see what those personas would Do, Think and Feel, when they are in that scenario."
4
"Disruption" is the most feared word for C-level executives these days. They agonize over their industry being disturbed by another player - most likely by startups.
2
The Quality Assurance engineer of an Agile scrum team must "own" the acceptance criteria for sprint tasks.
1
The top UI technologies you need to be aware of
The top UI technologies you need to be aware of

An important part of the job as a front-end developer is to stay up to date and in contact with new tools, trends and workflows. That’s why you cannot miss this upcoming webinar to explore the latest trends in UI technologies!

You can provide a virtual interface for remote stakeholders in a SWOT analysis through a Google Drawing template. By making real time viewing and collaboration possible, your team can build a stronger product.
8
 
LVL 4

Author Comment

by:Sina May
Comment Utility
Our org has a Google Apps account which made Drawings a bit more accessible. I could definitely see a company with Office 365 going with OneNote instead.  :)
0
 
LVL 2

Expert Comment

by:Deborah Canales
Comment Utility
What a nifty idea! My company utilizes Google Apps so I will have to keep this in mind to share with my users. :) Thanks!
0
Agile and Scrum have almost become synonymous. Have you wondered what's the difference? Scrum is just one way to be Agile. It is the most popular which leads to the common confusion. Agile actually refers to a philosophy shared by group of development methods, each offering a unique approach.
4
 
LVL 15

Expert Comment

by:Eric AKA Netminder
Comment Utility
0
If you are using Scrum Framework or another agile process, a retrospective may be part of it. Does your team perform retrospectives? Are you getting value from your retrospectives?

I see a common anti-pattern when people conduct a retrospective for a sprint or write a root cause analysis for a defect. First they will point out the sequence of events that led to some code executing which caused the wrong thing to occur. Then to prevent that kind of problem from happening in the future they will basically conclude "we will try harder" or "we won't do that next time."

The purpose of a retrospective is to improve your process continuously. First identify something that didn't go well; perhaps it's a defect. Next your team must examine each step of the process which resulted in the defect. For each step think about whether the defect got created in that step and whether the defect escaped detection in that step. Finally, decide what actions to take to improve your process.

For the scrum framework process, you might think about the following.
  1. Did you groom the story in the backlog before adding it to the sprint?
  2. Was the story too big?
  3. Did you rush to finish the story to make the sprint deadline?
  4. Were the acceptance criteria sufficient?
  5. Were the acceptance criteria specific?
  6. Did you write the acceptance criteria together or review them?
  7. Did you add acceptance criteria during the sprint instead of putting them on the backlog?
  8. Did you do Test Driven Development?
0
Backyard Hair Cut
It was Monday morning and while heading to work those familiar feelings of frustration began to rise: How was I ever going to get my yard work done?! At the end of every weekend I discovered that I spent more time trying to decide what to work on than actually working. How was I ever going to get to re-landscaping the front yard, prepping my vegetable garden for fall and maintaining the back yard so that the kids and pets could play? At the peak of my frustrations I discovered the Agile Scrum Framework.

Recently, buzzwords like Scrum and Agile were being tossed around the office. After educating myself by watching tutorials and reading, I immediately thought of my yard and how I could use the Agile Scrum Framework to accomplish my work!

Agile is a concept for software development cycle defined in the 80s by Hirotaka Takeuchi and Ikujiro Nonaka. Scrum is one way to adopt Agile that allows developers to be more flexible in reaching attainable goals. It breaks down like this: A team of cross discipline producers get together with a Project Owner and Scrum Master (a Scrum Master makes sure things stay on track but doesn't do any actual work) and decide what can be completed in a sprint (interval of time). Before sprinting user stories are used to define what needs to be done. Those user stories are broken down into tasks that can be accomplished during the sprint. These are backlog items. For more info on Scrum check out this great video series
7
 

Expert Comment

by:Jigs Gaton
Comment Utility
Helpful way to understand Agile, thx.
0
 

Expert Comment

by:Jigs Gaton
Comment Utility
Oh, and by the way, to answer your question in the last para:
Have you used Agile Scum? How?
I can only say,  "As consultants."
0
Cobalt Digital Marketing began using the Scrum Framework development process in summer 2009.  We hired a consultant to train the teams, observe meetings, and answer questions.

He recommended that we begin using one-week sprints for several reasons.  The team gets feedback quickly.  You fail faster and succeed faster.  You go through the complete sprint cycle many times so you gain experience quickly.

In my experience those made sense in theory and they were valuable in practice during our transition.  The consultant was also able to repeatedly coach the teams to learn agile principles.

You may hear that common practice is to use a two-week or four-week sprint.  Why, after more than two years, do we continue to use one-week sprints?

We plan to release our main application once per week.  The cadence of the sprints matches our release cadence.

The limited amount of time forces teams to create small stories.  We try to limit story size to two days for two people.  Small stories are easier to code review and demo.
Most of our teams have members in both the US and India.  Product managers work in the US.  India staff are hungry for all the communication they can get.  They miss some discussions in the US with the product managers, design sessions, and planning meetings.  The one-week sprint forces the team to communicate more often in planning, backlog grooming, and demo meetings.

Product owners can see progress and give feedback every week.

Business owners …
3

Agile

Agile software development is a set of software development methods in which requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. The agile philosophy promotes adaptive planning, evolutionary development, early delivery, continuous improvement, and encourages rapid and flexible response to change. Agile methods break tasks into small increments with minimal planning and do not directly involve long-term planning. Iterations are short time frames involving a cross-functional team working in all functions: planning, requirements analysis, design, coding, unit testing, and acceptance testing. Working software is the primary measure of progress.