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.
