I had to change a title of this post many time, as I was unable to give it a right sound. At the end I came back to the beginning, as it usual is when I’m doing something. Article inspiration came from a short Talk on Agile development that I have attended yesterday in London. Erik Doernenburg from company called ThoughtWorks was giving the talk. Very good talk with a number of real life examples (something everyone is keen on). He approached audience with presentation of 10 Myths about Agile Software Development. But let’s start from the beginning this time 🙂
If you know what Agile is SKIP THIS PART, as you might get bored.
One might wonder, what is this Agile thing that I’m talking about. There is a number of articles on web about it, a huge number. Some good definitions in Wikipedia as well. There is no need for me to rumble about it for the rest of this post, so I will briefly mention it.
For me Agile is approach to software creation, to the whole life cycle of a software. Design, implementation, testing, releasing and so on. Agile development favors PEOPLE over PROCESSES and TOOLS, WORKING SOFTWARE over TONS OF DOCUMENTS THAT SPECIFIES IT, COLLABORATION WITH CUSTOMER over CONTRACT AND IT’S NEGOTIATION, and CONSTANT ADAPTATION over FOLLOWING THE PLAN. You can read the whole Agile Manifesto in here.
Two words about what each things mean.
PEOPLE over PROCESS and TOOLS. It simply means that good, professional developer is more important than a development processes and tools to use. Often companies are forgetting this and develop all ridiculous bureaucratic software development processes and are using weird, complicated, and useless tools. POWER TO THE PEOPLE 🙂
WORKING SOFTWARE over TECHNICAL SPECS. There is no need to spend months on M$ Word documents, PowerPoint presentations, diagrams and Word documents again and not produce a single line of usable code, of anything that can actually be presented to customer as a product, and not it’s specification.
COLLABORATION WITH CUSTOMER over CONTRACT. Present ready for use software to customer as often as possible. Work on a weekly, two weeks iterations and collect customer feedback all the time. Listen to customer and build healthy relationship. What will contract negotiation give you when at the end you finish with unsatisfied customer, and project that has run out of time and budget scope.
CONSTANT ADAPTATION over FOLLOWING THE PLAN. For me this is the most important method. React to customer feedback and to difference in expectation. More often you get feedback and adapt, less changes and customer unpleasant surprise and dissatisfaction will you have at the end, and during the project as well.
I think that those two pictures are pretty good graphical presentation of Agile methodologies.
“And now for something completely different” – Monty Python
Not so much different as coming back to those 10 Myths that were presented by Eric in “Why Agile Teams Fail” talk. Those 10 Myths are the 10 major things that make people misunderstand Agile, and are there in a real life to mess it up (or just a project). I hope I remember all the 10 myths so I don’t make a fool of myself. Here we go.
Wrong idea about Agile.
Some people that heard about Agile thinks of it as it is a good thing for small projects. That is not true. There are companies like BT, Barclays Bank and many others that are using Agile on a daily basis and they are definitely not running small projects. I’m sure someone at those companies made a strategic decision about development way and it was truly thought through.
Next common misunderstanding is about pair programming. Twice as much programmers doing the same job == twice the cost. Let’s say now that one of these coders is writing a code, second person is reviewing the code in a real time. He can mention a better solution, or indicate potential problem. When person that is Driving Development (actually has keyboard and is coding) lacks idea and can’t find a solution they can switch. So, this approach results in better code, reviewed, and probably created faster us there is no stops because of lack of ideas.
One might think that because there is no documentation required there is no specification of what the final product should look like and do. That is not true that there should not be any documents. Every project should have a scope and should have documents that presents functional, real life requirements. We should <strong>NOT</strong> (thanks Spencer) produced documentation that is not going to be read by anyone.
No need for analyst/tester is also not true. Analyst should work on user stories for next iterations. Tester should test the code from previous iteration, and developers work on implementation of current iteration. Developers left for themselves can’t produce code that will meet customer requirements, they need to have understanding of a business that comes from analyst. They also need a feedback about bugs, problems and improvements not only from client but from testers.
Wicked (misunderstood) terminology.
There is a number of terms that are misunderstood by customer/client/project manager when it comes to Agile.
| What YOU know you said | What THEY think they heard |
| Extreme programming | Risky business 🙂 |
| Agile | Loose |
| Pair programming | Twice the cost |
| Standup Meeting | The team is running everywhere |
| Refactoring | Unnecessary changes to the code |
| Unit testing (absolutely must have) | Extra code |
Bad understanding causes confusion and rejection! You have to explain that. Unit tests is not an extra code. It is a requirement written as code and test at same time. Unit testing helps decouple objects. Refactoring leads to more flexible code and being better prepare for adaptation. EXPLAIN terminology, or use other words instead.
No key rules
But off course there are key rules. There is Iteration Manager (eg Scrum Master), there is Analyst and there is team of Testers. I don’t need to mention Developers, they are always there 🙂
Overdo
It’s easy to do too much. To create to much and simply confuse clients, another developers and so on.
- That’s why don’t create to much documents. Make sure there are people that are going to read it (FOR REAL) 🙂
- Develop and collect feedback.
- Drop things with no Value (why bother)
- don’t micromanage (one dude tells another what he should be doing, developers telling analyst, and vice versa)
- don’t create ridiculous diagrams because they look nice, remember, is there someone who is going to look at this or is it just going to make me feel better
Pickup cherries
You will always find one thing here, another one there. Don’t ignore it. Don’t let fools guide you, require experience. ASK FOR IT! Decisions should be made by MOST valuable people, team. All the others are just a distraction. Try something BY THE BOOK. It might turn out to works for you and for the team. Practice this for at least 3 iterations, give it a chance. Very important, UNDO changes that are STUPID and don’t get you anywhere.
Agile is not only about adapting the software, it’s also adapting the way you develop it.
Lack of discipline
That is actually total BOLLOCKS. Pair programming is all about discipline. Test Driven Development is all about discipline. Continuous build and integration is all about discipline.
Make sure you are doing more than your lips are saying and don’t be afraid to response to changes. If something was bad and you see it, MAKE SURE you change it.
Do retrospective. Every team member should answer two questions:
- What worked for you?
- What was rubbish?
Collect answers, eliminate bad things and increase good.
Failing to ask for help
When you don’t ask for help and you are in bad shape you might get worst. Leaders of a project should be experienced people. Team should have experienced team members. Each role should have a mentor.
Too long iterations
Some projects are done in a way that Customer see final result and for sure is not happy. Why did that happened? Simply because he never seen what you do and was unable to make comments and provide feedback.
- Iterations should be weekly, and sometimes when team is distributed two weekly.
- Iteration planning meeting should take one hour
- Best developers require directions as they are finishing user stories faster than others
- It’s hard to get LAZY when there is constant ACTION in a team
Best weekly iterations are Tuesday to Tuesday, not Monday to Friday.
Failing with Sponsor
If you wont to have a success with your project, you need a sponsor (client) that is going to support your development way. As there is a saying:
“Good trial Lawyer don’t take bad cases”
And a final truth
Team makes or breaks the project. You need to support your team. And most important:
Have FUN developing and Make the Rabbit happy
I was trying to write about all I heard. I have a good memory but short therefore there are some gaps in the stories. Erik showed problems and solutions, issues and approaches to it. I hope this will help you a little bit.
Take care, Gregster
PS. This is longest post I have ever done.
PS II. It’s late, I’m off to bed 🙂
Greg Gigon's wEbLOG 