Posts

Going Big with DevOps? Scale it Right with Four Key Ingredients

Success of your Agile and DevOps initiatives might often be a double-edged sword for technology teams. Happier customers, positive sales numbers, and increased opportunities inevitably lead to only one thing for the CTO — the need to scale. The question is, how? In this blog post, we draw out an overview of some of the capabilities you need to develop a strategy for scaling and keep yourself ahead of new organizational demands as your company matures.

Consistent performance at scale

As distributed teams grow, it becomes critical that their software is available around-the-clock and performs at a level that enables the teams to do their job. Applications need to maintain consistent performance and response times, irrespective of increasing number of users and workloads and support the collaboration needed across teams to drive shared business goals. Downtime and slowdowns can have a direct impact on business metrics and are unacceptable to a growing organization. 

Teams relying on single servers in their network architecture face a substantial outage risk, whenever server loads increase dramatically due to factors such as concurrent usage of the application, performance intensive workloads, or even for routine maintenance like patching and version upgrading. Systems should be designed to facilitate instant scale-out by adding new nodes for uniform redistribution of load and ensuring dedicated bandwidth priorities. With an infrastructure architected for improved resilience and business continuity performance, you can keep your mission-critical apps up and running and manage continued growth.

Improved data capacity and speed

It is no secret that with an increase in the number of users, data volumes continue to grow. Both users and the associated higher data volume can have a negative impact on performance at scale. The need for speed and increased data capacity mean that single server systems are often not able to meet the needs. A single server architecture typically has a fixed amount of ingest throughput as it runs on a single machine. These constraints can become a serious liability for applications (or organizations) aiming to scale.

Adequate visibility and control

As your growth accelerates, you are faced with increasingly challenging requirements around security and regulatory compliance. Large organizations face the added complexity of having several distributed users working from multiple locations, multi-jurisdictional global structures, and extensive legal demands. Without proper visibility or control, it becomes impossible to coordinate disparate teams, create consistency and prevent bad actors from negatively impacting your tools or teams. 

The challenge that many organizations face is in balancing team autonomy with the right level of control and governance. Administrators of large organizations cannot afford to become a bottleneck, especially as the number of users accessing different applications increases and there is a growing pressure to deliver customer value rapidly and regularly. It, therefore, becomes important to provide administrators better ways to delegate work, while ensuring they are able to monitor the actions of users and maintain appropriate oversight as teams grow.

Moving on at the right time

If you are looking to scale your DevOps practice across the entire organization, the need for enhanced scale, speed, user support and data capacity mean that single server systems are often unable to address the needs of modern applications. You need to identify and transition to more robust solutions that can alleviate the constraints of single server systems, and help you stay ahead and manage complexities as your organization matures. We recommend planning ahead by choosing the right foundation, which is designed to stay efficient and stable against heavy usage and also handle other complexities around ease of administration, security, and compliance.

If you are thinking about the broader deployment of DevOps and not sure about what to anticipate while scaling, we are here to help you take an informed approach.

11 Must-read DevOps Resources

Ring in 2018 with brand new perspective. Whether you are getting started with your DevOps initiatives or are midway along the journey, you’ll need context to everything that you are experimenting. Investing in comprehensive reading material written by DevOps gurus will yield long-term results. Read more

The death of waterfall has been slightly exaggerated

