Personal Productivity on Agile Teams

Personal productivity systems like Getting Things Done or the Pomodoro technique are quite popular among agilists, and I’m not surprised. There are many parallels with agile practices, most of these techniques use practices resembling iterations, backlogs and frequent retrospectives to become more productive. I’ve been experimenting with a couple of these but once I started using these at work I found that these don’t automatically work in a team setting.

Personal productivity isn’t team productivity.
In an ideal world a team consisting of very productive individuals is automatically a productive team. Unfortunately the real world is far from ideal. Because teams are very interdependent optimizing the work of a single team-member will not automatically optimize the whole. In many cases local optimization like this might even be cause the team to become less productive. Lets look at what’s causing this and how we can avoid it.

One of the ways to become more productive as an individual is to reduce interruptions. Making someone doing complex work switch between tasks a lot by interrupting them will make them far less productive, not only because the interruptions take time, the act of switching between complex tasks takes a lot of time too. A large part of personal productivity systems is avoiding interruptions. Unfortunately avoiding interruptions in teams often means avoiding communication. Communication is critical in a team.

Another way to get a big productivity boost is working with to-do lists. By listing and prioritizing tasks you can streamline your work. But in a team setting personal to-do lists can be problematic. People working from their own to-do lists instead of the team backlog can make coordinating work hard, it creates invisible work in progress and when people start planning their work too far in advance to-do lists can introduce rigidity into the team.

Aligning personal- and team-productivity
So should you only use GTD at home to organize your gardening duties? Of course not! There are a couple of things you can do to align your personal productivity with the productivity of the whole team.

Keep communicating.
The temptation to keep your head down and just steam through your own tasks is often big. For example the pomodoro technique gets is name from the kitchen timer used to time 25 minute periods where you need to do focused work without any interruptions. Pair programming can help to still get these periods of uninterrupted work without losing touch with your co-workers. You shouldn’t count questions from coworkers as interruptions. They’re part of your work. A way to deal with these is to add them as priority items to your lists.

Keep your todo lists short and up to date.
To-do lists are great for streamlining work. If you make your lists too long you’re planning too far ahead. A list that contains more than a day of work probably contains work items that should be on the team backlog. Claiming too much work for yourself will prevent your team-members from working on high priority items.

Stay transparent, give coworkers access to your lists.
Try to keep your lists in a public place. Write them down and put them on a corner of your desk. Communicate the items on your list during the stand-up. It’s important for the team to know what item is on who’s list when priorities change. Work items may even become obsolete.

When done right personal productivity systems can become an asset in a team. I’ve been experimenting with these for some time. I noticed that reporting on work done and work planned during the stand up became easier because I was tracking my work better. Tracking time (or pomodoro) spent on a single work item also made it easier to spot potential problems earlier.

The Secret To Delivering On Time

The Secret To Delivering On Time

Hi, I’m Kelly Waters, author of the popular blog, All About Agile. I’ve agreed with Artem to guest over here at ASD and be a regular contributor – this is my first post…

I’ve been doing agile development for quite a few years now, and seen many benefits. But one of the most remarkable things of all, is how so many teams can quickly get good at predicting what they can deliver, and deliver on time, even if they were hopeless at estimating before!

For decades, delivering on time has been the holy grail of software development. So this, for me, is one of the most compelling reasons to do agile development. Here is the secret to consistently delivering on time:

  • Estimate features, rather than tasks.

  • Keep your estimates high-level intuitive guesses (don’t analyse the details).
  • Estimate in points to indicate the relative size of each feature.
  • Consider estimating using a number sequence like Fibonacci. Fibonacci numbers get less precise as they get bigger, which builds a natural distribution curve into your estimates.
  • Estimate as a team. Consider playing Planning Poker to facilitate this.
  • At the end of your Sprint (or iteration), score the points for all features you managed to deliver. Only score points for features 100% complete, tested and potentially shippable. This is your Velocity. Count zero for incomplete features.
  • Track your Velocity over time on a graph. You can also track your Reliability, i.e. the number of points delivered as a percentage of the number of points committed to at the start of the Sprint.
  • At the start of each Sprint, look back at your Velocity for recent Sprints to decide how much to commit to for the coming Sprint.
  • Don’t try to reconcile points with hours.
  • Commit as a team.

