Tools for agile development? These are the must-haves for every dev team

What tools are essential for agile development? A code editor may be enough to get started. But what are the must-haves for every dev team?

(1) Software versioning

Never develop software without a versioning system. Why? sooner or later you will need to know what you changed since that last version that actually worked and did not have that strange bug you have now been tracking down for hours. Or you may need to fix a minor problem in the productive version but don’t want to roll out all your latest untested changes. Or you work in a team and several people contribute to a common product or service.

A version control system is a central code repository and provides what you need to combine work results in a controlled way. Don’t try to get along by copying your sources around in different folders or zip archives. There a many great tools for proper version management, pick one and use it. GitHub is one of the favorites. it even takes care of permanently and securely storing your sources. Left your notebook in the coffee shop and now it’s gone forever? Well bad luck, but at least you still have your source code available. And while we’re at it: put everything under version control, not only your source code. Version control your configuration files, your specs, your user documentation – whatever you and your team are producing. It’s just like a car insurance – sooner or later you will be grateful for having it.

(2) Issue tracking

Software comes with bugs, and you need a system to keep track of them. You’ll want to know what problems have been found in which version of your software, what has been fixed already. Team members will need to add comments, logs or screenshots to an incident. Ideally you may want to link the issue to the code in your central repository that fixes a the problem. And since you work in a team you want a system that supports simultaneous multi user access. Don’t waste your time trying to do all this with some spreadsheet software. Yes you could do that, but it won’t really work. There are many good incident management and bug tracking systems available. You may want to take a look at the issue tracking that comes along with GitHub, or check out Jira – these are probably the most popular ones.

(3) Build and deployment automation

Software is born on one or several developer machines, but this is (hopefully) not where it is going to be run for productive use. Various steps need to happen before the checked-in code arrives in production. Depending on your development environment, programming language, used components etc. the artifacts for the prod system need to be built and versioned. You may want to apply static code analysis. Deployment to a test environment comes next. If all tests have been passed you or product management or whoever is responsible for that may decide to put that shiny new version out for productive use by your customers or users.

Let’s note that most of these steps need to be automated in order to get to reproducible high quality results. The system behind this is often called the build pipeline because things happen sequentially in a predefined order. If any of the steps fails the pipeline stops – the team needs to fix the problem and restart the pipeline again. A basic build pipeline system is e.g. available as part of GitHub. Then there are many open source and commercial solutions out in the market, and each of the major cloud providers offers a solution. If you’re not sure what to use start with GitHub – you can always move to some other system later on. Just make sure that you have an automated build and deployment approach right from the beginning. Improve it over time.

(4) Team collaboration

This is a crucial topic and the perfect approach for team collaboration yet needs to be uncovered. And of course no tooling will ever replace person-to-person communication, willingness to engage, to share information, to work together. Check out this [] blog post to dive into this. Having said all that – collaboration is still an area where good tooling really can make a huge difference. What you want to have is a central place for all your team’s information sharing needs. Documents, drawings, ideas, team calendars, whatever. You will want to search for stuff, and create links between various pieces of information.

Of course you could just store stuff on some shared folder or Dropbox. However this will be far from good. Who will want to browse around in some obscure folder structure? Admit it – this does not even work for your own stuff on your notebook, am I right ? We are in the new millennium and Wiki’s have been invented – if you’re not using one already please start to do so now. Once you have used one you’ll wonder how a team could ever have survived without. It will of course only be accessible by your team, and each member can set up new pages and content with a few clicks. Documents become much more lightweight and can easily be interlinked. Updates are done in seconds and you’ll have one valid version per document only. Paradise. Who knows, maybe even your most no-documentation-required style people will start to add stuff to existing pages.

There are many hosted Wiki flavors out there, setting one up for your team is a matter of minutes. A good choice is Confluence (by Atlassian – no I’m not getting paid by them, I just like their software). If you happen to use their Jira for issue tracking you can take advantage of the integration between both. In my opinion a great choice and all you need to cover your team’s basic tooling needs.

(5) Is there point 5 ?

Well there’s many more tools out there for life-cycle management, test automation, code analysis, etc. etc. – but these may be somewhat more advanced topics and your needs will depend on the type of software you develop, on your programming languages, target system and so on. For now we wanted to stay with the indispensable basics. You can always add to your tool-set, just make sure you’re not missing out on versioning, build automation, issue tracking and a Wiki – the basic tools for efficient agile development.

Check out these related articles:

January 2, 2019February 2, 2019

What is DevOps? How development for the cloud changes a dev teams life

What DevOps means is quickly explained: Development + Operations together. ,But what does DevOps really mean for development teams and their day-to-day work? And what is ‘operations’ to begin with…?

“Operations” explained

What is operations, does all software need to be operated? To explain this let’s take your local Word and Excel, or whatever local software you have installed, as an example. It just sits on your notebook. Once in a while you’ll probably update it to a newer version but that’s it. It is your personal software on your own machine – no real operation involved.

Compare that to your email. Here again you may use some local client, or just the browser. No operations. But then there is your email provider and all that is required to manage your mail account and transmit your mails. This is done by services that run in some datacenter and you can count on a team of experts that look after that software. They’ll make sure that the system runs smoothly, they apply the latest security patches, protect it against hacking attacks and securely back up your data, to name just a few of the tasks. This is what an operations team does. And you need to rely on it because you are using services that are not under your own control. Means whatever software runs in a cloud or datacenter will need operations.

Software development vs. operation

Traditionally there has been a very clear separation between teams that develop software and the ones that operate it:

DevOps separation of development and operation — Photo by Raj Eiamworakul on Unsplash (stuff in red by Tom)

The developers would write their code and maybe even test it 🙂 but as soon as possible throw it over the wall to the operations team. Then it would be up to them to figure out how to install and run it. Okay, maybe there are companies with good collaboration between these groups, but still there may be some conflict of interest. Developers will want their new versions out on the productive system as soon and as frequently as possible to bring new features and bug fixes to their users. The Ops team will try to slow things down a bit and play it safe since every update is considered a risk and may required some system downtime.

Operation for cloud software

Now fast forward to cloud world with an agile team in Scrum mode. Software sitting idle waiting to be deployed is considered ‘waste’. The infrastructure does not consist of physical servers owned by administrators any more. Now infrastructure is code and the dev teams’ architectural design decisions have a huge impact on the required cloud building blocks and corresponding cost. Also the ongoing operations effort is to a large part determined by the architecture. System changes may require modification of the infrastructure code, too: adapted configuration of the used cloud provider services, extensions to the system monitoring etc. The entire separation between development and operations does not make sense any more. As they say: you can do it, but it’s not good.

DevOps to rescue

Instead let’s put everybody in one team. Ensure that operational concerns are considered during development and when designing the system architecture. The team should consider the overall lifecycle cost and minimize effort accordingly. This is what DevOps is supposed to mean. No wall any more, not even two distinct groups, hopefully.

development team — Photo by rawpixel on Unsplash

Check out these related articles:

January 2, 2019February 2, 2019

What is SCRUM – setting up highly productive development teams

What is the best team setup for efficient development? How the Scrum methodology and agile principles can help to increase software development team productivity.

The challenging way to version 1.0

Let’s assume that you have a good-enough-idea of what you want to build, at least for the first version of the new baby. How do you start off? Just let the team work – after all they are professionals and they should know… You can do that but it won’t work. Why? First of all, despite all the lengthy discussions you still don’t know exactly what you want to build. Most likely every member of your team has a different version of that clear goal. And the tricky thing is that you are not aware of these subtle but relevant differences. Between your idea and the first version of tangible software you’ll have to cross the land of realization. These are dangerous grounds where orks roam and you better not send out the team unprepared. As long as you are safe in Rivendell make a plan that everybody can follow even when walking alone for some time. Slice the mammoth. Break down the work in small pieces and write them down, each part at a time. Make sure all parts fit together and that the sum of the parts makes up what you have in mind for that next version of your software. Put the parts in an order, with most important ones first, and assign each part to one of your team members. Sounds a lot better than just heading out into the wilderness, doesn’t it?

No Master Plan required?

No. You won’t create that 200 page master plan for all that may need to be done within the next 3 years. Don’t waste your time, things will change and if we’re honest you don’t even know what’s going to happen 3 months down the road. But the next 2 weeks should be doable. That seems to be a time range that humans can overlook. 2 weeks are still soon enough to review the first achievements. And just long enough to give the team the time required to create results in the first place. Feedback and intermediate steps are what you are looking for when navigating the uncertain plains of software development. An incredibly high percentage of software projects fail and that should not happen to yours. Don’t be afraid but also don’t be careless. The orks are out there and your team needs a structured approach to succeed. Many methodologies exist and the best choice depends among other things on what you want to build. If you’re about to prepare the next mission to mars you may want to stick to rather old school waterfall style approaches. For all others: take a close look at

Scrum and agile principles

This may sound very abstract at first but is very straight forward once you have a basic understanding. Much of this about accepting that humans seem to have great difficulty to define upfront how exactly that final software should look, work and behave. Of course you can try to define it to the last detail before building it – but it won’t be good, at least not nearly as good as it may get with more degrees of freedom to change and adapt. Think about a cook inventing a new recipe. Will he do it all upfront at his desk? The basics, sure, but the difference between good and great happens during preparation in the kitchen. So with software. Learning usually happens over time and the teams growing understanding of the domain unlocks new possibilities. However if change hits too often chances are that nothing gets ever done. Some balance seems to be required and this is where Scrum comes in. It strikes a balance between not planning at all (no, not good) and overdoing the planning part. It allows for enough flexibility to factor in changes but provides the basic guide rails and structure to keep chaos at bay. And it provides some insight into work and team progress over time. Sounds great, doesn’t it? Let’s take a closer look. If you want the full story go to scrum.org. What you read here is a high level summary.