Waterfall is not the enemy and agile is not a panacea Agile has established itself as an effective management practice for software developers. It helps organizations of all sizes deliver high-quality, useful products on a much faster, tighter schedule than previous methodologies. Although Agile allows businesses to be more responsive, flexible, and engaged, it’s not the right fit for every project and every team. For many projects – especially those requiring high levels of industry compliance or those producing tangible products – traditional gated methodologies such as waterfall excel at bringing about the required structure, repeatability, and predictability. Choosing between waterfall and agile Waterfall is a predictive, sequential methodology that follows a linear design. It is analogous with “wash, rinse, and repeat.” It’s all about putting the plan on record, with requirements gathered in the initial stages of product development. It’s great for well-defined processes requiring little variance – such as define, code, test, release – as long as many changes are not made throughout the development process. In waterfall, testing and feedback do not begin until the very end of a product’s release. Agile is a reactive, flexible, iterative, and incremental approach. It’s most effective when rapid product creation is more important than quality. Agile is all about failing forward, so for beta releases, it serves well. Any type of GUI or web design also works well with Agile since it’s about iterative approaches and these types of designs can have multiple refreshes in a single day. The design process is where this methodology shines. Agile projects are fluid in nature and tend to be esoteric. Time and budget are hard to predict. Agile relies heavily on employees, since institutional influence plays a big part in the methodology. Here are some guidelines to help decide when to use agile and when to use waterfall:
  • Consider the risk vs. impact to product/release changes. When both risk and impact are high, use waterfall. If they’re both low, then agile might be a better approach. If somewhere in between, use a blended approach.
  • For tangible, repeatable services or a product-driven industry, use waterfall. Since agile is soft on documentation and product requirements, more conservative and/or regulated industries tend to do better with the additional planning that comes with waterfall. Example industries include government, medical devices, pharmaceuticals, manufacturing, and even construction. In waterfall, requirements must be well-defined before solutions are built.
  • The older an industry is, the more likely it is that the decision makers in an organization within that industry are more familiar and comfortable with waterfall.
  • For a software-driven industry, use agile. Agile methods are most prevalent in companies with less than $50M revenue. As size of revenue increases, agile adoption rates decline.
  • Agile is for companies that might not know what they want to accomplish or what the end-result product should look like. Collaboration among people becomes more important than the product.
  • The more a company or industry cares about the end user’s experience with its products, the more likely it is to use and benefit from an agile methodology. Companies whose products are client-facing are more likely to consider agile due to the ease of making improvements quickly based on user feedback.  
Introducing the blended approach: harmonious co-existence When the same institution employs both agile and waterfall methodologies, this is described as a blended approach. For new product development or the fastest time to go to market, the blended approach shines best. The Study of Product Team Performance, 2014, conducted by Actuation Consulting, highlighted this in a graph based on the question, “Which of the following methodologies best describe the way your organization develops products?” Of the respondents, 45.41% stated that they employed a blended approach with some elements from waterfall and some from agile. Agile as both an ethos and mindset In 2001, the Agile Manifesto was created to respond to a slow-changing approach to product development and place an emphasis on people over the product, matching the methodology to the mindset. Young, malleable, Web 2.0 companies often find more success with agile than waterfall. An earlier report by Forrester Research entitled “Agile Development: Mainstream Adoption has changed Agility,” stated, “Most teams are not adopting Scrum, eXtreme Programming, or another specific Agile approach, but are embracing agile as an ethos or philosophy and cherry-picking the best bits from many different process models to develop a formula unique to their own situation.” While things have changed since that report was published, the sentiment has not. Agile/scrum is a mindset about people. In addition to considering your organization’s mindset, size, and industry vertical, answering the following question might help you determine which approach is best for you: “Why do we do something a certain way?” If your answer is, “because we have always have done it this way,” then waterfall might be the way to go.

Five scrum KPIs to maintain team accountability during a product release

Since many software developers and QA testers employ some adaptation of the scrum methodology, today’s milestones tend to be in line with status updates (i.e., sprint planning, daily standup, sprint review, sprint retrospective, and backlog grooming). Certified scrum Master Robert Boyd insists that those milestones do not provide any guarantee of progress or success. As they stand, scrum metrics maintain neither individual nor team accountability. If you want your product release to be a success, then it’s out with the old, stagnant metrics and in with the new, actionable KPIs — key performance indicators. What’s the difference between the two? Driven by upper management, KPIs are actionable, quantifiable, leading indicators that have the ability to change over a particular time, and that measure outcome toward an objective-defined goal. Metrics, on the other hand, are lagging indicators focused solely on activity and output. There are many metrics but only a few KPIs. Furthermore, while all KPIs are metrics, all metrics are not necessarily KPIs. When in doubt, make a statement and follow that with the question “who cares?” If the answer is “upper management,” then it’s a KPI; if not, it’s a metric. Here are five measurable KPIs: 1) Stories completed vs. stories committed Measure: This is measured by comparing the number of stories committed to during sprint planning with the number of stories marked as completed during the sprint review. Action Required Indicators:
  • The team doesn’t have an applicable reference story for making relative estimates, or not every team member understands the reference story.
  • Customer requirements are either not properly defined (leading to feature creep) or not adequately communicated to the development team.
  • The team faces multiple disruptions or is undercommitted, working at a slower than expected pace.
  • A single team member is burdened with making all decisions regarding estimation, design, engineering, and implementation.
  • The product has bugs.
