Joakim Holm has written an awesome post about breaking through the wall of conventional thinking, smashing a dilemma into pieces, and finding a third option along the way.
One day soon they realize that “Hey, we’re pretty good. We can take advantage of that and release more often without risking anything.”
via Breaking through the Wall of Release Mediocrity « The Blogging Terrier | Den bloggande terriern.
Here’s me talking (in Swedish) about how we look at problems from a systems thinking viewpoint, at Lean Tribe 2.
Lean Tribe Gathering #2: Tobias Fors from Lean Tribe on Vimeo.
Over the last five years, I’ve taught lots of classes to lots of people. If I knew it before, I’m convinced of it now: lecturing is not the most effective way to help others truly learn.
The problem with lecturing is that it doesn’t really do much to change someone’s behavior, at least not in a lasting way. So what? Well, I believe learning is more than just collecting new pieces of information. Learning also means enabling new behaviors.
One thing is for certain: lecturing is satisfying, at least for a while. It makes me feel smart, and many of my student’s love it, because they get to lean back and enjoy the ride without expending too much energy on their own, until they finally fall asleep, or worse, just tune out. A great lecturer can stay interesting for longer, of course, but I’m afraid most people leave even a great lecture only to go back to doing whatever they did before.
Lecturing isn’t all bad – it’s just that too many expect too much from it.
Sometimes I get sucked into lecturing mode, even though I don’t want to. Maybe it’s an effect of my academic schooling.
I remember one of my university teachers well. In the first lecture of his course, he displayed a cartoon of a poor fellow in a chair. Attached to the fellow’s mouth: a hose. The other end of the hose was attached to a faucet, labeled “Knowledge”. My teacher proceeded to explain the picture.
- “I’ve recently been to a pedagogy course. They taught us not to try and stuff knowledge into our students in the same way you fill a sausage. I definitely agree”, he continued, “but then again, this is an advanced level class”. With that, he started lecturing.
The first few weeks of the course were indeed stuffy. We were expected to mechanically fill out answers to five hundred questions presented in a booklet given to us. Before you’ve done this, the teacher explained, you’re not really ready to enter into meaningful discussions on the topic.
Once the first part of the course was over, the style of teaching changed dramatically. Group work and seminars were substituted for lectures and answer hunting. I liked the second part better, but the first part was useful too.
I suspect fewer would pay to come to my classes if I required them to answer hundreds of questions beforehand. In just a couple of days, I want to help the participants in my classes discover new and more effective behaviors. How do I do that, if lecturing delivers such weak results?
My chosen path has been to learn about experiential learning. In experiential learning, the idea is to create a situation where students can construct new knowledge on their own. As a teacher, my work is to design the right environment for learning to occur, and to help the students make sense of what they discover.
I’ve always designed my courses to be very interactive, but there’s one key thing I’ve learned as I’ve started to study experiential training: debriefing is key. While experiential training builds extensively on exercises and simulations, the real learning seems to happen during the debrief. This is when the group works together to reflect on what just happened, and to build up their new knowledge. Debriefing often takes as much time as the exercises themselves.
Experiential training is not always welcome. It can happen that participants who did not quite know what they were getting themselves into are unpleasantly surprised by the format, which is the complete opposite of the archetypal classroom situation, where the all-knowing teacher is at the front of a silent crowd, lecturing from his book of clear cut answers.
For some, this format is different enough to create an uncomfortable confusion. For others, the amount of insights and emotions turn out to be an overwhelming surprise. For many, it leads to lots of learning. Whichever the case, it is my responsibility to make sure participants know what will happen, and that participation always is optional.
When was the last time you really learned something new – something that changed you? What conditions made that learning happen?
PS. If you want to experience experiential learning in a workshop setting, try to get a (highly coveted) place in one of Jerry Weinberg’s, Esther Derby’s and Johanna Rothman’s “Problem Solving Leadership” workshops. If you’re interested in this topic, you will learn as much about this style of teaching as you will about yourself during one intensive week.
In an effort to prove I’m not a perfectionist, I’m publishing this work of art I just created, while sketching out some ideas for an upcoming talk. Being a specialist can be a double-edged sword.
Have you experienced this pit? Did you like it there, or did you find a way to get out of it?
Many organizations forget that planning is all about the planning. You’ve probably heard the saying: “The plan is nothing, the planning is everything”. For me, that means that the process of planning itself is, to a large degree, what creates belief in and understanding of the plans. The plans will break anyhow (we’ll still do our best to create them), but the more we participate in creating them, the more we believe in them, the more we take ownership for them, and the greater is the chance that we will reach our goals.
It’s both easy and hard to do this. The easy part is what typically needs to happen. The hard part is gaining acceptance for it, and facilitating the process effectively.
Gather all the people in a room. Let someone who understands the business side of things start out by explaining what needs to be achieved. Invite everyone else to ask questions. Make it safe to do so. Use your tricks of the trade to make the interactivity happen. Silent brainstorming is one powerful technique; ask participants to silently write down their questions and comments on cards, then work through these together. If you’ve ever presented something to a large group and then asked “any questions”, only to be met by compact silence, you know why a technique like this can be very useful.
With the high-level goal presented and discussed, and with questions clearly captured on flip charts on the wall where everyone can see that their concerns have been captured, go ahead and work together on the plan.
By now, there are many techniques in the agile community to make this easier. Collaborative story writing, planning poker, silent sorting, and story mapping are all popular. I’ve just started to learn about system anatomies, which seem to be a powerful way of working together on other views of the work to be done. Whichever techniques you choose, make sure to use them in a collaborative way. Therein lies the key to success.
When I was still working as a contract programmer, I was on an assignment where the boss was from the United States. I didn’t meet him very often, but he seemed like a nice enough guy. One day, he surprised me though.
I was sitting in my chair, leaning back for a while with my hands behind my back. I was thinking about how to handle some little challenge with an XML schema I was struggling with. While sitting like that I heard (faintly at first) the sound of my American manager approaching. I could tell it was him, because his shoes made a specific and quite powerful clicking sounds on the hardwood floor. Suddenly, he passed behind me. He never stopped, but he did shout at me:
”Hey Tobias, you’re not programming! Hands on the keyboard!”
When we sit and think, it looks like we’re doing nothing. This makes it hard to think in many organizations.
Doing is what it takes to change the world, but if we don’t think a little first, how can we know if we’re about to change it for the better or the worse?
Is thinking allowed in your organization?
This week I managed to squeeze in three days of consulting and two days of public teaching. Side effect: less time over for reading. Still, here’s some of the stuff that piqued my interest online this week.
Bright and Terrible
Jay Yarow of Business Insider published a short post about what’s it like to fail at Apple. Not sure how fact based it is, but it makes you think about the challenges of managing risk and failure.
If you’re making too many mistakes, your company might not be around in a year. On the other hand, if you aren’t making any mistakes, you probably won’t be around in five. Why? Because making no mistakes means you’re avoiding risks entirely. Why is that so bad? Because risk is connected to reward. If you’re not taking risks, someone else is, and when they succeed, they’ll be ahead of you.
If you’re a manager who likes to chew out your management buddies, think about how that behavior is replicated by others in the organization. After all, you’re supposed to be some kind of role model.
Speaking of Apple, I also found a piece on Fast Company about the ever-accelerating smart phone wars.
Telling Stories Together
The next writer out also has a last name that starts with a Y: Adam Yuret. Adam shares the insights he’s gained after taking Elisabeth Hendrickson’s Introduction to Acceptance Test Driven Development. Specifically, Adam talks about the value of doing story workshops. In the end, Adam writes, we might not end up with a story chiseled in stone, but the shared understanding gained from a story workshop should reduce time lost to major changes and confusion later.
I couldn’t agree more. While I have only tiny experience from ATDD (a client of mine recently chose to go this way), I have lots of experience of facilitating workshops of different kinds. In my experience, the value of effective workshops is dual. First, we get the value of clarifying assumptions and laying out a clear plan of attack together. Second, we get the value of realizing that we’re actually in this together, and that we have the potential to work as a team. It’s plans and morale, both for the price of one.
WaveMaker
Back in the eighties, my best friend’s dad sometimes took his Mac SE/30 home from work. We ended up exploring it’s every nook and cranny. Probably the best piece of software on it (aside from the game Dark Castle) was HyperCard. It was the precursor of the wave of multimedia development environments that rolled in during the nineties.
HyperCard was awesome. You could easily create interactive storybooks and simple applications with scripting. Ever since then, I’ve been waiting for a replacement with HyperCard’s impact. This, of course, is when more experienced software people feel obliged to comment that ”that myth of making everybody a programmer has been around since the beginning of computer’s”. Well, maybe it has, but it won’t be a myth once it’s true. Or, if it really is a myth, I still choose to believe in it.
Why would anyone want a tool that makes it easy to create programs? Why wouldn’t we? With computers, we’re sitting on the most incredible piece of universal machinery ever created. But, for almost everyone, the power of the computer is still locked away behind arcane programming languages.
The untapped demand for accessible development environments is evidenced by, for example, how Excel is frequently used to develop ad-hoc solutions to computing needs. Professional programmer’s would say that’s not using Excel but abusing it, but the fact remains: Excel might just be the most widespread non-programmer’s development platform. Heck, even people who now how to code for real create stuff in Excel, like Space Invaders, for example.
This week, a tweet flew by about something called WaveMaker. It sounded like an attempt to create just that kind of accessible environment, so I checked it out, and it turned out to be some kind of browser-based development environment. I just downloaded it now to have a closer look. I don’t think WaveMaker is what I’m dreaming of, however. I managed to create a simple ”Hello, world!” app in a few seconds, but that’s just because I used to be a programmer. All in all, this looks more like a programmer’s IDE than the everyman’s toolbox I’m dreaming of. That doesn’t mean WaveMaker isn’t awesome. It does mean that it’s not what I’m looking for in this regard.
What’s a Test Strategy?
My friend from the AYE conference, Fiona Charles, has a great new article out. It’s called ”Basics Revisited: Test Strategy”. In it, Fiona takes a clear and pragmatic look at what a test strategy is. Fiona takes a stand against huge documents filled with boilerplate text. Instead, she urges us to understand what it means to have a test strategy:
”A test strategy is the set of big-picture ideas embodying the overarching direction or design of a test effort. It’s the significant values that will inspire, influence and ultimately drive your testing, and the overall decisions you have made about ways and means of delivering on those values.”
Fiona also asks us to think about the medium we use to communicate our strategy:
”I have used one or some of: a mind map, sticky notes, a drawing on a board, a colorfully highlighted diagram, an outline document, or presentation slides. The choice depended on the organization I was working with and the nature of the test. Whatever medium you choose, it should work as a tool you can walk around with to talk to stakeholders, or use in meetings to promote discussion.”
Also on the testing side, I found this neat report from StarEast 2011, written by agile tester Lisa Crispin.
Stay Uncomfortable
Finally, Andy Hunt has some good advice for advanced agile practitioners: stay uncomfortable. If you’re starting to think you know what this is about, that may mean you’ve stopped thinking hard about how to developer even further.
Here’s a mixed list of some of the things I appreciated online this week. They might turn out to be useful to you as well.
Fake and Shapes
Randy Rice published a blog post that listed different testing tools that came up during a tutorial session he hosted at StarEast 2011. I don’t work as a tester, but I’m fascinated by the field, and like to follow it from the sidelines. Plus, I love a smart tool.
One of the tools that stood out on Randy’s page was Fake (USD 29.95), an application that wraps a web browser with some Automator-like automation. I probably won’t be using it to automate tests, but I’m already keeping my eyes open for some boring web-related task to automate.
Lots of Mac software is made by small and creative software shops, so when I find a nice piece of software, I always look for other interesting offerings from the same developer. This time, I found Shapes. As with Fake, I haven’t tried it yet, but it looks interesting. I needed to help a client with some diagrams a year or so ago, so I bought a license for OmniGraffle. I can’t stand it. I will never learn to master it’s cluttered interface. Shapes might be what I need for those occasions where a napkin sketch isn’t enough. We’ll see. It’s only USD 4.99, so I could afford trying it on for size.
Balancing action and reflection
Esther Derby’s writings are thoughtful and balanced. This week, Esther published a piece called ”Fixing the Quick Fix”. In it, she argues for a balance between deciding and act fast and decisively, and not acting before you have understood the underlying problem.
I know from my own work with clients that this can often be hard to discuss. It’s not uncommon for organizations to be in constant conflict over this. On one side of the battlefield, department A wants to see higher speed in execution. They are wondering why nothing is happening. On the other side, department B wants things to slow down. They wonder why the organization has to spend so much time fire fighting, and so little solving the true problems.
What makes it hard to discuss this? Well, depending on where we’re coming from, we look at speed in different ways. An experienced and skilled agile team, for example, will think it perfectly natural to execute in high speed. They can move fast, in controlled formation.
A less experienced, less skilled team, will struggle to move fast. They don’t yet have the knowledge and understanding they need to speed up. Asking them to ”just move faster” is a recipe for disaster.
Do you know which of these situations most resemble your current workplace? This is where the questions Esther poses in her article come in handy. They are about uncovering the facts of the situation, so that you can take appropriate action. This too, is hard work, and follows the same laws of speed as everything else. If you’re skilled at asking them and if there is trust between you and those you ask the questions to, then gathering this information will be less of a struggle. When you do it for the first time, there is some risk that other will see you as the one slowing things down: ”If it weren’t for all your questions, we’d already be done with this”.
Esther’s article also goes into what you could do once you have a better understanding of the current situation. Specifically, Esther advises us to see if we can back up our ideas with hard data. This too, is often challenging, in my experience. Many organizations won’t be able to produce the numbers you need, because they do not yet operate in a way that makes extracting such numbers possible. Still, trying to get some data and finding out it can’t be done, is also valuable. It tells you a little bit more about the organization.
By now, you might you’re ready to decide. Hold it for just a little longer. Take Esther advice one more time, and generate at least three options. Generating options is a key part of any creative process. We don’t always have to be super creative, but we do need creativity at all times. Without creativity, companies end up being about as good as, or worse than, their competitors, and that’s no fun way forward. One of your options now is to escape from this weekly summary and dive into Esther’s excellent article.
Innovations in Management
Via John Seddon’s regular news letter, I found a blog called ”Gary Hamel’s Management 2.0”. You might have read it already, because apparently Hamel is a big management guru in the States. Somehow, I’ve managed to miss him completely. By the way, if you’ve already read Jurgen Appelo’s ”Management 3.0” book, it might seem that Hamel is running behind, version number wise. I’m sure Hamel will upgrade soon. Probably to 4.0.
Anyway, the reason Seddon mentioned Hamel was that one of Seddon’s clients – Owen Buckwell – has been awarded a prize instituted by Hamel, for his work in transforming the housing services organization he manages.
Apparently, Hamel has started something called the Management Innovation eXchange, which aims to highlight potential game changers in the field of management – and that’s what I wanted to tip you about. Pay a visit to the Management Innovation eXchange site, there’s bound to be something there that can inspire you.
How to Start Up …
Speaking of management, I have to share this link to a blog post that contains, essentially, a checklist for how to start a web company. All you have to do is follow the steps. I might try that some day. In a way, it still managed to inspired me a little bit, even though it reminded me of Paul Davies’ absolutely wonderful book How to Build a Time Machine. It’s pretty easy if you know how to do it.
… and how to start starting
Finally, for this time, I learned about the book ”The War of Art”. I believe I read about it in Kent Beck’s Twitter stream. This book is about resistance, specifically the kind of resistance that rears it’s ugly head whenever we want to start some kind of creative endeavor. I bought it for my Kindle, or rather for my iPad’s Kindle app and started reading last night. It’s a very smooth read, which is kind of funny considering the topic of the topic. There’s no resistance in reading this book about resistance.
I guess the advice in the book gave me a little push, since I sat down to write this Saturday morning post, just as planned.
Also, speaking of resistance, I found my way back to one of many great pieces by Dale Emery on the topic. It’s called ”People Resist Change?”, and deals with how we related to change. An absolute must read if you ever deal with change. I guess you do.
I’ll let that be it, for this week.
At Citerus, I worked with my colleagues to create a basic form we can use to take a quick inventory of the current engineering practices in the teams we work with. It was originally in Swedish, but I just translated it into English for use at a client.
We’re not dogmatic, so neither is the form. Nor do we think that anything goes, so there are lots of opinions built into the form. Use it at your own risk. The least it could do for you is to act as a conversation starter.
So, the form can get your team talking about engineering practices. There are many ways to use the form, and we don’t prescribe a specific way to use it. Among the ways I’ve heard it’s been used are these:
The document is available as a share on Google Docs, from where we might update it from time to time. Google Docs isn’t very capable when it comes to formatting, so the lines and page breaks I’ve tried to put in might or might not work for you.
We’re publishing the document under this Creative Commons license:
Examine Your Engineering Practices by Tobias Fors is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
Here’s the form: Examine Your Engineering Practices
I like to take stuff and try to express it in as simple language as possible. That’s my way of checking my own understanding of a concept. One concept that comes up often when we talk about lean software development, kanban and agile is that of “flow”. A couple of days ago, I decided to process that a bit.
One technique I use to process stuff is to sketchnote in Brushes on the iPad. Here’s the video output from my sketchnoting a basic explanation of the concept of flow in development.
What techniques do you employ to process stuff you want to learn well?
