Let’s take a look at education and agile, two awesome topics that fit together beautifully, and how they come together to help people become professional web developers in a very short period in Montana.

A great deal of my blog has been devoted to my experience of the Agile Software Development movement and trying to apply this beyond just code. When I sought links from my blog to reference, so much of the last 10 years of my blog is about agility in one way or another. So I won’t bother adding links. Just scroll down, read, and click on the “older entries” link and you’ll find more, and yet more. All of my career has been focused on agile in one way or another.

As for education, it’s been an area of interest since just after high school when I encountered a radical book Deschooling Society by Ivan Illich which exposed me to the idea there might be much better ways of educating. On thumbing through the aging paperback I bought probably in the summer of 1980 during frequent bicycle trips from Queens to Manhattan, I was surprised to see a reference to the work of Paolo Friere who “discovered that any adult can begin to read in a matter of forty hours if the first words he deciphers are charged with political meaning”, and that Friere “moved from exile to exile mainly because he refuses to conduct his sessions around words which are preselected by approved educators, rather than those which his discussants bring to the class.” Returning back to Agile, Paolo Friere and Augusto Boal were topics in an Agile 2010 conference from a speaker from South America who more lastingly introduced me to the work of these amazing gentlemen from Brazil. Both Friere and Boal know the deeper level of engagement that is possible in students when they are treated as subjects who steer their own learning, rather than objects into which learning is deposited or pushed.

Montana Code School is a community based initiative to train and educate professional web developers. Montana businesses needs them. May 2015 it became the only topic at a Lean Coffee conversation that was convened by Missoula’s 1 Million Cups community, which sparked Paul Gladen director of University of Montana’s Blackstone Launchpad (a resource for entrepreneurs on campus) to found the code school after that conversation. And I’ve been honored to be part of the founding team. We’ve been successful at training absolute novices with no coding skills to get full time development as junior web developers. Our first and second cohorts have attained at least 95% placement with an annualized wage increase that amounts to over $30K more income. The reason for siting our success isn’t to sell our school. We have professional marketing people from the community (often probono) already doing that better than I could. The reason to site our success is to hopefully help motivate you to look into the agile philosophy and practices that have supported and been foundational in our success at helping students learn rapidly.

How have agile philosophy and practices been incorporated into the school? We start our 12 week class the first day by briefly explaining the Agile Manifesto which we leave on the walls of the school. We explain Scrum, and we employ it with a week long “Sprint” that includes a flexible plan for the week on Monday that includes some of expected subject matter (though each week’s plan is always adjusted based on students needs, visiting mentors and employers who might share what their company does), and a demo and retrospective on Friday. The plan is on a kanban board, also on the wall. We start each day with a short standup meeting that incorporates the Core Protocols check-in and a short improv game to help the team develop their social and emotional intelligence. And during the teaching process we lean heavily on mob programming so the students can learn and teach each other as well as become powerful at collaboration. So most of the work students do are in small groups of three to five.

For people visiting our class, the level of trust and cooperation are very high. The informal atmosphere encourages vigorous engagement, and often requires breaks. Sometimes they’ll enjoy a humorous video together or a video game. There is frequent laughter, as well as staring at the screen working on a problem together. Student teams often take control of the set up of their desks during projects for their own needs. There are post-its and diagrams on all the walls. Although we have a course plan that works, most of the learning and the assessments are self-directed and managed. But we keep learning and adjusting, so what happens each week is a new adventure.

Although Montana Code School has definitely been powerfully influenced by agile philosophy and practices from the community of practitioners, and it is a cornerstone of our success, I’d really balk at the question “Is Montana Code School Agile?” After a week at the amazing Agile 2016 conference in Atlanta (the biggest conference ever for agile practitioners, which sold out at 2,500 attendees from all over the world), if you think you know what Agile is, or that you can tick a box and say “we’re Agile”, you’ve missed the point. Agility is a direction and a journey that never ends. Joshua Kerievsky‘s opening keynote moved many of us to update our understanding of the Agile Manifesto to a more modern approach that goes beyond a software focus to something more comprehensive: making people awesome, ensuring safety, continuous delivery of value, and rapid learning. Montana Code School continues to work on learning how to get better at each of these. Agile is a journey.

Most of you are probably familiar with the adage, “Physician, Heal Thyself!” The miracle of internet search revealed to me that this actually came from the New Testament as a quote of Jesus from an even older proverb. The meaning might seem to be transparent, which is that healers should use their own knowledge on themselves before attempting to use it on others.

As a student of coaching, this simple meaning was what came up for me on a phone call with a master coach, Michael Spayd. Michael along with Lyssa Adkins, author of the book Coaching Agile Teams, are working together to advance the practice of coaching in the world of agile software development. When most people think of the term “coach”, they probably see someone on a football field or basketball court on the sidelines giving guidance and helping the team perform while not actually playing the game him (or her) self. The closest people come to coaching regarding sports is probably playing something like fantasy basketball or other fantasy sports and trying to win the league table.

