My former fellow co-author on AgileSoftwareDevelopment.com, Jurgen Appelo, periodically compiles a list of top blogs for developers. This time around, he did a Top 200 and I was surprised to see this very blog at #196! If you clicked over here from there, welcome! Since the list came out on the day I did my first post in a month (!), I’ve been self-shamed into posting more. :)

I’ve been working a bit with JavaFX so I’ll be posting about that and we just started on our next big project at work so I’ll probably be posting about that as well. On top of those topics I’ve made a list of important books I need to work through to help my Java programming so I’m planning on writing about that process. All in all, lots of geeky goodness to come I hope.

Picture courtesy of sa ku ra on flickr

Welcome to the newest installment of My Agile Team, my team’s ongoing series of misadventures in trying to get better at Agile development. This time around, we’re still playing Whack-A-Mole on the list of bugs we’ve encountered since Go Live. We stomp one out, another pops up.

What I’m going to discuss this time is our approach to trying to fix these critical bugs while maintaining at least a semblance of our Agile nature. It’s hard to do a planning meeting and decide on what to work on when you’ve got new things popping up and old things dragging on. Read on for more on how we’re planning in the midst of firefighting production bugs.

Bugs incoming!

We did a lot of user testing. I mean a lot. The app is a billing system for an insurance company and 4-6 members of the billing team worked overtime for months to go over the system with as fine of a toothed comb as they could muster. And still, when we went live we started having problems we’ve never seen before. Billing in insurance is complicated and it’s not until you have to live with the decisions you made in development interacting with real people and real situations that you start seeing some stuff, there’s just no way around it.

Planning with fire

The question is, how do we plan for this? We’re trying to keep on the Scrum path and plan but as I mentioned last time, our “Top Priority” / Critical list is now 10 items. As soon as we get rid of one of them, another pops up and since it has to do with people’s money our Product Owner labels them critical. What we’ve been doing is using the critical list as our Product Backlog. We’re still not in the habit of estimating the size of the items the way we’d like to, but with most of these things we don’t know what they are until we get into them anyway. So we basically take the list of critical bugs and split them up based on who originally worked in that area and how much bandwidth people have. Giving people items in the area they worked on is really just to help speed up the process since hopefully the person with the knowledge already in their head will get a faster jump on things. Since these are by definition weird bugs though (if they weren’t weird we’d have seen them before) sometimes prior knowledge doesn’t help.

The Red Queen’s Race

The problem of course comes in between planning meetings when new critical things come up. Since to our Product Owner everything that’s critical needs to be fixed now, there’s not much we can do to re-prioritize. Some things are obvious but most stuff just goes on the list to fix as fast as we can. This is what I mean by Whack-A-Mole, we knock them down but there’s always new ones in their place.

The Finish Line?

At this point we’re just hoping the point where we stop finding new critical things comes soon. Our manager took our extremely rough time estimates and told the company that meant we would be done with everything in 2 months so we’re all shooting for that goal. Any comments from me about this will have to come over beer. :)

Agile Much?

At this point I realize that this series hasn’t exactly been All Agile, All The Time as much as I wish it were. I’m doing my best to keep our team and these articles informative and focused on Agile but it’s been difficult. I’m trying to make sure reading about our progress (or lack thereof) isn’t as hard as actually living it but I also think it’s valuable to see somebody else’s story, even when it’s a lot of running in place. I really, really hope that we make progress in the coming weeks and I have better things to write about next time. Thank you for reading and if you’ve kept up with this series, thank you even more.

If you have questions for me or suggestions for something you’d like to see me write about our team, I’d love to hear it in the comments below. Thanks again.

Picture courtesy of John-Morgan on flickr

Welcome to the second installment of my new series, My Agile Team, where we’re following my team’s progress in getting more Agile and in moving from one project to multiple projects. Right now, we’re still trying to put out fires and finish up the big project. We hope to start adding in things from our other projects in a couple more sprints.

The fires I mentioned are our term for the emergency stuff that pops up and has to be taken care of Now. This is usually things that customers will see; their bill being the most important. These seem to still pop up every couple of days so we have to drop our Sprint tasks and take care of them quick, fast, and in a hurry as my Dad says. It looks like we’ve probably stomped out the bulk of the underlying problems causing the most important fires so this coming week I’m hoping will be a little less crazy (of course now that I’ve said that, we’re in trouble). Once we all have some distance on these issues my goal is to do a deep retrospective just on these issues that have come up since Go Live and see if we can root out anything we should have differently for next time.

