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 DBAs 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).
Related Resources
