The Agile Mindset
It is important to think of Agile as a "Mindset"; a way of thinking/being/doing...
Agile is so much more than a methodology, and vastly different than simply an approach or tool.
It defines HOW we think and work together, not just WHAT we do...
We, as humans interacting with each other, operate from a set of core principles and values that drive us. The Agile Mindset gives us a foundation of techniques we can use to guide everything we do... not just at Work, but in all areas of our lives.
The Agile Mindset leverages four Core Values that indicate what is important to us — saying, one principle is more important than another:
People over Process
"After all... These really are just "PEOPLE" Problems."
proverb -unknown 5th Century Agile Analyst
Yes, the problems we face involve technologies, requirement expectations, and even 'processes', but "PEOPLE" are the heart of everything we are doing. It is important to acknowledge that "PEOPLE" are more valuable to us than the other aspects of every problem. In fact, "problems" can be reduced further to fundamental "INTERACTIONS with PEOPLE". Everyone has their biases and expectations — which define what we call "Problems".
We just want to acknowledge that the "PEOPLE" are more important to us than any particular Process, Technology, or Approach... and certainly more important than any indiscriminate "problem".
Delivery over Description
We value the accomplishment of our work, in order to see it to completion. We refer to our accomplishment as "being DONE!"
Being "DONE!" motivates us; seeing our work completed drives us to confidently take on each new task, because we know now that we can complete it, if work together.
If we can deliver something that works, we can use that working system to speak for itself. A working system is always more descriptive than a mere document. Documents are obsolete the moment they are published, but working systems live on their own, once they are in-play.
So, when we can, we would prefer to build something that works; that "LIVES", and let that serve as our documentation.
When documentation is required for the sake of user support, audit, or archival, we will produce a document, but it should be minimalistic and refer to the working system - so as to reduce obsolecense.
Collaboration over Stalemate
Since it's about the "PEOPLE" and being "DONE!", working together with competent people we respect and value is how we prefer to work. We acknowledge that we can not accomplish everything we need to deliver on our own, therefore, we build a Team of the best people we can find, who share our passion and workstyle and are as motivated as we are to delivery great work.
The collaboration with other people naturally brings challenges - such as conflict and interpersonal differences, but we value the objective to actively collaborate with people we respect, rather than suffering from disagreement, paralysis and stalemate.
Embracing Failure over the Belif in Clairvoyance
We believe Failure is simply the "First Attempt In Learning" and is a natural part of solving new and complex problems as a Team.
We can FAIL in two ways: Early and Often, or Once at the End.
Agile Software Development
We are Principle-driven
We consider Agile as a "Mindset", rather than a strict methodology. When we agree to these solid Core Values, they transform our thinking and unify our collective approach.
Here are the most Foundational Principles of the Agile Software Development process:
Collaborating » Learning » Planning » Doing » Delivering » Celebrating » Improving
- As Principle-Driven Leaders, we hold to several key Values that guide us: Inspiration, Movitation, Accountability, Agreement, Trust, and Self-Organization
- We crave Inspiration
- We are driven by personal and external (Team) Motivation.
- We long to be Accountable to those we work with and for.
- We must strive for Agreement and leverage "Healthy Conflict" and the Backlog when we can not agree.
- We continually work to earn Trust
- And we know that we must be Self-Organized
- We also embrace the core Values of "Good Agile" from the Manifesto that states clearly our Purpose - We are learning better ways of developing software by DOING it and by HELPING OTHERS do it.
- We value our People over Processes
- We need effective Leadership from all ranks of our organization - with our Team(s) and from ourselves.
- We value Delivery over Description
- We value Collaboration over Stalemate
- And we Embrace Failure over a believe in Clairvoyance
- We embrace failure because FAILure is the First Attempt In Learning and we want to learn from every failure -
TRY » FAIL » LEARN ››› RETRY.
- We want to deliver only the highest value/most important work items in a given Sprint, so we plan the work to fit in the Sprint.
- We leverage the Backlog if other work intrudes on the Sprint, so as to only work on what we have planned.
- The Backlog consists of value-ranked work items, called: User Stories - which explicitly defines the work necessary to deliver each specific working feature.
- The User Story describes a complete feature requirement - both functionally and technically, and serves as the Test case, defining "DONE!".
- We are proud to report and celebrate the work we accomplish (we call it "DONE!" when it is done).
- We devote ourselves to being "DONE!" because it is our best measure of success, which also allows us to continuously improve our planning, estimation, accountability, and trust among our Teams.
- We are dedicated to delighting our Customers (our "Product Owners"). Our Product Owners commit their time and expertise to guide our Development work.
- Our Product Owners define the Product Charter, the Persona Journey(s), and the Story Map, which guides all of our business and functional requirements. Our Product Owners also groom, prioritize, and value-rank the Stories and help prepare them for each Sprint Planning session.
- Our Product Owners work with us to build a Culture of Acceptance - where everyone understands the Acceptance Criteria, everyone knows what is being delivered, and everyone is ready to Accept the work once it's "DONE!"
- We want everyone to know what we are working on and what is being delivered, and we want everyone to participate in the effort to deliver what was "DONE!" in each Sprint.
- We also want to celebrate together, once the work is "DONE!"
- We reward those who worked hard to accomplish their work according to the Plan, and we value the closure at the end of each Planned Sprint.
- We value how much we Learn from every Sprint as much as we enjoy celebrating what was delivered.
- We refer to our Learning session as our Sprint "Retrospective" where we openly/honestly discuss what went well, where we failed, and how we could improve as we transition to our next Sprint.
These Principles are interlaced with each other. No one more/less important; no one dependent-on/derived-from the other.
- We Value our People and Working Together - We consider it essential to our work, social and family life.
- We want to Learn and Grow - all the time, every day, in & thru everything we encounter.
- We see the critical importance of Planning well, and want to do it as effeciently as humanly possible.
- We Do what we love and enjoy, but we also Do what needs to be "DONE!" and are motivated when we see our work accomplished.
- We need, no MUST Deliver a finished Work Product, because our finished work represents why we come together and defines our livelyhood.
- We enjoy the Celebration when we Deliver Good Work.
- And, We want to Get Better in every way possible, so we fold-in the Knowledge of the outcomes into our Continuous Improvement.
The Ceremonies of Agile
Eventhough Agile guides 'HOW we think' more than 'WHAT we do', there are several components of our workstyle directed by the Agile Process. These distinct components occur when we meet together as a collaborative 'working session' for a specific purpose during the Agile Software Development Sprint Life-Cycle. We refer to these 'working sessions' as the Ceremonies of our Agile process:
The Daily Stand-up
We meet together, every day, for 15-20 minutes max, to allow the entire Team to celebrate what was "DONE!" yesterday, and to learn (and agree on) what is to be "DONE!" today.
We address impediments and work hard to be efficient and respectful of everyone's time. We may also want to coordinate collaborative work, so we can take deeper discussions "off-line".
Product Owner Story Authoring
Our Analysts and Product Owners meet regularly to discuss business and application requirements and create User Stories. The User Stories correspond to the Story Map and complete each Personal Journey. Each Story must fulfill at least one Product Charter. Once Stories enter the Backlog, they can be value-ranked and scheduled for the pending Sprint(s).
Our Analysts, Technical Leads and SME's work closely with our Product Owners to routinely review and word-smith the Backlog Items (User Stories), to prepare them for each pending Sprint Planning session.
Every User Story must be complete with Acceptance Criteria and everyone must agree when a Story is ready to be prioritized and schedued for a pending Sprint.
Sprint Planning / Task Mapping
Sprint Planning, which essentially involves the adequate preparation for the immediate next Sprint, should be precisely no less and no more than is needed to schedule all work included in the next Iteration. The Sprint Planning process takes a great deal of mental energy on the part of everyone on the Team, and requires active participation from everyone. Sprint Planning consists of several steps:
- Make sure all of the Stories we are considering have been properly authored, groomed, sized, and prioritized for the immediate next Sprint. This also means every Story is complete with the exact Acceptance Criteria to define "DONE!" and they are word-smithed so everyone can clearly understand what is expected. Story Sizing is performed as a points-based assessment of the relative complexity of the Story once it is ready to include in a Sprint.
- In order to maintain the integrity of the Sprint, we must know who will be available to participate and at what capacity. The "Integrity of the Sprint" also includes the autonomy of the Development Team, so they can time-box their work and isolate themselves during their allotted ½-day's. We must work very hard to resist intrusion during the Sprint. The Backlog helps us defer work (analysis, planning & technical design) until we are ready to address each issue individually.
- The object of Task Mapping is to plan just enough detail to estimate the work properly. It is not the time to complete all creativity, but to prepare for the creative work necessary for each Story, so we can, again, time-box the creative development work and meet our estimates by delivering our work within the Sprint.
Task Mapping is the 'third half' of the Sprint Planning process and is the most cerebral of our collective ceremonies. During Task Mapping, the Technical Staff spends enough time thinking through each Story and A.C. to define the appropriate Tasks required to perform the work necessary. Task Mapping also involves careful estimation (based on man-hours), which helps us guage how much time from each Team Member will be required during the Sprint.
The Developer, Analyst, and Product Owner will perform additional creative design when they begin the task during the Sprint, but the Task Mapping process must include just enough creativity to consider all necessary tasks worth estimating as distinct work elements.
Sprint Transition: Demo & Retrospective
The activities of the Sprint Transition are distinct enough to discuss separately, but it is also helpful to consider the ceremony of the "Transition" as a singular event in the Agile Sprint Calendar. The wholistic purpose of the Transition is to 'call to a close' the preceding Sprint, and properly prepare for the immediate next Sprint.
Closing the Sprint requires an effort to recognize all aspects of the preceding Sprint worth mentioning: Demoing the work completed, celebrating the good work delivered and looking closely at areas of improvement.
The activities should be scheduled and participation should be required because of the importance of collectively closing the loop and turning the corner.
Delivery, Accountability & Trust
Apart from the human, collaborative benefits of the work we do, the single most important reason we come together is to complete the work we are paid to deliver.
As we become consistent in meeting our commitments in each Sprint, delivering the work we have promised, we become accountable to our business partners and Customers for the investment they have made in us. As we improve our accountability to deliver on-time/on-budget, within each Sprint, we develop a strong bond of Trust among our Product Owners who can speak confidently on our behalf, among Management who can rely on us to deliver the work committed, and with our Customers who we truly want to delight and depend on our excellent work, every Sprint.
Agreement, Teamwork, & W.W.K.
At the foundation of Good Agile is the necessity to find Agreement as we work together. In building and sustaining Teams, a core-factor of success is found when we can leverage our Agreement and categorize our disagreement. When we Agree, we can move, act, build, and deliver. When we disagree, we must find ways to leverage the conflict that comes from disagreement and make it work to our advantage - either by strengthening us to a better outcome as we talk-thru a challenge, or to allow us to move forward with What We Know, and use the Backlog to help us with the things we can not yet agree upon. More on this in the following articles...