One thing I’m struggling with right now is trying to get the Higher Ups to understand why we shouldn’t use real time estimates on the stuff left on the big project. Read on for my thinking on this and how I’m trying to influence things.

One of the big problems I talked about in the My First Agile Project series was lack of management buy-in on our project. They all knew we were doing Scrum and supported our efforts, but I don’t think the real nuts-and-bolts of the process sunk in.

One of the places I’m sure we didn’t do enough education is on putting estimates on tasks. Our manager wasn’t a part of the Scrum team during the big project so she doesn’t really know what we used to do. Now that we’re trying to finish up, she wants real time estimates on tasks to tell others in the company when we’ll be done. I appreciate the idea behind this, but I’m not sure about the best way to give her and the company what they’re asking for. I gave her my copy of Mike Cohn’s Agile Estimating and Planning with some relevant chapters picked out but that’s obviously not going to be enough on its own.

Obviously part of the point is that we don’t know how long these last things will take. All we can do is put rough “ideal time” estimates on them but then as Cohn notes in the book, you run the risk of people not differentiating between “ideal time” and “real time”. Since we really have very little in the way of big items left on the backlog, our compromise for now is putting ideal estimates on with the understanding that there are fires to be put out that seriously affect those times. Then we have to hope that this understanding gets communicated up from our manager to those higher in the chain. This isn’t optimal but I’m hoping once we’re a couple more sprints out and putting in other project tasks into the backlog that we can come to a better understanding on estimates and communicate that across management.

This is a tricky time for our team. On the one hand, we launched the product finally and people like it. On the other hand, we were very late and we’re still putting out fires. Our official manager is now back to officially managing us and hadn’t really had a lot of immersion in the Scrum process during the project. So we have to educate her, get back some lost credibility due to the lateness of the project, get back on track with Scrum, and finish up the last issues. We had a joke in the department that Only 3 Things Can Be Top Priority but we’ve recently increased that to 10 as having 3 Top Priority things is now seen as kind of a luxury. I fear if we don’t get our act together on multiple fronts all at once, the company could really start to see the Scrum/Agile process as a failure and we could go back to our old ad-hoc, somewhat random task assignment process which none of us wants.

My biggest piece of advice for trying to turn your team into an Agile team is to get on the same page as a team and educate the heck out of everyone. Each other, managers, everybody. Have your books, articles, presentations in order and bring them out at every opportunity. If you have to give in on a piece of the Agile process, make sure everybody knows what the tradeoffs will be. Speak up. If the process is important to your team, it’s important enough to speak up about, even to management.

Well, that’s it for this installment of My Agile Team. I’ll be back next time with what I’m seriously hoping will be the last sprints of cleaning up the big project and putting out fires. Thanks for reading and as always, if you have advice or comments please make them below. I love hearing from everybody and obviously, I need the help. :)

Previously in My Agile Team
My Agile Team: On The (Scrum) Road Again

Picture courtesy of unoguy on flickr

In the previous part of My First Agile Project I talked about the recent tempest in a teacup regarding the failure and fall of Agile. A commenter on that post ended up crystalizing something I thought during the reading of various posts on the subject; should we have hired an Agile Coach to help us start going on Agile? This is an important question for me in trying to figure out what we could have done better as well as for other teams starting out on Agile as well. This is an issue for Agile itself as well, whether a coach is needed for teams to succeed or not. Read on for more on this question and whether I think all new Agile teams need a coach.

When we started this project, our vendor brought Scrum to us. They recommended we buy Ken Schwaber’s Agile Software Development with Scrum and had one of their people give a presentation about Scrum. After that, we were on our own. Most of us read the book, me included, but none of us apparently internalized all the important parts of Scrum. As I’ve mentioned before, we didn’t do a good job of keeping track of our backlog or estimating things to know how much work we were adding to the project. These two omissions were the main reasons we got offtrack so badly without knowing it.

Would a coach have helped us with this?

It only really became an issue after 6 months or so when we’d added a ton of work to the backlog. When we started we thought we were doing really well with Scrum and honestly I think we figured if we got off the path our vendor’s people would help us back on. But I think they were as new to the process as we were. So if we’d had a real coach in the office to help us start, I still think we would have gotten off track eventually unless that coach drilled into us the importance of tracking the backlog over time like we should have been doing. I haven’t (yet) gone back into Ken Schwaber’s book to see what it says about grooming the backlog but if we had just read more about the Scrum process wouldn’t that have done the same thing? So I’m not convinced that having a coach in for the start of the project would have helped.

