Over the last few months I have been tossing this exact question around. I have been debating posting about it, and I have even talked with a couple people about it. But today, I saw this blog post on UTest that got my brain churning. The hesitation that I have had about posting this comes from a couple different thought points, but most of all I am not interested in creating some sort of development methodology war (you would not believe some of the flame wars I have seen just over naming conventions). I want to make sure that I expressed my paradigm, so my statements might be understood correctly.
· I have only worked in an Agile methodology for a few years, and in one organization.
· I am not a student of the Agile methodology so what I am seeing just might be a morphed version.
· My opinions are based on my experience. I would love to hear what you see with this methodology, and what your opinion is.
· I am an administrator by practice, I have done development, but not in this methodology.
· I am not in the same chain of command as the developers, although we do have a common VP.
What is it?
I debated even including this section, but I felt it fair for everyone to understand how I am seeing the processed used.
· Every 2 weeks is a Sprint.
· Each Sprint is preceded by a meeting where the group looks at the tasks, and determines how long a task might take, and how high of a priority it is. At that point they determine if the task is going to be included in that Sprint. People included in this are developers, management and a few other key players. The visibility is very transparent.
· Each day at the start of the day a stand up meeting is held. This is so the resources can talk about what is getting in the way of completing tasks and to update everyone on how well the task progression is going.
· If a task is going to take longer than 2 weeks, then it is broken up into pieces to fit in measurable smaller tasks.
· I believe anyone can add items to the task list. However, just because it is on a task list it does not mean that the task is going to get done.
My View of the Pros
I am really impressed by how fast the developers that work with this are. This group is an outstanding group of very talented developers. The amount of work that they are able to accomplish and the quality of the work is impressive for organizations twice the size. The process allows the developers to commit to an amount of time a task is going to complete, and I imagine that with the daily stand-up meetings, they don’t feel Micro-Managed. I have been in roles where each day managers want an accounting of how you spent each minute. For me, this is not a good way to be productive, so I see the daily stand-ups as a true positive. Developers have an input on the priority of tasks. So if there is a bug in an application, and it is not impacting anyone, they can make sure that the correct priority is set to the fix. My overall impression is that this puts a lot of control in the developer’s hands and I think this is also a good thing.
My View of the Cons
As an administrator, much of my job is getting ready for the future; this could mean that I am looking at information for 2 weeks down the road, or 2 years down the road. Tasks such as forecasting storage requirements, planning for future upgrades, outages and many other tasks of the like. The other aspect of DBA work is that I am a working on break fix issues, so normally I spend most of my time working issues today or down the road a bit.
· If there is a task which requires the assistance of a developer, and they are required to submit a task item for it, I have to wait until the next Sprint. This does not happen often, but it can happen.
· When a developer might need me for a task item, the time frame is also applied. This has never really become an issue, but it does go both ways. If I am in the middle of a big project and it is different than a project they are working on then we might not always be able to commit the same amount of time.
· One of my biggest concerns working in this methodology is the amount of time before new tasks are reviewed. If I take a new database design into consideration, there could be a bit of time that needs to be spent on evaluating if I use one method or another. The review method I decided to follow is to take a step back, look at the future plans as I understand them, test potential solutions and then execute on the decisions. Maybe it is just me and my personality, but I look at things from a long term perspective. It could just be the nature of my work in comparison to the nature of development work.
· Priorities are set based on what is most important at the time of planning. From first look, why would you not do it any differently? If you wait until everything is the top priority then isn’t that working in a re-active mode? For example:
o If you wait to quit smoking until the Doctor says you have COPD, then isn’t it a bit late?
o I have a son. He just finished his first year of college and is well on his way. When he was younger, and he would have a paper due then we would try to do a little each day, however as other school work would appear, or a friend’s birthday party would come up it was easy to prioritize the paper under something else. If it was not the pressing issue, it can be done a little later.
· I am not sure if this is related to the Agile method, or would be just as much of a concern with any shop. If, as a task submitter, I am not part of the planning meeting, then there is an impression that a “Sales” job needs to be done. Is this a drastic way to look at it? Sure – I guess, but end result is that with a number of people reviewing and prioritizing, then many people have to understand the importance of a what could be a pretty technical discussion.
Like I mentioned before, these are really just some thoughts, I wonder if they are just related to the implementation I have seen, or if others see these as well.
Pick just a few names out of the people that you want to meet, speakers or authors and even Microsoft guys and Gals. Force yourself to go shake their hand, I challenge you to not just go meet them, but tell them why they are on your list. There is so much work that goes into speaking, writing and well it is not very often that as a presenter, or as an author has the honor of knowing what we did to help individuals. I can tell you that the people who have shared with me how I helped them encourage me, and motivate me to do more. Tonight someone mentioned they went to a session I did a while back, and the applied what they had learned in one of my sessions and their salary increased because of it. The way he told me about it was, hey… you made me $14,000.00.
The more that I work with the tool, I am finding places where I can store personal information for my own use, or there is the ability to use a central repository where I can share connection information with other people that I am working with. The first question that comes to mind is how secure this is, but there is the ability to set default credentials and then over ride them for Individual users.
Chris Shaw's Weblog 