When I was younger, I used to paint quite a bit. There were many times when I would be gritting my teeth, feeling the tension in my neck, frustrated at being unable to get something just right or not being able to see what I was missing. I would have to walk away for a couple of hours, days, weeks, or months (in the case of the one behind my bed, years). When I would come back and look at it with a fresh mind, it was so easy to see what was wrong. Bad proportions, not enough shadow, need for detail in more areas, whatever. But I would pretty much always be able to see it the instant I set eyes on it when I came back to it.
This system that we’ve been building since June is in a very intense phase of testing, and there have been times when I spent a full day beating it up. I wouldn’t be able to see anything new at all, but would know the system was not bug-free. Intensely frustrated, I refused to give up because of the time limit imposed.
This was the wrong decision.
By taking just a few minutes and walking away, I was able to come back a little more clear-headed and calm and get a fresh eye on things. It can be the same way when you are writing user stories; you think about something for so long that you feel like you have everything, then when you go to put it on the board you see that a piece of acceptance criteria is blatantly missing. Or when you’re developing something and you miss something really obvious because you’re so mired in the details.
This could be a post promoting pomodoro, it could be promoting an iterative process, I don’t really know what it is. I guess what I’m saying is that sometimes you need to make sure that when you’re creating something, it’s good to step away and come back with a fresh eye.
Take 5 and get a little brain massage and come back to it; “wasting” five minutes to recharge/reset your brain is better than thrashing for an hour and ending up completely frustrated and with holes in your project.
After our alpha test, we had a round table discussion with the involved developers, the alpha testers, and the rest of the product owner-y type people. They talked about what they liked, disliked, general wrap-up business. One of the greatest compliments we received was from a seasoned pathologist who has seen plenty of other lab information systems; what he said was:
One thing I love about this system is it made me feel like I couldn’t get hurt.
That is a thing to strive for.
Pathologists can really get hurt if a system is not built well. Their patients can get hurt. Our patients can get hurt. We built in so many safety nets so that users do not have to worry about screwing up. Users should be concerned with the task at hand, not with worrying about how software will react or if something is going to get messed up and affect patient care. It was an honor that he said this to us, and I am proud of our system for making him feel completely comfortable entrusting people’s lives to our software.
Medical software aside, I think all software should make you feel like this. You should never feel painted into a corner or like you can’t go back and change something. Users should always feel safe and comfortable using your software, and by your team doing plenty of thinking up front, users will not have to concern themselves with it. By building software as such, you are allowing them to focus on their workflow and tasks without having to worry about whether or not they will get hurt or hurt someone else.
Think about how they will unconsciously or consciously screw up, and make sure they can’t. Or if they can, make sure they are damn aware of it and able to fix their error without a whole lot of extra steps. No one should have to suffer anxiety when using software, and we all do far too often.
This is something we can fix.
Two weeks ago we held an alpha test of the product we have been working on since June. While I knew it would be an eye-opener to see people actually using the product, I didn’t know just how much of one.
I asked one of the developers, Ed Taupier, to give me some of his thoughts on how the alpha test opened his mind, changed his point of view.
“Probably the most important outcome of the alpha testing, for me, was to gain an understanding of how the targeted clients would react and use the software we had built. Or course I had my own opinions about which part of the software i really liked or disliked, was proud of or not. My perspective is heavily "programmer" based though, which means the technological aspects effect my view. This is not the perspective of the users, however.
It was extremely interesting to see what the testers found most interesting, valuable, useful and (yes) terrible. Witnessing and gaining an understanding of their perspective impacted me a great deal. It emphasized how important maintaining a "user" awareness and perspective is to a project’s ultimate success. This has been one of the more difficult aspects of software development for me in the past. Now i have a better understanding of how users in general, and our client base specifically, view software. This will greatly enhance my ability to contribute to and affect the success of projects in the future.”
Very well said.
I’ve actually been reading that bolded quote for about 20 minutes, trying to expound upon it, but it’s perfect. Being constantly aware of the fact that someone is going to use what you are building is important (and sometimes hard). I mean, it’s my job to be the user, to tell developers what to make…it’s harder for developers to get in that user mindset. When I watched Ed and another developer during the alpha test, taking in every mouse click and every question and every…everything from the testers, I could see that their perspective had really changed. It was beautiful to watch them watch the fruits of their labor being used. My demands for checkboxes to be in consistent locations and for filters to exhibit certain behaviors were no longer major annoyances and nitpicking; the developers could clearly see what the testers struggled with and where they had questions, and they knew exactly what needed to be done.
Since the alpha test, the quality of the code has gone up, I’ve not heard one peep of bitching about having to do something, and there is very clearly a lot more thought going into the code that is produced.
It is important to keep in mind not just what feature you are building at the moment, but how someone will be using it and how it relates to the rest of the system. Things can get really frustrating, especially if people are being demanding, but as long as you are able to get out of a developer mindset for at least long enough to consider what is being asked for and think about your customers using the software, it should be easier to see.
I wrote a post on a similar note a while ago, and I got a lot of flack for it. I hope this post makes my previous words seem less harsh, and more well-intentioned.
What is your job?
My title is business analyst. My job is business analyst, designer, documentation monkey, trainer, customer proxy, mediator, product owner, Soothing, Reassuring Voice (I make the screencasts), product evangelist, exploratory tester, and surely more that I am blocking from my mind right now.
My title is simply my title. It is nothing more than a word.
There are a lot of hats that I wear that I don’t like, but there are also a lot that I do. However, I realize that it is important within the realm of my team and our products that I wear all of these hats. My deep knowledge of the workflows, that I get from the customers and build as I write specifications for development, comes in very handy when I am acceptance testing something at the end to see how a user will be using it.
I think that everyone in our industry wears a lot of hats. Or if they don’t, maybe they should be.
In my experience, developers hate testing.
In my experience, code that developers write tests for fails significantly less than code written without tests. Even building what you wrote right after you’re done to make sure it works is testing. There have been many times where I’ll take the first action to make something happen (“click a button”) and it immediately blows up. Not cool.
In my experience, developers hate talking to people (read: me).
In my experience, communicating with product owners, business analysts, and in general, everyone on your team, builds a really great product. No assumptions, no guesses, no lack-of-thought, coding-in-the-dark jazz. Talking to testers will give you good feedback about what’s going on and make sure that you solve the whole problem instead of patching parts of it, talking to your BA to make sure you’ve got a grasp on what the story really means and ensure that you are building what is being asked for.
We don’t always like all of our jobs, but how often can you find a job where you 100% love everything? You may love locking yourself in a room and writing code for a week, but how much do you love coming back and rewriting stuff to fix bugs and build things to specification?
Writing code is only part of the job of a developer, much like making coffee is only part of a barista’s job, or answering phones is only part of a client service rep’s job, or selling products is only part of a sales rep’s job.
You gotta do what you gotta do to get the job done thoroughly and accurately.
Happily or begrudgingly, you gotta wear those hats.
Definition: The faster you try to do something, the more likely you are to make mistakes that make you take longer than it would had you planned it.
Our team recently completed two rather large projects with fairly short deadlines.* Having overseen both projects beginning to end, it was easy to see the patterns of burnout and people feeling rushed. Throughout the life of both projects, the questions, issues, and general quality of the product was fairly consistent. Riiight up until the end.
In the last month and a half or so of each project, the quality of what was being produced really dropped and the number of bugs skyrocketed.* Every story that I’d test would get kicked back multiple times, a lot of them getting kicked back immediately because the program would blow up as soon as I tried to test the feature.
Feeling a lot of pressure as a deadline approaches is natural. Burning out after 6 straight months of 15-hour days and no vacation is natural. It’s easy to just say “work at a sustainable pace,” but it’s hard when you are right down to the line and things keep coming. The main thing is to try to recognize when you are feeling like that and when your code is unhealthy and attempt to mitigate it. If everything you are writing is getting kicked back, try to find a solution to get your mind back into a productive state. If you don’t, the end will be much more frustrating, as you will have to continually rewrite code and work on the same stories and rush to try to patch things to meet your deadline.
What can you do to get your mind back into a productive state? Smoke a cigarette? Go to Starbucks? Sit in your car with some death metal blaring? Change your socks? Try to find something that works for you (everyone is different). I’d love to hear some ideas/solutions in the comments.
*note: we are closing out the second one, it’s not actually done yet. But you get the idea.
*note: the quality of the last half of the second project was markedly better than that of the first one, so kudos on team improvement!
I may have alluded to this in previous posts, but let me try to sum up The Hell That Is What Our Team Is Working On Right Now:
We have been given 6 months to complete a web application that is basically a (beautiful and much improved) replica of an existing suite of desktop apps that took us two years to build. Oh, and we started with pretty much no web experience. Oh, and our deadline is Jan 1. Merry Xmas to me; this year I want Xanax.
After going through the complete Kübler-Ross model, we got focused and got started.
Let me tell you some facts about what we are working with: it involves people from a wide variety of departments across the company as well as a lot of hardware/tools/”things” that we do not have any sort of clear concept of yet. As a result, it has been very hard to get information and fairly hard to specify and figure out which stories a) have enough information to be worked on and b) won’t incur too much change as people figure out what’s going on.
Obviously, we’re building this iteratively. Because how the hell else can you build something when you get new bits of information every week? At any rate, this product is essentially changing the face of our company and there are a lot of stakeholders. This thing needs to be gold in everyone’s eyes.
So how have we been making this work?
We use V1: Agile Enterprise as our project management tool. The team uses the storyboard to move stories across the various stages of development, and we use tasks within that to log any issues that come up during testing. If we log a task within a story, that story gets kicked back for rework. We have ten columns on our board, so it is very easy to tell what is going on with a story, whether it’s in code, in review, in test, etc (you may have more or fewer; ten was the sweet spot we eventually came to through trial and error). Anyone on the team can see at any time what is being worked on and where in it’s life a story is. They can look at tasks within the story to see what kinds of stuff is being kicked back. Our boss, who is in a different location, can go in at any time and see where bottlenecks are and what needs improvement and then formulate a plan to resolve any issues. You can use index cards, other programs, carrier pigeons….whatever works for you. But having this very high level of transparency about what is being worked on has been great for all parties involved.
2. High Visibility
I’ve mentioned our weekly demos in previous posts, but they very much bear repeating. Without these weekly demos, this product would not be anywhere near the level of quality and, let’s not kid ourselves, awesomeness that it is now. We have all of the people working on the product as well as our boss and the CIO (a major stakeholder with a lot of knowledge about the rest of the company’s involvement in the product) in the demo, and everyone’s input is equally valuable. By doing these weekly demos we can ensure that the workflow we have envisioned works, and if it doesn’t we can figure out exactly what we need to change right then and there. All parties involved can give feedback and present their thoughts on the issue and we can all put our heads together for some critical thinking and problem solving. Even if it’s something like a minor design change we are very much able to address problems then and there, and sometimes devs will even make changes in the code right away in the demo so we can see what it looks like. No need to wait 3 days for an email response or call someone and wait for them to get the answer. Building this product iteratively with high visibility has been an incredible experience; watching it all come together, being able to make immediate tweaks to a system rather than finding out in beta that we’ve completely hosed something, bonding with each other during this hellacious time…I wouldn’t trade it. It’s been intensely valuable to us, and the product? looks absolutely fantastic as a result.
Which brings me back to the root of every good and bad thing that I ever talk about: communication. We communicate issues on the taskboard, we communicate the progress of a story on the storyboard, we communicate what is done to stakeholders by way of weekly demos, and we talk all the time to make sure everything and everyone is on the right page. With this short, rapidly approaching deadline, we don’t have a lot of time for rework and dicking around. We are all working together and keeping everyone in the know to make this project happen. Without this intensely high level of communication we would be halfway through the project and it would look awful and we’d all be looking for new jobs come January.
Our team is incredible. I love them like a weird family (the way I imagine carnival sideshow acts are a family), and without all of our contributions I can guarantee that we never would have come this far. I just want to say I love you guys and cannot tell you how amazing it has been to work with you on this mind-numbing, hair-graying, frustrating, wonderful project. You all bring, give, and do so much, and I sincerely appreciate all of it. Let’s drink all the beer (in the world) Jan 2.
– The Bearded Lady
The other day (read: several months ago) I was sitting outside talking shop with David Laribee. We started discussing kanban and some things he does on his team, and I thought I’d finally caught him on something:
Me: But wait…you do daily stand-up on your team. That’s a scrum thing. So would you say you’re doing scrum-ban?
Dave (nonplussed, and without hesitation): Daily stand-up is a tool. It has nothing to do with scrum.
Tools are not processes.
Tools can be used in any context, if they help you. Don’t limit yourself to using only things prescribed for your particular methodology. I’m no Jainist, but I’m still not going to kill a bug (except for that palmetto bug that I ironically attempted to kill with a copy of the Bhagavad Gita the other night [read: weeks ago], but that was life or death. That thing was the size of a pony). If something fits what you believe in or how you work, do it.
Prime example: Kanban is not a board. The board is a tool used with kanban. But how many times have you seen people get hung up on the board and focus explicitly on that as actually being kanban?
You don’t need to follow everything to the letter if it’s not working for you. Using scrum for us was like trying to fit a square peg into a solid piece of obsidian. Daily stand up sure helped though. We were able to strip out things we liked from scrum and cut the things that didn’t work for us in order to improve our process.
What you do need to do is make sure you are understanding what you are working with/preaching/living. If you said kanban was a board, maybe you need to do a little more reading and research. And in doing so, you will surely find a lot more information that will help enhance your processes and give you a better understanding of how these things can help your team. Maybe you’ll even find something better.
My recommendation is not to get hung up on making your team fit with a methodology or process (either because it’s the hot thing in development or because someone is cramming it down your throat as The Law); if some of the related tools are not working, drop ‘em. Find something better. Make your processes and methodologies fit your team. Make up your own stuff. Don’t feel pressured by the Kanban Kids or the Scrumies (Scrumites?) to work in rigid ways that don’t work for you. We got a lot of crap when we started dropping things from scrum, but then “scrum-but” became a thing, because, well…scrum works for some, but it’s not ideal in every team/project scenario.
I’d love to hear more on this in the comments.
In this post I am going to talk about something that has evolved on our team. It may not be right for you but it has served us well and you may find it useful.
Over the past year we have tried many different ways to estimate stories. We played planning poker (if that’s for you, this is a great tool for it http://www.planningpoker.com/ [and great for distributed teams too]), we used story points, we used days, hours, timeboxes (2 weeks or whatever), I’ve heard of teams using t-shirt sizes…there are all sorts of things you can do.
Having the whole team together to estimate felt wasteful. Sometimes there would be no discrepancies, sometimes there would be too many discrepancies, and a lot of times the people involved in estimating would not even end up working on the project. In any case, the estimates were always a lie. So we eliminated some waste.
We cut it down to just the people who would be working on each story, but sometimes those people would get pulled onto other projects so the estimates would be wrong for the new person that would be working on it. So we eliminated some waste.
We broke things into MMFs that contained roughly the same amount of work. Sometimes it would be 20 small things, sometimes it would be 8 medium things, sometimes it would be one ghastly, horrible thing. It was difficult to measure at first and we were wayyy off on a lot of things, but over time it got a little better. So we made some improvements.
Now, all of our stories are same-sized. When we write them we make sure that they are small, but not too small. Our stories are all “two days worth of work or less.” After our weekly demo of the current project (10am) we go through the next batch of stories/designs for the coming week (11am). We talk them out amongst the people who are working on the project at the time and make sure that everyone agrees that the stories are all two days worth of work or less. If they aren’t, I’ll go back and refactor them. If they are, they’re ready to be worked on and they go on the board.
For our situation, this process really had to evolve like this. I don’t know that it would’ve worked if we just jumped into same-sized stories right away. Getting a feel for how the team worked and how long each thing took (making sure to account for spikes and other things related to a feature but not necessarily in a story) got us into a really good groove.
Formal estimation did not do us well. Things would always run longer or run shorter, and both of those are bad. Too long and you’re behind, too short and people will slack off to stretch it out. Having same-sized stories makes planning a sprint easy. It makes meeting deadlines easy. It reduces a lot of stress that you would get from working on a huge story…on our team we would get brand new HIGH PRIORITY WORK on a fairly constant basis, so smaller stories mitigated context switching. Using same-sized stories has eliminated much of our waste and simplified our planning, and, in general creates a clean, constant flow of work.
I am a creature of habit. I like this because it keeps me efficient, which keeps me happy, which keeps my coworkers alive.
This is another situation in which I work the way I naturally live.
Consistency in Experience
When you use an app or a site, it usually only takes a few seconds or so to really get the hang of how to navigate and operate things. If all of the navigation is on the side and suddenly a navigational element is along the bottom, doesn’t your brain kind of get tangled for a minute? Personally, it makes my face scrunch up like a little badger.
Keeping navigational elements consistent is a real key in usability; your users will get used to how to work something fairly quickly if it’s designed well. If you have even small inconsistencies that confuse them, they will remember that they had trouble with the product and you will get negative press and unhappy customers.
Another key example of an easy way to be consistent in design/experience is to keep your Yes/No, OK/Cancel buttons in the same place. Doing some acceptance testing the other day, we noticed that the Cancel button was on the right and the Accept button was on the left in one area of the app. Everywhere else it was reversed. This was caught pretty quickly because we kept hitting Cancel when we meant to hit Accept. Your users will do this too; your app is so usable that they just fly through everything without paying too much attention and then….they hit a snag.
And then they make that badger face.
And so on and so forth.
Keeping the minute details of your designs consistent will keep your users moving quickly through your product and minimize the amount of thought they put into their use of it, which equates to great design.
Consistency in Development
On our team, we have some things that are just standard. Things like all grids should sort, all active checkboxes should be checked by default if a user is Adding New, case searches should be wildcarded, etc. These are items that we already know to do, and therefore we don’t have to add a lot of noise to acceptance criteria with these little things. Muddying up the spec will make other items of actual importance get missed, noise reduces signal, yadda yadda yadda. These are items that we have just determined will be standard, and as we get new additions to the team we make sure that they get informed of them (even if it means forgetting and kicking a story back and then telling them). As these conventions build up over time, we ensure that our stories always represent the essence of a feature and don’t have to waste energy or space on the scaffolding around them.
Consistency in Documentation
Just like with the Consistency in Experience section, users will get the hang of reading a manual/help file/on-screen info prompt/tooltip/etc. I know that sounds kind of silly, but little things can really make a big difference in user experience. If you go into extreme detail about editing a user account in one section of a manual and then only make a blurb about editing a user location in a later section, it might make a difference. People’s eyes will search for what they want to find, and if they are used to looking for headers like How to Edit a User Account and your location editing “section” doesn’t have that? badger face like whoa.
Now for the real meat of this portion of our show: consistency in stories and tests. Tests should be consistent in naming and consistent in organization. People should be able to easily read through the muck to get the information they need. Back in the day? I could never have read tests. Now that we’ve cleaned things up a bit I have some idea of what is going on and how things work/are organized. I can tell what stuff is because of the items surrounding it, or by the way it is named. It makes it much easier and faster for people to read if you are consistent in the way you structure your tests.
When I write stories, I like to lay them all out the same way. The same things get bulleted, the bottom of the story says “Mockup attached” if that applies, things get formatted similarly. For example, when something needs to be restricted, the first thing in the backlog item is some bolded text, before the story, that says Permissions: [Whateverthepermissionsare]. This is great because:
a) Developers will see that right away and know to build it in
b) It doesn’t muddy up the acceptance criteria and cause something else to potentially be missed
c) with this convention, if there is no explicit permission statement there, developers don’t have to guess if it needs it or not
(note: these things go for the “Mockup attached” thing too…they won’t look for an attachment if that’s not at the bottom of the story, etc)
Using ubiquitous language is extremely useful as well. We had a doozy of a time on our most recent project trying to figure out how to separate lab accounts and client accounts in stories…eventually we came up with those terms (and a bah-zillion others), and now our developers never have to ask me what the hell I’m talking about.
Oh, and, of course, as a developer I want my stories to be consistent so that I can easily identify each element of them. Heh.
Consistency in Code (written by Scott C. Reynolds because I don’t know enough about code but I do know that this section is important to this post)
Teams usually come up with conventions in coding, or coding standards, that define how the team will do things like organize code, name variables, and things like that. This is helpful in communicating intent and reaching collective code ownership. For instance, the team standard may be "all private members are named with a leading underscore". Then anyone in the team reading code that comes across a variable named _someVariable will know that it is a private instance member and not a local variable, and will know to be concerned with things like mutability. This cuts both ways, in that the benefit gained from following the convention is about equal to the damage caused when someone doesn’t follow the convention.
Some frameworks, such as Rails, are built on the principle of "convention over configuration". In trade for following certain conventions, you get increased productivity by leveraging things the framework can do for you automatically.
Conventions become a sort of "meta layer" of communication on a team when people are doing things the same way; whether it’s naming variables, sorting classes into certain folder structures, calling things the same thing (ubiquitous language is a convention, and bears mention somewhere I think), then it removes guesswork from the equation and focuses communication on problem solving rather than mechanical details.Some frameworks, such as Rails, are built on the principle of "convention over configuration". In trade for following certain conventions, you get increased productivity by leveraging things the framework can do for you automatically.Conventions become a sort of "meta layer" of communication on a team when people are doing things the same way; whether it’s naming variables, sorting classes into certain folder structures, calling things the same thing, then it removes guesswork from the equation and focuses communication on problem solving rather than mechanical details.
Oscar Wilde once said “Consistency is the last refuge of the unimaginative mind.” I would partially disagree with this statement. By being consistent with the overall structure and feel of things, you can exert your mental energy into things that really matter, rather than minutiae. Consistency in these small things means you don’t have to think about them; they exist as quality without any extra effort and greatly enhance the usability of a product, the understandability of a story, the ease of modifying tests.
…but maybe he wasn’t talking about software, hmm?