What I think would have helped was a real hard look at the entirety of our process after 6 months or so. We should have done a “Half-way Retrospective” to re-read the book and do a hard examination of what we were doing. That’s the point where I think a coach might have been more useful. It’s hard to look at your own processes so sometimes an outsider, especially one with deep knowledge of how the process is supposed to go, can come in with fresh eyes and get you back on track. Maybe 6 months is a little too long but the point is that some time has gone by with the team working hard on the project. In my opinion the process of Scrum is easy enough that a small-ish team should be able to pick it up without outside help. After some time has gone by though, a correction might be in order, which is one of the main tenants of Agile anyway.

The question of having a coach at the beginning of the project is where I think coaching proponents, and the Agile community in general, needs to look. If you’re saying a project needs a coach from the start, what are all the books for? Why is the process so complicated that it needs a coach? If you’re starting a hundred-person organization on Scrum and need to do Scrum-of-Scrums or something out of the ordinary like that, then yes, a coach with experience in that process is a good idea. But for a smaller team, an internal IT department like us or a small software shop, I don’t think a coach is needed. Or maybe I should say, a coach shouldn’t be needed for the Scrum process. You might need a coach for making your team more cohesive or to help with management issues that might derail the Scrum process, but not for the process itself. If your team can’t make a good go of it by reading a book like Ken Schwaber’s, there’s probably something else wrong and all a coach is going to do at that point is help point that blocker out. Like people say, Scrum helps expose problems in the organization that other processes might have hidden.

During all the recent brouhaha one of the criticisms of Agile I read over and over is that the pushing of coaching means the process is just a money-grab. I don’t think this is the case at all and it’s a pretty offensive accusation, actually. But the fact is that this notion is out there and it’s something Agile should be confronting. If ‘hire a coach’ is the answer people keep hearing to solve their problems, it starts to look like either the process is too hard or the dreaded Consultants are just trying to attach their suckers onto our budgets. Maybe the Agile community needs to come up with a way of approaching the importance of coaching. A cohesive statement about what teams should think about when starting the process; when you probably just need X, Y, or Z books or when you should talk to a coach about your process up front. A response from the community in general or just from the “thought leaders” of Agile would be useful I think and clear up some of the confusion. If you’re trying to sell Agile to your boss, a survey of your company that helps lead you to a book or coach seems better than starting out with “first we’ll need to bring Coach X on for a week”.

Obviously, this being My First Agile Project, my experience is limited. But I have read a lot and gone to the Agile conference so I’m not completely talking out of my hat here. If you think I’m wrong or misguided, please let me know in the comments. I hope I’ve made clear that I think the question of coaching is one that needs a discussion, not just to be blown off. Thanks for reading and I’ll be back next week!

Picture courtesy of J.H.C. on flickr

Recently James Shore wrote an article called The Decline and Fall of Agile where he talked about how Agile, and Scrum in particular, is failing many companies. The main reason I started writing this series of articles on our team’s experiences was to help myself examine why we’d had such a hard time with Scrum in various ways. In this part of My First Agile Project I’m going to go through Mr. Shore’s article and compare it to our experiences.

In the article, Mr. Shore focuses mostly on the engineering aspects of Scrum, or lack thereof. In our experience, Scrum’s lack of proscriptive engineering processes is hardly the biggest problem. It could be that we haven’t had enough time to run into the walls of difficult-to-manage code that he’s seen but thanks to some of the other problems we’ve had with shifting requirements and the like, we’ve all revisited chunks of our code during the project and we aren’t slowing down because of it. Read on for more on Mr. Shore’s essay and how I see it through the lens of our project. It may be that Agile is declining, but if so it isn’t for the reasons he’s seen.

According to Mr. Shore, our project should be failing due to the fact that we don’t do the recommended XP-style engineering practices like Test First, or pair programming. At least, that’s what I assume he’s talking about since he never mentions which practices we should be doing. But I don’t see that at all. I see our project having trouble because of incomplete control of the backlog and other “project management” centric issues that I’ve talked about many times (see Part 5: Our Top 5 Agile Mistakes).

