Matt O’ Rama

My First Agile Project Part 10: 5 Important Issues for Teams

Originally published on AgileSoftwareDevelopment.com

Picture courtesy of jeffk on flickr

I’ve written a lot about mistakes we made and the parts of Scrum we didn’t follow, to our detriment. We’ve got a late, still as yet unlaunched project, reduced credibility and lowered morale. And yet, even with all this going against us we still have one big thing going for us: an incredibly strong team. In this part of My First Agile Project I’m going to address this issue of teams and the importance of strong teams in Agile projects.

Read on for 5 important issues teams should look for. Some are good things, some are bad. But I believe we have a strong team and hopefully our lessons can provide some insight into building a strong Agile team.

—

1) We’re all friends.
Everybody on our team are friends. We hang out after work, we joke around; even if we didn’t work together we’d be friendly. I’ve worked at places where everybody was friendly and I’ve worked at places where everybody talked about everybody else behind their backs. Since Agile teams are supposed to be self-managing, it really really helps if people at least get along.

The problem with this is obviously if your team doesn’t get along, you can’t force it. Plenty of companies try to do “team building” exercises and these are even less effective for programmers than for other types of workers. Unless you’re trying to unite your team against management (which can be an effective tactic actually), you can’t build teams by doing inane activities. One thing you can do is try to split people up into smaller teams of people who get along. Having teams of friends contributes to the next couple of important issues and is vital for those reasons.

2) We communicate

The biggest benefit of being friends is that we talk. We talk about how we solved certain problems, we talk about things that went well and things that didn’t. If something is taking too long to finish, somebody will ask if they can help. Not only do we talk as a team, we talk to our Product Owner and she’s as much a part of the team as anybody. If we don’t like an idea she has, we’ll try to talk her out of it. This all contributes to the strength of the team.

An Agile team shouldn’t be just a bunch of people taking orders and going back to their cubicles to code/design/whatever. An Agile team is a team of professionals who should work together on their project and hash things out as a team. If your team isn’t talking, they’re not working at the level they should be.

3) We share work

During our sprint planning meetings, our practice was to assign work to specific individuals. Some people advocate assigning work to the team but we never had a problem giving work to people because we all knew it was really the team’s work to complete. None of us had a problem taking other people’s work if they got done early. Of course people’s first instinct is to be optimistic about finishing their work and not to voluntarily say they need help, but when everybody is friendly the risk of judgment is lower and people share their status and give up work more easily.

4) We Play

“Team building exercise” is kind of a joke around our department but we do things together regularly. Awhile ago the company was kind enough to pay for everybody in the company to go to the movie theater across the street for team building, my first exposure to the phrase. We all questioned how much team building could be done sitting in a dark room for 2 hours but it was a free movie. From then on though, whenever a new must-see nerd movie came out we would take off for a long lunch on Friday and see a movie as our own “team building exercise”.

In addition, at the end of our month-long sprints we would always try to do something as a team. We went miniature-golfing, bowling, out to dinner and drinks a few times, just drinks a few other times, things like that. We’ve also gone to a local laser-tag place for long lunches a couple of times, which is great fun even for the people who don’t think it will be. I really recommend activities like this for teams, it builds the team up without being any kind of explicit corporate-endorsed exercise. Even if your team is new or not up to friend status yet, everybody likes shooting at each other or beating the others at a fun game like bowling or miniature golf.

5) We let people go

The hardest part of keeping any team going efficiently is knowing when people just don’t fit. We (meaning our managers really) have had to let people go from the team twice during this project. The first was a programmer who just wasn’t picking things up quickly enough. When you’re sprinting, you can’t give people the same amount of time to come up to speed as you might on a regular project. The second time was someone who was slow and also didn’t follow our sprint procedures the way the rest of us did. He didn’t tell us during our morning sprint meeting that he was still working on something for the 3rd day and didn’t stick to the tasks assigned, taking half a day to work on random other things. These kind of things just take too much time to deal with when you’re packing each sprint to the gills with work and trying to get everything done. It’s incredibly difficult to get rid of people, but the integrity and efficiency of a team can’t be compromised when you’re in the middle of a project.

