Matt O’ Rama

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

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

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

My First Agile Project Part 6: The First End Of Our Project

Originally published on AgileSoftwareDevelopment.com

Picture courtesy of Photo Mojo@flickr

Welcome to Part 6 of my team’s first adventures with Scrum. If you want to start from the beginning, see the table of contents at the bottom of this article. Each part stands alone though so don’t worry.

In this part of the series, I’ll talk about what we did when we approached what we thought was going to be the end of the project. As it turned out it was only the first deadline that we would miss. Near the first deadline we went off of doing Scrum sprints and planning in favor of fixing bugs as they came up in testing. This cost us a lot of team cohesion and focus. Read on to hear about what led us to missing the deadline, why we went off Scrum and how we got back on the right path. As usual, I hope our story helps illuminate some decisions teams make with the best of intentions that can lead to unforeseen negative consequences.

—

During our Inception Phase the vendor whose billing system we were working with came up with a development model (basically a complicated spreadsheet) that was a SWAG at how long they thought this project would take, based on how many people we had on the team and a rough estimate of how much work we had to do. The model showed we would need 9 month-long development sprints and 3 integration testing sprints. As we neared the end of the development sprints, we knew we would need more time so we said at first we would take the first testing sprint and finish up the last development. Of course we needed more than that sprint so we pushed back testing another sprint leaving about a month for final testing before go-live.

The idea with leaving the integration / User Acceptance Testing to the end was that we thought unit testing and developer testing would be enough to flesh things out during development enough that we would just be squashing bugs during the final sprints. There were a couple of reasons this didn’t work like we thought it would but that’s a bigger topic that I’ll be going into in more detail next time.

Going off Scrum

Once we came to what we thought was going to be the final push to going live, we decided not to do structured sprints and just hit the bugs that came up in testing as fast as we could. We didn’t think we had enough left to justify doing a sprint. So for a few weeks we just followed the testing team, trying to take care of bugs as they came up. The more we went along though, the more apparent it became that testing was uncovering a lot more work than we thought it would. I don’t remember when we finally admitted that we weren’t going to make the deadline but it was after we should have admitted it. We were in denial.

After the first deadline passed and we were still working hard, as well as uncovering lots of work still to do, we should have gone back to doing sprints. I think we were still partially in denial as a team, thinking we would finish up soon and be able to go live. Team denial is a strong force and I think the only way to get around it is to make sure everybody speaks up. The whole team wasn’t 100% in denial about the amount of work we had but each person’s low level of unease should add up. We all had thoughts, we just didn’t listen to each other enough and put things together. It’s everybody’s responsibility to speak up and if they have reservations about something on the project they need to make sure everybody else is listening. If we had really been paying attention to our data conversion team, for example, when they said they weren’t comfortable with the initial deadline we would have pushed it back before hitting it. And we should have been more honest about the amount of work we were still uncovering. It’s been almost 6 months since the first deadline passed and we’re still finding things, which tells us something about where we really were back then (luckily now the new findings are going on the post go live backlog).

Loss of Team Unity

Since we thought we would be going live “any day now” and we weren’t doing sprints, we lost some of our cohesion as a team. One good thing we did was keeping our morning Scrum meeting, although it morphed a little. When we were going to be hitting bugs in preparation for go-live, we decided a sit-down meeting that might last more than 15 minutes was appropriate since we would be discussing bugs more and making first passes at solutions during the meeting to expedite the work. These meetings meant we all still knew what everybody was doing, but not keeping a taskboard or doing demos ended up being much more important to team unity than we thought. It’s a subtle thing that didn’t really realize until recently but looking at everybody’s work as a team effort and showing your stuff at the end of the sprint really pulls people together. By this time we all had areas of expertise in the product and we were working largely on fixes and additions to those things independently of each other. We still worked together a lot but had we not been a close, friendly team I think we would have drifted apart a lot more.

Sprinting Again

After a few months of what I called wandering around, instead of sprinting, fixing bugs and taking care of issues from testing, we’ve recently gone back to sprints. We’ve all been broken of our delusions about going live “any day now” and know it’s going to be some time still. I think it’s a testament to our team that we’re not all disillusioned and we still have our team morale. We’ve gone back to 2 week sprints, which helps planning meetings not take all day and gives us much more flexibility. Before we went back to sprinting, we had a big meeting with our vendor to work out a plan and a new model for completing everything. This model showed we were going to be at this for quite awhile longer. Once we started sprinting again however, we blew this model away with what we were getting done and the finish line looks closer than ever. Going back to the Scrum processes we liked has really re-energized the team. It’s very tempting to try something different when things get tough but we should have resisted the urge to move away from Scrum. Not doing sprints when you’re about to go live and are squashing the last-minute bugs is fine I think but we shouldn’t have left the path as early as we did. We’re all glad we’re back on now though and moving forward faster than ever.

Next time, I’ll be talking more in depth about testing. Why unit testing isn’t enough, how we did user acceptance testing, and why we should have started our testing team going much earlier than we did. Stay tuned and thanks for reading!

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

My First Agile Project Part 5: Our Top 5 Agile Mistakes

Originally published on AgileSoftwareDevelopment.com This has been, by far, my most popular post on ASD. People like lists, and mistakes.

Picture courtesy of DWQ Online@flickr

In the previous parts of this series (1, 2, 3, 4), I went into a lot of the initial issues of how we ran our project and some of the things we did wrong. For Part 5, I’m going to focus on the 5 big mistakes we made in the project before I move onto another phase of the series.

For some background, the project was to integrate an off-the-shelf (but highly customizable) billing system to replace an aging custom Oracle forms app. This was our company’s first foray into Scrum and Agile as well as the first Agile experience for most of the development team. After we sailed past our second management-imposed deadline I started thinking about how we could correct our process for this project and the next ones we do, which led me to write it all down in this series. Keep reading for the Top 5 mistakes we made (in no particular order). Where possible I also give some detail about how we’ve worked on correcting our process. I hope this list helps you avoid these mistakes and make your own all-new ones. :)

1) Not tracking backlog
This was by far our biggest mistake I think. As I mentioned in Part 1, we failed to keep track of how much work we were adding to our backlog as we went along. We all assumed that since we were being Agile, we would add work as we fleshed out requirements and learned new capabilities. The problem came with not tracking how much work we were actually adding and comparing it to how much we were doing in each sprint. Without doing this, another of our mistakes – Scope Control – became much more of a problem than it might have. Not reassessing the backlog periodically meant we didn’t know how scope creep was really affecting the project, which meant a downward spiral of allowing the scope to creep, not knowing the effect of the new scope, allowing scope to creep more, etc., etc.

Since we realized a few months ago we should have been doing this, we’ve been keeping much better track of what gets added to the backlog and making sure we’re being as ruthless as we can about moving features to Post Go-Live and only working on important bugs. As a result we have a much better view of the finish line of the project.

2) Too much planning upfront, not enough later
In Part 2 I talked about our Inception Phase where we had our initial meetings to get a rough estimate of the integrations we would be doing and business requirements from other departments who would be using or relying on the billing system we were building. The mistake we made here was in the amount of requirements gathering we did and how we did it. We took a “snorkel, not dive” approach where we didn’t get too many details, which is a good approach. But we also made requirements documents complete with flow charts of integration program flow. These documents took much too long to write and didn’t end being used by the developers at all. Once we started sprinting and doing the work, we re-learned, or un-learned, pretty much everything in the documents but it all made more sense since we had the context of our code to work in.

Obviously not getting deep technical requirements up front means you need to get them later and this is part 2 of this mistake. We should have made it our practice to start getting requirements for the next sprint so we could start working without waiting. As it happened, our Product Owner/Subject Matter Expert was busy enough that we spent a lot of time waiting for requirements before we could start.

3) Boring business people with technical demos
I was tempted to make this mistake “Didn’t get management involved properly” but I think the early mistake was our demos. As I said in Part 4, we demoed everything we did that sprint, including infrastructure and behind-the-scenes integrations. This is good for the team to get to show off but it’s boring and turns off the business people and management. Once you’ve turned people off the process, it’s hard to get them back into it when you need their input. They’re still going to give you input, it’s just going to be later than you expect and usually after you think you’re done with the thing they should have seen 3 sprints ago.

Making the demos boring for the business folks also meant we failed to properly engage our upper management. We ignored this problem for too long and once they started getting more engaged, it was after the deadline had been blown and they weren’t aware. Not a good position to be in. Having more business focused demos wouldn’t have guaranteed anything but combining better demos with an insistence that the business / management people attend would have helped immensely.

4) Not estimating product backlog items
Part 1 of this series talked about how we were Doing 80% of Scrum. What we missed was a chunk of related, but separate processes around estimating and planning the backlog. This mistake is tied to a couple of the others because of this but we committed them all separately so I’m listing them separately. Our product backlog was basically just a list of work we had to do. Our Product Owner prioritized her most important items before the sprint planning meeting, then we moved the items we were going to do over and estimated them then. We didn’t estimate the backlog items ahead of time so she could know how hard we thought things were or so we could know how much more work was ahead of us. We had rough ideas that Integration X would take longer than Configuration Y but without real estimates, we couldn’t start harder things earlier in the process or push things that were hard and low priority off until later, both of which are vital for planning.

Since we’re in bug-fixing mode right now, we’re struggling with fixing this mistake more than with any of the others. I got a bunch of Planning Poker cards from Mike Cohn at Agile2008 and we’ve been trying to use those but it’s hard when the issues you’re estimating are bug fixes that only the person who worked on it originally knows about. If you have any suggestions on this, I’d love to hear about it in the comments.

5) Scope control
Not controlling the scope of the project, combined with our lack of estimates and not monitoring the growth of the backlog, constitute by far the largest cause of problems with our project. If we had been estimating our backlog items it would have helped us track the amount of work we had left, which would have helped us know when and what to remove from the backlog and keep to the next release. Since we didn’t do any of those things, the backlog grew too much, which pushed back the set of testing sprints we had scheduled, which pushed back the work that testing revealed, which put us in the position we’re in today, with a late project, lower morale, and lost credibility with management.

One factor I’m struggling to figure out is that the nature of our project seems to limit our ability to control scope. We’re doing an integration of a new billing system to replace an old system. This means there’s a set of existing functionality we have to duplicate in the new system that can’t be pushed to the next release. Also, being a billing system you have to get things right the first time. You can’t send out a partial invoice, for example, just because doing the whole thing will take too long. But I’m sure everybody thinks there are exceptional things about their particular project so I don’t want to fall into the trap of saying we can’t learn anything about how to control scope because our project is the exception. There’s always something that can be pushed back and if you’re doing the right things with estimation and monitoring your backlog it makes finding those things much, much easier.

We’ve been in bug-fixing / testing mode for the past few months and have tried much harder to keep things out of the backlog if they didn’t 100% need to be there. There’s still things going in, but now we make sure each thing is absolutely needed for go-live and everything else goes on the list for after.

Mistakes != Fail

We’ve made mistakes on our project, for sure. We’re not done yet so I’m sure we’ll make more. But we’re learning, which is the important thing for our next projects. As a team we’re all committed to Scrum and being Agile so we’re going to make the effort to improve our processes where we think it’ll help. The more technical-oriented aspects of Scrum are incredibly appealing to us as developers. Keeping a backlog, committing to work, keeping interruptions to a minimum, sprints; all of this we’ve done mostly correctly and we love how it’s worked over the past year and a half.

I’ve spent the last 5 parts of this series talking about the basics of how we ran our project and the lessons we’ve learned while we chugged along sprinting. Next time, I’m going to start talking about what happened once we missed our first deadline. We changed our process, halfway-unknowingly moved away from Scrum, and suffered for it until recently when we did a reset of our process and got mostly back on course. Stay tuned next week and as always, I’d love to hear any comments you have on this series. Thanks for reading.

“Automated story-based acceptance tests lead to unmaintainable systems”

Projects where the team directly translates story-level acceptance criteria into new automated test cases set themselves up for a maintenance nightmare.

thekua.com@work » Automated story-based acceptance tests lead to unmaintainable systems.

One of the big things I’d like to do with our next projects is some kind of automated acceptance and UI regression tests. I’ve looked at things like Selenium and a little at FitNesse but I’ve worried about things like this article talks about, the tests becoming a maintenance challenge by themselves.

ScrumShocked writes about my articles

I've been following a very interesting series of posts (starting here) from Matt Grommes detailing his experiences managing his first agile project

ScrumShocked.

This is cool. This guy found my articles on AgileSoftwareDevelopment.com and writes about our experiences compared to his teams. This is kind of like being recognized on the street, awesome but strange. I like that people are getting something out of my articles though.

My First Agile Project Part 4: How to lose credibility and jeopardize your project with lack of management buy-in

Originally published on AgileSoftwareDevelopment.com

Picture courtesy of shaz wildcat@flickr

Welcome to Part 4 of My First Agile Project. If you haven’t read the others in the series, don’t worry. Each part should stand alone. If you want to read the whole story though, the other parts are available: Part 1, Part 2, Part 3.

In Part 3 of this series, I talked about our demos and I mentioned how they unfortunately turned people off the demo with presentations about mostly behind-the-scenes features. My first instinct was just to say that those people lost their right to have input since they weren’t involved in the demo. In reality, the business world just doesn’t work like this, much to my chagrin.

What happened was the people who didn’t care to come to the demos just came later with changes and “suggestions” for new work we had to do. Also, since a lot of the ones who were supposed to be coming were upper management, their lack of knowledge about the Agile processes we were using led to a lot of problems and misunderstandings later in the project. Read on to hear more about how we failed to get our management on board as much as we should have. Hopefully you can avoid that mistake and some of the problems we’ve faced.

