4 min read

What Exactly is Agile Methodology?

By Courtney Pool on Aug 17, 2021 12:22:47 PM

Blogpost-DisplayImage-August_ What is Agile Methodology-

Any person who's worked in or around software for any length of time has likely heard of Agile. Since the release of the Agile Manifesto in 2001, Agile has quickly spread through the industry, and even companies who aren't fully Agile sometimes claim to be, if only to check the box. Still, despite this popularity, we regularly receive confessions from people who admit that they don't fully "get" what Agile is, often from teams outside of software developers who want to know if Agile can help them too.

The Elevator Pitch

"Getting" Agile is a multi-step process, but knowing the elevator pitch is a great place to start. Agile is an iterative approach to software development and project management, with iterative being the keyword. Its primary focus is on delivering value incrementally, with those increments being faster, more frequent, and with fewer strings attached than some traditional approaches. Agile also acknowledges, accepts, and even encourages that risk and change are likely to pop up and need mole-whacking along the way, allowing for real-time course-correcting as needed.

This short description can help people navigate through many of the superficial conversations around Agile. If you want to impress though, knowing the details is the next step.

The Details

To really understand what Agile is, it helps to first understand why Agile is. Agile's origin is in software development, and its inception was a direct response to the rigidity of existing development methods like Waterfall. Despite this, its existence is not at all meant to be a critique of Waterfall, which is a valid methodology that still has uses in several scenarios; rather it's an answer to the "But what if...?" questions that plague so many projects, such as: 

  • What if I discover more requirements after development has started?
  • What if we don't catch a big problem because we waited too long to test?
  • What if we need to ship to market faster or more frequently?

Answering these questions is difficult in a Waterfall environment, and failure to answer them can be costly. This can be especially true in software, where conditions and criteria frequently change, and rapidity and innovation are critical factors in winning over users. Enter Agile, whose principles allow teams the flexibility needed to answer these questions as they arise while still meeting product and stakeholder needs.

While some interpret this flexibility as Agile having no rules, this could not be further from the truth! The Agile Manifesto itself includes both key pillars and guiding principles, which every organization purporting to be Agile should follow. Amongst the guiding principles are those that are arguably more nebulous, like "Working software is the primary measure of progress." Still, many are undeniably rules and not suggestions, such as the principle requiring the increments mentioned above: "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. "

Beyond that, there are also rules associated with each particular Agile framework to adhere to as well.

You see, while "Agile" is the overarching methodology (or philosophy, some argue, an ongoing debate), the actual "doing" is often guided by the numerous frameworks within Agile, with more popular frameworks like Scrum, Kanban, eXtreme Programming, and the Crystal Method leading the charge. Of course, that's not to say that one can't simply follow the principles of Agile without needing a specific framework -- you absolutely can! -- but development teams may find it easier to work within a framework. Aiding this ease is that each framework has taken the Agile principles and hammered them into specific actions, ceremonies, and practices for teams to follow, reducing the need for teams to develop their own.

Knowing the pitch and the details is essential to understanding Agile, but "getting" Agile requires that you take it one step further and apply it outside the business.

The Real World Example

As mentioned, Agile is an iterative process that seeks to frequently deliver value while still allowing for the winds of change. One of the reasons Agile can work so well is, if you think about it in the simplest of terms, because most people do Agile every day.

No, seriously!

I recently moved and learned again how ever-present Agile is. I prepared for the move with a soft plan and a general goal in mind: get everything packed and ready by X date. I even took an incremental approach to it, regularly moving smaller and more manageable items over to the new house in the weeks leading up to the move. As is frequently the case, though, life had different plans, and I found myself scrambling to finish hours before the movers' arrival (see: winds of change). I could have chosen to stubbornly stick to my original plan, risking either an incomplete project or a financial blow from having to delay, but I instead chose the Agile approach. I reprioritized and adjusted my goal, focusing on readying the most vital components and shifting lower priority items to my next increment. 

And just like that, you're Agile!

So now you can quickly explain Agile to someone any time it comes up, dazzle them with a few specific details, and even deliver an analogy or two to help set it in. The final step? Contact us to find out how Praecipio Consulting can help you make it work for your teams.

