We were invited to give a guest lecture at the University of Nottingham this week to form part of their 2nd year group project module. This invitation came about through discussion at previous group project open days when the parallels between small agile software development teams and the group project teams highlighted that agile methods might help students during this module.
Enthusiasm from our team to contribute to these lectures has actually led to the possibility a 3 lecture series from 7digital; with future lectures on Test Driven Development and Refactoring/Code Quality, the first was more about Kanban, Continuous Integration and XP/Agile practices.
We produced a short Prezi for the lecture which is available online directly on the prezi web site or should be conveniently embedded below.
To avoid providing a death by powerpoint presentation we often have different visuals to the actual content of the presentation. In this case we have a few text slides but the majority of the content was delivered during the presentation itself. To ensure that those that missed it still have the opportunity to gain as much information as possible we thought that we’d include it here on our blog.
The presentation takes the form of a day in the life of a 7digital developer, in this case, James Atherton. Each “slide” in the prezi represents a different event during James’ day, starting with the sunrise over London and arriving at an almost empty office.
Stand Up Meetings
Each team has a stand up meeting at around 10am. The purpose of this meeting is to get a quick overview of the team’s current situation, find out if any development tasks have been blocked, assign the day’s tasks, organise who will be pairing with whom and assess any broken builds. We physically stand up for this meeting to maintain focus and stop it dragging on.
During the 2nd year group project this type of regular, focussed and short meeting could be invaluable to the success of the group’s project. If you focus on blockers as we do, then the whole team can swarm on any bottlenecks so that problems are solved quickly and value can be added to your software consistently. We use this meeting to organise pairing, which means you can easily swap pairs regularly to ensure that everyone gets a good understanding of all aspects of the system. When I did my project in 2002 we split the team into programmers, documenters and organisers which I can now see was a mistake – sharing responsibility and knowledge by regularly swapping is a much better strategy.
The notion of pulling value through the various stages of development comes from the manufacturing of cars by Toyota. We use different styles of Kanban board for different teams but they all have something in common: features broken down into deliverable chunks and written on cards. The cards move from the left to the right with a focus on pulling things from the right. For example if there is something in the “deploy to live” column then this will get done before a new card is moved into the “in development” column on the left. You can see the examples of our boards in the presentation above.
The main benefit you’ll find by using Kanban in the 2nd year group project is the focus it provides and the preventation of overload. If you only work on one or two cards at a time, and deliver these to live before beginning any new cards then your software grows quicker and you can gain feedback sooner. Being able to get feedback from your users as soon as possible is invaluable to guide the features that you’re creating. This means that you can change the features in the system based on what the users are actually using the system for.
A good example is the failure of my 2nd year group project: we were asked to build a live catalogue of objects hat were present in a virtual reality world so assumed this meant a fully featured rendering of all the objects with some way of navigating. This wasn’t the case, the users only wanted to see the properties of the object in a simple tree view – had we delivered a basic text version first we would have known this was the only requirement but instead we spent weeks learning and developing in 3D graphics libraries, and our project was never finished, so the user never got a useful tool.
Kanban boards need to be visible and easy to use – we make ours with blutack, wool and index cards. All you need is 1 sq metre of wall space. Put one up in a team member’s house, or ask for some space on campus, or you could even try an online tool but you will lose the interactivity of it.
Test Driven Development
Not only will test driving your code ensure it works, it also means that the code’s API is loosely coupled as providing test coverage means that classes have to be open. One of the main benefits of automated testing though is the ability to easily re-run the tests and verify that your changes worked – this means you can make lots of small incremental changes to the software, making it easier to change, more readable and more robust with confidence. We use 5 levels of testing and we recommend you do the same. The same test driven development process applies to all levels; write a failing testing, make it pass, refactor to remove duplication and code smells, write the next test…
- Unit testing – covers the functionality of one a single unit of work, usually a single class or method, or the object’s collaborators and the messages passed between objects. You should have lots of these.
- Integration testing – ensures that parts of the system work together correctly e.g. the database adapter can read, write and transforms persistent data into objects correctly, or an external web service returns as you expect. You should have at least one of these per integration point.
- Acceptance testing – written using cucumber syntax (Given, When, Then) in plain English means that other stakeholders/users can describe how a feature will work by detailing their expectations. You should have a few of these per feature.
- Smoke testing – these usually cover the “happy path” use case of the application, for example, searching for an artist, making a purchase and downloading the mp3. They ensure that all aspects of the system are functioning together correctly and unlike most of the other tests, can assert that your live environment is working. You should only have a couple of these.
- QA – this level of manual testing through logical test plans, performance testing frameworks and randomised trialling is done by our QA team. You should ensure that you dedicate some time to QA as not all problems can be found by automated testing.
We are coming back for a lecture on Test Driven Development where two developers will test drive a simple application, live, in the lecture so that you can see how the technique works, and hopefully the benefits of it. This will be on Monday 28th November.
We pair on most development tasks at 7digital as it promotes knowledge sharing, prevents mistakes, ensures you get the best ideas from the team and makes the whole process much more sociable. If we’d used pair programming during my 2nd year project I’d have enjoyed it a lot more as the whole team would have shared the knowledge rather than one person doing the bulk of the programming. If you pair with someone who is a more confident programmer then you’ll become more confident yourself, ensuring that by the end of the project the whole team can contribute equally to the production of the software, presentation and open day.
We use Team City to track our builds and it runs builds that will compile the application, run the 4 levels of automated tests and even build deployment packages that we can then automatically (using another team city build) deploy to our testing and live environments. On a new project we’ll firstly try and deploy a “walking skeleton”. This will usually be a basic status page that we ensure we can deploy all the way to live. Once we know we can easily and automatically deploy our code it means we can add features much quicker, turning around features on some projects in a few hours. We suggest you do the same, automate as much as you can early on, and you’ll be relieved when you are developing features, responding to feedback and fixing defects later in the project.
Other popular CI servers we mentioned are CruiseControl, Jenkins and Hudson.
Releasing and Work in Progress Limits
As we’ve already said, automate releasing and do it often. There is nothing more valuable then getting feedback from your users. Break features down into small deliverable chunks – if this means hard coding a response from an external service or database then do that, at least your users can try it out with the hard coded data. Breaking features down is hard, but keep trying and don’t be afraid to abandon something that is too large in lieu of mocking part of the system.
When creating a new feature make sure you collaborate with the users to define the acceptance criteria in cucumber syntax that you can then use to write acceptance tests. Also ensure that you are not breaking any work in progress limits by pulling from the right on your kanban board and only working on a limit number of features at once.
We don’t do any formal design, we’ll usually have a session by the whiteboard to give a high level overview of the architecture but we prefer to test drive the code and let the tests document the functionality. If you spend time designing the system completely up front you will be less reactive to change and find it hard to adapt when you get user feedback.
Lots of things block our software development: dependant tasks, other teams, hardware issues and configurations. To ensure that the flow continues we “subordinate to the bottleneck” and swarm on the problem. This means the whole team will attempt to help solve the blocking issue rather than continue working and compound any issues. Blockers should be identified as early as possible – this is what the Kanban board and stand up meetings are for. I’m actually writing this blog post while the rest of the team are fixing a blocker – some of our test environments are down so deploying to these now would cause even more issues. Once the problem is fixed we’ll continue development but this focus on the blocker has created some slack time in the team that we can devote to other important tasks that are not related directly to development.
Googling terms like “Kanban”, “Stand up meetings”, “continuous integration”, “work in progress limits”, “test driven development” and “acceptance testing” should give you plenty of resources but some specfically useful books are:
We are always trying to grow our team with enthusiastic and intelligent people. We offer a number of positions for developers and even have an internship scheme. All the tips we’ve covered in our presentation should help you out with the 2nd year group project but above all, an understanding and experience in these areas will make you stand out from the crowd when it comes to looking for a career. If all graduates came to us with knowledge of TDD, CI, Clean Code and Kanban it would make expanding our team much easier: