Adopting Agile in 3 “Easy” Steps

All good plans come in 3 phases:

Profit

Although I won’t be collecting any underpants, I’ll be following this basic template (with a couple of tweaks here and there) during an Agile adoption initiative I’m currently working on.

In the South Park episode (from which I have taken the picture above) the boys discover a bunch of underpant-stealing gnomes, who are collecting underpants as part of a grand plan to make profit. The gnomes claim to be business experts but none of them appears to know what phase 2 of the plan is. All they know is that their business model is based on collecting underpants, and so that’s what they’ll do.

Unfortunately, I have been witness to a couple of attempts at adopting agile which weren’t very dissimilar to the underpants gnomes’ business plan. Namely, a business starts “Adopting Agile”, usually driven by the development team, where they start doing stand-ups and using a sprint board (this is phase 1) and somehow they are surprised when this doesn’t suddenly start producing profit. Clearly, “becoming Agile” isn’t as simple as that.

Phase 1 – Collect business reasons (not underpants)

So you’re going Agile. Presumably you’ve determined that this is what you want, and what your customers need. If you haven’t done this yet then stop right there and ask yourself “Do I Need Go Agile?”. The answer might be “no”, but does needing to go Agile have to be the only reason? Maybe you just want to go agile to see what the fuss is all about, or to make your business more attractive to potential new employees.

brush

So lets assume we’re going agile, and you have valid business reasons to do so. My first suggestion would be to make those business reasons highly visible. You have to outline the existing issues and how Agile can help to fix them. Mitchell and Webb once did a sketch about a toothbrush company who had to try to think of some gimmick to add to their toothbrushes in order to keep increasing their sales. They came up with the idea of “dirty tongue”. This is where microscopic “tonguanoids” build up, and basically result in social exclusion and a lack of sex. Their solution: to put bristles on the other side of the toothbrush so that people can brush their tongues while they brush their teeth. People will buy these toothbrushes despite the fact that “brushing your tongue makes you retch, everybody knows that”. The point I’m making, very badly, is that it’s a lot easier to sell things if people think that what they’re buying into will fix some very real, tangible issue.

The same goes with Agile. To get the buy-in you need to make your agile adoption a success, you’ll need to identify how “going Agile” is going to make life better for everyone concerned.

If the problem you’ve got is that you never ship software on time, or you constantly fail to deliver what the customer wants, then it’s fairly easy to “sell” agile as the solution. The concept of sprints are a doddle for everyone to understand, and they’ll love the idea that the customer will have regular interactions with the development team, and get to see regular progress in the demos. “Of course!” they’ll say “It’s so obvious, why didn’t I think of that before”. The business should easily be able to see how short, sharp sprints with an emphasis on “working software” will make it easier to deliver what the customer wants, and manage their expectations of when it’ll be ready.

But what if those aren’t the problems you need to solve?

What if your problem is quality? How do you convince the business that Agile will result in a higher quality product? It’s not quite so easy. Agile itself won’t deliver better quality, but the good practices you’ll have to implement in order to successfully be agile will help to improve your quality. I was thinking about this the other day because it’s exactly the problem I was faced with.

Agile isn’t going to make it easier to reliably test our software. But to be agile, we need to be able to build and deploy our project rapidly so that we can test it right there and then, not tomorrow, not next week, but right now, so that the testers and devs can work in tandem, building features and signing them off and moving on to the next one. We have to facilitate this in order to be agile, so as a byproduct of going agile we might have to invest in creating a new build and deployment system. And it has to be quick so it’ll have to be automated.

So we have an automated build and deployment system, but to be able to reliably test our features we’ll have to make sure the environments are reliable. We can throw people at this problem and dedicate a team to making sure our environments are clean and regularly audited, or we can automate all that as well! chef Fortunately there are numerous tools and good practices we can follow to do this, just take a look at Chef, Puppet, Vagrant, and VMWare as examples of tools for automating deployments of virtual machines, and the concepts of “infrastructure as code” for good practices. (of course, if your hardware isn’t already virtualised the first thing to do is see whether it can be, and if it really, honestly can’t, then look at tools like Norton Ghost and Powershell for ways of automating as much as you can).

“Agile” and “Improved Quality” might not be the most obvious bed partners, but the journey to becoming agile almost forces you to take steps which will naturally go towards improving your quality.

Hopefully you’ll have enough “sales material” to put forward a great case for agile – you can deliver exactly what the customer wants, to a higher quality, and you can manage their expectations in a way you could never do before. And that’s just scratching the surface of what Agile can do for a business, but for the purposes of keeping this post to a reasonable length, I’ll leave it at those 3 things!

Phase 2 – Pick the most appropriate project, and start doing Scrum

The sales pitch is over and now it’s time to start doing stuff. Make your life a lot easier by picking a project that has as many of the following features as possible:

  • Smart developers and testers
  • Isn’t suffering from a tonne of technical debt
  • Has users who are happy to get involved in early & regular feedback
  • Is small, new or yet to begin

If you’re taking on an existing project, a good idea at this point is to benchmark your existing processes. Consider trying to measure the following:

  • How long does it take to get a single change from request through to production deployment?
  • How much time and money does it cost to fix an issue on production?
  • How many bugs do you typically find on your production code every month?
  • How often do you deliver features that don’t satisfy the customer?
  • How often do you deliver features after the deadline?

Measuring some of the things above is clearly non-trivial, but if you can find these stats somewhere, they’ll be very useful benchmarks for you in the future. When you can demonstrate that all of these metrics are improved in your new Agile process, god-like status will soon follow.

You - after delivering "agile" to the business

Guess who just delivered a release on time…
Ohhhh Yeeeeaaaaahhhh!

I recommend doing Scrum because it’s simple and has the most support in terms of people with experience, material (books, courses etc), and tools. It’s a good “framework” to get you started, and once you’ve had success, you can evolve into other methods, or incorporate them into Scrum (such as BDD, TDD etc).

Succeeding With Agile

Here’s one of many great books to get you started on your agile journey

At about this point you’ll need to do some brainwashing training. The concept of doing analysis, design, development and testing all at the same time is going to sound absolutely bonkers to some people. Try your best to explain it to them, but don’t waste too much time on this – just crack on and make a start!

Most people will enjoy the experience of working in this “new” way, and the first few sprints will probably benefit from the fact that everyone is performing better simply because they feel more invigorated. Use this opportunity to promote scrum across the organisation.

In this phase, always maintain a focus on “the business” and not just on the technical team. It’s important that the business feels part of this new process or they’ll just see it as some crazy dev thing which doesn’t really affect them, and they won’t try to understand it. Business people might refer to this as “Promoting Synergy”, which I’ve just shoe-horned into this post so that I can add a picture from Lonely Island’s “Like A Boss” video. However, I do like to make a point of always highlighting the extra business value we’re delivering, and make sure the Product Managers (soon to be “Product Owners”) are involved all the way. They represent the traditional link between the customers and what we’re delivering, and so it’s essential that they understand the benefits of agile.

Promote Synergy!

Promote Synergy!

I was recently asked about the impact of “going agile” on a project’s release schedule, and when we would be able to deliver the features we’ve promised to the customers. It’s difficult to explain that we no longer know when we’ll deliver stuff, but at some point, people will have to realise that this is the wrong question. I prefer the idea of a rolling roadmap, which is continually reviewed and updated (as often as you can afford to do it, really). Rolling Roadmaps give the business, as well as the customers a good idea of our intentions, but it is very different to fixed dates on a release schedule, or a traditional yearly roadmap. Of course, everyone needs to understand that the main driver for our deliverables will be the customers, and what the customer wants will usually change over a shorter period than you expect. So for your new “Agile” project, try to work towards implementing a rolling roadmap culture, and move away from long-term fixed delivery dates (if you can).

One final note on Phase 2: Make it fun, and make it different.

Phase 3 – Improve

Agile promotes “fast feedback loops” all over the place: in development we get fast feedback on our code through Continuous Integration, with BDD we get fast feedback to the Product Owners/BAs and of course with our more frequent releases we get faster feedback from the customers. And so it is with our Agile processes as a whole. With short sprints and the clever use of retrospectives we can continually tinker with our fine tuning to see if we can improve our quality and velocity. Look at areas you can try to improve, change something and then see if your change has had a positive impact at the end of the sprint. This is basically the concept behind Deming’s Shewhart Cycle:

