Welcome to the authoritative resource of the Functionologist!

AgileTeam6: Principle-Driven Leadership

Inspiration » Motivation » Accountability
» 336/473-0700

Clemmons, North Carolina  27012


View Process Model in .pdf Format -

About Steve... Minimize

Steve’s most recent Resume is in two parts…

Starting with a brief 1-pager and bio, followed by a more traditional work history resume.


We've also included several additional resources you may find helpful:

  • First, is a consulting Bio Sheet which includes responsibilities and competencies in the role of Sr Engagement Manager at JSWalker.
  • Next, is the Ideal Team Player survey.
  • Steve's DISC Profile is provided and may give insight into his personality, modalities, strengths and weaknesses.
  • Also attached is the EQ-i Assessment in 3-parts.  This is an Emotional IQ evaluation performed by Jerome Daley of Thrive9.


...and, as always, we trust that you will respect the confidential nature of this very personal information.

Please do not distribute or copy it (in whole or in part) without express permission.

Providers' trademarks & content are representitive of their respective brands, and were purchased and licensed for use.

Useful Information...? Minimize
How did you reach this page?

Were you able to retrieve documents?

Which of these resources do you find useful?

Will you reach-out to Steve after viewing this information?

Submit Survey  View Results

Steve Stanley - Certified SAFe Professional Consultant (SPC)

Steve Stanley - Certified SAFe Release Train Engineer (RTE)

Applied Lean Agile, LLC

Applied Lean Agile, LLC - SAFe SILVER Partner

 Certified Trainer: Leading SAFe (Safe Agilist) 4.6  Certified Trainer: SAFe Agile for Teams (SAFe Practicionor) 4,6  Certified Trainer: Product Owner/Product Manager 4.6  Certified Trainer: SAFe Scrum Master 4.6  Certified Trainer: SAFe Advanced Scrum Master 4.6  Certified Trainer: SAFe Agile Software Engineer 4.6  Certified Trainer: SAFe Release Train Engineer  Certified Trainer: SAFe DevOps 4.6  Certified Trainer: SAFe for Government 4.6


Key Resources: Resume & Bio Minimize

Steve's Recent Resume

 Steve's 1-Pg Resume

Steve's Current Resume




Steve's Consulting Bio from JSWalker

Steve's Bio

DISC Profile

The Agile Mindset Minimize

The Agile Mindset - Basic Principles

TRY » FAIL » LEARN Minimize

The Agile Mindset - TRY » FAIL » LEARN

Our Principles of Agile: Minimize

