Agile Mindset: What is the Agile Software Development Mindset?
The agile approach to software development, including the agile mindset, is prevalent in the majority of organizations. Agile software development reflects a shift of mindset, a new way of thinking (WoT), compared with traditional. People working on, or supporting, agile teams must adopt this mindset to be successful. The following characteristic capture the agile mindset:
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 such humility they are unlikely to willingly choose to collaborate with other. A critical implication is that everyone must rethink the way that they work and be willing to change for the greater good. The attitude that “my group is primary and everyone has to conform to our vision and follow our process” doesn’t work.
Regular collaboration across teams. Agilists actively seek to define an overall approach that everyone agrees to. Processes imposed from the top fail as 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. You will find that a collection of shared beliefs 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. ,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 learn new ones. Many professionals are narrowly specialized in one aspect of the overall process, but over time they must upgrade their skills. And yes, eople 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 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. When people are overly specialized this is difficult to accomplish, but 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. Today you may do some requirements exploration, some architecture work, some more requirements exploration, some testing, some design, some coding, and so on. When you work incrementally you work in small batches. Whenvbuilding a data warehouse, for example, you might build a part of a table and deliver that into production because it’s needed right now. This is called vertical slicing – small increments of value, the slices, build up to a large thing of value.
Fit-for-purpose WoW. Agilists tailor their approach to meet the needs of the initiatives they are involved with. For example a team working on a data warehouse may very well take a data-intensive approach to development 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 documentation, is a necessity in their jobs. They choose to be effective at it, rather than merely suffer through it. 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. Many traditional architecture efforts fail because developers are not willing to invest the time to wade through architecture documentation. System documentation is required to support future enhancement of application code and evolution of the data schema. Agile software developers take an agile approach to documentation and produce well-written and concise documents that are just barely good enough for their context.
Light process definitions. An interesting observation is that you need 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. Many aspects of software development are 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 stopped accepting cheques years ago and everyone involved adjusted 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. Interestingly, even if you had them people aren’t going to read it anyway.