demingcycleDeming actually preferred “Plan, Do, Study, Act”, whereas I myself prefer “Plan, Do, Measure, Act”. The reason I prefer this is because it implies the use of quantifiable metrics to base our actions on, rather than some other non-quantifiable observations. Anyways, the point is that after agile is applied, you should keep looking at ways to continuously improve. This is key to keeping everyone feeling fresh and invigorated, helps us to learn from our mistakes, and encourages innovation.

So there you go, Agile delivered in 3 well easy steps. It shouldn’t take you much longer than an afternoon. Ok, it might take a bit longer but if you’re looking for a 30,000 foot overview of a simple 3-phase approach, then you could do a lot worse than apply the principles of “Sell the Agile Idea, Pick the Best Project, and Keep Improving”.

A Sprint Retrospective

The IT Ops team’s 4th sprint came to its conclusion recently… and we delivered all of our commitments! Huzzah! This post is basically a summary of how we analysed the sprint and what we got up to in the retrospective.
The main objectives of this sprint were:

  • Rolling out a new password policy
  • Rolling out a new file server
  • Rebuilding the dev db

In addition to these tasks there were a bunch of other smaller tasks, far too dull for me to list here.

This was the first time we’d completed all of our committed points, and it gave us enough information to work out how many points we can realistically attempt to deliver in each sprint.
Once again the team completed over 100 points in the sprint, and once again we committed to doing 50 project points (the other 50-or-so being unplanned interruptions).

Sprint 4 in Numbers:

sprintNumbers
We completed 50 committed points
We completed 64 unplanned points
Total: 114 points
That’s very much in-line with the total we’ve come to expect.
We averaged 3.8 points per person per day for the duration of the sprint.

This means that we’re able to do roughly 2 points per person per day on committed project work.
In an ideal scenario, with no interruptions, no meetings and nothing to distract us from our tasks, we estimate that we could do about 6 points per person per day.
Therefore, statistically speaking, were actually 33% productive on our project work.
Of the remaining 67% we spent another 33% on interruptions.

So what happens to the other 33%??
The remaining effort and time is taken up with meetings, discussions, unrecorded interruptions, emails, phone calls and unproductive time. This figure (33%) is in the region of what I expected before we embarked upon this process some 8 weeks ago.

How to use this information
Well we know that we can complete approximately 50 project points per sprint. So we can now break down upcoming projects into tasks, and give realistic predictions on when they can be delivered.
The only caveat is that we do not make guarantees on project priority. We will always commit to working on delivering the highest business value projects first, and as a result will take guidance from the business on priorities. If a project’s priority is lowered then it will likely drop down the pecking order of our tasks, and its delivery date will slip.
In short, providing project priorities don’t chance for the duration of the project, we can now give far more realistic predictions on delivery dates.

Retrospective
To get the creative juices flowing, we started the retrospective with everyone drawing a picture of Sprint 4. There were no rules to this task, we could draw anything we wanted that represented sprint 4 for us as individuals.

Here’s the resulting “artwork”, if you can call it that:

Farud

Farid, who for some reason I expected to be something of an artist, drew a picture of the Jules Rimet trophy. This was partly to represent the fact that we completed the Password and File server projects, and partly to reflect that we hit our target.

nick

Nick’s “effort” was of a question mark going into a grinder with a gold bar coming out of the other end. This reflects the fact that we’re not 100% sure of what’s happening up front at the beginning of our sprint, and we base our estimations on “best-guesses”, but by the end of the sprint we were producing the goods. It also raises a very relevant point about how we know we are addressing the right projects/tasks in the right order. More on that later.

boss

Jon (in his unique avant-garde style) drew a person wearing a Boss hat. The person represents the team, and the boss hat is representative of the fact that we all completed our tasks on time and delivered what we committed to. Or at least that was his explanation, although I suspect it has more to do with the Lonely Island “Like a Boss” video, which is something of a theme tune in the IT Ops team. Seriously.

Leo drew the burndown, the original of which you can find at the bottom of this post.