Like most great things in life, it’s actually very simple. That’s really the beauty of it. It seems a bit abstract, so many people might be retiscent to give it a try. I would urge you to try it.

You’ll need to give it several Sprints before you pass judgement on it. You will find your Velocity bounces all over the place for the first 3-4 Sprints. But then it will settle down, as your team discovers its norm.

Trust me, it works. I have seen it work in many different teams, time and time again. It’s a statistical approach to estimating. And statistically, if you estimate with relativity, everything is average in the end.


The 7 Software Development Wastes – Lean series Part 5 – Motion


Previous posts on software development wastes can be found here: In-Process Inventory/Partially done work , Over Production/Extra Features , Extra Processing and Transportation

I must apologize to you all for the lag in this series. But being August, I was away on vacation. Interestingly, getting back is hard. You have to get back into the swing of things again to get up to maximum productivity. There’s quite a bit of re-acquainting and relearning so there’s waste for sure. However, I do feel I have more energy now since I am back so perhaps the waste is negated over time.

Motion – Task Switching

Waste #5 in manufacturing is defined as Motion. And motion can be compared to “task switching” in Software Development – as defined by the thought leaders applying Lean thinking to software development.

Task switching can be a big time waster. Studies have shown that if you’re working on anything beyond two seperate and distinct tasks, your efficiency goes down drastically the more tasks you take on. The reason is quite obvious; working on software development tasks takes a lot of thought processing and task switching requires that your mind switch contexts all the time. Each time that you switch contexts, there’s relearning and re-acquainting that needs to take place.

Additionally, if you are working on multiple tasks simultaneously, it’s going to take you longer to complete the first and each successive tasks. If you storm the first task and get that out, you are delivering value to the customer much sooner.

It’s important to be mindful of this. I have found in many organizations, especially software companies where there is a real casual atmosphere, it’s easy to always interrupt developers. Interruptions are prevalent with requests. All this interruption only serves to add to the Motion bucket of waste. This is where the importance of a Product Owner, ScrumMaster and Backlog come in. These roles and any artifact are there to buffer the development teams from the noise and chaos outside of the current sprint activities.

If you’re a good tough ScrumMaster, you’ll see to it that priorities are all driven through the backlog and the Scrum process and that your teams are left to focus on distinct activities for maximum throughput and reduced overall cycle time in development.

Next week I will cover the 5th waste in the series – Waiting.

Fixed price part 2, Fix it with agile!

In my previous fixed price article I looked at why fixed price is not only bad for suppliers but also for clients. I also argued that contrary to popular belief using big design up front methodologies will not solve these problems. Fixed price is difficult no matter what methodology you use. In this article I want to look at why fixed price is still popular with many clients. Then we’ll look at what we need to do to be a bit more successful at fixed price and how agile methodologies can help us do this.

To look at why fixed price is popular with clients I’ll start with a comment I got on my previous article. Sergey Pyatigorsckiy commented “As to my mind, pure fixed priced project can be defined as a project nobody cares about. At best it’s spending money, at worst – wasting money. That is why real huge governmental projects are fixed priced: Nobody really cares.”

I tend to agree to some extent. Clients often don’t care about the project, they often just want the software and be done with it and for them the easiest way to get this is fixed price. So fixed price projects and clients that don’t care seem to go together. In most cases clients do care about the outcome of the project. Clients have a problem they want to see solved. Or, more cynical, in larger organizations, clients want a big successful project to show their manager. Often clients don’t realize that in order to improve chances of a successful outcome they should care about the project. Most clients have experience with processes like buying a new car, they specify what they want, recieve a time and cost estimate, wait a few days and get their car. Why should software be any different?

