"Agile" must surely be the most used (and abused?) buzzword ever in Software Development circles! But what does it really mean?
I don't think there is a single correct definition, but I can explain what it means to me and why just to give you another perspective. I have formed this opinion after reading and listening to many other people's opinions (such as Jergen Appelo) but reworded it so that it makes sense to me and helps me realize some actual benefits from the concept. Please feel free to leave comments if you agree or disagree because the reason for writing this up is to see if it resonates with other people or if you think I am way off track.
What? Happiness? Let me explain from a couple of different perspectives. If you don't feel like reading the whole text maybe just skim the "TL:DR" sections in italics to get the gist of what I am talking about.
TL:DR - Trying to be "Agile" may encourage us to rush into things and not think about longer term goals. Ensure that the client is going to be "happy" in the long run not just getting them short term happiness that may turn into unhappiness later.
I think where some definitions of "Agile" fall short is they elude to the fact you need to please the customer, but try to be too specific about the "software" aspect. For example definitions along the lines of "Agile means being able to implement changes and new features quickly without breaking things" don't really explain why that is important, or if it really is all the time. It is very specific to the quality of the code base - ways to achieve that are having high code coverage and robust software architecture following the SOLID principles for example. This is great, but it doesn't necessarily address any aspects of the Software Development Process or that particular project being "Agile", just the code base.
A common request from a client might be "I want this new feature in our app quick because our competitor is talking about introducing it soon". If you are blindly trying to be "Agile" you might throw that on the top of your backlog and work on it in the next sprint. This might make the customer temporarily "happy" because they feel like they will not be lagging behind, but they might lose sight of the bigger picture or other lost opportunities. If you have an agile process, it might involve taking the time to do it better than the competitor and making sure something else more important that will get longer term goals does not drop off the list, or blow out the budget. If your process can ensure that the best long term outcome may be achieved by not rushing into that feature request, and you can explain that to the customer, then they may end up still being happy in the short term, but also in the longer term. You may be "Awesomely Agile" according to my definition by doing nothing more than explaining a feature is a bad idea and not implementing it - if that makes the client happy and longer term keeps them happy then you are Agile! Yay!
Most projects start out new and exiting and people are generally happy to begin with - so it's only natural that things can go south from there since the bar is raised fairly high to begin with! Initially the team is probably burning through tasks and delivering a lot of benefit in a short time. Everyone on the project team is happy. Then things start to go off the rails. Maybe aspects of the process are not working well, clients are changing their mind and wasting effort or not communicating effectively. A very common one is that code starts to "smell" as we rush things and make changes so we quickly end up with a lot of technical debt. If nothing is done about this then even if the team can keep the client happy in the short term, it's unlikely that can continue for long.
Unhappy and unmotivated team members are far less likely to be productive, thus not able to implement changes as quickly, keep code quality as high or have great ideas to improve things. The very fact that "retrospectives" or similar concepts are encouraged in documented "Agile" methodologies makes this very obvious. I find generally everyone kind of knows this, but the real problem lies in the fact it's difficult to address it. I am sure you will agree it can be very difficult on any project to get time allocated to removing technical debt. This is generally a cost to the client for no perceived benefit (if you can't explain the benefits effectively). I am hoping a definition like the one described above can help people out with this. Basically we need to explain "in order to keep you happy and thus keep this project agile long term, we need to spend some time making sure the team is happy".
The purpose of being agile is not to win some sort of competition or think your Software Product is better than some other because it's "more agile". There is no value in comparing "agile" across Products or Teams. The only value in measuring the "agility" of a product is so that you can identify areas to improve it to make more stakeholders happier in a more timely fashion. If you can do this over time for a long period, then you would see a far better outcome than if you let things go off the rails and people are not happy.
Another perspective forgetting about clients and money etc is that all stakeholders involved in a project are generally spending time that they could be doing something else - maybe performing some other role or spending time with their family. We owe it to ourselves and each other to make sure working on software projects is an enjoyable experience so that we are not wasting our lives being unhappy at work!
http://teammetrics.apphb.com/
For the most part I am not really interested in "measuring" it, just knowing when things are starting to go off the rails so I can try to bring them back on. That can usually be done by talking to people and identifying any potential issues.
I don't think there is a single correct definition, but I can explain what it means to me and why just to give you another perspective. I have formed this opinion after reading and listening to many other people's opinions (such as Jergen Appelo) but reworded it so that it makes sense to me and helps me realize some actual benefits from the concept. Please feel free to leave comments if you agree or disagree because the reason for writing this up is to see if it resonates with other people or if you think I am way off track.
To me, if a Software Project is considered to be "agile" it means that all the stakeholders are happy and if they become unhappy, they are made happy again in a timely fashion.
nootn.com.au - 2016
What? Happiness? Let me explain from a couple of different perspectives. If you don't feel like reading the whole text maybe just skim the "TL:DR" sections in italics to get the gist of what I am talking about.
Customers/Clients/Product Owners/Project Managers *
*I will refer to all the types of people listed as just "client" for simplicity - it may be any or all of the above in your scenario.TL:DR - Trying to be "Agile" may encourage us to rush into things and not think about longer term goals. Ensure that the client is going to be "happy" in the long run not just getting them short term happiness that may turn into unhappiness later.
I think where some definitions of "Agile" fall short is they elude to the fact you need to please the customer, but try to be too specific about the "software" aspect. For example definitions along the lines of "Agile means being able to implement changes and new features quickly without breaking things" don't really explain why that is important, or if it really is all the time. It is very specific to the quality of the code base - ways to achieve that are having high code coverage and robust software architecture following the SOLID principles for example. This is great, but it doesn't necessarily address any aspects of the Software Development Process or that particular project being "Agile", just the code base.
A common request from a client might be "I want this new feature in our app quick because our competitor is talking about introducing it soon". If you are blindly trying to be "Agile" you might throw that on the top of your backlog and work on it in the next sprint. This might make the customer temporarily "happy" because they feel like they will not be lagging behind, but they might lose sight of the bigger picture or other lost opportunities. If you have an agile process, it might involve taking the time to do it better than the competitor and making sure something else more important that will get longer term goals does not drop off the list, or blow out the budget. If your process can ensure that the best long term outcome may be achieved by not rushing into that feature request, and you can explain that to the customer, then they may end up still being happy in the short term, but also in the longer term. You may be "Awesomely Agile" according to my definition by doing nothing more than explaining a feature is a bad idea and not implementing it - if that makes the client happy and longer term keeps them happy then you are Agile! Yay!
Product Team (Developers, Testers, BA's etc)
TL:DR - In order to achieve the objective above of keeping the Customers/Clients/Product Owners/Project Managers happy, the team should be happy and remain happy also. If they are unhappy, they are unlikely to be able to keep other stakeholders happy and may drag the project down to a point where it is longer able to be "Agile".Most projects start out new and exiting and people are generally happy to begin with - so it's only natural that things can go south from there since the bar is raised fairly high to begin with! Initially the team is probably burning through tasks and delivering a lot of benefit in a short time. Everyone on the project team is happy. Then things start to go off the rails. Maybe aspects of the process are not working well, clients are changing their mind and wasting effort or not communicating effectively. A very common one is that code starts to "smell" as we rush things and make changes so we quickly end up with a lot of technical debt. If nothing is done about this then even if the team can keep the client happy in the short term, it's unlikely that can continue for long.
Unhappy and unmotivated team members are far less likely to be productive, thus not able to implement changes as quickly, keep code quality as high or have great ideas to improve things. The very fact that "retrospectives" or similar concepts are encouraged in documented "Agile" methodologies makes this very obvious. I find generally everyone kind of knows this, but the real problem lies in the fact it's difficult to address it. I am sure you will agree it can be very difficult on any project to get time allocated to removing technical debt. This is generally a cost to the client for no perceived benefit (if you can't explain the benefits effectively). I am hoping a definition like the one described above can help people out with this. Basically we need to explain "in order to keep you happy and thus keep this project agile long term, we need to spend some time making sure the team is happy".
Why do we care about being Agile?
OK so you have read down to here.. or skipped if you got bored. Anyhow why do we care about this buzzword and all seem to want to aspire to what it seems to promise?The purpose of being agile is not to win some sort of competition or think your Software Product is better than some other because it's "more agile". There is no value in comparing "agile" across Products or Teams. The only value in measuring the "agility" of a product is so that you can identify areas to improve it to make more stakeholders happier in a more timely fashion. If you can do this over time for a long period, then you would see a far better outcome than if you let things go off the rails and people are not happy.
Another perspective forgetting about clients and money etc is that all stakeholders involved in a project are generally spending time that they could be doing something else - maybe performing some other role or spending time with their family. We owe it to ourselves and each other to make sure working on software projects is an enjoyable experience so that we are not wasting our lives being unhappy at work!
Measuring Agility
By the definition above, in order to try and measure how agile a project is, you are going to have to rely on qualitative measures that involve people's opinions. If anyone has a better way of doing this other than "survey's" then let me know! Here is one relevant survey I found that may be a good starting point:http://teammetrics.apphb.com/
For the most part I am not really interested in "measuring" it, just knowing when things are starting to go off the rails so I can try to bring them back on. That can usually be done by talking to people and identifying any potential issues.
Comments
Post a Comment