Tuesday, July 11, 2006

Problems with Agile

Ok, to start with I don't personally have problems with Agile. In fact Iove everything I've read about agile, however at my company we are having a lot of problems incorporating it into our department.

Issues.
  • SCRUMS (Daily Standups)
    • Our projects are not big enough to require multiple developers or iterations generally. Thus the developers almost never care about what the other developers are doing.
    • Our projects are not big enough to require multiple iterations, so our updates are really only to find out if there are any questions and if we will still be done during this 2 week iteration.
  • No gain in momentum
    • As much as I love working on a variety of projects I don't like the fact that if something hangs over, it just hangs over. I don't ever accomplish any more amount of work from iteration to iteration, because each iteration I'm starting over with having to understand a new process and start design again. This is not a problem in that it slows down everything, but it's dissapointing mentally to not be able to gain that momentum and make it look like I'm improving.
    • Management seems to want to push us to do more as if we are gaining momentum, but it's just not possible, in fact due to some recent turnover we not only are completing fewer stories (as would be expected with fewer developers), we are also taking longer on each one and having more hangover because we have lost a huge knowledge base and have to relearn things that we could easily ask someone in the past.
  • Deployment problems
    • It may be that the developers are now getting more things developed, but because of the additional layers of testing and sign-off added, we are not being able to deploy our solutions. Eithe we don't have enough BAs to handle the process, or we are not getting the buy-in from the client (our internal end users) that is required in an Agile world, to be able to move quickly.
    • After a story has sat in User Acceptance Testing for a while and is finally completed, the client feels that the application should be able to be deployed immediately. In another environment this may be the case. Where I work though, all of the deployments are to internal clients. At the same time our testing environment is not the exact same as our live environment. There is almost always some setting up and preparations that need to be made post UAT signoff and deployment. This adds to the time pressures that we have as well as to potential reduced client satisfaction.
  • Time pressures.
    • Yes time pressures always exist, but our time is booked pretty well with story card development and the standard meetings that we need to attend in order to continue the requirements gathering and estimation process for future story cards. This leaves very little time for bug fixes (thankfully this has not been much of an issue for me).
    • A deployment is not a hands off process here. We are involved in retesting the live deployment, verifying DB changes and any other setting changes are made correctly. We work with the clients to verify that the installs work correctly. None of this time is allocated for within our normal iteration.
  • Narratives
    • Our narratives never seem to be fully developed. We are constantly starting projects (with only a 2 week cycle) where we are still trying to gather requirements or understand what is being asked for.
    • Our narrative tells us exactly what to do and not why something is being requested. This has caused rework many times because the solution provided did not deliver what the client wanted.
    • There is a misunderstanding from our BA group in what they think the developers need and what the developrs think they need. I think this is due to the implementation process of Agile where I work. We took the group of people where were kind of good client contacts and put them into the roles of BA without giving them any training. Thus we have a group of BAs doing their best to get a job that they don't understand done.
  • Insufficient 'items' for developers
    • We did not get enough Agile training to start with. Bringing an Agile process into the department is a big process. It's not easy to implement and everyone has to understand what is required of them to make it work. Communication is a very big part of it and everyone needs to understand the high level of communication that they will need to be involved in.
    • We have application requests for technologies that not all of our developers are capable of accomplishing thus preventing some things from being played in the order that's actually most beneficial to the company. Having all of the developers able to do everything will prevent this, but we need to make sure that everyone knows all of the technologies.
    • Permissions. Not all of the developers have the same permissions. Thus when one person is no longer able to work on something, for being out sick or on vacation, not just anyone can pick up where he left off. We don't have the same permissions and must spend the next day or two getting permissions. Giving all the developers all the permissions that they need can make reduce this delay and prevent the frustration by all of the developers.
    • We do not have a test environment for some systems. That is just out of our control. However, most of the things that we do could have a test system. As a company more funds need to go into these test systems to allow a better testing and an easier transition from testing to deployment.
  • Lack of documentation
    • Not specifically an Agile problem, but a lack of documentation has been made more apparent with the agile process. One application may have 5 enhancments done by 5 different developers over 5 different iterations. The documentation for each of these enhancements is not being kept in a good central location for everyone to be able to understand what has been worked on in the past and what they may have to keep in mind with their own work.
    • A card is sometimes designed by one developer then developed by another. The desing of the card to the one who made the design makes sense because of the additional information that is gathered through conversation and stored in the mind. However the new developer picking up the card does not have any of this information and the design documentation becomes inadequate and leaves the same holes that have already had to be understood empty. Time is lost finding the same answer twice. Part of this could be reduced with better narratives, but even if the design documents were more accurate for everything that is known about the process then someone else could pick it up a lot easier.
    • Design reviews should catch this more often. If a design reviewer has to ask a single question, the question or the answer to the question should be added to the design documentation.
I have noticied a few positives that I would definitely like to point out.

  • SCRUMS
    • This is a place the a problem can be called out for everyone to know about.
    • This provides a place that help can easily be requested from fellow developers.
    • Personally I think these can be reduced. Questions should be emailed or called about immediately, we should not wait until the following day's stand up meeting.
  • Narratives
    • The narratives have been getting slightly better. A narrative coming from within IT instead of from Ops is a lot better, I hope the BAs can learn from all the additional amount of information that is given by an IT person that we need that amount of additional information from our clients.
    • Additional training for the BAs is still needed.
  • 'Items' for developers
    • Additional training is coming. It's hard to just up and train everyone at one time, so bringing everyone up to speed is a slow process that will probably take the next full year, which puts us a year and a half into our Agile expiriment. I think it will get better, but we have to weather the bad.
  • Documentation
    • We have a wiki and shared network drives that documentation can reside in. Both locations are accessible to all of the developers and can be uesd easily. Personally I prefer the wiki, because it's also more easily searchable and items can be cross linked easily.

No comments: