My day job doesn't always involve a lot of new technology or techniques, but recently we have made a commitment to start using Agile techniques, especially Scrum and Kanban. So far this has involved projects already in the pipeline and designs I have (or should have) completed previously, but I have a small team now and we get together to do three week sprints to develop new software. Well, changes to an existing system.
Sprint Planning
To begin, we all get together (developers and testers, sometimes a business analyst) and plan the sprint. Again there is a more traditional plan already hanging around in the background with existing requirements which have become backlog items, but we still get together and discuss the requirements and assign a size to them. We're using scrum poker cards for this (either physical cards or apps for our phones). The item sizes are meant to be relative, but have no meaning by themselves. The idea is that you are not committing to work based on estimated time, but just a more vague idea on how big the task is. The reasoning behind this is that estimates are rarely accurate, so why waste time and energy coming up with hours when they will probably be wrong?The Sprint
Once we have committed to our backlog items (or have them committed for us), then its time to create tasks and begin work. Tasks come first, and are easily broken down and shared out. This is where our time estimates come in, as each task has a remaining time in hours. Using TFS, this then drives the burn down.It hasn't always been easy to come up with tasks up front. The first sprint took about a week to get everything in place, due to inexperience. This meant that we burned up for a while, not down. The second sprint was better. We got it all done on day one, and the burn down was a lot more helpful. This time around, the backlog items are not as good as last time, as we are using raw requirements from the customer without a lot of backlog grooming. This is partly due to the requirements being created before we started the Scrum approach, and also due to the lack of time spent working the requirements into backlog items. This is again partly due to inexperience, and also due to me not having a lot, or any, time to look at them seriously before the start of the sprint.
Test Left
One goal we have which predates the move to Scrum by several months is known as Test Left. This means getting test done early with partial releases from development. Previously we could go through months of development before any real QA besides what developers do themselves, which isn't always adequate, to be honest, especially when it comes to testing freshly built and deployed software. It has been difficult to make sure the development branch is in a place where a build can be created and given to test, and that we know that the components will install ok, and work as expected. It's ok testing something on your own machine, but can you be sure it will work for someone else?That's a challenge I'm still trying to work out, and probably my biggest problem at the moment.
Coding
Coding is nice, but I feel like I'm doing less and less of it. Once problem is that it requires a lot of concentration. One big complaint developers have is about interruptions.When you are in the middle of some gnarly code, you are thinking about that one thing only. Being interrupted at that point is annoying and very disruptive. That's something I try and keep in mind when working with other developers in my team. It doesn't work to well when I'm the one trying to avoid interruptions though.Demos
Demos are hard. You get all your code working nice on your development environment. The test team get it working for them. You run through the demo at the office, and everything works fine. Then, when you're in front of the customer, it all falls apart.Lessons from this: have complete control of your environment, and have a backup plan.
Control your Environment
Corporate networks are usually finicky things. Even if you manage to get to the outside world, it doesn't mean that something won't interfere with your communications. Best to host everything in one place, e.g. a VM on your laptop, or in the cloud, provided you at can at least fall back to mobile internet if the client's network fails you. Trying to connect a device over a network you've never used before is a recipe for disaster.Backup Plan
Your demo isn't working. What do you do? Just sit there staring at your hands, hoping everyone will forget about you, get up, and leave? Being able to fall back on mobile networks, VMs hosted on your laptop, or even videos of the demo recorded previously enable graceful degradation of your demo.There's nothing like a bad experience to make you help you learn the right way though.
