Tuesday, July 31, 2007

Failing to Manage to the Values

I’d like to take a look a management dilemma posed by Jack Welsh, former CEO of GE. It’s posed as a classic 2x2 matrix (or Gartner Magic Quadrant chart). On one axis is the notion that a manager lives by the values of the organization, and on the other axis is whether the manager delivers results (the numbers). This gives us four outcomes. Welsh states that in three of the outcomes the management decision is easy:

• makes the numbers, shares the values - no brainer - this manager is excellent and a keeper
• doesn’t make the numbers, doesn’t share the values - no brainer - fire them
• doesn’t make the numbers, shares the values - a good manager, well intentioned, needs investment in coaching in order to improve the numbers

However, it’s the fourth type that causes the problem. What do you do with someone who makes their numbers but does so in a way that is out of alignment with the values of the organization? In the short term, eliminating someone like that may mean that the numbers are not achieved and the higher level manager takes a blow to his/her own numbers. How do you explain a J-curve effect period undertaken to fix the values of the organization, in a world where values are about managing for the long term, while the markets expect us to manage for the next quarter?

In software projects, I see these managers as those who deliberately, consciously death march their people to achieve a project date, or deliberately, consciously sacrifice quality in order to make a project date or manage in some other fashion that might deliver results but leaves a sour taste - for example, a manager who suffers 50% staff turnover, rules with an iron fist and has instilled the fear of death in to the 50% who do hang around long enough to get anything done.

It’s all too easy to see managers revert to methods that are not in alignment with agile values, particularly when there is a specific extrinsic incentive for them (and usually not for the workforce.) The war of attrition attitude - deliver the numbers, let me make my bonus, and don’t worry about the casualties! It’s a style that shows that the manger is being narrowly managed and doesn’t have to pay the costs of attrition - that comes from a different budget. In a similar vain, large industries get to pollute our environment and aren’t always taxed accordingly.

My view on this is very simply - knowledge workers are human. You cannot deny their humanity. To invoke De Luca’s First Law, “[It’s] 80% psychology, only 20% technology!” Knowledge workers productivity is directly related to their motivation and engagement in their work. All the process and methods and organization in the World will not fix a demotivated workforce. And hence, I come to the conclusion that living by the values is paramount. You cannot sacrifice the values to hit the numbers in the short term. So for me the Welsh dilemma isn’t a dilemma at all. Managers who don’t live by the values should be removed. Period!

Question: Does your organization have published values? Do your workers understand the values you use to lead your organization? Technorati tag: Agile, Software+Engineering, Management, Jack+Welsh

Monday, July 30, 2007

Jeff Sutherland at the Bellevue Harbor Club

I attended a talk by Jeff Sutherland at the Bellevue Harbor Club this afternoon. It was an invitation only event thrown by one of my suppliers. I wanted to capture a few memories from the event - and make them available to you all.

Venture Capital. He started out by suggesting that venture capital firms will be unwilling to invest in firms not using agile development and went further to state that as Scrum and XP has 90% market share of the agile methods space, that only firms using Scrum and XP will receive investment.

Agile Adoption. Later he was questioned about the notion, “that if agile is so great why isn’t everyone doing it?” He admitted that agile still represented less than 10% of the market but that he fully expected with the current rate of growth that agile would be the dominant method soon and would be the only method by 2017. He called this the “lilly pond effect.”

Test First Development. Jeff defined a difference between Test First Development and Test-Driven Development and his definitions would match mine. Test-Driven Development is a specific technique that grew out of Extreme Programming where Unit Tests are used to drive the emergent design of the code and there is no explicit design or subsequent code review against design, whereas Test First Development is simply the notion that tests are created prior to any code and effectively become part of the specification. There isn’t a focus on emergent design with Test First.

Agile in a CMMI Level 5 Org. A large section of his presentation focused on a CMMI Level 5 company that had deployed Scrum and produced approximately a 2x productivity improvement over their already very high quality processes. This has allowed them to bid jobs at half the price. They now offer two bids - one based on waterfall at 2x the cost of the other based on Scrum. They ask that the customer agree to participate in Scrum as part of the contract. Very cool!