Topics: kanban process tips agile software-development waterfall
3 min read

Old Is New Again – Conversations Over Documentation

By David Stannard on Jun 18, 2021 11:43:00 AM

Blogpost-DisplayImage-June_Old is new again - Conversations over DocumentationImagine a world where businesses can concurrently develop next generation manufacturing processes while designing products based upon the as-yet-non-existent implementation medium. Imagine that they can do this all while reducing time-to-market and allowing the continued benefit of exponential growth in complexity every 18 months. Add a twist of “design-anywhere-build-anywhere” – and serve shaken; not stirred. Perhaps in software, the analogy might be "develop applications on a language being implemented and SDKs that will also be created concurrently – trust us, it will be fine." At the same time, many graduates from engineering colleges were learning that the soft skills of communication and collaboration had higher impact to their success than the hard earned technical skills.

In the early 1990s, an organization is asked by several of its clients to help them address time-to-market pressures. The result: in 1992 Don Carter published a book founded upon a transformational approach called Concurrent Engineering based on consulting experiences. One impact that I remember well was the increase in actual conversations amongst the various constituents - breaking down the barriers between the silos was a key component of this philosophy. Coincidentally, the quality of results increased too, along with client satisfaction.

Back to the future... Literally!

There is even more pressure on businesses to reduce time-to-market, and there are few signs that this will change or needs to change. No time for creating voluminous documentation in semi-isolation that can't capture all aspects and are often subject to interpretation by the reader. The division between hardware and software development has blurred. In fact, hardware designs are created, modeled, emulated, and the proposed implementations are verified using specialized high level languages prior to implementation. The abstracts are subsequently decomposed into manufacturable entities while continuously confirming no unintended loss of the design intent using specialized tools such as formal verification tools. 

Businesses are and must continue becoming Agile – businesses are greater than having Agile development organizations. So the adoption of Agile, Scrum, and other practices continues unabated. There are even early discussions of what’s beyond these Agile practices that are standing the test of time after several decades of adoption. 

Two important aspects of the Agile Manifesto are valuing “Individuals and interactions over processes and tools” and “Customer collaboration over contract negotiation”. It was increasingly common pre-COVID that these teams were distributed geographically and even culturally. So while tools are a part of the solution – the need to communicate well and often has never been more important. This practice is standing the test of time.

A closing note to Scrum Masters who help teams live the benefit of the cross-functionality objective: Your Scrum teacher and Agile coaches have provided you with lots of reference material about building teams and communications. Now is a good time to revisit those references; one of my favorites is “Crucial Conversations” by Kerry Patterson et al. The book addresses situations with perceived high stakes, diverse constituents, and possibly highly emotions.

Looking for more Scrum tips? Check out Sprint Planning: How Long Should Sprints Be? or Kanban vs. Scrum: Which One and Why? and contact us, we love to help!

Topics: scrum collaboration documentation agile software-development
2 min read

Should Stories & Bugs Follow Different Workflows?

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

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

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

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

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

I hope this explanation helps you avoid unnecessary workflows!

Topics: blog best-practices bugs kanban scrum workflows software-development coding
4 min read

Do testers need to be in sprint planning?

By Marcelo Garza on Mar 3, 2021 11:30:58 AM

Blogpost-display-image_Why do testers need to be in sprint planning-In today’s business environment, high-speed implementation is a must. This applies to all products and services. Suppose you were using an application and got stuck because of a bug: after reporting the bug, you expect the team to fix it as soon as possible. If not, your next move is probably going to be switching to another service.

Software companies want teams working together providing quick and on point solutions to save time and resources, which can only be accomplished by the involvement of all of the teams working on a project. That’s why companies are opting for testing with Agile teams, since it allows for a greater collaboration across teams on a project. 

Agile allows a key collaboration between testing teams and developers which can’t always be accomplished with traditional approaches. It enables testers to share their perspective from the start of the sprint planning; this leads to less bugs during testing and creates a better possibility for sprint delivery dates to be met on time.

Let’s dig a little deeper to understand what this means.

The objective of Agile/sprints/scrum 

Agile methodologies were born as an alternative to traditional software development approaches, like waterfall methodology. 