But the term “coaching” as intended in this article comes out of the increasingly relevant field of professional and life coaching. The International Coaching Federation defines coaching as “partnering with clients in a thought-provoking and creative process that inspires them to maximize their personal and professional potential.” There are executive coaches, success coaches, and many other “niches”.

Alright, so I just completed Coaching Fundamentals, the first class of the Coaches Training Institute (CTI), which is one of the leading coaching training and certification organizations. It was inspiring being with such a diverse group of people who wanted to help others – from technologists to teachers to managers to real estate brokers. What strikes me most about coaching as taught by CTI is “nobody gets to be wrong”, which means that the relationship between coach and client works best when you go outside of evaluation. In other words, good coaching is not about handing out grades. We’re not in school any more. Coaching especially isn’t about making judgements. And this can be quite tricky. I wonder if a good researcher has measured how much of most of our self-talk is evaluating and judging whether we’re getting it “right”? And what’s funny, is that judging and evaluating itself isn’t ‘wrong’ either.

So when I thought “Coach, Coach Thyself!”, I think mostly for me that was about doing what the manual of coaching as taught by CTI teaches. Here’s a quote from the beginning of Co-Active Coaching: “Naturally Creative, Resourceful, and Whole – The primary building block for all co-active coaching is this: Clients have the answers or they can find the answers. From the co-active coach’s point of view, nothing is wrong or broken, and there is no need to fix the client. The coach does not deliver answers; the coach asks questions and invites discovery.”

Wow, that’s a refreshing way to look at ourselves too. Imagine if we stopped being the judge and stern schoolmaster to ourselves, and instead we were coaches that were curious, asked useful questions that encouraged discovery rather than self-judgement.

I wonder how I might start asking myself better questions and be a better coach to myself? And maybe how can I put away that ugly free clip art whistle too?

Some have said that the mind is like a parachute. It has to be open in order to function. Contrasting that, the street wisdom I’ve heard is that if you keep your mind open, people will throw their garbage in it. Certainly openness is a virtue, and in what way and what context?

There have been a number of articles in my blog about Agile Software Development, and in this entry we’ll take a look at the project management framework called OpenAgile, which might help us also understand the meaning and value of “open”. And much like in software development we help to manage it using software deployment, making it available to everyone, we can understand the value of “open”.

Before we talk about OpenAgile we need to set the stage. If you’ve been involved to any depth in any human affair, there’s going to be some dirty laundry. It doesn’t matter if it’s a family, or a business, or a charity. Agile Software Development was intended to improve the bureaucratic and oppressive management structures in place in large corporate software development teams. Much like how sites like Fileproto.com try to open software up to the world, so too did we want to open up the discussion and integration between the development and the democracy that goes into making said software. To find out what goes into the development of an enterprise app, read Saleforce’s article on the state of development of such applications. That is why so many software developers prefered to work from home through companies such as Clevertech. I’m deeply grateful for the changes that this movement has made in my profession as a software developer even if there is still a long way yet to go. The most successful system under the “Agile” transformation umbrella has been by far, Scrum. Now as exciting and juicy as conflict and controversy can be, it can also be tawdry. So rather than digging into the trash for trash’s sake, I’ll only reflect some of what I know to help understand perhaps at least some of my interest in the OpenAgile framework.

Although Scrum appears to have roots that trace back to Japan in the 1980’s, most people credit Scrum for software development to Ken Schwaber, founder of both the Scrum Alliance and the Agile Alliance. Ken Schwaber’s book, Agile Software Development with Scrum, co-authored with Mike Beedle, is the standard reference (although many other books on Scrum have been written.) In 2010, my company SAP had Ken Schwaber speak to its employees and Ken personally claimed the “blame” for Scrum. But in 2009, the board of the very Scrum Alliance Ken had founded unanimously asked him to resign. It is quite interesting to read Ken’s account of his “resignation”, and his reasons for founding yet another organization. Another more recent resignation from the Scrum Alliance came from its Creative Director, Tobias Meyer.

Both Tobias’s and Ken’s posts about their resignations speak to a conflict of vision contrasting mission against money. As a member myself of the Scrum Alliance, losing these two visionaries is a clear loss to the organization, and it raises many questions. And although it may be too soon to tell whether OpenAgile answers at least some of those questions, I’m very grateful that they’re trying to do so and that the appearance of the OpenAgile Institute on the scene will at the very least contribute to the conversation about these questions.