I won’t go so far as to say our code is a paragon of beauty or anything, but even without coding Test First (indeed, without many unit tests at all in some cases) and working mostly by ourselves we have a good code base. I’ve gone into my coworkers’ code and made changes without spending all day on it and we’ve all taken over things from each other with usually just a minimal knowledge transfer. And since we’ve been working on this project for a year and a half now, we’ve gone back to old code multiple times. Despite the essay basically saying Scrum is deficient because it doesn’t have XP’s engineering practices, this hasn’t been a problem for us.

I’ve always thought one of benefits of Agile was that it wasn’t a bunch of rules you “had” to follow but Mr. Shore doesn’t seem to feel the same way. He disparages the idea of taking Agile as a “Chinese buffet” where you take what you want and leave what you don’t. Unfortunately for our project, we didn’t know about some of the important things in Scrum/Agile but we also left behind things that we didn’t and haven’t needed without looking back. I like that there’s wiggle room in Agile. I like that there’s no checklist of approved procedures and methods for us to follow. In my experience everyone picks and chooses parts of methodologies that work for them, no matter what. Not every piece is going to fit your puzzle so you can’t force it.

If not doing every part of a theoretically perfect “Agile method” means somebody is going to say we aren’t doing Agile, fine. We’ll still call it Agile, as I’ve never seen the problem that some people seem to have with the name. We’re being agile in the dictionary definition so we’ll call it Agile. It works for us, we like it and we’re going to keep with it. We’re also going to work on making it better for us if we can. And if we want to try out pair programming or writing tests first, we’ll do that too and maybe we abandon it. We’re being agile.

This brings me to my final point. Maybe he and I are looking at this from different perspectives but I don’t like the talk about ‘rescuing Scrum’ and rehabilitating the Agile brand. The point of Agile is to help teams. If a team is having problems, the point should be to help them, not to make Agile look good. If parts of Agile or Scrum are helping, great. If something isn’t going to make a team’s life better, it should be left behind. I won’t say anything about the certification parts of the essay beyond saying that if somebody thinks they can take a course and apply methods X, Y, and Z to their project and succeed, they’re deluded. You have to live with it to determine what works and what doesn’t. Then you can keep the parts that work. But if somebody wants to say we’re not Agile because we’re only doing what works for us, they can keep Agile and we’ll keep working.

Thanks for reading. If you have comments on this post, and based on the sea of commentary around the web about it so far I imagine some of you do, please leave them in the comments below. I’m curious what you think. Thanks again and stay tuned next week for more of My First Agile Project.

Picture courtesy of cliff1066 on flickr

Welcome to Part 12 of My First Agile Project. Inspired by Peter’s recent 5 minute retrospective article, this time I’ll be talking about our retrospectives, which we termed our GBU or Good, Bad, and Ugly meetings. Our vendor brought these GBU meetings to us, along with the Scrum methodology, and while we weren’t doing everything by the book (not a surprise if you’ve read any of the other parts of this series) I think they were very valuable and still light-weight and easy enough to be adapted for other teams looking for retrospectives.

Read on for more on how we ran these meetings, what we got out of them, and what we’ll be doing differently in our next meetings.

Our Process

A good retrospective has to have some kind of structure to it, to keep from just becoming a complaint session or everybody sitting around silently. Our structure was to put everything into buckets of Good, Bad, and Ugly. Good was obvious; the stuff we thought went well during that sprint. Bad was things that could have gone better but weren’t terrible. And Ugly was things that were plain horrible, could have derailed the project, etc. Usually our Sprint Demo lasted a few hours in the morning, then after lunch we’d come back and do the GBU.

We started out the first few sprints coming in and just doing the three buckets in order; Good, Bad, then Ugly. Everybody would write down their list of things and we’d write them on a larger piece of paper and discuss. For Bad and Ugly, we’d also discuss things we could do to fix or make the things better.

After a few sprints, we started the meetings by going over the previous sprint’s lists of Bad and Ugly to see if we were actually taking care of those things or if they were just as bad. This is immensely helpful. It helps people speak up if they know their complaint isn’t going to be forgotten or blown off. This also acts as a retrospective on the retrospective, to make sure you’re getting benefit out of them instead of just wasting an afternoon. We also started doing the buckets in reverse order as well – Ugly, then Bad, then Good. We started this partially as a joke, because we didn’t want to end the meeting on a downer, but it was a helpful change as well. The Ugly and Bad lists always take more time to talk about than the Good list so it helps to give those the most time for discussion. And it does help to leave the meeting on a good note. Scrum is as much about how people feel than anything else so don’t ignore these kinds of benefits.

