Becoming agile without permission

Do you set goals for big projects?
Do you set goals for releases?
Do you set goals when you get behind?
Do you set goals for regular work?
Do you set goals to goals in emergencies?
Do you set goals for the team?
Do you set goals for the sprint?
Do you set goals for yourself?
Do you set goals for the day?
Do you set goals for the next activity?

Why not?

​Is setting goals an unconscious activity?

Why not?

​The “Waterfall” method has dominated the last 30 years of enterprise software development. The method prescribes a series of steps that, when used with the correct templates, provides developers with all the information they need to create good software. We measured “good” by how well the software reflected the documents. The goal was to make software development so that anyone could participate in the definition of software requirements.​

We got so tied to the process and templates that we forgot about ​the software. The software became a secondary output to all of the other documentation.  We got so tied to the processes and templates that our governance revolved around using the right templates and filling in the right fields, not creating good software. All of this emphasis on forms and fields produced a generation or three of people whose job was to fill in the fields.

Then we realized that there are better ways to create software, agile ways.

​The Agi​​le ways tossed out most of the process and templates and documents and forms and told people to think about the software. Think about what we do that provides the most value to actually creating and delivering software.

Problem is, we have people who have only be taught how to fill out forms, how to fill in the blanks. We don’t have people that ​have been taught how to think about what will provide value. H​​ow to think about value. How to develop strategies for delivering​ software incrementally. How to evaluate what really is the Minimal Viable Product.

Even many of the Scrum masters and Agile coaches, the keepers of the agile ways, do not know how to think. They teach user Stories as a form to be filled out,

“As a ___ I want ___ so that ___.”

They don’t teach that the blanks are there to get us to think and talk about the who’s, the what’s, and the why’s.  We concentrate on filling out the fields in JIRA because there are fields. We don’t question if they are useful. It’s there, it must be filled out. The tools can record and track time so that must be important, right?

We don’t think. We just fill in the blanks.

​Who are your customers?

  • Who are the people you do things for?
  • Who uses your work when you are done with it?

These are your customers.

What value do you provide?

  • What services do you provide?
  • What things to you provide?
  • Do you make their work easier or better?
  • Are these things valuable ​to them?

Ask them.

As a Daily Scrum participant
I provide accurate and concise task information
so that everyone understands the state of my work.

Acceptance Criteria:

  • When not providing my update
    • I actively listen to my teammate’s updates
    • I do not use electronic devices unless I am taking notes
  • When providing my update
    • I talk loud enough so that the person farthest away from me can hear me
    • I talk to the whole team, not just to the Scrum Master, Product Owner, or other ranking official
  • When answering, “What I did yesterday?”
    • For each task I worked on
      • I identify the Story and Task
        • At least by ID, by name is better
        • Pointing at the task on the Task Board is good
      • I indicate if the task is complete
      • When I learn something that is valuable to the team
        • I mention it
        • I ask for time after the Scrum to explain it
      • I do not talk about the completed work
    • I do not talk about anything that is not on the task board unless it was an impediment to yesterday’s work
  • When answering, “What will I do today?”
    • For each task I will work on
      • I identify the Story and Task
        • At least by ID, by name is better
        • Pointing at the task on the Task Board is good
      • I indicate if I added the task after planning
      • When I need help
        • I am as specific as possible in my request
        • I get the name of who will help me
      • I give the hours remaining or an approximate completion time
      • I do not provide any detail about the planned work
    • I do not talk about anything that is not on the task board unless it will be an impediment
  • When answering, “Do I have any impediments?”
    • I make it clear when I do not have any impediments
    • When I have an impediment
      • I identify the impeded Story and Task
      • I am specific about the nature of the impediment
      • I indicate what I have done to remove the impediment
      • When help is needed in removing the impediment
        • I am as specific as possible in the help required
        • I get the name of who will help

Testable Increments

As part of my Think Big, Act Small philosophy of agile software development, I prefer to implement things in small units that can be easily tested. I call this unit a testable increment.


A testable increment is small. An increment can be a new method, a single change to an existing method, the shell of a new class, anything that is a small change and can be tested. A single increment should be implemented, integrated, and tested within a single day. Several, dare I say dozens, of testable increments should be completed in a single day.

By being small, testable increments can be completed quickly. By working with testable increments we can see progress towards getting the bigger things done. It feels good to get things done and with testable increments we can get many things done in a day. Instead saying, “I worked on story A yesterday and I will work on story A tomorrow”, you can say, “Yesterday I completed the get/set methods and the main processing flow of the class. Today I will complete the three exception flows and add the special case creator methods.”


A testable increment is testable. If it cannot be tested, the quality of the change cannot be validated. By testing it, I have confidence that it works and I can build more things using it. Unit tests, especially automated unit tests, are invaluable, almost indispensable, for coding in testable increments. After I am done with the current testable increment, the automated tests become part of the regression tests that I run frequently to ensure that the current testable increment I am developing does not break all the previous testable increments.

