AORTA Spiritual Entrepreneurship Practices
March 6, 2023 § Leave a comment
Adapted from Perpetual Adolescence
1. Ambition: Desire -> Meaning
Best Practices for Design in Agile
August 7, 2015 § 1 Comment
A Bibliography, mostly discussing UX Design but a little on the related issue of Architectural Design.
- A List Apart: Getting Real about Agile Design
- The uneasy relationships between design and agile
- SPARC: What an Agile Design Process looks like
- Thought Works: Just Enough Design
- Martin Fowler: Is Design Dead?
- Design Spikes
- Enough Design Up Front
- Overcoming Why Designers Resist Agile
- Agile Web Design Manifesto
- Agile Modeling: Agile Design Practices (architecture-focused)
- How does Design get done on an Agile Project?
- The Last Responsible Moment for Design
- Stack Exchange: How is architectural design done in an agile environment?
- Full Day Training: Lean UX and Agile
- 12 emerging best practices for adding UX work to Agile development
- Atlasssian: Collaborative design in agile teams (video)
How to Fund Growth
July 2, 2015 § Leave a comment
Most organizations’ financial structures are designed for predictability rather than explosive growth.
To change that, we must:
Invest Constructively in Passion
1. Align Incentives
- Learn what people deeply want.
- Articulate how they can pursue that by contributing to the organization’s mission
2. Unleash Talent
- Learn where people are the happiest and most productive.
- Build support systems that allow them to maximize flow.
3. Virtualize Infrastructure
- Learn which essential tasks nobody is able to do efficiently and awesomely.
- Sell those to a business that sees the opportunity.
The Celebration-Driven Church
October 19, 2012 § Leave a comment
[A follow-on to Spreading Effective Vision and The Agile Church, addressed specifically to the Church Spread of Kingsway Community Church.]
In less than twelve months, together with the Holy Spirit, we have completely reinvented Kingsway Church. While our overall numbers may be the same, we have spread to two new neighborhoods, dramatically expanded our pastoral staff, and filled much of our congregation with renewed vision for reaching our communities.
What if that was just the beginning?
« Read the rest of this entry »
Spreading Effective Vision
October 11, 2012 § 2 Comments
While discussing The Agile Church and Metrics versus Goals, I realized that our organization’s primary motivation for adopting Agile practices is to spread the ownership of effective vision.
That is, we start with a shared belief that vision ought to be:
- Effective: timely, clear, actionable & aligned with the organization’s overall purpose
- Spread: distributed from the core leadership out to every member
- Owned: each person takes responsibility for how they implement that common vision
Working from there, we can adapt techniques from, e.g., Scrum, that will help our organization achieve that goal.
Here are what I consider the most powerful suggestions:
- Adopt a mindset of continuously developing and implementing new visions
- Care about improving how we do things, not just what we do
- Maintain a written backlog of “things worth doing/changing”
- Innovate in seasons of 4-8 weeks, tied to, e.g., a sermon series
- The leader (pastor) prioritizes 1-3 items from the backlog to focus on each season
- The team owns the vision (together) and its implementation (individually)
- Define the conceptual goal and practical metrics in terms of the value delivered to the customer (e.g., God)
- At the end of each season, celebrate what was accomplished (“thanksgiving”) and reflect on what did or did not go well (“confession”)
To me, the key is moving from strategic once-a-year vision-and-budgeting meetings for leaders towards tactical “sprints” that mobilize the entire organization (congregation).
This pace may sound a bit exhausting, but that very awareness forces us to alternate “productive” and “relaxing” sprints to keep the whole community healthy. It is already too easy to fall into ruts where some people never do much while others are continually burning themselves out. A good process should make explicit important issues that were previously implicit, so we are forced to consciously manage them.
The Agile Church
September 28, 2012 § 5 Comments
The modern church is typically structured like a 20th-century business, with distinct, mostly autonomous departments focused on executing an agreed-upon “business plan” that changes very slowly over time. The church adds a layer of relationship and prayer, and relies on volunteer labor, but overall mostly matches the model invented by Alfred Sloan at GMover 50 years ago.
The important thing to realize about this model is that it is optimized
for better doing the same thing over and over again — what’s known as
“disciplined execution.” This is contrast to “rapid innovation”, which
is better done by small, high-performance teams.
For years, management theorists assumed that a single organization could not do both. This split is somewhat reflected in the historic distinction between “church” (execution) and “parachurch” (innovation).
In the last decade, a new approach to managing software projects has
emerged called “Agile“, which has achieved remarkable success at doing both
disciplined execution and rapid innovation. The key cultural values
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
If that sounds a bit foreign to the church, try reading it as:
- People and relationships over processes and tools
- Transformed lives over written agreements
- Glorifying God over fulfilling the Law
- Responding to today’s culture over following tradition
The critical term is “over”: the items on the Right side are still valued, but are explicitly subordinate to those on the Left.
These aren’t just nice-sounding values; there are very specific structures, practices, and choices (e.g., Scrum) that flow out of (and can help create) this shift in mindset.
Further, there is an ongoing movement called Stoos to apply these practices beyond software to the general problem of organizational management. Interestingly, many of the attributes of “Stoosian” organizations matches what we want to see in our churches:
- The workers, not the leaders, “own” the work they do.
- The job of leaders is to articulate the needs and desires of the Customer (in this case, God) in way workers can fulfill.
- The measure of work is not how much we do, but how much value we deliver to the Customer.
- Everybody takes responsibility for improving how we do things, not just what we do.
I believe there is enormous opportunity for the church to radically improve how we “delight our Customer.” Below are some early attempts. I look forward to further dialogue around this issue.
Agile/Scrum in the Church
- Agile Church: Slides and Case Studies « The Blue Room
- Scrum — it’s not just for software anymore « Agile Raven Blog
- Simple Church: Returning to God’s Process for Making Disciples
- Scrum in Church: Saving the World One Team at a Time
Excerpt from “Scrum in Church”
The ways we organize ourselves, the structures we create to order our lives, and our work, reflect our deepest theological understandings. How is power understood? Does it flow from on high? Does it emerge from the people? Does it take a completely different configuration? Who benefits? What is most highly valued? What cognitive styles are preferred? What or who is on the margins? What is not seen because it cannot be imagined? Who is not “like us”? How do we treat them?
One of my favorite questions as I enter a congregation is “How does power flow around here?” One answer I’ll never forget is, “Well, it’s sorta like water in a bathtub, it sloshes.” We laugh, perhaps in recognition?
In short, the ways we live, what we do, and how we do them reflect one’s deepest values.
Poppendiecks on Lean Software Development
November 13, 2007 § Leave a comment
Thomas and Mary Poppendieck are to Lean Product Development (for Software) what Charles and Ray Eames are to design. LPD can be considered the project management aspect of Agile, to complement the software engineering practices of, e.g., Behavior-Driven Development. Some of my favorite essays from their website are: