Need to ask what each member of your team is doing? Then your team is too big!

In daily (or more frequent) stand ups that is common in agile/scrum based teams many practices the process of asking each and every attendee: what did they do yesterday, will be doing today and if there is any impediments. Many do this by default without considering alternatives.

I have previously blogged that I trust my team members and do not need to know in detail what they did yesterday. I firmly believe it is more productive to focus on the tasks on the board rather than the individual. If you do not trust every member of your team then you have bigger problems.

However task focused only works with a small “1-2 pizza” team. A small team where everyone knows what everyone is doing, where the scrum master / project manager have full understanding of what tasks is currently in progress if not already obvious from the board.

Once the team grows too large you tend to have too many tasks on the board and people are all working on different perhaps even unrelated  tasks. The other team members, and especially scrum master, cannot keep up with all individual and task statuses so you need to do the token ring quiz.

The ring quiz takes time, and tend to let people’s focus drift away from the stand up and not really listen particularly well to what the others have to say after a while (I am guilty of this frequently), especially if some tasks never involve certain other members.

Also the project comes more inclined to individual tasks and not pairing and swarming together on the same tasks. The risk is then some people can disappear between the cracks or loose focus and your project start to become less efficient and agile.

So if you find you stand ups are leaning towards individual “what-you-did what-you-will-do any-impediments” interrogations then it is a strong smell of having a team that is too big.

(“1-2 pizza” is an analogy of how many can share large pizzas together. In my case 3-5 members is a good size, 8-9 is too big, and more than that is simply not agile)

Agile project tools for personal/open source projects

Been briefly assessing some online free tools for agile task planning for a few personal FOSS projects.

A physical task board is perhaps the suggestion from the agile purists, however not useful for me (nor my family :)).

At work I often have to use the awful Quality Center. It is good for planning functional testing, but not much else. The user interface is painful, and only works on windows with IE.

But most project I have been on eventually drop it for the more developer friendly Jira by Atlassian. Its UI gets cleaner and cleaner. And is great for Scrum projects since the intergration of GreenHopper. It is however very feature rich which is good and bad, and sometimes quite slow. I recommend Jira for distributed larger organisations. It is however an overkill for my needs.

I have been using Pivotal Tracker for some of my projects for a few years. It is a great tool. For scrum projects it is the tool I would recommend the most. They recently started charging but it is still free for public projects. It is however very iteration/scrum centric and as such not useful for my more Kanbanish time irrelevant requirements.

So I started to look at more tools (and revisit some previous ones).
My requirements are:

1. Free, as in beer or near enough. $9/month and similar is too much for personal projects unless heavily used.


2. Agile task board simulation


3. Not time iteration based


4. Simple functional UI, but not ugly


5. Icebox feature for storing tasks/ideas not yet ready for the backlog


6. Pivotal like Feature, Chore and Bug classification


7. Limiting WIP


8. Kanban queues


9. Simple T-shirt or fibonacci estimates

Not all requirements have to be met.

Here are my initial impressions:

Pivotal Tracker

Time iterative centric.
Looks nice. Clean interface.
No WIP limit.
No kanban queue.
Got Icebox feature
Got Feature-chore-bug classification.
Fibonacci estimates.
Unlimited free public projects.

AgileZen

Kanban style flow.
Looks nice. Clean interface.
Columns can be renamed.
Got WIP limit.
No icebox. Can rename backlog icebox and rename another column backlog.
No estimates
Only 1 project on the free price plan.
FOSS projects can apply for free usage.

Kanbanery

Kanban style flow.
Looks nice. Clean interface.
Columns can be renamed.
Got WIP limit.
Got Icebox feature
Got Feature-chore-bug classification.
T-shirt estimates.
Only 1 project on the free price plan.
No FOSS free plan.

Kanbanpad

Kanban style flow.
Clean interface.
Little confusing UI.
Got Kanban queues.
Got WIP limit.
Got Icebox (the "backlog").
No estimates.
Unlimited projects.
All plans are free.
Permissions are strange. No member can edit and public can only view. Either member view and edit with no public access, or public(anonymous) can view and edit!!

Leankit

Kanban style flow.
Seems very feature rich. Perhaps too many features.
UI a little cluttered.
Tasks seems too much like post-it notes.
Only 1 project on the free price plan.
No FOSS free plan.

ScrumDO

Scrum focused.
Looks nice.
Feature rich.
UI a little confusing.
No Icebox.
No WIP limit.
No kanban queue.
Fibonacci and t-shirt estimates.
10 project on the free price plan.
No FOSS free plan.

Flow

