Skip to main content

Being Agile

In the past 20 years, I have seen our ITS department develop systems that were never used.

Maybe the stakeholder opened it once, tried it, said, “Nope,” and it just went to the annals of forgotten systems. The developers thought they knew what the users wanted – turns out, they sometimes didn’t.

I have also seen systems rejected when first developed then after a learning period users claimed they could not live without. These were our success stories! However, whether a project would be a success or not was often up in the air and never predetermined.

Three business analyst positions in 2015 were created to try to avoid the first scenario. We had little idea of what we were doing. I came from a tech support/teaching background while my two cohorts came from a developer background. One thing our leaders all agreed on was that we were “people” people.

We went to a few classes, took a few webinars, and googled a lot. We quickly learned that while these activities could help us build our business analysis foundation, there was no class or series of classes targeted at our education needs. Our higher education organization focus was on a medical school and health science center.

So, we dove in head first and started figuring things out ourselves. We learned how to schedule a meeting of a large group of people, many who were not yet vested in the project. We learned how to stop talking and start listening. We spent countless hours trying to get to the very essence of what users wanted in a system. We learned how to draw up a SIPOC, create process maps, and document user requirements. We even fought an internal battle against developers who questioned aloud whether our existence was necessary. Fortunately, our executive director assured us we were instrumental in helping solve the campus’ computing issues.

We decided to use the waterfall methodology. Conception, initiation, analysis, design, construction, testing, production/implementation, and maintenance – ah, sweet maintenance – was the path for us. We now felt armed with a plan for projects. No more time wasted delivering useless systems that weren’t well thought out.

We noticed our most successful project was different. We met weekly with several users, got their thoughts, and the developer, who attended the meetings, went back and update the system with their requests. After only a few months of this, we delivered a system that cut our users process time from two weeks to two hours.

I thought the success of this project was based on customer engagement and in part, it was. However, we soon realized it was our different approach to this project that sped it along. We cut away a lot of the fat and got to the meat of the problem.

After other projects had begun to drag on, we realized we had pages and pages of user requirements and process maps, but the amount of time we were taking to gather all this caused customer interest to waning. We also weren’t sure if all this paperwork we had contained anything of substance to turn over to the developers.

Our team lead suggested the agile methodology. Remembering that highly success project, I realized that, even though I did not realize it at the time, that was agile and I was on board.

Switching was not without its own pain. I had spent an enormous amount of time on a project using the waterfall methodology – the user requirements were complete and signed. “I am done,” I thought. Then the team lead wanted me to get user stories.

Something strange happened. I drew up user stories (since we had been meeting for so long, I felt I knew what they wanted exactly), but when we met with the users, a new idea came out. Things I thought I knew for sure were scrapped.

While it took a year of meetings to get the user requirements hashed out, the user stories only took three meetings. I turned them over to the team lead, and he was pleased with the results. I began to see the light at the end of the tunnel.

We are still new to Agile, and I am sure we are going to make mistakes. However, we continue to learn and grow from our mistakes and the more we do that, the more tools we will have to help our users meet their end goals.

At the end of the day, that is all we need.