In order to test a testable increment, good unit tests need to be created; good test data needs to be accumulated; and good test harnesses need to be built. While all of these things take time when you are just starting to work in testable increments, in the long run you will save time because what you build is reusable, extendable, and can significantly reduce the amount of time spent investigating and resolving anomalous behavior. Sometimes, if not frequently, the test harnesses can become good demonstration tools, especially for backend or API driven systems.


Faster Feedback

Creating and testing small things is faster than creating and testing big things. Because of the faster times, we get much faster feedback loops, which in turn allow us to debug and improve at a faster pace.

Faster Throughput

Smaller batch sizes move through the delivery flow faster than large batch sizes.

Easier Validation

Validating and repairing a few lines of code is easier than validating and repairing hundreds of lines of code. When something is wrong, you have a smaller space in which to find the error.

Better Design

Creating things as testable increments leads to better design. In order to test these small things, they have to be built-in such a way so that they are testable. This leads to components that have well-defined interfaces, are encapsulated, and are not as cohesive with other components.

Higher Possibility of Reuse

By making things smaller, they also have a higher possibility of reuse. A function that is contained in a single testable unit can be incorporated into other functions much easier than one that is in a module with several other functions or spread across several modules.

Complexity Isolation

By creating smaller things, you can isolate the complex aspects of a function into a couple of small complex things so that you have dozens of simple things and on a couple of complex things. In most cases, something that looks complex is only complex in a very limited space within the bigger function. Breaking it down into testable increments allows you to 1) get the simple stuff coded and tested independent of the complex stuff and, 2) isolate the complexity so that it does not affect the rest of the code. You can “stub out” the complex part while one part of the team is working to solve the hard problem. The rest of the team can continue creating the rest of the solution. When the complex part is ready, It can replace the “stub” with little or no impact on the rest of the solution. This approach also allows the team to try multiple solutions without a lot of code rework on the easy stuff.

Evolutionary Development

Testable increments allow the feature to “grow” over time. Starting with the most basic needs to get a feature working and then adding small enhancements to make it better, the software evolves rather than bursts into existence. As it evolves, we can evaluate what things are more valuable than others so that we can direct our attention towards the things that provide the most value.


Think Big

Think and design with the complete system in mind. See the “big picture” and understand the goals and objectives. Seeing the pig picture helps you identify, design, and make small changes. Understanding the complete system reduces the chance of making a series of small changes that do not fit in with the whole system.

Act Small

Make very small changes to the system. Make small, testable, functional, changes to the system.Keep the system working: Make a small change; Integrate the small change; Test the small change; Test the system. Is everything still running? Good. Make changes in what I call testable increments.

Small changes are easier to get done. Small changes are easier to verify. Small changes allow you to focus on just a little bit of the problem. Small changes allow you to learn faster, to validate assumptions faster, to allow you to innovate faster.

Small changes lead to better designs, better quality, and better solutions.

Making a lot of small, good changes adds up to a big, good system.

I Am an Agile Team

The last level of whatever organization to which I belong is me. I am responsible for planning, doing, and delivering my work. I am the one that makes sure it is of sufficient quality. In reality, there is no other group. There is only me. For me, I have to do it all. I am an Agile team.

I Am My Product Owner

I decide on what I do now. I assess the value of all the things I need or want to do and determine what I should be doing now. When I am done doing whatever it is I am doing now, I decide on what I do next. I use all the information at my disposal to determine what is the best thing for me to be doing now. I am my Product Owner.

I Am My Scrum Master

I make sure that I am working as effectively as possible. I make sure I have the skills to do what I decide to do. I make sure I have all of the information I need to do what I decide to do. I work to remove any impediments I might face. I communicate to the outside world set the appropriate expectations I am my Scrum Master.

I Am My Team

I am responsible for defining my work. I do my work. I make sure the work is good. I collaborate with other teams, that is, other people, to get big things done. I troubleshoot my work. I integrate my work with my previous work and the work of others and make sure it all still works. I find ways to do my work better. I find better ways to work with others. I am my team.

I Am an Agile Team

Even though in the larger context, I am a developer, or tester, or Scrum Master, or Business Analyst, or whatever, on an Agile team, I can, and I do, everything that an Agile team needs. For I am an Agile team.

I’m working as a Scrum Master these days. Today, I attended a Scrum Master’s Community of Practice. As the group is new, we were working on a Mission Statement. While the ideas were begin tossed around, I wrote 4 things on the whiteboard: Craftsmen, Retro & Learning, Coaching, and Evangelist. To me, these are things a Scrum Master should strive for. As the discussion progressed, these words cam to me:

As a Scrum Master
I strive to be an Agile:

  • Craftsman,
  • Coach, and
  • Evangelist

so that

my organization,
my teams, and

deliver quality and value in all we do. 

This has become my Scrum Master Pledge.


Accountable is a word that has two very different connotations in the agile world. One way is perceived very badly by Agilists. The other is absolutely necessary for agile to succeed.

Good: To Be Accountable

Bad: To Hold Accountable