Hello friends! We are so excited to launch our public 2-day Behavior Driven Development workshop for Agile teams in the first week of December 2015. For this workshop, we chose the Aloft Hotel in Broomfield, Colorado—it’s a convenient location for those either traveling from Denver or Boulder.

In the 2-day course, you will learn how to build quality into your product while controlling scope and avoiding duplicated efforts. We will learn how to apply a ‘whole-team’ approach to quality and how to orchestrate feedback from your tests in order to be extremely effective. We will learn why the traditional approaches to test automation don’t yield the returns we require and why these approaches do not increase quality despite being expensive and costly to maintain.

The course is implemented as an interactive workshop aiming for about 50:50 lecture to lab ratio. Students will have fun, be energized and ready to apply this skill upon completion of this extremely engaging workshop.

We want product owners or non-technical business stakeholders, developers and tasters, as well as anyone interested in learning the craft of Behavior Driven Development (BDD) to attend.

Why?

The pattern repeats itself every day. Many teams implement Scrum or other iterative practices in their quest to be Agile. Initially it appears to work great as the team can just go fast. But, just as quickly as they got started, they discover that they can no longer go fast—that the architecture has devolved, the code is a mess and the team starts to discuss “technical debt” as the reason they are no longer as Agile as they could be.

The reasons for this are many, but if we apply the same practices we’ve always used we’ll find ourselves in trouble sooner, rather than later.

And yet we know that some teams are developing complex software and deploying quality releases. In some cases many times a day. So what is it that these teams know and other teams wish they knew?

What:

The 2-day course for Product Owners, QA Professionals and Developers will teach you what it takes to create quality while building the right product that can support change. We’ll learn how teams new to Agile create technical debt like a leaky faucet and what we can do about it. We will learn about modern ways to “bake quality in” to our products and why practitioners feel these techniques will save “Agile.”

Where:

The Aloft Hotel in picturesque Broomfield, Colorado
8300 Arista Place
Broomfield, CO 80021

When:

Tuesday, December 8, 2015 from 8 a.m.-5 p.m. –Wednesday, December 9, 2015 from 8 a.m.-5 p.m.

Registration:
Hurry! Spots will fill up fast. Register here: http://bit.ly/1UXLRlU

If you have any questions at all, please don’t hesitate to e-mail Tim Walker, instructor and founder of The Agile Tester, LLC. E-mail: Tim@TheAgileTester.com or call 720-323-4652.

Can’t wait to meet all of you! 

Many teams adopt agile practices without a good idea of what to do differently than traditional process methodologies. Often the team will get the direction to "go agile" as a management edict. Perhaps they'll adopt Scrum, or Kanban and implement the ceremonies and approaches prescribed by those process frameworks. 

For a while, they're happy. They can go fast and cut corners and rationalize about anything because "they're agile". But then, something happens and they are unable to respond to change. They're unable to "go fast". Production issues and brittle designs which don't support change will prevent the changes they need. The words "technical debt" become part of the team's vocabulary. 

The main reason this happens is drift away from the values and principles of the Agile Manifesto. Agile is, simply, a set of values and principles. Process frameworks, like Scrum, Kanban, or even SAFe (The Scaled Agile Framework) depend on intelligence, skill and approaches which support these values and principles. It's not enough to do daily stand-ups and demonstrate working software every two weeks. Teams need to proceed in a sustainable fashion, they need to pay specific attention to technical excellence. 

Teams that are agile are often surprised to realize that technical excellence is an Agile Principle. Agile is not about cutting corners, or going fast, It is about delivering value to the customer, getting empirical feedback quickly from the customer and responding to change. If the code has not been designed to be easily changed. If the safety net of the right kind of test automation is not present to support refactoring and ensuring behavior developed in sprint 1 is still working in spring 10, the team begins to struggle to support change and wonder if Agile is such a great idea after all. 

Many teams never realize that they're not doing anything different than they had been in the old process approaches, except that they're doing it with less discipline, less requirements and less design than they had in the past. They treat their sprints, and stories, as mini-waterfalls. In fact, some teams automatically have the same "phase gates" as they had in the old plans. They move stories from "requirements" to "analysis" to "design" and then "code", "integrate" and "test". Just like in the old days. 

Many teams with QA groups spend inordinate amounts of time translating stories to "test cases" and "suites" in tools, like Rally or VersionOne. They dutifully execute their test plans but they realize that, with the speed of iterative development, the amount of time to execute these regression tests increases, sprint over sprint with no hope of catching up and with very little new information being generated by the test cases. 

Teams with separate QA teams will often code new features right up to the end of the sprint and stories get accepted without a clear definition of done, no code review, no automation and with poorly designed implementations. This means the QA team has to work weekends  or testing has to be scheduled in the next sprint Either way is not sustainable and creates all manner of problems for these teams. For example, what is the velocity of a team that discovers a major defect in the sprint after the story was accepted? 

So what is Agile Testing and how is it different from traditional testing? Who is "The Agile Tester?"

First and foremost The Agile Tester is someone who is passionate about embracing the techniques that support Agility and incremental development. The Agile Tester recognizes that we need to do something different. We need to "cease dependency on manual inspection" as warned J. Edward Deming, more than 5 decades ago. 


