Friday, November 28, 2008

Kanban Conference Early Announcement

I am going to organize a small kanban conference. It’s going to be on the week of February 16th in Miami, Florida. The dates are provisionally February 18th and 19th. The venue and pricing are yet to announced. I’m hoping to keep the pricing very low and get some sponsorship from a few well known vendors/consulting firms in the agile community. The dates may move slightly depending on the chosen venue. Anyone booking travel to Miami now should be safe if they assume a flight home late on the 21st or on the 22nd.

I need input from you if you plan to attend. Firstly, I need details on numbers. I initially envisaged an open space event for perhaps 20 of the folks on the kanbandev Yahoo! group. However, judging by the responses to my tweet and my post on the group, I’m now thinking between 50 and 100 people. So if you plan to attend, please email me or leave a comment.

I also need input on the format of the event. Several people emailing their intent to attend have suggest they want to present or that they want to hear case study presentations. I’m now thinking day 1 would be a couple of key notes - one from me - one from someone else with a solid background in Lean - to be announced. These would be followed by a series of theory and case study presentation. Potentially two tracks - one on theory - one on case studies. Would you prefer one track or more than one track. On the second day, I am proposing we do open space for perhaps two thirds of the day and then have some closing presentations for the open space facilitators. Please leave comments with your thoughts and suggestions.

More details will be announced as soon as I have them… Technorati tag: David+Anderson, Agile+Management, Agile, Lean, kanban

Wednesday, November 26, 2008

Trashing Scrum or Reflecting Reality?

Tobias Mayer thinks the Lean folks in our community have been trashing scrum!

While his criticism was aimed at Mary Poppendieck, others associated with Lean in software development, most notably Alan Shalloway and I have said things that the Scrum community don’t like. So I think it worth expressing my point of view on this.

For 6 years, since I developed the manuscript for my book, I’ve been saying that Scrum is a useful process that helps immature teams achieve success. However, it only takes them so far and that more is needed if they are to keep improving. Based primarily on the available literature at the time - 2002 - I observed that Scrum is designed at the practice level to eliminate a lot of external variability that affects the performance of most development teams. As such, this recipe of practices, or prescription will have a quick positive effect on performance, but without a true focus on organization level continuous improvement and cultural change, it will fail to generate further improvements. The result will be a [more or less] unit step improvement in productivity and reliability [and possibly quality]. The Scrum community doesn’t like this observation.

However, many of us working in the field find senior people in large companies telling us - we’ve tried Scrum and it worked for a while but now we are looking for what is next, for the thing that will take us to the next level. This isn’t an issolated comment. And those saying it are not critical of Scrum. They simply recognize that it gave them a boost in performance and reliability and now they need something more to continue improving. While the leaders in the Scrum community like to promote the concept of a culture of continuous improvement, Scrum does not appear to have enough depth in its guidance, literature, training and coaching to get teams there. Perhaps these teams are amongst the teams that Ken Schwaber describes as having “failed with Scrum.” If that’s true then as Alan Shalloway suggested, Scrum is failing us. If what it takes to really do Scrum right, you need Jeff Sutherland or one of his folks to be present, then more work is needed - more guidance, more depth, more theory, more practices. The literature simply leaves too much as an exercise for the reader.

Jeff Sutherland has been the voice of reason in the Scrum community over the years. He has been the one talking about the challenge of achieving hyper-productivity [4x productivity improvements] and the one publishing metrics. It turns out that few Scrum teams achieve the hyper-productivity and of those who do when you look at the absolute numbers the performance is good but not stellar. Again, this reflected an observation I made years ago, that many agile teams were anecdotally reporting relative improvement but not absolute numbers for productivity or quality. I strongly suspected that FDD teams were out-performing many other agile teams significantly and this turned out to be a correct assumption when years later metrics began to appear. Even the original FDD team in Singapore building a huge enterprise system produced productivity at the higher end of scale that Sutherland reports. The team at Motorola that I was running, particularly on the OTA Device Management project exceeded the productivity of the Borland Quattro Pro project that Jeff likes to quote as one of the best ever and not only did we have the code production metrics, we also had the initial quality as escaped defects to system test numbers. Both were in the 99th percentile for the industry. It’s only recently that, as a community, we’ve started to have an open debate about absolute performance of agile teams and look at what truly affects performance. What’s driving this is enterprise scale adoption. It is no co-incidence that big corporations want to see productivity data. So while, Scrum has clearly helped a lot of teams improve and the relative improvements have often been enthusiastically received, the absolute numbers, seem to imply that more is needed. As Tobias reports Mary Poppendieck reflecting on Jeff Sutherland’s approach, Jeff does more. He includes many software engineering and risk management practices that in my observation improve the organizational maturity and ultimately produce significant productivity improvements that are remarkable in absolute terms, not just in relative terms. I often lament that Jeff Sutherland has not written a book.

