Recently held workshop on Agile Awareness in Xebia India was a great learning experience for all the newbies into Agile way of working. The delegates who made up for the event were from a wide range of portfolios starting from Team Lead, Project Manager to Software Developer. So, this made the whole stage quite interesting.
It started from “The Problems that we face generally in Software Development”. And the answers that we had were quite unanimous.
- Unrealistic Deadlines
- Poor Estimation
- Surplus Documentation
- Inadequate Testing
and the most stressed point by all of us was “Changing Requirements”.
After expressing our major ‘Blockers’ it seems we were ready to take a plunge into the Agile World. The buzz word here is “Iterative Incremental”. This simply means that Iteratively you keep on making progress by adding something to the structure, however small the increments may be.This is a lot different from what “Traditional” methods ask us to do. Simply put,in traditional methods,the peak comes only when you are at “All-at-once-Delivery Stage” which is when your project completes.
Nicely Stated by Craig Larman :”Usually a partial system grows incrementally with new features,iteration by iteration,in other words,incremental development.”
The dictionary defines Agile as “Nimbleness or Flexibility”. Agile in context of software development paradigm is all about being Adaptive than Predictive or Rigid. To change is law of nature. So we should not be afraid of changes. Rather we should plan how to act according to the change. The ones who crib over the changes required are rigid in thier approach. And Agile calls for being flexible in accepting any change made or to be made.
Most of the delegates have already experienced the pain of changing requirements, thus we were excited to see how Agile would come to our rescue in this area
This was explained quite well .It goes like:
In Software development it is impossible to have “Frozen Requirements”. And this is because we simply cannot freeze time. So we generally have bulk of requirements from the client which can be modified , updated or scrapped by him in later stages of time. . Out of these we first focus onto the “High Risk” and “High value” requirements. High Risks need to be tackled early in the development phase and High Value means more profits to the business. Apart from this we also have MoSCoW techniques to prioritize our requirements. For those who are thinking what is MoSCoW city to do with Agile and software..Take a look:
- MUST have this requirement to meet the business needs.
- SHOULD have this requirement if at all possible, but the project success does not rely on this.
- COULD have this requirement if it does not affect the fitness of business needs of the project.
- WOULD have this requirement at later date if there is some time left (or in the future development of the system).
A brief mention of The Agile Manifesto was also made which is followed by the four points:
- Working software over Comprehensive Documents.. (Simply Said is: All that matters is what Works!!)
- Customer Collaboration over Contract Negotiation..(Collaborates definitely sounds positive than Negotiates)
- Responding to change(Definately with a plan!)
- Individuals and interactions over processes and tools.
Short Iterations, TDD, Potentially Shippable (or Working Software) product at the end of each iteration, individuals and interactions over processes—Is all what we need to do.
To summarize Agile Way of working ill put it like this:
PRIORTIZE –> DO SOMETHING (ITERATION) –> GET FEEDBACK –>IMPROVE N GET GOING.
The two things that personally strike me are:
- Getting Feedback
- Failing Early.
I was amazed to see how “Real” is this way of development. Feedback was something we ve always taken/given. Be it shopping with friends or Areas of Improvements Column in magazines or newspapers.We all want to improve.
Another thing is to fail early. It’s always appreciable if you fail early ,improve and then win your task. And as a developer this is what we should look for too.This Calls for the use of Test Driven Environment.
After opening up the umbrella of Agile in the” Why Agile?” session we were now braced to take a peek at various technologies comprising it.
Our first destination was SCRUM Techniques. Had heard the word “SCRUM” before which had to do with the Rugby team. It is when the team huddles together to discuss their plan of action for the next few minutes of the game. Was figuring out as to how it fits in here? To this we were told that to work Agile way the teams should be self organised and cross functional. When we say cross functional it means that a team should be adept and complete in every sense. This can fuel a very common debate of Generalists over Specialists that is persisting in the industry since long. I came across a very useful blog on this topic which happened to be written by one of the speakers of this event. The other key aspect is self discipline in the team. And I think this is what makes this simple concept a difficult one to follow. We don’t like to be disciplined ..that’s the general word..
After this we were introduced to various roles existing in Scrum. To give a short trip ..Product Backlog,Scrum Master,Sprint and Sprint backlog,Committed Backlog, Burndown chart. Another very important point that caught my attention was “Responsibilities are never given but taken”. I agree.Responsibility “given” is more of an instruction. As someone has aptly said : “You cannot instruct to innovate”. Later in the session we talked more about the iteration details.An iteration is a short period of time say 2-4 weeks in which a team goes for a complete development cycle.For traditional developers we can put as a whole waterfall within an iteration. In Agile starting from taking requirements into Sprint backlog to Sprint retrospectives -all becomes part of an iteration.In this whole discusssion it was little difficult to think in terms of velocity and complexity points though. Probably cause brain was busy receiving hunger signals!! 😉
After breaking for snacks,it was eXtremeProgramming..second flavour of Agile. This name was little tough to comprehend than the earlier ones. It started on the note that everything done should have some business value and should make sense. So it was clear that its from the developer’s perspective. Out of the four levers of a project namely:
agile team plays with the lever of functionality i.e.Scope. Its very common to see that about 60% of the functionalities of a product are never used and about 20% are intensively used.
Again coming back to real life association of agile..I believe that not everybody is a born genious. But two ordinary minds working together can definately come up with extra ordinary results. And simply put this is Pair Programming in Agile. No doubt it is a win-win situation if both of you pair well. But i was stuck with a question..What if you and your pair dont gel well? It could be disastrous to project’s productivity. We then discussed number of intelligent ways to overcome such situations within the team. In this course of discussion one of the speakers came up with a really interesting Solution to this called “CC and BCC”. Those who are wondering..CC is communication over coffee and BCC is bullshit communication over coffee. Indeed, a lot can happen over coffee 🙂
Here I would like to quote one of the speaker ..You need to have a lot of “Courage” to work Agile way. I guess that’s absolutely true. When working agile way you need to shed all your inhibitions . Come out with any or all of your problems . Discuss with the team and move ahead. How many of us are really comfortable saying “I’m stuck with this problem , Dunno what to do?”Not many of us can really tell our weakness to others. This in particular calls for lot of “Courage”as agile encourages full interaction among the team.
Till the end of this session i was happy as i could now make this point clear that XP talks at developer level whereas SCRUM talks at project management level..
As we say in software industry there is nothing like theory sessions.. So here also a hands on session was awaiting. It was real fun to now imply the “simple and realistic rules of Agile”.We went through two iterations..where we were given user story . We had to plan and assign complexity points to each user story. After this planning we had to commit to those stories which we thought were achievable in stipulated amount of time. And it was not points that made a team win but how much you learnt from the mistakes.. We had a sprint retrospective after each iteration. This was the real learning of the day. At the end of this hands on we were now really comfortable with complexity points and velocity concept..
In the end to summarize i’ll say that Agile way of development is not a revolution but evolution. It’s realising your roots ,infact, coming back to your roots. Taking feedback , working in baby steps and improving, failing early is all we have been doing in our early days but then had kept them in oblivion.
Agile is not about revolutionizing software development but breaking the ice of rigid mindsets!! Its time that we break free and appreciate the beauty of Agile way of development. I congratulate the speakers for their efforts which definitely ignited these sparks in most of us.