Wednesday, July 02, 2014

Agile Principles - Working Together

Business people and developers must work
together daily throughout the project.

One of the challenges I often face when I start working with a new client that has not been following agile is the amount of time expected from their business people. Their approach has always been that the business people meet with business analyst (BA), tell them what they want, and come back 9 months later to see what got built. 

I have to explain that agile doesn’t work this way and that in order to be successful, we want to have access to the business throughout the project. I find myself providing guidance on how much of business team's time we may need on a daily or weekly basis. 

The real problem with the first (waterfall) approach is that when asked, the business people may not know what they really want. They may be able to come up with a list of things they think they want, but if everything gets built, you will most likely have a lot of features that never get used.

Users will know what they want when they see it. So by starting out with what’s most important to the user, building something to show them, the users can target in on what they really need.

There’s another factor at work here. Studies have shown that a lot of knowledge is lost as it’s handed over from one group to another. So if a BA talks to an end user, creates a requirements document, and hands that to an architect, that architect is going to be missing some of the information the BA learned. When the architect hands it over to a developer, more information is lost. It’s only when all the silos are removed and the developer talks directly to the business person that they get the whole picture. They may hear something that a BA or architect didn’t think was important enough to document that is important. 

This all takes time, which is why a successful agile project follows the principle of the business and IT working together on a daily basis. It is through the interactions that happen on this frequency that help the team know what to really build.

No comments: