Sunday, April 25, 2010

Thoughts on #lssc10

On Friday night I flew out of Atlanta for London and Hamburg, after a successful Lean Software & Systems Conference at the JW Marriott. It had been almost a year in planning. I thought it would be appropriate to take a moment to reflect on a project successfully delivered.

Planning for #lssc10 started on the final day of the Lean & Kanban Conference in Miami in May 2009. Software Engineering Professionals (SEP) impressed with what they saw in Miami and keen to help grow the community, offered me their Director of Marketing, Kelly Wilson as the event planner for 2010, in exchange for title/organizer sponsorship. Kelly is a professional experienced event planner. I jumped at the offer. This mitigated the first major risk for 2010.

In total Kelly must have devoted about 14 weeks of effort to #lssc10. SEP were by far the largest contributor to the success of the event.

The next job was to a pick a venue. We picked the city of Atlanta because it was still in the Eastern time zone and closer to Europe and South America and had a major hub airport. We also hoped that the Atlanta Agile and PMI communities would be excited by our event and turn out in force. We planned for 300 people - a massive step up on 57 in Miami. We hoped for 80 from Atlanta. In the end, it wasn’t to be. We got less than 10 from Atlanta. However, the choice of Atlanta was still good for travelers and worked well for international guests.

Within Atlanta we solicited bids via the Vistor’s Bureau from suitable venues. We narrowed this down to 3 candidates, one in downtown, one in midtown and the other in Buckhead. We ended up picking the JW Marriott in Buckhead. I believe that the two main risks in any conference are the event planner and the venue and the past week has shown that we successfully mitigated both. The JW Marriott really worked out. People liked the location. They liked the proximity to public transport and straight train ride to the airport. They liked the intimacy of the venue and close proximity of all the rooms which made for easy transition between sessions and lots of coverage for the exhibit booths.

The next big executive decision was the program. I pushed back on some Lean SSC principles and ran with a 3 track, 2 key note format, with an open space on day 3, plus a title sponsor talk, over the same 2.5 days as 2009. This gave us 43 sessions up from 19 in 2009. That’s a lot more complexity and cost to carry. However, it also worked out.

One of the more interesting comments since the event has been “the lack of Kanban content.” It’s interesting that this was the perception from some of the more advanced, expert members of our community. Lean Software & Systems 2010 actually had more Kanban content than any other event held anywhere, previous to this. In fact there were 10 Kanban track sessions, plus 10 experience reports, nearly all Kanban related, plus a the title sponsor talk that included a case study from a major investment firm, again about Kanban, plus Kanban games in the Open space, and Kanban related lightning talks. It’s actually a tribute to the quantity, quality and diversity of the other content that some Kanban experts chose to spend their time in other sessions and hence perceived a lack of Kanban content at the conference.

The conference also met all my major goals: set the direction for the community; show the growth and vibrancy of the community; demonstrate beyond all reasonable doubt that Lean and Kanban are a force for good and genuine trend in software engineering and IT related work.

The key note speeches were probably the 3rd major risk. Some questioned the choice of Bob Charette as they weren’t familiar with him or his work. However, both Don Reinertsen and Robert Charette were incredibly well received and their talks defined the direction I want the community to follow - a new definition of Lean that includes economics, risk management and systems thinking. Together Bob and Don laid out both a strategic direction for us to follow and specific areas of interest for us to pursue at a practical, pragmatic, actionable level.

One of the highlights for me was standing in the exhibit area just absorbing the atmosphere and thinking that this time last year, none of this existed. We had 4 vendors showing Kanban tools on their booths and two others represented amongst the speakers. We had a definable sub-community of tool vendors and creators.

I was also delighted to present the first ever Brickell Key Awards, commemorating the formation of our community and organization in Miami in 2009. The award went to two very worthy winners, Alisson Vale and David Joyce. I’ve blogged over at Limited WIP Society about these.

I’m out of time today. I’ll blog more thoughts about the event soon. I’m off to teach Kanban in Hamburg now.

Thursday, May 01, 2008

Agile Leadership Summit - San Francisco May 5th

Register now, using code ‘d400’, to see me present kanban in San Francisco May 5th 2008 before March 19th and get a $400 discount.

I’ve never spoken about Agile Management in the San Francisco Bay Area with the exception of my visit to Yahoo! to talk about kanban last year. So, I’m really excited to have the chance to do so in San Francisco this year. It’s been so long since I’ve spent any time in city of San Francisco - one of my top 5 favorite places in North America. I believe it was 5 years ago that I last attended JavaOne as a Motorola employee.

If you live in the Bay Area and would like to learn more about kanban and have a chance to meet me and talk directly about agile and lean ideas for managing software engineering teams, then come along to the JAOO event on May 5th. Accelinnova and TriFork are jointly presenting an Agile Leadership Summit. The line-up is basically the same folks who turned out for the APLN Leadership Summit in Dallas. However, the San Francisco event is commercial and does not benefit the APLN. Technorati Tags: Kanban, Lean, David+Anderson, Agile, Software+Engineering, Management+Science

Saturday, April 17, 2004

Management versus Leadership on ‘The Apprentice’

So America sat glued to its TV sets on Thursday night to see Bill, the entrepreneur, win and Kwame, the Harvard MBA, lose in the final episode of The Apprentice. As The Houston Chronicle reports, it is really hard for us in the audience to judge the result due to the shows editing. We clearly didn’t have all the facts. However, it was very obvious in the end why Kwame didn’t win. He lacked leadership. It was a theme over several shows. His cool, unflappable, trained manager, Ivy League MBA style might have been full of delegation and empowerment, but he wasn’t prepared to provide the leadership, direction and example when it mattered. When his team was flustered and confused filled with ambiguity, uncertainty and doubt, Kwame didn’t step in and show them how he wanted it done.

Management is an essential skill in business but it cannot go without leadership. The season of The Apprentice showed us why and how leadership matters. What does this teach us in the software business?

I discussed this once before - my belief that all good software development managers have to have come from a strong coding background, whilst some others believe that the problem with managers in software development is precisely because they did come from a development background and have no management training. I feel The Apprentice has reinforced my belief that leadership is essential and in software to be a leader, you need to carry the respect of the geeks who work under you. To do that you need respect as a technically accomplished individual who can step-in and show them how and why. Managers can be trained. I’m not sure that is true of leaders. I feel leaders are born. So perhaps the correct recipe for a good manager in software development, is to find the talented developer with born leadership skill and train them as managers - coached by a mentor, someone who has learned good management practice and can provide Kwame-like coolness, delegation and empowerment, whilst maintaining the ability to jump-in, analyze, design and architect with the best.

Sunday, February 01, 2004

Compensate Uncertainty with Leadership

There has been some considerable debate in the agile community about the percentage of good people required to make agile methods work. Most recently this thread at the FDD site. The topic was also a common running theme in Boehm and Turner’s Balancing Agility and Discipline where on page 185 (for example) they postulate that FDD requires a lot of good people in order to scale. Schwaber and Beedle’s Agile Software Development with Scrum claims on page 121 that it needs 50% experienced people to work. As I state in the thread at the FDD site, my experience with FDD is that 1 in 6 is about sufficient. Why?

Simply put, I believe that this endeavor to define how many good people or how many experienced people are required for any given method, is a red herring. The real issue is one of leadership versus uncertainty. Uncertainty comes in many forms - change (see Satir’s change model, see also Peopleware 2nd ed page 199), scope ambiguity, domain ambiguity, schedule uncertainty, job description and positional ambiguity, fear, difficulty, novelty of process, technique, tools and lack of experience therein, then there is variance both common and special cause. The greater the uncertainty in any project, the more leadership is needed (at all levels) in order to compensate for it. By loading too much uncertainty into a project, without sufficient leadership, there will be the chaos that Satir identifies but rather than recovering from the slump to show an improvement - the J-Curve effect - there is simply a slump and things remain worse than they were before.

FDD gets its leadership at many levels - the Chief Programmer (the shop floor foreman) is the first level of leadership, then there is the Development Manager and Chief Architect. All these roles must provide leadership on a day-to-day basis in order to overcome the uncertainty. When a project is happening in a new domain, with uncertain scope and schedule, and FDD is being introduced for the first time, along with color modeling and perhaps new middleware tools or development tools such as a JDO implementation and the Togethersoft Control Center, then everything is in flux. In such a situation, a team needs every CP, the Dev Man and the Chief Architect all to be great leaders, mentors and teachers. In simpler situations, where there is less ambiguity then less leadership is required.

In order to be a leader, an individual must be both good at software development and experienced in the software lifecycle (with a particular method). Hence, “good” and “experienced” are actually emergent properties of “leadership”.

The amount of leadership required on a project is situational. Trying to measure it by method and define a scale of agile methods versus percentage required is futile!

Wednesday, January 21, 2004

To Code or Not to Code: Leadership versus Management

Recently I’ve been coding!

Back in the days when I worked at IBM as a contract coder - in the mid 1990’s - my line managers were both young and recently promoted to their first management job. The management training involved as many as 5 weeks away from the team and was referred to as “the brain washing” by the former colleagues (now staff) of the new boss. One of the key tenets which was drilled into these young managers was “thou shalt never code again”.

The position of line manager is key in any firm. The line manager is the one who manages the economic engine of the company. Without good line management, there is no business. The transition from individual contributor to line manager is also perhaps the most difficult and the most important for any business. For the first time, new line managers must learn to live vicariously through their staff. They must learn to coach the best performance out of their staff and to accept that some jobs will never be done as well as they would have liked them to be done or might have done themselves. This behavior of accepting life as a vicarious pursuit and learning to accept “good enough” rather than “perfect” is a measure of how well a manager is progressing and something on which further promotions to higher levels are measured.

It seems obvious then that if former developers are to learn to live vicariously, they must never code again. The temptation to “just do it” might otherwise be too great and they will never be good managers - always down in the noise and not defining the governing rules for their systems and the metrics with which to monitor and control them.

However, management is all very well but occasionally the troops need leadership. Developers need to be shown the way. This is particularly likely in new and uncertain territory. The greater the uncertainty - the greater the leadership required. Uncertainty can be caused by the domain - a new market being entered, or the technology, or the tools being used, or the working practices being adopted. In any or all of these circumstances, if the manager has the hands-on experience then it makes sense to lead by example.

When introducing FDD, for example, don’t be afraid to lead a Feature Team as Chief Programmer! Don’t be afraid to demonstrate how to Design-By-Feature by convening a Feature Team and facilitating the drawing of a Sequence Diagram! Don’t be afraid to hold a code review! When developers are unsure of how to implement behaviors such as “blue” <<description>> classes on a domain model, don’t be afraid to pair-program with a developer to make it happen. Pair programming is perfectly acceptable in FDD as part of the early lifecycle of a project whilst the architecture and design templates are being created. Don’t be afraid to fuzzy the line between Step 1 - Build a Domain Model and Step 4 - Design by Feature. It doesn’t matter if you have to go and build a dozen Features to prove a model. If seeing is believing then make your development team believe. Lead them to belief through example. Don’t let “analysis paralysis” bog you down. Don’t let subjective debate and belief cost you inertia and velocity. Lead by example.

It is OK for managers to code when they are leading! Once momentum builds and the team feels comfortable then the manager can quietly slip back into the vicarious life of monitoring metrics.