Teaming over Processes

There are some good discussions going on in Agile Alliance. One discussion that caught my attention was around "Will we break scrum by allowing changes coming in between iterations?".

Clearly by first principles the answer is YES. But that should not stop there. Why would one ask for change within an iteration when the iterations themselves are short? The design of agile is not to get into such a need. But life is hard, the unknowns are much more and hence there may be reasons when product owner may want a change coming in and can potential convince the teams to take it. In such a case, it is absolutely acceptable for the teams to take it up, rather than being rigid on this criteria. However, these changes will be taken with some compromises on the committed scope for the iteration.

The main point to take home is that agile runs on the Agile Manifesto and not a process definition. The agile practices are frameworks that SHOULD be tailored depending on team dynamics, strengths, weaknesses, contexts, etc but the manifesto should be understood and digested. Teaming and bonding takes precedence over a defined process as long as the overall manifesto is not broken. Kabir keeps saying "process is for defining what we cannot do naturally - teaming is something we can do naturally and hence is not a process!"

Thoughts?

Comments

tumstech said…
Good about the Agile, But my head is still spinning around the part where we accept changes in the Sprint / Iteration. It makes the Customer drive us like "Go left, no no, i ment Right, and now left". Just a thought
June 30, 2010 at 2:13 AM
Prasanna Raghavendra said…
Vishwanath, the key is to ensure that the product owners and the team work as a team and ensure that the changes coming are due to unforeseen areas and is also not possible to wait until the end of the current iteration due to business needs. It is a group decision to be taken to take these changes, the more the rigid these lines are, the more dysfunctinal the team becomes. worth a try!
June 30, 2010 at 7:09 AM
Saurabh Chandra said…
I agree teaming over process is the way to go, but how to form a team which is cohesive enough is a bigger challenge. How people with different aspirations come on board and create a product which is a winner. There are lot of factors which can help in doing that, I saw a article recently which talks about some things which I strongly feel can help a product company -
http://www.businessinsider.com/management-lessons-i-learned-working-at-apple-2010-7. Thought will share with you. I follow your blog regularly, interesting read!
August 2, 2010 at 10:35 PM
Prasanna Raghavendra said…
Thanks Saurabh. I did see this and I agree that it is a very interesting read, it takes collective innovation to make a great product and a great company!
September 1, 2010 at 6:41 AM
Post a Comment

Popular posts from this blog

Agile and The Moving Train

Back into the Blogging mood after long years! The reason is simple, I did not have much to share than the mundane stuff that kept on running for the last few years. I am back because I am now beginning to implement agile development process for a large team and am discovering wonderful stuff as and when I plough through the details of the agile delivery model. There are a lot of anologies that comes to my mind and I will keep writing these as a beginner trying to unravel a new world. First is an anology that I draw to a moving train. In agile you make timeline constant but scope the welcome variable (which is exactly the opposite in Waterfall), this means how often you deliver to the outside world is constant, but what you deliver is what you play with. A moving traing has stations and their locations constant (where/when) and how many people you move across is a variable. When you start with this basic analogy, there are a lot of things you can draw and ensure various roles are unders...
Read more

The joy of the journey

The software industry in India has really taken a toll on the IT employees. There have been plenty who are talking about exhaustion , retirement and moving out of the industry after 15+ years of hard experience. These are some of the stalwarts, greats who have done well for the IT service industry. The key reason has been that they have put in long midnight hours to bring a new project, work on bring the the projects into control and just executing this cycle with different pace, complexity and size but the cycle has been the same. When you take a step back at these instances, it is very evident that the industry will very soon take the exhaustion path unless we device a mechanism to bring in the joy of the IT journey at everything we do in IT. I have found less and less people who enjoy what they do, and always have a reason why they do not like what they do. The key is 'What is the joy factor of the Indian IT industry?'. Improving this is hard both individually and collectiv...
Read more

HOW SHOULD MANAGEMENT ENGAGE DEVELOPERS?

It was in one of those meetings, a senior leaders from a large company told me, ” You know, when I was a team lead, I had such a good time interacting with the team – I knew exactly what they are working on, how they were working and how I could support them. And I knew exactly how I can make a difference in their life. Today, I have a much bigger organisation under me, but I don’t know exactly what those individual contributors are working on? and no clue on how I can make a small difference to them and hence multiply those small differences to affect change in the company.” This got me thinking. He was absolutely right, the higher you go, the less you know about the individual contributors, but you have more individual contributors under you! “The larger your ability to make a difference, the lesser visibility will you have to bring that difference. An irony of life!” But I believe, you can actually make a big difference to these individual contributors even when a large orga...
Read more