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.
I recently had a conversation with Dave, over at the Mastering Business Analysis podcast, about splitting big user stories down into smaller stories. The interview was a lot of fun and it’s available now. You can get it direct from the Mastering Business Analysis website, or point your podcatcher at one of these links:
You can also read about splitting user stories at SmallerStories.com.
Thank you for the certified scrum master training last week in Beijing. Your training is very impressive, and I appreciate it a lot. I asked you a lot of questions; may I ask one more? In our company, the automation for regression tests hasn’t been set up, yet. Without automation of the regressions tests, unit test, and pair-programming, how can our scrum team improve the quality of the product?
First, let me encourage you to keep up the work to automate your regression tests. Few things have as big a return on investment. Test automation enables the team to move much faster and make improvements fearlessly. The other practices you mention: unit testing and pair programming, are also great practices, and I encourage your team to try them too.
Having said that, your question was what else could your team do. Additional practices I would recommend your team consider are: code reviews, frequent testing by real users, testing bashes, and whole-team ownership of quality and testing.
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.
Journalism is a lot like software development (or anything else for that matter) in that it's common practice for top performers to eventually move into management, in large part because that also happens to be the path to financial well-being. The worst editors I've ever worked for, and I've worked for a lot in a 20 year freelance career, were genius writers turned editor. The best editors where those who had experience working as writers, but never felt that role was a good fit. Sometimes they had even failed as writers. As editors, these people appreciated and respected their writers precisely because: 1) they knew how challenging the job was, 2) they were never inclined to think they could do a task better themselves, 3) they didn't perceive themselves as having risen "above" those they managed, but as having taken a different path.
The point being, we're all talentless hacks at something, and the sooner we recognize it, the better we'll each be at what we're actually good at.
I was prompted to reflect on all of this by Alistair Cockburn's post about a recent discussion at the Salt Lake City Agile Roundtable where everyone offered up advice to a new team lead, ie, one promoted from star programmer to manager. It's a great collection of thoughts, listed as bullet points, including "In almost any high-skill arena, taking the top performers and making them coaches/managers is almost always a disaster." And, "How can we make it acceptable to promote the people who may not be the top technical performers?!?" Another mentioned the need for companies to create technical tracks that don't require one to move into management to move up.
All of this leads me back to the notion that hierarchy is a poor framework for knowledge work. The native structure of a productive creative team is the network, a system comprised of various nodes, gaining strength through interconnectedness. Think of it as a geodesic dome, rather than a skyscraper. A team need people in roles, rather than positions. What we have a hard time wrapping our minds around is the concept of manager as an equal, not a superior.
It strikes me that the role of Scrum Master is designed to function in this way, and it's interesting that one of the challenges people trying to grasp Scrum for the first time is wrapping their minds around the idea that the Scrum Master isn't a leader in the traditional sense, but a facilitator. Maybe it's the rather unfortunately macho term itself–anyone who calls themselves "master" anything can quite naturally be assumed to be a bit of an assclown.
The notion of servant leadership is also aimed at correcting that very imbalance, but
fails because it merely inverts the hierarchy, rather than dismantling or de-emphasizing
it–it's still a hierarchy, and worse, it's phony. The only thing more arrogant than someone who calls themselves a "master" is someone who calls themselves a "servant." Sheesh!
What teams need are "peer leaders," those
with a talent for human interaction who can be charged with maintaining
the flow: a "Scrum Keeper" if you will.
What's a good mother/son spring break activity? Why, going to Startup Weekend and spending 50 hours building a company with ten total strangers. Perfect because my 17 year-old vastly prefers the company of adults to that of other teenagers, and because he's been on the high school treadmill for so long that I thought it would be nice for him to see what the light at the end of the tunnel might look like–that the world of work can be a rather thrilling place.
Several years ago, I visited the very first Y Combinator class of college-age founders when they were only six weeks into their startups and was astounded at the number of fully functioning products. Turns out six weeks is an eternity, way more time than you need to build and launch a startup!
This weekend, 150 of us crammed into a giant room in Microsoft's Market St. facilities. We were given lots of food (thanks to Sana of Women 2.0) and very little direction. After a free-form round of idea-pitching, with coaching from the lovably dyspeptic Dave McClure (our team-member Han Pham describes his style here), we were cut loose to self-organize into teams.
Tyrone and I were interested in Connor Lee's idea for a venue-rating site for event planners (easy to build in a weekend), and Julian Bryant’s pitch for a site that would allow people to interact around pending legislation. As it turned out, Connor, who had legislative experience Tyrone and I all joined Julian, along with developers Marcus Phillips and Philipp Pfeiffenberger, SEO/Social Media/Web Marketer Aris Vlasakakis, marketing gurus Sherbeam Wright and Mariam Ishpahani, journalist Han and a couple of others who came and went over the weekend. Julian emerged as the natural leader, as well he should being a former Senate intern and Georgetown Law grad with a startup around language learning.
I have worked as an employee or long term contractor on three tech startups, one VC funded, one angel funded, and one bootstrapped. This team outshone them all in terms of raw talent, intellectual horsepower, organization, distribution of skillsets, commitment and efficiency. And we were not alone. In all, 23 teams had working demos or prototypes to share on Sunday evening, and a couple had actually launched fully functioning products (I was using Snoozemail in my gmail inbox before the evening was out). There could be no better demonstration of the power of self-organizing teams than this display of exponential creativity and productivity.
Marcus and Philipp–both Y Combinator alumni if I'm not mistaken–were curious about Agile, and we talked about it a little bit, but there really wasn't time to talk about anything but pushing our product out the door. What I found enlightening was that their native values, instincts and practices were inherently Agile. Being Web 2.0 guys who work in Ruby and Python, they have never been exposed to Waterfall. (The only team that did anything resembling a Waterfall process was the one team that had absolutely nothing to show on Sunday, having spent all their time creating specs.)
This makes me think that perhaps the best way to promote Agile is to take a cue from crime prevention and literacy drives: don't focus on reforming those who have already been "lost" to Waterfall methods; focus instead on preventing the destruction of our talent pool in the first place!
Our team, christened "Democlarity," divided rather quickly into two right-sized sub-teams (also quite Agile). Tyrone went with the bus dev side, working on business planning, market research and content creation, while I went with the development side–the first time I've ever worked on a project and not been the writer/editor. I did some HTML wireframing, then turned my attention to CSS styling while the devs blasted in the functionality.
We had technical difficulties here and there–the wifi broke, version control broke, my host account where I was hosting images while designing went down at a critical point. Marcus and I paired on merging the disparate html files, then Philipp and I paired on some last minute CSS (he is 10x faster than I am, so my main contribution was saying things like, "Can you make that greener?").
Everything got done, and Aris and Marcus had time to practice their demo pitch. We weren't live online, but we were certainly way too cool for powerpoint, and were able to show a site with functionality and an amazing amount of depth.
Aris and Marcus rocked the demo, with Phllip driving the mouse so they wouldn't have to break their patter, and we disbanded feeling like we'd accomplished something fairly spectacular and been a part of something pretty important. The Democlarity team is looking forward to a reunion in a month, and plan to continue developing what we started in an open source-ish sort of way. In the meantime, a demo of our site should be up on www.democlarity.com fairly soon.
Tyrone went back to swim team practice today, and I'm back at work too. But I learned more about teams and teamwork this weekend than I did in the previous year–and that's a year in which I wrote an Agile training manual and helped organize the Orlando Scrum Gathering's Open Space Conference. I'd highly recommend the startup weekend experience for anyone who is seriously committed to working on or with software teams–the pressure of an insane deadline like that compels you to strip everything down to the purest, simplest form: communication, decision making, work flow, product features, everything, and conversely, it also leads one to discover the enormity of one's own personal resources. We were like those people who, in a crisis, lift a car off of a person. Heady, empowering stuff.
This weekend was Startup Weekend World, with 50 cities participating. There will be another soon enough. Hope to see you there!
Craig Brown voiced a common concern project folks have in "A Downside of Agile Development?" on his Better Projects blog, writing about his fears for his company's proposed transition to Agile:
Just about every time you log in, there is another feature being promoted and presented to you for consideration. Sometimes things you were used to have moved or disappeared.
This constant change makes some products less appealing than something that is more reliable.
There are valuable lessons to be gleaned here about what Agile is failing to communicate to customers. I like to think that the customer is always right, even when they're wrong, and if they're having a problem, then there is a problem. Brown is making visible a world view problem that is hindering agile adoption.
I left a comment on Brown's blog trying to reframe the question. Here it is:
I think I only captured part of my thought process in the comment, so here's the rest of it:
The takeaway is that often the resistance to Agile, or any other new way of doing, working or living, springs from underlying assumptions that aren't being unearthed and challenged. These assumptions are not ignorant–they are unconscious, and based on experience. As change agents, it's our job to challenge and persuade, not the other way around. For a customer who has lived through Vista or iTunes 8, and maybe a buggy beta or two of their own product, announcing happily that Agile will allow you to release every week will justifiably cause panic and soulful dread. Better to say, "We can make it so you never do releases. We build and test constantly behind the scenes, and add new features without disrupting your users' workflow. You'll never have a beta or a bumpy release to contend with."
Paul Graham wrote years ago that "…designing Web-based software is like designing a city rather than a building: as well as buildings you need roads, street signs, utilities, police and fire departments, and plans for both growth and various kinds of disasters." This high-level re-imagining is what Brown really needs to hear–he needs the shining city upon the hill, and for the leap of faith we're asking him to make in joining the revolution, he ought to get it.
Someone in the audience at the Scrum Gathering keynote last week reminded us that "A good trainer can lead a horse to water, but can't make them drink. A great trainer can make them want to drink." It's not enough to offer the customer better solutions and value, we have to offer them a vision of a better world; we can't focus on delivering processes and tools; we must focus on individuals and interactions.
Chris just published an article on InfoQ called Refactoring is Not A Substitute for Design about the debate over what role design plays in agile development. The worry is that agile processes shortchange the very principles of good design, because so much of agile happens at the granular level while design is seen as a macro-level activity. But is that the case? Here is the bit that I consider Chris' main point: Big Design Up Front is not design; it is just one way to accomplish design.
Agile practitioners tend to prefer a different approach, in which the current design emerges in response to the actual functionality being supported. The design reacts and adapts to the needs of the system, which itself is constantly evolving and adapting to the needs of the customers.
Chris addresses a common misconception, that foregoing up front design in favor of an agile process is tantamount to no design at all. Yes, yes, agile is anarchistic, the sky is falling, and kids these days listen to the darnedest music, we know, we know.
It strikes me that this type of sea-change has all happened before:
When the first impressionist painters broke the rules by dispensing with classical rendering and embracing naturalistic forms and gestures, a great many people refused to call it "art." But in hindsight, we now recognize the equal level of artistry involved in making art that departed from classical norms. Just because Van Gogh didn't block and draw on the canvas with charcoal before he took up his palette knife didn't mean he lacked an eye for shape, perspective and line: in fact, art students now are taught that "You must know the rules by heart in order to break them." The expectation now is that artists will be able to break the rules, and thus they are now expected to know these things at the cellular level.
I predict that we'll look back on this change in our attitudes toward design and software in much the same way–we'll think of the curious olden days when developers were seen as code monkeys wrenching on software that someone else designed. By engaging developers in all aspects of coding, and including design and test, agile actually seeks to elevate design and function to a higher level of importance, to where it's part of everyday practice for everyone who writes code.
Software Test and Performance Conference in Boston, a group of a bout twenty software quality professionals gathered to consider the most basic and practical question of the conference: What are the things that we can do that make the biggest improvements in the quality of our software?
The idea was simple, each person would share those things that had made the biggest impact on the quality of the products they worked on. No theory or vendor hype here, just actual experience. We used the Group Wisdom Without Groupthink process, and over the course of an hour generated and ranked a list of thirty best practices. Those at the top of the list are the ones that the group identified as the most effective ways to improve the quality of a software project, based on the collective experience of the group.
Proper test planning
Simulating customer environment as closely as possible
Developer/Tester collaboration, actually talking to each other every day
Defect Tracking (workflow, reporting, and metrics)
Test cases formally reviewed by QA, Dev, and BA
Extensive & visible automated regression tests
Defect meetings to review, prioritize, and scope
Team collaboration on reviewing issues
Proof of concept demos
Sufficient time and resources
Control of QA lab, clean testing environment
Build management integration tool that includes automation testing
Having developers do QA
QA teams with broad diversified skills
End-to-end testing, downstream, integrated
Gap analysis, BA/QA/Dev
Documentation of old pieces of the system
Giving QA tools and control over their environment
Entry criteria checklist
Don’t file stupid bugs
Application training to make QA expert users
Wikis and blogs
What have you or your team found to have the biggest impact on software quality? Post a comment and share.
I am finally getting around to doing my taxes. I went out and bought Turbo Tax Home and Business, installed it, and started working. At a certain point in the process, Turbo Tax crashes. Bleh! I fire it back up and try again, same crash same place. I click the “Tell Intuit about this problem” button. It comes back with a link to a ‘fix’.
It would seem that Turbo Tax requires .NET, but will crash if you have the ‘wrong’ version of the .NET framework installed. Their ‘fix’ is to uninstall all of the installed versions, breaking who-knows what other programs that require those specific versions, rename a system directory (because uninstalling it doesn’t really make it all go away) and then install a version of .NET that Turbo Tax likes.
There are (at least) two problems with this.
If Turbo Tax is that finicky about what version of .NET it will run with, the Turbo Tax installer should sort this out. It is totally unacceptable to have the user discover this at runtime, by crashing and losing time and data.
Turbo Tax, a commercial software product that will be installed on systems with every imaginable configuration, should not depend on the .NET runtime at all. In my humble opinion, there are just too many variations of the runtime out there in the wild, and this sort of thing is bound to happen.
If you write in-house software, which will be installed on a homogenous set of systems, then .NET is great. However, if you can’t count on the configuration of the systems your product will be run on, you should probably avoid .NET like the plague. Even if your program installer gets everything right, and makes sure that the ‘right’ version of .NET is installed, it is entirely possible for that version of .NET to be uninstalled later, perhaps because the user is trying to do their taxes!
Personally, I prefer static linking as much as possible, and reducing external dependencies to a minimum. This makes your program much more robust, and is likely to greatly reduce support costs.