2) Technical debt management (the known problems and issues delivered at the end of each sprint) Measure: For QA testers, this is usually determined by the number of bugs identified. Action Required Indicators:
  • No customer input has been requested, or team members are building the product based on how they think it should work rather than listening to the customer’s requirements.
  • The product’s “fully completed” stage isn’t properly defined, or other gating factors (such as the introduction of bugs) aren’t acknowledged.
  • There is extensive pressure from outside forces (including upper management and the customer) for the early release of a product.
  • The team is compromising quality by working excessively on stories during the sprint.
  • The team isn’t documenting found or fixed problems.
3) Team velocity (the consistency of the team’s estimates from sprint to sprint) Measure: This is calculated by comparing story points completed in the current sprint with story points completed in the previous sprint. (Aim for no higher than a 10-percent variation.) Action Required Indicators:
  • There are variations in team size between sprints.
  • The team has very short release cycles or is constantly doing maintenance work.
  • The team doesn’t understand or is unable to gauge the extent of the work to be completed at the sprint’s inception.
4) Retrospective process improvement (the team’s ability to revise its development process, making it more effective and enjoyable for the next sprint) Measure: This can be measured by retrospectively counting the items identified, the items the team committed to addressing, and the items resolved by the end of the sprint Action Required Indicators:
  • The team is unable to stay organized or manage itself.
  • Feature stories are put first, and team self-improvement is put second.
  • Team members lack the measures to check or rate themselves with respect to internal and external factors during the retrospective.
5) Team’s adherence to scrum rules and engineering practices Measure: This is determined by counting the number of infractions that occur during each sprint. While scrum doesn’t outright define the best engineering practices, companies usually have their own ideal practices for undergoing projects. The scrum team should not deviate from that defined set of expectations. Action Required Indicator:
  • No one is leading the team or coaching it to be more productive and produce higher-quality products. (Keep in mind that a good process leads to good products.)
Refer to the Atlassian Agile Glossary for more detail. Thanks to Robert Boyd, whose scrum insights were provided in the Fall 2014 issue of Pragmatic Marketer.

Agile West 2014 – Go2Group and Atlassian Together

Go2Group and Atlassian together rocked again at Agile West. The expert’s combination has always been a successful one in adding value to customers.

The two days Agile conference, held at Caesar’s palace in Las Vegas on 4-5 June, 2014 provided delegates with an opportunity to explore ways to unlock the value of best practices through Agile methodology. It was a successful event with hundreds of attendees from various industries stopping by the booth. And, majority of them were Atlassian tool users. The team shared their expertise at the booth as attendees explained their real life business challenges. Apart from that, Dan from Atlassian presented on Git and Agile over the two days. The presentation was an engaging one and was very well received.

rsz_agile_dev_west_2014-1

Overall, it was a great experience to share the stage with Atlassian and more such interactions with customers help us to add value in a better way

Agile Project Management Webinar, Recap

  Today’s webinar on Agile Project Management with Atlassian Jira and GreenHopper was awesome – thanks to everyone for attending! We’re including the slides here (PDF) and we’ll have the recording available shortly. Updated: The recording is below! As mentioned in the webinar, we’re now offering a special package for implementing Agile in your organization. For more details, please see the 6 Hours to Agile Nirvana page. If we missed your question during the webinar, please know that we will follow up with you directly. Thanks again!  
  Ps: Next time we will have it in full-screen mode!    