The following images show the big difference between agile and waterfall methodologies. (Source)

wCXkvvXwQxlBYxwzr_327Yp6iURV_I96Tp1aH_7sZ_o-nN_WgAHqwLsCGZhKraLYAj96nyay0z6VH3GqeZvv7HdSwF1OCGvp

On one hand we can see that the traditional approach (Waterfall) aims to understand user needs and develop a product. After development, testers test the product and report bugs before deployment. The development team then works on them and fixes any errors using the best possible solution. This is progress through phases, one starts only when the previous one ends; this does not create an opportunity for proper feedback or collaboration between testing, developers and users teams.

On the other hand, Agile is mainly focused on performing constant, small deliveries of the product in order for the customer to be able to see how the product advances through the lifecycle. This gives the opportunity for testing to take on a bigger role and to get involved at an early stage of product development and throughout all the lifecycle of the product.

Agile has four important values:

  1. The focus should be more on individuals and interactions instead of processes and tools

  2. Working software is more important than comprehensive documentation

  3. Customer collaboration is more vital than contract negotiation

  4. The process should respond to change rather than follow a plan

Testing in sprint planning: The goal of sprint planning

During sprint planning, the team discusses which stories they will focus on in the upcoming sprint based on aspects like priorities, time frame, feasibility, etc.

The whole team involved in the development of the product should be involved, and if additional expertise on specific backlog tasks is required, then stakeholders can also be part of it.

Sometimes, during this meeting, the testing team can take a secondary role since the main focus tends to be on the development of the stories; this is understandable since it will set the start of the sprint. However, the testing team's' perspective can lead to some serious benefits for developers.

Why testing should be involved

One flaw of working in traditional testing (i.e. Waterfall methodology) is that during the test case design phase, although testers receive the requirements, most of the time they don't get access to the software they will test until it is time to begin the test execution phase.  It is well known that there is usually a big gap between what a requirement specifies and the actual software developed. 

This leads to a huge time investment on the testing side to reach out to both developers and users to define how the product works and how it should work in order to define the correct test scenarios and test cases.

Agile methodologies give testers the opportunity to be involved in the development of the product from the get-go. Testers can be involved in the design of the software by working closely with developers to assess and advise on testability aspects.

An Agile tester should understand the relevance of technical skills. A tester is always prepared to contribute to the technical discussions of the team. Their contribution may extend up to code reviews, user stories grooming, and understanding requirements. The Agile Software Tester gets to work with the developers when they are performing unit testing and share the perspective of testing from a tester's point of view instead of a developer's. The tester can work collaboratively and productively with the product owner and the customer to form acceptance criteria from the sprint planning itself. 

Before any user story is sent for development, the tester and other team members can discuss the complete user story with the team members to find out what the customer wants. Having testers collaborate with developers from the very beginning of sprint planning helps to achieve more accurate estimations and to ensure that everyone has some testing tasks as part of their responsibilities

Great testing teams know they need to become an extension of the customer and end user. Testers need to understand the customer's needs: an Agile tester should be able to describe the feature as well as the customer.

Drop us a line for expert advice on testing and all things Agile, we'd love to help your teams achieve their true potential.

Topics: blog testing tracking collaboration agile software-development
3 min read

Could Testing Be the Missing Link for Effective Agile Transformation?

By Praecipio Consulting on Feb 20, 2019 7:03:00 PM

NOTE: The following is a guest post by Tricentis Director of Product, Ryan Yackel.

A modern testing platform is a critical, but often overlooked, element of successful agile transformation. Could QA (Quality Assurance) be the missing puzzle piece in your quest to deliver higher quality software faster?

The pace of software development is accelerating, and technology teams face increasing pressure to adopt agile development and continuous delivery models so that their businesses can more quickly respond to customer demand.

But your first-mover advantage will suffer if you are first to market with mediocre software.

If you fail to deliver high-quality digital experiences at the pace today’s users demand, you risk alienating customers. In the case of defect-ridden software, poor user experience, or a catastrophic bug, you risk losing significant market share and damaging your reputation.

Software Testing