Apparently, trying to have this kind of rational discussion about Scrum and its practices is unacceptable. The Scrum community doesn’t want to hear anything other than “Scrum is great!” and “Scrum is the answer to all problems.” Any form of discussion or debate is regarded as dissent. This leads me nicely to my second observation…

My second observation about Scrum relates to the community itself. In recent years, any form of debate that suggesting there may be challenges with Scrum or implementing it has been rooted out and abolished. There were several public ex-communications from the Scrum Yahoo! group including prominent figures like Scott Ambler and Alan Shalloway. Others like me, were warned off by Ken Schwaber and chose not to participate further. My observation from the outside is that the Scrum community reflects the antithesis of our agile values. It is run from the top. The message is strictly controlled. Dissent is not permitted. It resembles a cult of personality and appears to be the very definition of command’n'control in its execution. Speaking from my own experience forming the APLN, we were very conscious that we must create an agile organization that truly reflected the values that we espoused. So we created an organization that encouraged spontaneous affiliation, encouraged diversity, had a small government run at almost no cost, requiring no annual fee, that encouraged innovation and dictates no rules to members or local chapters. If you are trying to create a culture where people feel free to speak up and raise issues at daily scrums, I cannot see how this is possible, when the organization doing the coaching discourages any form of dissent.

So when you hear someone from the Scrum Alliance accusing others of trashing Scrum look deeper. Apparently, if you say, Scrum really helped a whole bunch of projects, teams and companies improve productivity and reliability on project delivery, but the improvements topped out and now they need something more to really keep moving you , are trashing Scrum. This leads me to the conclusion that if Scrum is so easily trashed, how can it have any real substance or worth? If the leaders in the Scrum community truly believe in its worth and value then they should show some maturity and open themselves to constructive professional objective debate.

Related articles: Why we lost focus on development practices Technorati tag: David+Anderson, Agile+Management, Agile, Lean, Scrum, Extreme+Programming

Why We Lost Focus on Development Practices

This is the first of two responses to Tobias Mayer’s Getting Trashed by the Lean Machine, his reaction to the panel session at the Agile conference in Buenos Aires last month. This first response deals specifically with the interaction between Tobias and Micah Martin, and Micah’s comments which I copy here for convenience…

[...] My frustration is not specifically with Scrum but with the diminished focus on software in the Agile community. As Agile has grown it has become more of a project management topic rather than a software development topic. For good or bad, Scrum is the most prominent face of Agile project management and so it gets the blame. [...]

I’ve heard this sentiment a lot recently at conferences from the programming focused folks. The key problem is that their locus of interest surrounds programming and they want to be part of a community inventing better ways of developing software (in the tightest definition meaning programming). Meanwhile, many of us in the agile community are interested in better ways of developing software [projects and product]. This second interpretation of the purpose behind the Agile Manifesto leads us to look at whatever constrains our ability to deliver projects and products better, faster, cheaper, and with higher quality and higher value.

It’s understandable that many developers want a focus on their own craft. And it is understandable that without this they quickly lose interest. As Tom DeMarco wrote, they are Dilbert delegating responsibility for their success to someone else. It’s the blinkers on, just leave me alone to do my thing, approach.

While I have an solid belief that there is a lot more we have to learn about programming and software architecture and engineering, the reason the community has lost its focus on this activity is easily explained. Programming and programmers are not the constraining factor on improved performance!

In my Zen of Agile Management class, I teach participants about constraints. I then ask them, in a collaborative exercise, to speculate about the bottleneck in their organization and discuss how they would prove it and what they would do about it. In almost 3 years of teaching this class, over 4 continents, and around 12 occassions with groups ranging from 16 people to 250 people (at Javapolis in 2007), I have concluded that developers are the constraining factor on project and team performance less than 10% of the time. In some groups it is as low as 3%.

My belief around this is quite simple. Basic agile practices focusing on quality including collaborative working such as pair programming, and a strong focus on unit testing and early defect detection with continuous integration and test automation, have greatly improved software development to the point where initial software quality (i.e. bug insertion rates) is not the constraining factor on team performance. With immature teams, with sloppy development practices and poor initial quality (i.e. high defect insertion rates) development is the constraint. Agile has successfully fixed this!

So we can declare victory!

In this sense, the crowd who argue for a continued focus on better development practices are fighting the last war.

