Ruminations of a Prima Donna
By Travis Bailey on Tuesday, February 13th, 2007Developers are classically referred to as prima donnas. We are a needy bunch that left unchecked can cause a number of ailments. But, is this characterization really limited to Developers? I find that everyone channels their inner “prima donna” to some degree. This means they want some level of influence, interaction, visibility into the processes that are important to them. We dislike inconvenience and treasure being free to express our ingenuity and cleverness!
This isn’t really an unrealistic expectation, is it? I mean… clients pay us a lot of money to develop systems for them. If it is my pocket book shelling out dough, you’re damned-straight I want to be involved, and know how my money is being utilized… sooner, rather than later. The system designers, whether BA, IA, PM, QA (or other acronym), want to feel pride that they are significant to the success of a project. Quite frankly, the effects of group collaboration on idea generation is extremely effective.
However, the point is that this process operates most efficiently when it is completely transparent. Transparency - a simple word. But a powerful concept that applies to everything from Sarbanes-Oxley to my physician’s visit. It boils down to trust and honesty; because you MUST give visibility to everyone involve.
Enter stage left, Agile processes. Agile shares a lot with the somewhat illusive web 2.0 moniker. The point of both is to make the processes more transparent, collaborative, and organic. We employ a variety of Agile called Scrum. I really hate cheesy processes and the silly names they use. Scrum is no exception. I has its own names, including ScrumMaster, Sprints and Retrospective; generally based on the English Rugby sport. It elicits smirks and giggles nonetheless. Lot’s of humor on the web:
YouTube: High Moon Studios: A Portrait - Scrum
YouTube: Scrum Masters 2
It’s all funny and insightful in its own right, but I take it seriously from the conceptual level. How I look at it, most fail to realize that Agile isn’t about providing good solutions faster as much as it is about engaging the customer to provide the correct solution for their needs. The point is “customer engagement and satisfaction”. The most efficient way to achieve this goal is to involve the customer as much as possible throughout the development lifecycle. It is integral that they are available to clarify, elaborate, and prioritize the features and designs they want from the feedback we give them.
As a manager of “prima donnas”, I want to empower my developers to deliver the best product they can currently conceive that meets the customer’s expectations. To me, this means that I need to put the developer as close to the customer as possible. Agile development processes and tools generally answer this need.
The basic premise is to start with “what you know” develop with “refactorable” techniques in “small iterations” and “solicit customer feedback” often. There are a lot of concepts in that small sentence. “What you know” implies that we don’t belabor the requirements since it’s hard for the customer to truly visualize what they want in its entirety. “Refactorable” implies that we are going to develop in such a way that change isn’t hard. “Small iterations” and “solicit customer feedback” imply that we want the customer to be an active participant in the software we develop. Plain and simple, we know software is expensive and we want to bet on the best system to ensure that your money buys what you need now, and can easily grow to what you need tomorrow.
We utilize tools like XPlanner, Basecamp, and MediaWiki to engage our customers, while enabling our developers to use the best tools to deliver the best product to our clients.
Thanks for presenting a clear picture of Agile development.
Good luck to you and Danny!
Good explanation.
I think these approaches are all good on paper, but don’t always take into consideration the human elements and client/vendor dynamics of real projects.
For various reasons, I think it is almost impossible to have a completely transparent development process where you throw the client in the room with the BAs, IAs, Creatives, PM, and Devs and go at it.
Firstly, I haven’t met too many developers that want to be working directly with the client.
Secondly, they speak different languages (clients and developers) and it’s not always good to try to get them to communicate with one another.
Clients also tend to have issues that aren’t necessary to creating a better product (i.e. in any client meeting, only so much time is actually spent ‘on topic’). As a business, you want the developers to focus and build a great system, and be protected from a lot of the client issues that can arise. It is good to have other people involved then that can take it all in, distill it, and present it to the development team appropriately.
Also, there are definitely things that arise throughout development that you do not want to be transparent to the client. Things go wrong sometimes. It’s inevitable.
All that said, I fully understand the need to get the technology represented earlier in the dev process. There is no reason to wait until requirements are spell-checked and beautified before developers, creatives, or architects are involved (as waterfall processes would dictate in many cases).
But I also think the constructs of Agile go too far to the other extreme. There needs to be early involvement, but there also needs to be separation.
Has anyone tried a hybrid approach where the roles stay the same (PM, BA, IA, Creative, dev, etc.), but the full-team involvement happens earlier in the process?
I have worked in orgs where that was being discussed, but I’m not aware of any where it has actually been put into practice.
TS, I agree that customers and dev often do not speak the same language… but I could say the same about creative and user experience.
Generally every group has to educate, in some capacity, the customer as to why certain recommendations are made.
As far as hybrid approach, I have experienced techniques where BA/IA works ahead of Dev/Creative/QA by an iteration or two because of the coordination issues. This, in essence, starts to draw away from the prescribed Agile methodology. We are experimenting which just such a technique on one of our current projects and would be happy to share how it turns out.
Customers are varied and I am not saying that the process will work purely as defined by Scrum for everyone… but that is also part of the process. To change the process itself to be most effective for the situation. Agile processes embrace change. By doing so, it will naturally be able to deflect the bad and focus on the good.
I look forward to contributing more as we go!