Kanban style flow.
Tasks seems too much like post-it notes.
No Icebox.
Got WIP limit.
Only 1 project on the free price plan.
FOSS projects can apply for free usage.


I may update this in the future when I get more impressions of the ones I use and if I find other tools.


My recommendations depends, but currently they are:

• For large commercial projects Jira offer features and reports. And can be installed inside your firewall.


• For Scrum projects Pivotal Tracker offers the most complete package.


• For Kanban projects, the it depends on your own requirements and taste, but my current favourites are Kanbanery and AgileZen. Kanbanpad's no restrictions on number of projects is also tempting

Scrum bashing - natural iterative evolution

Not throwing my weight into a current Scrum bashing trend that erupted this week, as I'm a nobody when it comes to agile. But I tend to agree some of the points and disagree with others.

It all started off with Uncle Bob responding to Chris Brookins whom was looking for some of Scrum shortcomings to present at his work.

That raised a large number of responses on the thread and in the blogsphere. People such as Jeff Anderson stated that it was time for Scrum to evolve.

Others such as Jurgen Appelo came in defense of Scrum by insisting people should stop pissing on Scrum.

Issues raised

• No technical rules, ie no prescribed methods of insisting on CI, TDD etc.
  I dont agree with limiting Scrum to development only, but suggestions are fine, which they kind of already do.
  


• Sprint lengths are too long.
  They are. But again agile carrots of emphasising e.g. 2 weeks are better than bashing teams that need longer sprints.
  


• Scrum masters assume or are assumed to have to much power.
  That does happen too ften, but coaching of team members and external chickens are probably the solution.
  


• CSM, Certified Scrum Masters.
  Yup the title does not help, I even got it....,
  but dropping it may result in very few taking the courses all together. Time will give a solution to this I think.
  


• Backlog structure.
  Not sure this can be solved, because so many different type of organisations use scrum for a variety of usage, the items in the backlog are very different.
  Partially the problem here also lies in the pedantic use of manual physical task boards,which translate into difficulties in transferring stories/tasks.
  Also the tools available, e.g. Jira+Greenhopper, have poor support for Stories and Themes.
  


• Anti management.
  Scrum and its adapters have a reputation of Anti management.
  This may be true as team members often would like to introduce Scrum for the empowering of the team in the decisions.
  But once implemented it is not so much the case.
  I would actually say it is a bit pro management, once they see the results and a clearer vision of their future. Also Scum increases management due to the team's own micromanagement and constant status reporting.
  


• Automatic tests.
  It's Uncle Bob, Mr FitNesse. True, an essential part, but not always the rule.
  


• Multiple teams.
  Yes, this is one point that Scrum struggles with.
  

Future of Scrum

I think this bashing of Scrum now is a natural evolution.

The early adopters, the evangelical Scrummers, now need a new fix, and are quite vocal in Scrum's negative points. The early sceptics, also realises Scrum does not solve everything and would like to move on.

But it is natural. RUP, then XP, Lean etc are not perfect, they are just an iterative history of continual evolution and improving methodology of teams and projects.

Scrum is not a bible to follow for the next 2000 years. But now, or rather 5 years ago it was the best thing around. It has helped a huge amount of organisations become agile. Not perfect, but a lot better than before.

We should not always jump to the new shiny thing, but it is probably time to evolve, to continually improve and never rest at least not too long.


I quite like ideas suggested by Kanban. Kanban practices more common sense. As Henrik Kniberg writes in his minibook about scrum and Kanban.

But again it is not the final evolution. And everyone should adapt their needs as appropiate. There is no need for this bashing of Scrum. But neither should we not try to improve it.

Coding Happy Place

Quite an interesting article on where a developer/programmer is most productive. (And the relevant slashdot discussion)

It is something I think is very relevant for the productivity and happiness of a development team, but is very difficult for companies and managers to control and allow. People need to communicate, share ideas, ask questions, freely and easily, but at the same time be isolated and respected to actually concentrate on their work.

Companies generally prefer and mostly demand people to be at their office desk during the same work hours as everyone else. And that they do their work effectively there, while being able to monitor and contact them at any time in person. Developers (or perhaps rather me) prefer the opposite. We would like to be left alone, unmonitored, trusted to deliver quality work by concentrating on the tasks in hand and at different times.

One issue is of course that everyone is different, some people are most effective and happy in noisy, open environments with frequent dynamic exchanges with numerous people, other are useless in such places and brilliant when left on their own. Most people are somewhere in between and at different times.



My experience, with different hours and locations

I have worked in a team once where one member worked from 6:00 till 14:00, while another worked from 14:00 till 22:00 and this was in the same office not different time zones. That only worked as they did not have much overlapping work and thus no direct interaction was needed very often. If that was needed, clear lines and rules of communication must be agreed and accept calls and work outside your normal hours.

My benefits

In that company I worked from about 10:00 til 18:00, of which the first few hours was from home, then the afternoon in the office (just round the corner). That worked very well for me. I could concentrate and produce code in the morning, be available in the office for meetings and discussions (gossip), and when people was leaving the office for the day I could concentrate on work again for a few hours. It was very gratefying to always be able to deliver something every day as I had those few hours in the morning, before getting caught up in the possible interuptions of the office later on.

Being able to work from home is difficult for companies as they must trust you to deliver and to be an asset for others while not being in the office. I think my own contribution was good. I could concentrate and deliver at home, while being always online with IMs, and usually had 2-3 windows open all the time for continous discussions with other developers, while not letting it interupt whatever I was concentrating on, which a verbal discussion in the office would have interupted.

Problems

However other colleagues it may not have worked so well for. One delivered excellent code, however was very hard to get hold of, so it delayed mine and other people's work all the time. (So much that the company implemented in office core hours between 12:00-17:00, probably mostly so managers could get status updates.). However that could have been avoided if good practices and respect for each others meant that people were nearly always available and quick to respond to email, IMs, video chat and telephone calls. Another colleague felt managers did not appreciate or trust that he concentrated on his work, so he made a point of working in the office and placed his desk right in front a manager with his screen in full view, so they could see he was working at all times! :)



Scrum, agile enough?

So if you have or need this flexibility how do you then integrate Scrum and agile process in to this free multi-location, any-time setup? Scrum implies that teams physically sit very close together, share and discuss verbally, have in person stand up meetings, use non electronic task boards.

Simple answer is you don't.

But actually you can. But probably not at the start. Once people are familiar with the process and each other and trust has established, you can start to use electronic tools such as JIRA-GreenHopper for the task board, develop processes for IM/webcam communications, agree regular but flexible times when everyone is in the office, etc.

Even if not working from home you can achieve Coding Happy Place with headphones, offices with doors, just some separation from other people and developers without the humiliation of cubicles (basically just being really left alone) etc. One of Scrum's ideas is to shield developers from interuptions. And that benefits concentration.



My Coding Happy Place

So where I am most productive, and also happy?

As a consultant on contracts I now have to show facetime at clients, and as a 3rd party, are perhaps not trusted to work from home (ie bill unseen). So I basically can never work from home, and I think my productivity suffers. Being professional I still produce well and accept these limitations, but at a cost.

I can achieve coding efficency at work, usually after 16:00 when the offices is emptying and I can relax and concentrate. (And usually get engrossed/stuck on some task, and don't get home til 21:00). Also when I have had a nice desk in corner (facing outwards), quite inaccessible for others and not overlooked (not feeling paranoid about searching newsgroups for answers), I have managed a Coding Happy Place and churned out lots of work, as Im comfortable and people do not interupt me directly or indirectly so easily either. (With the right tools: Tiny screens, forced to use Windows, restrictive network, etc over time costs much more in lost productive hours than initially supplying better hardware).

I did like the arrangement I had at that previous job (however as mentioned it did not work for everyone). So somewhere you are trusted to work from home when required, and it is not an issue would be great for me and really for my productivity.

Recently when I was left to myself at the cabin, I did more work on a pet project in two days than I had for 6 months. Simple because I was left alone. So that is my Coding Happy Place, being left alone. Whether it is at home (mornings only, not evenings when other people is there) or in a corner desk at the office. I would still spend most time in the office, for project discussion and velocity but also for the social banter and gossip!


Can companies compromise?

I hope they can, but big companies can afford to and unfortunetly often let go of creative developers in favour for A4 ones, but also big companies can afford to adapt to more flexible arrangements as well. Can small to medium as well? I think so.

Basically I think with trust comes respect for others. So they accomodate your flexibile location and hours, while you must respect other's needs as well. With good lines of communication this can so easily be overcome. Not just phones, but email, IM, webcam, good use of task managers etc.

They should not think they are pandering to developers, nor should they accept missuse. But see benefits with flexibility and privacy comes concentration and very good productivity. Catering for Coding Happy Place is good for everyone concerned.

Don't like Scrum. But will not use anything else! Part 4

This is "Don't like Scrum. But will not use anything else! Part 4". But really it should be: Love "Scrum", but it is not perfect. Yet.

Right, I am now a Certified Scrum Master, so I should know more about the pros and cons of Scrum, and how to reduce some of the cons/risks.


Shorter sprints. Definitely something I have learned, so 2 or 3 weeks seems ideal. I have been involved in 4-5 weeks sprints, and they work, but not so well. Longer sprints have more scope, more risk, and can end up with several developers idle for many days at the end. Shorter sprints cuts this to perhaps max one to two days if any. It is also makes you pick only a few stories so they have more focus, instead of 5 stories which end up spanning many sprints due to impediments etc.

Each developer should pick only one task, and try to share tasks. Avoid bottlenecks and teams overdependent on one person.

Use electronic tools for task board, but have it showing clearly in stand up room, ie on projector or large screen.

Dont be a jobsworth police, but try and get the group interested to be on time for standups. And for people to say nearly only 3 sentences, no need to explain in detail what they did, so less pressure to have a "plan" ready and also much quicker.

Arrange discussions for later/afterwards, if anything pops up, do not solve them there.

Encourage another voluntary standup/chat in the afternoon if standup is in the morning or inverse. This to further encourage rubberduck chat and share knowledge and problems.


As for the Scrum Master certification, I did a two day Mike Cohn course here in Oslo. He is very good teacher/lecturer, as he knows the subject, have a well prepared agenda/curriculum, can answer all questions clearly and with authority. So I can recommended the course very much.

Don't like Scrum. But will not use anything else! Part 3

I like ranting I do.... :)

