Sometimes, when engaged in lean-flow trainings or discussions, I will use my "church meeting" example to explain U-Curve optimization for finding optimal batch size (eg: transaction cost, holding cost). Thought I'd share.

It goes like this. 

After a church social (or any other meeting, in particular the one at the moment), we usually volunteer to put away the folding chairs. The big, strapping, football jock will (in an attempt to impress Mary) grab 6 of them under each arm and hold them out like an iron cross as he toddles toward the closet. 

He can press two-times his weight, after all. 

Next phase of Operation Folding Chair: waddle with a half dozen chairs under each arm, over towards the hallway connecting the rooms. In the process:  knocking over the nice cupcake lady, spilling 2 glasses of purple punch on the new laminate floor and denting the drywall. Our guy eventually makes it to the storeroom like a Category 5 hurricane. Once in the storeroom, he proceeds to drop 4 of the folding chairs (now that Mary can't see him), knocking the previously organized chairs over and tearing one of the seat covers. He might have even strained his wrist. Coach ain't gonna be happy.  

On his next trip he tries 4 and finally settles on 3. 

The holding costs of keeping the chairs in the gossip chamber a few more minutes is nothing.

The transaction costs go up with the batch size and the frequency and total number of trips to the storeroom. 

At this point we can explain how we this applies to things like: code check-in batch sizes (replace big-strapping jock with over confident joe programmer), number of #userstories in an #agile #devops release, and #kanban #wip limits. We don't want to check in code for evert single character we write but we probably don't want to wait for more than a few hours, either.   

We can continue to learn that you figure it out your batch sizes in precisely the same way: 

Trial and error and continuous #measurement. 

​Go find your optimal batch size! But please, tell the Church Lady you're sorry if she gets knocked over in the process.  

A great deal of potentially dangerous confusion and guidance exists around the subject of "Tasking" in Scrum. You'll encounter wildly different guidance on the subject. SAFe, for example, says that they recommend against them (largely for the reasons outlined in this article), but can be useful for teams getting started. Others suggest it's just a good way to roll always.

So which is it? Let's dig in. 

Before we start, we should make sure we understand that the term as the word "task", and the derived verb "tasking", can mean different things to different people. If you read "User Story Mapping, by Jeff Patton", for example, you'll see "Tasks" in a Story Map as the things people want to do while telling the Story of what outcome they want to achieve, not the "things to do (i.e. work-breakdown structure) to accomplish a goal". It is the latter definition that I am referring to in this blog post. 

Tasking as a management imperative, to track the work being done, can work counter to our other Agile inspired practices.

For example, if we attempt to use tasks in this fashion, we potentially invite: 

• Parkinson's law. Work will expand to fill the estimate.
• Time spent in bookkeeping that isn't adding value
• Discourages the advancement of cross-functional teams. We'll see tasks decomposed by the "experts" in that subject on the team
• We become template zombies over time. "Define it, Build it, Test-it, Nom, Nom, Nom"
• Difficulty knowing where actual story progress is during the sprint (90% of task completion but the last 10% takes triple the whole-time).
• "Busy-ness" becomes the primary measure of progress
• Management looks to optimize utilization of "resources" which will, predictably, cause utter collapse in flow of delivery
• Utterly duplicative. If the teams know the tasks to do than just do them.
• Output is not the same thing Outcome.
• It is rife with abuse
• Delaying one task delays another task - just like it always has
• The focus is on the task and the plan - this crushes any possibility of innovation along the way 
• It is "following a plan" over "responding to change"
• Tons of extra work by the developers that adds no value
• As an excuse to not decompose stories into small vertical slices
• Demoralizing order-taker mindlessness
• The list goes on...

Now, "tasks" aren't bad, per se.

I routinely use them.

All the time.

At work, at home...just about everywhere.

But I use them in an agile way. I scribble the list on paper and delete it when a better idea comes along. I don't agonize over how long the task is going to take because the task will take what the task will take. What's funny is I regularly achieve the "value" from the thing while many unfinished, or different, tasks remain on the list. I use them to guide me but they are never "the thing of value". 

Here are my heuristics for the use if tasking as work-breakdown structure:

• Tasking can be useful on many levels when used as an 'emerging dynamic checklist'
• Therefore, the approach must "support changing tasks, even late changing tasks" as new information is obtained to allow for a better plan
• Do not record tasks in an ALM. It's pure waste
• Do not use tasks to measure progress (working software is the primary measure of progress)
• If you must put tasks in the ALM do not put time on them
• Teach leadership to trust the teams
• Focus on User Story understanding and decomposition instead
• make your stories smaller and constantly work on the abstractions
• use User Story Mapping and BDD to create a shared understanding
• pair on all stories
• communicate in person as a team, not through the ALM task "work breakdown structure
• Do burn-up story points
• Do let the teams decide for themselves if and how tasking is useful
• Do use the time you would have spent tasking to understand the customer needs better and to build quality in, instead.

ReplyForward

The question: "Is SAFe Agile?" comes up with great regularity. There are myriad opinions on this subject. Some of these opinions are from people who have never worked in a SAFe environment who have never really studied or experienced it. Some are from experts in Lean and Agile practices. Some are even signatories of The Agile Manifesto itself. Others are the opinions of people with great experience in successful as well as unsuccessful SAFe implementations. 

So, does SAFe really comply with the Agile manifesto or is it, simply, more snake oil?

Let's take a look. 

SAFe (in its training and elsewhere) claims to be based on the Agile Manifesto, SAFe also calls out Lean principles with the goal of "the delivery of valuable software with the shortest sustainable lead time to the customer". As well, SAFe inherits from "Agile Software Requirements", which scales the concept of User Stories to the Enterprise. If that weren't enough SAFe is built on literally every principle in Donald Reinertsen's breakthrough research described in "The Principles of Product Development Flow". But, did it succeed in being "Agile". 

The Agile Manifesto is 4 values and 12 principles. Let's do some comparative analysis with SAFe. 
​
SAFe’s highest priority is to satisfy the customer through early and continuous delivery of valuable software? 

Check. Team Demos/Train Demos/Solution Demos/PO’s on team and attention to stakeholder management continuously create opportunities for fast-feedback so the best fit-for-purpose solution is delivered.   

Safe welcomes changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage?

Check. The use of Agile Software Requirements (the “Bible” of SAFe) as well as continuous planning across the enterprise, coupled with the XP practices of Test First/Refactoring/Collective Ownership/Pair Programming and Continuous integration provide best in breed agility at scale. 

SAFe delivers working software frequently, from a  couple of weeks to a couple of months, with a preference to the shorter timescale?

Check. SAFe promotes the concept of “Develop on Cadence, Deliver on Demand”. SAFe can deliver anytime the business deems it’s ready. Scrum delivers working software on a cadence and Kanban delivers in a continuous flow. SAFe is extraordinarily powerful to influence a true DevOps culture and calls this out directly.  

SAFe supports the principle that business people and developers must work together daily throughout the project?

Check. SAFe is, essentially, structured Scrum of Scrums with simple roles and clear alignment. Scrum/Kanban as core practices inherit this from XP with the presence of Product Owners, Lean/Agile Leaders and goes beyond this with the larger inclusion of stakeholder involvement at every level. 

SAFe knows to build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done? 

Check. This is essential to Agility and SAFe just inherits that directly from the manifesto. The SAFe training has done to advance the “Motivation of Knowledge Workers”, arguably, more than any other  single process or activity to date. 

SAFe believes the most efficient and effective method of conveying information to and within a development team is face-to-face conversation? 

Check. SAFe supports all of the ceremonies of Scrum of Scrum and Syncs on a regular basis.  

In SAFe, working software is the primary measure of progress. 

Check. Moreover an emphasis on the business value of the software delivered, just not the quantity of software developed, is a metric recommended by SAFe.  

SAFe Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely?

Check. SAFe is a pull system and is based in a value of respect for people. Teams only pull what they can reasonably accomplish. The IP sprint allows teams to recharge and innovate. 

SAFe recommends that continuous attention to technical excellence and good design enhances agility? 

Check. SAFe recognizes the ability to respond to change and support the rest of the manifesto hinges on exceptional SW practices and calls out the best of breed from XP as essential. Many teams try to “do Agile” and make the mistake of “cutting corners” “because we’re Agile”. Scrum makes no provision for XP. 

SAFe knows that simplicity--the art of maximizing the amount of work not done--is essential? 

Check. The alignment with the PI planning facilitates powerful big room planning and alignment which would otherwise result in myriad meetings, dependency planning issues, additional coordination and failed integrations and numerous other wastes. The absolute minimal number of people required to deliver in large enterprise are in place in the SAFe big Picture. Pretty hard to lean it down any more. A layer is 3 people and a backlog and only what else makes sense. Contrast that to thick layers of middle management in traditional project structures.  

SAFe allows for the best architectures, requirements, and designs to emerge from self-organizing teams? 

Check. Recognizing that it would be catastrophic to allow 400 scrum teams to architect a solution without some architectural guidance “unintentional architecture” is a certainty. SAFe aligns architecture and user experience across the portfolio. Teams are responsible for articulating their requirements. Designs emerge organically at the Train/Team level. 

In SAFe, at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly?

Check. Team retrospectives, Train retrospectives, coupled with true root cause analysis and calling for improvement backlog items as mandatory to comply with the “relentless improvement” siren puts SAFe squarely in the requisite PDCA idioms of modern-age development. 

Summary: 

SAFe scores a perfect 12 out of 12 compliancy with the Agile manifesto. If there is any deviation whatsoever it would be in additional scaling acknowledgement and recognition of powerful flow concepts such as “there is more efficiency in overall alignment than with local optimization”, and powerful arguments about when it makes sense to decentralize control to the teams in the enterprise makes SAFe even better.

Case study after case study not only make it clear that SAFe does indeed comply with the Agile manifesto but takes the Agile manifesto in to the enterprise with style, aplomb and lean based flow. The only way SAFe can not conform to the Agile Manifesto is if it's poorly implemented. "Agile", being absolutely nothing more than a set of "Values and Principles" it is the practitioners, not the SAFe framework, which determines if SAFe complies. It can be no other way.   

Abstract
 
The Software Industry is changing in remarkable ways and at a pace that is almost impossible to comprehend. With the advent of practices such as cloud computing, on-demand virtualization, automatic scaling, self-healing systems, rich development technologies and and extreme DevOps approaches, development teams that are not mired in outdated approaches are gaining a competitive edge that will be very difficult to catch by legacy development teams.

​We know the value of Agile methods. Studies, such as those published by David Rico in “The Business Value of Agile Software Methods”, shows that the ROI of Agile technical practices such as Test-First Development, Pair Programming, et al, deliver remarkable ROI and give organization a beacon to follow for effective change. 
 
So, how do these legacy (“venerable”) teams catch-up with those teams that are delivering business value at rates that can only be described as scary? Enter DevOps and the DevOps Dojo, which might be better called “The Agile Accelerator”. Even as this is written new practices, such as Behavior and Domain Driven, User Story Mapping and more, are further accelerating the advantage forward learning teams are experiencing.
 
This brief describes, in a step-by-step fashion how to go about building a DevOps Dojo.
 
The DevOps Dojo
 
A dojo is a term from martial arts that means “Place of the Way”. It is where martial arts students progress by the use of training fundamental skills (“Kihon”) and practicing them through exercises and repetition (“Katas”).
 
A Dojo consists of the “place”, which is the dojo itself, the students and the instructors (“Senseis”). A sensei is a person who is extremely skilled in the discipline, usually a multiple degree “black belt”, who also shares a passion for the craft and for teaching others. In the above photograph you see the discipline taught instilled in the heart and mind of even very young students.
 
If you watch a martial arts dojo, even for the young children, you will immediate notice the culture being taught is as, or more, important than what is taught. Students learn to bow to the sensei and show respect, to work together and positively at all times. In the dojo or otherwise. This is very important in building a DevOps dojo in your environment so keep that at the center of your thinking and planning.
 
A DevOps Dojo consists of the same components.
 
Step 1: The Champion
 
A successful dojo will need a champion for the effort, supported by the people who know how to do it.
 
Step 2: The Kihons
 
The next step in building a DevOps dojo is to understand what “Kihons” are desired to develop in your teams. In the case of DevOps (which is more of a culture supported by these practices) the interest might be in Test Driven Infrastructure, Configuration as Code, Continuous Integration and Delivery and the XP inspired technical practices such as Test First, Pair Programming, Design Patterns and Refactoring.
 
Step 3: The Senseis
 
When we know, more or less, what the Dojo The next step in our Dojo journey would be to identify and engage those people who are skilled and who have the right attitudes to lead the journey. Unless we have this skill in-house, this usually means bringing in the skill by hiring experts in the industry or bringing in highly-skilled consultants to “seed” the Dojo.
 
We’d want to have a pair  of senseis per Dojo instance, per team. This is to learn from each other, to exploit the skills between them and to accommodate any absences by one sensei that could disrupt the training.
 
In the case of specific needs we might need to bring in “special senseis” that have specific skills that are not otherwise present. One of the differences between a DevOps dojo and a Martial Arts Dojo is that the Martial Arts dojo usually consists of a “specific discipline” while a DevOps dojo could be any technology skill in the industry. Perhaps more analogous would be a “Mixed Martial Arts (MMA)” dojo.
 
Step 4: The Dojo
 
When we have a champion, know what we want to teach and have identified the senseis who will be leading the students we need to know where the Dojo will be located. In some cases it’s possible for the Dojo to “go to the teams” but we prefer to identify a special place showing “the way” and disrupting the cycles that have been engrained, possibly by years of situational katas and exploiting the “old ways”.
 
The size of this Dojo should accommodate the number of teams we want to train (a team is usually a small, cross-functional “Scrum” team of 5-9 students), and scaled by the pace that we want them to learn. For example, if we have 12 teams and we want to train them in 1 year, we’d need space to accommodate 1 team undergoing a 1 month Dojo which means we could get 12 teams per year through the Dojo.
 
The dojo will be a pleasant location, well lit and with plenty of whiteboards, space and other supplies that might be required.
 
The dojo will also need acces to the cloud or systems that can be leveraged to do the training such as AWS EC3 access.  
 
 Step 5: The Dojo Flow
 
When we’ve identified the people and place of the dojo we need to create a plan for the execution of it. Some questions we’ll need to answer:
When will it meet?
How will it work?
Who will be involved?
How long is the dojo?
How will we deal with follow-up and continual growth and technology advances?
 
Step 6: Build it and Improve
 
Finally, we need to find a team and get them in to the dojo so we can learn and improve. It is very common to do assessments of one form or another before the dojo and again after the dojo so that we can continually improve.
 
Summary
 
Building a DevOps dojo might be the difference between a legacy company staying in business and being overcome by teams who have “technology birthrights” and delivering outcomes to its customers at a rate and quality that has heretofore been impossible to even comprehend. Some customers are release software as often as every minutes, hundreds or times a day.

© The Agile Tester, April 20, 2017 ​

The Scaled Agile Framework (SAFe) is a marvelous tool for allowing us to visualize, baseline and improve our agile initiatives as we scale them to the largest development efforts on the planet. As a SAFe consultant, practitioner and team member I’ve noticed a couple of patterns that I’d like to bring forward for discussion and/or maybe a simple “adoption pattern" that others might find useful.
​
1.The Complexity Container
The SAFe 4.0 (Lean Systems Engineering) brought forward a new level (physically) in the SAFe big picture as well as powerful engineering constructs like Model Based System Engineering and Set Based. It did this through the creation of a new “Value Stream layer”. Since the advent of this layer we’ve seen a lot of excitement as well as some confusion around when and how it should be applied.
 
For example:

1. Some have suggested that the “Value Stream” (VS) layer is “ephemeral” in nature and should not be applied until it is absolutely needed and then folded up and removed when it is no longer needed.

 

1. Some suggest that you don’t need a VS layer if you have a Portfolio and that the coordination or multiple ARTs can be done in myriad ways.

 
This kind of confusion, as well as hearing the word that “SAFe is a simple Fractal for decomposition”, has made me think there’s an easier way.
 
Here’s the proposal:
 
We do away with the Value Stream layer.
 
Instead we create an analogous layer “Complexity Container” or “CC”. Anytime we have more than one ART we can consider the creation of a CC. The “interface” to the CC is the troika (just like in the VS layer). We, therefore, will have “SAFe CC3” (or similar) and everyone will know what we mean. We simply have the troika repeated everywhere and used to connect the containers.  We can have multiple layers when appropriate. For example, something complex like a satellite system, might have a CC4 with a “lopsided implementation” having CC3 layers on one branch and CC2 layers on another.  
 
We move “Solution Intent” and “Solution Context” to the Spanning Palette.
 
We can have solutions everywhere and at any level. If we’re building an amusement park ride, for example. The Track System can be a solution, as can the Vehicle and, perhaps, the Networked Ride Sharing system. Even in a single art, the solution intent and solution context become valuable constructs. Even in a single ART we demonstrate “the Solution”.
 
We move all the Portfolio Constructs (including the Enterprise) to the spanning Palette
Need a specific budget for a given ART? Need capacity allocation to a “C3 Container”? Need to have a single portfolio for a series of businesses? No problem. These are just conceptual building blocks that can be applied as needed. It is the core provided by “Essential SAFe” scaling in myriad ways without locking companies in to a prescriptive solution.
 
We move MBSE and SDB (Model Based Systems Engineering and Set-Based Design) to the practices we support
Right along with TDD, BDD, Pair Work, Refactoring and Collective Ownership. We add, Domain Driven Design, Contract By Design, Design Patterns and more as the requisite practices for scaling agility.
 
We create a true troika by adding a Quality component at each level.
Like the 3 legs of a stool, or the branches of government, we add a Quality Engineer to the troika at all levels. We extend that level all the way through the team and all the way through the complexity layers, even with portfolio constructs. We recognize the business will determine what needs to be built, development says “how” it will be built and quality determines “how” it will be validated. This, then, becomes another fractal in the system.  
 
2.The Ghost Train
Some concerns are cross-cutting but are too large to be considered a “shared service” and to important to be considered a “community of practice”. Security, User Experience, etc. Enter the Ghost Train.  The Ghost Train is a “Virtual Train” that has standards and deep knowledge on it but, to avoid becoming a single constriction, is manifested as people on the regular trains augmented by special alignment/standards/skills, etc. This distributed model would ensure that approaches and standards are adhered to while providing for feedback from the system.

Author Tim Walker, CEO & Founder, The Agile Tester, LLC

I’ve been a huge fan of “Executable Requirements” for more than a decade. I have delivered many classes (“Executable Requirements with FIT and FitNesse”). I’ve followed the evolution of these powerful approaches to software engineering and have seen the state of the art as it’s sashayed its way along through the x-Behaves (jBehave/rBehave), Story Runner, RSpec and, most recently, Cucumber.

Earlier this year Matt Wynne, one of the contributors of Cucumber and co-author of “The Cucumber for Java Book”, gave a talk where he extolled the virtues of Behavior Driven Development as the force that could “save Agile”. I couldn’t agree more.

As a software engineer these are techniques I always reach for and consider essential. I have built test labs using Cucumber for Smart Grid devices. I have used Cucumber to help rewrite one of the largest systems in the Department of Treasury where thousands of business rules are verified and I have used Cucumber to describe and verify the behavior of “infrastructure as code” using the EC2 API and Docker.

Jeff Patton’s “User Story Mapping” is an excellent way to draw outuser stories using a narrative flow and which creates a two-dimensional backlog. This extra dimension  allows us to drill down on different user stories, explore and group additional stories and creates an excellent opportunity for visually defining minimum viable product. It’s also extraordinarily powerful when used in conjunction with Behavior Driven Development, which is also known as “Specification by Example”.

In a modern Agile workflow, we delay the creation of details as long as practical. This keeps us from spending time specifying details of something we may never build, but also allows us to specify details when we know the most about them and keeping those details fresh in our minds when we drop down a gear to implement them using Behavior and Test Driven approaches.

Story Mapping can be used anytime to help visualize the user story narrative for a user of a system, or Persona. We are admonished to use real names of real people who are using the system to help us understand the way different users engage with it. We can then use Behavior Driven Development to drive out the details in a directly executable format and begin our “outside-in” development to help us deliver the feature while “baking quality in” and managing scope.

Let’s give an example.

Let’s assume that we are developing mobile software for teenagers to keep them safe while they are driving. The idea behind our software is to disable incoming and outcoming text messages while the vehicle is in motion.

The Story Mapping narrative might go like this:

Rhonda gets in her Honda

• Starts the car and drives off
• When a text message is received while the car is in motion
• Then a text message is returned to the calling number
• And a log is maintained

Rhonda Checks her Logs

• Rhonda gets home
• She checks her call log
• She replies to anyone

Rhonda Sets up Autoreply

• Go to app settings
• Open AutoText
• Open Configure AutoReply
• Set Minimum Speed to 15 MPH
• Set Message to be “Rhonda is driving her Honda and will Reply when it’s Safe!”

Now, using the Good, Better and Best approach to Story Mapping we might consider something for a later release

Rhonda sets up AutoReply with a Video Call

• Go to app settings
• Open AutoText
• Select Configure Video Reply
• Record a Video Message
• Save with a name
• Select that Video Message for AutoReply
• Set Minimum Speed to be 15 MPH

Rhonda sets up AutoReply for Different Speeds

• Go to App Settings
• Open AutoText
• Open “Slow” Auto Text
• Set Minimum Speed for Slow to be 15 MPH
• Set Message to be “Rhonda is fighting traffic and will call right back!”
• Open “Medium” Auto Text
• Set Minimum Speed for Medium to be 25 MPH
• Set Message to be “Rhonda is delivering mail in her Honda and will call when it’s safe!”

    etc.

Now, any one of these scenarios might make it into the backlog as a user story.

In order to safely notify friends when I am driving, I’d like my cell phone to automatically reply with a default message when my vehicle is moving, so that I can concentrate on driving while letting my caller know why I am not responding.

When it is time to flesh out the details of this user story we can use Specification by Example to do the job.

Feature:  Basic Auto Text Reply when Vehicle is moving
  In order to safely notify friends when I am driving
  I’d like my cell phone to automatically reply with a default message when my vehicle is moving
  So that I can concentrate on driving while letting my caller know why I am not responding

Background:  
   Given my cell phone is in motion and is travelling at least 15 MPH

Scenario: Use defaults to answer SMS Message
   When a SMS message is received
   Then a default SMS is sent to the sender

Scenario: Use defaults to answer a voice call
   When a phone call is missed
   Then a default SMS is sent to the caller

As you can see, just thinking about the problem made us handle the case where we might decide to implement the basic behavior when a regular voice call is received, even though that’s probably another story altogether. In any event, we know clearly what is in scope to be developed and a simple (and functional) application could be delivered. In this case, we’re not allowing any additional configuration, just specifying a couple of defaults (the speed of the car to auto generate a response and the fact that a default message will be provided).

Using this example to get to work on our story “outside-in” is very easy. We’ll simply execute Cucumber, use the snippets it generates for us, add these to our steps files and start implementing the code using TDD. In this fashion, we have a simple and testable design, by default, but when we start working on additional behavior we’ll know that our basic case stays working.

I invite you all to attend my upcoming workshop on Behavior Driven Deveopment for Agile Teams. It will be held on December 8-9, 2015 in Broomfield, Colorado at the ALoft Hotel. 

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