I asked Jeff if he thought he had evidence that high maturity organizations can adopted agile faster and better than low maturity organizations. He went on to quote a couple of other examples, one where the company was already good at Six Sigma, where agile was introduced as pilot under strict process improvement supervision. Once proven, it was quickly replicated throughout the organization. These high maturity organizations had scaled agile methods across the org within 9 months or so - very impressive. And further proof that high maturity and agile are highly compatible.

Lean Maturity Model. He also showed some Lean maturity and adoption model based on work by the Poppendiecks (I think. It wasn’t clear with the Poppendiecks had done all the work.). This was very cool and I want to learn more about it. Corey Ladas and I have been talking recently about a Lean Adoption Cycle and providing specific guidance for how to drive Lean Software Engineering adoption. I’d like to compare the two.

New Paradigm. Jeff also talked about how Scrum is a different paradigm and how to shake some folks out of their old way of thinking. Two specific pieces of advice - ban Gantt Charts, and ban time sheets and time reporting - were in my opinion particularly poignant.

Agile at Scale. The talk focused on case studies that showed the benefits of agile practices and data that showed scale to projects in the 500K-1 Million LOCs range, with high maturity organizations with CMMI Level 5 appraisals and with distributed teams. Particularly interesting was one study where management had decided to only have distributed Scrums, i.e. teams where the members where in at least 2 locations. The typical Type B Scrum where teams collocate around some architectural decomposition - this approach has also been widely documented by others for non-Scrum-branded methods - was not adopted. Instead the teams were asked to overcome the distance challenge and achieve collocated levels of velocity despite the dual location. The result was that the management could later turn off the second location and achieve a linear reduction in velocity without loss of tacit knowledge of the system. If they’d adopted a Type B solution then they’d have lost a lot of knowledge of the 2nd part of the architecture and any maintenance to that part would have suffered a severe non-linear drop off in velocity.

Non-co-located Agile Teams. It sounds really hard to achieve non-co-located agility, but the benefits of overcoming the challenges seem to be exceptional. I’ve seen Ron Jeffries comment recently that when something seems hard, you should practice doing it often and get good at it, so that any one time does not become a burden. I recognize this advice with what we’ve been doing with respect to software releases. We’ve released 33 time since last September. With each release, we first practice the release in to our staging environment. So actually we’ve released 66 times in 46 weeks. Needless to say, we’ve got really good at doing releases, and it is now so smooth that no one gets stressed and the organization hardly notices when a release is going out. The transaction cost of releasing has fallen dramatically. Jeff’s client appears to have achieved a similar level of capability at distributed non-co-located agility. Technorati tag: Agile, Scrum, Jeff+Sutherland, David+Anderson, Lean, Corey+Ladas, Mary+Poppendieck

Friday, July 27, 2007

So-wuh, do we still need a reuse policy?

It’s taken me a long time to come around to the view that SOA was more than just early 1970’s procedural programming wrapped up in an open transport protocol. I’ve been widely skeptical of all the claims that “SOA is a new way of building software,” and “SOA is a whole new paradigm.” All of this struck me as RDD (resume driven development.)

I liked this article in SD Times this week that pushes the notion that SOA is not about reuse. Some of the guys on my team have been telling me this for months. They’ve been pushing the idea that SOA is all about agility. The idea of software as swappable and replaceable blades.

And I’ve been replying that this might be all very well but I wanted to hear their reuse strategy. Reuse is still the best way of improving programmer productivity. Not writing code because you are reusing something that already exists is better than any alternative.

What’s condensed from the intellectual debate that has ensued in the team these past months is the idea that we have a two pronged reuse strategy - a pincer movement on the enterprise services we’re writing. The first is very traditional - basic good internal code quality based on structured methods, object and aspect-orientation. The second is leading edge - we’re using Software Factories to templatize much of what it takes to create, manage and deploy a service, based on a schema, allowing the developers to focus on the business logic and behavior that belongs in the service - that business logic being written using the basic good internal code quality that comes from disciplined adherence to best practice in structured methods, OO and AO. The result is both code and pattern reuse, with automation of final code generation that eliminates defect insertion opportunities.

I’m finally happy that we have an ability to move forward with service-orientation for all the positive reasons (agility, flexibility) and avoid throwing the reuse baby out with the bathwater that came with the earlier generation of enterprise reusable component frameworks. Technorati tag: Agile, SOA, Service+Orientation, OO, Object+Oriented, Software+Engineering, Software+Factories

Thursday, July 26, 2007