Conclusion

A good team can make up for almost any other deficiency in process. A good team can make a good product with no process or bad processes. A bad team can make a bad product no matter what. Good processes can’t help a dysfunctional team. A good team, with good processes, can make a good product and can make it fun. Increasing communication is the single best way to improve your processes. Helping people share information is good for cross-training, sharing the workload, and for increasing morale. Making a good team isn’t a magic, but it’s not easy either. If your process just doesn’t seem to be working or your team is going slower than you all think you should be, you might take a close look at how well your team gets along and work on that first. I know the strength of our team has helped us immensely through some pretty rough spots.

Please share any ideas you have for real team building in the comments. Thanks for reading and I’ll see you back here next Monday! You can also reach me on Twitter as mattgrommes.

My First Agile Project Series
Part 1: Doing 80%
Part 2: Inception & Planning
Part 3: Viral Videos and Bad Jokes in Scrum Demos
Part 4: How to lose credibility and jeopardize your project with lack of management buy-in
Part 5: Our Top 5 Agile Mistakes
Part 6: The First End of Our Project
Part 7: Adventures in Agile Testing
Part 8: 9 Things We Disliked (and Liked) about ScrumWorks
Part 9: Choosing A New Tool – VersionOne

My First Agile Project Part 9: Choosing A New Tool – VersionOne

Picture courtesy of VersionOne and me

In my previous post, I talked about my team’s experience using ScrumWorks as our Scrum backlog management for the first year or so of our project. After our vendor’s license for ScrumWorks ran out, we thought we were close to the end of our project so we stopped using any tool for tracking tasks beyond our bug repository. As I’ll talk about in this post, a combination of factors led us to start looking for a new backlog / taskboard tool and the one we’ve settled on is VersionOne. Read on for more details about why we chose VersionOne and how we plan on using it, even once we’ve moved on our first agile project.

—

First, a word about Part 8 of this series, where I outlined the things my team and I didn’t like about ScrumWorks. I didn’t intend that article to be a review of ScrumWorks at all but more of a look at how we used it and why we didn’t like it at the time. It expanded and was seen by some as too harsh on ScrumWorks, especially since I was talking about an older version. It appears that ScrumWorks has done some good updates and fixed a lot of the issues we didn’t like about it. But some of the problems are philosophical and I’ll get to those in a bit. But if you’re looking for a Scrum tool, make sure you do your own evaluation and don’t take my word for it. Every team is different.

Also, just so there’s no misunderstanding; neither I or Agilesoftwaredevelopment.com have any connection to any tool I mention here beyond using them.

Time To Find A New Tool

Our license for ScrumWorks running out happened about the same time we thought we were nearing the end of the project and we refocusing to work strictly on bugs that came up during testing. We all had bugs related to things we’d worked on so we didn’t see a big need to track things and do sprints like we had been doing. There’s more on this phase of our project in Part 6 of this series. But overall we liked the Scrum process and had been laying the groundwork for making sure we kept doing it even after we moved off of this project, the one that had introduced Scrum and Agile to our company. To do that, we knew we’d need a tool so we looked around a little for one while continuing work on the existing project. A few months later I went to the Agile2008 conference in Toronto and found a couple of good alternatives to ScrumWorks.

Picture courtesy of VersionOne

At the conference I saw a couple of products but was most impressed by VersionOne, by far. Everything was done in the web browser, which I was specifically looking for after disliking ScrumWorks’ use of a web browser and desktop app for different tasks. The UI looked easy to use and didn’t get in your way. It looked very easy to add different projects to keep the various tasks we had in our company tracked together. Part of my search for a new tool was one that was easy enough to use that it wouldn’t take too much maintenance or setup. I was trying to get our department and company to accept wider use of Scrum and Agile methods and a tool that would add a bunch of work would just be an impediment. Another very cool feature was their open API that allowed people to write integrations and tools on top of VersionOne. We use Jira at work for bug tracking and VersionOne has a synchronization tool for Jira that looks like it’ll fit our workflows very well.

