Fannie Mae's SDLC Journey from Waterfall to Agile

schedule Oct 15th 03:15 PM - 03:25 PM place Ballroom D people 15 Interested

A well-defined Software Development Life Cycle (SDLC) is a requirement for many government institutions. However, the typical SDLC process is very "Waterfallish" by nature of it's phase gates and documentation requirements. This talk will explain how the SDLC at Fannie Mae has evolved as the company has transformed from a Waterfall to a lean Agile organization in alignment with Agile best practices.

 
6 favorite thumb_down thumb_up 0 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

  • Overview of Fannie Mae's history as a Government Sponsored Entity
  • FM's introduction of a formalized SDLC process
  • SDLC documentation and phase gates in a Waterfall world
  • Changes to the SDLC process as FM has transitioned from Waterfall to Agile
  • State of the SDLC today and future changes as FM adopts Dev Ops and Scaled Agile

Learning Outcome

The objective is to demonstrate how the SDLC process can evolve with the adoption of Agile practices and align with the Agile Manifesto's core values of "Individual and interactions over processes and tools" and "Working software over comprehensive documentation".

Target Audience

Those who are following an SDLC process while striving to align with Agile best practices

schedule Submitted 5 months ago

Comments Subscribe to Comments

comment Comment on this Submission

  • Liked Cherie Silas
    keyboard_arrow_down

    Cherie Silas - Power Coaching – Pushing the Boundaries to build better teams

    45 Mins
    Talk
    Intermediate

    Elevator Pitch

    Sometimes teams need more than just questions. They need scrum masters and coaches who are courageous enough to have the hard conversations, challenge their decisions, push them to the next level. During this session we will introduce participants to some anti-patterns that have arisen in the scrum master and agile coaching communities and discuss ways to break free!

    Description:

    Coaching Agile Teams is all about asking questions and allowing them to self organize, right? Well, that's just part of the mission. During this session we will introduce participants to some anti-patterns that have arisen in the scrum master and agile coaching communities and discuss ways to break free!

    Sometimes teams need more than just questions. They need scrum masters and coaches who are courageous enough to have the hard conversations, challenge their decisions, push them to the next level. However, sometimes we push our teams a bit too hard and create negative conflict. It's times like this when we need to demonstrate how to reach out and make the first move to repair the relationship. We will introduce the concept of repair bids to help in this area.

    Lastly, we learn a model to put into practice to create a coaching alliance with teams so you can be in agreement on how you will work together for their best interest and improvement over a period of time.

    The reason we chose to create this session is that over the past few years we have noticed that as people are learning more about coaching they are getting out of balance and believing that the only thing that coaches are allowed to do is ask questions. We've noticed that scrum masters lean so far in the direction of self organization that they no longer believe they can challenge teams to grow or to move beyond where the team decides to be. We believe that the root of the problem rests in the fact that people are learning a bit about coaching but not actually learning how to be a coach. We would like to introduce to the attendees the more direct coaching methods that are available for use such as 1) direct communication, 2) challenging, 3) courageous questions that push the edge of the comfort zone, etc.

    Session is collaborative and includes interaction with the participants throughout. Also has collaborative exercises.

  • Liked Pete Oliver-Krueger
    keyboard_arrow_down

    Pete Oliver-Krueger - eWSJF - Using Real-World Lean Startup, Emotions, and MVPs in Product & Portfolio Decision Making

    10 Mins
    Lightning Talk
    Executive

    Are you “going Agile” but your executives are still asking you for Gantt charts and delivery dates? Here’s an exercise to do with them instead. Usually, they just want to know when to check back on “the project”, and whether or not their money is being well invested.

    To answer the last question, many teams have discovered the “Weighted, Shortest Job First (WSJF)” method of project prioritization. Basically, if you have two items of equal effort, but one has twice the return on investment (ROI) of the other, do the one with greater ROI. And if you have two items of equal ROI, but one can be done in half the time, do the shortest job first. But that’s not enough. We all know of projects that had great promise, but customers wouldn’t pay for it.

    Lean Startup has discovered that emotions are one of the best leading indicators (predictors) of future product success. Emotional-WSJF (eWSJF) balances customer demand with Minimum Viable Products (MVPs), i.e. "this only has true business value if we can deliver within 2-3 sprints."

    I use eWSJF within my teams to prioritize Epics, and I’ll show you how to use it to keep your executives happy! It replaces the conversations about “Show me a Gantt chart,” and “When will this be delivered?” My executives instead ask, “Have you talked to any customers?” or “Can you build it faster?” To which my teams respond, “Yes we have talked to customers, and they’re even helping us beta test it!” and, “The next version will be delivered in two weeks, and here’s what it contains.”

  • Liked Thomas Stiehm
    keyboard_arrow_down

    Thomas Stiehm - Failure is Inevitable But it Isn’t Permanent

    Thomas Stiehm
    Thomas Stiehm
    CTO
    Coveros, Inc.
    schedule 5 months ago
    Sold Out!
    45 Mins
    Talk
    Intermediate

    Elevator Pitch:

    Agile Transformation is harder than it needs to be because we often find ways to consciously or subconsciously sabotage our efforts if we can recognize this behavior it is possible to intervene and make a change for the positive.

    Abstract:

    Have you ever been on a project where it seems like team members are preventing the team from getting better? Why do they do that? I don’t know either- a psychologist might have to answer that. What I can tell you about is my experiences in seeing teams become their own worst enemies and unwittingly sabotaging the projects they are trying to make successful. My goal is to help you realize when you or those around you are behaving in a way that is going to lead the team plateauing or even failing. I have often found that many teams can get stuck, or plateau, at a certain point along the continuum of agile maturity. These teams can meander around without getting better or even changing anything for long stretches of time. I have also worked with teams that put so many hurdles in their own way that they had no option but to fail. They often fell back into old patterns and gave up hope that things can get better. As an Agile Coach, I have often felt that one of the most valuable things I can share with the people I coach are my failures. I have worked on Agile projects for a long time, and I have failed in many different ways. Having been through failure, I have learned that to keep getting better you have to recognize the things that you do that lead to plateaus and failures to overcome them. This talk is for coaches and team leads who want to make sure their team isn't getting stuck in a rut, or who are trying to get out of a rut with their health and sanity intact.

    Failure signs and examples

    No process is defined and followed

    • ex. Projects that claim to be agile without any experience or training, or doesn’t have basic agile practices such as retrospectives, I.e. we are agile because we have hour long daily standup meetings.

    Process practices are ignored or removed with no compensating practices

    • ex. Agile practices hold each other together, supporting each other by the value they bring to the project, some teams decide to not do some practices without doing something else to get that value, for instance pair programming provides code review and knowledge transfer, many teams don’t pair program and don’t do code reviews and or knowledge transfer.

    Automation is not valued or planned into work

    • ex. We will automate tests later. Often that later never comes and the team is left with a code base that is hard to maintain and change because you don’t know what your changes break.

    No stakeholder expectations management

    • ex. The only way a project can negotiate scope and or schedule is to actively manage stakeholder expectations. An example of unmanaged expectations is the PO that never says no to a feature request or the executive that decides what must to delivered and when it must be delivered.

    Quality and testing practices are an after thought or short changed on schedule

    • ex. Teams that don’t complete sprint commitments because the testers get coded stories too late in a sprint to do all the required testing and the rest of the team isn’t held responsible to help test.

    No negotiation allowed in deliverables and or schedule

    • ex. Executives that dictate all of the terms of a project before a team is even selected.

    The team doing the work didn’t estimate the work but are held to an estimate

    • Many government projects have such a long procurement cycle that no one from the proposal team is put on the project.

    Part time team members are in the critical path

    • ex. Sometimes people with special skills are needed for a part of a project. If the person is part time but their work is in the critical path the project is in trouble.

    Heavy team turn over

    • ex. Heavy turn over is a sign of a project that isn’t on track, even if it hits its deadlines the quality and output will suffer.

    Political motivations more important than team’s ability to do work

    • ex. If the team is setup to fail for reasons outside the team, they will most likely fail.

    Distraction from issues outside the work that needs to be done

    • ex. Scrum Masters that don’t shield the team from issues outside the work that needs to be done during a sprint will end up with a team that doesn’t hit the mark.

    Examples of what can be done to avoid failed projects:

    Focus on shielding the team from outside influence

    • Have the team focus on the things they can control and prevent outside issues from distracting the team.

    Negotiate delivery with the team

    • The team can develop an understanding of what it can deliver. Trying to make the team do more is going to lower quality and potentially make the project take longer.

    Management of stakeholder expectations

    • Stakeholders always want more, that is their job. Let them ask for anything but set their expectations on what is really going to happen.

    Focus on technical excellence, quality, and automation

    • If you want your teams to get better, have them focus internally on things they can control like technical aspects of the project including quality and automation.

    Hire motivated team members and make it possible for them to work

    • People who care about what they are doing will always be better than the cheapest people that don’t care. Hire people who care.

    Maintain a progressive planning pace for getting requirements ready

    • Agile requires planning at different levels, skipping a level for any reason means there are going to be disconnects between your stakeholders and the people doing the work. Disconnects means the project will not product the results you want.
  • 45 Mins
    Workshop
    Beginner

    “The single biggest failure of leadership is to treat adaptive challenges like technical problems.” -Ron Heifetz

    We live and work in an increasingly interconnected and rapidly changing world. New business models are shifting duties to teams instead of individuals, which means people are now working more closely together. It also means leaders at all levels have to begin to adapt their leadership style to guide the intricacies of human dynamics and channel the collective knowledge of the groups they interact with.

    In this workshop we will explore how leaders create environments that navigate the complexity of interpersonal relationships, overcome the human element of barriers to change, and support the growth and engagement of their employees. Attendees will walk out of the room with a clearer idea of their own leadership style and a list of action items they can use (tomorrow!) to move their teams one step closer to higher performance.

  • Liked RUSHABH SHAH
    keyboard_arrow_down

    RUSHABH SHAH / Dave Omondi / Ghazi Omar / Philip Masiewicz - Introduction to TDD (Test Driven Development): Lessons from Loan Delivery application

    45 Mins
    Experience Report
    Beginner

    Test-driven development (TDD) is a programming technique in which the tests are written prior to the source code. It is proposed that TDD is one of the most fundamental practices enabling the development of software in an agile and iterative manner. Both the literature and practice suggest that TDD practice yields several benefits. Essentially, it is claimed that TDD leads to an improved software design, which has a dramatic impact on the maintainability and further development of the system.” (Reference: ieee.org)

    Fannie Mae, a government sponsored entity (GSE), is in the fourth year of it’s agile transformation. Teams use an Agile Maturity Matrix as a roadmap for optimizing their agile capabilities as well as technical engineering practices.

    As long-standing teams, we have a long track record of trying to incorporate persistent TDD practices with varying degrees of success. But it was only after the LDNG teams collectively matured their agile mindset and focused on optimization, implementation of TDD took flight.

    Past year, 4 teams comprising the Loan Delivery Next Gen were recognized for being the first teams in organization to complete highest agile maturity model’s category, hallmarks for which include: Feature level BDD, Test first mindset & All layers of testing are automated and executed on every check-in.

    • Do you want a real world example of implementing TDD in a large program?
    • Are you unable to grapple with the challenges of TDD? Is TDD frustrating you?
    • What are some misconceptions about implementing TDD?
    • How do you get a good ROI (Return On Investment) by developing TDD capability?
    • By the way what’s the big deal about TDD? Is it really helping or just another hype??

    This talk is intended for the technical members on a cross-functional team (responsible for the “how” who are faced with implementing TDD) as well as well as Scrum Masters and Product Owners who are interested in understanding the benefits of TDD and why they should be advocating for / insuring there is capacity to develop and mature these practices as part of the team’s work. Unlike most TDD training sessions, this focuses on the subtleties and challenges of implementing TDD in a pragmatic manner that address everyday concerns of a large organization.

    Join us to get answers to all these questions based on our real world experience as well as see a live intuitive demo.

    While we are not experts in this field (at least not yet), we will share our journey and practical learnings. How does that sound?

    Our presentation shares experience of Loan Delivery teams. We will share our journey in adopting TDD along with moving away from testers in team, to training developers with test-first mindset. We will also cover misconceptions and touch a little on testing techniques for developers. We would like to cover the non-technical blind spots that most TDD trainings might miss, based on our real world experience.

    Also in the spirit of Agile, we will present practical real-time example of TDD in action that addresses a number of concerns, but mainly how to re-factor code using TDD. We will use personal laptop to demonstrate a loan calculator example.

  • Liked Jolly Rajan
    keyboard_arrow_down

    Jolly Rajan - Measure It! - How You Can Drive Continuous Improvement With Simple Metrics

    Jolly Rajan
    Jolly Rajan
    Agile Coach
    EcoLogik Consulting Group
    schedule 5 months ago
    Sold Out!
    10 Mins
    Lightning Talk
    Intermediate

    You don't need complex metrics that are onerous to track and analyze to drive continuous improvement. Lets look at 6 metrics that are easy for any team to use to accelerate their progress to being a high performing team.

  • 45 Mins
    Talk
    Intermediate

    The Triple Track Method

    This talk is for Agile teams delivering using the Scrum framework

    Who desire to put the customer as the central force in maximizing product value but struggle to do this in the midst of an intense focus solely on delivery of feature after feature

    Unlike maximizing how many features are shipped by a certain date in a certain budget with limited customer engagement or having separate teams gather customer insights for the Agile delivery teams

    The discussed approach focuses Agile teams on maximizing a positive customer behavior outcome and the resulting business impact through direct customer interaction throughout the delivery cycle

    This results in moving the team towards a collective product ownership mindset, bringing the team and the customer together to achieve optimal outcomes.

  • Liked Arlen Bankston
    keyboard_arrow_down

    Arlen Bankston - Performance Management in the Age of Agility

    Arlen Bankston
    Arlen Bankston
    Founder
    LitheSpeed
    schedule 5 months ago
    Sold Out!
    45 Mins
    Workshop
    Intermediate

    Agility is about adaptation, challenging the status quo, experimentation and learning. HR has historically hewed closer to compliance, but that has been changing rapidly.

    Today's nimble teams and workers will no longer tolerate stifling, staid environments and management practices. The newly popular label "people operations" implies an emphasis on human engagement over bureaucracy and regulation, and indeed many organizations have been moving this way.

    Be inspired by some of the most daring advances in human resources while also learning some practical approaches and techniques that can be applied to start leading your business down this path. We'll discuss new approaches in hiring, performance management, learning and development, and even the structure of HR groups and roles. Participants will also enjoy a few exercises that will illustrate some interesting techniques.

    Prepare yourself for HR in the next generation.

  • Liked Gene Gotimer
    keyboard_arrow_down

    Gene Gotimer - Build a Better, Faster Pipeline for Software Delivery

    Gene Gotimer
    Gene Gotimer
    Technical Manager
    Coveros, Inc.
    schedule 5 months ago
    Sold Out!
    45 Mins
    Workshop
    Beginner

    The software delivery pipeline is the process of taking features from developers and getting them delivered to customers. The earliest tests should be the quickest and easiest to run, giving developers the fastest feedback. Successive rounds of testing should increase confidence that the code is a viable candidate for production and that more expensive tests—be it time, effort, cost—are justified. Manual testing should be performed toward the end of the pipeline, leaving computers to do as much work as possible before people get involved. Although it is tempting to arrange the delivery pipeline in phases (e.g., functional tests, then acceptance tests, then load and performance tests, then security tests), this can lead to problems progressing down the pipeline.

    In this interactive workshop, we will discuss how to arrange your pipeline, automated or not, and so each round of tests provides just enough testing to give you confidence that the next set of tests is worth the investment. We'll explore how to get the right types of testing into your pipeline at the right points so that you can determine which builds are viable candidates for production.

  • Liked Gene Gotimer
    keyboard_arrow_down

    Gene Gotimer - A Definition of Done for DevSecOps

    Gene Gotimer
    Gene Gotimer
    Technical Manager
    Coveros, Inc.
    schedule 5 months ago
    Sold Out!
    45 Mins
    Talk
    Intermediate

    DevOps needs to consider many different aspects of software quality, including security. The term DevSecOps was developed to highlight that security is a focus of the pipeline, not a second-class citizen.

    Fortunately, we can define done for our pipeline so that it includes security. Continuous integration can invoke static analysis tools to test for security errors and check if we are using components with known vulnerabilities. Automated deployments and virtualization make dynamic environments available for testing in a production-like setting. Regression tests can drive traffic through proxies for security analysis. From the code to the systems where we deploy the software, the process can be designed to make sure that we follow security best practices, and not produce insecure software.

    Participants will learn how to construct a definition of done that focuses on security in a DevOps pipeline. They will see how to define security practices that build confidence that they are doing DevSecOps, and how those practices and criteria might mature over time.

  • Liked Glenn Buckholz
    keyboard_arrow_down

    Glenn Buckholz - Failing Faster with Kubernetes and then Recovering

    Glenn Buckholz
    Glenn Buckholz
    Technical Manager
    Coveros
    schedule 5 months ago
    Sold Out!
    45 Mins
    Case Study
    Intermediate

    Kubernetes is quickly gaining popularity, but does the technology deserve so many accolades. In this talk we learn what exactly kubernetes has to offer in the DevOps world. We see that as a service it can provide resources for your DevOps pipeline, automated tests, and the application you are trying to build. We visit an example implementation of such a pipeline and discuss some lessons learned about how to balance these three needs. Additionally, we look at what design considerations your application needs to make, you should consider for your automated testing infrastructure, and how all of this can be leveraged to keep consistent CM while deploying rapidly. Lastly, we explore how threading it all together can help you fail fast and recover quickly as well.

  • Liked Matthew Kleiman
    keyboard_arrow_down

    Matthew Kleiman - Pair Programming: Better Than Adderall

    45 Mins
    Talk
    Beginner

    Not all programmers are comfortable with coding alone for 10 hours a day. Matt Kleiman spent years programming inefficiently in a cubicle. His Attention Deficit Disorder (ADD) and other learning disabilities deterred his success on traditional development teams. Seeking out an environment that would nourish his strengths, he found Pivotal Labs. Pivotal's Extreme Programming practices empowered Matt. Attend his talk to learn how pair programming and test-driven development transforms ADD into an asset in the workplace.

  • Liked Leland Newsom
    keyboard_arrow_down

    Leland Newsom - Sprint with Agile, Deliver with DevOps

    45 Mins
    Talk
    Beginner

    Enterprises want to deliver more value with higher quality at a faster pace. Many development teams have adopted agile frameworks to improve their ability to deliver software. This has led to a local optimization for the development teams and they have become good at delivering potentially shippable increments of their products, but from there, they typically see organizational constraints in moving it to the customer. The development organization is quickly adding features to the queue waiting to be released, but the operations teams are struggling to support fires in production, maintain stability, and provide the environments and infrastructure needed so development teams can move their new functionality forward. The operation team’s focus on stability usually minimizes the number of changes in production thus creating infrequent, large batches being deployed at a planned date. Can Agile and DevOps bring the development and operations teams together to remove the organizational constraints in moving the software to the customer?

    In this session, we’ll talk about the relationship of Agile and DevOps, not as an intersection, but as a progression of capability with development and operation teams working together to remove those constraints. We’ll discuss how using Agile and DevOps practices together, teams can release value faster, with higher quality, and in more stable environments making it safer to deploy.

  • Liked Rupesh Kumar
    keyboard_arrow_down

    Rupesh Kumar - DevSecOps: Building a resilient pipeline

    45 Mins
    Talk
    Beginner

    To all technical members involved with building DevSecOps pipeline this talk is for you.

    In today's competitive world, fixing problems in the pipeline is still a human task and how many times have we seen that when pipeline stops, notifications are sent out and then we wait........ for someone to identify, diagnose and resolve the issue. I am sure we have all been there and done that.

    Is this good enough?

    In my talk I will share some smart ways of infusing self healing into your existing pipeline. We all know it’s good to set thresholds and quality gates in the pipeline, so you can stop the pipeline when the threshold or the gate fails and notify appropriate stakeholders. But in this approach the problem is brought to the attention of the humans to take corrective action what if this issue gets self diagnosed and self healed by the pipeline itself!

    Imagine that....

    I will shows ways on how self-healing can be built into the pipeline by leveraging the data that gets generated from within the pipeline by converting it into information, and the information into knowledge, and the knowledge into insight to make intelligent data driven decisions and remediation.

  • Liked Jonathan Kauffman
    keyboard_arrow_down

    Jonathan Kauffman - Accept Kanban, or Keep Living a Scrum Lie?

    Jonathan Kauffman
    Jonathan Kauffman
    Consultant
    Coveros, Inc.
    schedule 5 months ago
    Sold Out!
    45 Mins
    Talk
    Intermediate

    Are you lying to yourself? Do you keep using Scrum even though you should have switched to Kanban months ago? Scrum is a popular Agile development methodology, but if it doesn’t make sense for your team, then you might be better off switching to Kanban. I will describe my experience working with a team transitioning to Agile and attempting to use Scrum. We initially did a good job at planning, but external dependencies and unplanned work disrupted our commitments. We stopped planning and fell into the pattern of moving most of the stories to the next sprint at the end of every sprint. I will discuss some telltale signs to help you identify when you shouldn’t be using Scrum and might benefit from a Lean methodology like Kanban. I will also provide you with some practical suggestions that you can use to help your team make the transition from Scrum to Kanban.

  • Liked Beth Hatter
    keyboard_arrow_down

    Beth Hatter - Beyond Servant Leadership: The Evolution to Empathetic Leadership

    45 Mins
    Workshop
    Beginner

    The concept of servant leadership is nothing new in the agile community. Servant leadership shifts the focus of leaders from managing teams to empowering and supporting teams. But as the world continues to evolve, are we really forming the connections we need to have truly high performing teams? Empathy forms the foundation of connections between individuals, teams, and organizations, and is the key to successful in supporting the needs of our customers and society. To have truly high performing teams, we need to move beyond servant leadership to a more empathetic leadership mindset. So how do we recognize, nurture, and grow empathy and grow from Servant Leadership to Empathetic Leadership?

    This workshop will guide participants through several topics. We'll explore how empathy changes our thinking, how empathy and agile success relate, and how to build empathy within ourselves, our teams, and our organizations.

  • Liked Thomas Stiehm
    keyboard_arrow_down

    Thomas Stiehm - Walk before you run with Continuous Delivery

    Thomas Stiehm
    Thomas Stiehm
    CTO
    Coveros, Inc.
    schedule 5 months ago
    Sold Out!
    45 Mins
    Talk
    Intermediate

    Elevator Pitch:

    DevOps and Continuous Delivery call for a new look at agile software development best practices in order to maximize the efficient delivery of value.

    Abstract:

    Is your agile team “using DevOps” but still struggling to successfully deliver quality software to Production repeatably? Are you part of an agile team struggling with how to best support your DevOps (CI/CD) pipeline? As your practices mature it is natural to adopt best practices to improve the team. As the team gets better, the practices they follow need to change as well. Initial agile software development practices are designed to help the team bring order to the chaos of their projects. These practices help them become predictable and deliver working software on a regular basis. As a team progresses to continuous delivery, they need to focus on a new set of practices that leverages their build pipeline to build confidence in each build of the software. This session will lay out the best practices and process evolution to move from delivering at the end of a release, to delivering at the end of each sprint, and finally to delivering on a continuous basis.

    DevOps Maturity levels

    0 - Ad Hoc- rare builds with limited, if any, reliability. There is no build pipeline or any automation. Provisioning, deployment, or test are ad hoc.

    1 - Continuous Build - builds happen on a regular or continuous basis but without tests. Teams know the software compiles but nothing else.

    2 - Continuous Integration - Sufficient level of unit test coverage and static analysis gives the developers a high level of confidence that the software works as they intended it to work.

    3 - Continuous Delivery - Software is deployed to an environment automatically based on passing CI and automated tests are executed in that environment. You have a build pipeline or are in the process of putting one together. The team has confidence that if the software passes all tests and inspections that the build might be a release candidate. The team will start experimenting with techniques like feature toggles to have selectively activated code in specific environments.

    4 - Optimizing Continuous Delivery - making your build pipeline take less time using parallel builds and shifting tests left (doing some perf or security testing earlier in the process). An initial build pipeline is fully established and the team is focused on making the pipeline fast while increasing confidence in the result. At this stage the team wants to use techniques such as build step parallelization to shorten the build cycle and adding tests in targeted areas. The goal of this level is to have a fast build that, if it passes, the team feels it ready to go into production. The team will have defined practices around selectively activated code in defined environments.

    5 - Continuous Deployment - The ultimate expression of a build pipeline where the team has such confidence in the pipeline and its ability to determine build health that all check-ins are release candidates and any build that passes all tests and inspections are automatically put into production. This also requires a healthy rollback process that the team has tested and is confident that it will work if needed. Most teams will have adopted practices that support their practice of releasing into production multiple times a day.

    The goal of creating a build pipeline is to help the team progressively gain confidence in the software they are building. With each level of maturity the team is focused on developing best practices for delivery of software in smaller chunks. The best practices change with the delivery timeframe. Best practices for each timeframe include:

    Release Delivery Maturity

    • All work required to release software is completed in the release
    • Functional test suite is used to perform regression testing
    • Software is production quality by the end of the release with the goal of having software working at all times
    • Since the release spans multiple sprints the production deployment timeframe is the release and the team uses progressive planning for a release

    Sprint Delivery Maturity

    • All work required to release software is completed in sprint
    • Software is production quality by the end of the sprint
    • Functional test suite is used multiple times a sprint or is continuous during the sprint
    • The sprint is the release timeframe for the team but the team may have plans that span multiple sprints
    • The team may use branches or feature toggles to mange feature development

    Continuous Delivery Maturity

    • Software is always at production release quality, the goal is for the software to always be releasable
    • All automated tests and inspections are continuous
    • Human required processes are still performed but not in the path of release, ex. Accessibility testing
    • Feature activation is managed by software techniques like feature toggles
    • The release rollback process is matured and tested on a continuous basis

    Examples of teams progressing through build pipeline maturity

    Forge.mil - started with six month plus release cycle with no automation,through a series of incremental improvements we reduced that to releasing after every sprint using a totally automated process

    REProfit - greenfield project that we took over and built out a build pipeline immediately. Developed a Continuous Deployment pipeline that took around 2 hours to go from check in, to released in production.

    Abiomed - Embedded medical device with no automated build or pipeline. Created an automated build process including automated testing and a Continuous Delivery pipeline that deployed to test environments that ran test automation with every successful build.

  • Liked Max Saperstone
    keyboard_arrow_down

    Max Saperstone - Managing BDD Automation Test Cases Inside Test Management Systems

    45 Mins
    Case Study
    Beginner

    Behavior Driven Development has been around for a while, and it is here to stay. However, the added abstraction levels present in it, pose a technical
    problem for writing and managing tests. While it does a great job of marrying the non-technical aspect of test writing, to the technical flow of an application
    under test, keeping this information under source control becomes problematic. Frameworks such as Behave, Cucumber or Robot give subject matter
    experts that additional ability to write test cases, however, they are often restricted to access to them, as if test cases are treated as code, they stored in
    source control repositories. Additionally, frequency these Given, When, then steps soon grow to an extent where they become difficult to manage without
    an IDE, and most non-technical people don't want to run an IDE.
    Through the use of Management Tools such as JIRA, and VersionOne, Max will show how to simply manage these non-technical steps and keep them in sync
    with the automaton in an SCM, such as Git or SVN. Additionally, he'll discuss and show how to link these tests to requirements, and stories in development,
    to provide traceability, and continuous integration support. He'll share his hands-on experience developing an open sourced product to help manage these
    tests, along with proven workflows at an enterprise level for ensuring full team buy-in on both non-technical and technical aspects of test case development.

  • Liked Georgiy Deliya
    keyboard_arrow_down

    Georgiy Deliya - Industries use Big Data analytics to get the job done, why would you ignore it?

    Georgiy Deliya
    Georgiy Deliya
    Consultant
    Coveros
    schedule 5 months ago
    Sold Out!
    45 Mins
    Talk
    Beginner

    Technology has developed modern society and will continue to be a major player in improving the future of global business. With digital information constantly evolving and becoming more accessible we find ourselves in the era of Big Data and connectivity. Big Data is used in describing the increase in digital data sourced and generated from many formats. Data is the foundation which helps any organization to function successfully. With data storage there is immense information at your fingertips. Use of it, helps organizations to have the advantage in performing thorough analysis, extracting valuable information, as well as providing new opportunities and advantages. Data is being created constantly and the need for more storage and analysis results in cheaper storage. Businesses need as much value as possible from mass amounts of stored data. Relative to the rapid change of data, analytics require new methods and processes to store more information as well as a new type of Big Data. It is necessary that these amounts of Big Data are stored, analyzed and extracted properly in order to validate the information.

  • Liked Phillip Manketo
    keyboard_arrow_down

    Phillip Manketo - Energize you Communities of Practice (this session was withdrawn)

    45 Mins
    Workshop
    Intermediate

    (this session was withdrawn)