Now to my third instalment(1,2) on this subject, which will regurgitate a lot that has been said before.

As mentioned before I have major issues with the Scrum methodology. BUT it is also the only methodology I would use! (At the moment).

Scrum and XP, which are being advocated by developers as the new messiah. But I think developers fail to see it will have a derogatory affect on themselves.



First of all: Stress: The constant status demands every morning, all the time on notes or JIRA tasks etc. The constant planning of your day and defending every minute used. Mostly due to the stand-ups.

By iterative development, you minimise the stress at the end of a major release, but introduce others.

True, for business, this means more effective developers in the short run. For managers, it is a good way of keeping oversight of how things are proceeding, and a good whip to keep people in line.

But for developers, yes you are more effective, but eventually you are also getting very stressed. The need to perform at your maximum all day every day will wear and grind your psyche. If you had a bad day, where not much was actually done on a specific task, you have to defend that the next morning, or simply lie. You can not cover the slack by concentrating a bit more for the next few days.

For the perfect A4 cubical worker, ala German, Norwegian, Japanese (anyone else I can offend by stereotyping?), then this rigid life will work well, but for more creative, individualistic, "agile" worker this can cause friction.

(Not sure I've mentioned I don't like the standing up in "standups"...)

But again, I can not see how you can not have morning stand up meetings, as the benefits outweighs the eventual stressed programmers....



Second: Pair programming.

Unless you are the A4 type programmer without a personality, I can not think any self respecting programmer would welcome pair programming? It is intrusive, violates your personal space, stops any creativity, lack of trust and is just smelly.

The benefits of sharing of code knowledge, the idea bouncing while creating classes and methods are great. The banter if personalities match can be good. And also distracting?

The smirks as girlfriend/wife sends embarrasing emails/IMs that pop up in the previews...

The concentration of working on only one specific sub task can be good for velocity. But also sometimes you are stuck and switching context, briefly or for longer periods can also help enormously. But can you with someone sitting next to you? Or just drag that awful day further by staring at the screen?


But again, the benefits outweighs the violation of the individual. But I'd much prefer a more limited pairing, shorter periods, perhaps not always sharing desks, etc.


Also forgetting/ditching all knowledge learning from previous methodologies seems quite frivolous. RUP may be tedious and over extended, but many bits can assist and enhance your project. Don't just ditch everything , because you have converted religiously to something else, something "new" and "exciting".


But again. Scrum works well, brings a lot of benefits, and I recommend it!

Don't like Scrum. But will not use anything else! Part 2

Following on from my general rant about Scrum, Part 1, here is Part 2.


The main beef I have about Scrum, are
* the constant status updates at stand up meetings
* the use of non electronic tools
* inflexibility on tasks

These are elements that are easily changed and is probably mostly interpretation. My dislike for these can also reflect perhaps badly on me, if taken from a superficial view.

I don't like the morning stand ups. For several selfish reasons.
* I don't like mornings.
* I am not in early. (Especially now living in Norway where developers start work 4 hours earlier than in the UK even with only 1 hour time zone difference. My last job in Manchester, developers where not in till 11am. Here they start at 7am... )
* I don't like standing up.
* My memory is terrible.
* My plan for the day have not yet been thought of.
* I don't like standing up.
* I prefer to work from home in the morning, thus actually getting something done, instead of being a zombie at a meeting.
* I don't like mornings.
* I don't like the micro-management of it.
* It is a forced meeting.
* I don't like standing up.


