Software development is hard.  For all our talk about “sprints,” anyone who has been involved in a major software development effort will agree it is more of a marathon.  Well, if we have to run a marathon, wouldn’t it be nice to start on mile marker 2?  Some inline skates would be nice, as well! 

In this talk we will describe a new technique for jump-starting application development, with software seeds and generators.  

A seed project pre-integrates a set of technologies, with a minimal working set of services and screens, a set of example automated tests and a fully tricked-out DevOps pipeline.    Like an erector set (or a Raspberry Pi Maker Kit—to use a more up-to-date analogy), a seed is designed to be used for building larger projects.

A generator can be used to generate a new project (by customizing seed templates, for example), and, later on, to generate new software components from blueprints as they are needed.  Like a casting mold for molten metal, a generator helps ensure new components follow naming, testing, and design conventions.

A properly configured set of seed and generator projects can provide a number of important benefits:

• new project team members can explore and learn using a project small-enough to get their arms around.
• New insights, components, and design patterns can be quickly promulgated and shared within and across organizations

Of course, all this does not come for free.  Seeds and generators must be regularly maintained, and they require senior expertise to build and maintain them.  However, even a junior team can derive benefit from downloading a pre-existing example from one of the many online sources such as yeoman.io. 

In this talk we will explore the process for building and maintaining seeds and generators using a case study of three seed projects developed for a NYC municipal agency using Ruby on Rails, Microsoft C# .NET Core, and AngularJS 4, technologies.  We will talk about the lessons learned, commonalities and differences between technology stacks and what it takes to maintain the seeds and generators long-term.   We will also talk about our experiences using the seeds and generators to build production applications and helping other groups to do the same.  We will discuss the issue of achieving buy-in, even from development groups that did not participate in the initial seed development.    Finally, we will explore next steps and speculate on where the next major leaps in software development productivity may come from.

NOTE: This talk can be delivered at the intermediate or advanced level, depending on the audience

A deeper insight in how and why agile works is the pre-requisite for business agility and the agile organization. Flow thinking has proven to be foundational. But the concept of flow is not an easy concept to master for people that have not experienced it. Rational explanations of flow only go so far. Without intuitive understanding based on experience it may not be easy to mobilize a team or organization into action.  By visualizing work, reducing multi-tasking, and removing obstacles, lead times may be drastically reduced leading to better outcomes.

Introducing the Okaloa Flowlab board game-- an exciting new approach to learning how to think about flow through practice and simulation.  With Okaloa Flowlab we will perform a series of experiments through board-play style simulations that reflect real work environments.  This session provides a quick introduction into what is typically a three-hour interactive class.  In order to fit into the 45-minute timeframe, we will provide a “before” vs “after” game play rather than introducing agile policies incrementally, but the end result will be the same.

We first simulate a conventional work environment that reflects a “mechanistic” mindset characterized by a focus on resource efficiency, command and control, and specialist workers, so that participants will viscerally experience which roadblocks need to be overcome.  We will then implement a number of agile policies and practices (including pull of work, peer collaboration and limiting the amount of work in process) and observe the results.

This learning session enables attendees to experience first-hand the effect of adopting agile processes in a safe-to-fail simulated environment. 

Each team consists of 3-5 people seated around a table with the board (ideally 4 people and 1 person taking up the role of project coordinator).

Participants will discover the power of visualization, limiting work in process and collaboration, and understand the fundamental difference between resource efficiency and flow efficiency.

Come check out this exciting and innovative new way to learn about agility!

You are adopting Agile practices throughout your organization, and you set up a shiny new set of tools to support it.  All of your teams have captured their backlog and are running their Sprints (Scrum) or continuous-flow (Kanban) process.  Great!  There is only one problem.  How can management see at a glance what is going on in each effort?

• How do we know if each effort is “on track” or headed for disaster?
• How do we know when we have capacity to take on new initiatives?
• If a new high priority/urgent initiative is proposed, how can we quickly see if it would impact other efforts at the same or higher business priority?
• If a new high priority/urgent initiative must be undertaken, how can we quickly analyze resources and schedules for what is happening currently, so we can do an impact analysis?
• How can we avoid getting bogged down in the day-to-day minutiae of user stories, story points, and bugs and quickly identify important blockers, major risks, or emerging trends that could have ripple effects?

Through a case study involving a $1B municipal government agency, we will describe the process of configuring a set of tools to feed a one-page dashboard displaying current and proposed initiatives – enabling management decision-making.  The tools include Atlassian JIRA, BitBucket, Bamboo, and LeanKit, but the lessons may be applied to other similar toolchains.   We analyze both the technical work involved, as well as the important process and cultural changes we had to make in order for this to happen.   All changes automatically roll up from the team level to the portfolio level, so that progress, blockages, and risks are always visible.   Senior management can drill down to get details if needed.

Perhaps “Agile PMO” is not an oxymoron, after all.

Behavior Driven Development / Acceptance Test Driven Development (BDD/ATDD) is a new, exciting approach to developing software that has been shown to reduce rework and increase customer satisfaction. While other testing tools focus primarily on “are we building the thing right?”, BDD tools such as Cucumber and SpecFlow attack the problem of software directly at its source: “are we building the right thing?” By retaining all the benefits of automated unit testing, while extending them upstream to cover requirements, we cut the Gordian knot of risk and complexity to unleash hyper-productivity. 

Why is BDD so effective?

• As a form of Test driven design, BDD helps produce frugal, effective and testable software.
• As a development tool, BDD frameworks like SpecFlow provide many convenience functions and are pre-integrated with powerful libraries like Nunit and selenium to make writing tests a snap.
• As a collaboration tool, BDD helps ensure the “three amigos” (tester, analyst and developer) sync up – ahead of time.
• As a facilitation technique, BDD enables product owners to efficiently provide the team with concrete examples that clarify the true intent of a user story and define the boundaries.
• As a reporting tool, BDD captures functional coverage, mapping features to their acceptance criteria to their test results, in an attractive hierarchical presentation.

Want functional documentation? How about documentation that is guaranteed to be correct, because every feature maps to its test results? Witness the holy grail of traceability – executable specifications.

We will spend a few minutes talking about the context and pre-requisites, so attendees have an idea of where BDD fits in, and what type of investment they are signing their teams up for. We will see that in return for a modest amount of investment in tools and training, very significant benefits can be realized, and the benefits compound over time.

This workshop then dives right in to Gherkin, the structured English language technique used to capture BDD specifications. We will spend the better part of the session learning the tricks and techniques that make for robust and maintainable gherkin specifications. We will review and critique lots of examples, both good and bad.

We will review several examples of reports generated from BDD tools, to provide context and to immediately highlight the bottom line business value that makes an investment in BDD so worthwhile.

Come and learn why Behavior driven design is taking the software world by storm!

At a Federal Agency or a large commercial company you may get a chance to work on a major program that makes a real difference in people’s lives.   But the (legacy) software behind such programs is often large and complex, and therein lie some challenges.  Here are some of the challenges we faced on a major 15+ year old legacy system comprised of 2M lines of source code:

• maintenance costs were escalating
• It seemed like every time an issue was fixed, it caused two more
• Lengthy delays between major software releases
• New releases suffered from high priority bugs that had to be hot-fixed immediately
• The software was taking longer and longer to be fully tested; in fact, it became practically impossible to test every feature.

When looking to implement agile practices on a legacy program, it is hard to know where to begin.  Innovative Silicon Valley companies like Etsy leverage DevOps and Continuous Delivery practices to achieve new levels of automation and agility, shrinking development lead times and deploying to production many times each day.  However, it can be a struggle to implement these practices for legacy systems that run our core businesses.  To make matters worse, the agile community offers relatively little practical guidance for implementing DevOps practices in legacy environments.  Fortunately, the Kanban Method provides a practical way to gradually evolve these core systems towards achieving DevOps cost savings and efficiencies, even if you don’t have a massive budget.

