Friday, 21 November 2014

The Project Board - How we implemented an Agile product road map.

Recently I gave a talk a the Newcastle Coders Group around the agile process that I and my colleagues have built up at work.  This talk covered a few areas but the key take away point that seems to interest people is how we applied agile techniques to higher level projects so that we could have a shared language with the stakeholders outside of the development team and our business could better understand what we're doing.  

One of the problems that we've repeatedly encountered over the years is that stakeholders outside of our Product Development Team (PDT) are baffled when we say that we are running out of work.  We're faced with responses like "How can you be running out of work? We've told you about all these things that you haven't done yet!",  and of course we experience the counter point to that, "Why haven't you done this thing that I want yet? You can't be that busy", the inevitable answer to which is "Because we're busy doing the other thing that you/someone else wanted."  I'm sure that sounds like something you've heard as well.

We've been building visibility into our process as best we can, We've got JIRA in place that's mapping our day to day work, but the business doesn't really care when User Story X or Y is done.  They just want the whole Feature Set.  So we felt that we needed to find a new way of communicating the work that we're doing to the people that are interested in our longer term plans not the day to day. 

Enter... The Project Board!

The project board is a special Kanban board that we've put together to provide visibility into what PDT is doing for those people that are not interested in knowing what we're doing day to day.  The board has five columns which track the progress of a project from being an early idea through to a marketable product. 

The first column is the Backlog. The Backlog is a catch all. If someone brings an idea to PDT it gets dumped here and prioritized.  If an estimate is required its done in T-Shirt sizes. There is no limit for number of items that are in this column, because it's a catch all. The projects that are in here are not ready to be worked on and don't even need to be well formed ideas.  

The second column is the Dev Queue.  To transition into the column an idea needs to be estimated and tasked up to the extent that PDT can pick it up and run with it without needing to do a whole lot of analysis.  The requirements are pretty large to get here because we need the stakeholders that are external to PDT to know what is required of them to get an idea to the point that PDT can work on it.  Because PDT always needs to have a next job to go onto in order to keep them utilised there is a one job minimum on here

The next column is Development.  Because of the requirements to get into Dev Queue to get into this column all an item needs is to be at the top of the Dev Queue column and for PDT to have enough time to get to it.  The Development column has a two job upper limit here and a one job lower limit.  As we're trying to manage the Development process the limits here are the key ones.  We need to make sure that PDT is kept at the highest level of productivity that we can manage.   

Once PDT thinks that it's done with the project the project it is pushed through to Release Candidate Testing.  This is the point where PDT is trying to release control on  the project, PDT need to have the release notes written and the application/feature set documented.  While its here there is still some discussion and support of the RC testers so it's not entirely out of PDT's hands.  

The last column is marketing.  Here it's completely out of PDT's hands and through to the people who will sell and support the product. 

I'm sure that the idea of managing higher level projects using Kanban is not a new one.  It is however one that still needs to be spoken about in the development community.  By using the techniques that we use day to day to help our productivity in a way that targets the more business minded we are able to find a common language that helps us all communicate. 

In the end good communication is the key to developing good software. 

Friday, 23 May 2014

My story so far...

I always like to know what influences someone I am reading has, it helps me to understand their position and how they have come to their opinions.  To that end the following blog is a brief overview of my software development journey so far.

My name is Klee Thomas and I'm a Software Developer and aspiring Software Craftsman. I'm passionate about Software Development and use words like craftsman and clean code, possibly a little to, often.  I only started developing professionally a few years ago and am lucky enough to work with people who share my drive towards self improvement.  I am a regular attendee and occasional presenter at the Newcastle Coders Group.

I am not one of those people who started developing at a ridiculously young age.  When I was in primary school and early high school I played the occasional computer game and made one or two Power Point presentations.  I had no idea what Software Development was, let alone how to do it.  I did a little programming in the later years of my high school career.   My teachers did a great job in teaching me how to find answers to my questions online and taught me some basic algorithms.  But the programming I did was really just enough to pass my assignments.

Through University I started to be a bit more interested in development, but still after the assignments were finished I didn't do a whole lot of self improvement.  With the help of my lecturers and tutors by the end of Uni I did have an idea that there was such a thing as good code and such a thing as bad code, but looking back I certainly didn't know the difference.

Towards the end of Uni I picked up a job doing some Tech Support for some local(ish) primary schools and there I had my first experience writing a piece of software that actually solved a problem for someone.  It made me feel pretty good and I realised then that where I wanted my career to head was towards writing software not doing IT support.

At that same time that I had that job I was working on my honours project at Uni writing some software that solved Ordinary Differential Equations using Python.  The code wasn't complex, in fact the main outcome from my honours project was how easy it was to solve relatively complex mathematical problems using Python.  Despite it's lack of complexity it gave me something to hold up in my next job interview.  As I was finalising my thesis I had a chance to showcase the code in a job interview. I proudly stood at the front of the room with my code displayed on the projector and showed it off.  A month later I would look over that code in embarrassment.  Fortunately though my employers thought that it was good enough to get my foot in the door.  I'm so glad that they saw potential beneath that code.

The software development team I worked with taught me about craftsmanship, clean code, automated testing and well architected software.  They changed the way that I thought about software, from something that is there just to get the job done to something that should be well crafted and maintainable.  The introduced me  to podcasts, presentations, blogs and books.  They had me consuming work by names I had never heard before, like Martin Fowler, Kent Beck, Eric Evans and Greg Young as well at this oddly named Uncle Bob. These people now strongly influence my coding style and opinions.  Clean Code, is compulsory reading for any new developers starting with us. I just wish it was compulsory at Universities and Colleges as well.

While working in this job I have worked on two separate teams, within the overarching product development team.  Both teams work in the same general domain but solve very different problems. The first team I worked built a client server application built on top of a CQRS architecture using version 1 of the Axon framework.  This was a steep learning curve from where I started.  Before this I had never touched C# and WPF, never heard of CQRS or event driven programming and had only the Java knowledge that I had learned at Uni.

The team I now work on an in vehicle interface that still needs to be responsive while running on dedicated, but memory and performance constrained hardware.  This brings with it a set of challenges, problems and solutions that are unique.

Outside of work I now strive to improve my skills.  Focusing on areas outside of that which I cover each day in the course of my job.  I doubt I make up the 20 hours a week suggested by Uncle Bob but I get in at least a few.   Hopefully having somewhere to document them will help with that.

To finish this blog I'll finish at the start. My name is Klee and I'm a coding addict.  It has been mere hours since I last coded and I have no intention of stopping now.  Expect to hear from me again as I intend to use this blog to document my experiences on my journey. 

Wednesday, 14 May 2014

NuGet Productivity Hack

This article explains how with a couple of quick hacks you can gain a little extra productivity when using NuGet.  The hack it's self is simple, Just add NuGet's local cache as a feed.  It turns out this can save you time, keep you team mates on side and even improve your presentations.

Originally I did this to help with development of API's that develop and use in house.  We were facing a problem with rapidly increasing version numbers when initially developing an API for the business logic of our product.  Each developer was working on one vertical slice of the product meaning that they may have to tweak the API if they found something that they hadn't considered in one of the layers of the application.  The simplest way to develop the package dependent on the API is to update it with NuGet. 

Our process for getting packages into the shared NuGet repository is simple.  We publish packages to NuGet after a build on our Continuous Integration server.  That way we know that each build has passed tests and that each package is as stable as it can be.  We follow Semantic Versioning and our rule is once it's in NuGet it's published.  So any change to the interface after that point means that the version number needs to change.

So in order to include a package into the dependent project without first pushing it through the NuGet process I needed to publish it locally.  I had to pick somewhere so I thought why not into the local cache. This way I don't need to keep tabs on somewhere else in the system and as long as the version of the package that I finally pushed to CI was the same as the last one I pushed locally or had a higher version number then NuGet would take care of making sure that what I was developing against was the same as everyone else. Unless of course it explicitly wasn't.

Great, with this I was able to develop an API, change it as often as I wanted while making sure it integrates smoothly with the dependent package and not ramp the version numbers up needlessly.  Awesome! that's some productivity bonuses right there.  No more waiting for the slow build server to build and publish the package.  No more annoying the rest of the team with increasing versions and breaking APIs.

But this is all expected, it's the desired outcome of the problem I had.  I got a pleasant surprise as I kept working.   With the local cache at the top of my NuGet repositories list it was loaded up first when I went to add a new package.  Because it's accessing the local disk, an SSD, it was almost instant to load the add packages dialogue.  I'm not sure if serving the package list is universally slow or if it's our internal infrastructure but I found that this saved me several seconds and a fair bit of frustration when going to add commonly used internal and external NuGet packages. This may not save too much time but it does save a little frustration waiting for the NuGet dialogue.


The other day while attending the local Newcastle Coders Group we had Internet access issues, rather par for the course at the University of Newcastle.  These issues inhibited the presenter from being able to add the packages he required in order to do his demonstrations.  This might normally have stalled the presentation.  Instead I was able to get him to hook up his local cache as a repository and continue with the presentation.

So there we have it.  Publish packages to a local NuGet feed and avoid annoying your team members.  Make that feed  your local cache to speed up your daily development in adding regularly used packages to projects.  Use the local feed to have access to regularly used packages when for some reason you have no internet access.