The Agile Manifesto | Principles behind the Agile Manifesto |
Thursday, July 28, 2011
Agile Manifesto T-shirts
Here are a couple of suggestions for T-shirt stencils you might consider. The word clouds for Agile Manifesto and the principles behind it...
Wednesday, July 27, 2011
Word cloud for "Describe what you do in three words"
A recent popular thread on the Lean Six Sigma LinkedIn group triggered over a thousand responses. So I took a snapshot on Wednesday July 27th (New Zealand time) and created a word cloud, to see what we were all saying.
By the looks of it, most of us Improve, quite a few of us Make, Learn, Deliver, Create, Analyze, Lead, Drive, etc.
Enjoy!
By the looks of it, most of us Improve, quite a few of us Make, Learn, Deliver, Create, Analyze, Lead, Drive, etc.
Enjoy!
Monday, July 11, 2011
Entertain me!...
As Agile Coaches, we often have to find fun ways of inspiring our Teams to learn and gain fresh insights so they may collaborate better.
The Mashmallow Challenge is a very instructive design exercise that encourages teams to experience simple and profound lessons in collaboration, innovation and creativity. The TED video is well worth watching, it's virtually guaranteed to amuse you.
TastyCupcakes.org is another brilliant source of inspiration for various games, including quite a few designed for Agile Teams.
The Mashmallow Challenge is a very instructive design exercise that encourages teams to experience simple and profound lessons in collaboration, innovation and creativity. The TED video is well worth watching, it's virtually guaranteed to amuse you.
TastyCupcakes.org is another brilliant source of inspiration for various games, including quite a few designed for Agile Teams.
Great Teams are Grown, not Hired
Roy Osherove discusses three maturity stages of a team and adjusting leadership accordingly, along with techniques meant to bring craftsmanship and maturity in a software development team.
Roy argues that Great Teams must be grown - they cannot be hired in whole. Teams must learn how to become great at their work through practice and intense collaboration (just as military units become better by drilling and fighting together).
To grow Teams more effectively, leaders must tailor their leadership approach to the development stage or characteristics of the Team.
Roy argues that Great Teams must be grown - they cannot be hired in whole. Teams must learn how to become great at their work through practice and intense collaboration (just as military units become better by drilling and fighting together).
To grow Teams more effectively, leaders must tailor their leadership approach to the development stage or characteristics of the Team.
Wednesday, June 29, 2011
The Gemba Walk with Jim Womack
Jim Womack just gave an excellent The Gemba Walk webinar (there's also a follow-up Q&A session to watch), under the auspices of the Lean Enterprise Institute. The core message is that the Gemba Walk can be used as a mechanism to give context for horizontal conversations that lead to improved flow. An excellent practice for all leaders!
Tuesday, June 28, 2011
What's this Kanban thing, anyway?
Kanban is a simple way to visualize and control work (or things-to-do in general), limiting the amount of work-in-process in order to achieve good flow.
For details on how Kanban may be applied at different scales, please see or listen to:
- Personal Kanban and PK Flow: what is it and why use it? - applying Kanban at an individual level
- Becoming an Agile Family thru Kanban - applying Kanban at a family and Team level
- Agile and Kanban - applying Kanban in Agile Teams
Tuesday, June 21, 2011
Start with Why
See the Simon Sinek: How great leaders inspire action TED talk for an interesting view on modern leadership. Simon argues that the leading companies answer the question Why? before they attempt to tackle the How? and the What?. By presenting a message in the order Why?, How?, What?, leaders can forge an emotional connection with their people and clients. Jean Tabaka just hosted a nice session in Wellington following this very concept, applied to the use of Agile methods.
This is not to be construed as being in conflict with John Shook's advice about the order of asking questions when doing a Gemba walk: "First ask what, then why, then what if ... and, finally, why not." Notice that this order checks for the standard work that should be the What?, then verifies that the Why? is understood, and then explores improvement opportunities.
Both views are harmonious. A healthy value stream or network needs a clear Why? It drives the value being created for clients, and guides the improvement efforts of the workers, for both work products (What?) and work processes (How?).
This is not to be construed as being in conflict with John Shook's advice about the order of asking questions when doing a Gemba walk: "First ask what, then why, then what if ... and, finally, why not." Notice that this order checks for the standard work that should be the What?, then verifies that the Why? is understood, and then explores improvement opportunities.
Both views are harmonious. A healthy value stream or network needs a clear Why? It drives the value being created for clients, and guides the improvement efforts of the workers, for both work products (What?) and work processes (How?).
Going to the Gemba for Agilists
John Shook's latest e-letter, How to Go to the Gemba: Go See, Ask Why, Show Respect covers four main perspectives from which people generally observe work when going to the Gemba:
What does this mean for the business of software-intensive systems development? The ideas apply directly - no significant adjustment required.
To achieve continuous improvement, we must start by respecting our engineers, encouraging and supporting them to create improvements to their work processes, in addition to creating and enhancing features for the systems they develop. We trust them to create intricate engineering constructs. Surely they're best placed to design the improvements to their work processes as well.
We have a responsibility to develop ourselves and our colleagues into intense noticers and tenacious experimenters. We must challenge each other to create better systems that create products in addition to creating the great products themselves.
- Solution View - hunting for opportunities to use Lean tools. Tempting but risky - since it implies a hazardous rush to conclusions - potentially disruptive for continuous improvement if used on its own.
- Waste View - keeping an eye out for wastes of various kinds. Useful, and should be handled carefully so as not to pursue local optimization to the detriment of global outcomes.
- Problem View - confirming and inquiring into impediments. Handy, and may take many shapes - its weakness (and opportunity) lies in the fact that it lacks an in-built structure. Various problem-solving approaches can be devised to suit the team and organization's context.
- Kaizen View - seeking patterns, forms, routines. By engaging the people doing the value-adding work into a structured problem-solving pattern, this is the strongest choice.
What does this mean for the business of software-intensive systems development? The ideas apply directly - no significant adjustment required.
To achieve continuous improvement, we must start by respecting our engineers, encouraging and supporting them to create improvements to their work processes, in addition to creating and enhancing features for the systems they develop. We trust them to create intricate engineering constructs. Surely they're best placed to design the improvements to their work processes as well.
We have a responsibility to develop ourselves and our colleagues into intense noticers and tenacious experimenters. We must challenge each other to create better systems that create products in addition to creating the great products themselves.
Labels:
agile,
Gemba,
leadership,
lean
Location:
Paraparaumu, New Zealand
Subscribe to:
Posts (Atom)