Through a case study involving a criminal justice system for a US government agency, we will examine how the Kanban method helped us identify and remove the barriers that prevented us from implementing DevOps automation for legacy systems.  Just as importantly, Kanban provided the means to measure the efficacy of our efforts, prompting us to course-correct when necessary. We will review some interesting examples using the Microsoft technology stack, but these lessons apply equally to Java, LAMP, MEAN, or any other set of technologies.  The end result was better quality and collaboration and faster delivery of value to our stakeholders.  Perhaps it is possible to teach an old dog new tricks, after all.

Agile software development methods are now well established in many commercial organizations, and are starting to make inroads into government contexts. There are reports of software development projects using Agile methods that achieve significantly higher levels of productivity and quality compared with projects that used traditional methods. When it comes to brand new “start from scratch” software projects, a wealth of information, advice, training, and literature exists to help guide practitioners and speed them along the path to agility. Unfortunately, most such publicly available resources have relatively little to say when it comes to legacy systems. However, there is a small but growing amount of evidence that agile practices can yield compelling benefits for legacy projects—even those that have been previously successful using traditional methods. Our experience suggests that agile practices need to be customized and introduced in a different order into a legacy project. This presentation provides an analysis of the differences between legacy projects and new software development and the implications for the adoption of agile methods.

Many Federal government agencies are implementing Agile methods in addition to or in lieu of traditional waterfall lifecycle models.  However, comprehensive documentation is often still required by Federal IT governance, legal, regulatory, or statutory frameworks, or to meet outside audit or “watchdog “ requirements.   The Agile Manifesto values “working software over comprehensive documentation,” but that does not mean that Agile teams cannot or should not produce valuable documentation.  Although there are some well-publicized Agile success stories in the federal space, some agile federal projects are receiving criticism for failing to meet applicable standards when it comes to documentation deliverables.  With Agile’s emphasis on small, lean teams and intensive technical practices such as pair programming, meeting documentation requirements set forth by Federal IT governance poses challenges for Agile teams in the Federal space.  This session will review the documentation that is typically required in a heavily regulated environment, and discuss specific techniques for reducing, replacing, generating, or “slimming” the document deliverables.  Specific tools, techniques and best practices will be reviewed and analyzed with “before” and “after” snapshots and a look at cost versus benefit.    Documentation generation is an area of intensive activity with some very exciting new developments that can change the game significantly for the better!  Tune in to share insights and discuss strategies for breaking down one of the last big barriers to significant agile adoption in the federal space.

Using tools like TDD and ATDD, Agile provides the means to be confident that your brand new software is well tested-- even for life critical situations such as criminal justice software.  But hold on a minute!  It is a rare mission critical system that is built completely from scratch.  There are always legacy components your team didn't build or doesn't control.  Maybe the previous contractor built it-- but now they are gone and it is your problem.  How can you be certain that everything functions properly in such a situation?  How much testing is enough?  How can you know whether a system has been tested?  These are the questions that standards such as CMMI and PMBOK seek to answer with traceability.

The debate about traceability has been raging for a long time, with passionate advocates on both sides of the argument.   Projects following traditional waterfall methods, and projects that conform to PMBOK or CMMI standards often create and maintain a requirements traceability matrix, or RTM, a document that traces “shall” requirements to functional capabilities and testcases.  Some Agilists argue that the RTM is rarely consulted in practice, so the significant efforts required to maintain such a document are “waste.”  Others point out that agile practices such as TDD provide all the traceability that may be needed. This talk will explore the underlying reasons why traceability may be important and worthwhile in many Federal government contexts, and review exciting new technologies that may provide an “agile answer” to this conundrum.