Inspired by the Toyota Production System, Mary and Tom Poppendieck describe the seven wastes of software development as: partially done work, extra features, relearning, handoffs, delays, task switching, and defects. In this video from the February Scrum Professionals MeetUp, Kim Poremski explores the seven wastes and introduces tools and techniques to overcome the seven wastes and unlock organizational agility and scalability.
“It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is most adaptable to change.”
— Charles Darwin
Just about everyone agrees that being “adaptable to change” is important.
At the same time, many people believe that we’re entering an age of acceleration. The models underlying society at every level are being redefined as traditional linear models of change give way to the explosive power of exponential growth. According to computer scientist, inventor and futurist Ray Kurzweil:
“The 21st century will be equivalent to 20,000 years of progress at today’s rate of progress; organizations have to be able to redefine themselves at a faster and faster pace.”
At all levels of engineering, we need a management methodology that is “most adaptable to change.”
Is “Agile” the answer? When we ask people to voice their opinions, doubts emerge around the concept of “agile methodologies.” Is it a new buzzword, yet another management fad or a new paradigm for surviving and thriving in times of rapid change? Or is there something better on the horizon?
Join Cathy Simpson of Agile Learning Labs to explore these questions at the next IEEE Technology and Engineering Management Society meeting on April 2, 2015. In this talk, we will look for the “core of agile” that will endure beyond the fad. We will address agile in context. Everything that is old is new again; and perhaps we will discover together that we’ve been agile all along. We just didn’t have the context to know it.
By Hillary Johnson
Last weekend, Chris and I attended a marvelous event called Dare 2B Digital, aimed at addressing the gender gap in computer science careers, and at which 7th through 10th grade girls got to play at writing code, crafting business plans, and other techie things.
We held a session called "Teamstorming," leading a group of enthusiastic students in a series of the same learning games we use to teach teams of software developers on big, important enterprise projects to work together collaboratively.
We were completely blown away. The girls weren't just good: they were great. This was the most quick-witted, productive, outgoing and naturally cooperative group of individuals we've ever had the pleasure of teaching, by a significant margin. Chris and I have both mentioned to several people now our experience of finding the teenaged girls smarter, stronger, faster and sharper than their elders of any gender, and have heard a few theories about why this might be, the top three being:
They are unspoiled.
They are female.
They are female and unspoiled.
We laughed, too. But each of these notions has some merit. First, there is the unsullied youth theory: It seems patently obvious that many adults have a great deal of wariness, and weariness, to overcome before they are open to participating freely in a game-based exercise. Our teaching style is based entirely around games and simulations, and the younger a student is, the closer she is to the memory of learning almost entirely though play. It is not, however, particularly true that children are born collaborators, as any parent whose pre-school has a biter enrolled can tell you.
As for the gender question: Are females, by nature or nurture, better collaborators and problem solvers than males? To whatever extent our temperaments are deterministic, my hunch is that girls would respond better to the collaborative exercises, and the boys to the competitive ones. There is research-based evidence that there are gender-based differences in learning styles, but the same research indicates that the variation between individuals is greater than the variation between the genders.
So yes, the girls may benefit from being both female and unspoiled, but this doesn't mean they are superior to the male and the spoiled, it just means they're naturally suited to collaboration and have nothing to unlearn as they encounter collaborative situations.
But by adulthood, we are all engaged in activities that may or may not speak to our true natures. Girls don't tend to play with toy cars, but they grow up to drive real cars in the same numbers as men. And if you believe insurance companies' actuarial tables, they grow up to be the better drivers. On the flip side, I think this means that boys can grow up to be fine collaborators, as good as or better than their female counterparts, despite their greater inclination toward competitive styles.
I am not a big fan of determinism. Things do come out in the wash, and in the long run, even unlearning can be a productive process. As Chris will tell you, part of the reason he values Agile so much is that teamwork and collaboration do not always come naturally to him–he was once a boy who played with cars, after all. He has enjoyed being in a traditional leadership role, and can remember exactly what it was like to resist the urge to "help" a team, instead letting them solve their own problems through self-organization. Which is why he is good at teaching Agile techniques, especially to people who have a lot of un-learning of traditional top-down management styles to do.
The clear outcome, to me, is that the gender bias in the field of software development that persists today is entirely bogus. If boys have an edge when it comes to math–hence their delight in code–and girls have an edge when it comes to collaboration, then it seems stupefyingly clear to me that you're most likely to have a high-functioning team if you have both styles well represented, with plenty of room allowed for something even more important: individuality.
If you want to hear Chris explain agile in layman's terms, have a listen to this episode of the Cranky Middle Manger Show, where Chris is the featured guest. The show is hosted by our friend, Wayne Turmel, who is jovially cranky in a way that only a stand-up comic-turned-management trainer can be.
We did a pilot for a two day course with Wayne in Chicago last year, aimed at introducing newly-promoted individual contributors to the dark arts of management. It was a lot of fun, and would be even more fun to do in-house at your company now that you have a hiring freeze and need to bootstrap your junior people into management… but I digress.
Wayne dedicates each show to a historical figure; it's always someone fascinating you've never heard of, and it's always eerily apt–don't know how he does it. This episode is dedicated to Gaius Marius, "reorganization consultant to the Roman Army."
Another Cranky standard, the quote of the week, is from the Kaballah, and is also astonishingly relevant to agile practice:
On Wednesday, I’m doing a presentation on doing presentations. One of the little gems that I was looking forward to passing on was Lucky Oliver. It has been my favorite source for images for presentations and the web. The quality and variety of the images has been consistently great, and the prices were more than affordable. Today I discovered that Lucky Oliver will be closing down on May 15th. I’m sad to be losing this source for great photos, and sad to see the business fail. Best of luck to Bryan, and everyone else at Lucky Oliver.
Now where am I going to get my images? Any suggestions?
I’m back home, in the San Francisco Bay Area, after a couple of weeks on the road. I went to Chicago for the Scrum Gathering, where I presented Agile 101, and What Makes Agile Projects Succeed (or Fail)? I also facilitated a couple of open space sessions. Notes from one of those, Let’s Practice Agile Estimation, can be found here on the Agile Alliance Wiki.
After Chicago, I headed up north to Canada, where I ran a half-day workshop From Tester to Leader as part of the KWSQA’s Targeting Quality conference. I’ll be posting some notes from that session soon.
For the moment, I’m catching up and getting ready for a busy week. This Wednesday, the Bay Area Engineering Managers Support Group is meeting. In addition to the usual peer-support and problem-solving session, I’ll be doing a presentation on doing presentations. Perhaps next month I’ll do a presentation on doing presentations on doing presentations. OK, maybe not. This event is free, and includes some good food, thanks to our sponsors: The Technical Management Institute and Rearden Commerce. You can RSVP here.
Thursday, the IEEE Technical Management Council of Silicon Valley is putting on a dinner event featuring Elisabeth Pate-Cornell, Chair of Management Science and Engineering at Stanford. Her topic for the evening is Risk Analysis as Decision Support. You can get more information and RSVP here.
For those of you who couldn’t be there, here are Abe‘s Powerpoint slides.
Managers, as well as engineers, are occasionally called on to give presentations. Preparation and practice are the biggest ingredients in a successful presentation. You don’t want the big day to be the first time you’ve given the presentation. Practice out loud, first by yourself and then in front of some friends or colleagues who can give you constructive criticism. Practice with the actual equipment that you will be using, preferably in the actual room where you will give the final presentation. The more you rehearse, the lower the chances of something going wrong. Sometimes, things still go wrong. John West tells the story of one such occasion, and how he did a respectable job recovering, in this post to Leading from the Trenches.