Implement Agile Effectively!
Don’t have process for the sake of process! Make your process work for you!
Agile methodologies have been around for quite a while. Even after all these years, armed with multiple past experiences, it can still be difficult to transition a development group to use proper agile practices. Whether you are interested in making your current agile practices better, or you are starting to implement them from scratch, here are a couple suggestions that will make your life simpler.
First and most importantly, make sure the agile process you define works for you. If the process that you try to implement just makes it more difficult to get the job done, then it will not last. Teams will always default to the path of least resistance unless they see the value in doing something different. If they are not getting an equal amount of value or more from the agile process you implement, they will quickly start to subvert the very system designed to aid them. The Agile Manifesto itself is about individual interactions over processes. Too often, teams decide they want to go “pure” agile and simply make a process that is strict, inflexible, and more difficult to maintain than it is worth. For agile to get full acceptance by all members of your team, the key is to remain flexible and adjust the process so it works for you. Its practice should simply feel natural and non obstructive for everyone involved.
The next suggestion is just an extension of the first one. You have to look at converting your team incrementally. Just like agile promotes incremental improvements on software, it can be incrementally applied and tuned to improve your development process. If you are starting with a fresh team, like at a startup, this point is less important. Hopefully in that case, you’ll implement the proper processes from the beginning. However, when you finish each of your iterations, you should be looking at how your agile implementation might be adjusted during the next iteration. Businesses subscribed to this practice long before agile came along. Whenever there is a win or loss, successful businesses reflect on what can be learned and applied to the future. Agile is no different. At the end of each iteration, it is important that your team reflects on what went well and what could use improvement as you move forward. The focus should be on incrementally improving over a period of time, rather than simply changing your entire process all at once. This makes it easier for teams to transition when they have not been exposed to agile. Baby steps will ensure that your new process is fully adopted, ready to stand the test of time, and always able to adapt as your business changes.
I have implemented and improved agile processes several times throughout my career. From each experience, I have learned that no two implementations are alike. While it’s great to learn what the utopian dream of agile is, the implementation should not be taken literally. You have to remain flexible and remember that the best measure of progress is incremental improvement. Don’t expect to completely revamp your team’s process in a single day. Don’t expect to do it in a month. Your process should be something fluid that improves over time without end. There will always be some adjustment that needs to be made. A year from now, you will look back and notice that you have come a very long way. But even then, you will still have a ways to go! Good luck!
Page with Comments
Comments are closed.
Hi Rob, what’s your take on using paper scrum boards vs a tool like Jira? My current team uses index cards and a dry erase board but we have Jira available to us. I’m all about metrics so want to move towards Jira but one senior dev is set on using paper. Any recommendations?
Great question. It can be difficult to change some developers that have become used to working a certain way. Two things worth mentioning. First, we use TFS not Jira, but I am pretty sure they have very similar features. In TFS, we have a board view of the backlog that behaves exactly like what you are describing. There are swim lanes for New, Active, Resolved, and Closed and it allows developers as well as testers to move their user stories and tasks to the appropriate state with a simple drag and drop. The second thing I would mention is how you can approach this particular developer. He likely is not concerned with the fact that you care about the metrics, but if you can show him the value that it can add to his daily work routine, then you are not far from getting him on board. My developers leverage the metrics from TFS almost as much as I do. We use TFS to measure our team and individual velocity which leads to effective sprint planning where developers are given an appropriate work load. Has this senior dev ever bitten off more than he can chew because he was not aware of his current velocity and thought he could finish a big task in an unreasonable amount of time? I’m sure the answer is yes, and that is where Jira can help him in the future. It also helps you determine what amount of work will actually fit in a given release, preventing end of release death marches that kill developer moral. Once he understands how leveraging a system like Jira will help him personally on a daily basis, you likely won’t have to do anymore convincing. Good luck!