The rest of the community moved to other areas - most notably project management and business analysis / value-based software engineering. The community tends to get sucked to where the constraining problems are occurring. This is the natural and correct behavior. And it shows that many in the community interpret better ways of developing software in the broad sense rather than the narrow programming-centric sense.

So what next for the purely coding-centric minds in the community? I would encourage them to keep at it. As the wider community fixes the issues with project management, analysis and requirements, and improves the flow of value, the focus will swing back to engineering/development practices. In the case study from XIT, I show how we improved the productivity of a team at Microsoft by more than 3x and shortened their lead time by 90%. All of this was achieved without making any changes to how software was developed or tested. It was achieved by focusing on the bottlenecks  and the waste and eliminating them. What would it take to further improve the performance of that team? A renewed focus on development and testing practices.

So I truly believe the community will swing back to the developers and the testers. Meanwhile, they need to be patient. It’s a compliment not to be the focus of attention. It reflects success. Embrace that success and stop complaining! Technorati tag: David+Anderson, Agile+Management, Agile, Lean, Scrum, Extreme+Programming

Wednesday, November 19, 2008

Tech Program for SEPG North America 2009 Announced

I’ll be giving three sessions at SEPG North America in San Jose in March. One on agile metrics for quantitative management (i.e. model level 4) another the other on building a culture for high maturity (model levels 4 & 5) with kanban and teaming up with Mike Konrad and the gang to talk about the new Technical Note, CMMI and Agile: Why not embrace both! The program also includes a key note from Alistair Cockburn and a considerable amount of Agile+CMMI material from folks like Nelson Perez, Corey Ladas, Christian Hertneck, Hillel Glazer, Jeff Dalton. This is the year of Agile and CMMI and the two camps coming together. I would really like to see a significant turn out of agile folks at the SEPG in 2009. Open your mind to the idea that organizational maturity matters and that the SEI has a contribution to make that can help us all succeed. Take a look at the program for the event. Hope to see some of you there.

Technorati tag: Agile, CMMI, SEPG, SEI, Carnegie+Mellon, Software+Engineering+Institute

CMMI and Agile paper causing a stir

The new Technical Note from the SEI which I co-authored has been causing a stir. My friend Adail Retamal has translated some of the somehwat cynical commentary from Brazilian agile and XP discussion lists. I’m excited to see so much debate on this and read these wonderfully creative comments…

Well, after some have found the Agile CMMI idea nice (this is a sign of the end times) , I can only propose an AgileWaterfall 2009 conference.

Some of the themes could be:
- Agility and Bureaucracy: get the best of both
- Waterfall made Agile: just burn out the documentation
- Agility with Control: Henry Ford has done it a century ago!
- XMMI (eXtreme CMMI): the 12 practices revisited under CMMI
- The CMMA Model: How Agile are You?

See how the first XCMMI practice would look like:

Pair Everything: Why only pair programming? Let’s expand this agile
practice: Pair Analysis, Pair Design, Pair Project Monitoring and
Control, Pair Requirements Management, Pair Organization Process
Definition, Pair Quantitative Project Management, Pair Decision
Analysis and Resolution, etc. As you can see, with XCMMI, we have a
lot more pairs than with the regular XP.

If you send me enough good ideas, we’ll even build a site like the waterfall’2006.

——————————————————-

hehehe “Pair Decision Analysis and Resolution”

Some other ideas:
- Taskboard CMMI: all your documents printed and exposed on a white board visible to everyone.
- Daily meetings: 15 minutes every day… for every process.
- Chart burndown. Let’s show all the metrics in a bunch of burndowns!

And so on :D

——————————————————-

Extreme Waterfall:

Just 4 Values, 12 Practices, 5 Years and 12 million dollars!

Values (aka, The Cobra Kai system):

Fear - code is dangerous, code is your enemy. Run away or hide from
code if you can. If you can’t, pray. Pray VERY hard.

Silence - it is golden, gold means money and money is good. If you
can’t say anything good about the system, shut up. We don’t need your
negativism!

Aim - measure a thousand times and cut once. After all, systems are
very much like diamonds!

Practices

Stand-Up Coding: coding 15 minutes a day keeps tendinitis away.
Feudal CodeBase - Be the Lord of Thy Land, keep invaders at bay,
punish trespassers.
Weekly Iterations - based on Pluto’s calendar.
40-Hour Weekend - times flies with pizza and cola!
Lego Design - 5 generic components is all you need to build any
system. Take a look at Assembly. Technorati tag: David+Anderson, agile+management, CMMI