Busy Time – Agile Anti Patterns

Busy Time – Agile Anti Patterns

Every development team is different. Sometimes you walk onto the floor where the developers live and it is a hive of activity. There might be a few people clustered around a white board, whilst others are having an animated discussion around a screen.  Often the workspace is set up to enable easy communication with no barriers, and break out areas where people can go to focus on a particular challenge. Through that noise, movement and activity you get a sense of collaboration.

Other times you can be deafened, deafened by the clattering of keyboards… and nothing else. People are obviously busy and getting things done but what they are doing is not immediately apparent.  Sometimes conversations will spark up but they are often muted with people wanting to get back to the task in hand. If you observe longer you might find people getting frustrated with each other, annoyed about interruptions and thinking that time collaborating in meetings is a waste of time, time away from getting real work done.

I’m going to suggest that the way success is measured in these two extreme examples is different. And that may be driving behaviours.

In the first example I would guess that the team is motivated by flow. They want to minimise the cycle time of getting work completed. This is driving collaboration and the desire to minimise work in progress. Whilst it might seem from the outside that all the noise and communication is wasteful and yes it might be less efficient from an individual’s perspective, it is effective in getting the work in hand done.

In the other scenario, you could walk up to any person and ask “are you busy?” and you would get a resounding confirmation. People in that team may feel maxed out. And it is likely that their managers would be very happy. After all, each member in that team is being fully utilised writing code. What’s not to like? The managers may even be reaching out to the recruitment market to ensure that the organisation’s delivery commitments are made.

What is happening is the two organisations are optimised around a different dimension. Team 1 are flow optimised and team 2 are resource optimised.

If you buy into lean thinking, then the focus should be on flow and not resources. Results for a business are achieved when ideas are processed by the development team and release to customers as quickly as possible.

Running people at 100% capacity is risky. By definition something at 100% capacity means nothing else can be taken on. Upstream that means work can stall. It means there is no contingency for the unexpected. Busy people become bottlenecks. If you are a bottleneck in a resource optimised organisation you become the focus of attention as you are critical to getting things done. Some people like that but not everyone does. And what happens in resource optimised organisations if one of the bottlenecks decides to leave?

In flow optimised organisations people tend to avoid being bottlenecks. Instead of being a doer people in these organisations are enablers. It might seem like a subtle difference but it is a fundamental in organisations that are routinely delivering new features to their customers as oppose to continuously putting out fires.



The impact of risk

The impact of risk

Oh no, a post about risk. Yes, I know this post might seem boring from the title, but bear with me. Here is a picture of cat to keep you going.

Right are you refreshed and invigorated, ready for a roller coaster ride of risk. Lets get started….

The normal approach to managing risk it is identify it, classify it and then provide some form of mitigation to stop it turning into an issue. Architecture is often defined as managing technical risk. When there are a lot of risks and/or their impact is high there is tendency to do work to mitigate them early. This why you might see lots of upfront design work or project planning. It is an attempt to make the uncertain, certain. It is an attempt to avoid the risk occurring because the cost of it’s impact is too high to bear.

Some examples of risk are

  1. Unreliable architecture meaning a server failure causes an outage that results in loss of revenue
  2. Changing requirements late in the day causes cost overruns or implement delays

OK, you have done well getting this far. Here is another picture of a cat to keep your energy up.


Still here, great!

If you could arrange things so that the impact of the risk was next to nothing, would you approach risk management in the same way?

If the impact of the risk is nothing you change from a mindset of reducing risk to accepting it. Bad things will happen but you have systems and tools in place that mean you are not affected. But how might you do this.

  • Working in small batches means that changes are smaller and the impact of that change not realising it’s intended value is low.
  • Reducing the lead time between you having an idea and testing it with real customers means you can regularly deliver. You can get feedback from your customers quickly and change course as necessary. There is less chance  of investing time and effort building something nobody wants.
  • Building a reliable and repeatable release pipeline means that the transaction cost for getting the next version of your software in front of customers is lower. Automating this also eliminated the chance of human error.
  • Regularly introducing failure into your Live environment and ensuring that your systems and processes can cope means that when something fails for real it is routine and customers don’t even notice.

Any of this sound familiar?

I have kept this short and to the point. Here is a picture of some beer as a reward. Hopefully there be some real beer nearby.


Quality shouldn’t be testing

Quality shouldn’t be testing

The comic above makes a good point. It is common to expect code to include executable tests that demostrate that it works as expected. Even if you deliver on time, have team full of experienced engineers and otherwise describe yourself as putting quality first face with a code base without test I’ll be thinking

  • You delivered on time but there are no tests – what other corner have been cut?
  • You have experienced engineers that don’t write test – your definition of experienced is different to mine
  • You say you put quality first but you don’t measure it – How do you know you are delivering a quality product

From my perspective reputation and credibility is eroded if I can’t see your quality assurance process in the code.  Having worked on solutions, some that had automated tests and some that didn’t, I have first hand experience of the compromises that are made when some form of automated testing in not there.


There is a good way to test and a bad way to test. Often, you see tests that simply test that the code does what the code does. What use is that? Instead the tests should represent the requirements and therefore assert that the code meets the needs of the business. So while it can be painful to discipline yourself to write test firsts it often results in a solution that better fits the requirements.  It takes time and effort to get there.

Developers and testers have different skills, they think differently.


The roles should complement each other. Testers can show developers how to think critically about their solutions whereas developers can help testers with the coding skills that are increasingly required to build a reliable and repeatable test suites.

Writing code, testing it, finding bugs and fixing them up is a natural cycle of software development. It is said that people learn more from mistakes so perhaps creating, understanding then fixing bugs makes a software team better.


Rather than focusing on stamping out bugs the focus should be on implementing a series of practices that increase the quality of the team output, which would include more than automated testing. The team needs to understand how to write good code, continuously improve it through refactoring and find ways to continuous measure the quality of their output. That is not only in terms of test coverage, but measuring other metrics such as the cycle time to deliver a story to the definition of done and code analytics like cyclometric complexity and method or function size. Thinking about it, it is not about testing code, instead we should be focusing on measuring quality metrics.

The continuous pursuit of learning

The continuous pursuit of learning

I often think the biggest challenge of working in IT is learning. Not only is the technology that we use relatively complex, it is evolving rapidly. The tools and languages you are using now are changing at an ever-increasing rate. You can no longer expect that what you are working on now will be current in 12 months’ time.

On the one hand, you could be working on something long term. Maybe working on a product, adding features over months and years. The fundamental technology stack of the solution is less likely to change so you’ll be using the same languages and tools each day. If you keep an eye on what is happening in the industry, you might see new things. Often, they are things you will not be able to use. Over time you might become more distant and start thinking you’ll never use the “cool” stuff.

How do you get to play with the good stuff if you have little opportunity to use it in your day job?

On the other hand, you might regularly move from job to job, whether that be as a freelancer or working for an IT consultancy. Here the challenge is not the lack of exposure to different things it is quite the opposite. There are so many things you are expected to know, how can you keep up to date, let alone be an expert in so many things?

How do you know enough about something to be credible in a new job?

How hard is it really? Let say you’re a .NET dev. You need to know your way around the .NET framework namespaces covered in this diagram.

NET_35_Namespaces_Poster_JAN08 (1)-page-001.jpg

There is quite a bit there but with a training course, some hands-on experience and a bit of background reading you can become quite effective.

Suppose now your application is running on Microsoft Azure and you are asked to evaluate if you are using the “right” Azure services and that your organisation is getting value for money.

Azure is this big, with each service have lots of hidden details and some being as big as the entire .NET framework.


And the questions keep coming

  • Which is better Amazon AWS or Microsoft Azure?
  • Can we use React or AngularJS for this new front end feature?
  • We should be writing Microservices, can we use containers here?

How are you supposed to provide credible responses to these questions? You are being asked because you are considered a “technical” expert, but if for don’t have a point of view can you remain an expert?

At this point I’m not going to wave a magic wand or pull a silver bullet out of my pocket that makes this all easy. This problem is not going away. Instead it needs to be addressed head long.

The first stage is acceptance. You need to realise that it will take effort to stay current. If you are employed and not freelance, your employer will be expecting you to stay current too. As a freelancer you have to keep up to date to continue to pay the bills. Employer may offer some sort of training budget but frankly this is never enough, often hard to justify, in terms of time away from clients and projects, and in most cases, you are not given a free choice on how this time is spent.

Once you have the epiphany that this is in your hands and no-one will do it for you, the next step is to broaden your horizons. Seeing what other people are doing can open your eyes. Sometimes you can see what other projects are happening in your organisation but this is just the start. We are lucky that we have the Internet at our disposal where you can find out about anything. However, curated sources may be better to avoid information overload. Services like Flipboard and Medium offer to collate articles on certain subjects. I personally prefer podcasts. I can listen to them in dead time such as during commuting, they tend to cover a broad range of subjects and they often have further reading lists.

Getting this far, it may be dawning on you that this will involve time. That is true: you’ll will have to make an investment in time to make this happen. This is true in any profession. Time always needs to be invested for self-improvement. IT is no different.

How much time should you invest? Think about all the commitments you have, both professionally and personally. If you are already working long hours and have a large family, then you are not going to be able to invest many hours each week. Perhaps, you’ll only be able to use some of your commuting time and maybe one or two lunch breaks a week. Other people may find much bigger chunks of time. The important thing is to be realistic. There is no point over committing. You’ll find it too much of a challenge and be very likely to stop altogether. The aim is to make it routine and easy.

Once you have carved out some time you should think about what you are going to achieve and how you are going to do it. Are you going to use that time for reading articles or listening to podcasts? Do you want to do online courses such as those provided by Pluralsight? Maybe you’ll be setting aside time so you can work on side projects or even contribute into some open source projects. What you end up doing will be personal and will relate to your overall goals. Personally, I try to do a few of these. Sometimes, like on my commute, Podcasts are my only options but other times it easy to open of the laptop to either read something or open up an IDE.

Happy learning,