Becoming agile without permission

Archive for the ‘Personal’ Category

In addition to the things I do just to live and work on this planet:

  • What did I do yesterday to make the world a better place for all?
  • What am I going to do today to make the world a better place for all?
  • What is preventing me from doing something to make the world a better place for all?

 



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