On The Inside: Kickstarting Agile at Work

Welcome to the first episode of the Allthings Agile journey: On The Inside. Pete, our new CTO, will be telling the story of our transition to Agile, detailing the highs, the lows – and most importantly-  the results.

Dave: “Mate, we’d like to offer you a position at Allthings”.

Pete: “Erm…ok…what would I do?”

Dave: “We want you to run the development team, and be our product guy. You know a ton about that Agile stuff”

Pete: “Ok, I can do that. Sounds a lot like what I was doing”

Dave: “And we want you to develop our productivity tool to be an Agile tool”

Pete: “Eh…do you know what that would mean?”

Dave: “No, but you do. And we want you to be our Agile expert…for the site“

Pete: “Eh…what..write a blog? I don’t know. Ahh, what the hell, count me in.”

That’s the conversation I had with Dave Hay, the CEO at Allthings. Dave and I had worked together at another local startup called HoundDog which had been bought and grown into LogicNow. Both HoundDog and LogicNow were a great time in my life and I have fond memories of working there. I decided to leave my position as Director of Engineering at LogicNow after 8 years with the company and I was looking for something new.

Going back to the start of the company lifecycle and working with people I knew on something I thought was pretty cool and was knowledgeable on just seemed like a perfect fit for me.

I’ve been involved with software development for the last 18 years, initially as a developer and then moving into team and department management. During that time I’ve introduced Agile processes wherever I’ve worked, largely due to reading Kent Becks’ Embrace Change in 2000. Dave wanted to bring “the Agile magic” to Allthings and I was sure I could do that as I’d done it many times before.

What was different this time was that he wanted me to write about it. To tell our story of our adoption of a new process and becoming agile – a honest account of the good, bad and ugly of our story as it unfolded.

allthings

Allthings & the new Dundee bridge last week

That’s a lot of insider knowledge. That’s a lot of myself to just put up on the web. What if we mess up? What if people disagree with how we’re doing something? What if I don’t really know what I’m doing and it’s a disaster? Get a grip Pete!!

The best talks and blogs I’ve read are always honest. The wins and losses put there for everyone to read are what makes them the best. I decided to be brave, dive in and just see what happens. I hope others find our story interesting and maybe even useful. It will certainly help me think about what we’re doing and force me to verbalise what has become instinct after this amount of time. I hope that it will make me a better professional in the process.

So here goes…

Allthings is currently a small startup. The development team consists of 2 full time developers and 1 part time developer. Marketing is done in house by a digital marketer/designer and a content writer. Allthings is right at the start of it’s startup life.

I joined after the team had been working on the product for 2 years. It had started out as a workflow manager, then moved to a to-do list, then to a productivity tool and lots of other ideas in between. It wasn’t immediately clear who it was for. It had lost it’s way slightly and needed a new focus and direction.

The initial feedback from Dave was that the development team had stalled. I didn’t yet know the details of why but I decided to go back to basics and I kept reminding myself of the three basic agile steps from this article by “Pragmatic” Dave Thomas – Time to kill Agile – where he lists the simplest steps to do something in an agile fashion.

photo-pete-1

• Find out where you are
• Take a small step towards your goal
• Adjust your understanding based on what you learned
• Repeat

Find out where you are

I needed to get a feel for the problems in the company. I was on the lookout for some of the more common problems I’d seen in other teams. I started asking questions. Questions like:

What are you working on now?
Who is responsible for the plan and what is it?
Where do new ideas come from and how are they factored into the plan?
How are you measuring the success of the software?

 

Where do bugs get raised and how do they get tackled?
What are the parts of the product you dread working on?
What would you like to clean up?

 

How do you know the software is ready to release?
How do you release the software?
How do you learn from the running system?

 

Often software teams have similar issues and I knew if I could figure out where & what they were we’d be able to solve some and move forward. I had spoken to Dave and asked him what his problem areas in the company were. The development team was his biggest issue. In my experience, and granted I’m a developer, it isn’t usually the dev team. It’s what the dev team are being asked to do or how they’re asked to do it.

Speaking to the guys in the development team over lunch it became clear that they were hard at work. They were all hard at work on three different projects:

1. They were in the middle of a UI revamp that had grown arms and legs. It was going to be done when it “looked right” and had no clean end goal.
2. They were also converting from PHP to .Net. One developer was working on this full time as a complete replacement for the existing PHP API. The API had also been improved during development meaning that the clients would have to be updated and the data transformed in flight during the release step none of which had been planned out.
3. The existing PHP running system was being maintained by a single developer who was made responsible for all bugs, improvements and operations of the system.

 

That is a lot of work to be doing at once for such as small team. Something had to give if we were going to change the status quo.

Take a small step towards your goal

My instinct was that by pausing threads of work and focusing the team on one project we’d start to make head way. This seemed like good sense, reducing “work in process” to increase the flow of work through the process. The running system is making money so that seemed like the one system to concentrate on. I paused the .Net transition and the UI redo projects. This freed up 2 people to help work on the running system.

Another effect of focusing work was that we also all started working on the same codebase instead of on effectively 3 different codebases. We started to pull together, helping each other  with bugs and where we could improve the system. Collaboration in the team was increasing.

Previously any and all bugs were verbally raised with the developers. The expectation of the person raising the issue being that this should be fixed immediately and shipped. There also tended to be several follow ups with the developers to find out what stage each bug was at and when it would be released. This was using up a lot of time and was distracting for everyone.

Working with the whole team, both business and technical, we agreed to change how we reported bugs as a group. We sat down to review and triage the bug list together. Marking only bugs that would stop us releasing as high priority and concentrating our effort on them. This formed the initial scope of the release. Once all the agreed bugs were done we’d release. If new bugs arrived we’d evaluate them as holding up the release or not. Simple but effective. This is a fixed scope variable date project approach. When the agreed bugs were done we could release.

To help drive out even more bugs the whole company pitched in with the testing. Picking different browsers and using the same rough test document. Previously this was left to one person to do but there was never enough time to do it properly.

Bugs were marked as completed when fixed so that everyone would know that they were fixed and there was no need to come through and ask in person.This touches on a wider theme of internal communication I’ll talk more about in another post.

 

We worked like this for almost 2 weeks until we’d fixed and tested all the bugs we’d all agreed to and felt we were ready to ship.

My attention turned to the release process.

Only the developer who had been responsible for the running app and was working on the single Mac machine could run the build process. The build and deploy process didn’t work on windows. This is a red bus problem. A problem of business continuity if that person is off or decided to leave. Very serious.

We swarmed around the problem and created a windows version of the build and deploy processes as soon as we could. We released the code on Monday night with all of us watching the logs, logging in and checking that everything was OK.

Success! The release was good. The initial customer feedback was positive. The team felt they’d made progress and more importantly had done it together. It was a huge effort by everyone and there was a collective sigh of relief.

Adjust your understanding based on what you learned

We’d reduced the work ‘in progress’ and freed up development time. We’d proved we could still release new features into our software. We’d created a clean slate to start thinking about what we wanted to do rather than what we had to do next.

We still had a lot to do to make the process and the way we worked together work for us. We needed:

1. A backlog of stories and a rough plan of the order for the coming weeks
2. Some way to verify the code we wrote
3. Separate development, staging and production environments
4. A strategy for .Net and how to handle our technical debt sensibly
5. A bug tracking and review process
6. …
.

The list went on and on. The team were sparking with all the ideas of what they could do next. Time to bring some structure to what we do and get organised.

Repeat

Pete: “Great job everyone. I’ve booked in our first sprint planning meeting for next Monday.”

Click here to read part 2: On The Inside: Is Agile The Right Approach To Take?

 If you’ve got any questions about Agile & Allthings, feel free to get in touch with me via feedback@allthings.io