Agile project methodologies espouse the benefits of fluid communications among all project team members, team members are empowered to self-organize and make decisions, emphasize prioritizing project features that should result in the highest business value, organize work plans in a time-boxed sprint of two weeks or so of focused teamwork, hold frequent reviews of completed work with all stakeholders to get timely feedback on the success of meeting the business vision, forgo up-front full requirements and design documentation in favor of just-in-time design specifications, and place far less emphasis on total project cost estimations and time tracking. And, if you are doing scrum, the vestigial IT team roles of business analyst and project manager can be effectively morphed into the product owner and scrum master roles.
To me personally, the agile scrum process seems like a much more organic and highly collaborative approach, as it diminishes the roles of the information gatekeepers by enabling the IT architects, developers, and designers (we’re not building kitchen cabinets here) to gain firsthand knowledge directly from our customers to determine just what it is we are being asked to “create” for them. This makes far more efficient use of everyone’s time, results in noticeably reduced timelines, and facilitates the production of higher quality output that provides the greatest business value.
Have you ever worked for a large organization? If so, then you know you have many hurdles and bureaucracies to deal with whenever you need to get anything done. Regardless of the size of your organization, you face these on some scale whenever you need to do cross-functional teamwork tasks.
What about within your own team? Do you receive a timely flow of information and access to the business decision makers so that you can make the right choices in your analysis and design work in an agile fashion? Or do you have to wait for the business relationship managers, business analysts, and project managers (wait just a minute, what happened to the agile product owners and scrum masters?) to complete their weeks and months of contextually rich meetings with the business stakeholders before they finally decide when the time is right to give you their “highly-detailed” four-page requirements document? Ahem, how about that impressive stream of timely information flow, huh? What about the cost of lost opportunities for just-in-time assimilation of business domain knowledge? As a software engineer, developer, designer, are you blocked from communicating directly with project business representatives and decision makers? Obviously, this separation of business personnel from IT personnel must be enforced at all times, because as a software engineer, developer, designer, you must have spent most of your high school years stuffed in a locker without any means to communicate with normal human beings and develop suitable social skills, right? Pfft!
As a senior software engineer, architect, and web design professional, I have had to reinvent myself non-stop for many years to stay effective and relevant in my profession. I suggest that our business analysts, project managers, business relationship managers, and other information gatekeepers, do their part to step up and adapt to this important change in how we should be doing business if we are to survive as a whole.
I eagerly await our “Agile Transformation”, as I have many years of experience and knowledge that I wish to share with my business friends and coworkers. I constantly seek fresh ideas and I have a great desire to add intrapreneurial value to potential problem analysis and solution conversations. I fervently wish to reduce the time required to ferret out the true business needs and to acquire timely answers to technical and analytical questions. Ultimately I wish to speed up our ability to deliver new business features and increase the business value of our service offerings to our customers.
Whew! That was cathartic for me. I hope it was not personally career limiting to speak my mind. 😉