The biggest thing about retrospectives is to make sure everybody knows they can speak their mind. It’s not going to help anybody if people keep things inside and those things are just going to fester for that person if not resolved. We didn’t have any of our direct supervisors in our meetings, which let us speak to management issues at will. We also naturally kept things civil when it came to issues like work not getting completed, a benefit of us all being friends. I think my tendency to speak my mind, even on issues of upper management or other sensitive areas, helped as well. People saw that if I could run my mouth and be honest, they could as well. I didn’t set out to do that but I think it ended up helping.

Changes

When we started our retrospectives, none of us knew anything about them save what we remembered from reading Ken Schwaber’s Agile Software Development With Scrum and from our vendor told us. Now that I’ve read the excellent book on Agile Retrospectives by Esther Derby and Diana Larsen as well as what others have written about on this site and others, we’ll be trying some changes to our GBU meetings in the future. First, we’ll probably rethink the use of Bad and Ugly. It’s too hard to think of what makes something bad enough to be Ugly rather than Bad. Some teams just use a ‘What I liked’ and ‘What could have gone better’ approach and I think we’ll try something like that. Second, I like the idea of a timeline of events where people put things that happened on stickies where they happened in the sprint. This is part of Setting The Stage that Diana Larsen recommended to me at the Agile 2008 conference. This gets everybody on the same page before you start drilling down into details later. Other than that, a lot of the things recommended in the Retrospectives book and elsewhere seems like it would be important for teams that don’t get along but we don’t have that problem, which is one area in which we’re extremely lucky.

Overall, I’m absolutely sure our retrospectives helped our team and our project. Even for things like upper management not being involved, which I listed as an Ugly very early in our project and ended up being a continual problem, just talking about it with the team is useful. If people have these kinds of issues in mind, it can influence how you do things even if it’s not a problem that can be “solved.” I would really recommend all Agile teams do some kind of retrospective, even if it’s just a basic Good/Bad list of things on the minds of the team members.

Please share your retrospective tips in the comments below, it’s an important topic and one that everybody can learn something from. Thanks for reading.

Stand-up meetings are a healthy part of the daily routine. They are a useful forum to keep everyone up to date with the happenings of the team, escalate any blockers that may have arisen and set direction and focus for the days activities.

However, in practice they can easily degrade to daily habits, where each person talks, no one listens and nothing is accomplished. Observable signs that this is happening in your team:

Improvements to the standard stand-up meetings

Our project started out with excellent stand-up meetings. Even though our team was about a dozen people, they never lasted too long and were very informative. Over time though, as our project moved through different phases we took to doing longer meetings and moved them from the beginning of the day to 11am. Hopefully once we move off this project and recommit to our Agile system we’ll go back to real stand-ups and I’m for sure going to look at using some of these tips.

Picture courtesy of iowa_spirit_walker on flickr

And now, a story about physics. I’ll get to programming in a second though, I promise. In 1900 Lord Kelvin (of the Kelvin temperature scale among many other things) spoke at the meeting of Royal Institute in London. There was a consensus at the time that physicists had succeeded in discovering almost everything knowable about the universe. Kelvin was one of the believers in this idea and also one of the most powerful and influential men in science. His speech at the Institute was on 2 ‘dark clouds’ he saw on the horizon, 2 experimental results that didn’t fit in with what they knew at the time. Since they thought they knew almost everything, Kelvin was confident that these clouds would be found out and moved past sooner rather than later. What he couldn’t have known was that within the next decade, those 2 dark clouds would revolutionize not only physics but would literally lead to the invention of our modern world, including the computer you’re reading this article on.

Read on for how this story relates to Agile projects. Although if you’ve been on a sufficiently large project, you can probably see the connection between things on the horizon that seem small and end up having a huge influence on your project. In this part of My First Agile Project I’ll talk about a part of our project that seemed like a ‘dark cloud’ and ended up being a tornado tearing through our town.

The 2 dark clouds Kelvin was referring to in his lecture were the problems measuring the speed of the Earth around the Sun in what’s called the Michelson-Morley Experiment and the difficulty people were having in explaining “black body” radiation. These two experiments led to two of the most important discoveries in science, discoveries you may have heard of even if you’re not a science person: Einstein’s Theory of Relativity and Quantum Mechanics. This isn’t a science article and I’m not a physicist (just a ‘science groupie’ as Kevin Kelly says) so I won’t go into the whys and wherefores of these discoveries. But the fact that 2 unsatisfactory experiments led to theories that we’re still investigating today and to many, many inventions should be familiar to any one who has come across backlog items that blew out the schedule or required much more resources than originally estimated. It happens in every field and can break the assumptions and surprise even the smartest of practitioners.