It is not that I don't agree with status meetings and I can see standing up keeps meeting briefer.

Many of my work places, many of the companies' main issues have been solved in frequent 5min fag breaks (the English sigarette meaning of the word) even when no-ones smokes at the place. As a non-smoker I would always attend them, and discuss a bit rubberducking about things Im working on and stuck on. So informal meetings are very usefull.

Regarding standing versus sitting, I just hate standing. And not able to fully listen to anyone else's issues.

That it is just a quick run around of what you did yesterday, what you are going to do today and if any impediements, I just don't see the value for the developer. This should be clear in JIRA or any similar tool. Sure, it is a face-to-face status update for the management, so they can micro-manage everyone's day, but really mature developers should be trusted to deliver. That you can not discuss issues, devalues any development benefit from the meeting.

There are also some cultural issues to consider. Standing is meant to make it quicker, but Norwegians once a meeting is finished its timeslot will stand up and leave the room even if nothing has been resolved, or even when senior management or customers are present.


As a technologist and computer geek, the use in Scrum of non-technology such as post-it notes, sticking notes on boards, face-to-face meetings, is a sore point. Again I see the value, but it just goes against the grain of a technologiest.


Also the focussing on only the tasks on the board, post-its on your desks, and status updates on these every dawn is quite blinkered. True, it will keep people in check and some is usefull to make people consentrate on the tasks delegated.
But also have negative effects. Such as me, whom may help too many people, which is discouraged in Scrum as you should only focus on your own task.


And don't get me started on pair programming! That I should share my days with some other smelly developers odour is quite repugant. But again I see the value of writing code, solving problems together, sharing application knowledge. I just prefer frequent fag breaks and my private space! :)


BUT let me reiterate, I would only use Scrum!

Don't like Scrum. But will not use anything else! Part 1

As the title says, I don't like the Scrum (the project methadology). But I don't think I would use anything else!

It is like Churchill or Rooseveldt said something along the lines of: "Democracy is flawed, but nothing else works!". Which is also true. Democracy is the rule of the mob and pop culture, but all other governing styles leads to chaos, elitism or despotism.


I do like a lot of the ideas behind Scrum, the agile thinking is great, the XP ways do work. Everyone seems to jump on the Scrum bandwagon taking every element as gospel, and defending it religiously. But Scrum, has introduced many elements I don't like. I can see why, and what they can achive, but some I really detest.

Unfortunetly, all other project managent styles have more flaws, so I think "Scrum matured", or some better Agile methodalogies in the future is a better solution.


For Scrum and agile there are 3 sides to view from the pros and cons to its benefits.

* Management
* Developers
* Customers

It is mainly been developers who having been pushing Scrum as it will be better for customers, hence in the end for management as they are more profitable. However the bits I don't like is mostly where the benefits are purely for the management.


For management the pros are:
* Constants status updates
* Up to date status
* Future cost projectability
* Focused costs
* Low risk of wasted development


For customers the pros are:
* Ability to direct and change requirements
* Cost transparency
* Feature and status transparency
* Final release is as required


For developers the pros are:
* Low up front documentation
* Task sharing
* Modern and new, therefor interesting
* Management and customers are open to ideas
* Iterative development, of which one benefit is you dont have to solve everything immidietly


There are other pros, but they are not specific to Scrum, more that Scrum project are Agile and open to new technologies, and other methoods etc. Such as Continuous Integration, Wiki, JIRAesque.



But the cons are for developers
* Stress, due to constant pressure to perform every day
* Loosing individuality
* Turning into factory lines
* Constant status updates
* Perfect planning every day
* Orvelian supervising
* Loss of trust
* Low priority of refactoring
* Stand ups
* Back to low technology


Cons for management
* Stress and morale of staff
* Projects fix specific problems, but leave all else untouched, increasing rot and risk of general purpose tasks
* Distributed development is tricky


Cons for customers
* Probably not that much!
* Must trust supplier
* Difficulty in estimating accurate final cost


So you can see the pros does outway the cons. For Customers there really are no cons. It is just pros. For the management, once informed and convinced, they are also mostly pros.


It is just for the developers there are real cons, and they are the most noisy Scrum advocates! I am afraid as the idea behind Scrum gets older, developers will wain of it when they realise some of the consequences. But perhaps by then "agile" people will have forseen this and adapted a more mature and compatible "Agile 2.0" methodology and processes.