As practitioners of Good and Practical, Applied Lean Agile, we follow these Values and Principles:

  1. As Principle-Driven Leaders, we hold to several key Values that guide us:  Inspiration, Movitation, Accountability, Agreement, Trust, and Self-Organization
  2. We crave Inspiration
  3. We are driven by personal and external (Team) Motivation.
  4. We long to be Accountable to those we work with and for.
  5. We must strive for Agreement and leverage "Healthy Conflict" and the Backlog when we can not agree.
  6. We continually work to earn Trust
  7. And we know that we must be Self-Organized
  8. 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.
  9. We value our People over Processes
  10. We need effective Leadership from all ranks of our organization - with our Team(s) and from ourselves.
  11. We value Delivery over Description
  12. We value Collaboration over Stalemate
  13. And we Embrace Failure over a believe in Clairvoyance
  14. We embrace failure because FAILure is the First Attempt In Learning.
  15. We want to fail early and often... rather than once, at the end.
  16. We want to learn from every failure - TRY » FAIL » LEARN ››› RETRY.
  17. We need to Collaborate to Learn from our failure -
  18. We want to deliver only the highest value/most important work items in this iteration/Sprint.
  19. We iterate in order to deliver the highest value items quickly.
  20. We Plan our work with the end in mind - to deliver/accomplish.
  21. We only plan what we can deliver in a Sprint.
  22. We only work on what we plan in the Sprint.
  23. 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 (prioritized) work items, called: User Stories (…or "Stories")
    • User Stories are uniquely testable elements of functionality - and describe the work necessary to design and deliver a specific working feature
    • User Stories are:  
      • Uniquely Testable - Independent
      • Groomed - Written and revised collaboratively by the team until the language is acceptable to the Product Owner and Developer - Negotiable
      • Prioritized - Ranked according to business value (no to items can hold the same business value - one is always more/less valuable than another) - Valuable
      • Designed from repeatable, familiar work, so we can understand the complexity and size of the entire work effort within the Story - Estimable
      • All the work of a Story (from analysis and design, development, testing, acceptance, and delivery) must fit into a Single Sprint - Small
      • Written as a "Design Requirement" -AND- as a "TEST CASE" so the same Story can direct development and be used to validate the working functionality when delivered - Testable
      • I.N.V.E.S.T.
    • A User Story is written to map exactly to at least one Product Charter value statement, one unique Persona, and one component from the Feature Map.
    • The User Story is written in the form:
      • As a "WHO", I want a "WHAT", so I can fulfill a "WHY"
      • As a Persona, I want a Feature, so I can meet my Charter
    • User Stories consist of 7 key components:
      1. The Name - or the most basic description of "WHAT" is requested
      2. The ID - a unique Backlog Item Number
      3. The "WHO" - the unique Persona addressed by this unique Story
      4. The "WHAT" - a specific high-value component from the Feature Map
      5. The "WHY" - value statement from the Product Charter
      6. The Acceptance Criteria - list
      7. The Task(s) - all assigned work (for every member of the Sprint Team)
  24. We want to be accountable to our Plan by reporting, each day, what was accomplished ("DONE!") yesterday and what we are going to accomplish today.
  25. We report what was accomplished/"DONE!" so we can record and celebrate the accomplishment.
  26. We celebrate what was accomplished/"DONE!" because it motivates the Team.
  27. We devote ourselves to accomplishment/"DONE!" because it is the measure of success.
  28. We measure our success so we can continuously improve our planning, estimation, accountability, and trust among our Product Owners and Stakeholders.
  29. We acknowledge 4 stages of "DONE!":
    1. Daily "DONE!" - Reported in the Stand-up
    2. Acceptance Criteria "DONE!" - Testable Functionality
    3. Story "DONE!" - Feature Complete
    4. Delivered = "DONE/DONE/DONE!" - Into next environment (UAT or PRODUCTION - depending on the culture of Acceptance)
  30. We are dedicated to delighting our Customers - Our first-line Customers are our Product Owners who are Knowledgeable about our Products, have the Authority to make design, acceptance, and delivery decisions, and are Available to work within the Iteration/Sprint to respond quickly.
  31. Our Product Owners lead our Product Delivery process from three "Core Concepts" (which make up the criteria for "Acceptance"):
    1. The Product Charter - the business case for "WHY" we have decided an item has business value.
    2. The Persona Journey - the explanation of "WHO" will be interacting, affected, or benefit from the working functionality.  All working, perceived Personas for the given system should be explored.  The Persona "Journey" is the unique decision flow or path of interaction each distinct Persona will take as they experience the Product.
    3. The Feature Map - a comprehensive, organized list of "Features" that make up the distinct experience of the Product.  There is no established level of detail necessary for the Feature Map; it should be hierarchical to allow for non-descript detail - a Feature starts out large and vague, and is refined with detail as the Team collaborates to "Groom" the Feature Map.
  32. We collaborate closely with our Product Owners so they can understand our iterative/Sprint process and contribute to the User Story Authoring process (Intake » Backlog Item Creation » Story Authoring » Grooming).
  33. We work hard to build a Culture of Acceptance - where our Product Owners understand the Acceptance Criteria, know what is being delivered, and are ready to Accept what is Story "DONE!".
  34. We deliver what has been accomplished/"DONE!" so we can delight our Customer.
  35. We use the "Acceptance" process to ensure the delivery of what was "DONE!" and allow us to continuously improve our working relationship with our Product Owners and Test Users.
  36. We celebrate what was accomplished/"DONE!" and want everyone to know what we are working to deliver, so we perform routine "Demos" of our work accomplished/"DONE!" in each Iteration/Sprint.
  37. We value transparancy - We demo our work so we can let everyone know what we are working on.
  38. We want everyone to know what we are working on because we always, only, want to be working on the highest value/most important items, and demoing our work gives everyone a chance to see our progress and hold us accountable to our Plan.
  39. We want to celebrate what was accomplished/"DONE!" so our Demos include simple presentations, explaining the Product Charter and User Story (with Acceptance Criteria) so everyone can gain context of why we are working on each item and where it fits into our Plan. 
    • The Demo Presentation is prepared, conducted, and facilitated by the Team responsible for the delivered work.
    • The Demo Presentation is often accepted by the Team with applause, showing appreciation and respect to the Presenters for a "Job Well DONE!"
  40. We reward those who worked hard to accomplish their work according to the Plan/"DONE!" - The Demo Celebration is often accompanied by some physical acknowledgement of the effort and diligence required to accomplish what was Planned/"DONE!"
  41. We value and crave the closure at the end of a milestone (hard work in the Iteration/Sprint) - The Demo Celebration is often followed by a meal, where we also raise a glass to the hard work delivered by the Team as a whole
  42. We value how much we Learn from every Iteration/Sprint as much as we enjoy celebrating what was delivered.
  43. We focus attention on what was learned in each iteration/Sprint - in order to continuously improve every Sprint
  44. We refer to our Learning session as our Sprint "Retrospective":
    • Following the Demo Celebration, the Team reconvenes to perform a Retrospective to identify, discuss, and document everything that was learned in the Sprint
    • The Retrospective may recount details of what was accomplished/"DONE!" so we can identify what went well - perhaps where we applied what we learned from previous Sprint(s).
    • The Retrospective also allows for respectful but honest discussion of what did not go well, so we can evaluate where we failed, and immediately call it what it is and learn from it.
    • We also take time to acknowledge any necessary process improvements or adjustments that must be made to facilitate better quality, faster delivery, better communication, and more consistent recovery from failure.
    • The Retrospective also includes discussion of individual members' participation in external groups, events, or contributions to blog posts, articles, presentations, etc.
© The Table Group Maximize
Copyright © 2001-2008 & © 2012-2017, .COM ?'s. All Rights Reserved. Terms Of UsePrivacy Statement