Value, what is value?

When you get to work with Agile methodologies, you start hearing a magic word all the time. The word "Value" in agile methodologies is what drives everything. What makes "Value" so magical? Lets see what is behind that word by starting with the  dictionary definition. There are many definitions there but I think this is the one that applies in this case:

"relative worth, utility, or importance" 

This is where everything gets hard with an agile methodology. The definition says it's a relative, but relative to what? Everybody will gets a difference sense of value, because everybody measures it with a different stick.

The business user measures value, in something that will allow him to work less and make the same or more money. A developer will see value on using the latest technology. A DBA will see more value on having a well defined DB schema. A Project Manager will see value following a process and become predictable. A QA guy will see value in a testable application. But, which of all those values is the one you should care about when working in software development? We got into a worst place, because everyone seems to have different objectives while they do their work.

Now, which of all the different values is the right one? Well, I think all of those at the same time, but each one with a relative worth. Now lets look at the first principle of the Agile Manifesto to get a better understanding of which value is important

"Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software."

This means the value the customer gets, it the most important one. So we need to build everything around that. Still, that is not something simple, and it takes a lot of effort to satisfy a customer. Who will put in all that effort to achieve this important goal? That's the whole team working together. But as we know, not all teams are able to overcome all the problems in the process of satisfying a customer. Something else should be added to this mix, and that is team commitment. Without the team working at full steam, it will be really hard to satisfy a customer and be profitable at the same time. There is also another principle in the agile manifesto related to this.

"Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done."

Which is the trick for that? is there any recipe to build a committed team? That's something everybody struggles with, when they are building a team. I think the word "Value" comes into play again. To have motivated people in your team, they need to get value from the project.

How can you align each team member's value with the customer's value? I think that is what management should be focused on through the whole project. The best management is the one that achieves that. This is also not an easy task. Because management is not measured by value, it's measured by numbers. They are often so trapped into those numbers, that they forget what really matters.

"Value" can be many things, acts and even just feelings. I could be just being listened or listen. It can be a mountain touching the sky or bytes stored in a hard drive. The only way to find out what it is, it to talk, dig and look for it. This is probably the biggest challenge for a manager, find out where is value for everybody in the team and align that with the value for the customer. Once you get to that point, you will see a successful project all around.




References
http://www.merriam-webster.com/netdict/value
http://agilemanifesto.org/principles.html

The definitive Corporate IT Firefighter guide

A firefighter in real life, is a person dedicated to extinguish fires caused intentionally or unintentionally. The Corporate IT firefighter does the same. Here is a guide for all the IT firefighters around the globe.

The IT Firefighter theme
"All the effort is dedicated to the most important fire. Then we run to the next fire."

Here is the process IT firefighters follow everyday. We start with the most important thing a firefighter needs to know to be the best as his job. That's knowing :

How to prioritize a Fire?

Fires can have multiple sources on IT. The best way to prioritize fires is analyzing the source. The source of the fire is more important than the size of it, that's why the source is vital to determine the fire priority. A good practice is working with an organization chart. The organization chart is like the real life firefighter cloth, it prevents you from getting burnt too fast. The standard procedure is matching the name of the person that triggers the alarm with the names in the org chart. The higher the box matching that name, the higher the priority. All the fires you are not working on are kept in a backlog, which we cleverly named it the Burning backlog. We will focus then on the fire at the top of the backlog, while all the others wait in the burning backlog to be extinguished.

Once you get to be an experienced firefighter, you will develop improved methods to prioritize backlogs. I met a couple of IT firefighters that used the title of the person reporting a fire but unfortunately they are not working on IT anymore. This is because titles lately became meaningless in companies. For example the only tester in the company now is called Vice President of Quality Assurance. So as a general rule, don't pay attention to titles.

Also you might run into the case, where two fire alarms were triggered by two people at the same level. The best way to solve this case, is to look who has more boxes below him in the org chart. It's also highly important if your name appears in one of those boxes, because that could change the more boxes rule.

With this guidelines, you will be able to successfully prioritize fires in your corporation. 

Fire Alarm response procedure

Whenever there is a new alarm, you need to prioritize it. If the priority is higher than your current fire, you need to grab all your stuff and run to fight the new one. Remember our theme, we alway fight the most important fire. Wasting time in the other fires is not well seen in the IT Firefighting Union, and could get as bad as lose your annual bonus if there is one.

Once the new fire has been prioritized, you need to send a response to the person who set the alarm to calm him during this troubling time. Your response should be "We are working on it, and we will have a solution as soon as possible". That will make you look good, even when you are not even close to work with it or know what the problem is.

Make it a learning experience
Corporations usually have two policies. One is the "no training" policy, and the other is the "no training now" policy. Either way, you will not get any training for most of your tasks, if not all. So, what do you need to do to learn from experience?
When you are working on a fire, you need to be really dedicated, and not just look at the fire, but what caused it. So you will start learning what you should never do in your applications. Things like:

• Catching exceptions and never log any error.
• Building your own internal web framework based on struts.
• Your own XML parser or ORM tool.
• Your own IoC lightweight container.

All those might have a reasonable explanation when they decided to do them, but in the end, you learn they become a big source of fires. Once you see a big source of fire, look at it, understand it, and search somewhere what would be the best way to do it, so it doesn't cause more fires. That will be the closest you will get to training unfortunately. If you are lucky you will get a chance to properly fix them.

Live with it and climb the corporate ladder
Being on Corporate IT is not an easy job. Just like a real life firefighter. Nobody wants to pay for your work or care about your well being. But as soon as they get into a fire, they will call you right away and thank you gratefully once you extinguished it.

Once you become popular in the corporation, everybody will call you and talk about you. If you always follow these simple guide and keep up with the hard work, you future is assured and you will get high in the corporate ladder.

Seriously... if you are working as a firefighter in IT, don't sign up for the union. Become a planner, and work on plans. Planning is looking ahead, firefighting is looking backwards.