On our project, our darkest cloud was generating invoices. Our project was to integrate a very customizable off-the-shelf billing system for the insurance company we work for. When we started, we had 3 documents we knew we would have to generate ourselves instead of using the built-in document generation in the billing system because they were too complicated. But even thinking they were complicated, the original plan was for one of our more experienced developers to use the invoice to come up with the system for generating the PDFs and then we would break up the work for the rest of the documents over the course of a few weeks. It turned out, however, that both our assumptions and those of the vendor were conflicting and wrong in different ways. We assumed that being a billing system, it would have built-in mechanisms for generating invoices. The vendor assumed that since every company has different requirements for invoices that each of their customers would naturally figure out their own way of pulling the data they need and generating the invoice.

Once we started into the development of the invoice and discovered that we would have to pull all of our own data from the system we doubled the time we thought we’d need for development of it. A developer from the vendor also started helping. After a while though, we were able to convince the vendor that they should give us a mechanism for pulling some of the data more easily and that would help their next customers as well. So now we could rely on them to make the logic match up between what shows on the screen of the system and what appears on the invoice. This helped with the complexity of the system immensely but by that time we had done so much of the work that converting to their new mechanism actually added time to the project. In the end this solution is a lot more maintainable though since we’re not duplicating their logic. Plus, the next customer to come along will owe us some thanks (we wouldn’t mind beers and/or money as well :)) for doing this work for them.

Invoices are just plain more complicated than we would have anticipated as well. A billing system has multitudes of different kinds of charges, credits, payments, reversals, writeoffs, and even things I still don’t understand like ‘negative write-offs’ which seems like an oxymoron but thankfully our Product Owner understands them. All of these things need to show up on the invoice, connected to the different policies the customer may have. We also need to make sure the invoice fits on the special perforated paper so the customer can tear off their bottom part and it needs to fit the envelopes and postal service requirements so they don’t charge us extra shipping. These are the tear-your-hair-out requirements you never learn until the last minute. Luckily this code ended up being developed by our most experienced programmer so even though there are what seems like a hundred corner cases for what appears where and when on the invoice, the code is easy enough to follow that I’ve made changes to it without having to spend all day figuring it out.

In the end, this particular dark cloud started out as something we thought would take one developer one sprint and is still not 100% complete after two developers have spent the better part of 9 months on it, including all the various things that have been discovered and added over time. Revamped invoices were part of the reason our company even decided to get a new billing system though so our Product Owner has given it the time it’s needed.

The reason I use Lord Kelvin’s ‘dark cloud’ metaphor is to show that even the best and brightest can underestimate what’s on or beyond the horizon, often in a big way. Accounting for dark clouds is what Agile does best though. In our case, the invoice is the biggest change our customers will see with the new billing system so it’s an important integration point that’s worth the effort. We’ve spent a long time on it but it’s definitely worth while and impressive as invoices go. We’re going to have less errors on these things than I get on invoices from my cell phone company, that’s for sure.

Thanks for reading and I hope this inside look at one big part of our development process was helpful. If you have stories or comments you’d like to share, please do so in the comments below. Thanks and stay tuned for more next week.

That link has the full list of announcements of stuff that will be in Java 7. This isn’t everything but it’s a good list. Here’s my favorites:

What will be in

• Modularization – 294 and project Jigsaw

Cool.

• 292 – JVM Support for dynamic languages

Yay!

• Null dereference expressions – Null checks with ‘?’ syntax similar to Groovy… lettingn developers avoid a nest of null checks.

This is objectively awesome. Less code is a big win.

• Multi-catch – (yes!) allows a comma seperated list of disjunctive exception types in catch clause.

I second the (yes!). Less code again, is win.

What will not be in

• BigDecimal syntax

Grrr. This sucks. I’ve been working on a financial system for over a year and the BigDecimal syntax is insanely painful. I’m really not happy about this.

One of the commenters on this post questions the lack of mention for JSR310 which is a revamp of the Date/Time system. I’d love to see this go in and since there’s already a great implementation in use I hope it makes it. Dates are second in my list of complaints right behind BigDecimal in terms of API confusion.

In all, I’ll be excited to see how Java 7 evolves as it comes closer. It’s still a year away probably but it’ll include some nice changes.

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