In the rush to beat the competition to market, organizations are transforming software development and delivery processes. But too often, business leaders fail to prioritize QA transformation, and QA teams are stuck using ineffective legacy solutions that were built for outdated waterfall environments. The reality is that as long as your testers are using legacy QA tools, your transformation will remain incomplete.

Legacy QA tools like Micro Focus Quality Center cannot accommodate modern development workflows. (Year over year, Micro Focus Quality Center (HPQC) has been among the least recommended testing tools for agile teams in VersionOne’s State of Agile Report.)

Legacy tools do not integrate with open-source automation tools, which limits testers’ options for accelerating test cycles and makes it impossible to integrate QA into continuous delivery pipelines. This means QA teams lack visibility and are not able to test new code as it is written. Development is further delayed when developers cannot quickly access test results and mitigate issues QA has found. As a result, releases are delayed, and quality inevitably suffers.

When testing occurs at the end of a development sprint, bugs are often embedded in the code, where they are significantly costlier and more time-consuming to correct. As a result, the myth of the QA bottleneck persists. Or worse, the QA process is rushed, and organizations end up with defect-ridden releases that fail to provide the high-quality experiences their customers demand.

Development and QA

If you can integrate quality into agile and DevOps processes, instead of treating it as an afterthought, testing can occur almost simultaneously with development. When a tester finds a bug, he or she can alert a developer to address it right then, instead of after lines of dependent code have been written on top.

With the right approach QA can help speed development by helping developers identify potential defects early. That means that QA is no longer pressured to complete testing quickly as the last step in a sprint. With a truly agile testing approach, QA can become a strategic enabler of business success, rather than a bottleneck.

Integrated Testing

Successful agile organizations have adopted modern test management tools like Tricentis qTest to successfully integrate testing into modern development and delivery processes. Tricentis qTest offers a real-time Jira integration and centralizes test automation management across frameworks and tools – including out-of-the-box integrations and a robust API for test automation management. qTest also offers testers in DevOps environments a single platform for unifying tests that run through continuous integration with other tests.

Contact us to learn more about how we can help you accelerate your agile transformation by modernizing testing.

Topics: blog best-practices devops testing digital-transformation agile software-development tricentis
15 min read

Hello World From Praecipio Labs

By Praecipio Consulting on Mar 12, 2018 11:00:00 AM

Machine learning, artificial intelligence (AI), and other advanced technical concepts are not new to Praecipio Consulting's engineers. In their spare time, they like to experiment, solve problems, and test ideas in a variety of areas. And the way they see it is they succeed, or they learn. Praecipio Labs, formalized in 2017, has really been around since the beginning. Whether it was a problem that needed solving, or it was just innate curiosity, Praecipio Labs was there to dig in and find a solution - or just have some fun! Most of the team's activity includes a variety of topics that may not be beneficial today, but are interesting nonetheless - like AI, improving advanced systems configurations, and much more.

So, who's the fearless leader?

Christopher Pepe, the Dragon of the West, oversees Praecipio Consulting's more technical endeavors. Having studied neural networks in college for robotic control systems, he has recently revisited the topic to enjoy some of the advancements that have been made. As artificial intelligence is held up as the greatest thing the universe has ever known it seemed like the right time to jump back in. Together with a ragtag team of interested engineers, Christopher is leading the Praecipio Consulting machine learning think tank to see if they can converge on a future that is better than a bag-o-if statements.

Some of Pepe and team's early projects included the Jira Toaster and Beer Me Jira. That was just the beginning. Today, Praecipio Labs is beginning to experiment with applications for machine learning. 

Pepe's recent experiment with text generation with neural networks is one of the many learning opportunities. We explored with Pepe his most recent experiment. 

 
 
 
Video Thumbnail
 
 
 
 
 
 
 
 
 
 
 
0:56
 
 
 
 
 
 
 
 
 
 
 
 

 

Concept

Using neural networks to generate text is certainly not novel but is a fun exercise. It is also a fairly simple problem since there isn't much preprocessing to create training data. (In most data science and AI exercises one spends the majority of the time formatting and processing data.) The idea here is simple, we want to train a neural network on a given body of text (corpus) so that it can generate similar text. In this way one can generate text in the voice of the author.

I took on this experiment to build an AI that could speak in my voice. As with any worthwhile endeavor, I learned more than I accomplished.