Next up, we all chose 1 thing from the sprint that we wanted to discuss in more detail. Here’s what we ended up speaking about:
1. Using small post-it notes to record interruptions on the board didn’t work. They’re too small and not sticky enough. This was a major issue for Leo and Jon, who clearly have something against post-it notes.
2. We need to plan more carefully. Our planning sessions are rushed, and as a result we don’t think our tasks through as well as we should. The main failure here is that we don’t think about the impact other people can have on our tasks.

Following this, we discussed what we think went well, and what we think went badly in the sprint:

WENT WELL

  • Better prioritisation of interruptions allowed us to concentrate on the
  • committed tasks
  • Implementing the password policy
  • Realistic goal setting

WENT BADLY

  • IT request backlog grew bigger

What did we learn from Sprint 4:

  • 50 Project points is our magic number
  • Don’t over-commit
  • Do more forward planning
  • Our prioritizing is getting better

Finally we discussed the stats and figures mentioned earlier, and then we looked back at the burndown to see if there was any useful information we could take from it.
Leo suggested that the burndown be pre-populated with the mean line, so that we can see our daily deviation from that line. I have filed this suggestion in a folder named “Leo’s Good Ideas”, and we’ll adopt it in future sprints once I’ve worked out how to use Excel properly (or found a pen and a ruler).

The Burndown

s4burn

 

Improvements
As mentioned earlier, we’ve worked out what our average velocity is – and we can now confidently say that 50 project points per sprint is a realistic target for the team. Now that we’ve established this, we need to turn our attention to ensuring that we’re delivering the highest business value we possibly can. At present we feel we are slightly deficient in engaging with the business to define our priorities, so in the future we’ll be looking at having a much closer engagement with the rest of the business to help us with our prioritising and acceptance criteria. We want to be delivering the most important projects first, and we want to have a clear picture of what a successful delivery of those projects looks like.
Over the next couple of sprints we’ll be shifting our focus in this direction, and hopefully people will start to see the results over the next few weeks.

P.S. Jon is available for hire as a short order artist, ideal for weddings and birthday parties. Disappointment guaranteed.

ITOps Sprint 1 Review

Our first ever ITOps sprint completed on Friday 7th December amid much fanfare and celebration (ok, that’s a bit of an exaggeration). The team completed a whopping grand total of 103 points. Among the highlights were:

  • An Anti-Virus upgrade
  • A new dev server
  • 10+ IT Requests from the backlog

Yes, those were the highlights. But don’t scoff – that new dev server was AMAZEBALLS.

Retrospective

The format of our first retrospective was to spend 5 minutes writing down (on cards) what we felt went well in our first sprint, and what went not-so-well. We then discussed these and made a list of “lessons learned”. It turned out a bit like this:

 

What went well What went not-so-well
2 week “focus” made a huge difference: we could concentrate on a smaller number of tasks, rather than work from a massive backlog with no end in sight. We under-estimated task sizes. Massively, in some cases.
Having the tasks on the board helped us see what everyone was doing 7 point task sizes were waaaaaaaaaaay too large
When working on a task, we no longer felt that we perhaps ought to be working on something else We did fewer IT requests than we would otherwise have done
Time-boxing certain IT requests was a good idea. We didn’t take holidays into account when we did our sprint planning! Duuuuuh.
Improved visibility: the rest of the world could see that we didn’t actually spend 2 weeks updating Facebook We failed to get much done on the new File Server
We got through more project work than we expected  
Easy to visualise the sheer amount of unplanned interruptions  
We prioritised our interruptions quite well  
   

 

Lessons Learned

  • 2 week sprints work well for the team’s focus
  • We should time-box research into upcoming projects
  • Any task which is above 5 points should be broken down into smaller tasks
  • We need to improve our estimation
  • We need to focus on completing the projects if we’ve committed to them
  • We need to take holidays into account!
  • Relative to interruptions, we can do more project work than we originally expected

 

Facts and Figures

  • We completed 103 points
  • 53 points of which were project points
  • 50 points were interruptions
  • 15 points were in progress at the end of the sprint
  • 9 points (of committed work) remained incomplete
  • 4.5 points were blocked

 

The Burndown

Friday to Tuesday were the least productive days in terms of project work. This was mainly due to hangovers holidays which “we” (namely me) hadn’t taken into account, with 2/3rds of the team being off at one point.

endbd

 

Conclusion