When I returned from the conference, I setup a trial with VersionOne that allowed us to use the tool for a month to really get a feel for it. I used it to run a small sprint we were doing on a bigger integration piece we needed to get done quickly and it handled that very well. I also imported all of our Jiras as a different project as a test and although the importing process had some problems it worked well (there’s an XML importer but no example XML I could find and the CSV importer didn’t appear to allow importing notes from Jira which we use extensively). I didn’t setup the automated Jira synchronization due to a lack of time. If you’re looking at Scrum tools, I’d encourage you to get in touch with VersionOne and try their demo, it’s very enlightening to actually get your hands dirty on a tool and it’s easy to setup with them.

Picture courtesy of VersionOne and me

Working with VersionOne, the biggest thing that stands out is how it doesn’t try to force you onto a specific path. ScrumWorks tries to keep you on the strict Scrum path, which according to the product manager who kindly responded to last week’s post, is their intention. That’s fine but just didn’t work for us. I’m not a big fan of strict processes and like the ability to go the way that suits us best without having to work around things we don’t need. We want a way to keep track of tasks, make sprints, etc. We don’t care about a lot of the stuff other teams might want or need and VersionOne doesn’t force us to. I think the only required field by default on backlog items and tasks is the title. Other than that it’s up to you.

Transitioning from one agile project to many

As I mentioned, I’ve been working on convincing our department (and by necessity, our customers in the rest of our company) to move to a more Agile process. Before starting on this big Scrum project, our process was pretty much non-existant. We didn’t even really do waterfall, we just came in every day and worked on bugs and issues from Jira. Luckily for me, I was only with the company a few months before we started using Scrum on this project.

What I’m hoping to do, and I’m pretty sure I’ve convinced my manager and director that this is the way we should be going, is to do Scrum on a multi-project basis. Instead of almost all of us being on this one big project, we’ll make 2 week sprints out of issues from the various projects in Jira. VersionOne’s Jira integration will allow us to keep having people enter tasks in Jira like they always have, then we’ll pull them over into backlog items and defects and enter them in sprints to work on. Priorities will be set by our manager, in a modified Product Owner roll, and we’ll be removed from the management back-and-forth of those decisions in a way we weren’t in the previous process (we hope anyway, we’ll see how that works in practice :)). This will let us work as a team on multiple projects at once, without having to multitask and switch projects based on which department manager is at our desk that day. Or we can put all of our resources on a big project for awhile to get big chunks of work done. It’s a very flexible system and I think will work out well for us once we can get everybody on board.

But the reality of the situation is that I’m just a programmer with ideas, a big mouth, and a genetic inability to keep quiet about things. My management tends to listen to me but we’ll see how these plans work out when they hit the corporate reality. I plan to write more about how this transition is going in real-time once it gets closer and I finish out this My First Agile Project series.

As I say every time, thanks for reading. If you have any comments on any of this, please use the comments form below.

My First Agile Project Series
Part 1: Doing 80%
Part 2: Inception & Planning
Part 3: Viral Videos and Bad Jokes in Scrum Demos
Part 4: How to lose credibility and jeopardize your project with lack of management buy-in
Part 5: Our Top 5 Agile Mistakes
Part 6: The First End of Our Project
Part 7: Adventures in Agile Testing
Part 8: 9 Things We Disliked (and Liked) about ScrumWorks

Blocking thinking with information

In the interest of posting more, I’m not going to be as diligent about making links to everything since for some reason that always takes more time than anything else. You can google for anything you want to find more about anyway.

Since almost the creation of the format of podcasting, I’ve been an avid listener to podcasts of all kinds. I was an early listener to ITConversations and for a time listened to every single program they put out. I phased most of them out except for select ITC shows and some other technical programs (the list of what I listen to can be found below). I was listening to a talk given by Tom Kelley from IDEO, one of my favorite writers on innovation from one of my favorite companies, and he talked in there about how he used to listen to tons of audiobooks (also a love of mine) but when he started writing his own book he found that listening to the audiobooks blocked his own creative process.

