Archive for the ‘agile’ Tag
Some Good Specification Practices, or, I Am Out of Clever Titles
Filed under: Improving Software Development, User Stories | Tags: agile, gemba, specifications
Comments (4) This post was co-written on Google Wave with my colleague Scott C. Reynolds, who makes me insane every day. It is part of his How We Do Things series.
Where We Came From
We began our large LIS project in late 2004, starting with about 6 full months of writing specifications and designing the database. We created reams of documentation for each application complete with use cases that we knew we wouldn’t even implement until after the first version was released (sidebar: some of those still haven’t been done). We defined more than 100 tables of heavily normalized database schema. Before one line of code was written, we had spent six months of project budget.
As development continued on the project we found ourselves diverging from the specifications that had been created. The documents became little more than a roadmap, with the bold headers on functional groups and the basic usage stories becoming the guidelines that we followed. Much of the detailed specification and database schema went out the window as the system took shape and people began to see and give feedback on what was being produced. Too much specification gave us a false sense of "doing it right" and led us down many wrong paths. Balancing rework with completing planned features became a costly chore.
By the time the project was complete, it was clear that much of that up-front work had been wasted time and money. Had we top-lined the major milestones of such a large project, detailed a small set of functionality, and started developing iteratively, the system would have taken form much sooner, allowing for a tighter feedback loop and much less overall waste.
How We Do It Now
Lessons learned, we set about improving how we do specification. Scott already talked a little about this in the posts on planning, so please review those if you haven’t seen them yet (here and here).
When planning a new project of any size, we take an iterative approach. We start at a very high level, and strive to understand the goals of the project. What need does it serve? Who will be using it? Are we competing with something else for market share? Is there a strategic timeline? What’s the corporate vision here? What are the bullet points? We will fill in details later. We only want broad targets to guide us further.
When we get closer to development, we start to identify smaller chunks of functionality within each of those broad areas. This is still pretty high level, but done by business analysts and management on the IT team. We start to identify MMFs (minimal marketable features) and group them up in order of importance to help determine next steps.
MMFs in hand, we take the first one and start defining it further. This is where the information from the planning post comes in. We start to write stories (Cat has a great post detailing how to build effective stories). The other information gathered to this point sits dormant, with as little specification work done as possible, until such time as we are getting closer to working on it.
Over time, and only as needed, we put more and more specification on the system, and this is done in parallel with development. In fact, often the most specific information can only surface during development of those features, as they take shape, and as we understand how users will react. Specification should be every bit as iterative as coding.
Reduced to its essence, we JIT specification at many levels to allow maximum flexibility to change direction with minimal wasted work.
Gemba As an Essential Part of Specification
Lean has a concept of the gemba attitude and genchi genbutsu; essentially, being in the place where the action happens. Developers and business analysts have to work with the domain experts, in the place where the work happens, and observe the true workflows in place before hoping to design a system to support them. You cannot get this information from sit down meetings and emails with domain experts. You must go and see for yourself, or you will miss things.
It’s often the case that a team relies on "domain experts" to provide them with the specifications they need to build software. This is the BDUF way – gather in committee and have the all-knowing user tell you what to build. Fail.
My Experience With Gemba
Our dev team works out of the corporate office in Florida, while the actual laboratory is located in upstate New York. As a result, it is often an exercise of the imagination to figure out the best way to create things for them. Before I visited the lab, I relied on information from others, emails back and forth to the lab crews working all weird hours of the night, and my knowledge of the applications currently in existence. I really only ever got half the picture, and it was difficult to ensure that the things I was specifying would fit into the lab users workflow well without actually knowing what was going on up there. When I visited the lab my whole world was changed. Actually seeing how users interacted with the software and seeing ways they would work around what we didn’t have (open Excel or Word documents on their desktop, a wall covered in post-it notes). Just from walking around talking to people for 2 days, I probably got 50 requests. And they never would have asked for them; they would have just kept suffering. Being there showed me everything about how they worked and a million ways I could improve their lives. The experience was invaluable to both me and them, and each subsequent trip has just improved my knowledge of the way we work and the way they interact with our software.
~Cat
There is no substitute for a certain amount of domain expertise being resident in the team room. Your domain experts are experts only in their domain. They may know the workings of a histology laboratory inside and out, but if you ask them to design a system to support that lab, they’ll come back with something that looks an awful lot like excel and post-it notes.
Yes, this is real. Yes, I died a little inside.
In the next post we will talk specifically about the tools and techniques we use to specify work, and how we combine them to form complete pictures of a system (spoiler alert: it ain’t just stories).
Agile, Agile, Agile, It’s the Way to Be
Filed under: Eine Kleine Nerdmusic, Improving Software Development | Tags: agile, parody, schoolhouse rock
Comments (3) Note: This is in response to @scottdensmore’s request for software-themed Schoolhouse Rock. I didn’t really know where else to post it, plus I can whore traffic this way. Try to sing along in your head.
Agile, Agile, Agile, It’s the Way to Be
Design, code, test, deploy
You think this is the way to work? Oh boy!
Have I got a thing to show you
It’s called agile, it’s the best!
Plenty of communication
Makes it better than the rest!
You think you’ve got a great thing going
With waterfall
But how much room for change do you have?
None at all!
With agile you build in
Plenty of room for change
*some other character pops head in* “Why build it any other way? I find it rah-ther strange!”
Big design up front
Long requirements docs
Annoying when your BA is a ****
And your POs are all coooocks! *piano trill*
Can’t get answers when you need ‘em
Spec docs have no sense of totality
How will you ever satisfy
Your zero-defect mentality??
Weeellll, you’ve gotta go with agile
Make user stories follow INVEST
Back it up with good criteria
And your product will be the best!
Working software is
The primary measure of success
Use the agile way and you’ll get there
With much less streeeesssss!
Be a craftsman not a drone
Take some pride in your code
Leave your codebase clean for the next guy,
Don’t be a total chode!
Iterative development,
Continuous delivery
All these reasons add up to:
It’s the methodology for me!
*song slows, piano playing*
With a kaizen attitude
You can get there too duuuude….
*music resumes and full chorus*
Just work well with all the members on your team!
*piano closes out song*
Design, code, test, deploy
You think this is the way to work? Oh boy!
Have I got a thing to show you
It’s called agile, it’s the best!
Plenty of communication
Makes it better than the rest!
You think you’ve got a great thing going
With waterfall
But how much room for change do you have?
None at all!
With agile you build in
Plenty of room for change
*some other character pops head in* “Why build it any other way? I find it rah-ther strange!”
Big design up front
Long requirements docs
Annoying when your BA is a ****
And your POs are all coooocks! *piano trill*
Can’t get answers when you need ‘em
Spec docs have no sense of totality
How will you ever satisfy
Your zero-defect mentality??
Weeellll, you’ve gotta go with agile
Make user stories follow INVEST
Back it up with good criteria
And your product will be the best!
Working software is
The primary measure of success
Use the agile way and you’ll get there
With much less stresss!
Be a craftsman not a drone
Take some pride in your code
Leave your codebase clean for the next guy,
Don’t be a total chode
Iterative development,
Continuous delivery
All these reasons add up to:
It’s the methodology for me!
*song slows, piano playing*
With a kaizen attitude
You can get there too duuuude….
*music resumes and full chorus*
Just work well with all the members on your team!
*piano closes out song*
A Post About Kaizen in Which I Get Preachy, or, There -is- a “Try”
Filed under: Fix Your Damned Life., Improving Software Development | Tags: agile, kaizen, software improvement
Comments (5) Scott says (9:41 AM):so a guy is on a cruise ship
Scott says (9:42 AM):and they cruise near this island in the middle of the ocean and he’s on the deck looking out at the view, and sees a haggard man on the island in tattered clothes running around and waving his arms frantically
Scott says (9:43 AM): and he goes to the captain and tells him about it, and the captain says “yeah, I don’t know what’s up with that guy. we cruise by here every month and he’s always out there doing that”
Scott C. Reynolds told me this joke this morning and it really made me think.
A lot of times development teams have this problem. They are blind to the fact that something could be better. We have many times when something will get screwed up or be done poorly and no one fixes it. There are a number of reasons people will do this…laziness, unwillingness to learn, general blindness. But maybe it is because they don’t know that there is a better way to do something.
One thing I’ve taken away from this past year of change is the philosophy of kaizen. “Kaizen is a Japanese word adopted into English referring to a philosophy or practices focusing on continuous improvement in manufacturing activities, all business activities, or even all aspects of life, depending on interpretation and usage.” (Thanks, Wikipedia!) In everything I do I tell myself that I will do it better than I did yesterday but not as well as I will do it tomorrow. By doing this, by absolutely drilling it into my brain until it is part of my unconscious, I am ensuring the most quality in everything I do. If my stories aren’t comprehensive enough and my acceptance criteria not robust enough, I am sure to deeply interpret the next thing I have to write and make it more thorough.
This is how everyone should live.
Software will never be perfect, I will never be perfect, and change is a constant. These are all truths. If you can fully ingratiate the notion of kaizen into your life and try to make improvements on everything you do, you’re gold. You can’t expect to write flawless code every day, but you should expect yourself to see how you made those bugs and why you made them and figure out how to fix that in the future. If you are thrashing with something, do a little more research on it. Work a little harder. Anything you can do to make yourself better, to make your products better, is never a bad thing.
Here’s a thing: broken window theory. The gist is that if a building in a bad neighborhood has a broken window and it’s left alone, that building is more likely to get vandalized worse because the perception is that it doesn’t matter. You can find these buildings all over the place in DC in the area of the 9:30 Club (that’s all I can picture when I think of this theory). These people leave one broken window, and then people start tagging. And then they break more windows. And then they have bonfires and pee in it. Et cetera et cetera. But say someone boards up that window before the crap happens. It looks like someone cares. Maybe it still gets a little graffiti, or maybe people don’t mess with it because someone lives there or otherwise uses that building.
Get it?
Don’t just let bad code sit. Do the Boy Scout thing. Leave the campsite a little cleaner than when you found it. Don’t keep making the same mistakes and letting QA catch them and then do wasteful rework. Figure out a better solution for what you are doing, talk to someone else who knows it, read blogs. Do SOMETHING. Stagnation is the death of everything; do not let yourself become stagnant. Start improving today.
Maybe this sounds hard. Well, no one said it would be easy, least of all me.
Do a little introspection and take a look at the way you work. What are your problems? What is holding you back from being the platonic ideal of yourself? Why does your code keep getting kicked back from QA? If you just pick one thing at a time and lock it into your brain to do, you’ll be there in no time. Making too many changes at once is a sure way to fail. Your body and mind are sensitive and need time to adjust; if you want to quit smoking and lose 30 pounds and move to a new place, you’re gonna need to space those things out. You will fail at one of them. If you do not, you are a freak of nature and should be burned at the stake (I’m speaking to one person in particular). The rest of you, don’t feel so bad. There’s always room for improvement.
Plays Well With Others: Communicate or Die Trying.
Filed under: Fix Your Damned Life., Improving Software Development, User Stories | Tags: agile, communication, iterative
Leave a Comment So you’ve written some clear and concise user stories with robust and clean acceptance criteria. Good job.
You’re not done.
Because user stories are placeholders for conversation, simply writing them (no matter how fancy and thorough they are) is not enough. You need to follow through and talk with your team about what the stories entail. On our team, Wednesday is Demo Day. We do a demo of what has been developed so far for our major project, go through screens that have been designed to make sure everyone agrees with the design and functionality (and to make sure they understand what needs to be built), and go through the next MMF to be developed. At this stage people can interject with additional acceptance criteria that are needed, any concerns they have for the legality or complexity of the system, or anything else they need to voice about the upcoming work. It’s a great way to make sure everyone is on the same page and have a pretty good understanding as a team about the project as a whole, but even that is not enough.
Last weekend I was emailing back and forth with one of our developers regarding a particular story…the story was fairly confusing, partially because of the way it was written and partially because it is just a confusing piece of functionality. In the end (after maybe a dozen emails) we realized we needed a higher bandwidth conversation and input from others to really get this story locked in. When demo time came on Wednesday I found out another developer had taken and worked on the story by himself and the one I had spoken with had not ended up working on it at all. As the demo went on it became apparent that the entire thing was completely wrong. Several days of development time had now been lost on this project and we would have to scrap all of that functionality and start over. This is waste. Waste is the enemy, to be sacrificed on the altar of agile on the betrayer moon. Appropriate communication between myself and the team could have avoided this, and this example will serve as a lesson in the future (I hope).
Communication is really the key to everything. Software development has gotten so good and improved so much because of all of the communication that happens now. Think about how effective pair programming and user stories are as opposed to one dev holing up in a room with a use case and cranking something out. Being able to communicate effectively will improve your team and your product, make releases go smoother, and in general keep your life together. In the past year I have had to make a lot of changes to my life and improving my communication skills (inside and outside of work) has been the best thing I’ve ever done. If you are thrashing and can’t seem to find a good place to start making improvements, I strongly suggest taking a look at how you communicate and seeing how you can improve that.
Constructing Effective User Stories, or, My User Stories Bring All the Boys to the Yard
User stories are…
And this is where I get stuck. I’ve been so enveloped in writing user stories for the past year that I seem to have forgotten the basics. I’ve forgotten how I got to where I am now. When I started my position as a business analyst, my knowledge with software was…limited, to put it nicely. I didn’t have a damned clue about what I was doing. And The Google couldn’t help me either. Sure, I found some things, but everything I found made me look up something else. Everything was written a tier or two above where I needed it to be. I needed a really good starting point to kick me off but everything just skipped over that valley of basic knowledge and into the stuff that people really want to read.
So let me try to start from the beginning.
User stories are meant to capture the essence of the business value of a system, and are written in everyday language. For example:
As an oceanographer I need to cut open this shark so that I can see if that little Kintner boy is inside.
Ok, this is not a software requirement per se, but I am watching Jaws and it is shark week (love!), so deal with it. Here is a real user story:
As a nurse I need to be able to set my default location so that I am viewing my preferred data when I log in to the Nursing Station app.
Here is the breakdown of that story, and the basic format for user stories:
As a [role] I need [feature] so that [business value].
The nurse is the user who will be using the Nursing Station app. She needs the ability to set her default location so that she won’t have to waste time setting or selecting a location upon each login to the app. The business value implied here is that she won’t be wasting time doing this and can instead get some actual work done fast and not hate on my software for being unusable.
Depending on how long you’ve been writing user stories, you may or may not have learned a very true, key fact: users get in the way. They don’t know what they want but they will be damned sure to tell you. You will hate it. Do not count them out. Regardless of the way they present themselves, you need to come at it with the mindset to figure out the actual need there. If they are nagging you for a button or a field to enter a number, determine why they need it. If they just want it because of the way it looks or for an insignificant value/one that may a) mess with the rest of the software or b) tack a lot of development time on, probably don’t just give into their needs (in the long term they will start yelling about how long it’s taking, and when you throw that “you needed this button” back in their faces they are none too happy). Figure out why they want what they want, what purpose it serves, and if it works for all of the people who will be using the software. We don’t write code for edge cases, we make it work with edge cases.
The INVEST model
The INVEST model is the shit. It is one of the best things I have discovered for improving my user stories. This blog (http://www.agile-software-development.com/2008/04/writing-good-user-stories.html) has a really great summary of the INVEST model, which I will expound upon here:
Independent: User stories should be as independent as possible (don’t put something about a link in one story and then separate the link functionality; you’d have a dead link if the sprint wrapped and the complementary story did not get completed)
This is something I have really improved upon in my last year as BusinessCat.
1. Making stories more atomic means less of a chance for things to get tangled up and confused
2. That dead link thing? Yeah that happens. Be careful and make sure all of your stories and acceptance criteria are complete. See my thoughts on MMFs at the end of this beast.
Negotiable: User stories are not a contract; they are reminders for the team to discuss and collaborate to clarify the details near time of development
What a user story really is is a placeholder for a conversation. We’ve gotten away from writing strict, rigid use cases and into these user stories, which are much better for the way the business world really works. By writing a user story this way, I am opening up a higher bandwidth conversation. Instead of a developer just reading what I have and doing it word for word, now we can talk about things and make sure everyone is on the same page and fully understands the business value and the needs of the user. I like that Kelly specified “near time of development” though; that’s one thing you’ll always find: CHANGE IS A CONSTANT. Friggin annoying, but it is inevitable. The closer to development time you talk about something the more likely it is that you’ll have the best information and the most clarity on the item.
“A fundamental lean principle is to delay decisions until the last possible moment so you can make the most informed decision possible.” – Mary Poppendieck, Lean Software Development: An Agile Toolkit
Valuable: User stories should be valuable to the user and written in user language
User stories are user stories. So put on a user hat and write it. You should never have anything like this in a story:
“title attribute displaying formatted address when user mouses over”
I got stuck putting this in a story the other day by a higher-up and I was really mad at myself for letting it in there. Yes, it will tell the developer what to do, but no user would write that. Leave implementation details to the developer. Describe the desired result, not the implementation. What it should say is:
“display tooltip when hovering over address”
There is still a little bit of implementation language in this, but it’s an abstraction higher than spelling out the html. Sometimes you can only refactor so far; I would be happy to leave this in one of our stories.
When I have the conversation with my developers we can talk about this to make sure they understand it, but it’s terrible to have the former in a user story. If I don’t understand it, I shouldn’t be writing it. And I am the user.
Estimable: User stories need to be possible to estimate; they need to provide enough information to estimate, without being too detailed
This goes back to stories being atomic. When we write stories on my team, we make them no larger than 3 days worth of work. If the developers do not agree that it will take three days or less, it’s time to refactor. This isn’t ideal for every team, but we have worked to become a sophisticated enough team that we can work like this. Plus, it’s ideal. If you have massive stories there is more chance for stuff to get lost or overlooked, things will be harder to test, and general craposity will ensue. In summation: Yer doin it wrong.
Small: User stories should be small. Not too small. But not too big.
See above. D’oh. Additionally, don’t be discouraged when you need to refactor your stories a bah-zillion times to get them to be more atomic. You will not get it right at first (I sure as hell didn’t), and a continuous improvement mindset is an absolute necessity to success. Be willing to give it a go, observe the results, and adjust, as an ongoing process.
Testable: Need to be worded in a way that is testable and not too subjective; must provide clear details of how the user story will be tested
When QA tests, they run through many, many different scenarios. If your stories are too rigid they won’t necessarily hit all of the possible scenarios and edge cases. Be sure that you leave the story open enough that people will think about all of the ways the feature will be used.
We recently starting using MMFs (“A minimum marketable feature is the smallest possible set of functionality that, by itself, has value in the marketplace.” – James Shore [http://jamesshore.com/Blog]), which has helped us immensely with keeping things together and not losing track of things. It also makes our releases easy peasy and we don’t miss things (dead links?), etc. If your stories seem to be less cohesive than you would like or you find that things get missed, MMFs might be the right route for you to take and I would recommend using that format (or at the very least checking it out and seeing if it’s for you).
For a little further reading, I would recommend checking out Ron Jeffries’ post on the three C’s: Card, Conversation, Confirmation (http://www.xprogramming.com/xpmag/expCardConversationConfirmation). He’s got some great points that he makes better than I could, so if you’re interested in more detail about writing effective user stories that’s a good next stop.