Sprint 1 was an enjoyable success within the team. The increased visibility of interruptions as well as a clearer focus on our tasks was refreshing.

We failed to deliver one project (the new file server), which is disappointing, and we will need to focus on progressing and completing our project tasks in future.

We’ll continue with Scrum for the time being.

The other thing we noticed was that interruptions take up more time than just the duration of the interruption. There’s an additional amount of time on top of each interruption which needs to be taken into account. When someone is being productive working on a project task which, let’s say will take 3 hours, and they get interrupted to do an IT request which may only take 1 hour, the total time for completing the project task PLUS the interruption isn’t going to be 4 hours. It’s more likely to be 5, and this is because it takes some time to get back to being fully productive.

We made a conscious effort not to measure tasks by elapsed time, and instead we tried to use “Level of Effort”. I thought that mapping points to hours would be a bit too convenient for observers to draw incorrect conclusions by just adding up the number of hours and comparing it against the number of points we achieved! By using Level of Effort points and taking into account the number of interruptions (at the end of the sprint the points showed us that we’d done an almost equal number of interruption points as we had done project points), it was clear that in future we need to buffer our estimations somewhat. 🙂

 

 

Agile ITOps: Day 4

It’s day 4 of our first agile ITOps sprint and so far it’s pretty much going to script. Our estimation of how much work we would be able to get through is looking roughly in the right ballpark (for more details on how we did the estimating, and other stuff see Agile ITOps: Day 1)

Looking at our sprint board a couple of things are fairly apparent. Firstly, that we were right about the number and frequency of interruptions, and secondly that we’re going to need a bigger board:

We’re going to need a bigger board

One of the things we aimed to achieve with the sprint board was to raise the visibility of the constant “interruptions” we have to work on. To do this we decided to note down every “interruption” on a red/pink card. As you can see in the picture above, we’ve worked more on interruptions than we have on our committed tasks. This was exactly what we expected to see.

Another thing we expected to see was a correlation between the number of interruptions we had, and the amount of project work we achieved. It was expected that on days where there were a high degree of interruptions, the number of project points completed would drop off. That hasn’t quite materialised yet, as you’ll see in the burndown below:

day4

2 Plus 2 Doesn’t Equal 4?

Another thing that we’re expecting to see is that the maths just don’t add up. What I’m saying is that I don’t expect the team to be 100% productive when you add up the completed tasks we committed to deliver, plus all the points we did on interruptions. The reality is that people can’t automatically switch from one task to another and not lose any productivity. At the end of this sprint I’m hoping to be able to get a rough estimate of this “lost time”. In due course I will try to see if there’s any relationship between the amount of “lost time” and the types of tasks/interruptions we work on, so that we can effectively “cost” some of our regular tasks.

Agile ITOps: Day 1

Today we started day 1 of our first ever ITOps sprint. This all came about because we needed a way of working out our productivity on “project tasks”, as well as learning how to triage our interruptions a bit better. None of the IT Ops team had tried any form of agile before, so there’s a mix of excitement and apprehension at the moment! I’ve opted for the old skool cards and sprint board (we’re using scrum by the way – more on this in a bit) rather than using an IT based system like Jira. This is mainly because everyone’s co-located, but also because I think it’s a good way to advertise what we’re doing within the office, and it’s an easy way to introduce a team to scrum.

The team already had a backlog of projects, so it was quite an easy job to break these down into cards. First of all we prioritised the projects and then sized up a bunch of tasks. We’re guessing, for this first sprint, that we’ll probably be around 40% to 50% productive on these project tasks, while the rest of our time will be taken up by interruptions (IT requests, responding to inquiries, dealing with unexpected issues etc).

Sprint 1 – planned, or “committed” tasks are on green cards, while interruptions go on those lovely pinky-reddish ones.

I’m using a points system which is roughly equivalent to 1 point = 1 hour’s effort. This is a bit more granular than you might expect in a dev sprint, but since we’re dealing with a very high number of smaller tasks, I’ve opted for this slightly more granular scale.