I thought about this and I think that it’s true to an extent. I fill most of my time listening to new shows and learning, but I definitely notice when I’m thinking and not paying attention to the show. I don’t want to get into the position of just stuffing new information into my head without giving myself time to think on it. I’m doing a couple of particularly boring tasks at work recently and usually I’d be listening to some program or another at the same time. Today though, I just turned on music the whole day so right now I’m listening to Bowie’s Ziggy Stardust album instead of the most recent Planet Money show. I’m going to have to get past the feeling I always get where I’m falling behind on my shows but maybe this will just make me go to the gym more. I can’t bring myself to get on the elliptical without something to zone out to.

My podcast subscriptions

• Java Posse
• Stack Overflow
• Planet Money
• This American Life
• Software Engineering Radio
• SPaMCast
• Mark Kermode’s movie reviews
• Entrepreneurial Thought Leaders
• various IT Conversations technical shows

Daring Fireball: iPhone-Likeness

Figure out the absolute least you need to do to implement the idea, do just that, and then polish the hell out of the experience.

Daring Fireball: iPhone-Likeness.

Not only a good idea for iPhone apps, a good idea for all apps. Too often people just say ‘Do the simplest thing that could possibly work’ and don’t carry on with the polish.

My First Agile Project Part 8: 9 Things We Disliked (and Liked) about Scrumworks

Originally published on AgileSoftwareDevelopment.com – This started out as a comparison between Scrumworks and VersionOne and turned into a bit of a rant and slam on Scrumworks. I was pleased to hear from various users of Scrumworks that they’ve fixed some of the specific issues I mention.

Picture courtesy of Danube and me

This installment of My First Agile Project is going to be a little different than the previous ones (Table of Contents for the series available at the end of the post). Today I’m going to tackle the topic of tools. During the first year or so of our project we used ScrumWorks by Danube. It was brought to us by our vendor along with the Scrum methodology. After our license ran out we didn’t like ScrumWorks enough to get our own license or even go with the free version, which I’ll go into more detail about below.

For our last couple of sprints, we’ve been making due with a whiteboard and evaluating other tools. The one I like the best and we’ll probably be going with is VersionOne, which I’ll be talking about in more detail next week. Honestly VersionOne makes ScrumWorks look old-fashioned and barely functional. I had a list of things I didn’t like about ScrumWorks and one of the first things I noticed during my initial demo was that VersionOne didn’t do any of those things, obviously a big selling point. This week’s post is that list of pros and cons about ScrumWorks.

Choosing a tool can be very important in a lot of software development and choosing where to put your backlog and tasks is extra important to Scrum. Since the whiteboard/corkboard + stickies/index card approach is basically free, you want to choose a tool that gives you some extra benefit. Read on for my team’s pros and cons about ScrumWorks and hopefully it’ll provide some insight on this important decision.

What we liked about ScrumWorks

The first thing I should say is that we started using ScrumWorks over a year and a half ago and I only recall doing one update so my experience might be out-of-date. I didn’t bother looking at ScrumWorks again when looking for a new Scrum tool. Also, these are my and my team’s opinions only and I’m not affiliated with either Danube or VersionOne beyond using them.

1) Gave Us Structure
As I said, our vendor brought ScrumWorks with them along with the Scrum methodology when they came to work with us on our project. Since this was our first exposure to Scrum, bringing a tool they were familiar with was a good idea. If we hadn’t had the guidance on the process that ScrumWorks brought just by having a set workflow and screens that asked for the important information for backlog items and tasks, it would have been a lot more work getting going. If we’d had to figure out what needed to go on cards, which cards went where, how to make a burndown chart, etc., it would have taken a lot of time.

2) Did the Basics
We also liked being able to see our tasks and make changes online, run reports, make graphs, etc. Being essentially lazy, having a program automatically make the burndown chart alone is worth a lot to me.

An aside about Burndown charts

One unrelated note on these automatically generated burndown charts: make sure your upper management doesn’t fall too in love with them. We had problems early on with our management not understanding the process and using whether or not the line on the chart was going up or down as their only view into how the project was going. Managers love graphs and will (ab)use them if you let them. You learn things and change estimates and the line goes up. This is fine.

