Jens Meydam asked “What do you really care about in Scrum?” I decided to answer, instead, “What do you think is really essential in Scrum-style software development?
12/23/2009
Features or Date
Jonathan Rasmussen replied recently to a question on the Scrum list, saying that you can pick your feature set and let the date move, or pick the date and let the features move. Roy Morien asked “Why isn’t this obvious”, noting that it sure seems that people don’t get it.
10/16/2009
The Agile Skills Project
Some good people[1], plus Chet and I, met in Ann Arbor the week of October 12 2009, to discuss Agile Team Member qualification. The outcome: The Agile Skills Project. Read More…»
10/02/2009
Interesting Links
I just thought I’d make a page with links that may be worth exploring. If you have some, let me know. I have not explored all of these, nor, probably, have you. That’s why I’m listing them.
Iteration Burndown Google Spreadsheet
Visual Management Blog. Articles and pictures about managing projects with big visible charts and information radiators.
Why Project Managers Can’t Manage Projects. Interesting David Schmaltz article suggesting that project management is literally impossible.
Technical Debt on Your Balance Sheet. Is it possible to monetize technical debt?
Perfect Example of Certification. Who says certification has no value?
10/02/2009
Evidence about Collocation
Here are a few links relating to collocation, thanks to Adrian Howard and others. If you know of more, let me know, please.
CSCW 2008 Workshop: Supporting Distributed Team Work
RE challenges in multi-site software development organisations
An empirical study of global software development: distance and speed
Team Knowledge and Coordination in
Geographically Distributed Software Development
Team Knowledge and Coordination in
Geographically Distributed Software Development
How Does Radical Collocation Help a Team Succeed?
09/28/2009
Agile Team Skills Workshop
Things in the skills development area have changed in some
interesting ways. We have room for a few more people who want to contribute to our proposed session in Ann Arbor.
The workshop schedule has been changed owing to changes in the environment. It will be held for three days, Tuesday October 13 through Thursday October 15, in Ann Arbor. There is no charge for the workshop, and you’re on your own for travel and housing.
As this will be a workshop, it isn’t possible to predict exactly what will happen. Our purposes include, but are not limited to:
Gain a deeper understanding of the dimensions of skill required of team members on Agile projects;
Elaborate and/or modify the “Seven Pillars” idea to define a framework for team member education for Agile projects.
Discuss and consider recommendations to Scrum Alliance, Agile Alliance, and the universe at large regarding team member education for Agile projects.
Discuss and consider group and individual actions regarding the scrum.org and related developments. Decide how we should speak to this issue, and where, so as to guide the community in the best possible direction.
Discuss and/or demonstrate specific training examples or course materials.
Things in the skills development area have changed in some interesting ways. We have room for a few more people who want to contribute to our proposed session in Ann Arbor.
The workshop schedule has been changed owing to changes in the environment. It will be held for three days, Tuesday October 13 through Thursday October 15, in Ann Arbor. There is no charge for the workshop, and you’re on your own for travel and housing.
As this will be a workshop, it isn’t possible to predict exactly what will happen. Our purposes include, but are not limited to:
- Gain a deeper understanding of the dimensions of skill required of team members on Agile projects;
- Elaborate and/or modify the “Seven Pillars” idea to define a framework for team member education for Agile projects.
- Discuss and consider recommendations to Scrum Alliance, Agile Alliance, and the universe at large regarding team member education for Agile projects.
- Discuss and consider group and individual actions regarding the scrum.org and related developments. Decide how we should speak to this issue, and where, so as to guide the community in the best possible direction.
- Discuss and/or demonstrate specific training examples or course materials.
If you would like to attend, and can make a firm commitment, please write an email to Chet’s training address, training@hendricksonXP.com. We’ll have light continental breakfast and snacks, we’ll be on our own for lunch, and travel and accommodations are up to you. We have arranged for discounted rooms: we’ll let you know when you sign up, and here are the links. (Please don’t sign up for a room until you know whether we are able to accomodate you in the sessions. King Room. Double Room.)
09/10/2009
Developer Certification
Scrum luminaries freely grant the necessity for good developer practices, and the Scrum Alliance is thinking about developer certification. Some important people in the community are involved, and so am I. Read on …
Schedule changed, see new post.
Ken Schwaber, co-creator of Scrum, says publicly that perhaps only 25% of Scrum teams get the full benefit of Scrum. Jeff Sutherland, the other co-creator, says publicly that all the high-performance Scrum teams he has seen used XP-style practices.
In those two sentences, we see a problem, and part of a solution. Ken Schwaber has the Scrum Alliance working on a possible “Certified Scrum Developer” program. One thread of work on that involves Chet Hendrickson, Brian Marick, Bob Martin, and Jim Shore. I’m in there as well. Recently Elisabeth Hendrickson has been helping also.
You might be thinking that certification is evil and/or stupid, and therefore why are these people involved in such an evil and stupid thing. For me, my thought is that if certification is to happen, I’d like to try to guide it to be as good and as smart as possible.
The people listed above have corresponded and there was a meeting in Chicago, where we listed seven areas where a development team member needs high skills in order for a team to really rock. We put all that information on a Google group, Agile Developer Skills.
We’re inviting you to join that group. New members will be able to read and post to the general list, and if you want to create and edit documents you’ll need to be approved for that. If you want to contribute–not quite the same as rant–please sign up and help us.
In addition, Chet and I are planning a small no-cost workshop in Ann Arbor, October 12-15, at the Ann Arbor Courtyard by Marriott at 3205 Boardwalk. We’ll be test-flying our presentation and material on the subject, and we expect lots of discussion with attendees on the whole subject of whether and how to certify members of the development team.
We can accommodate around 12 people, so if you would like to attend, and can make a firm commitment, please write an email to Chet’s training address, training@hendricksonXP.com. We’ll have light continental breakfast and snacks, we’ll be on our own for lunch, and travel and accommodations are up to you. We have arranged for discounted rooms: we’ll let you know when you sign up, and here are the links. (Please don’t sign up for a room until you know whether we are able to accomodate you in the sessions. King Room. Double Room.)
We’d like to get people who are passionate about excellence, and interested in what, if anything, should be done about certification.
Comments welcome.
09/08/2009
Watering Things Down Is Not Good For The Plants
Extreme Programming used to have a very specific meaning. It still has a fairly specific meaning. Scrum still has a fairly specific meaning. It, too, has drifted a bit over time. It is natural that terms drift a bit as we learn.
TDD, Test-Driven Development, has started out with a very specific meaning, concerning a programmer or pair writing a single test at a time, and making it run, on a very short cycle, as short as ten minutes or less.
Part of the value of TDD is that it makes the programmer’s intentions clear to her–and to her colleagues who may read the tests and code later. Clear intentions are great, and there are other places where teams may really need them. One of these is in the relationship between Customer (Product Owner) and developers.
On struggling or learning teams, we often see the Customer come in with a vague story, talk about it for a while and set the developers to doing it. When they come back, the Customer says “That’s not what I said,” and the developers say “It bloody well is what you said,” and trouble ensues. It really doesn’t matter whether the Customer said it right and the developers got it wrong, or whether the Customer said it wrong, or whether the Customer has changed his mind. It’s irritating and wasteful in any case.
The standard corrective action for this situation is to express requirements in part with examples. See, for example, the Card, Conversation, Confirmation article from ever so long ago. The Confirmation part is about examples showing how the system should work. It works best, by far, if these examples are executable.
This is clearly the same basic idea as TDD, only written larger. It’s a good thing to apply this kind of thinking at all levels. I’m all for it.
However, let’s not call every ****ing occurance of calling our shot and then executing it TDD.
We did that with Agile. The term “Agile” was vague at the beginning, as an umbrella term covering many methods. It is now watered down to the point where to people who care, a project calling itself “Agile” is assumed to be messed up, and it usually is.
Let’s not water down yet another term. It’s not good for us.