Keynote 8:50 — 9:50
The car that Scrum built
We have found team morale to be a multiplier for velocity.
The Agile Manifesto applies to all industries. When we read it and its 12 principles, and switch each mention of “software” with “customer visible value”, we have an elegant methodology that applies to all business.
Session 1 10:00 — 11:00
Top 10 problems found in immature Govt Agile Teams and how to solve
Over the last 10 years I have implemented Agile Programs at scale for the Government at Lockheed Martin both domestically and Internationally. Within the last 18 months I have been an Agile Coach for many programs across multiple lines of business. I have seen very similar patterns in the problem areas on these projects.
I will walk through the top ten, giving examples from many of my programs, how we have solved those issues and the results.
- Not having a coach, and not training the team (the whole team)
- Tailor the process before they understand what practices are used for
- Assume the customer will say No before and discussion
- Do not set up the Performance Management Baseline
- They do not plan correctly (example only one sprint ahead)
- Utilize two methods to manage program, the PMO uses traditional tool set, technical team another
- Work their way around a tool not meant for the Job (Jira/Greenhopper) on large programs
- Use Agile for part of the process as opposed to the whole program (example just development)
- Do not understand how to break down their work into small pieces
- Do not Use Visable progress Indicators for transparency
Decision Making Techniques for Not for Profits
(Not for Profits)
Agile approaches emphasize delivering business value to stakeholders. The concept of business value is a difficult concept to get your arms around, doubly so if you are working in a Not for Profit.
One way to address the problem is to see the idea of business value for what it is – an aid for making decisions. In this talk Kent McDonald describes three simple techniques that you can use to make decisions in your Not For Profit.
Kent describes how to apply the idea of business value to not for profits and shows how you can use three techniques – Real Options, Decision Filters, and Purpose Based Alignment to make decisions in any kind of organization, even Not for Profits.
When Product Owners Are Challenged, Try Value Teams
When people learn about agile they usually learn about Scrum (since it is the most popular flavor of agile). While Scrum is beneficial, it does not have answers to all the challenges of software development. One of the common challenges teams face is that of having an effective Product Owner. From experience, it is not about who is fulfilling the role of the Product owner in your organization but about the definition of the role itself. We have played with many different variations of the PO role, till we ended up with the concept and structure of the Value Team. After using Value Teams in many corporations they seems to be a practical solution to many problems about how agile can work in complex environments where there is no ONE product owner, but rather multiple organizations and people that have a say in what needs to get build and how. This session will present the idea of Value teams and answer questions on how to create them, how they operate, who is in charge, and why they are so critical to the success of the agile delivery team.
Agile Methods 101, an Interactive Workshop
Confused by the buzzwords? Wondering which Agile framework to start with and what the differences are? You’re not alone.
This fun hands-on workshop features and in-depth comparison between Scrum, eXtreme Programming, and Lean/Kanban. Come to this session first, and get the basic terminology people will be using throughout the day.
Lean Innovation on Agile Teams
(Business Point of View)
The Lean Startup© methodology has taken the business world by storm, and is revolutionizing product development through the application of a Build-Measure-Learn cycle, and the systematic application of techniques such as Customer Discovery, Customer Development, and Pirate Metrics.
With agile teams in place, how can organizations now drive lean product innovation on their agile teams? How can we bootstrap product development with product roadmaps and business requirements that are truly aligned with end-user needs?
Learn how to drive Lean Innovation on your agile teams by:
_ Setting up clear, short-term experiments using the popular Lean Canvas tool;
_ Structuring direct customer interaction through systematic customer interviews;
_ Release planning informed by both qualitative & quantitative feedback through the design of actionable metrics;
_ Generating user stories and acceptance criteria directly evolved from the above data;
_ Creating a _dual-track_ of no- and low-cost UX prototyping in conjunction with agile delivery to reduce the cost of iteration while validating ideas and features; and
_ Designing collaborative workspaces that enable tight collaboration and higher productivity through visual management, creative lighting, lounge space and other proven techniques.
The Lean Startup© is a registered trademark of Eric Ries.
Patterns and Principles of Scaling Scrum with Scrum
Scrum is a very popular Agile Framework, but “out of the box” it is restricted to a single, co-located, Team working on a Single Product. Most situations are more complicated than that: multiple locations, multiple Products, multiple Teams, and so on. Dan introduces a few patterns (Development Team, Coordination Team, Workgroup, …) and shows how they can be combined, using a few simple principles, to work in some quite complicated situations. Dan will also show how the two most popular scaling frameworks (SAFe and LeSS) can each be derived using these patterns.
Leading an Agile Legacy
As the tech industry increasingly transforms to Agile development, we’re faced with yet another challenge for developing our Mainframe technologies and legacy systems. From tackling the challenges of employee engagement to the problems of fitting procedural/linear technologies into the fluid world of Agile, successfully navigating these issues will allow IT leaders to breathe new life into the development of aging technologies. In this session, Jay McFarling and Danielle Roecker will share their experiences over the past two years of successfully moving the waterfall development activities around a Mainframe legacy system into the new world of Agile. This interactive session will provide both a glimpse into the “Top 5″ blockers they faced and a facilitated venue to explore the top challenges faced by session participants.
Automated Acceptance Tests on Agile Projects
Wyn Van Devanter
(Code and Tests)
It’s no secret that automated tests are a key part of Agile projects.
Once you start digging deeper into what is required for a complete test
suite however, you realize the types of tests you need gets complicated.
Integration and acceptance tests come up frequently, as does the
complexity in automating them. What parts of your application require
what kind of
tests? To make things just a little harder, automated acceptance tests
(AATs) are riddled with controversy, as they can be expensive to build
and maintain if not approached carefully. Some have even said they
aren’t worth the time. Many more say they are though, and there are many
examples of successful projects that
gained quite a lot from automated acceptance tests in a carefully planned
This talk will review the current landscape
of automated acceptance tests. It will talk about why more projects
don’t use them, and how to get over those issues. Attendees should walk
away with an understanding of the AAT landscape, how they generally work,
how to approach them from a journey perspective, and how to get benefits
from them while avoiding brittle tests and maintenance nightmares.
The Agile Dashboard
(Improving Your Game)
There are more to Agile metrics than velocity and sprint burn-down charts. However, most Agile teams focus on velocity and target story points which leads to executives misusing the metric and teams gaming the system. There are other metrics that can provide a more holistic view of the project_s overall health. The Agile Dashboard collects such metrics and acts as an information radiator giving us real time project updates on value, performance, schedule, scope, cost, quality, and team spirit. Come learn what to measure and for how long. Learn how to read warning signs and what corrective actions to take. Learn to setup your own Agile dashboard to arm yourself with the right information and make careful and constant adjustments to ensure forward and safe progress towards your final deliverable.
Session 2 11:30 — 12:30
A Year in the Life – Trials and Tribulations of Implementing Agile in a Federal Government Matrixed Environment
The session will address the challenges faced in the first
year of implementing Agile in a highly matrixed federal government
environment. As a small 8A business without a history of agile software
development, our company, Tantus Technologies, Inc. was tasked with
helping our client at the Federal Aviation Administration (FAA) continue
its evolution by piloting then formalizing Agile software development
into a matrixed environment that includes over 100+ federal and
contractor personnel historically implementing between 50-70 projects
each fiscal year. The session will summarize some of our challenges in
the first year along with a focus on the specific constraints we have
encountered in a matrixed environment. The key points we would like to
highlight relative to having “dedicated” vs “matrixed” team members
The impact of context switching on productivity.
The improved team communications experienced with dedicated teams.
The decrease in reliability of velocity data for matrixed teams.
Test-Driven Database Development: More than “Just Do It”
(Code & Test)
Max Guernsey takes you on a whirlwind tour of everything you need to not only drive database development from tests, but to make your database “just another module”. You will get an introduction to a system of techniques that make developing database designs just as consistent, pain-free, and risk-controlled as developing a .Net assembly or a jar file.
Attendees will learn the following:
* How long-lived data, the true difference between database development and “regular” development, impedes fast development cycles.
* How slow development cycles actually put data at risk. How test-driven development overcomes the risks inherent in fast development cycles.
* How to create a predictable database build process and how to drive errors from it.
* How to protect value by ensuring downstream systems are using a database correctly.
The Culture Engine: Exploring the Social Side of Software Development to Accelerate Team Performance
We aspire to make great software. But too often we come up short.
After years of experiencing our own failures and successes and studying those of others, we have come to believe that making great software depends less on tools and techniques, and more on working together effectively to solve difficult problems.
How well we work together is governed by the agreements we make and the quality of the relationships we form as a result of how we manage those agreements. All too often, however, we manage agreements poorly. We break our agreements, and when we do, we fail to confront and renegotiate them quickly and effectively.
When these things happen, the trust we share in ourselves and in our colleagues erodes, and we unintentionally reinforce a culture that reduces our ability to solve the problems we face every day.
The best teams and organizations—those that achieve the highest performance and take the greatest joy in their work—have a discipline around “how we work together”. We see this discipline as the agreements they make and the workplace culture that results from making and managing agreements well.
Agreements, well made and well managed, are the engine of culture change. This culture engine, when properly maintained and fueled, creates an environment that amplifies the power of the tools and techniques we use and supports the extraordinary collaboration that is required to achieve extraordinary results.
By mastering agreements, we realize the full potential of ourselves and of our teams to solve the wonderful and terrible problems we encounter when we aspire to make great software.
Five Years of Agile Failures (or what NOT to do when becoming Agile)
“Everybody is always asking me “What data do you have on success vs. failures of Agile”. I usually tell them they are asking the wrong question. It is the wrong question because Agile is always successful and failing at the same time… simultaneously. Of course this is usually when I get the blank stare. I’m trying to be trite, but I’m coming off that way. So… like a good Agile coach I try to reframe the topic in a different light in order for the person to see success and failure through a different lens. I ask them the simple (but terribly loaded) question, “How do you define Success?””
I would like to propose the following topic: Lessons Learned From Five Years of Agile Failures (or What NOT to do when becoming Agile).
First I will cover how I define Success in becoming Agile. Then I will discuss the three most common failures I’ve experienced in coaching for the past five years. In discussing each failure I will also cover how to avoid these failures using pragmatic but often hard preventative steps.
The three most common failures I’ve experienced are:
- “Immeasurable Agility” or clinging to mostly useless metrics while refusing to adopt the metrics that tells you if you are going to deliver a product on time and on budget that meets or exceeds expectations and quality levels
- “Oh that’s outside our control” or not having the correct sponsorship, champions and support structures in place to successfully become Agile
- “I shall redefine Agile in my own image” or redefining success in order to claim success while covering up all of the things wrong with the organization ergo Leadership.
Creating Sprint Reviews that Attract, Engage, and Enlighten your Customers
(Business Point of View)
Are you suffering from organizational disinterest in what your agile teams are delivering? Are your Product Owners unavailable or distracted? Does everyone question the value and flow of what your teams are working on? Are your sprint reviews a ho-hum experience with varying and low attendance?
If you answered yes to any of the above, your agile teams are in trouble and you need to attend this session.
Join experienced agile coach Bob Galen to explore real-world patterns for how to increase the interest, energy, and value of your Sprint Reviews. First we_ll explain the importance of proper preparation, keys to dry runs, and role of a Master of Ceremonies. Then we_ll look at ways to orchestrate reviews to include the whole team and engage your audience, while always demonstrating _working software_. Next up is how to perform effective review follow-up gathering feedback towards high-impact improvements.
Finally, we_ll wrap-up the session by exploring how to make your reviews a centerpiece of your agile adoption and cross-organizational transformation.
An Agile Approach for BAU / Maintenance Projects in a Regulated Environment
Whether providing dedicated production support or dividing time between new development and maintenance, a framework for managing business as usual (BAU) / maintenance projects is required to insure Teams can balance competing mandates from stakeholders across the portfolio as well as the technical enterprise. This session will propose agile strategies for managing an Enhancement Backlog, System Support Backlog and Defect Backlog either independently, or as a single prioritized consolidated pipeline. Several Agile BAU Frameworks used successfully in the finacial service industry will be presented; thereafter, attendees will broken into working groups to discuss / “white board” their BAU framework and team members will work collaboratively to optimize with coaching support from meeting leaders.
Beyond Requirements Dictator: How Agile Helped A Business Analyst Discover Her Real Value
This is my personal journey of discovering how to provide value as a business analyst on an agile team. I will share some things that smoothed my path and some obstacles that slowed me down.
And for the many BAs struggling with how they fit into this new world, I will also redefine the role of a business analyst as more than a requirements dictator. In closing, I will illustrate how BAs, as well as the rest of the team, can reap the benefits of broadening their roles and stepping outside of their role boundaries.
Agile Edge Cases: Startups, Data Warehousing, and Functional Programming
The typical Agile project involves using an object-oriented language to create or maintain a system for a business end-user. But what happens to the Agile practices when you’re a startup, without a clear user? How about if you’re in the data warehouse, where everybody is simultaneously your user? Or perhaps you’re writing purely functional code? These three edge cases are related. Find out how, and how that relationship can rock out your own team.
Building Software Craftsmen
(Improving Your Game)
There has been a lot of talk lately about Software Craftsmanship. Most of this talk has been centered around how to take existing, skilled programmers and turn them into Craftsmen. What about those who are just entering the field? In this talk, we will explore a new approach to fulfilling the entire journey from Apprentice to Master, both from a personal and organizational level. We will also look at how to get such a program started, and how to bring the existing team along.
Session 3 1:45 — 2:15
Confessions of a New ScrumMaster
This session details some of the struggles many new ScrumMasters face after they become certified and start practicing with a team. I will provide real life examples of some of the situations I’ve encountered and how I learned to deal with them and help new ScrumMasters and experienced ones alike continue improving their skills.
Agile for things other than Software
Compare and Contrast two different attempts to use Agile principles and methodologies for running a business. Attempt one used something very scrumish and Attempt two use something very kanbanish. Take a look at what worked and what did not and the effects of culture and work style on level of adoption.
Self-management and Self-organization: Agile Games with Motion
(Improving Your Game)
Self-management and self-organization are important themes in Agile software development, but what do they actually look like? We pontificate about worker empowerment, but then we revert to command-and-control: our product owners mandate project scope and deadlines, and our Scrum Masters assign tasks to team members. Why can_t we let teams be self-organized and workers be self-managed?
These activity-based learning activities are kinesthetic learning games. Players learn by playing fun, physical games of movement. These games create a social atmosphere and a full body and mind experience that make it easy and fun to learn. We_ll play five games, including Line Up, 60 Paces, Triangles, Human Knot, and a special surprise game.
In this session, we explore and experience self-management and self-organization via Agile games. You will leave with a deep internalized understanding of self-management and self-organization and an appreciation of how they work better than command-and-control. You_ll be able to share these games with your coworkers.
Making Improvement Standard: Making Agile Practices Dynamic through Lean Standard Work
(Improving Your Game)
Continuous improvement and adaptation is practically the definition of agility, but teams have to start somewhere. This session will explore how common tools like agile practice self-assessments have been combined with lean “standard work” practices to provide early agile teams with focused guidance, while encouraging them to raise their own standards as they mature and learn.
We will describe a framework for management and coaching roles involved in driving and supporting agile development efforts, based upon our experiences in both small companies and large enterprises at various stages of adoption.
Experience Report: Converting A Successful FBI Program From Waterfall To Agile
We have heard the reports of unsuccessful programs “rebooted” and rescued through the use of agile software development models. And there is a wealth of information available on how to institute agile practices such as test automation and refactoring into greenfield projects. But what about a highly successful, longstanding, waterfall-based government program with 2 million lines of code? This is an up-to-the-minute account of our (continuing) experiences instituting agile practices, paying down technical debt, and addressing the concerns of skeptical governance and oversight groups.
The Right Stuff
A group of strangers is assembled for a daunting task: create and ship a new product within 36 hours. From the outset our team faces set backs. Racing against the clock and working on minimal sleep, they must overcome obstacles, course correct, and move to ship a quality product on time.
This a true story recounting the speaker’s experience as the member of an ensemble team working on creating: a short film. A case study on what makes a great team, and how to apply this in software.
New Beginnings: Agile in the Equity Capital Industry
In 2012 the information technology group at The Carlyle Group (TCG) decided to embrace Agile after a number of false starts. TCG and the David Consulting Group decided on an immersive approach to implementing Agile rather than a train them and they will come approach. The presentation will deliver a collection of lessons learned that include why engaging the business and product owners is important, why just-in-time is effective, when lean techniques such as Kanban need to be blended with more classic agile techniques and how TCG integrated Agile into corporate governance processes.
The presentation will provide context for the how Agile was embraced at The Carlyle Group and where they are today. Attendees will learn why the lessons that the TCG learned can be generalized for other organizations to leverage.
How to Implement Zero-Debt Continuous Inspection Architecture in an Agile Manner
(Code and Tests)
This presentation describes an extract, transform, and load of key commit and code-quality data from the build system to a code-quality database. It will cover how the database was used to transform two large project teams by baking quality into the build process in an Agile manner.
Many talk about technical debt in abstract terms. This presentation defines it in terms of actual code metrics and how they can be measured and tracked in an Agile manner. It will explain important details about the three groups of debt_static analysis, testing coverage, and class metrics.
How much unit test coverage is enough? Management often sets a standard of 80%, assuming the 80/20 rule is the most cost-effective. However, which 20% should go untested? This presentation asserts that 100% is an attainable goal and will detail how 100% coverage was attained as part of normal maintenance. Development culture changes when the standard becomes 100%.
Debt is incurred under various pressures and is paid back later. This is especially true with coverage and metrics debt. Tracking debt is essential to making it visible and enabling its reduction later. Tracking techniques are explained. The role of reviewers and code-quality automation is explored.
Techniques for tracking the error rate of actual commits are explained. Outstanding technical debt management reports are presented and explained along with their relationship to a trouble-ticket system.
A four-year case study of a 12,000 class, 2 million-line Java system with 25,000 commits of 250,000 program changes by 175 developers will be used. Unit tests increased nine-fold to 36,000, raising the branch/line coverage from 27% to 82%. A total of 5,500 technical debt items in 10 debt categories were identified, tracked, and resolved. A similarly sized C# system will also be used along with two different version-control and build systems.
The role of designing and writing testable code is explored. Architecture decisions can enable higher testability. For example, functional programming enables already tested code structures to be employed.
You’ll come away with ideas you can apply immediately as well as a longer-term blueprint for an architecture and process to attain zero technical debt in your organization.
The Benefits of Dedicated Teams: How Agile is Changing the Structure of Service Organizations
(Business Point of View)
Based on the research conducted over the course of four years, Dr. Berry will discuss how Agile development methodologies are forcing companies to confront the failures of a highly matrixed organization. The popularity of Agile methodologies is forcing leaders to rethink their organizational structure and return to dedicated teams to ensure that projects meet the high levels of service expected by clients today.
Session 4 2:30 — 3:30
Quality is a Team Sport
Who is responsible for testing on agile teams? The answer is _Everybody__and yet this is rarely the case. Often the testers write their test cases in isolation and execute them after development is finished. Developers write their code without talking to the testers except to understand how to reproduce the latest discovered defect. Product owners elaborate requirements in isolation and then hand them off to the team only to check back at the end of the sprint. Business analysts spend their time working on documents that have questionable usefulness. Join Cheezy as he paints a different picture. With the help of volunteers from the audience performing skits, Cheezy demonstrates practices that not only foster collaboration among all team members but also dramatically improve quality. These practices help teams achieve a better flow resulting in a more streamlined development effort. This new picture is a picture of teamwork and quality assurance.
Getting Blood From a Turnip, the Art of Facilitation Made Fun and Effective
(Improving Your Game)
Have you ever been asked to pull together the team to discuss a new capability or an existing problem and found that either you only hear crickets when you ask for ideas? Or, only two of the ten people in the room actually participate? Or, worse yet, you are the one doing all the talking?
Well, there are some great facilitation techniques (a.k.a. games) that are geared towards getting teams to open up and work together to create a shared vision, express their great ideas, and provide constructive opinions which in the end help make better products and hopefully, happy customers and end-users.
In this workshop, we_ll play some facilitation techniques (a.k.a. games) and discuss the steps to leverage them in your organization to both make you a better group facilitator, but also help make better products.
NOTE: We call these facilitation techniques instead of games because some places just can_t grasp the idea of having fun _ we_ll show that games can be used for work.
Initiating Your Agile Project
(Business Point of View)
What happens when we need to start a project? Whether it is a customer struggling to articulate a problem set in the form of a Vision statement or a responding company bidding on a proposal, we struggle with this step particularly using Lean and Agile concepts. In this session, we will explore different techniques and practices on how to initiate a project using Agile best practices. We will demonstrate how to write a Vision statement, Roadmap as well as estimating techniques that use traditional Agile principles. In the end, you will know how to write an Agile proposal as well as how to scope and estimate one for your next proposal.
Distributed Scrum Management – Sharing of Practical Experience and War Stories
(Improving Your Game)
Distributed development (Distributed Scrum for us) is not a new notion, but rather, a frightening one. Whether the team is off-shore, in another state, or even in another building, Distributed development presents a challenge.
Challenges are presenting themselves in many, sometimes surprising ways, through different cultures (sometimes even within the same company, not to mention when working with a truly different culture), language, _intentions_ (when _done_ is _really done_, or even _really really done_) and goals.
We strongly believe that Scrum is one of the techniques that allows for bridging the gaps caused by choosing a Distributed Development model. In our talk we would like to share our experience, insights and anecdotes but also have an open discussion with the participants to gain their thoughts, insights ideas and experience, thus, push our collective experience one notch further.
Integrating User Experience into an Agile Environment.
Each panelist will describe a case study example of how they successfully (mostly) have created and/or participated in a development environment where UX has been integrated within an Agile methodology. Their discussions will begin with an overview of the different work environments for each of the case studies in which the different methodologies are implemented. Panel members will also examine pros and cons of each method, the challenges encountered with each and solutions they’ve implemented or are considering.
Each of the case studies will provide audience members a cross-section of different experiences allowing them to determine how they might create a more optimized UX/Agile solution within their own work environments.
Potential topics that panel members will address include:
– How has each panel member integrated user research?
– Was user research conducted during the months ahead up to Sprint 0?
– What were the goals of the user research?
– How are UX teams involved in the day-to-day Sprint activities? In Scrums?
– What have been the tradeoffs of each UX methodology included? Have some tradeoffs introduced too much risk?
– What factors were considered when designing a process to fit the work environment?
– What methods were used to communicate the design?
Time will be allowed for audience participation so that attendees can share their own experiences as well as ask panelists questions.
Comparing Scaled Agile Approaches: Scaled Agile Framework (SAFe) and Disciplined Agile Delivery (DAD)
Building upon well established Scrum, XP, and lean software development methods, agile scaling frameworks such as Dean Leffingwell’s Scaled Agile Framework (SAFe) and Scott Ambler’s Disciplined Agile Delivery (DAD) address large, complex software delivery initiatives through their full delivery lifecycle from project initiation to production. These frameworks have received significant interest in both federal government and private industries, recognizing the need for continued team-based iterative and incremental adaptive approaches to software development, balanced with scaling processes and factors at the Program and Portfolio levels and organizational governance models and guidance for large enterprise engagements. This session will provide a brief overview of these two agile scaling models, address the benefits of what both are trying to accomplish, and compare and contrast specific similarities and differences.
Recognizing and Counteracting Oppression
Every day, across a wide variety of software and IT organizations, people are being oppressed. At this point, the oppression has become so systemic, so ingrained, and so accepted as “business as usual” or “the culture around here” that it is effectively invisible. In the software industry we casually talk about “death marches” and how people that give up their vacations, weekends, and special events at their kid’s schools are “real team players.” We routinely set ridiculous deadlines that nobody believes in to “motivate” people into “giving it their all.” And for what? Is a little extra bonus money worth the broken relationships, lost time with your children, high stress, guilt, unhappiness, and impact on health?
Unfortunately, one of the reasons that Agile adoptions fail is that implementing the principles and values of the Agile Manifesto requires breaking the deeply ingrained habits of oppression. It is time to do more than just offer the solution of Agile development, it is time bring the subject to light and provide ways to counteract oppressive behavior.
Who is to blame? Is it a certain personality type or role? No. The root cause is not a person, it is the practices and organizational structures of traditional development itself. It is the system, not the people. Truly addressing the problem means changing the practices and organizational structures to support a healthy work environment. But the path to change starts with awareness and coping mechanisms.
In this session, participants will share their stories, learn ways to peacefully and constructively counteract oppressive behaviors, and come up with new ways to counteract oppression.
Five Refactorings You’re Not Using Enough
(Code & Test)
You know what refactoring is, maybe you’ve even read the book, but how
do you know which ones to use? How do you spot opportunities for
refactoring? And what refactorings should be in your everyday kit?
Here is a fistful of refactorings, some familiar and some obscure —
but all of them underused by typical teams, who could make great
strides in internal quality simply by knowing what they are and when
to use them.
Agile Acquisition Practices
Using agile within the Federal Governments Acquisition Framework is complicated. The organization must be ready, the team must understand how to maneuver within the perceived structured environment, what is flexible and what isn’t. Session contains specific Techniques with case study information on how to be more successful using Agile in project, writing contracts and executing them. Includes issues, recommended solutions, examples from Federal Acquisition contracts, acquisition lifecycle framework and IPTs. previously vetted at ALN, BBB 2.0. Video taped
Agile and Federal Governance – A Look at Contracts and EVM
With the increasing federal interest in agile, are Federal governance controls ready for Agile implementations? This session explores dealing with Federal contracts and EVM when implementing Agile on Federal programs.
Session 5 4:00 — 5:00
Okay So The CIO Said We Are Agile — What Should I Be Doing? 4 Topics A New Agile Manager Needs to Consider
This is a session intended for business or project managers who are new to Agile and who are responsible for the human resource and professional development aspects of Agile project participants. These individuals are often in a difficult spot as they can be asked to evaluate and develop Agile team members using their organization’s traditional (and perhaps Non-Agile) metrics and approaches.
Starting up and growing Agile within a company can have unintended consequences — not the least of which is the inadvertent creation of teams who perform work and interact in ways that are not always consistent with traditional management cultures. Moreover you may risk creating professional career cul-de-sacs for Agile personnel if the organization’s rewards structure is not in tune with Agile methods.
With this in mind this presentation will focus on the following four topics as they relate to Agile team members. We will touch on current thinking on each and offer some thinking from others who have encountered the same issues.
• Responsibilities and Roles
• Career Paths
• Training, Education, and Community Involvement
Overcoming Problems Implementing Cloud-Base DevOps for Distributed Agile Projects
Cloud-base development, delivery and deployment are the future of IT operations. Getting to the Cloud and conducting the business of IT there is a journey of change and growth to an IT Organization. Discover potential problems and their solutions based the experiences in developing Cloud-Based operations for multiple large, distributed projects in a variety of challenging environments. Overcoming these challenges is the key to successful adoption of Cloud DevOps and realizing the operational and productivity gains of the Cloud. Learn the hard earned lessons we learned from creating successful DevOps projects using Cloud Technology.
Get What you Need, Not What you Ask For, An Intro to ATDD/BDD and
(Business Point of View)
Do you want to learn the basics of ATDD/BDD so that you can ensure clear
communications between business and development?
Do you want to go beyond building to a specification, and build what is
If so, come to this session.
Agile teams often relied on user stories and acceptance criteria alone.
Then more advanced teams started doing TDD (Test Driven Development) so
that developers could build what they thought the business asked for. When
it became clear that TDD was not enough, ATDD (Acceptance Test Driven
Development) / BDD (Behaviour Test Driven Development) became popular, as
they provide a common language for business and development.
But building what the business wanted is not enough!
With HDD (Hypothesis Driven Development), we can test our business case,
just like we test our code. When we find that results don’t match our
expectation, we adjust our business case to get better business results.
In this hands on workshop, we will create several examples in ATDD/BDD and
then extend out to the business case level with HDD.
High Maturity Operations with Kanban
(Improving Your Game)
These days, everyone is keen on lean and agile and some outfits are even realizing some limitations when desiring robustness, scalability, and growth. Many organizations struggle to make meaningful inroads towards realizing the combined benefits of lean/agile and robustness. Traditional approaches towards CMMI make using agile approaches awkward, and, agile approaches make their traditional approaches to CMMI awkward. This is even more pronounced in “high maturity” CMMI.
“High Maturity” CMMI (Maturity Level 4 or 5) is often seen as “out of reach”. If, for no other reason, than the perceived (and oft-reported) time and expense of establishing and maintaining the necessary processes. Even for those who fully internalize the benefits of having high-confidence and predictable performance — the anticipated benefits of CMMI high maturity — the prospect of the ginormous amount of work necessary to get there is daunting enough to not even try.
As it turns out, ML4/5 can be *much simpler* than what most people experience. With simple data, no fancy models, and no statistical geniuses, what’s required for an ML4/5 appraisal and the performance benefits can be had for any business, small or large, doing any kind of development or service work using practices commonly found in lean, agile, and in particular, Kanban.
ABUSER STORIES: Thinking Like the Bad Guy to Reduce Security Vulnerabilities
Abuser stories is a way to capture potential vulnerabilities in software systems, using the standard user story format. While user stories are written from a user perspective, abuser stories are written from an enemy or attacker_s perspective and describe the enemy_s mal-intent and motivation.
The session will look at the concept of Abuser Stories more in-depth. We will examine:
How seemingly benign functional user stories can create vulnerabilities in our software, leaving lots of opportunity for our enemies to take advantage of our weaknesses.
How to use the concept of abuser stories to shed some light on where these vulnerabilities can be introduced.
How to craft a good abuser story.
How to craft refutation criteria so that we can determine that the attack depicted by the abuser story is not possible.
How to estimate and rank abuser stories.
Taking Flight: From Agile Aspriration to Transformational Action
I’ve been implementing a combination of many concepts into a transformation model that can work for a large organization, starting by helping the organization take ownership of what Agile means to them (personalizing it). This has been performed within the Federal space at varying levels and currently is being used to transform a large Agency.
I’ll present the differences between an Aspirational Model and an End-State Model and why an Aspirational Model is a better fit for Agile Transformations. From there, I’ll discuss different techniques for developing an Aspirational model and how to assess the current state of the organization and its people, and develop strategies and actions for the necessary change management to move towards the organizational Aspiration. The talk will discuss understanding progress and the conceptual change-in-progress limits that we must think of… and how to help the organization become more responsive to change. We’ll close with how to create feedback loops on progress for this change management.
Is it still agile if software development is absent?
Implementing agile in a development group that has nothing to do with software development is still a little unique. Global Knowledge Learning and Performance Solutions department has done just that and we_ll share our experiences and challenges. We_ll divide the session between the strategic and tactical aspects of why and how we implemented agile practices, starting with who we are, our business challenge and why we thought agile might be the answer to meeting the specific drivers of that challenge.
We_ll talk about the key activities for getting started based on our current state and future desired state, asking audience members for input on what they have experienced as they begin agile practices. Transitioning into the more tactical side of our implementation, we will describe our version of agile that we settled on after training and consulting assistance. This version of agile practices produces both classic and unique challenges that we_ll share and discuss with the audience. We_ll describe our outcome to date, and share our early and our enduring successes. The unexpected occurred here as always, and we continue to have challenges within our department and the organization. A description of how we manage those and continually improve in an often nebulous future state will wrap up the session.
Testing Inside Your Timebox on Federal Agile Projects
The thesis of our session will be understanding ways to complete all required testing inside your timebox without extending your iteration, requiring a hardening sprint/release iteration, or accepting low-quality: We will present the various tests required on projects within the Federal government and, depending on your organization and the applications you are building, there are many (Unit, Integration, Functional/Acceptance, Smoke/Exploratory, Independent/IV&V, Regression, User acceptance, Usability/Section 508, Performance/Load, Security/Vulnerability, etc.). There are many challenges with performing proper Agile testing in the Federal space. We will present challenges brought to bear by the nature of Federal programs and identify factors that could undermine your ability to complete all testing within your Sprint. Finally, we will present solutions to the proposed challenges with suggestions that can be enacted in the near-term and long-term.
Behavior Driven Development with Cucumber-JVM
(Code and Tests)
Behavior Driven Development (BDD) drives development of features using the Red-Green-Refactor cycle of TDD. In this workshop you’ll pop open your IDE and we’ll build the beginning portions of a service layer of an airport parking cost calculator. We’ll use Cucumber-JVM and the Gherkin language to define our acceptance criteria in the business domain language (DSL). We’ll then use the Gherkin feature files to drive the development of the feature for the “outside in.” While this session is using the Java based tool Cucumber-JVM, .NET developers can follow along with Specflow a C# based tool. Please go to http://www.youtube.com/watch?v=aPDMDufkBSc and follow the Cucumber-JVM setup video so we can get right to the code!