http://jeffsutherland.com/scrum/2006/11/scrum-supports-cmmi-level-5.html
http://jeffsutherland.com/scrum/2006/11/is-cmmi-worth-doing.html
From the inventor of scrum
(Disclaimer i am working in a CMM Level 5 company and its possible indeed probable i am biased)
So the agile management folks see value in CMM level 5 principles. After all what could be incorrect about
Level 1 - Uncertainty. Success depends on individual effort.
Level 2 - Awakening. Basic project management practices are established.
Level 3 - Enlightenment. Standard process throughout organization.
Level 4 - Wisdom. Detailed metrics are collected and evaluated.
Level 5 - Certainty. Continuous process improvement via metrics feedback.
Wouldnt everyone want to be level 5 , certain their project succeeds?
But isnt agile about people above process?
Doesnt agile tacitly imply that if the people arent good no process is going to save anything?
Certainly there isnt anything in agile that forbids collection of metrics and forbids improvement. Indeed doesnt the automation of everything in sight actually allow you to do this.
But but but and herein lies the problem, the practice of collecting metrics is so perverted (see the timesheets which have a task called filling in timesheet) that almost always means that people will fudge it.
It also looks like agile management consultants have discovered there is money to be made by coaching people to be agile scrum cmmi pcmm bs577 compliant. Or whatever.
So will the agilisits be enlightened? Does a standard process have more value than a tweaked one? Whatever happened to the these are guidelines and must be changed for your project, use whatever works for you?
Sunday, November 19, 2006
Sunday, November 12, 2006
Agile no more
Its amazing to see how developer friendly practices are perverted into management friendly practices as soon as a pack of managers are let loose on them.Right so lets begin at the beginning Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan (http://www.agilemanifesto.org)While we could quible over whether we collaborate with customers or negotiate with them , its fairly reasonable to assume that no software engineer is going to disagree with the spirit of what was said here.All of the above principles are developer friendly. No more follow that CMM level 5 process, No more according to my project plan we should have finished 53.23% percent of project. are we there yet?But look agile has crossed the chasm and what do we haveAgile consultants who have the "you must tailor agile to meet your needs" that means you need an agile coach or a scrum master whatnot because evidently if you tried to do it yourself your project would fail because you would do agile wrong.Oh look agile projects do need management. And it must be something new otherwise how would we consultants ever earn money?Heres a new management technique. Lets call it Scrum. We cant obviously have a position called Project Manager , lets call it scrum master. Lets not call it a requirements document, lets call it a product backlog. Lets not call it an iteration , lets call it a sprint. Oh yes how about burndown charts, yep sounds like something people would pay money to be taught what it is. Oh and wait we need to know what our teammates are upto every minute. Lets ask for status updates every day. Oh and we need to have data on the minutest of things. Hmm we cant call it a timesheet but we'll make them fill up the hours for every minute task and we'll make them constantly reestimate each task.Ok so thats an exaggeration.But think about it. Say the functionality on a website was show orders for a user. What would a developer say (lets assume the overall architecture and software and platforms have been decided). Mostly something like ok it would take about a week for me to do it. If you fell behind you 'd sit up for 2 hours more if you were ahead you'd quit and go home early. In about a week you'd be done if you were reasonably competent. Developer friendly? Id think so. if there were problem you'd escalate as soon as you knew of it. If the problem was technical you'd ask your peers at lunch or tea.But thats not what's being practised.1 week as a coarse estimate wont do any more. You have to provide finer tasks so that you know if you are in red. You have to track at an hour basis for the tasks. You have to give an update every day. You have to work uniformly for 8 hours every day because supposedly that increases productivity. Bah. Anyone who's coded knows that if the problem is interesting and you've started on it , you wont stop unless you've solved the problem Or atleast its that way for some people.Not all people are alike.And so we come to the original manifesto. For the agile projectsIs it individual and interactions over processes and tools ? Probably not. look around the debates in agile . To pair program or not to (process) , to TDD or not to (process), unit test all code (process), daily standup calls(process), use wiki for collaboration (tool), use junit(tool) etc etc
Working software over comprehensive documentation ? Product/Sprint Backlogs, Burn down charts, User stories (all documentation)
Customer collaboration over contract negotiation ? Ambiguous at best. And certainly i have yet to see any agile consultants who havent negotiated contracts.
Responding to change over following a plan? No more and no less than before, perhaps evidenced by the fact that the manifesto is signed in 2001 and 5 years hence there has been no change to it. Lessons learnt in the 5 years have definitely not caused the manifesto to change. Rather any failures are met with the standard "you arent doing it right"
Perhaps the problem is in the first item in the process. Individuals. And individuals are flawed and biased.
Working software over comprehensive documentation ? Product/Sprint Backlogs, Burn down charts, User stories (all documentation)
Customer collaboration over contract negotiation ? Ambiguous at best. And certainly i have yet to see any agile consultants who havent negotiated contracts.
Responding to change over following a plan? No more and no less than before, perhaps evidenced by the fact that the manifesto is signed in 2001 and 5 years hence there has been no change to it. Lessons learnt in the 5 years have definitely not caused the manifesto to change. Rather any failures are met with the standard "you arent doing it right"
Perhaps the problem is in the first item in the process. Individuals. And individuals are flawed and biased.
Sunday, August 27, 2006
More Agile
Burst out laughing when I read
“Soon all of our singletons were composite, we could use the factory method on our abstract factory to get the prototype of the builder which would make a proxy for the decorated adapter that acted as a facade for the visitor which took us to see all of our singletons”- http://jroller.com/page/rolsen?entry=turn_it_up_to_11
Since it reminds me of a certain project I was in where the chief designers had obviously come out of a design patterns course and so there were *Factory aplenty which then lead to the creation of a class named FactoryFactory and the clients of this API who ofcourse had their own factory came up with FactoryFactoryFactory. Ok the last class is fictional , but the one before that is an actual class.
And so yes the latest rage is Agile and Scrums and what nots. I remember reading Kent Beck’s book on extreme programming about 5 years ago when agile had not yet caught up here in India, agreeing vehemently on the accept change and disagreeing just as vehemently on pair programming (some people interpret this as side by side programming, a practice I wholeheartedly endorse , and not just for technical reasons, its how I met my wife to be :-) )
As the years went by and I saw more and more of the strict waterfall model , the im not going to start design till requirements are signed of, im not going to start development till design is signed off, I realized the agilest were right , waterfall like practices are no way to run a project. Agile was the way to go. And though we didn’t practice all the various XP practices or Scrum or whatever, most projects I worked on were pretty much flexible, with changes being accepted after the date for code freeze (which magically thawed)
Oh just to clarify , we are a service/project oriented organization , providing services to various clients. The client I work with now has decided to go Agile in a major way and to impress the client agile training is now mandatory for everyone in our group in our organization. And ive kept up with some of the articles that the agilists keep publishing. And so the inevitable conclusion. There is no practice in the world that people cant screw up.
So lets see where do we start.
First the proponents of agile itself. While they make the right noises (Each process must be tailored to what works for you), the answers given most of the time is ,(to quote cedric beust) “if you aren’t getting benefits from agile , you aren’t doing it right.”
Second the insistence by some on absolutely silly practices. Like Code the test first before you write the code. I cant and don’t want to code tests that don’t bloody well compile , I have to define the interfaces and classes implementing those first atleast! Though of course testing is good , automated tests are better, unit tests are ok, mock tests are ok, Integration tests are worth their value in gold. But try getting some agilist to talk about tests other than unit tests.
Then we have the silly rules that follow from the above. You must have 90% coverage in your tests cases, otherwise code is rejected. Heres a thought experiment. Write a function doubleIt , return the value 4 always and write a test case which passes in the value 2. You have voila 100% coverage. Beat that. No need to write more tests. If you impose silly rules , developers will work around them.
And then we have the other problems. Daily status calls, not exceeding 15 mins. Must be at the start of the day. Ok cool. Umm the delivery head is US based, the customer in UK and the dev team in India. Whats the start of the day? Oh agile doesn’t work so well for distributed teams! Well what do I do then go back to waterfall? Stupid.
And the ofcourse the famous if you aren’t doing practice x, you aren’t agile.
I think I prefer the time when in a project of duration of 1 month you could relax for 15 days and then work double for the next 15 instead of work uniformly for the 30 days.
Though people may say that quality in the latter case is better, I don’t think that’s necessary.
I don’t think agile works in the real world. Distributed teams are a fact of life. Multi vendor projects with conflicting interests are a fact of life too. I suppose agile would work with a closely knit team. But that’s fast becoming an exception in the areas we work.
And with new processes and positions (like agile coach) the Agile methodology is becoming as rigid as the other processes.
And a final thought whats remained the rule in software , good people can make any process work, incompetents can make any process fail.
“Soon all of our singletons were composite, we could use the factory method on our abstract factory to get the prototype of the builder which would make a proxy for the decorated adapter that acted as a facade for the visitor which took us to see all of our singletons”- http://jroller.com/page/rolsen?entry=turn_it_up_to_11
Since it reminds me of a certain project I was in where the chief designers had obviously come out of a design patterns course and so there were *Factory aplenty which then lead to the creation of a class named FactoryFactory and the clients of this API who ofcourse had their own factory came up with FactoryFactoryFactory. Ok the last class is fictional , but the one before that is an actual class.
And so yes the latest rage is Agile and Scrums and what nots. I remember reading Kent Beck’s book on extreme programming about 5 years ago when agile had not yet caught up here in India, agreeing vehemently on the accept change and disagreeing just as vehemently on pair programming (some people interpret this as side by side programming, a practice I wholeheartedly endorse , and not just for technical reasons, its how I met my wife to be :-) )
As the years went by and I saw more and more of the strict waterfall model , the im not going to start design till requirements are signed of, im not going to start development till design is signed off, I realized the agilest were right , waterfall like practices are no way to run a project. Agile was the way to go. And though we didn’t practice all the various XP practices or Scrum or whatever, most projects I worked on were pretty much flexible, with changes being accepted after the date for code freeze (which magically thawed)
Oh just to clarify , we are a service/project oriented organization , providing services to various clients. The client I work with now has decided to go Agile in a major way and to impress the client agile training is now mandatory for everyone in our group in our organization. And ive kept up with some of the articles that the agilists keep publishing. And so the inevitable conclusion. There is no practice in the world that people cant screw up.
So lets see where do we start.
First the proponents of agile itself. While they make the right noises (Each process must be tailored to what works for you), the answers given most of the time is ,(to quote cedric beust) “if you aren’t getting benefits from agile , you aren’t doing it right.”
Second the insistence by some on absolutely silly practices. Like Code the test first before you write the code. I cant and don’t want to code tests that don’t bloody well compile , I have to define the interfaces and classes implementing those first atleast! Though of course testing is good , automated tests are better, unit tests are ok, mock tests are ok, Integration tests are worth their value in gold. But try getting some agilist to talk about tests other than unit tests.
Then we have the silly rules that follow from the above. You must have 90% coverage in your tests cases, otherwise code is rejected. Heres a thought experiment. Write a function doubleIt , return the value 4 always and write a test case which passes in the value 2. You have voila 100% coverage. Beat that. No need to write more tests. If you impose silly rules , developers will work around them.
And then we have the other problems. Daily status calls, not exceeding 15 mins. Must be at the start of the day. Ok cool. Umm the delivery head is US based, the customer in UK and the dev team in India. Whats the start of the day? Oh agile doesn’t work so well for distributed teams! Well what do I do then go back to waterfall? Stupid.
And the ofcourse the famous if you aren’t doing practice x, you aren’t agile.
I think I prefer the time when in a project of duration of 1 month you could relax for 15 days and then work double for the next 15 instead of work uniformly for the 30 days.
Though people may say that quality in the latter case is better, I don’t think that’s necessary.
I don’t think agile works in the real world. Distributed teams are a fact of life. Multi vendor projects with conflicting interests are a fact of life too. I suppose agile would work with a closely knit team. But that’s fast becoming an exception in the areas we work.
And with new processes and positions (like agile coach) the Agile methodology is becoming as rigid as the other processes.
And a final thought whats remained the rule in software , good people can make any process work, incompetents can make any process fail.
Sunday, June 04, 2006
Agile
The other day I got a ppt from a friend who got it from someone else about a project in my company which is a “success” because how they implemented “agile methodologies” and how it helped and the practices they followed with general patting of backs and lessons learnt and improvements still to be made.
It’s a 75 slide power point.
Get the picture?
Or lets see the Extreme programming principles. On one hand embrace change and on the other you must follow x,y,z to have a successful project(with no guarantees of success). What happens if you don’t pair program or do test driven development or whatever else is the latest breakthough in software engg? Is it that you don’t embrace change?
I think agile is best described by uncle bob , “never be blocked”. And once you accept that, the agile manifestos, the programming principles the slide guides aren’t all that necessary. True they might help, but the problem is any rigid process (agile extreme or otherwise) causes blocks.
Write junits for everything. Unit test are really low value for money. Integration tests are very hard( especially if it’s a distributed system, developed by multiple disparate teams )over space and time. All the wonderful stubs and mocks so loved by the TDD guys fail when the stub and mocks are replaced by the actual system. Which isn’t to say stubs aren’t good, but they give you a false sense of security. And can hide flaws. For e.g. There was a defined web service interface. It wasn’t ready we mocked it. All was well. Till we ran it with real data. Turns out we get stuff like ##YOUSHOULDNTSEETHIS## the xml structure is the same , the web service has the same interface but surprisingly none of us thought to write stubs and mocks that returned elements with junk values.Or what to do in that case or even how to identify them.
You can and should violate principles if the need arises. That’s agile. Embrace change. a
It’s a 75 slide power point.
Get the picture?
Or lets see the Extreme programming principles. On one hand embrace change and on the other you must follow x,y,z to have a successful project(with no guarantees of success). What happens if you don’t pair program or do test driven development or whatever else is the latest breakthough in software engg? Is it that you don’t embrace change?
I think agile is best described by uncle bob , “never be blocked”. And once you accept that, the agile manifestos, the programming principles the slide guides aren’t all that necessary. True they might help, but the problem is any rigid process (agile extreme or otherwise) causes blocks.
Write junits for everything. Unit test are really low value for money. Integration tests are very hard( especially if it’s a distributed system, developed by multiple disparate teams )over space and time. All the wonderful stubs and mocks so loved by the TDD guys fail when the stub and mocks are replaced by the actual system. Which isn’t to say stubs aren’t good, but they give you a false sense of security. And can hide flaws. For e.g. There was a defined web service interface. It wasn’t ready we mocked it. All was well. Till we ran it with real data. Turns out we get stuff like ##YOUSHOULDNTSEETHIS## the xml structure is the same , the web service has the same interface but surprisingly none of us thought to write stubs and mocks that returned elements with junk values.Or what to do in that case or even how to identify them.
You can and should violate principles if the need arises. That’s agile. Embrace change. a
Subscribe to:
Posts (Atom)