What we didn’t like about ScrumWorks

This is the bigger of the 2 lists, unfortunately. ScrumWorks gave us the basic functionality required for a backlog/task manager. How it did that is where the annoyances came from. Now, these things might not annoy you and I’m sure they made some of these choices on purpose but they didn’t suit our team. Tools are very individual and I think ScrumWorks is pretty popular so other people must love the heck out of it. That was not our experience.

Picture courtesy of Danube and me

3) Too Many Required Fields
The first annoyance we ran into was that ScrumWorks makes too many things required. To enter a backlog item you have to do your difficulty estimate, and enter a value for business benefit before you can save the item. This gets in the way of just entering things into the product backlog so you don’t forget about it later. Estimating difficulty should be the team’s job (or at least the team member responsible for the item), not the job of whoever enters the item. And being forced to enter a benefit in just so ScrumWorks can do its priority calculation (it gives you a ratio of difficulty to benefit) was extra annoying because we never used the calculation it gave. Since our project was to replace an existing system, everything we entered at first was functionality we had to replace so how were we to determine the benefit? We tried at first but it just wasted time in planning meetings. At the end we were just entering 5 for everything it required us to fill in just to get past the screen.

4) Too Much Required Workflow
In the same vein, you also have to estimate tasks as they’re created and you’re not allowed to assign a task to somebody before you put the item into a sprint. It’s one thing to suggest people follow the proper procedure, it’s another when your tool forces you to do things a different way than you want to for no reason. I can’t tell you how many times we were forced to stop our planning flow to do things the way ScrumWorks wanted us to.

5) Can’t Split Items Between Sprints
Another big irritation was the inability to split up items between Sprints. If you don’t finish a task during a sprint, you’re forced to move the whole backlog item to another sprint, losing the history of when you first did what. The first chunk of our planning meetings was spent going through unfinished items, checking if they were actually incomplete or if we just forgot to close them out, and moving the item to the current sprint. I was beyond pleased to find that VersionOne gives you an easy way to split things up between sprints.

Picture courtesy of Danube and me

6) Forces You To Use 2 Different Tools
ScrumWorks is actually 2 tools, a web-based taskboard and a regular desktop application for sprint and backlog maintenance. I can only guess that either they, unlike VersionOne, didn’t think the web could handle the maintenance interface or they added the taskboard web interface later. In either case, it’s jarring to have to go from the taskboard to a different URL to launch the desktop app for certain things. But the web interface is the one you use most of the time so that’s not a huge concern.

7) Can’t See Only Your Tasks
First is that you can’t just see your own tasks and items. All the items are shown in a long list and you just have to scroll or search for yours. They’re highlighted with a color but you can’t just show yours. This led to a lot of problems with people not knowing they had been assigned something or forgetting to update a task because they skipped over it. Just because you can’t sort or filter a whiteboard with index cards doesn’t mean I shouldn’t be able to filter a web list of tasks. That’s a head scratcher of a decision to me, it makes no sense.

8) Web Interface Became Unusably Slow
The more sprints we went through, the slower the web interface became. I won’t guess at how they designed the thing to say why that might happen but it was almost unusably slow after 9 or 10 sprints.

9) No Way To Find Each Team Members’ Hours
There’s no way to find how many hours of work you have assigned to you. It’s not in the web interface and if it’s in the desktop app we never found it. What we always had to do was export the sprint to Excel and use the Filter feature to show each person’s tasks, then add up the hours. Obviously not ideal.

Conclusion

I hope that gives you a feel for what we liked and didn’t like in ScrumWorks. It does what its supposed to, giving you control over items and tasks and whatnot, but the way it does those things ranges from no-frills to annoying to infuriating. It was never really a question on our team if we wanted to continue using it or not, we even considered just writing our own basic version. As I said, our experience is a year old now and they might have revolutionized the product for all I know. But for now, we’re all glad to be off ScrumWorks, even if it means being without a good tool for the time being.

