Empirical Team Thinking
Agile development is now commonly referred to as those set of methods that come under the umbrella term agile or support agile thinking. To avoid a circular set of definitions we will define the word agile.
Agile is being quick enough to avoid or take advantage of those things that can hurt or help in your pursuit.
A pursuit in this context would often be called an effort, work or project. However, notice the phrase “quick enough” why is that wording used and relevant. The biggest difference here and said in a very summarized way (which does not reveal the depth of thought behind it) is the difference between predictive thinking vs. adaptive thinking.
No matter who you are and what you do we will all fall prey to predictive thinking in varying degrees. To reduce the likely hood of being tripped up by predictive thinking agile frames a state of mind that leverages those around us to help us detect when we are being predictive and should be adjusting our plan based on new information rather than ignore it. Said another way is that we fail to detect/ignore when our assumption are no longer valid. So, agile is a social agreement to be empirical as a team. Agile development is a description of how we can put that framework to use as a well formed team. A framework for agile development is especially important as the complexity of our effort increases. For simple problems or things that are complicated but knowable a standardized process is suitable. For complex problems that can change just by looking at them we need an empirical framework.
Spectrum of Agile Methods
There are several Agile methods which support an Agile Development process. However, each one is best called a framework because it is applied in a unique way for each context of use.
The above diagram represents the best way we have seen to describe the agile development methods available. The ones on the right are more Bodies of Knowledge and are vast. It is their very nature of vast that can cripple a team of people trying to focus their effort. Typically large systematized thought models can become more than I want to think about and crowd out the purpose for me focus which is my effort/work/project or product that I am trying to build.
There are more such as TSP / PSP but, this model paints out a quick spectrum that summarizes the models of thought and those that sit on the boarder such as RUP. The bodies of knowledge on the right have some very good practices, processes and methods in them and should not be ignored just because they are vast. Often when you scale past 70 or so people on one project effort you will need many of the techniques that can be found in the bodies of knowledge on the right. Or if you are simple running a call center where things are complicated but, knowable and creativity for transcending the current established patterns is not desired then they are more appropriate. We would call this things that fit SOP (standard operating procedures). However, were creativity is desired and the problem is complex then the models that support agile thinking are the only ones that seem to work.
Scrum is by far the most popular of the agile models and has shown some of the best success and transaction because it is not vast. Scrum is a simple rational framework that can be memorized in 20 minutes. Applied Scrum is exceedingly difficult to do well because it requires a tremendous amount of discipline and challenges standing assumptions. The ability to reveal and challenge standing assumptions is what has made Scrum so successful. Scrum has proven itself beyond the realm of software development (form where it orginated) however, its language and purely rational approach are its weaknesses.
A quick list of agile methods
- Scrum
- FDD
- Lean
- XP
- Crystal
- Kanban
- Other often proprietary Special forms…
When doing software development work a popular pattern is to use the Scrum method wrapper the XP coding practices. This is recomended and has been found to be one of the best patterns for success.
Transitioning to an agile thinking process is best done by building Agile Pathways that supports and nurtures a pattern of adoption. It is important when applying agile to not toss out established processes that work but, instead reveal how they can be improved and reinvigorated. However, a solid implementation requires an almost prescriptive start. There are too many hidden assumptions that need to be re-explored and often changed.
- Some short phrases that help focus on agile thinking
- Let the product lead
- One bite at a time
- No head works alone
- Be empirical
- Reflect early and often
- Make it visible
- Pay attention and adapt
The agile movement got it start in the public sector in 2001 with the signing of the Agile Manifesto. The first project done under the term agility and done with 1 week development cycles was in 1983 (more on this later).
For those new to agile, Scrum is a recommended place to start.
In all cases of applied agility or scrum the analysis sets the tone. Without agility in the analysis the remaining part of your effort will “waterfall” or fall prey to predictive thinking. The following set of techniques assumes a complex problem or situation. Analysis is looking for an opportunity to move. There are a few analytic techniques that show up
- No head works alone: peer review your thought process with someone and avoid heavy process driven peer review
- Don’t make a belief out of a model: use a data rich subject matter orientation so that you don’t try to overly tidy your thinking at the wrong time
- Highlight areas of risk and uncertainty: the number one risk is building the wrong thing! adjust your analysis to mitigate that risk first
- Conceptualize appropriately through time: watch which techniques you are thinking with when you move from past certainty to future uncertainty (i.e. accounting vs. finance)
Stories are the Fundamental unit of work in an agile project, which “describes some item of value to a user or product owner”. Stories are units of value that and are visible and understandable outside the team. Stories can describe functional scenarios, interactions, UI screen, and non functional requirements.