As well as project work, there was also an existing list of IT requests which were in the queue waiting to be done. I wanted to “commit” to getting some of these done, so we planned them in to the sprint. I had originally thought of setting a goal of reducing the IT request queue by 30 tickets, and having that as a card, but I decided against this because I don’t feel it really represents a single task in it’s own right. I might change my mind about this at a later date though! So instead of doing that, we just chose the highest priority IT requests, and then arranged them by logical groupings (for instance, 3 IT requests to rebuild laptops would be grouped together). At the end of our planning session we had committed to achieving approximately 40% productivity.

Managing Interruptions

We expect at least 50% of our time to be taken up by interruptions – this is based on a best-guess estimate, and will be refined from one sprint to the next as we progress on our agile journey. Whenever we get an interruption, let’s say someone comes over and says his laptop is broken, or we get an email saying a printer has mysteriously stopped working, then we scribble down a very brief summary of this issue on a red/pink card and make a quick call on whether it’s a higher priority that our current “in progress” tasks. If it is, then it goes straight into “in progress”, and we might have to move something out of “in progress” if the interruption means we need to park it for a while. Otherwise, the interruption will go in the backlog or in the “to do” list, depending on urgency.

At the end of the sprint we’re expecting to see a whole lot more red cards than green ones in the “Done” column. Indeed, we’re only a couple of hours into the first sprint an already the interruption cards contribute more than a 4:1 ratio in terms of hours actually worked today!

Interruptions already outweigh “committed” tasks by 4:1 in terms of hours worked – looks like my 40% guess was a bit optimistic!

Triage and Priorities

One of the goals of this agile style of working is to get us to think a bit smarter when it comes to prioritising interruptions. It’s been felt in the past that interruptions always get given higher priority over our project work, when perhaps they shouldn’t have been. I suspect that in reality there’s a combination of reasons why the interruptions got done over project work: they’re usually smaller tasks, someone is usually telling you it’s urgent, it’s nice to help people out, and sometimes it’s not very easy to tell someone that you aren’t going to do their request because it’s not high enough priority. By writing the interruptions down on a card, and being able to look at the board and see a list of tasks we have committed to deliver, I’m hoping that we will be able to make better judgement calls on the priority, and also make it easier to show people that their requests are competing with a large number of other tasks which we’ve promised to get done.

Why Scrum?

I don’t actually see this as the perfect solution by any means, and as you might be able to tell already, there’s a slight leaning towards Kanban. I eventually want to go full-kanban, so to speak, but I feel that our scrum based approach provides a much easier introduction to agile concepts. Kanban seems to be much more geared towards an Ops style environment, with it’s continuous additions of tasks to the backlog and its rolling process. I think the pull based system and the focus on “Work In Progress” will provide some good tools for the ITOps team to manage their work flow. For now though, they’re getting down with a bit of scrum to get used to the terms and the ideas, and to understand what the hell the devs are talking about!

Retrospectives, burn-downs and Continuous Improvement

We’ll stick with scrum for a while and at the end of our sprint we’ll demo what project work we actually got through, as well as advertise the amount of IT requests we did, and the number of “interruptions” we successfully handled (although I don’t think I’ll keep calling them “interruptions” :-)). I’m also looking forward to our first retrospective, which we’ll be doing at the end of each sprint as a learning task – we want to see what we did well and what we did badly, as well as take a good look at our original estimations!

I’ll keep track of our burndown, and as the weeks go by I’ll try to give the team as much supporting metrics/information as I can, such as the number of hours since an interruption, the number of project tasks that are stuck in “In Progress” etc. But most important of all, we’re looking at this as a learning experience, an opportunity for us to improve the way we manage projects and a chance for everyone to get better at prioritising and estimating.

I’ll keep the posts coming whenever I get the chance!

Ten Mistakes That Software Team Leads Make

“Ten Mistakes” (as I shall now call it because I’m too lazy to keep typing the whole title), was a talk by Roy Osherove which I went to at Skills Matter. He basically takes us through ten common mistakes he sees team leaders make, and offers some solutions to them. He also looks like Adam Sandler, I kid you not.

Roy Osherove

Roy Osherove

Adam Sandler

Adam Sandler

Here’s Roy delivering a piece to camera…

And here’s Adam, doing some funny acting, or something.

Adam Roy started us off by talking about a number of questions that team leaders might have. These included such things as:

  • How do I convince my team to do X
  • What do I do with the bad apple in my team?
  • What am I supposed to do as a team lead?
  • Why can’t we get away from fighting fires?
  • Will I lose friends?

He said that these were all questions that haunted him for years, and in the rest of the talk he goes on to explain how to answer them. He is also in the process of writing a book called “Notes to a Software Team Leader” which also covers these points.

So, we then moved on to the first of the Ten Mistakes…

#1 Not Recognising Team Maturity

This was a good place to start because much of the talk referred back to the “maturity level” of the team. Roy says that there are 3 levels of maturity when it comes to describing agile teams. These are:

  1. Chaos
  2. Learning
  3. Self-Leading

Chaos

A chaos team is one where people are always too busy. Maybe they’re always firefighting or they’re just being asked to too much in too little time, eithesinking shipr way, the result is the same – chaos. Nobody has any time to get organised and nobody has any time to learn anything new because they’re just too busy for that. This is obviously not a great maturity level to be at if you ask me, because eventually people will suffer burn out or get frustrated at the lack of opportunities to learn, and eventually the good guys will leave. However, Roy says that the chaos level is actually exceedingly common, and I can easily believe him. The trick is to act in an appropriate way if you’re the leader of a chaos team. A chaos team leader needs to be assertive and strong in their actions.

When the ship is sinking, you need a leader to give orders, not call a meeting

A chaos team leader will often need to take a stand and maybe tell management that the team cannot do everything that they’re being asked to do. It’s a tough role, it requires you to make tough decisions with conviction.

Management done right is a really tough job

So why, as a team leader, do you have to make all of these tough decisions yourself, instead of discussing them with your team? Well the simple answer is that there just isn’t enough time for meetings. by making these executive decisions yourself, you’re giving your team some breathing space, or simply just the space they need to get their work done. Sure, you might make a few wrong decisions, life’s tough, but it’s for the greater good because you’re giving your team the space they need to grow into the next level, a Learning Team.

Learning

This level of maturity is one in which the team has a greater degree of self organisation, but the team members still need to be coached. A team leader will need to grow his/her team by constantly challenging and questioning them, maybe even setting them homework! The goal with these teams is to improve week-on-week, and to get the team members to start solving their own problems.

So what are you going to do about it?

As a team leader of a Learning team you need to start to get your team members to solve their own problems in order to grow into a self-leading team. So if someone comes to you with a problem, encourage them to think of ways to fix their issue, and empower them to do so by responding with “so what are you going to do about it?”.

Self Leading

The third level of maturity is the self-leading team. This is where we all want to be! In this team, the leader is more like a mentor – he doesn’t tell people what to do or make executive decisions on behalf of the team as he/she would in a chaos team. Even in a self leading team, the team leader should still spend in excess of 50% of his time with his team.

So, the first mistake in our list is to not recognise what maturity level your team is at, and therefore not know how to lead your team in the right way. If you run your team as if they were self-leading, but in reality they’re chaos, then before long you’ll be heading up a certain creek without a paddle.

#2 Fear of Delegation

If you’re used to taking things on and doing them yourself, then it can be quite hard to feel comfortable delegating work to people, especially if you have trouble relying on others to get the work done.

If everyone feels comfortable in what they’re doing, then you’re doing something wrong

When you delegate work, you’ll need to get used to asking other people to take responsibility for something you’d otherwise do yourself. This responsibility can take some people out of their comfort zone, and this is a good thing. It’s important to challenge your team and get them out of their comfort zone as it’ll help them grow.

#3 Fear of Engagement

This generally means not communicating effectively, but Roy breaks this down even further:

#4 Placating

“The Bus Factor” – what’s that? Well, the bus factor is the number of people needed to get hit by a bus for the project to grind to a standstill. It’s all about individuals holding lots of information. I’ve seen this in a number of places, on good projects as well as bad, so I think it’s fairly natural, but the point that Roy makes is that you mustn’t placate these individuals just because they hold a lot of crucial knowledge. A person with a bus factor of 1 (meaning they could bring the project to a halt if they got hit by a bus) should be treated just the same as anyone else. I love the idea of people having a bus factor, just because it reminds me of the Kevin Bacon number.

#5 Being Irrelevant

I think this is about being in too many meetings and dealing with too many emails etc and so on – basically not being there for the team, losing contact with the real work, and generally being irrelevant. Nothing to do with Kevin Bacon.

#6 Being Super-reasonable

Not sure I really agree with the terminology here but Roy says that it’s super-reasonable to assume that everyone understands what your talking about when in reality you might not be getting your point across. I think the point to make here is that when you’re dealing with groups of people, as in an agile team, it’s wrong to assume they all have the same level of knowledge and understanding as yourself, and that you should communicate with them in the best way suitable, which tends to be by not making too many assumptions.

#7 Blaming

If you make your mind up that someone’s rubbish, then you will consciously and subconsciously use this as an excuse to not engage that individual. There will always be some people who are rubbish, but what you need to do is work on their weaknesses and bring them up to the level of the team, rather than to avoid engaging them, as this just means you’ll constantly be carrying a dead weight.

#8 Ignoring Behaviour Forces

You must understand the forces that act on a person in order to understand how they behave. There are 3 main types of forces that act on a person:

  • Personal
  • Social
  • Environmental

All of these can affect a teams ability to be successful, and you need to work out exactly what these forces are, and determine whether they are affecting your teams ability. An example of an environmental force is not having enough hardware to do what you need to do – for instance, if you don’t have budget for a continuous integration server then it’s going to be almost impossible to be agile.

#9 Fear of Assertiveness

Apparently this is common in the UK and in Norway, but not in Denmark. Bet you didn’t know that. Well it’s true, allegedly. Anyway, assertiveness is all about standing your ground and not living with things that you feel aren’t acceptable. If your team is in chaos mode, then you need to be especially assertive. A fear of being assertive can be disastrous in a chaos team.

#10 Spreading Non-Commitment

This is about using vague language. Roy says that you should always commit to deadlines, and when speaking to your team, make sure they tell you when they will do something by. Apparently, just by making the commitment in the words they use, they will be more motivated to deliver on that commitment. Roy suggests that when you have a meeting, end it by asking people what they’re actions are, and make sure they answer in the form “I will do X by Y”. However, people should only commit to doing things that are under their control, there’s no point committing to doing something that you have to get someone else to do. Also, as soon as you know that you’re unable to deliver on time, let the team know and they might be able to help you out and maybe then you will be able to deliver on time.

Questions and Answers

The Q&A went on for an age. I’ll summarise in bullet form, because bullet points are great!

  • You need to recognise when to change your leadership style – you need to stop being a chaos team leader if the team moves on the being a learning team
  • There’s no such thing as a chaotic learning team. The 2 cannot co-exist, however, teams can switch from one form to another.
  • Overseas teams don’t work as well as having everyone in-house. If you’re in this situation, you need to “change your reality”.
  • Agile teams should be 2 pizza teams – i.e. only as large as can be fed by 2 pizzas.
  • Good teams are grown, not hired
  • Scrum sometimes doesn’t fit teams in chaos mode
  • There’s no difference between a team leader and a manager if they’re the same person, which they can be.
  • Protect your team from project managers if your in the chaos mode

Books

A number of books were mentioned. Here they are!

Managing Teams Congruently – Gerald M Weinberg

Managing Teams Congruently

Behind Closed Doors – Johanna Rothman

Behind Closed Doors

Influencer (The Power To Change Anything) – Patterson et al

Influencer - The Power To Change Anything

Succeeding With Agile – Mike Cohn

Succeeding With Agile

Acunote – Agile Project Management Tool

This is just a short little post about a task management tool I’ve been using for roughly a couple of years now. It’s called Acunote (http://www.acunote.com) and I’ve come to love it. I use it as a task management tool at the moment but in the past I’ve used it as a project management tool and a team management tool.

Acunote is based on the agile scrum system, and as such it allows you to create “sprints”. In your sprints you create tasks (in the real world these would be derived from user stories). You can assign tasks to individuals, estimate them, set a priority and continually update this information.

acunote sprint

As you can see, acunote will work out a burn-down chart for you as you go along (which you can view by user, multi-user or team), and will give predictions on whether you’re going to hit your targets etc. It also allows you to keep a backlog, and to add a bunch of tasks from you backlog into a new sprint is as simple as a click of a button.

All in all I’ve found it to be fantastic, and I couldn’t imagine not using it now. I highly recommend taking a look at it.