I meant this entry to be a review of both ScrumWorks and VersionOne but in the interest of not putting any more of my readers to sleep than I already have, I split this up and will give each tool the space they deserve. If you’re dying for a VersionOne review before next week, I give it a big thumbs up and encourage you to talk to them about doing a demo. They let you use it for 30 days and I found that a big help. They also have a ton of videos and tutorials that give you a feel for using the tool. More on our experience next week! Thanks for reading.

If you have experiences with ScrumWorks you’d like to share, please do in the comments below.

My First Agile Project Series
Part 1: Doing 80%
Part 2: Inception & Planning
Part 3: Viral Videos and Bad Jokes in Scrum Demos
Part 4: How to lose credibility and jeopardize your project with lack of management buy-in
Part 5: Our Top 5 Agile Mistakes
Part 6: The First End of Our Project
Part 7: Adventures in Agile Testing

8 Years Late

The other day I was watching some reruns of The West Wing and told my wife that if things didn’t go right during this election, that show might be the last vision we see of government as capable, intelligent, and standing for something. I honestly think we’ve avoided that future with the election of Barack Obama as our next president. I’m looking forward to finally starting to move this country forward into the 21st Century the way we should have 8 years ago.

Merlin Mann on blogging

I started out trying to do this but got “too busy”. I’m done being too busy. I’ve written over 10,000 words for AgileSoftwareDevelopment.com and I’ve been neglecting my regular blogging for that and work and family. I’m done working extra hours at work for awhile so I’m going to redirect that energy to this blog again and hopefully Get Better. Thanks for the inspiration Merlin.

My First Agile Project Part 7: Adventures in Agile Testing

Originally published on AgileSoftwareDevelopment.com

Picture courtesy of Sebastian Bergmann@flickr

In Part 7 of My First Agile Project, I’ll be talking about how we went about testing on our project. This part should stand alone if you haven’t read the other parts but if you want to catch up, see the series Table of Contents at the end of this post.

Our project was to integrate and configure a new billing system to replace an old custom Oracle forms app. Doing an integration and configuration project presents a lot of challenges to testing, which I’ll talk about below. In addition, like all projects, ours had a special set challenges. At first we thought the developers would do most of the real testing on the project with unit tests and verification of configuration changes by our Subject Matter Expert. The original plan included 3 sprints of testing at the end of the project just to make sure we had gotten all the needed functionality in during development. Looking back at this plan now, we all wonder how we could have so stupid. :)

Keep reading for more on how our plans went during development, what happened once we got into testing and why we’re still doing testing now – 6 months past our original go-live date. As I said, testing on a configuration / integration project presents special challenges so I hope our adventures will help other teams avoid some of the pitfalls we encountered. If you’re doing a similar project or have had different experiences you’d be willing to share with me and others, please post in the comments.

Working On An Unfinished Product

As I mentioned, we started the project intending to most of our testing as we developed, then doing 3 testing sprints (12 weeks) of regression / integration testing. Our thinking was that since we would be working on a pre-built base product doing mostly configurations we wouldn’t have to test functionality in the base product. There was a big problem with that assumption though.

Our company had decided, along with the vendor, that we would start working on our integration of the product while it was still in development. This was meant to give us a jump on going live. In my opinion the vendor was far too confident of the state of the product in saying it was okay to do this. Working with an unfinished product gave us the opportunity to influence its design but also meant we were delayed many times waiting for fixes or changes we needed. Since the platform we were building on wasn’t finished, a lot of things we completed broke in later sprints and needed reworking. So testing as we went along developing didn’t work like it should have, leading to lots of retesting later.

In addition, we’ve ended up testing every part of the application, even the parts built by the vendor we thought would work out of the box. Next time we do an integration project we’ll be much more careful to factor in time for testing the base product instead of assuming it’ll be correct from the start. I’m also going to recommend against starting work on a product as far from complete as this one was, the trouble it caused just wasn’t justified by the benefits. Our Product Owner might think differently but from a developer perspective, working on something that’s changing underneath you is really difficult.

