Category Archives: software

Smaller User Stories Podcast

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.

Cheers,

Chris Sims

Share it!

How Can Our Scrum Team Improve Product Quality?

XZ, a participant in a public Certified ScrumMaster workshop that I gave in Beijing last week, asked me how his scrum team could improve their software product’s quality. I thought that the answer would be of general interest, so here it is.

Hi Chris,

Thank you for giving us 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 setup, yet. Without automation of the regressions tests, unit test and pair-programming, how can our scrum team improve the quality of the product?

XZ

Dear XZ,

First, let me encourage you to keep up the work to automate your regression tests; few things have as big a return on investment. It enables the team to move much faster, and make changes and improvements in the code 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.

Code reviews
A code review is a meeting between 2 or more developers where they look at some code and talk about how it could be improved. This isn’t about finding fault, or showing how much better or smarter one developer is. The simple fact is that all code can be improved, and having multiple people look at it can lead to improvement. It also leads to learning. The participants in the code review share and learn techniques that will make them all better coders. Thus, all future code will be improved, not just the code currently being reviewed.

By the way, one more reason to consider pair-programming is that it gives you continuous real-time code review. I’ve seen a few teams adopt code reviews, and then move on to pair-programming, so that they could speed-up the feedback loop, and learning, that their code reviews were providing.

Frequent Testing by Real Users
If you want a reality check on the quality and usability of your new functionality, just grab a real user and ask them to accomplish something with it. This doesn’t have to be a big deal; 10 minutes might be all you need. If you don’t have a real user handy, get as close to real as you can. A team I was on had one of the customer support people try to use new features. They were close enough to ‘real’ to know how a real user would approach the task and what they would expect the software to do. Note, I’m not talking about full-blown user acceptance testing here. That’s good stuff too, but I’m talking about ad-hoc testing, as soon as possible. Just added the ability to make text bold? Grab a user (or support person, or your mom) and ask them to make some text bold, without explaining to them how to do it. You will probably learn something about the usability and quality of what you have built.

Testing Bashes
A testing bash, or testing party, is time set aside for the whole team to get in a room and test the product, in any way they can think of. The idea is to make it a fun, interactive, and social event. Who can find the most edge cases? The most unusual input? Let’s explore the edges of performance with big input, or on a machine that is running very slowly, or with low memory. Are there configurations we haven’t thought of? The idea is to encourage creativity. The testing bash should not replace your regular testing techniques, and alone it won’t provide sufficient testing to ship with confidence, but you may find it a worth-while addition to your testing regiment. One of the things I like about a testing bash is that it gets the whole team involved in testing the product. Which leads me to…

Whole Team Ownership of Quality and Testing
In my work with new scrum teams, I often find that ‘the team’ is really two teams: the coders and the testers. A team is a relatively small group of people working interdependently towards a common goal. For a good scrum team, the common goal is a shippable product. Of course, the product isn’t shippable until the coding and testing (and probably other stuff too) is done. If we allow the coders to think that they’ve done their job as soon the code is written, we are undermining the team and reducing our chances of shipping a quality product any time soon. We want the whole team to be responsible for creating shippable product. That means writing code, and testing it as well.

Very often, I see teams that can write new code at a much faster rate than they can test. In these cases, if the coders only code, the testers will never really catch up. Better that the coders stop coding and help the testers test! Several powerful things happen when coders do this. First, they start to take ownership for delivery of product, not just code. Second, the coders often find ways to accelerate the testing. You want to see good test automation come together quickly? Get your production coders to write the automation code! They will be motivated to do so if they don’t get to move on to new code until the current code is fully under test.

I hope some of these ideas are helpful to you.

Cheers,

Chris

Share it!

What Does Your Team Need? Girl Power!

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.

Share it!

Do talentless hacks make the best leaders?

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.

Share it!

What I learned at Startup Weekend SF: Agility is the state of nature

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!

Share it!

Agile Ontologies: Why the customer is always right, even when they’re wrong

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:

I use a few online services, and you can tell which ones have adopted the philosophy of incremental product roll-out.

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:

This seems more like a web design  problem than a development problem to me. A product can be designed from the outset so that you can add to it without disrupting the work flows users have established. A top level menu system whose categories are general enough that you can fit almost any new feature under them, for example, allows you to release new features iteratively and allow users to discover what they need as the need arises. The problem may lie in treating each new feature as a "release" by shifting features around and making big front page announcements ala "Now with extra cleaning power!!!!" Constant improvement is not a series of events, and every addition doesn't need to be celebrated. Most of the time, it's enough to blog the new feature and move on. This is better than saving up features and doing a faux release. Why would you make an innovative new process mimic an obsolete process? Better to adapt how you think about the product instead.

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.

Share it!

What exactly is agile design? Or better yet, what could it be?

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.

Share it!

The Most Effective Ways to Improve Software Quality at ST&P Conference

STP Logo 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.

Tier One
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)

Tier Two
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
Unit testing
Proof of concept demos

Tier Three
Sufficient time and resources
Control of QA lab, clean testing environment
Virtual machines
Build management integration tool that includes automation testing
Scope control

Tier Four
QA Diplomacy
Code reviews
Having developers do QA
QA teams with broad diversified skills
Code coverage

Tier Five
End-to-end testing, downstream, integrated
Gap analysis, BA/QA/Dev
Feature freeze
Documentation of old pieces of the system
Training tools

Tier Six
Giving QA tools and control over their environment
Entry criteria checklist
Docs

Tier Seven
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.

Cheers,

Chris

Share it!

.NOT Again!

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.

Problem 1
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.

Problem 2
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.

Cheers,

Chris

Share it!

P-Camp – Agile 101

Agile 101

I spent yesterday at p-camp, an unconference for agile product managers. The event was hosted at Yahoo! and put on by the folks at Enthiosys. I led two sessions: Agile 101, and Why do Agile Projects Succeed (or Fail)? This post is about the Agile 101 session. Watch for future posts about my other session, and some more pictures.

The Turnout
The intention of this session was to provide an overview of what “agile” is, for those who are new to agile. Honestly, I wasn’t sure how many folks would turn out, given that this was a conference explicitly for agile product managers. Well, the room was full. Even better, the energy and curiosity levels were sky-high.

The Problem
This is where it got tough for me. I prefer doing interactive sessions, as opposed to “stand and deliver” lectures. With only 45 minutes to work with, I only got through the first half of my slides. This is good for all of the people who got their questions answered; I’m happy that they got the information that they needed. Still, I felt like there was a lot of “the basics” that didn’t get covered. This was confirmed by number of folks who came up afterward and asked for the slides.

The Solution
I promised that I would put my slides up, and here they are. I find that slides alone don’t really tell the story. So, I’ve decided to make the following special p-camp offer:

I’ll do the long or short version of Agile 101 for your organization for free.

The regular prices for these talks are $1000 and $500 respectively. Send an email to this address: FreeAgile101@AgileLearningLabs.com to claim your free session.

My thanks to everyone who came out and made the sessions so much fun.

Cheers,

Chris

Share it!