Becoming agile without permission

Archive for the ‘Personal’ Category


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

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
myself 

deliver quality and value in all we do. 

This has become my Scrum Master Pledge.


Accountable

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


Everything I do, I do it with POO

Everything we do in life has POO. Everything we do at work. Everything we do at home. Everything we do when we are alone or with somebody or in a group or in a crowd. Everything we do has POO. Everything we use has POO. Everything we create has POO.

What is POO?

POO is the Purpose, why we do something; the Objectives, what we are trying to get out of something; and the Outcomes, what we expect at the end. POO helps us better define what we are doing and why we are doing it. POO also helps us put boundaries on things. It helps us determine whether or not something contributes or not. It helps define when we are done. It lets us know if something is appropriate for what we need to accomplish.

Purpose: Why bother?

The Purpose tells us why we are doing something. The Purpose provides context. It gives us the reason and motivation for doing or changing something. It helps us prioritize what we need to do or change.

The Purpose is usually just a single sentence. For example:

The purpose of this article is to convince others that POO is a good framework for defining changes to things and other activities.

Objectives: What do we want?

The Objectives describe what we want out of something. It focuses our thoughts and actions on specific, defined goals. This helps us choose thing and activities that contribute to the objectives so we do not waste time or resources that do not help us achieve the objectives.

There can be one or more Objectives for something. It helps if the objectives are listed in order of priority. For example:

The objectives of this article are:

  1. To raise awareness in others that everything has POO
  2. To show the usefulness of identifying the POO
  3. To solidify my thinking and understanding about POO
  4. To foster discussions on POO

Outcomes: What do we get?

The Outcomes identify what we expect to get out of something. They are the state of the universe after doing or making something. The Outcomes help us focus on what we really need to deliver, on what we expect to change.

Like Objectives, there can be one or more outcomes. For example:

The outcomes of this article are:

  • People use POO when defining activities or changes
  • People use POO when doing and making choices
  • I am happy with my understanding of POO
  • I am happy with my POO
  • People talk to me about POO

So? Why is POO important?

POO is important because:

  • It helps us focus on what we really need to do or make.
  • It helps to align expectations.
  • It helps use understand the bigger picture in which we do specific things.
  • It provides a framework for discussing and making decisions about activities and changes.
  • It helps us know when we are done.
  • It is a tool for defining activities, tasks, deliverables, conditions, projects, changes, and… well, everything.

 

(You may say that all of this is a load of BS. I say it is POO.)