Developer Testing Isn’t Enough

A billing system touches a lot of parts of the company which means we had a lot of integration points to develop. We ended up integrating with about 10 other systems and had probably 30 points of integration with those systems. With the product we were integrating, that meant a lot of Java code but also a lot of rules written in the product’s custom language and a ton of custom web services to pass data around, also written in their language. The Java code is easy to unit test, which gives you a certain level of comfort with the code but not 100% comfort to be sure. Where it gets hard is testing the rules and web services. We still don’t have a good way of testing that part, so we have to rely on our unit tests and manual tests to make sure the data we want is coming back and the rules are acting properly in the application.

We’ve found it very difficult to test a product that runs from a rules engine. The various levels of customization and rules add complexity very quickly. Once you’ve customized enough of a complicated product, finding if a bug is in your code or the product gets harder and harder. Also, “bugs” can be of multiple types; problems in the code that cause error messages, numbers not adding up or processes not being followed, and just incorrect behavior. There were a lot of times where the designers of the base product had an idea of how to do something and our Product Owner thought that was just wrong. So we would have to either work with them on changing the behavior or try to change it with customizations. This type of thing leads to a lot of work since it’s not just a bug to fix.

Since we relied on unit testing of integrations for most of the project, we didn’t find a lot of these bugs until late, when we started doing manual verification of every process and function in the application. A unit test is never going to see that an account that should have gone into delinquency after 15 days actually waited 16 days in months with 30 days. Or that all the charges on the invoice PDF file were 2 days off from when they should have happened. What we should have done is work in bigger chunks of functionality and have somebody go through and test the whole process and all the scenarios early on. If we’d spent our sprints doing both development and testing it would obviously have slowed the pace of development but that time would have been made up and more by eliminating a ton of rework.

Manual Testing

Once we figured out that we’d be doing a lot more testing than we originally anticipated, our Product Owner (the manager of the billing department) enlisted her billing team as manual testers. During development we had written literally thousands of test cases to use to verify all parts of the system. The new testing team went through these books and added new test cases all the time. They manually went through and compared a percentage of accounts in the new system with the old, checked invoices against the legacy invoices, and went through their daily procedures in the new system. This was hard but absolutely invaluable. For untrained testers, they’ve done a great job. I should have done some training on how to file good bug reports earlier on but we’ve worked well together.

I wish we had done some automated testing of the system for regression testing, but keeping UI tests up to date is a job in and of itself and isn’t as flexible as manual testing by a mile. The bugs we’ve discovered doing this manual testing has made up almost all of the work the developers have been working on for the past few months. Also, nothing is as valuable for finding what the users really want from the system than sitting with them and watching what they use, curse and smile at.

A Cross Country Journey

In trying to explain the difficulty of a big software project to a non-technical friend, I came up with the following: A normal big software project is like driving across country without a map. In a non-Agile project you try to work out in detail where you’ll be going before you leave. With Agile, you start out headed in the right direction and adjust as you go. Sometimes you hit a highway and make excellent time. Sometimes you hit the Grand Canyon and have to drive days out of your way. Our project, I said, was like driving across country without a map in a car that was still being built.

At the user conference for the company we purchased our billing system from, our Product Owner was asked to be on a panel about testing their products. The other participants had big teams of professional testers, hugely expensive automated testing tools, and lots of other advantages it would have been very nice for us to have. But even without them, we’ve done a good job of testing I think. We’ve got a very tight product that will be as right as we can make it when we go live, which is very important for a billing system. Even if you’ve got a small team, there’s no reason to think you can’t do a good job of testing your application, no matter if it’s a custom project or a configuration project. Yes, it takes time. But it’s worth it.

Thanks for reading and if you have testing experiences you can share please do so in the comments.

My First Agile Project Series
Part 1: Doing 80%
Part 2: Inception & Planning
Part 3: Viral Videos and Bad Jokes in Scrum Demos
Part 4: How to lose credibility and jeopardize your project with lack of management buy-in
Part 5: Our Top 5 Agile Mistakes
Part 6: The First End Of Our Project