Requirements. It can be a dirty word. It can be a word of power and controversy. Projects and teams suffer when requirements are nonexistent, incomplete, inaccurate or tumescent. Creating acceptable requirements has but a few simple characteristics.
Simple ideas that often prove elusive and without them can lead to rehashing work done before, dissecting other implementations and guessing. To understand why achieving the 4C's is challenging, is to understand the origin. In any organization of girth, requirements are dove tailed together from a variety of often disparate sources:
Business (sales people, partners, executives, ...)
The weaving of information heavily contributes to unintentional violations in the 4C's. Violations not seen in smaller, nimble companies where individuals must wear several hats of responsibility, allowing vision and communication to be simplified, direct and focused.
Most ideas start out simplistic. The more the idea is considered, the more impacts are realized, holes in the initial intent are revealed and more people start getting involved. Soon the addition of features and other agendas causes bloat in the ideas scope. A simple idea such as adding a calendar to a web page turns into adding a CMS to administer an event and scheduling application. This is difficult to avoid, even if your a one-person show. Some people revolt at the idea of bloat and project scope creep, some embrace it. I believe the iterative mind does the latter.
Most people have heard of the KISS principal. There are a plethora of reasons for why keeping it simple can be difficult and why adhering to iteration then fails. Below is a short and incomplete list of reasons why iterating work can be feared and loathed:
Loosing the tail. The assumption is when a large project is iterated over, some of the low priority features will not get done (and we want it all). So if we iterate, not everyone will get what they want out of the project as features prioritized lower may never come to pass.
Iteration lengthens projects. The argument is that taking several months to plan, design, architect and build something all at once, results in less churn, planning and allows the project to be locked down and accurately estimated. Iterating a project will take longer because of the time to spin up and down the team to do iterations.
Iterations will result in less quality and product cohesion. If a project is done all at once, the product vision, direction and documentation will be better and lead to an improved result. Iterations allow for flexibility to change direction each cycle and that can lead to a project direction tug-o-war.
Lack of understanding why building software can be hard or time consuming. Keep in mind less technical team members will not always have a clear perspective into what work is a high level of effort or has prerequisite work involved. If coworkers don't have the full picture of what is involved to build software such as working with other teams, third parties or even pulling along legacy platform baggage it will create an understanding rift and ultimately distrust.
The pros to iterating are easier to understand. The primary reasons are boil down to:
Incremental course corrections. During the course of iterations, teams can change features, priorities and sometimes even longer term project road map goals. Altering scope is often hard or even implausible to do in a waterfall project since the team can spend hundreds of hours designing and writing technical documentation up front that would have to be reworked. By having a small, flexible team that works closely with it's constituents the final, long term product will be more accurate and useful (even if it wasn't what you started out to build).
Quick exposure. When teams iterate properly, they are supposed to implement and release the most important content and features early. If the Product Owner has done their job, the less important features and details will be in the tail end iterations.
Quality. The idea here is a close knit team will keep better track of the product changes all throughout development and everyone will take more pride and ownership in it.
Staying competitive and relevant. By getting features to market more frequently, media attention will be generated and product use can follow. Making users wait months or even years between product releases for features and bug fixes is becoming less and less acceptable to everyone from users, shareholders to marketing departments.
An interesting concept that the iterative mind brings to the table is promoting creative thought again. Something that has been stifled in many projects out of budgetary, time line or product complexity concerns. Iterating renews the possibility that any feature can be added to a product in any upcoming cycle, it gives creativity a new breath of life. Giving creativity a wide girth can be an amazing experience and open the door to leaps in productivity and team commitment. Not every idea will be implemented, of course, but once an idea has baked and becomes formalized into a workable story that gets some priority behind it, it is time to consider iteration and how to apply it.
Scrum is a methodology. No, wait. It is a framework. Maybe it is a process. At any rate, it is Agile. What is Agile? Is that XP, Lean or RUP? Ok, stop. I do not care for semantic games of process methods unless it helps employees get work done more efficiently. That is not to say Agile or formalized process methodologies are bad. In fact, for some companies it may be salvation. This blog entry is about thoughtful consideration of existing organizations processes and steps toward a better way.
Any organization of size will have many processes, probably too many. Most processes did not spring into existence. At some point a group of people in the organization communicated a problem to each other and agreed on a way to mitigate the problem by following a set of new procedures, documented or otherwise. The existence of each process filled a need. Perhaps the need no longer exists or has changed and the process needs to be re-evaluated but the point is there was thought and effort put into avoiding a problem to improve efficiency.
Many companies get bogged down over time by these processes. This could be a fundamental organizational structure issue or it could be a simple failure to reevaluate how people do work and why. When organizations start falling behind competitors, shareholders watch large efforts fail in the market or similar issues confront the executives in a company, the door opens to the process definition game. The push for process change generally is associated with desires to get products to market faster, be more agile, improve quality and communication. All honorable intentions but a frequent end result of sweeping, immediate process change is time wasted, money burned and opportunities lost. Companies can loose key people over redefining existing process, ultimately undermining the organizations ability to function at all.
Enter the concept of iteration. A pretty simple idea and likely the basic goal most executive teams and managers are trying to achieve. Something that can be achieved without turning organizations upside down and alienating employees. Iteration is a key component of any modern development process. What is often overlooked is iteration can frequently be applied to existing organizational processes. Changing the mindset of the people who define the work is a fundamental component. Becoming iterative can meet the companies goal or be a means to a larger plan. Either way, it can be applied with significantly less up front costs and chaos.
More on changing mindsets to iteration in my next post.
Here it is. Now I have a blog too. Just what the world needed, another blog. Maybe people will read it, maybe they won't. I'm not sure I care. Regardless, it is here. My motivation for writing it is purely selfish but I have an underlying hope others might get some use out of it. I am certain any blog I write will need a theme but I have been struggling with what that should be. Should it be a daily journal? Naw, that is a little fluffy for me. Should it be tech focused? That seems more reasonable given my profession and geek tendencies. Ok, so I know some tech stuff and that is a good place to start. What kind of tech stuff should I cover? Everyone rushes to talk about the new hardware and I am ill from hearing about the new iPhone no matter how much I want one myself. Should I focus on CSS or AJAX? I doubt it, that is done to death as well. After much self debate, it seems clear that I would get more out of this endeavor if I write about tech issues I face each day. I will avoid being limited to a specific technology and not have such breadth that readers will feel like it is another blog of someones random thoughts. So here it is.