Approach

People approach this problem with either character based or word based inputs. Character based means that if your input is "Hi there Bob" then the network is fed "H", "i", " ", "t", "h", "e", "r", "e" and so on. If word based then the network is fed "Hi", "there", "Bob." Character based approaches allow the network to do cool things like create new words. Word-based is an easier approach and in our approach was the more successful choice with less training. Our approach used a wide-ish, shallow network instead of a deep network. That means our model memorized the corpus rather than learning the meaning of it.

Training data

In all training problems, you need a large set of training data that has inputs and corresponding outputs. For instance to build a tweet sentiment model one needs 1+ million tweets with an associated sentiment label (0=mad, 1=annoyed, 2=flat, 3=happy, 4=overjoyed) and the quality of that training data determines how good your model is. That's a big task to build on a novel data set.

On the other hand training, a text generator is a simple process. The input is some number of words and the output is the next word in the corpus. Using this paragraph as an example one input might be "On the other hand training a text generator is a" and the associated output value would be "simple." The next input would be "the other hand training a text generator is a simple" and the output would be "process." 

Stepping in this way over the corpus a number of times the network eventually converges to an acceptable point.

Goals

GPU Training

To get anywhere with deep learning one really needs to train on GPUs. There are some nuances to using GPUs on AWS, and to writing code that will take advantage of multiple GPUs. This project allowed us to figure out a successful approach to using AWS for training our models.

Intro to Recurrent Neural Networks

My intro to neural networks was in college using plain old fully connected, feed forward networks for non-linear control systems  (it was a bit more state of the art back then but would still be a fun project). Life and career keep me focused elsewhere and I've only recently jumped back in. There are a dizzying array of new architectures, and approaches to interesting problems to solve. I have long been interested in time series problems and have been focused on recurrent neural networks. This was a simple but non-trivial challenge to write from scratch.

Results

After 84 epochs the loss function was minimized to 0.1195. Providing a random sample of text from the corpus as a seed the network produced this output:

 to merge completed stories and bugfixes as quickly as possible into develop so that integration and quality testing can begin sooner. merging a feature branch into the develop branch should start a build and potentially deployment to an integration testing environment. deployments can be manually triggered, but the if automatic then one is always testing the tip of the develop branch. integration and qa testing should always be occurring on the develop branch. feature branches are where developers write their code. this keeps their work isolated from other developers until it is stable. stories are sized so that a feature branch lives for 1 to 3 days. many feature branches make up a deliverable epic. features are integrated into develop by way of pull requests. pull requests are gated merges. before the feature branch can be merged into develop the code must go through a review. this can be forced with permissions or by a convention that the team uses. the merged pull request also provides a single commit to use for cherry picking features. cherry picking process again note that this process circumvents best practices  

The source corpus content is listed here. You can see that the network simply memorized and regurgitated the source.

The Develop branch is the shared branch that developers use for integration testing and to accumulate features from the product backlog. The aim is to merge completed stories and bugfixes as quickly as possible into develop so that integration and quality testing can begin sooner. Merging a feature branch into the develop branch should start a build and potentially deployment to an Integration Testing environment. Deployments can be manually triggered, but the if automatic then one is always testing the tip of the develop branch. Integration and QA testing should always be occurring on the develop branch.  Feature branches are where developers write their code. This keeps their work isolated from other developers until it is stable. Stories are sized so that a feature branch lives for 1 to 3 days. Many feature branches make up a Deliverable/Epic. Features are integrated into develop by way of Pull Requests.

Some generated samples varied or had incomplete sentences but overall this model did an excellent job of recreating the source document.

I, and the team, look forward to sharing more experiments and tests like this one soon.

Topics: praecipio-consulting blog artificial-intelligence software-development machine-learning

Praecipio Consulting is an Atlassian Platinum Partner

This means that we have the most experience working with Atlassian tools and have insight into new products, features, and beta testing. Through our profound knowledge of Atlassian environments and their intricacies, we can guide your organization as you navigate these important changes.

atlassian-platinum-solution-partner-enterprise

In need of professional assistance?

WE'VE GOT YOUR BACK

Contact Us