Clients often don’t trust the supplier enough to move away from fixed price to other contract types. Fixed price often seems a lot safer to a client because it allows them to push risk to the supplier. In practice this just isn’t the case. The fact that a client can sue a supplier for breach of contract will not change the fact that the client doesn’t get any software. Allowing the client to point fingers won’t solve their business problem.

What do we need to improve our chances in fixed price?
Unfortunately we can’t get rid of fixed price. But there are several things we can do to make the best of this situation.

  • We need to make the best estimates possible within the limited time we have available before the start of the project with the limited requirements we have at that time.
  • In order to reduce risk we need to keep a close eye on progress in order to detect problems as soon as possible.
  • We need to build trust with the customer. Without trust there’s no way we can break the fixed price habit in the future.
  • We need to create a situation where we can break out the fixed price contract whenever requirements change without having to throw away lots of work in progress.

Agile fixed price
Fixed price projects will cause an agile team to make several compromises, up front estimation is not something we’re used to doing, committing to those estimates even less so. Limiting scope is also not a very agile thing to do. But even within these constraints I do think agile has a lot to bring to the table in fixed price projects. Lets look at how agile practices will help us achieve the four goals I stated earlier.

Agile estimation
The hard part of fixed price is up-front estimation. You need time and a detailed set of requirements to create really accurate estimates. We don’t have either so we have to make the best estimates possible with the least amount of resources. One of the best methods to do this is agile estimation. Even with the rough requirements you have before the start of a project it should be possible to create a set of user stories and attach rough relative estimates to them using something like story points. These can be transformed into a set of estimations using past velocity of the team. Keep in mind that it’s probably a good idea to pad these estimates with a risk-factor. In my experience abusing agile estimation techniques like this will not bring you the most reliable estimates, estimates are never as unreliable as at the start of a project, but considering the circumstances it’s the best option. Techniques that claim to be more reliable like function points analysis simply take too much time.

Agile risk management
Finishing stories every iteration is the best way to measure progress. A story is never 80% done. It’s 0% done or it’s 100% done. Everything in between is uncertain and will not allow you to measure progress. Agile forces you to finish stories every iteration giving you a clear picture of progress so you’ll know early on when a project is behind schedule. This kind of risk management is very important in fixed price projects where missing a deadline can mean the difference between a happy customer and a lawsuit.

Build trust by showing working software
Actually finishing stories in every iteration also gives you the ability to show working software every time. In fixed price projects this does not seem very important. Clients don’t expect to see software until the very end, and on the many non-agile fixed price projects I’ve been on that was exactly what we were aiming for. But when you want to build a relation based on trust with a client this is not the way to go. The best way to show a client that they can trust you is to be able to show them what you’re doing. Show them working software.

Break out of the contract
Showing your customer working software has an interesting side effect. They’ll want to change requirements. But because of the fixed scope this won’t be possible without breaking out of the contract or by doing work outside of the contract, giving the customer features for free.
There are two things that make breaking out of a fixed price contract hard. First of all the supplier will want to bill the customer for the work that has already been done. But if you have lots of work in progress defining progress is hard, fortunately in an agile project progress is much easier to measure as we’ve already seen. Also clients will probably not want to pay for software when many important features are missing. Prioritizing work according to client business-value will make sure the most important features will be implemented first. It will be much easier to switch from fixed price to a more flexible contract type halfway through a project.

In situations where you can’t get around working with fixed price contracts people often give up on doing things agile altogether. To me this is a bit like someone who is trying to stop smoking who, in a moment of weakness, smokes a cigarette, gives up completely and starts smoking one pack a day again. The fact that fixed price makes you abandon a couple of agile practices does not mean you should give up on agile altogether. I hope to have shown some compelling arguments for doing fixed price agile in this article.