Epics, User Stories and the Backlog

Did we mention the 2 week time range and that a breakdown of the vision to smaller parts is required? In Scrum these small parts are called epics and user stories. A user story describes a functionality, a feature, some requirement from a specific stakeholders perspective. It should be a very tangible thing with clearly defined outcome, with just enough information so that the people in the team understand what is expected. The team will order the user stories by priority – they all go into a central list called the backlog. And this is what the team is working on within the 2 week period – which is by the way called a sprint. Before the sprint starts the team has agreed on the user stories to be tackled and their priority. The backlog for this sprint is then fixed and the team can focus on working on it undisturbed. No change of priorities, no sudden additional tasks. Let the team do its job. In time before the next sprint starts there’ll be another planning for this next sprint. Then the game starts over again.

Why 2 week sprint cycles?

This is some sort of balance between structure and flexibility: the current sprint is fix, but you can plan the next one as required, factoring in whatever changes that came up. So the backlog is your definition of the work to be done, and it will change over time. However the team will work on stable ground and produce results every 2 weeks. Note that there is no fixed deadline and no fixed overall goal any more – it just doesn’t make sense in this ever changing environment. Instead there is the backlog and each completed user story drives the team towards the next better version. Some forecast about what will be available when is still possible but with less binding guarantee. This approach may sound very challenging in an enterprise, customer, contract context, and it somehow is. By the way – how reliable was your binding guarantee in the past anyway?

Overcome lack of transparency

This is another major challenge in software development. Where does the team stand? How much time is still required to get that next version ready? When will it be done? If the answer is ‘one more week’ or ‘one more month’ you know you’re doomed. These answers mean in fact that we are optimistic and quite sure that we can get the job done – but have zero clue about the remaining effort. Just leave me/us alone and come back again in one week/month. Then by the way you’ll get the exact same answer again. Sounds familiar? This is not bad intention, this is how humans are structured. We tend to underestimate larger work packages. Back to Scrum and the user stories. A story should be small and have a clear, tangible outcome. Something you could see or ideally test once it is done. Like an updated version of that UI with the new feature xyz. Small means it should be feasible to complete it within 1…3 days.

Break things down into smaller parts

If this sounds impossible break your story down to several parts, think about a step wise approach. Sounds like a bit of extra work but the team will get many benefits in return. Each small part will either be not started at all, in progress or done. That’s it. Nothing in between. No it’s-almost-done-come-back-in-a-week any more. The team will see that progress is visible on a day by day basis. Check out this blog post [] for more details. Ah, how will the team see that by the way? The backlog will be visible to the team at any time. You could do it via post-it notes on a wall, one per user story, as very basic approach. Or probably much better via one of the many available Scrum tools with online access for the team and a virtual board for each sprint. You can find some recommendations in the tools article.

Streamline team communication

This is the next critical element. No lengthy status meetings any more, from now on there’s only short ‘stand-ups’ but these happen each and every day. The team meets standing up. Don’t get too comfortable, this should be a quick thing, just a few minutes. Everybody tells what his/her current topics are, any problems or help needed? Then up to the next one, no lengthy discussions. And over, back to work. This approach is much more efficient than weekly status meetings that nobody follows over the entire time anyway. For any detail clarifications people can meet one-one-one as required.

Learning and improvement

Good is never good enough. At the end of each sprint the team will change the perspective to the meta level and meet for a ‘retrospective’. The purpose of this meeting is to think about the team as such, reflect on what worked well within the sprint, what did not, what could be improved? The team should capture and follow up on proposals and ideas. Make team members address impediments together. Get stronger and more efficient over time. And by the way this is it. Stand ups, backlog grooming and planning, a retrospective. No other meetings. Leave the team alone, give them the time to do their work.

And how about roles?

Scrum articles often start with role descriptions as if this was the most important thing. I think the idea is the most important, the team working together, ever improving. Yes, somebody should own the definition of the software product to be build, collect feedback and bring it back into the team, in general act as interface for the team towards the outside world. The outside world will be first of all customers and users, but also most likely other internal stakeholders like upper management, sales, marketing, whatever – depending on company size. This is the Product Owner (PO). The team as such is responsible for contributing to and for delivering on the backlog, but the PO is the one who writes the user stories and prioritizes them. This puts him in the driver seat for steering the product and ensuring fits with the overall vision and market requirements. However a smart PO will always collect as much buy-in and feedback from his team as possible. And then somebody needs to look after the process as such. Invite to backlog planning, ensure stand-ups are short and remove impediments for the team as such. This is what the the ‘scrum master’ does. The team could determine one of the members, or rotate the assignment. For larger organisations there may be full-time scrum masters that looks after several teams. And that’s it.

Check out these related articles: