There continues to be all kinds of messages about Agile. My assessment is that there is both a rejection of Agile and an effort to reestablish it more closely with its original guidance and aspirations. As a result, the message is close to this.
Agile is dead. Long live Agile.
The messages read to me like large efforts tearing down the unscalable wall of “Agile” and rebuilding “Agile” by piecing together a new unscalable wall. You can see this in “Long live Agile” translates to “Long live Agile the way we have (re)defined it.”
To be frank, “Agile” has asked a lot from us. I am not saying that the original guidance and aspirations have done so. Rather, we have been inundated with many interpretations of Agile, including a lot of procedures, rules, and regulations, which include obtaining certifications around the packaging. The spirit of Agile is not found in procedures, rules, and regulations. The complexity is significant. The interpretations clash. Who should we listen to? When complexity leads to failure in a context, those with different interpretations blame the interpretations previously employed. The cycle continues.
When fulfilling some preset number of steps in some perceived priority order becomes more important than the spirit of using the approach to deliver value, it’s not going to end well. Like I have said many times before:
We are standing up at 10:00am. It must be Agile.
That’s not Agile in the same way that learning the steps to the tango doesn’t make you a dancer. A standup is just procedure unless the spirit of why the standup is happening is realized. It may make managers or some Scrum Masters feel good that you are standing up, but in themselves, following procedures, such as having a morning standup, doesn’t help you deliver better software faster.
Get More From Agile Than Agile Takes From You
If you don’t get just a few things right you are never going to achieve what Agile is meant to help you accomplish, because you will likely be giving more to Agile than you are receiving from it. Try the following before you do anything else.
1. Identify goals
2. Define short iterations and implement
3. Deploy increments when legit value is achieved
4. Review the outcome, record debt, goto 1
There are certainly details in each of these steps, so I don’t mean to over simplify. Still, if you can’t be successful applying these four steps in the simplest possible way, how will you ever be successful applying a large number of rules and regulations as add ons? Certification can’t help you. And scaling Agile across multiple teams or a large enterprise? Not a chance.
I will explain a few of the above points with a bit more detail, but I will purposely avoid making this seem like procedures. Everything that you do, every tool that you employ, should reflect the flexibility that Agile affords. If you are going to make a single “rule” then you must be inflexible here.
Agile is flexible. Everything that you do, every tool that you employ, should reflect the flexibility that Agile affords. Be flexible.
Neat, right? Being inflexible about being flexible is the one rule. This one rule around four steps is pretty much all you need. The rest is wasting your time and energy, which are not commodities. Said another way,
Being inflexible about procedures, rules, and regulations is not Agile. Refuse to be inflexible even though others will try to enforce procedures, rules, and regulations.
I will give you an example of what not to do. Some people want a formula around which Agile tools to use at any given step, and with clear direction on the order in which the tools should be used. So, if you have the following tools to help you discover your goals (#1 above), what’s the “right way”?
- Conversations and collaboration with people
- Whiteboard drawings and diagrams
- Writing scenarios
- Mining for more knowledge
- Experiments with code
- Impact mapping
- Event Storming
So, what is the correct order? Other than “conversations and collaboration with people” and “mining for more knowledge,” there should be no certain order other than the order in which spontaneous and serendipitous learning leads you. Note that there are no numbers that might indicate priority. In reality, two tools are wrappers around the others.
- Conversations and collaboration with people; Mining for more knowledge
- Writing scenarios
- Impact mapping
- Event Storming
- Whiteboard drawings and diagrams
- Experiments with code
Wrapping the other tools means that even in step #1 above, there are iterations and increments. In other words, learning is iterative and incremental. Use any and all tools at your disposal, including those not mentioned here, to learn in an iterative and incremental way.
The previous diagram illustrates how this can work. Conversations and collaboration along with work to acquire more knowledge call for the use of Agile modeling tools. It is the conversations and collaboration that drive the need for more knowledge, and the need for knowledge requires the use of discovery and learning tools, which lead to more conversations and collaboration. The learning is iterative and incremental.
1. Identify Goals
What are “goals,” and how do we “identify” them? Goals are larger than individual work tasks. They include finding the impacts that your software must make on users. These are the kinds of impacts that change their behaviors in positive ways. These impacts are recognized by users as what they need, but before they even realized their need.
The business must be engaged to the extent that they help developers drive out the business impacts that must occur to change peoples’ behaviors for the better. If not, it doesn’t matter how much work you identify for iterative and incremental development. The impacts made won’t be purposeful and certain, and thus may be far different from what is critical to the business.
From the essential business impacts identified, then work can be identified. Knowing what work is needed leads to step 2.
2. Define short iterations and implement
Since we are defining short iterations, consider the definition of iteration.
iteration: a procedure in which repetition of a sequence of operations yields results successively closer to a desired result
The iterations are repeated and lead successively toward a desired result. Our human brains can’t deal with a lot of scope. We can maintain a focus on 5 to 7 things, or at least remember them. Yet, given project pressures, unavoidable interruptions, and other distractions, including the end of day and week, we should limit our work items to a number that we can readily remember and grasp.
If your team has 3-5 developers, each developer may be able to work on one or two tasks per day, and possibly more, hopefully resulting in deliverable value. Limit work tasks to those that can be achieved within a day, or two if necessary. Iterate quickly. By quickly, I mean within several minutes or a few hours. Long iterations, such as those that require a day, days, or even weeks, is too long to feel achievement and discern recognizable value.
Your team should feel your way forward as experimenters. Maintaining an experimentation viewpoint means that you are not afraid to experience failure and learn toward more valuable deliverables. Failure is best when it happens rather quickly, within minutes, a few hours, or at most a few days. You sense and learn and adjust.
3. Deploy increments when legit value is achieved
Consider another definition, this time of increment.
increment: the action or process of increasing especially in quantity or value; something gained or added; the amount or degree by which something changes
If delivery of value is not possible by means of one day’s work, then at least an increment toward value can been reached. You should be able to string together one or two additional days of iterations and reach value delivery.
Deploy and observe.
4. Review the outcome, record debt, goto 1
Has the increment achieved an intended and vital impact? If not, you may need to shift toward another set of iterations with increments of different value. If so, note what your team sees as reasons for success.
Even when you have reached delivery of some critical value, it is normal that your incremental results don’t leave you feeling entirely successful. This is often because as we implement we learn more and achieve a clearer understanding of our problem space. Even so, we are time boxed, and we won’t have the opportunity to immediately remodel or refactor our current results. Record it as debt. You can address it in the next iterations and increment if it is urgent enough to do so. This is the mindset that experimentation affords, and what Agile is all about. If you have planned too far ahead you will experience conflict and probably fail to care for the debt sooner than later. It may even be forgotten and never improved.
Whether or not you have achieved a critical impact, return to #1 now. It’s time to identify more goals, or at least which work tasks will take you nearer to goals already identified.
Conclusion
Until you learn to dance the Agile dance, the four steps above are all you should attempt. Actually, try hard to forget the steps and just do Agile as a flow. As time passes and you become more comfortable, the steps will blend and the lines will blur. When Agile is experienced existentially [1] then you are Agile.
[1] existential as in empirical; relying on experience or observation alone often without due regard for system and theory