According to OpenAgile.com, the approach evolved out of Mishkin Berteig‘s work as an Agile software development consultant. It was also influenced by his father, Garry Mishkin’s teaching model, called the “Learning Circle”. Mishkin wanted to share this method for any type of work, and he wanted to share it in a collaborative way. He specifically wanted it to be like an open-source software project, thus he named it OpenAgile.

Having read the OpenAgile “Readiness Primer”, and having passed the “Readiness Test”, there is so much to love in OpenAgile. It simplifies much of the structure of iterative development while delineating in more detail many of the virtues required to make a team successful at getting work done collaboratively. I’m eager to learn more, yet this article wrestles with that sticky word, “Open”. How is OpenAgile Open? What does it mean to be Open?

The open-source movement attempted to free software developers from getting stopped by the barbed wire of patent law and copyright intellectual property claims by licensing the “source” code for software in a way that would allow others to copy and alter the “secret sauce” inside the software as long as they passed on the same open source license to all their users. This model has become extremely successful, and much of the worlds computers run this way. It engenders active user and developer communities who write code, find problems, fix problems, and give their fixes back to the community as a whole – usually without even getting paid for all their contributions.

On the face of it, OpenAgile is not “Open Source” in the common way of understanding it. The license on their website allows for people to copy and distribute the content, but not to alter or derive other works from it. In other words, if you see an improvement you might want to make to OpenAgile – you would be breaking the law to do so without getting permission from the OpenAgile Institute. I suspect that within the OpenAgile community, there is much more openness to collaboration. But this openness is not legally granted to the general public.

Before going any further, let’s take a pause and look deeper into openness. When I was going to college, I recall a Woody Allen movie in which nine year old Alvy Singer stops doing his homework because the universe is expanding, which to him means that everything is going to break apart and so there’s no point to it all. In college there was also for me a lot of talk about entropy and the laws of thermodynamics, which basically says that a system tends towards maximum disorder. Everything eventually falls apart. It seemed a dismal but fundamental law of the universe. But after college I came across the work of Ilya Prigogene which really opened my mind (pun intended). It turns out that, yes, systems tend to fall apart – if they are closed. But all living systems are in fact open systems. They receive inputs in the form of sunlight, air, water, food, and they release what they don’t need. Open systems can in fact become more complex and develop higher and higher levels of order. They can evolve.

Perhaps this is why democracies have been much more vibrant and productive than closed societies, and why collaborative processes like Scrum and OpenAgile work. It certainly plays a part in the success of Open Space Technology about which I’ve written many times such as here and here and here. In an Open Space Technology style meeting or conference, the agenda is fully open to every attendee to talk about whatever they want to talk about. And every attendee is also free to come and go as they please. You can talk about whatever you want to, and you are given a chance to invite all the attendees to come to your session. This kind of openness enables the system to organize itself. It enables it to evolve.

In fact I only know about OpenAgile because of Open Space Technology (OST). It was at the amazing OST event, Scrum Beyond Software, that I first heard about OpenAgile. And then at the OST event, AgileOpen NorCal 2010 in San Francisco last October, I attended a presentation that David Parker gave about it. David is the current Executive Director of the OpenAgile Institute.

If it seems I’m being critical of OpenAgile, perhaps it is because I’m both disappointed by it and excited by it at the same time. I’d been fortunate enough to spend more time with David Parker at Lyssa Adkin’s most excellent Coaching Agile Teams class last November, and his enthusiasm about OpenAgile is infectious. The topics that OpenAgile covers, the virtues its extols, and even the books it recommends are excellent.

I hope that OpenAgile can grow more and more into the “open” that its name invokes. I asked David some of these questions at his session in San Francisco last year. How will the OpenAgile framework evolve? Will they give permission for derivative works to be generated? If not, how will the framework be open to submitted contributions? And how will the board of directors be constituted in the future? Will the membership be able to vote for the board members? Interestingly, the Agile Alliance gives members the opportunity to vote for board members. But the Scrum Alliance does not. This fact does not make me comfortable about the Scrum Alliance.

And here is one last question about the meaning and value of “open”. What place do certifications have in a dynamic open system? The Agile Alliance has made a specific policy not to pursue certifications. Harrison Owen did the same for Open Space Technology. Yet the presence of certifications helped make Scrum extremely popular by helping to spawn an industry of Certified Scrum Trainers. Isn’t it interesting that the financial success of Scrum certifications also seems to have led to the ejection of some of the foundational and creative forces behind Scrum such as Ken Schwaber and Tobias Meyer? Is there a way to have both certifications as well as openness?

Maybe there is no answer yet to these questions. And maybe, that’s also a part of openness – not always knowing the answer.

