So I recently moved jobs… and cities…and countries and more importantly programming languages, environments and platforms. Big changes. I went from developing an off-the-shelf enterprise engineering application in C# (a language I had 10 years worth of experience with) on a windows machine, to a new company (Hello FreeAgent!) developing a SaaS accounting application in Ruby on Rails… on a Mac. Out of my depth doesn’t even begin to describe it… It took me two days to work out how to copy & paste!
Well because it was time for a change mostly. That old chestnut about wanting a new challenge was very true in my case. I felt a bit stuck in my ways and wanted to shake things up a bit. I wasn’t necessarily looking to change everything at once, but when the opportunity arose I wasn’t going to say no.
What have I learnt?
Being a newbie is a humbling experience, especially when you’re used to being one of the more experienced people around. Especially when you’re a manager. I wasn’t used to feeling useless so I had to quickly find ways I could add value to my team. I didn’t know the language or code base well enough to do any development immediately, so instead I had to look to processes to see where the pain points where and find ways to help out there.
It’s very difficult to go from being an expert to a newbie, I often found myself thinking I’d made a mistake. However it did make me think long and hard about why I was doing management – I’m not doing it because I’m better than anyone else, I’m doing it because I want to help my team do the best they can. Because even if I can’t write code, I can help them to write better code. I can remove distractions and deal with planning and worry about when things are going to fit in and leave them free to do what they do best.
It’s an experience I recommend every manager should try – even if it’s not in your day job. Go find somewhere and something where you’re a newbie and learn how to contribute something to that environment. You lean a lot about yourself and why you’re doing the job.
OK, looks like it’s time for me to dust the cobwebs off this blog as I’m hoping to speak at a couple of conferences this year.
I’ve got some posts lined up for the next few weeks, so keep any eye out.
We used to be very much of the mindset that each story had one person working on it at a time. Often people would say, oh I don’t think you can get more than one person down that hole. This lead to problems.
Large stories that would take a single person more than a sprint to complete are not uncommon for us. Partly because we’re not (yet) that good at breaking stories down and I suspect partly due to the legacy code we are working with. Anyway if we only have one person working on such a story they aren’t going to get finished inside a sprint, so it’s hard to track progress which can hide big problems for too long.
One of the ways I’ve tired to help people change their mind about the one-person per story mindset is to task up stories at the beginning of a sprint like normal. Then we position the tasks to highlight parallel streams of work. So if two tasks can be done at the same time they sit on post-it notes on the same line. It’s not uncommon for there to be 3 or even 4 possible streams of development for at least part of the sprint.
Related to this is that tasks that are ‘stalling’ (taking longer than expected) can also be split once they are identified. If we identify a task that is taking longer than a day then we ask what’s going on, what work is being done, what’s still left. I ask people to write their responses up as additional tasks in the same way as in the sprint planning. We can then split up these tasks amongst the rest of the team if need be and have a better chance of getting to done.
I’m sure the real solution is to get rid of the big stories, but until we acquire that skill (we’re working on it!), this process seems to be working well for us.
After three days of development I have a basic framework in place and about 10 automated acceptance tests. I suspect I’m far from the best solution right now, but it works and I think it’s reasonably easy to work with. I’ll be testing that theory soon though as the next step is to get the framework reviewed by some colleagues. I’ve already had a few people take a look and suggest some changes, but now it’s time for a proper code review.
I can see already how important it is to make the automated tests maintainable. If anything I think they need to be written to a higher coding standard than the rest of the application. Throughout the 3 days I’ve been working on this I’ve been constantly refactoring. If a method feels like it’s in the wrong place I take the time to assess where it should live. If a class name no longer fits, I change it. This absolutely cannot stagnate or it will become a burden to maintain and then the tests will be useless.
I’ve made rather more use of static classes than I would normally find acceptable, however SpecFlow requires the Before/AfterScenario attributes to be on static methods whereas our base class for database tests is not. To get round this I’ve created a static wrapper round the test class which exposes just the methods the automated tests need.
I’ve also ended up with a static object store so that I can split up my step definitions into several files. The idea being that you create an object in one step definition, put it in the store then get it back out in another step definition. It seems to be a neat idea, but I’m not sure it’s practical. Let’s see what my colleagues think, in the end they’re the ones who will have to use the framework.
*** Update ***
So the code review went well. I’ve added in some more structure to make it obvious how the system should grow (and so we don’t end up with monolithic files) and I made some improvements to the underlying structure after some suggestions by my colleagues. The real test will come next sprint when we write automated tests for another feature.
Over the past couple of days I’ve been trying to put into place an automated acceptance test framework. Just the beginnings really, but I have a new found respect for test automation engineers.
My aim is to just get something going, to make a start that other people can build on. I’ve taken one feature which we believed was no development effort, but which leant itself very well to automation. I’m also trying to be as agile as possible, developing just enough of the framework to meet the needs of the tests I’m writing now, but also trying to make sure I’m building decent foundations.
I’ve decided to begin my experiment using SpecFlow because it integrates nicely with Visual Studio and because I like the natural language support from cucumber. This might change in future, but I’m hoping it gives up a quick start.
Last night I went to a talk by Phil Trelford organised by software east. I’d heard a bit about F# and a friend had showed me some code, but I’d never tried using it.
Before the talk I was chatting to Phil and he asked me if I enjoyed C#. I said that I did and he replied that F# would change that! And I can really see why…. All the boiler plate is gone… Classes defined in one line, getters assumed etc. Makes for really clear concise code. I can see why it would be a great language to use to define your business domain.
The bit that had me amazed though, was the built-in compile time support for units of measure. You can define your units e.g. metres and seconds and then apply them to values in the system. If you try to multiply incompatible units or assign a value to a variable with different units you get an error at compile time. That’s got to be so useful for scientific applications.
Definitely going to try out some F# at home.
I tried this exercise from Jurgen Appelo in one of our weekly team time slots. You get 10 cards each with a different intrinsic motivator on them. In the first step you simply order them from most to least important. Sounds easy, but almost everyone has one or two they struggle to place, either because they find it hard to define (honour was a particular problem for my team) or because they value them similarly.
I was chatting to a friend yesterday and we were discussing how planning meetings, retrospectives and stand-ups can be really hard work when you have a group of people that just don’t want to talk. Agile needs good communication to make things work, so how do you go about persuading a group to talk when they are naturally quiet and shy individuals?
We have a few thoughts between us and I’ve come up with a few more since that conversation. Continue reading
Don’t Make Me Think by Steve Krug
This slim book covers all the basics for designing a usable website. It is really easy to read with plenty of pictures to explain the points. You find out how people really use the web (i.e. in a rush), which key areas of a site you need to get right and a bit about how to push back against daft suggestions from higher up. There’s also a good chapter on doing usability testing on a (very) low budget.The tag line for the book says it all really ‘A common sense approach to web usability’.
Although this book was almost exclusively talking about websites and I work on a web application I still found there were many useful and relevant points for out situation. Clear navigation, obvious search and getting rid of needless words are equally as important in web applications.
The section about designing the homepage was also interesting. Steve Krug makes the point that the homepage has to make it clear what the purpose of the site is. The product I work on has a web application as part of it’s suite of tools. As a company we don’t control most of the real estate on the homepage as customers can customise it to meet their needs, however I think it is still important to make the purpose of the site clear. We do have control over the title bar and left hand side and they can convey a lot of information on their own.
Last year we did some usability testing on some summer students working for the company. This year it might be interesting to start by showing them our web application and asking them what they think it’s purpose it. Can they tell just by looking? What would they use the site for if someone pointed them at it? I’d be interested to find out.
To sum up this was a very interesting read and I would definitely recommend to anyone developing or designing websites or web applications.
So I went on the course that goes with the book and I had a great time. It was Jurgen Appelo himself who did our class so it was good to meet him and he is a really interesting and engaging person. Despite having a horrible cold I didn’t find myself drifting off or losing track.
Over the next few days I’m going to write about a few of the ideas from the course that resonated with me. The first of these is slack time.
This is something that I didn’t immediately think of when asked about takeaways, but it’s something that’s been growing on me for the past day or so.
In our team we’re definitely guilty of not leaving any slack, the temptation is to fill up the sprints as full as possible, often with a bit extra thrown in for good measure. This leads to a relentless pace with us often feeling demotivated because we can’t get everything we planned done. As scrum master I’ve tried in the past to tone things down, asked the team to put less in, but in the end I fall into the same trap of just wanting to get everything done and keep the sponsors happy.
Looking back over the last release I’m starting to realise that this is not working well and we need to change. We need occasions where we can sit back and congratulate ourselves about finishing everything we planned. We need to feel good about ourselves now and then or it doesn’t take long before you lose your energy and then you end up working even slower. There are other bad effects as well, the crammed sprints mean that our testers fall behind and never quite catch-up which means we end up with a mini-waterfall rather than agile.
The problem is that on a 3 month release cycle it doesn’t feel like we have the time to experiment. If we plan in a really ‘light’ sprint with few features how are we going to meet the sponsors expectations, it can look (and feel) like we are just slacking off. There isn’t time for things to even out, or at least that’s the way it feels.
We need to find a way to break out of this cycle and to change the way we work, we need to manage expectations of sponsors so that we have the space to make these changes and we have to convince them that it will benefit them in the long run as well.