Are you part of the Post-Agile Movement?

Last January I had a long chat with Luke Hohmann while we were both in Munich at the OOP conference. We talked about “getting beyond agile” and why we felt it was necessary and what we each had been doing that wouldn’t be considered agile by some of the community and yet we both knew that these innovations were taking the industry in the right direction - the more productive, more economically successful direction. It’s almost four years since I published why I was re-evaluating my Agile affiliations. I feel as strongly about this today as I did then.

My view is quite simple. There is an element of the community who want agile to be defined as a convergence of XP and Scrum and nothing more or less. They have lots of vested interest in this definition because their businesses would like to sell it to you. They are not interested in innovation. They are not interested in diverse views. And they shun other schools of thought that might also deliver a solution to the frustration of low productivity and poor industry morale that led to the Agile Manifesto. They want to eliminate competition - pure and simple. They want a homogenous definition of Agile that has everyone doing the same thing.

Meanwhile, there is a community that wants to continue to push the boundaries, to continue to innovate and to continue show greater and greater economic and social improvements in software engineering. It’s this group that is feeling the need for a post-Agile movement. A movement that says, “Yes, XP and Scrum are all very well, and good, and wholesome, and we’ve learned many lessons from them, but there is room for new thinking, fringe ideas and innovation, and we want to continue to push the boundaries and explore scalable solutions to knowledge worker productivity in the 21st Century.” That to me is getting beyond Agile. And I feel that in my work this past couple of years, I have pushed that boundary and been exploring the post-Agile world.

I loved Jason Yip’s views on post-Agile. As he says “Lean is the story Agile should have been.” I’ve felt this for several years. I’ve been arguing for several years that FDD was more of Lean approach than a classical agile - embrace change approach. While the likes of Ron Jeffries were arguing in my Yahoo! group that FDD wasn’t agile . I was appearing in places like USC, suggesting it was Lean. The key here is that it wasn’t important whether FDD was agile or not. What was important was whether it worked and whether it was producing financial, economic results coupled with social improvement for developers.

And so, the Agile tribe will gather for its annual rite of passage at Agile 2007 next month. There will be those who are in and those of us who are not in. As one of the not in you might ask me, why do I bother attending? Well its simple. Agile 2007 is the best social networking event because almost everyone goes, whether they are of the homogenous, converged Agile camp, or the heterogeneous, innovative, post-Agile camp. And so I’ll hope to see you there, and I hope you’ll have an open mind about what’s beyond Agile and want to talk to me about something other than XP or Scrum. Technorati tag: Agile, David+Anderson, Lean, Software+Engineering, Extreme+Programming, Scrum, Post+Agile

Sanjiv Augustine to Speak at August APLN Seattle Downtown Meeting

Sanjiv Augustine, co-founder of the APLN, signatory of the Declaration of Interdependence and author of the excellent, Managing Agile Projects will be the first guest speaker at the APLN Seattle Downtown Chapter on August 6th. The meeting will be held at the Avanade office at 2211 Elliott Ave in Seattle. Networking and food from 5.30pm. Sanjiv to present from 6.15pm. The meeting is open to anyone who would like to attend. Hope to see you there. Please RSVP via email to Dragos Dumitriu so that we can insure sufficient food and seating. Thanks.

Small is Beautiful - The Evolution of Agile to Complex, Multi-Project Environments

Over the past years, successful practitioners have applied Agile methods like Scrum and eXtreme Programming (XP) on individual projects to cut development lead times, improve product quality and reduce engineering cost.  For instance, time-to-market reductions in the range of 30-50% have been reported by leading companies.  Now, as these practitioners seek to expand on their initial successes, they face many complex obstacles posed by the realities of today’s business environment: distributed teams, outsourced development, interfacing with ‘non-agile’ vendors and customer organizations,  continued cost cutting, complex product suites, and the pressing need for innovation.

How can agile practitioners apply the fundamental tenets of Agile - integrated small teams, small releases, sufficient-to-purpose, etc - to provide the next round of significant returns from their Agile investment?   Sanjiv Augustine of LitheSpeed will lead a discussion on adopting a philosophy of smallness within bigness to allow the scaling of Agile practices beyond individual projects to deliver process improvements in complex environments with multiple projects and products. Technorati tag: Agile, APLN, Seattle, Sanjiv+Augustine, Project+Management