Becoming agile without permission

Archive for the ‘Personal’ Category

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.)

 


100% QualityBeing agile means delivering value; value in everything we do. A major part of delivering value is delivering quality. You can deliver something of poor quality and there still might be value, but not near as much value if it had high quality. This means that there needs to be high quality in everything you do, quality code, quality tests, quality user stories, quality designs, quality e-mails, quality discussions, quality requests, quality learning, quality thinking, quality doing. It is not just the end product that needs quality. Everything needs quality.


There was a lot of talk and activity this week around defining new activities and roles. I am also working on defining what my role is here at my new company. Several times I brought the conversation around to the purpose of this new thing. The purpose specifies why we do or need something. It specifies the reason for something’s existence. Identifying the purpose goes a long way towards defining the activities and outcomes. Identifying the purpose also helps to put boundaries around something. The boundaries then help keep things more pure. They keep us from adding more stuff to something just because we can.

When I was a software designer and architect, I would always define the purpose of a component, the reason for its existance. This purpose would then guide us as to where to add functionality. If the new functionality did not support the purpose of the component, we usually did not add it to the component. We found the component where the functionally fit the purpose. Sometimes we had to create a new component with a new purpose. Rarely, we had to redefine the purpose of a component to include the new function.

So, this week I started on identifying my purpose in my new role. I drafted my professional mission statement. The mission statement identified the reasons why I am here. What I am to do. What I am to change. What I am to be.

What is your professional purpose? What is your personal purpose? Why are you here?

What is my purpose?


41SZPFin3BL._SL500_AA300_Designate a couple of hours (2 to 3) in the morning and a couple of hours in the afternoon as your Core Work Hours. These hours are set aside for actually working on the stories and tasks for the current iteration. These hours cannot be used for meetings. It does not mean that you cannot work collaborative with others, just that what you are working on must directly contribute to the current primary work. Meetings are not considered primary work. Do not let people take this time away from you. If they request a meeting during your core hours, suggest a different time. If they insist, let them know that they are taking time away from committed work.


This one is not particularly an agile behavior, just a good practice. When you need to ask someone for something, make it easy on the person you need something from. Make sure your request is well-formed. By “well-formed” I mean that the request has all of the information necessary to complete the request. I should also request a confirmation that the person will do the request.
A well-formed request should have the following parts.
State what you want. 
This is the request. Be specific in what you want. Do not make the person guess at what you need. In a poorly-formed request, this is all that someone gets and it is usually not very specific.
State how you want it.
This is the form of the reply that you are expecting. This could be an e-mail, a report, a spreadsheet, even a simple “tell me what you find out” form.
State when you want it.
This is the timeframe in which you need the request to be completed. In addition to dates and times, “By Friday noon” and “before you leave today” are examples of timeframes. If you request a date, be sure to indicate a timeframe. Friday 8:00 am and Friday 5:00 pm are two very different interpretations of “on Friday”.
Indicate the priority of the request.
“High”, “Medium”, and “Low” are always good indicators. However, if every request you make is “high” priority, you lose all credibility in the “Is this really important” department. If you know the person’s work list, you can say what the request is more important than or less important than.

Ask if this works for the person you are making the request?
This gives the person a chance to ask questions about the request. It also gives them an opportunity to assess the request against all of the other work they need to complete. If they say yes, you have an implicit commitment that they will do what was asked.  If not, you can answer questions or reframe or adjust the request to be more acceptable. You can negotiation an agreeable request. Sometimes though, the person just cannot fulfill your request. But now you know so that you are not expecting something to be done when nothing is happening.

Yes, making a well-formed request takes more time on your part. But, by taking the time, you will usually save time in the long run. By making a well-formed request, you…
1. Improve the odds that the request will be handled to you satisfaction.
2. Make it easier on the person by providing defined response criteria.
3. Show respect for the person’s current work and autonomy.

Too many times we let many things control our attention. We let things interrupt work in other areas. We need to focus. That other thing might be impotrtant. if it is, take care of it. But if it is not as important as what we are working on, note it and get back to work. Taking time to work on the other thing just takes work away from our current activity. We all have more than enough to do. If we focus on the most important thing and get that done, we can move on to the next important thing. Then, one by one, we get stuff done. Otherwise we work on a whole lot of stuff without really getting anything done.


Think in terms of changes to the system that need to be made instead if what tasks do you need to perform. Thinking in changes to the system forces you to think more about the design of the changes and therefore the complexity and size of the work required to make those changes. Tasks will follow naturally from thinking about the design of the changes.


Write and unit test the code in very small increments.
Make a very small enhancement and get it working and keep everything else working.


Focus on delivering high quality software. Check-in defect free code that gets the job done. In most cases, the time spent producing good code the first time is less than the time spent later trying to fix it. Also, be embarrassed when you deliver code with defects. You professional reputation is at stake. Take great satisfaction in delivering error product. It feels good.


In the course of your work you will discover something that is not clear, is un- or under-specified, or just plain wrong. When you bring it to the attention of the team,  have suggestions and a recommendation of what should be done to resolve the issue. You will be seen as a creative, knowledgable problem solver and not someone that leaves the hard work for others.