The Agile Tester recognizes the "whole team" approach to quality and software delivery. Specifically, we value collaboration with the business/customers to help us ensure we're building the right thing. That we share a solid understanding of what it is we're building. 


The Agile Tester recognizes the  significant skill a good tester will bring to an iterative development process, especially when they are a part of the process from the very beginning, at the requirements level. 


Using guidelines like Brian Marick's "testing quadrants" The Agile Tester recognizes that we have test automation in our development processes at the right level for what is being automated. We recognize the value of unit tests to help support refactoring, business facing integration tests showing progress and that desired behavior stays working. We have automation around our non-functional requirements and we integrate constantly, relentlessly. 


The Agile Tester adds high-value "exploratory testing" to the mix and takes advantage of what we're really good at to discover new information about the software. 


Embracing the solid values and principles of "XP" (Extreme Programming) The Agile Tester supports pairing, test-first approaches, and is a student of exceptional object oriented principles and patterns. 


One of the most powerful tools The Agile Tester has in his/her toolkit is "Specification by Example" (Behavior Driven Development) which is also known as "outside-in development" where ambiguity is removed and shared-understanding increased by the use of collaborative sessions which express requirements as concrete examples. This approach results in "executable requirements" which has a profound affect on our iterative processes. 


The Agile Tester is someone who applies all of the above, and more, as a passionate member of a performing agile team. 

If a Scrum team working within the SAFe (www.scaledagileframework.com) framework were a fish, then SAFe would be (to that fish) the thing that would make sure your water is cleaned, the filter is running and you get fed on a regular schedule. 

You’re still a fish. 

As a software engineer, I spent a year on a “SAFe systems team” at a large provider of extremely high-resolution satellite imagery. During that time an imaging satellite was launched.  It was cool. Very cool. The launch was incredible and to see the first images breathtaking. I was really glad to have been a part of it. 

This systems team operated as part of a SAFe ART. It was a supporting ScrumBan team that provided CI infrastructure support for about the 10 Scrum teams we worked with. For example, we developed a strategy for test driven database development and automated migrations using LiquiBase, and taught everyone else how to do it. We supported our shared Jenkins, Artifactory, etc. to keep the teams in flow. We created deployments and test systems in Docker and EC2, etc. We did these things for the teams and as part of an overall management of prioritization of a “program backlog” all of us pulled from. 

I can contribute the view of what it is like as a software systems engineer on a Scrum or Kanban team on a SAFe ART. The most important thing to say about it, I think, is that it was just like many other agile team I’ve been a part of over many projects over many years. Those differences were mostly good (see the fish analogy) but were *very good* in the larger enterprise-wide ecosystem. 

For one, we always had a very good backlog of the best parts of what the user wanted and we had a clear path up to the business strategy that created them. We had a great way to prioritize between teams and manage dependencies as we were aligned with our cadence but also a regular synchronization point (as well as constant interactions with the other teams in our value stream). In fact, that regular synchronization via “program increment planning” was about the only difference to a plain old scrum team. It took place over 2 days about every 10 sprints where the ARTs “inspected and adapted” and planned together for the next program increment, a la Scrum. That helped all of our schedules, for sure. 

Those planning sessions were flat out productive and fun. Everyone in the value stream was there and we talked as a group and then, the ARTs broke out and did a program increment planning, built the new one and inspected and adapted through excellent retrospectives. Moreover, the “social fabric” of a very effective larger team in the ART context and in the value stream context was built. On top of that it, as I mentioned: it was fun, invigorating and, pretty much what we wanted it to be. 


Another difference is that we had built in slack for innovation between program increments. We could work on our hackathon projects for about a week every quarter. Then we’d have an awesome, awesome demo and, again, we had a lot of fun as DevOps engineers. The best projects got mandatory time in the next program increment and were implemented.       

One of the core values of SAFe is “respect for people and cultures”. I can attest to that. The ART I worked on bore it out anyway. We did self-organize and we did self-select on our teams. What we also had was a clear expectation of what decisions were ours to make, what needed to be made for all the teams in the value stream. This little piece, an awareness of clear decentralized control all the way through leadership in the ART, was very, very useful. 

Some things, like having the teams on a regular cadence, are decided at the program layer, because they affect everyone. Other things, like if the team is using Kanban or Scrum, or what practices of XP they want to use (pairing, test first, etc.) are still in the purview of the team. On the systems team (which is right in the middle of the SAFe picture) worked with the business and the engineering teams and we saw great visibility to the overall work in process and solid metrics and approaches to control it. I know managing WIP locally helps manage WIP globally, so I imagine what I saw was extraordinarily valuable to the “business fish”. 

Really, though, as a fish what I saw was was clean water and little multi-colored flecks of food on a very regular schedule. Sometimes I could even control the colors of those flecks. 

--
In the spirit of full disclosure, I am an extreme fan of SAFe and have been using it a long time. I was a rails engineer on a scrum team that was used as one model of SAFe initially as the company referenced in “Agile Software Requirements”, Leffingwell, though I didn’t know it at the time. The job on the system team I referenced above was something I took a pay cut to pursue specifically to experience SAFe in context, which I continue.
--

Yours in the aquarium. Tim