This Week In Go2Group Webinars

  It’s a big week for Go2Group webinars and some upcoming news that will be announced during the webinars. First, a quick note about the webinars:
  • Go2Group JaM Webinar: Our monthly JaM webinar series continues. This session is going to be a little different than the previous webinars. We’re opening it up to you, the attendees. We’ll run through some slides and details about JaM but the focus is going to be on you – if you have a question, it’s the mic is yours!   You can register for the Go2Group JaM webinar here. (It’s Tuesday at 11:00 AM ET.)
  •  
  • Agile Project Management with Atlassian Jira and GreenHopper: This is our latest series of webinars that’s focused on Agile, and it’s one of my favorites. We turned this into a fireside chat with our friends at XBOSoft and open the room up to questions during the discussion. With Agile picking up steam, it’s a great oppportunity to ask questions and learn about different approaches. It’s really fun and educational.
  •   You can register for the Agile Project Management webinar here. (It’s Thursday at 10:00 AM ET.)
(If you have questions about an upcoming webinar or event, feel free to check out the Go2Group Events page.) Then there’s the news. We’re planning to announce something around Agile later this week. Nothing specific yet, but you should hear more about it by Friday at the latest. To hear the news, check back on this site. Or join us on Twitter. Or subscribe to our newsletter. Or find us at Atlassian Summit.    

How You Benefit From Rapid Deployment Cycles And Agile Testing – Webinar Recap

  We had an awesome turnout for yesterday’s webinar: How You Benefit From Rapid Deployment Cycles And Agile Testing. Thanks to everyone who participated in our unique, fun, and educational session – we really enjoyed it! We mentioned we’d be posting follow-ups to yesterday’s webinar. You can find these below.   SLIDES You can download the slides here (PDF). The webinar went a bit over the stated stop time so if you needed to drop off, these slides will help round out the last few minutes of the webinar.   ANSWERS There were a lot of great questions posted during the session yesterday and most were answered. However, a few sneaked through that were not responded to during the webinar. In the spirit of keeping this session interactive, we’re planning to open up a Google Doc for you to reference. We’ll be posting all questions from the session in this document where you can review. We should have this available shortly (still working out a few kinks and making sure responses have been included!). Check back here or find us on Twitter to be notified of updates. A few notes:
  • Mike & Shawn are updating the doc with responses over the next few days.
  • If we missed your question, don’t hesitate to contact us!
  RECORDING   NEXT WEBINAR As mentioned yesterday, we’re planning another webinar around Agile and a few tools. You can find details (and a registration link!) to that webinar below:
Agile Project Management with Jira + GreenHopper Thursday, May 24 @ 10AM ET Register Today!
If you are interested in taking a closer look at these tools prior to the upcoming webinar, here are some additional details:
  • Jira: The project tracker for teams building great software. Jira sits at the center of your development team, connecting the people and the work being done. Track bugs and tasks, link issues to related source code, plan agile development, monitor activity, report on project status, and more.
  • GreenHopper: An Agile project management add-on for Atlassian Jira. Whether you’re a seasoned expert or just getting started with Agile concepts, GreenHopper is perfect for visualizing your existing process and stimulating incremental improvement.
   

Agile Project Management Webinar for Testers and Developers

 
How You Benefit From Rapid Deployment Cycles And Agile Testing Thursday, April 26, 2012 | 11:00 AM ET – 12:00 PM ET Register here!
  We just had a practice run for this week’s How You Benefit From Rapid Deployment Cycles And Agile Testing webinar (register here) and I’m super excited for Thursday. So excited, I decided to write this post! We provided an outline for the webinar earlier but after this morning’s test run, I thought I’d add a few more details. Read more

Go2Group synapseRT 4.2 Available for Download

  Well, that was fast. While announcing Go2Group synapseRT 4.1 earlier this week, we’re making version 4.2 available today. It’s available via the Atlassian Plugin Exchange now. More details below!  

Overview

Go2Group creates and manages requirements, releases, test cases, test suites, bugs, and provides a comprehensive traceability matrix and dashboard to view, track, and manage your development and testing. Go2Group synapseRT integrates testers, developers, requirements managers and engineers all INSIDE Jira. Read more

Pages