Man’s mind, once stretched by a new idea, never regains its original dimension.
Agile Management
Real Options Get Together
Announcing Lean Kanban 2009 Conference
Due to demand from members of the kanbandev group I have created a Lean Kanban conference to bring together the community to discuss and extend the state-of-the-art in using Lean and Kanban in software development and full project lifecycle management.
Registration is now open http://www.leankanbanconference.com/
Download Draft Agenda and Promotional Flyer (PDFs)
The event is limited to 125 folks. We expect it to sell out. We've selected a superb venue the Mandarin Oriental Miami located on South Beach at Brickell Quay right on the water.
http://www.mandarinoriental.com/miami/
Because of committed sponsors like Net Objectives and Ultimate Software we are able to keep the registration fee down to only $800 per person for the full 2.5 day event. Registration includes an invite to our evening reception on February 18th courtesy of Ultimate Software. Breakfast and coffee breaks are included all 3 days. Lunch is included on Wednesday and Thursday 18th and 19th.
Wednesday 18th February - Keynote Alan Shalloway - Lean Track and Kanban Track sessions
Thursday 19th February - Keynote Don Reinertsen - followed by Open Space all day
Friday 20th February - Keynote David J. Anderson - followed Lightning talks for 2 hours
Please register now to avoid disappointment and book your flights to Miami. Please be sure to make a reservation with the hotel. Ask for the "David J. Anderson & Associates" event rate of $250 per night. The hotel has indicated that it will honor this rate for extended bookings prior or post the event subject to availability.
Our confirmed speakers are:
David J. Anderson
Alan Shalloway
Dean Leffingwell
Don Reinertsen
Peter Middleton
James Sutton
Clinton Keith
Amit Rathore
Corey Ladas
Karl Scotland
Eric Landes
Eric Willeke
Reni Elisabeth Phil Friis
Alisson Vale
David Laribee
Linda Cook (with Max Keeler)
Many of these people are regular contributors to the kanbandev group and havetogether created and lead the kanban movement over the last 18 months.I believe this is the finest list of proponents of Lean software development ever assembled.
With our 2.5 day format, we have one day of sessions in two tracks, one day of open space and half a day of lightning talks. This will give all attendees the chance to work with the experts directly. I look forward to welcoming you to Miami in February. Technorati tag: David+Anderson, Agile+Management, Agile, Lean, kanban, Alan+Shalloway, Don+Reinertsen, Dean+Leffingwell
Scott Ambler reviews CMMI+Agile Technical Note
Agile 2009 - FDD anyone?...
Eric Willeke and Karl Scotland have been on Twitter overnight suggesting they'd like to see FDD content presented at Agile 2009.
Recently there has been renewed interest in FDD from the BDD/Feature Injection community in London (Liz Keogh, Chris Matts). There is also growing interest in domain-driven approaches to design and development and this has renewed interest in color modeling.
If I see sufficient demand I will prod some FDD folks such as Stephen Palmer, Daniel Vacanti and others and see if we can get a couple of submissions together.
What specific aspects of FDD would you like highlighted and why do you think it would be interesting? On hhich stage at Agile 2009 should FDD appear? Strangely it feels like an Agile Frontier topic because it is fringe, slow burning and unfashionable but that is so weird for what was one of the original agile methods. Technorati tag: Agile+2009, Agile+Alliance, FDD, Feature+Driven+Development, Domain+Driven+Design, Color+Modeling, Peter+Coad
Karl Scotland Discusses Required Level of Maturity for Kanban
Nice article from Karl Scotland on why Kanban isn't just for mature teams. I particularly like his conclusion...
It seems to me that there is in fact a subtle difference between kanban and typical agile processes such as Scrum. Scrum focuses on being agile which may (and should) lead to improving. Kanban focuses on improving, which may lead to being agile. However, being agile itself is not important - it just happens to be the best way we (or at least I) know at the moment. If a team improves in other ways, then its the improvement that's important.
I would go a little further. Kanban is a way of insuring sustainable pace. Sustainable pace generally means that slack exists in the system. Slack generates opportunities for people to think about the process and what hinders overall team performance. It is this that leads to improvements being implemented.
Kanban also creates a process that visibly exposes bottlenecks, waste and variability. Hence, kanban exposes improvement opportunities at the same time as providing a system with slack that allows people to focus on implementing improvements.
As Karl says, agility is a potential outcome. A culture of continuous improvement (kaizen) is the goal. Technorati tag: Agile+Management, Software+Engineering, David+Anderson, Kanban, Lean, Karl+Scotland
Agile 2009 - Karl Scotland KFC Submission
Agile 2009 Submission - New Approaches in Risk Management
I have decided to show leadership by making a submission to the Agile 2009 conference early. The organizers are very concerned that many folks will leave their submissions until very close to the closing date. The intent of the open review system is to encourage feedback to refine submissions and optimize quality and value of content at the conference.
My submission is about new techniques for risk management that includes influences from lean pull systems (kanban) and real option theory. After some careful consideration of options, I concluded that I had to submit it to the Agile Frontier stage. Please assist and encourage the process by taking the time to review it and provide me with feedback. Thanks.
http://agile2009.agilealliance.com/node/96
If you intend to submit a proposal yourself please do so as soon as possible. Let's make the open review system work properly. Folks who submit early should be most likely to succeed. Technorati tag: Agile+2009, Agile+Alliance, David+Anderson, Project+Management, Portfolio+Management, Risk+Management, Real+Options, Kanban, Lean
Agile Frontier Stage announced for Agile 2009
Thanks to everyone who contributed with comments to my open letter to Johanna and Ahmed. It worked! A new stage has been added to the Agile 2009 program. Olav Maassen and Eric Willeke will coordinate the Agile Frontier. It will be the home for out-of-left field, discontinuous innovations, dissenting voices, unfashionable ideas and slow burning concepts that are developing slowly in our community. Here is an extract from the CFP...
This is a stage for pioneering Agile thoughts, practices, models and questions. It is a place to share emergent, intriguing, minority interest and innovative ideas. It is a home for unfashionable concepts, unpopular ideas and dissenting voices.
It is fertile ground for slow burning, long term ideas, where they can grow and thrive. Ideas like Agile Contracting, which appeared in Breaking Acts last year but is still a minority interest activity very much in its infancy.
The Agile Frontier stage accepts proposals that are new and do not fit into the existing categories. It is the home of every idea for which "people" say "it is not Agile" or "it is just wrong". It is the double black run for your new ideas as a speaker where the audience will challenge you on every aspect. Performances on this stage may illuminate new approaches that will make you question your beliefs or inspire you to try something new. Whatever the specific content is, each session will challenge you to think hard about what you do, whether you're presenting or attending.
Performances on this stage may or may not impact the future direction and maturity of Agile processes. At the same time, it is the place to visit to see what could become hot in the next five years. Technorati tag: Agile+2009, Agile+Chicago, Agile+Alliance, David+Anderson, Eric+Willeke, Olav+Maassen, Johanna+Rothman
Scrumban Book Published
Clarifying People versus Process in Agile Fringe Letter
I spoke with Ahmed Sidky today and his feelings about my open letter advocating for an Agile Fringe. Ahmed feels some folks in the community are misinterpreting my remarks [in the paragraph below] to his detriment. So I feel some clarification is in order.
I find Ahmed's attitude to be academic and unrealistic. It relies on the process and removes focus from the people. His argument that all the submissions for Breaking Acts in 2008 could have been accommodated on other stages might be valid in theory but in practice they would never have been accepted. In the agile community we should know better than this. We value individuals and their interactions more than we value processes and tools. Ahmed is asking me to put my faith in the review process and the online review tool. I prefer to put my faith in human nature. [...]
First let me state that Ahmed has been a keen innovator in our field and a true supporter of innovation and protector of those ideas. He was involved in our agile model evolution discussions at Agile 2008. He truly understood and supported the idea that we needed a more expansive and scientific definition of our agile values that would allow us to recognize new innovative practices as aligned to our underlying agile values. I have every faith that Ahmed wants to see innovation in our community and that it should be present at the Agile 2009 conference.
So moving on to my remarks about people versuses process and tools. These remarks were prompted by this paragraph from a private email from Ahmed to me, Olav Maassen (and others.) I am reprinting this with Ahmed's permission.
I really have a lot faith in our peers that they can spot innovation when they see it. If you look at committees that are in place for each stage - you will see that these are competent professionals who I don't believe have hidden [...] agendas. I believe that if a group of 10 of our peers look at a submission and say it is not suitable for the conference - then that means quite a bit to me. Why would I think that only those handling the Breaking acts stage could "spot" innovation.
There are really two established interpretations of the Agile Manifesto statement that we value "Individuals and Interactions over Processes and Tools."
There is a simplistic interpretation. It is the interpretation that we simply must have good craftsmen and that tacit knowledge transfer will always work best. I feel this is an elitist interpretation. It's exclusive in nature and suggests that only truly great craftsmen (developers) are welcome in the community. It also completely fails to scale beyond teams of 6 to 12. This view outlived its usefulness years ago. Applying the benefits of agile development to enterprise scale problems has been an active topic in the community for 6 years and it simply isn't possible for every IT worker in every enterprise to be a truly great performer.
A second more useful interpretation is that individuals implies psychology and that interactions implies sociology. In other words, we believe that effects of psychology and sociology are much stronger than the effects of processes or tools in determining an outcome, and hence, processes and tools must be designed to accommodate human nature and work with, rather than against, recognized psychological and sociological effects. This is largerly the work we have been doing for the past decade. We've been throwing out old development processes and tools that denied the fundamental human nature of our work and did not adequately reflect the psychology and sociology involved and replacing them with more human friendly processes and tools. Feature Driven Development embraced the idea that we need a solution for large teams and adapt to the psychology of the people on the team. Jeff De Luca's 1st law, "It's 80% Psychology, and 20% Technology."
While I have no doubt that Ahmed has a deep belief in people and their ability to do the right thing, I find his confidence in the correct outcome unrealistic. Ahmed believes that the people will overcome the process and tools (in this case the announced program and the submission and review system) that are by their nature designed to solicit submissions for the topics named in the announced stages, and uses a popular democracy mechanism (albeit an open flavor) to select the winners. He asked the stage producers and reviewers on a conference call recently, to watch out for innovative ideas and to protect and support them.
I have two problems with this. The first is that the system is designed not to encourage submissions about topics not listed in the announced program. Psychologically and sociologically there is nothing in the announced program to encourage submissions on other topics or dissenting viewpoints. The second is that while the reviewers may have heard Ahmed, understood him, and value his message, they will not as a group be able to advocate for and protect the innovative, or dissenting ideas that compete against other submissions that fit nicely with the envisaged stage. Again it is simply the natural effect of the psychology and sociology designed into the system. The popular democracy will tend the outcome to the safe middle ground.
Ahmed and I have agreed to disagree over our opinion on this.
Meanwhile, Ahmed is worried that folks in the community have formed the opinion that he doesn't understand the Agile Manifesto and the principles that our community is formed around. If this is true, then I apologize for seeding that opinion. I am quite convinced that Ahmed does "get it" and that he has a valuable part to play in our community. I look forward to working with him on it in future. If I have a criticism it is simply that I feel he is putting too much faith in people. Too much faith that they will do the right thing and follow the direction that was provided as a bandaid because the Breaking Acts stage was dropped from the program.
[I hope that clears this up. It's very difficult to articulate. Meanwhile, Ahmed has a proposal he is circulating that may lead to a satisfactory resolution of the matter. I want to give him the space and time to work this and I am confident of a satisfactory outcome.] Technorati tag: Agile+2009, Agile+Chicago, Agile+Alliance, David+Anderson, Ahmed+Sidky
A Couple of Other Areas of Innovation
In my post The Case for An Agile Fringe I mentioned two current fringe areas that I thought were interesting: Real Options; and Agile+CMMI. I don't want folks to think this list is exhaustive. Two more areas that I see current interest and activity building are agile for embedded systems, and agile contracts.
I've been asked by several people in recent months who work for companies that make physical products that contain significant portions of software, about how agile practices can be applied in their field. Some folks are responding to this demand. I would expect some of that to emerge in 2009 in publications and presentations. So I'm predicting the emergence of an agile for embedded systems movement next year.
I'm also seeing a lot of work on developing agile working relationships between client IT and technology companies and outsource development vendors. Until now the agile contracts literature has been fairly thin and based mainly on thought experiments. I'm actively seeing consulting and outsource firms offering agile ways of working and interacting to their clients, for example, Valtech have an offering they call Software on Demand. I am also seeing significant users of outsource/offshore development demanding more agility from their suppliers and writing contracts requiring an agile way of working and interacting. In the language of the Software Engineering Institute, we are now seeing agile penetrate into the field of Supplier Agreement Management and Software Acquisition. I fully expect case studies and more literature to appear in this field in 2009.
What else are you working on that might be considered fringe? Technorati tag: Agile+2009, Agile+Fringe, David+Anderson, SEI, Carnegie+Mellon, CMMI, embedded+systems, software+engineering
The Case for an Agile Fringe
In the background, the debate with the Agile 2009 Conference committee has been continuing since I raised my disappointment with the announced program. Olav Maassen and Eric Willeke have stepped forward and proposed an Agile Fringe stage that would encompass the ideas of the Breaking Acts and Questioning Agile stages from the 2008 event. However, the organizers are pushing back claiming both a lack of space and lack of need. Amhed Sidky is arguing that the existing program can accommodate the types of new ideas and agile skeptic proposals that the Fringe stage would actively solicit. I believe that the Agile Alliance and the Agile 2009 conference committee led by Johanna Rothman with program chair Ahmed Sidky need convincing of both the purpose, value and strength of support for an Agile Fringe stage within the main conference. So I am posting here an open letter to Johanna and Ahmed. If you agree with the sentiment in this letter I would like you to sign it by leaving a comment. Thanks.
Dear Johanna and Ahmed,
I greatly value the contribution you make to our community giving your time and energy to facilitate the gathering of our community of peers at Agile 2009. The Agile conference is the public face of the Agile Alliance to the wider community of software developers and technology industry professionals. So you have taken on positions of great responsibility. Your decisions about the conference send a public message to the wider professional community about the Agile Alliance and what it values. I strongly believe that the Agile Alliance values innovation, openness and objective debate about better ways of building software. I believe it is important that the Agile Alliance shows leadership and stands by those values and protects innovation, and shows openness through Devil's advocacy by giving these topics specific space in the conference program. Two members of the Agile Alliance, Olav Maassen and Eric Willeke have proposed an Agile Fringe stage for the conference program to serve this purpose. I commend this idea to you and I hope that you both appreciate its value and show good leadership and judgment through its inclusion in the program.
Ahmed has argued in private email that such a stage is not required. He argues that the existing program can accommodate new ideas such as Real Option Theory or ideas which engender skepticism amongst the agile community such as Agile+CMMI. He also argues that the theme of this year's program is to have domain specific stages e.g., a testing stage, a developer stage, a product management stage, and so forth, and that cross-cutting stage concepts are not part of the plan for Agile 2009. He argues that an Agile Fringe stage would be cross-cutting and therefore doesn't fit neatly with the pattern. He continues that any submission for a Fringe stage could easily be accommodated in one of the domain specific stages. And further, that the review committees for these stages are open-minded, experienced professionals capable of judging submissions each on their own merits. That the open nature of the submission system will give innovative new ideas a fair shake and that there is no need for a specific stage to provide a home for emerging concepts or skeptical challenges to agile values, beliefs and practices. I would contend that this opinion is wrong-headed and not supported by history from previous conferences.
Others have argued that the open space area is all that is needed to accommodate innovative ideas and skeptical dissent. While there is truth to this I would argue that open space is not enough.
If we look at the emergence of kanban as a case study, kanban first started as a single open space at Agile 2007. At Agile 2008, there were 6 kanban presentation by other presenters, some of whom had been present at the open space session the year before. Almost all of those 6 kanban presentations appeared on the Breaking Acts stage. If Breaking Acts had not been present, it is likely that many of the kanban submissions would have been rejected. Rejected for entirely explainable human reasons. Rejected because they wouldn't be interesting to a wide audience. Rejected because the reviewer didn't know about or understand this new technique and found it confusing, threatening, or simply not interesting. As Chris Matts pointed out during the open review period for Agile 2008 in response to a reviewer comment, "we have 5 submissions about the specifics of prioritizing the Sprint backlog in Scrum, surely we have room for one more presentation on kanban...?" New things get rejected by reviewers looking for the familiar and the safe. Without a specific category for the new and challenging, it's human nature to go with familiar safe choice.
A second valuable case study from Agile 2008 would be the treatment of submissions related to CMMI and organizational maturity. Many of the review comments were based on ignorance, fear and loathing and certainly not objective in nature. The treatment of the submissions and the submitters was often shameful and reflected poorly on us as a community and on the individuals making the submissions. I used my status in the community to dedicate a section of my main stage speech to the topic of Agile and CMMI. Afterwards, I received many positive comments and emails from regular attendees who were amazed that no one else was talking about it. This shows us that reviewers don't often reflect the true concerns of the attendees. Reconciling agile methods with CMMI has become a hot topic outside Agile Alliance circles this year and the program for the Software Engineering Institute's SEPG conference in March 2009 contains many presentations on Lean, Agile and CMMI including some from people who presented on the Agile 2008 Breaking Acts stage and some from those who were vitriolically rejected through the Agile 2008 submission system. Again, history would indicate that the existing program selection and review system for the Agile conference does not produce the right results.
While I have chosen to highlight Agile+CMMI and Real Option Theory as topics I believe would find a home on an Agile Fringe stage, I believe there must be several more out there, perhaps from people we've never yet heard of? How do we provide them with an audience and a hearing? If we allow the program to be driven by popular democracy we will always be trending towards the middle, the mediocre and the status quo. We will be reinforcing a narrow definition of agile and sending a message to our community that outsiders with new ideas are unwelcome.
I find Ahmed's attitude to be academic and unrealistic. It relies on the process and removes focus from the people. His argument that all the submissions for Breaking Acts in 2008 could have been accommodated on other stages might be valid in theory but in practice they would never have been accepted. In the agile community we should know better than this. We value individuals and their interactions more than we value processes and tools. Ahmed is asking me to put my faith in the review process and the online review tool. I prefer to put my faith in human nature. If we do not provide a stage that explicitly solicits innovation, skepticism and ideas from outside the established and accepted notion of agile methods, we will have a conference devoid of significant discontinuous innovation. I would surmise that we have an echo chamber.
I truly hope that you will find a way to adjust the program to include the Agile Fringe stage.
Best regards,
David Technorati tag: Agile+2009, Agile+Chicago, Agile+Alliance, David+Anderson, Eric+Willeke, Olav+Maassen, Johanna+Rothman
Encouraging signs from Agile 2009
So while I posted my criticism of the Agile 2009 program a few days ago, I thought I'd take a moment to comment on the trends that I see as encouraging and favorable.
Most of all I am delighted to see a stage dedicated to tools! :-D It seems that the elephant in the room has been unveiled! The Agile Manifesto taught us to despise tools and processes. Despite this, from the beginning agile development has been about tools and processes. They were just different tools and different processes from those that preceded them [in the 1990's.] So we went around saying tools and processes are bad, when what we meant was, your tools and processes are bad, our's are good! So :-p :-p :-p to you! (traditional, waterfall, SDLC, academic, big process, big design folks.)
So I see a full stage dedicated to tools as a real coming out for the community. Meanwhile, the type of tools I see being developed in our community are quite astounding. I'm a particular fan of JBehave and the work from the BDD community. So I'm looking forward to what else shows up on the tools stage.
So what else looks interesting?...
I'm particularly glad to see a user experience stage. I was, after all, the UX guy on the Singapore Project when FDD was born. And most of my early publishing was agile user experience material. I wish the abstract for this program was a little more specific and gave better guidance for submissions but regardless, it's good to see that user experience is getting a fair shake. It is so vital to the delivery of customer value. Technorati tag: Agile+2009, Agile+Chicago, Agile+Alliance, User+Experience, David+Anderson
Clinton Keith on Why Kanban Makes More Sense for Games
Clinton Keith's name is associated with Scrum. His website even proclaims it boldly. But recently Clinton has been doing a lot more with kanban. He had a kanban/lean pull system presentation at Agile 2008 and now this Gamasutra article. It's really well worth reading, though its heavy reference to manufacturing plants is not to my personal taste. Clinton reports that using kanban has shrunk lead time on lgame evel production activities by 56%.
In the example above, the team went from producing a level every 16 weeks to producing a zone every week. With seven zones per level, the ultimate improvement to level production was 56%.
This snippet provides some background ...
Asset creation is deterministic and sequential work that does not fit the Sprint iteration cycle very well. If we think about production as a factory assembly line, then the two to four week iteration cycle doesn't make as much sense. Factories don't empty the assembly line every four weeks and determine what to build next.
Assembly lines have things rolling off much more frequently and require incremental improvements instantaneously. The rate that completed assets roll off the line becomes the new heartbeat of the production team.
[...]
However, when we enter production, we can have a long chain of tasks that need to occur before we see some production assets in the game. Take, for example, the steps that need to occur for a single level to appear in the game.
Technorati tag: David+Anderson, Lean, Kanban, Agile, Games+Development, Clinton+Keith
Disappointed with Agile 2009 Program
Am I the only one who is disappointed with the lack of vision and leadership in the Agile 2009 program? The Breaking Acts stage is gone from next year's event. There is no explicit place in the program for innovation that doesn't already fit with the established notion of agile. After dedicating the largest share of my main stage speech in 2008 to this topic I am extremely disappointed that innovation and new agile method ideas don't seem to be important to the organizing committee.
Equally, there is no explicit place for Lean in the program. Given the very evident shift in the community towards Lean principles and practices and the rapid growth of kanban, and the fact that the Gordon Pask Award was given to Kenji Hiranabe and Arlo Belshee explicitly for their contributions bringing Lean/Kanban ideas to the agile community, this is a truly surprising ommission.
But what surprises me more is the degree of duplication in the published program. What for example, is the difference between Agile Product Management and Customers & Business Value?
One of them asks us for "best practices for prioritization/ROI, getting customer input, roadmaps and releases, etc. Commercial products (for revenue) versus internal projects (for in-house customers)" and the other for "Defining and measuring the business value of projects, features, and processes. Using business value as a means of deciding which functionality to pursue. nventing, prioritizing, managing, and validating requirements. Working with customers and stakeholders Process/Mechanics"
And then there is Agile Adoption and Agile & Organizational Culture. What is the difference?
The latter asks us for "Agile is all about changing your organization. It's not only about changing the way you think and work. Improving your organization's agility in a sustainable way may also require changing its underlying values and principles. Change doesn't come easy. An agile initiative doesn't take place in a vacuum; it has to interface with the existing (organizational) culture. Both will influence each other as change takes place. This is a process of mutual adaptation, where one possible result is that the agile initiative can fail because the neither the organization nor the agile initiative is sufficiently adaptable."
while the former suggests... "Knowing what Agile is quite different from knowing how to roll out an Agile process. The Agile Adoption stage will focus on lessons learned from rolling out an Agile process. [...] How can you assess your potential for becoming Agile before starting a migration? How can you minimize delivery risk when moving to an Agile process? How can you implement an Agile process that recognizes your unique business model, customer, and company culture? What does the Agile migration process look like in application? What are the key foundation steps for starting a move to Agile? What are the best practices for getting executives, managers, customers and team members to buy-in to moving to an Agile process? Can you mix Agile practices with your existing processes when migrating to Agile? Can you migrate too quickly? Can you migrate too slowly? How can you sell adopting Agile during the current financial crisis?"
Does one of these sound like a subset of the other?
And then there is a Telling Our Stories stage that asks for experience reports, but then so do almost all of the other stages.
I can't help feeling that with some portfolio management of the program, the committee could have consolidated the existing stages and freed up 3 slots to use for something else. I personally would like to see the Breaking Acts stage back again. And I'd like to see a Lean stage. What else would you like to see at the Agile conference?
Update: Read Johanna Rothman's reply. Technorati tag: Agile+2009, Agile+Chicago, Agile+Alliance, Lean, Kanban, David+Anderson
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
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
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
Personal Hedgehog Revisited
[First pusblished at moduscooperandi.com] More than 4 years ago, I riffed off Jim Collins idea of a corporate Hedgehog Concept, with this blog post on Personal Hedgehog Concept. It's proven to be one of the most popular blog pages on AgileManagement.Net since I started it in August 2003.
The original post used the career of Cameron Barrett as the example. At the time, Cam was pursuing his passion for politics supporting the campaigns of Democratic candidates Wesley Clarke and John Kerry. However, recently I was challenged by Liza Raiser to explain what the Personal Hedgehog Concept means to me.
Actually, I've been working on my own hedgehog concept for most of the past 8 years.
First, what am I passionate about? For a long time I've been passionate about the underperformance of the software engineering profession and the low rate of success on software development projects. In fact, I was so disgusted with the profession I intended to quit almost 10 years ago. It was thanks to Jeff De Luca, and the original FDD project in Singapore that I regained my enthusiasm for the profession.
So what can I be one of the best in the World at? It's taken a while, but I started down the path to publishing and what we now call blogging in 1999 at the behest of Peter Coad and Jeff De Luca. 4 years later, Peter was instrumental in assisting me with the publication of Agile Management for Software Engineering. I've continued to work at improving my ideas on software engineering process and management of knowledge workers and I've continued to work as a practitioner in regular jobs managing software engineers - until recently, when I formed David J Anderson & Associates.
So what changed? Well finally, I was able to realize my Hedgehog Concept. Finally, my skills with software engineering process and management and leadership of knowledge workers were in sufficient demand that they could drive my economic engine. Let's be under no illusion! There is little to no premium in the market for good management in the software and IT industries. While great individual contributors often become independent contractors and earn high hourly rates, the same does not generally apply to managers. And while employers might be willing to pay a 10%-20% premium for a decent person, often a great manager find him/herself earning far less than the top technical people on the team. This is despite the hard economic evidence that it is management talent that generally constrains the performance of software engineering organizations.
So, for a long time, I've known that I had to break out of working as a manager for other people and start my own firm. The question was when? When would the timing be right? Finally in 2008, with a track record that includes successful projects and teams at Sprint, Motorola and Corbis and with a catalog of intellectual property that includes my contributions to FDD, the MSF for CMMI Process Improvement and most recently my contributions to Lean in software development and the innovations with the Kanban method, I finally have sufficient recognition and respect in the industry for it to drive my economic engine.
Along the way, I've also resolved my own inner conflicts about whether I had taken the correct career path. I've finally come to realize that management and leadership is my real strength and that other things I enjoy are merely hobbies, like painting, art and design, and my synthesis of those talents in user interface and interaction design. It was in fact user interface design that got me started down this road, with my uidesign.net site. Recognizing in myself what I could be World class at, from the things that I can be merely good at, has been the foundation of a new happiness in my life.
So here we are! I'm having the best fun at work since I quit the games industry in the late 1980s and I'm happier than perhaps I've been since leaving Singapore in 1999. Finding my Personal Hedgehog Concept has been at the root of that happiness. It's been a long slog - more than 8 years. A journey of personal discovery. But ultimately it's been worth it. And now I am excited about the future where I intend to continue innovating in leadership and management of knowledge workers and helping teams deliver superior economic performance.
Are you working on your Personal Hedgehog Concept?