A few weeks ago I had a problem. I had attended a computer conference, Agile 2010, in Orlando this past August which also meant I needed to do a presentation for my colleagues about what I learned. If you have a presentation coming up, take a look at local tech supplies that could help for example commercial av systems bluffton sc, to give you presentation that extra professional edge. It’s important that you’ve prepared everything for your presentation. All things need to be considered. For example, when one of my friends delivered a presentation at his office, he needed to purchase a whiteboard beforehand from somewhere like Writey (HTTPS://WRITEYBOARDS.COM/PRODUCTS/WHITEBOARD) for example. Luckily, we’ve got a whiteboard, but that’s something that needs to be considered because whiteboards are, usually, an essential part of a presentation.

Planning a presentation is always a source of stress, so I thought I’d try an experiment. What if I let the presentation organize itself? I guess anyone with any knowledge of the different types of projector are fully aware of how effective their organizational qualities are.

Before I get into the way I let the presentation do the work, you need to know a little about the topic, “Agile Software”. The term was born almost 10 years ago by some amazing software practitioners who wanted something more lightweight than the heavy, painful, and bureaucratic methods that were dominant at the time. The term “lightweight” didn’t really evoke a lot of confidence, so they picked the term “agile”. They did this at a resort in Utah between ski runs where they also wrote and signed the Agile Software Manifesto. It’s picked up a lot of steam since the early days when it was considered heresy, a fad, or even a cult. These days, it’s most definitely well into the Early Majority part of the diffusion of innovation curve, and it seems clear that it will soon be the dominant way humans make software.

Although this might seem to be something purely for the techies, geeks, and their bosses – the values and philosophy behind agile software development methods extend well beyond software. In fact, I got the idea for how to organize my presentation from a conference convened by the Scrum Alliance in Chandler, Arizona called Scrum Beyond Software. What is Scrum? One of the main techniques in the agile toolkit is called “Scrum”. It was stolen from the sport rugby, but the general idea behind scrum is that you let the team organize itself around the work that it is tasked to do. The boss might tell the team what it needs to make for the customer, but the team (not the boss) decides how to do it. For the team, the key phrase is “organize itself”, or self-organizing.

Without diving deep into the term self-organizing, let’s say it contrasts with the old purely hierarchical “command and control” style of management. So what does that have to do with getting out of a lot of preparation work for my presentation?

At Scrum Beyond Software, an organizational guru, Jim Benson, spoke about a new tool in the agile toolkit, called Kanban. Kanban is from Lean Manufacturing. If you haven’t heard about Lean – it’s the way that Toyota beat the pants off of most American automakers. Taiichi Ohno found that Toyota after WWII had few customers for the cars they were making. In an effort to reduce waste, they only built cars that customers were ready to buy. It’s a bit more than that – but one of the things that has been adopted from all the Lean techniques into the Software world is called Kanban. It just means “sign” or “visual card” in Japanese – and the basic idea is pretty simple.

With Kanban, you look at all the steps in your process, and draw those steps as columns on a wall. Then you use a card, or a post-it, to represent all the production parts (or to-do items). All the inventory moves from left to right. When a card moves into the last column on the right, it means the piece of work is complete. Jim Benson explained that the most important idea in Kanban is to get a picture of the work you are doing.

Now we’re ready to talk about how I let my presentation organize itself. Jim Benson started the Lean Coffee Seattle discussion group in a coffee shop and he spoke about how he runs the group at the Scrum Beyond Software event. Jim starts each one of these sessions by gathering from the participants all the topics they want to talk about and put the topics on stickies which gather up in the left most column of a large three column table chart. That column he labels “To Be Discussed”. They quickly vote on the topics, and they proceed from the topics with the most votes to those with the least. When they discuss a topic, Jim moves it to the middle “Discussing” column. And when they finish, he moves it to the right “Discussed” column. This helps everyone see what they have coming up, what they’re doing, and what they’ve finished.

So rather than generate a large deck of Powerpoint slides to help people get in a little nap after lunch while I droned on reading my slides – I went to an office supply store, bought some huge 4-6 inch post-its, and put all my topics on the post-its in large letters. I posted those on a large whiteboard in the conference room in a three column table, just like Jim Benson’s Lean Coffee Seattle. Everyone voted, including folks online, by letting everyone vote for three topics. We tallied up the score, which gave an easy ranking order. When I started talking about something, I moved the post-it to the middle “discussing” column, and when we finished, I moved it to the “Done” column.

I guess the presentation didn’t exactly write itself, but rather than make it all about me talking at my audience, I also generated a few questions on each of the topics so that I could engage the audience, and I also provided a Wiki page of links for each of the topics so that the audience could follow up after the talk.

The end result – we had a lot of very engaged people during the talk. I received a number of compliments afterwards. And I didn’t have to stay up until the wee hours the night before creating my slides, so I was a lot more relaxed and a lot less tired and burned out after the presentation.