The Agile Attitude Part 2: Letting Go
For many of us in the IT industry, the popularity of Agile development has been a freeing experience. When an organization understands its role in Agile development and allows the team to self organize and come up with creative solutions, many of the stress and tensions that can be felt by the development team can melt away. This is because Agile processes allow development teams to do what they do best: develop software. The drivel that follows is advice for development teams on how to let go of some habits or preconceptions in order to better benefit from using an Agile development process.
Follow the Agile Process - it will make your life easier
One of my favorite things about Agile development is that it removes the burden of decision making from the development team. The team gets to provide facts to the decision maker (Product Owner) and then execute once a decision is made. There is no more need to hide problems or try to make up schedule time (although I'm sure that no IT professional has ever done such a thing). Developing software is what it is - unpredictable - and Agile development accounts for that through continuous planning. The best thing that a team can do is be as transparent as possible, help decision makers gather all the information that they need in order to make a decision and then sit back and wait for the next Sprint's marching orders. This allows the team to spend more time and energy on what they do really well - building good software.
Remember who owns the system
The majority of software developers out there are building a system for somebody else. Yes, there is a tremendous amount of pride and sweat equity that is built up when building any system, but we always need to keep in mind who it is for. Many times its not our system that we our building, its our customer's. Software developers get paid to develop software and thanks to Scrum, Product Owners now get paid to make decisions that directly shape the software. They get to make big decisions every month, and they should be making little decisions every day. So remember, what makes sense to you should be a starting point for implementation. Many times as developers we understand how our users think and can implement features in ways that are both elegant and intuitive - but not always. Sometimes we completely fail to grasp our customer's environment or needs and if left to our druthers would create a system that would completely miss the mark. This is the way of the past. The future (powered by Agile process) is to let our customer's be intimately involved with the software right from the beginning, and let them shape our actions so that the systems we build will be as useful as possible to their users.
Help Make Decisions
It may sound like I want to purge thought and creativity from the development team, but I really don't. The team is the Product Owner's biggest asset. The team should let the Product Owner understand the possibilities that technology can provide. We are responsible for keeping our Product Owners informed, providing suggestions, and laying out the pros and cons of various options so that they can make good decisions. There is nothing more beautiful in software development than a well oiled development team that has an intimate relationship with its Product Owner. With ideas flying all over the place, creativity and experience can come together to create game changing software that really adds value on top of the regular automation of business processes that we have learned to do so well over the past 10 - 20 years. Just remember, ultimately it is the Product Owner who is responsible for the return on investment for the system, and when it is all said and done, they have final say for implementation.
Don't fight the process
Agile requires a different way of thinking than many IT professionals are used to. Agile development asks us to give up some control over the process for building software. For many, this change can be hard to swallow, especially when we are asked to do things that we don't agree with, be it adding a particular feature or changing the layout of the UI. In these cases, feel free to voice your opposition, but remember your role. System design and implementation is your thing. Deciding what to do and when is up to your Product Owner. You will likely have very good input on these matters, and if you voice your opinion respectfully (not forcefully) in time your Product Owner will come to trust and depend on your sage advice. Allow the iterative nature of the Agile process to work to your advantage. If your Product Owner fails to follow your advice and makes a bad decision, it will be brought to light rather quickly. Its OK to cut them some slack. One thing that as developers we love about Agile is that it tells us that we don't always need to have all of the answers. I think its reasonable that we don't expect our Product Owners to always have all of the right answers either.
Let me sum up
Agile development isn't easy. Bridging the gap between the business side of an organization and the IT side of an organization is extremely hard. As software developers, by giving up a little bit of control and not giving in to our egos always telling us we have the right answer, it will be easier to benefit from all of the wonderful joys that Agile Development has to offer.
Follow the Agile Process - it will make your life easier
One of my favorite things about Agile development is that it removes the burden of decision making from the development team. The team gets to provide facts to the decision maker (Product Owner) and then execute once a decision is made. There is no more need to hide problems or try to make up schedule time (although I'm sure that no IT professional has ever done such a thing). Developing software is what it is - unpredictable - and Agile development accounts for that through continuous planning. The best thing that a team can do is be as transparent as possible, help decision makers gather all the information that they need in order to make a decision and then sit back and wait for the next Sprint's marching orders. This allows the team to spend more time and energy on what they do really well - building good software.
Remember who owns the system
The majority of software developers out there are building a system for somebody else. Yes, there is a tremendous amount of pride and sweat equity that is built up when building any system, but we always need to keep in mind who it is for. Many times its not our system that we our building, its our customer's. Software developers get paid to develop software and thanks to Scrum, Product Owners now get paid to make decisions that directly shape the software. They get to make big decisions every month, and they should be making little decisions every day. So remember, what makes sense to you should be a starting point for implementation. Many times as developers we understand how our users think and can implement features in ways that are both elegant and intuitive - but not always. Sometimes we completely fail to grasp our customer's environment or needs and if left to our druthers would create a system that would completely miss the mark. This is the way of the past. The future (powered by Agile process) is to let our customer's be intimately involved with the software right from the beginning, and let them shape our actions so that the systems we build will be as useful as possible to their users.
Help Make Decisions
It may sound like I want to purge thought and creativity from the development team, but I really don't. The team is the Product Owner's biggest asset. The team should let the Product Owner understand the possibilities that technology can provide. We are responsible for keeping our Product Owners informed, providing suggestions, and laying out the pros and cons of various options so that they can make good decisions. There is nothing more beautiful in software development than a well oiled development team that has an intimate relationship with its Product Owner. With ideas flying all over the place, creativity and experience can come together to create game changing software that really adds value on top of the regular automation of business processes that we have learned to do so well over the past 10 - 20 years. Just remember, ultimately it is the Product Owner who is responsible for the return on investment for the system, and when it is all said and done, they have final say for implementation.
Don't fight the process
Agile requires a different way of thinking than many IT professionals are used to. Agile development asks us to give up some control over the process for building software. For many, this change can be hard to swallow, especially when we are asked to do things that we don't agree with, be it adding a particular feature or changing the layout of the UI. In these cases, feel free to voice your opposition, but remember your role. System design and implementation is your thing. Deciding what to do and when is up to your Product Owner. You will likely have very good input on these matters, and if you voice your opinion respectfully (not forcefully) in time your Product Owner will come to trust and depend on your sage advice. Allow the iterative nature of the Agile process to work to your advantage. If your Product Owner fails to follow your advice and makes a bad decision, it will be brought to light rather quickly. Its OK to cut them some slack. One thing that as developers we love about Agile is that it tells us that we don't always need to have all of the answers. I think its reasonable that we don't expect our Product Owners to always have all of the right answers either.
Let me sum up
Agile development isn't easy. Bridging the gap between the business side of an organization and the IT side of an organization is extremely hard. As software developers, by giving up a little bit of control and not giving in to our egos always telling us we have the right answer, it will be easier to benefit from all of the wonderful joys that Agile Development has to offer.
0 TrackBacks
Listed below are links to blogs that reference this entry: The Agile Attitude Part 2: Letting Go.
TrackBack URL for this entry: http://www.nearinfinity.com/mt/mt-tb.cgi/1565
Leave a comment