Agile Teams – A new kind of slavery

The first line of the agile manifesto says

Individuals and interactions over processes and tools

( copy paste from Agile Manifesto , font size included:)

I find it quite surprising how soon in an agile project we become slaves to processes and tools over individuals and interactions. From tools that capture stories and use cases to those that manage bugs, all those word documents that gets pumped out to prove to customer we are indeed a CMM level 5 company, or that we are compliant with some so called consortium.

How many times in the beginning of a project have you written a document ( although i hardly write much of these today ) called functional specifications, software architecture document. Every company fills these documents with 80 percent fluff ( what i called cut and paste sections, be glad if at least the project name gets changed , AN RFP that goes in depth to prove why we are any different that someone else who is trying to prove the same point.

Sometimes the very nature of how software gets written today in distributed teams forces us to become slaves to tools.

Daily stand ups are often seen huddled around a monitor or a projected screen pointing to exactly the story and task number thats they are working on.How different is this from a classic status reporting. Some one recently pointed to me that a particular stand up was looking like they are attending a funeral. Heads bent every body is trying to answer the three questions

What i did yesterday -

What am i doing today

Any impediments.

Why only these three questions ( because scrum says so — Process again coming in the way of agility).

Can I not share answer a fourth question, what if i don’t have any impediment do i still have to say no impediments

Then we have team members that are arguing all over the tools , whats right and whats wrong. A meeting or so to discuss the implications on not following agile processes.

In doing all this dance to product software, we forget the simple facts for success in a projects.

You produce good software if you have teams that work together, that can mingle and tell someone on their face how they can improve.

Teams have to feel safe to work and be told that they are they are important for the companies success Its not enough to just say, you are a self managed team figure it out:)

A self managed team needs some management and training on how to be one. They may not know what it means. Read this outdated paper on All I Really Need to Know about Pair Programming I Learned In Kindergarten.

Share everything.
Play fair.
Don’t hit people.
Put things back where you found them.
Clean up your own mess.
Don’t take things that aren’t yours.
Say you’re sorry when you hurt somebody.
Wash your hands before you eat.
Flush.
Warm cookies and cold milk are good for you.
Live a balanced life – learn some and think some and draw and paint and sing and
dance and play and work every day some.
Take a nap every afternoon.
When you go out into the world, watch out for traffic, hold hands and stick together.
Be aware of wonder.

Software development is only complex due to all the walls we build around to make it.

- Hire trustworthy developers, let folks who don’t gel go to another team

- Trust your fellow developers and make things visible.

- Try a couple of things and customize it to what works for your group

- Human mind gets bored of routine mundane tasks. Create an atmosphere where all these mundane tasks are CTRL-ALT_DEL

- Set expectations on your team.

- Treat your customers time and budget as your own. It takes time to build trust. Don’t take shortcuts.

- If something does not work for your team, chuck it. ( if you have a supportive management, you can do this)\

- Encourage creativity. Software development is as much art as science. Dont make it so complex that creativity goes away.

Read this blog by Steve who seems like a Google employee on good and bad agile. Its long be patient. It gets better if you stick till the end.

If you had the patience to read Steve’s article and still come back to my blog: Thanks for hearing me out.

Be different. Develop software with pleasure, make a difference.

What brings out the best developer in us?

In the past decade I have worked with a dozens of developers, people with different skills, different Type A, Type B characteristics. I wonder what brings out the best developer in us.

Is it money?
Is it some title – Lead software architect, Best code monkey, Director of development?
Is it the challenge of the work?
Is it the recognition from fellow workers and management of your good work on a internal memo or meeting?

What motivates the inner developer/ software creator ( not all of us are developers) in us to create software that goes beyond our own expectations and gives that aha moment!

I always thought that developers are motivated by a little bit of some or all of the factors above.

I guess i am proven wrong time and again.

Is it money?
Money obviosly is a big part but that does not explain all the free and open source world class software systems out there.
Whats common about all the open source developers, most of them work somewhere or are students and develop open source software for the fun of it. If every one would do it just for money we would not have all the Free and open source software around.

Is it the title ?

I once met a software architect who was a control freak. Everythings gets done his way. His team members would never speak in a meeting. They had gotten bored of being over ruled time and again. Repeatedly they would come to meeting, shake thier heads vigorously to what the architect would have to say and then go and do what they want.

There is no fun in development when there is no debating, arguing and fun to do stuff. There is no correct way.

So obviosly title means nothing

Is it the challenge of work?

Not everyone likes challenges. But software develoment is not always about challenges. In most of the software projects there are many cycles . In some we are in the investigative mode, trying to figure out the unknown and hence the challenges. I have seen some developers who are good at solving problems. Some like to do the routine take the data from some database, apply some business rules and show it in the UI.

So challenge is not the only aspect of it.

Is it the recognition / motivation factor from fellow workers and management of your good work on a internal memo or meeting – Honest feedback?

Well this to me seems to one of the most important aspect of development and often very few companies do anything about this.
Positive reenforcement works wonders even when we grow up. If someone listens to me and gives me honest feedback, ( good or bad) i like it:)

In the past I have worked with probably a few dozens of people but those that come to my mind first are those that have taken that extra step to tell me i am good or that i suck, directly to me or through some other means.

In a world where i have to spent a big chunk of my time sitting in front of a dumb terminal, a chat with a developer, a feedback from my manager ( Not email, no phone). Here are examples of folks with no names that made a huge difference to my software development

- My first team lead when i worked in India, who took the extra effort to teach me the skills of a good developer.She would never get upset with all my questions.
- My client in florida who forced me to speak at a conference on design patterns.
- My team member ( when i was a team lead Title Title ) who told me that he did not like the way i had spoken to him the previous day about his work in front of everyone
- The software architect mentioned above who never stopped arguing with me on anything,just because he was the client and he could.
- My manager who told me to speak with a voice that my own ears can hear
- My client who left a badly worded letter on my desk telling me how my skills was, when i got caught in a polital battle between two architects/ senior political developers
- To the clients who told me that i could come and work anytime in thier firm
- To the interviewer who told me to write code for a doubly linked list on a white board to prove a point.
and so on

Notice no where here there is money or title involved. Its mostly the recognition / motivation factor and challenge

Have fun doing what to do. If you are not having fun developing software, do something else !! Be open to ideas good or bad

and walk what you talk..

So long..

Mock objects not compile aware

When I use mock objects in this case NMock, I would really like to have compile time check that passing the paramters to the expectation as strings

Example

Expect.Once.On(dbHelper).Method("GetRequestsForUser")
.With(userID).Will(Return.Value(requests));

In case in point above I am expecting that when i call the helper in that a method called GetRequestsForUser with userId
will return something

The problem is the mock framework is quite dumb until invoked.

When i want to refactor by adding a new parameter to the method GetRequestsForUser, the compiler has no clue that i have to change the test above.

Does anyone know the intent behind choosing such a design for the mock framework. Is there something more smart out there.

Update: Found out from one of my friends about Rhino mock. A typed mock framework. I haven’t used it yet, but plan to try it out soon.