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

How does Scrum work on large complex stories? We cant do this in a month?

The word potentially shippable does not mean that you ship to production every Sprint in Scrum

You can have stories that span multiple sprints, that may not make it to production. This may be part of a larger EPIC story. The goal is to work on it every sprint. We have seen many instances where the product owner decided to ship the story half way through that process, as they see see that what is developed so far is not complete, but is good enough to ship.