Self organizing team – This is not a myth

Here is an email message from one of the coaches who is helping a team

The “Code Warriors” team has transformed itself into a self-organizing teams. They have gone from a cycle of 8 to 9 days to complete a user story to a new cycle of 1.5 days and they are now capable of taking an average user story to demoable state in just 1.5 days. They have also succeeded in achieving cross-functional behaviour with a couple of lean practices. Their developers can write test cases and test. Testers can write unit test cases.

I dont get to hear this too often. Hene I thought of writing this.

This team in a federally regulated industry and have to produce a lot of documents, ( I mean a lot lot ) for every line of code they write. This is what I call the art of possible.

Only a few months ago the same team had doubts on all of this to the point they wondering even to write two documents they may take a few months. They are building a faily complicated healthcare device based software. So its is not easy.
I remember thier early questions, doubts etc. In fact even I doubted this and They have proved everyone wrong.

So it makes me wonder how someteams make it and somejust complain for years. Hear is my observation of what I think has made this team go past all the hurdles.

1) Great attitude – Yes we can style. THe team has lot of young minds ready to change things as needed. They really have so much energy that you can bottle it and channel it to run a nuclear reactor.
2) Fantatic leader – Scrum Master. At first you may feel this scrum master ( yes he is a full time scrum master), is not that good. But he has made the teams impediments visible and known clearly within the organization. A calm person, I must say.
3) Fearless waste identification – A good team that needs to get self organized needs to really focus on waste. This group with the supprt of scrum master and manager have really identified many kinds of waste. I cannot mention many of them hear dur to confidentiality reasons, but they have stopped going to meetings, they have brought thier build time down significantly, testers no more wait for developers, isnt this a aha moment, what else they sit and write the unit tests with the developers. Wait this is not enough , developer help testers write test cases.
4) They sit in the same conference room for as much as they can.
5) They are focused on engineering practices not just scrum. Scrum can only expose mess. If you are runner, it will tell you “You suck at running because you run too fast” but it wont let you win the race.

As i always say, teams need to focus on engineering practices. Many teams get too fancy and start doing all kinds of weird things. Lets do TDD , even when they have no clue how to write unit tests.

Do what this team did , “Learn to write good unit tests first, write code if you need” work with your team

5) Testers do not anymore track bugs and write them in the bug tracking. They find it and walk to developer and sit with them and help fix it.

It is really said that many teams are just the opppsite. Ego issues, unneccesary focus on ESTIMATION ( did we do estination well), how much we are deviating from estimation, We cant do this because its not my job, I am testers I am measured by the number of bugs I find. I am a developer , I am measured by the number of bugs I write:)

Get over it software teams, the new generation of software teams are coming, Work like start up mentality, Code as soon as you get in the office, dont do the meetigns game, measure the time it took to write the code and report to manager,

Remember in the end its teams like this one that make all the differnence in a large organization.

My trust in Agile is still intact. Way to go Self organized team. Way to go the coach and scrum master who worked on this,
This team surely will go a long way.

I am done with my joyous speech. Amen

Advertisements

What is Promiscuous Pairing

Thanks for the image

 

Promiscuous Pairing” is a term coined by Arlo Belshee, and it refers to switching pairs very frequently (every 90-120 minutes) and swapping out the most experienced member of the pair each time

This can lead to a lot of knowledge sharing and multilearning in the team .

A random pair draw at the daily meeting is a way to start the first person to pair with.. Promiscuous Pairing forces the member to get over thier issues and can reduce the risk of only few people knowing about a particular thing.

Is Pair Programming Infectious?

Pun intented here.
If you do a lot of pair programming think again

here are some reasons why you should use your own keyboard at all times:)

1) Your pair has a virus ( real kind ) and is sneezing all over the keyboard
2) Your pair had a flu and is recovering from it.
3) Your pair is holding fries in one hand as he./she types and uses the keyboard with the same hand . Umm french fried keyboard.
4) You turn your pairs keyboard on the side and see all the food particles and dandruff fall.
5) Your pair went to the bathroom * enough said:)

If i have convinced you enough carry your own keyboard for pairing sessions and use purell when in doubt:)

How do you know if pairs are not working?

  1. If one person in staring at the monitor while the other keeps typing for more than 15 minutes.
  2. When a pair starts to become a mini gang. It two members get along well and start pairing they do well, bringing the other pairs down.
  3. When pairs are stuck in the same task for ever and start doing other things during thier time
  4. Its easy for the pair to lose focus just as one person, if they dont know the ettiquettes of pair programming
  5. If one of the pair members is forced to pair.

What is pair programming?

 

An XP practice where two programmers work alongside each other, trying to get a task accomplished. Two minds at one problem.

What does this bring about:

 1) It brings up productivity if the pair knows what it is upto. A chatty pair can cause more damage to the project than getting done

2 ) It keeps each person honest. If you dont know something its apparent in the fifth minute.

3) It helps keep the quality of the code. Since the pair is helping code.

4) This is where design happens.