Agile is really about forming 1-BIG-happy family or in geek terms: one collaborative unit of work.
If you go over most(if not all) of the practices Scrum\Agile\XP have to offer, you’ll find two things in common: how to make your customers ROI as higher as possible as soon as possible and bonding everyone together so they are ALL responsible for the ship to move forward, one step at a time, constantly. Good-will and high IQ is a (really)great start but never enough. At the end of the day, customers understand working functionality described in user stories(“I will be able to move my money between my bank accounts”) rather than functional stories(“The system will supply Web Services in order to integrate with our billing system”) and most importantly – they’ll only pay for the former. But the technologist part in me(I’m made of 70% water, 29% 0 and 1, leaving about 1% for adult context), understands that we programmers really love to solve hard problems in elegant ways. I never saw nor hear a developer jumps up and down saying something like “I made it possible to move money from account A to account B!” or “The user can now get his lost password via email!”. I just love the idea of creating a successful setup so our brilliant guys will be able to transform their IQ into business value. What a noble idea, actually making one’s talent into a fat paycheck (I’m probably the only one finding it romantic am I?).
In many ways, gather the “right” practices for the team is like getting ready for a lecture in front of a big (important)audience. Forming a good lecture requires a lot of thinking(what do I want to deliver), preparation(how can I do it), ice-breakers\funny stories(keeping them smiling and cooperative in the process), motivation points(keep their eyes on the ball), examples(proves that it works) and most importantly – letting your audience know what they’ll gain from this lecture(high ROI) and keeping your promise. Don’t be a fool, trying to enforce the process or make a shortcut will be like participating in a lecture where the presenter decide to write a set of articles in his slides causing you to look at the 100–inch-screen-with-1500–words-per-slide, thinking it will deliver all the data you’ll need. It never does.
How can you start making a change(including improve an already great practices)?
- Read, listen, view, try things, write notes. Play the secret agent role and try to learn your enemy.
- Let your people know about these practices. Open their eyes into new ideas.
- Explain how things will work from now on, how it will look in 2 months, 6 months, 1 year, 2 years from now. Inspire them.
- Answer their questions, make them trust in the system and trust the family.
- Detect negative workers and detach them from the team. NOW.
A little push to get you going:
- Portrait Of An Agile Development Process
- Seven Agile Team Practices That Scale
- Scrum et al (Google Video)
- On Process And Practices (Jermy Miller)
- Kanban in Action – whiteboard to the rescue, making it all visible
- Comparing Approaches to Budgeting and Estimating Software Development Projects
- Agile Process Smells: Solution Stories
- Agile Process Smells: Waiting on Specialists
- Agile Project Planning Tips
- Tacit Knowledge – constant learning and practicing