The agile approach to software development is prevalent in the majority of organizations. Agile software development reflects a shift of mindset by IT professionals, a new way of thinking. People working on, or supporting, agile teams must have this mindset. This mindset that is characterized by the following strategies:
Close collaboration within teams. Agilists recognize the importance of working together effectively with others and will act accordingly. They have the humility to respect and appreciate the views and abilities of others, without this humility they are unlikely to willingly choose to collaborate with other. A critical implication is that everyone is going to have to rethink the way that they work and be willing to change for the greater good. The attitude that “my group is the center of the universe and everyone has to conform to our vision and follow our process” doesn’t work well.
Regular collaboration across teams. Agilists actively seek to define an overall approach that everyone agrees to. My experience is that processes imposed from the top are very likely to fail because all it takes is one group to reject the process and “go rogue”. A better strategy is to organically grow a tailored WoW that reflects the needs of everyone involved. Because IT professionals are intelligent people with valuable skills you are likely to find that a collection of beliefs that everyone agrees to is often the most important part of an effective process. In the case of the Agile Data method this is the Agile Data ways of thinking (WoT).
Active communication. Effective communication and collaboration are critical to your success, and you are much more effective working with others than you are working alone. Because communication is a two way street you also need to listen as well as talk.
Cross-functional people. Agilists are generalizing specialists. The implication is that everyone needs to have a wide range of skills and be willing to work with others to improve upon existing skills and to learn new ones. Many professionals are narrowly specialized in one aspect of the overall process, but over time people can upgrade their skills if they choose to do so. People new to the IT industry will always need to start somewhere and will clearly need time to come up to speed.
Cross-functional teams. Agile teams strive to have enough people on the team whom together have the requisite skills to get the job done. Cross functional teams require fewer interactions with other teams, thereby reducing waste resulting from waiting, hand-offs, and hand-backs. This can be difficult to accomplish when people are overly specialized, but rather straightforward when people are cross-functional generalizing specialists.
Evolutionary way of working (WoW). Agilists work in an evolutionary manner that is iterative and incremental in nature. When you work iteratively you alternate between activities as needed. For example, today you may do some requirements exploration, some architecture work, some more requirements exploration, some testing, some design, some coding, some requirements, and so on. When you work incrementally you work in small batches. If you were building a data warehouse, for example, you might build a part of a table and deliver that into production because it’s needed by your end users right now. This is an agile strategy called vertical slicing where you build things in small increments of value to build up to a large thing of value.
Fit-for-purpose WoW. Agilists are also prepared to tailor their approach to meet the needs of the initiatives they are involved with. For example a team working on a data warehose may very well take a data-driven approach to development, using conceptual data models as the primary analysis artifact and physical data models as the primary design artifacts. A team working on a business system is very likely to take a different approach. No one development process fits all applications.
Sufficient artifacts. Agilists recognize that the creation and evolution of artifacts, including documetation, is a necessity in their jobs, although something they can still be very effective at. For example, enterprise architects recognize that the goal of enterprise modeling is to produce effective models that meet the needs of their audience, not to produce reams of documentation. They recognize that many traditional architecture efforts fail because developers are not willing to invest the time to wade through the documentation to learn the architecture. Application developers realize that system documentation is required to support future enhancement efforts and Agile data engineers realize that documentation is required that describes the data sources that they support. Agile software developers will take an agile approach to documentation and produce well-written and concise documents that is just barely good enough for the situation at hand.
Light process definitions. An interesting observation is that you likely need a lot less documentation describing how people should work together than you think. For example, consider the processes by which you obtain food. Clearly this is a very important part of your life because starving isn’t much fun, yet I doubt very highly that you have a detailed process written down about how you do it. Furthermore, I doubt that your local grocery store has written procedures that you must follow in order to purchase food from them even though this is also a process that is critical to their success because it’s hard to stay in business without any customers. Many aspects of software development can also be like this – once you have an agreed to process in place that everyone understands you can follow that process successfully. New people can get involved with and learn the process, I often see parents taking their children with them to the grocery store, just as I see new employees in IT departments. The process can evolve over time, my local grocery store started accepting debit cards a few years ago and everyone involved can adjust accordingly. Yes, software development is a lot harder than shopping, but the basic ideas hold. When there is a common vision in place, when people agree to and conform to that vision, and when people understand how to go about their part of the process then there is little need for detailed procedures (even if you had then people aren’t going to read it anyway).