Consequences of Boring Demos

Our tendency on the project was to demo everything. We wanted everybody to get credit for their work and the audience to get to comment on everything. We wanted to be transparent so we showed everything, even though we knew it was sometimes boring for the business people in the audience.

At first, I didn’t think this was as big of an issue as it really was since I thought people understood the process and would pay attention because this was their chance to give feedback. Instead, we got comments from people like “I’m not going to waste 2 hours sitting there listening to IT clap for each other.” This wasn’t to our faces but behind our backs when higher-level people were asked to explain why they didn’t bother coming to the demos.

I’m not sure what the answer is to this. It’s valuable to have these kinds of demos so people can show off their hard work and get the team on the same page. And it does give people the chance to give feedback, but in practice, demos for stuff that happens behind the scenes can turn people off the whole process, which we learned can be worse than just not getting some feedback. Once somebody decides they’re not going to come to the demos any more, it’s hard to get them to reconsider when you get to the stuff they should be seeing. What ended up happening was that we would get feedback many sprints after we thought we’d “finished” some piece of functionality as word got back to somebody about what we’d built. We had to do a lot of rework due to this. Even things like finding out later what paper we were going to use for printing invoices came back and caused rework.

Getting Management Involved

Beyond rework, not having management involved is an even more important consequence of turning people off the project. At our company, managers and directors do a lot of the work so we invited a lot of upper level people to our demos. Getting these people on board and understanding the process is more important to an Agile project than I originally thought. Our project was the first exposure that our company had to Scrum and Agile processes so we tried to explain what it all meant so everybody would know. It was clear early on that the Agile ideas weren’t being understood at the higher levels of the company so at our second or third demo I gave a small presentation about the Scrum process and thought that some upper management people would be there to learn about it but they didn’t end up coming. We tried as we went along to get everybody on the same page as well but we mostly used the demo as the communication channel so with people not attending the demos knowledge of the problems didn’t get out there like they should have. In retrospect we were not as forceful as we should have been in getting the information out there. You just can’t expect that business people will be interested in something like Agile without a lot of hand-holding about it.

When we got down the line and were in trouble with problems on multiple fronts our management just saw the project was late and we were responsible. The clash between how a company wants to work with big projects (set deadlines, set budgets, etc.) and how Agile deals with big projects is real and if you don’t work hard to get people to understand the differences, you can’t come in after the deadline has been blown and expect to educate anybody. You need to start early with planning and estimating, make sure everyone involved knows where the project is at all times, only then can they reconcile how the project is going with the budgets and the deadline. See Part 1 of this series for more on the problems we had with not estimating and planning correctly. But you can do all the planning in the world and if the information isn’t getting to management or if they don’t know what it means, it’s just noise and people will ignore it, to your peril.

If we’d been communicating all along, we’d be in a much better place. As it is now, I can see that we as a team have lost a lot of credibility and I believe our ability to continue using agile processes is probably in jeopardy.

Team Responsibility

We can argue that a lot of the problems we’re having are because of bad 3rd party vendors, complications in the product we were integrating, problems converting data, etc. but at the end of the day we’re a team and this is our project so the responsibility is on all of us. Agile isn’t just about getting management off your back or freeing the team from over-documenting. It’s about the team taking responsibility and part of that is not giving up power over your project any more than you can help. Good managers don’t just shrug their shoulders and let things happen to their projects and that includes self-managed teams. We should have insisted that certain people attend our demos and keep up on our project status just like we insist that our fellow team members don’t slack off and endanger the project. That takes some courage, to be sure, but it’s important. When you’re building a product for internal use, the users and management are a part of the development process just like the development team is. This is a change for a lot of people but the team has to insist that everybody participate if the outcome is going to be a good one. We’ve certainly learned this lesson the hard way but sometimes the hard way makes the best teacher so we won’t soon forget.

If you’ve had issues with getting management involved on your project, please share. I think it’s in the nature of most developers to not place the importance on management participation that the issue deserves so if you’ve learned this lesson, or if you think I’m putting too much emphasis on it, I’d like to hear about it. Thanks.

Clean Code Review

As developers, system admins, and a variety of other roles in IT, we have to deal with code on a daily basis. Sometimes it's just one-off scripts we never have to see again. Sometimes we stare at something that, for the life of us, we can't understand how it came out of a human mind (or, as the book puts it, has a high WTF/minute count). But there is a time when you find code that is a joy to use, to read and to understand. Clean Code sets out to help developers write that third kind of code through a series of essay-type chapters on a variety of topics. But does it really help?

Slashdot | Clean Code.

Good review of a book I’m hoping to get to reading very soon.