Yesterday I attended TDC.
It was fun to see so many from the software development community in Trondheim turn out all at once.
I also had a short talk about better ways to work, focusing on delays and feedback – especially how it’s more central to knowledge work than we think.
Here’s the slides if you’re curious (PDF):
201210 TDC Better ways to work
Update: I added a few slides for a talk at the office – see extended version (pdf) if you like, containing a few more links/ reading tips.
If you visualize more you get more agile.
Tom Wujec had an excellent TED talk on 3 ways the brain creates meaning.
- Use images to clarify ideas
Visual shapes, physical space, colors, motion help us create mental model, more understanding
- The act of engaging, being interactive enriches mental model
- Augment memory by creating persistent, evolving views
Let’s say you have a task board for a software development team, either a physical one or a digital one shown on a screen as a dashboard. Let’s say it’s visible in an office so that everyone on and outside the team sees it several times a day.
- People in and around the team gain a shared mental model, a shared understanding.
- People interact with the board as things change, including upstream and downstream stakeholders. A visible task board creates more engaged stakeholders.
- A task board is persistent and evolving, and becomes a new visual, domain-specific language of sorts, where the domain is the reality of the development team.
This language is a more abstract, high-level language, and enables much more effective thinking, communication, and collaboration.
A software development team communicate and collaborate better the more they visualize the work.
How can you visualize more to gain advantages like that? Here’s a few examples:
- Let workflow on task board be closer to reality
- Show different types of work differently
- Let a status screen display a virtual task board permanently
- Are you working in a traditional waterfall project? Regularly print the latest version of the project plan (and progress) and put it on the wall.
- Show more policies like DoDs, increase transparency
- Are you doing CI or continuous builds? Create alerts or alarms for failures, include status on status screens.
- Show problems and impediments clearly
- Do you share status on sales, bugs, product upgrades, project progress, project backlog etc in monthly or weekly meetings? Make status visible for everyone at anytime via screen or paper.
Agility is about balance and speed, and being able to change and adapt to change.
It’s not a binary state, something you are or not, but a question of degree. You, or your team or company, are more or less agile.
From the dictionary:
- ability to move with quick easy grace
- having an adaptable character
- synonyms: light-footed, nimble
- related words: flexible, limber, dexterous
- near antonyms: inflexible, stiff
In my opinion, being agile is not the same as using a specific method, tool, or process, or following a specific philosophy.
Agile does not equal Scrum, even if Scrum is an agile process.
Agile software development is not defined by the agile manifesto, even if I agree with most of it.
Getting more agile “simply” means to increase your ability to adapt – getting real feedback more often, and improving your ability to change and adjust.
Enterprise agility is the ability to respond quickly to unfolding events or opportunities, according to David Anderson in the webinar Scaling Agile in the Enterprise with Kanban. Getting more agile in the enterprise involves, among other things, increasing trust and minimizing resistance to change (i.e., improvements).
(This blogpost is subject to updates…)