“Computers must support the way in which people naturally and comfortably work. This is needed both for personal job satisfaction and for corporate survival. I care about whether the team is thriving, and whether the software is being delivered. Keeping the people trained and the process light are key to both.”
| | This site is here to act as a watering hole for people with interests in these topics, with hopes that you get pleasantly lost browsing the content :-) |
Dr. Cockburn (pronounced Co-burn, the Scottish way) is an internationally renowned project witchdoctor and IT strategist, best known for describing Software development as a Cooperative Game (discussion: Re: Cooperative game manifesto for software development), for helping craft the Agile Development Manifesto, for finally defining Use Cases (discussion: Re: Use cases) and for developing the initial response technique relaxation/massage form.
Humans and Technology, Inc.
44 W. Broadway, #1601
Salt Lake City, UT 84101
801.824-1211
mailto:TotherAlistair@aol.com
Most recent changes to this site:
An alternate photo of me:
Hi, Atalichome — I moved your question to Use case questions (discussion: Re: Use case questions) where I answered it.
All the best – Alistair
I am battling with one central problem in agile: how do you remain “agile” and open to change when you’re working against a fixed budget and defined scope, and a customer who is not a “software person”.
We use an adapted version of SCRUM for web development, which is part-software and part-design. Our customers have only a limited interest in being involved in the project. They want x by x date. But they also want to make changes along the way.
So do you baseline the project against the original scope document? And then measure each change impact on the budget?
It’s driving me kind of nuts — how can you merge an agile process with a non-agile budget?
-by Jarred Cinman on 11/25/2009 at 1:38 PM
I think
Earned-value and burn charts and
http://en.wikipedia.org/wiki/Project_triangle might help you.
Also: don’t be afraid to say “no” to the customer. Every time you say “yes” to the customer you lose a bit of control over the project. If you say “yes” too much the project will spin out of control.
-by Floyd on 11/26/2009 at 7:18 AM
I recently read about this new agile methodology (well, again calling Agile a methodology itself may be problematic … anyways) ... its called PLAY BALL!
I read it twice and kind of think it is nothing but a modified version of Scrum and a little hypothetical in terms of 9 innings and all. Wanted to know your view point on the same.
-by Dinesh Madne on 12/24/2009 at 8:26 AM
Have you considered how Eliyahu Goldratt’s Theory of Contraints might be applied to Lean Manufacturing to try and increase the overall throughput of a software development organization? Just curious.
David
-by David Douglas on 1/29/2010 at 2:55 PM
Yes, indeed —- see
"Spending" Efficiency to Go Faster, which does just that.
cheers – Alistair
-by Alistair on 1/30/2010 at 11:46 AM
Wondefull way how you describe the use cases, in your book, it is the only place where I have found a natural, clear, objetive and well description.
Success in your bussiness
Jorge
-by j.m on 2/17/2010 at 3:27 PM
Hi:
What are your undergraduate degrees?
From which institution did you receive your doctorate and what was the subject of your dissertation?
Regards,
Zarfman
-by Zarfman on 3/9/2010 at 10:12 PM