How well does your company do Scrum?

During the day I work in a Scrum team. I love Scrum (and agile in general), and the benefits it has provided for both the application as well as my personal working environment. But I don't think our company has fully embraced the idea...

Our Room

Early on our team was moved into what used to be a meeting room, which is fantastic as it has provided an isolated area where we can focus and get on with the work. Also we can have our stand-ups and planning sessions right next to our scrum wall with minimal impact to the rest of the floor. I don't even mind the fact that they removed the door (which has been a source of amusement since it happened), as we already had an 'open door' policy which is central to an agile process (although we now tend to book a real meeting room for our retrospectives, as these can get quite personal).

However, due to a reduction in the team size we had a couple of spare desks in the room, and they have now been given to people who are working for another team. They moved in today and didn't mind the fact that we were in the middle of our stand-up - they simply walked through us as though we weren't there, and talked over us so they could be heard. It wasn't really their fault as they were just doing as they were told, and are likely to be friendly (they are external contractors, so we don't know them yet), but it was an annoying distraction. It also doesn't help that they are on the other side of the room, and have constant visitors to help them with their work.

I anticipate that this will have a fairly strong impact on our velocity until we get used to the interruptions.

The Team

For each sprint over the past few sprints the team has changed (although in one sprint a team member left to work for another company, so that couldn't really be helped). Mike Cohn has stated in his new book Succeeding with Agile that it is not ideal to constantly change the team size, and that it can take several sprints to regain the velocity. His recommendation is:

Stop changing the team. Teams benefit tremendously from having a stable membership. Of course, team composition will change over the long term, but try not to exacerbate the problem by moving people back and forth between teams as is common in many organisations.

We have some additional work with tight time lines coming up within the next few sprints, and apparently the solution is to add another person to the team. Although they have some experience in the application, we have to take time to set them up and get them operational again, as well as deal with yet another change in the team dynamics. By the time we're running at an optimal velocity again, the deadlines will have passed.

Multi Tasking

You know how, no matter how hard you work, study, research, and generally improve yourself, there is always someone who is still better than you? Well for me at the moment that is one of my teammates. He knows everything about anything, all he touches turns to gold, and I have to constantly struggle to at least try to understand what he is talking about at times.

This person is at his happiest when he is getting his hands dirty writing code, yet he has been assigned the following responsibilities for the team:

• Team Member
• Technical Lead
• ScrumMaster
• Product Owner
• Project Manager

Mikes comment in his book about the ScrumMaster also being the Product Owner is

No. In the vast majority of times I've seen this done, the results have been disappointing. Not only does combining these roles put a lot of power in one person's hands, but it also creates confusion for both team members and the ScrumMaster / product owner hybrid.

He goes on to explain that "a certain amount of tension should exist between these roles" as product owners continually want more features, and the ScrumMaster helps to protect the team. Not only does this person have both these responsibilities, he has had no project management training and no desire to do it.

Additionally, this person is not 100% on this project as he has other responsibilities for other applications. In fact, just last night he completed a bunch of work in his own time for another project so that he could spend the day working on our application.

Yet he still turns up to work with a smile, is still fairly sane, and can still tolerate my (slightly) bizarre sense of humour. I have no idea how he does it - I would have been committed a long time ago if I were in his position.

Performance Reviews

I have recently completed my annual performance review where I was asked questions such as "How have I helped improve the company financially". For most of the questions, all I could answer was that I helped contribute when the team completed a particular goal. I can remember times when the team excelled, or delivered something particularly amazing, but not really my individual contribution to that amazing feat (although this could just mean that I generally sleep when in the office).

It seems contradictory to me that a department that is supposed to be pushing agile and teamwork, still has performance reviews at the individual level. I would like to see more focus on teamwork in the reviews, but this kind of thing is way above my skills and pay grade.

Conclusion

I still love agile and hope to keep doing for a long time, but I think some corporations have a long way to go before they adjust to this new "radical" way of doing things.

Tuesday, September 21, 2010

Update 1

Over the past couple of weeks I have been reassessing the role of the Project Manager in Scrum, and have come to realise that this role is now shared between the ScrumMaster and Product Owner. We've had it pretty soft until now as we had managed to retain a Project Manager who dealt with all the slightly more boring work. But those days are now over. Therefore even though we almighty developers don't like to get our hands dirty with petty management and financial concerns (and don't we have enough pain already with having to now - heaven forbid - test our work!), we have to accept the fact that it has now become a small part of our daily work lives.

Mike said in his book Succeeding with Agile:

On Scrum projects we acknowledge the untenable role of the project manager and eliminate it.

For example, without a project manager to assign tasks to individuals, team members assume the responsibility of selecting tasks themselves. Other responsibilities shift to the ScrumMaster or product owner

Update 2

My colleague who I mentioned above has now been off work for a couple of weeks with fairly severe RSI. I guess the stress finally caught up with him... :(

Unit Tests Rock!

While I've been a big fan of TDD for a while, I must admit that I don't always develop this way. Most applications I work on are large and have been around for many years, generally meaning that there are currently no (or very few) unit tests already in place. Inserting unit tests into an application of this type can be very overwhelming.

I am currently reading the excellent book Working Effectively With Legacy Code by Michael Feathers that details a lot of techniques to get your code under test (you can get an idea of what the book is like from this this article). While these techniques are very handy, it is still very time consuming to implement and convincing the product owners that this time is worthwhile can be very difficult, especially for a legacy application as described above.

Note that the term "legacy application" may seem a big rough as this application isn't terribly old, but Michael's definition of a legacy application is:

The main thing that distinguishes legacy code from non-legacy code is tests, or rather a lack of tests

However, I generally always use TDD where I can and when I don't have the pain of retrofitting it into existing code. I had the opportunity to do this the other day for a debugging utility that I had worked on. I am currently in the process of interfacing a legacy application with a new fancy Java based back-end application. The problem is that the new application is effectively still being developed, which means that the XML SOAP message we need to provide is constantly changing as the application evolves and bugs are removed.

To alleviate some of this pain, I built a little XML document manipulator into our interface application that would allow you to configurably manipulate the SOAP message by inserting, updating or deleting XML elements as required. I had initially built this right into the class that processes the message (I know - ugly!), but as the utility grew in functionality, I refactored it out into its own class and wrapped it in unit tests.

Being the typical lazy developer that I am, and as this was essentially a hack to help us with our real testing, I didn't actually test the new refactored class in the application, figuring that I could quickly fix any issues if and when they happened. No one seemed to be using this utility anyway, and I was feeling a little dejected because I thought it was pretty cool (it was fun to develop anyway) :-).

Anyway, Monday rolls around, its the last day of our sprint, and we have a demonstration to show at 2pm. Unfortunately the application had changed again, and we couldn't get any of our downloads to work. I became aware of the problem at about 1.30pm, and suggested that we use my "nifty" little utility to reformat the XML and get us through the demo. I was a little nervous that it hadn't really been used yet, but it was worth a try right?

Well, it worked first go! I was as stunned as everyone else. The unit tests had come to the rescue. Because of the unit tests, I had fixed many many problems while developing it and the end result was that it all worked correctly first go. Unit tests had saved our (especially my) bacon!

While I'm certainly not suggesting that we can forget about testing if we implement unit tests (actually, I still believe that while testing is boring, it is by far the most important part of the process), this example demonstrated to me again how important unit tests are.

The Case of the Irritating Tooltip - Part 1

For various architectural and historical reasons that I wont go into here, one web application that I work on (lets call it Qwappy) is built using frames. (I have previously entertained the idea of replacing the framed website with a fancy div version, but gave up after about 5 minutes after realising that the cost of the change would way exceed any potential benefits). It is pretty much the standard layout - banner at the top, treeview menu down the left, and main content forming the bulk - with a few extra frames included for fun.

The problem (well, one of them anyway) I have with this design became evident the other day when I was playing with the content of the menu tooltips. Hovering over an item in the treeview menu will bring up further details such as a price, an id, a fancy description, etc. It seems that every version of every browser renders the tooltips differently - from displaying multilines to wrapping or truncating the text. It is obviously not this extreme, but its close enough to make tooltips worthless for anything slightly more complex than a simple 2-3 word message. This is when I looked to the client framework for help.

Qwappy uses mootools for it's client-side framework (as an aside, check out this nifty and slightly outdated speed tester). I believe that mootools is a nice elegant framework, but these days I generally prefer an alternative framework that is natively supported by a well known IDE :-) So, solution fixed. Simply integrate the tips effect provided in the mootools more collection, and voila.

But no, that's where the real problems start. The menu frame is too small to contain the tooltip div, and being a div constrained by that particular frame, it wont cross over to the next frame so keeps dissappearing off to the left of the window.

Part 2 explores how I managed to fix this so that the tooltip acts as though there are no frames on the page...

Razor

Today I read a blog post written by the excellent Phil Haack that introduced the new razor view engine soon to be available for ASP.NET MVC. This led on to a more comprehensive post by the also excellent Scott Guthrie.

Even though it sounds really geeky, I fell in love with the simplicity of this syntax, and I've already had a few ideas of how I could use it. I have convinced a colleague from a side project that I'm currently working on that this is the way of the future, and he was thankfully willing to give it a try. I am now impatiently waiting for the release of the beta...