List of Lean or Agile Community Groups

Here is a list of both Google and Yahoo groups that have some focus on Lean and/or Agile Development. You will need to sign up with Google and Yahoo to join these groups. Most of these groups are very active and you will find it's a good resource for both newbies as well as seasoned agilists. Enjoy!

Google Groups:
Agile Tangents (http://groups.google.com/group/agile-tangents) - Good overall discussions around all things Agile

Yahoo Groups:
Agile Project Management (http://finance.groups.yahoo.com/group/agileprojectmanagement/) - Focus on the management side of Agile projects

Test Driven Development (http://tech.groups.yahoo.com/group/testdrivendevelopment/) - Everything you want to understand about this practice also known as TDD

Scrum Development (http://groups.yahoo.com/group/scrumdevelopment/) - Emphasis on just Scrum brought to you by the Scrum Alliance

Lean Development (http://tech.groups.yahoo.com/group/leandevelopment/) - Focus on the content of the Lean Development books by the Poppendieck's

LeanAgileScrum (http://tech.groups.yahoo.com/group/leanagilescrum/) - A newer group started by Alan Shalloway from Net Objectives. Brings together Lean, Agile and Scrum discussions in one place and talks about how they work together.

If there are other community groups, please let me know by responding via comments. They can be other Google or Yahoo groups or other types of communities that focus on Agile or Lean.

Good document on Scrum

Graeme Matthew has provided an in-depth look at Scrum. You can get the document here.

Overcoming Fears with Collaboration

Since Agile is so team-centric, collaboration between team members and customers is essential for success. However, for some people collaboration isn't an easy thing. There may be some fears that need to be overcome to fully see the benefits of collaboration.

Fears fall into these categories:

1) External Fears - The organization may have fears of being too transparent to their customers, competitors or other outside interests. Sharing too much information could be considered giving away company secrets to your competitor. Having your customers talk with other may uncover issues they have with your organization. Your customer may have information you might not want to hear (but should).

2) Organizational Fears - Executive management is supposed to drive the long term vision and strategy of the company. Operational teams are supposed to implement this strategy. But what if the two groups should clash? What if the operational teams come up with ideas that will cause a need to change the direction of the company? What if strategy is on a "need to know" basis and executive management doesn't give enough information to operational teams? What if management doesn't trust operational teams? What if operational teams don't trust management?

3) Individual Fears - Perhaps the individual hasn't had the education and skills developed that encourage collaboration. Most people grew up going to school where the teacher talks and everybody listens. The teacher gives you the homework and you follow the instruction. No coloring outside the lines. No challenging ideas. Speak when spoken to. Then, that person starts their career where the manager talks and you listen. The manager gives you tasks and you complete them. Same structure, but highly different than a collaborative environment.

So, how do you combat these fears?

1) External Fears - Managers worry about transparency because they think that outsiders don't know what is going on in the company, but in this Information Age the opposite is true. Customers will talk with other customers. Competitors will find out what you are doing. The competitive advantage is no longer how you hold on to information, but how quickly and better you can implement those ideas. Once you understand this, you will be more open to knowing what is out there. The more transparent the organization can be in an collaborative environment, the more accurate you will meet the needs of those "outsiders". The competitor who is most open and both listens and responds to what is being said, the better they will be.

2) Organizational Fears - Collaborative environments have one thing in common - an environment of high trust and respect for each individual. Strategies need to be shared. Everybody may have knowledge on any topic so every topic should be shared. People need to understand the vision. Most of all, everybody in the organization should help influence where the company needs to go. It's not just Executive management's role, but everybody who has a stake in the company.

3) Individual Fears - New people have the most opportunity for collaboration because they come with a fresh and naive perspective. No questions are "dumb" ones. Organizations need to encourage new employees to contribute in any way possible as soon as possible. There needs to be retraining and rethinking about how individuals should contribute. Some people are more comfortable in a verbal discussions. Others need time to digest information then respond. Yet others feel more comfortable in "tweaking" existing ideas instead of coming up with new ideas. Others like to respond in writing. You need to provide an environment that plays to each person's strengths and allows them to participate.

Pipelining is not Lean

LeadingAnswers has a thought-provoking post today called "The Pipelining Anti-Pattern". Here's how Mike describes it:

If you have analysts working ahead of development, or have testers working significantly behind development, then you may have “Pipelining” problems. Pipelining is the term used to describe the situation when business analysts are working ahead on the requirements for a future iteration; the development team is working on the current iteration, and the test team is engaged on a previous iteration. In some circumstances analysis may be several iterations ahead and testing several iterations behind. To some people this may seem an efficient use of resources with each group running at their optimal speed, unfettered by the co-ordination constraints of different groups. However from an agile and lean perspective this is problem, a bad-smell that needs fixing.

Here are the problems with pipelining:

Three teams not one – in a project where pipelining is occurring we do not have one cohesive team we have three teams (or more). It is hard enough co-ordinating the members of one team towards a common goal aligned to business benefits. When there are three teams it is just too easy for people to claim that they did their bit and problems lie with other groups. Yet, the fact remains that if the software does not meet business satisfaction then it is everyone’s problem.

Increased Work In Progress (WIP) – Requirements whether they are in the form of user stories, use cases, or formal specifications all represent work invested that has not delivered value to the business. The same goes for code, until this functionality has been tested to the satisfaction of the business it is not valuable. As the time increases between capturing the requirement and finishing the last test two problems occur. The first is classic accounting, money have been invested for no return yet and there is a risk associated with future returns. The second is that requirements decay; the longer we keep requirements around for, the higher the likelihood that they will no longer be required or will have to change.

Increased time from defect injection to defect remediation – the cost of change increases the longer a defect goes undetected. In a pipelining project, defects introduced by faulty analysis could take months to be detected in testing or user review. Fixing the problem after this period of time will entail refactoring far more code (for the work happening in the interim) than if it was detected earlier, and will increase technical debt...

Time fragmentation costs when groups collaborate – on pipelining projects the test group could be working on iteration 2, the developers on iteration 4, and the analysts on iteration 5 or 6. If a developer has a question for an analyst or a tester for a developer then task switching costs will be incurred. Task switching is the time required to respond to an off-topic interruption. We must mentally “park” our current work, try to think back to whatever it is this person who has interrupted us is asking about, recall the details, answer their questions and then resume where we left off. The problem with this is that studies have shown people, while great at many things, are generally very poor at task switching. Our recall of past details is poor, defense mechanisms in our brain designed to dull unpleasant experiences erode memories of nasty problems, and we are terrible at remembering where we parked our current thoughts. The net result is that just a few requests to recall past events really mess up our performance and yield low quality answers to the enquirer.

Throughput optimization – three or more teams running through work at their own speeds with fewer dependencies on others may seem like it is working, but from a systems perspective it is a problem. Processes running at different speeds require work buffers to avoid running out of work and they build piles of unfinished work. This inventory is waste in the system and leads to scrap and more rework as processes change and partially completed work needs to be updated.

I really think Mike is on to something. I have seen this struggle in our own product teams. Read more of the post to understand this problem as well as see how Mike addresses it.

A Simple Look of Lean and Agile

Somebody asked me if I were to talk about the relationship between Lean, Scrum and XP what would that be in the "simplest way possible" (At our organization, we are implementing all three). Here's how I answered:

Lean introduces the principles, or the "why's" of producing software. Focus is on maximizing customer value while minimizing waste to provide the most optimal ROI.

Scrum takes those principles and introduces the management practices, or the "when's" of producing software. Focus is on incremental delivery of working solutions that improve over time.

XP takes Lean principles and Scrum practices and introduces the technical skills, or the "how's" of producing software. Focus is on constant improvement of skills (and the underlying infrastructure) through analysis, design, and implementation of producing software.

It is my strong feeling that you really need all three to maximize your effectiveness in the development of software. Individually, each part can be implemented on it's own but you will discover something missing. Together, these really cover all aspects of developing a successful software solution.

The Exposure of Lean and Agile

A few years ago, I attended a local conference on Software Quality. We were just starting to roll out our own Agile implementation, so I was eager to hear some discussion from others at the conference. In the keynote, there was an introduction to Agile. The speaker polled the audience to see what they knew about it. I would guess that probably 75% hadn't even heard of Agle, and out of the other 25% only a few were actively using Agile practices. There was absolutely no discussion around Lean development as well. I was sorely disappointed that there wasn't more of a buzz, as I could see great potential in adopting Agile. This was 2004.

Last week, I attended a one-day seminar on Collaboration. This was by no means a technical conference, in fact there were many people who weren't even in the software industry. For those that did develop software, they were more of the project manager or program manager types. I surely didn't expect much to be talked about Lean or Agile. I was VERY surprised. It seemed that most people were actively using some Agile practices, and those that were not were eagerly listening to others. It seemed most talked had something around Agile or Lean, or the discussions following the talks would discuss either one. There were a few who had already made the connection between Lean and Agile. Most surprising of all, there was much discussion with the people outside of the software industry about how Lean and Agile could be adapted to work outside of software development and be used for other types of projects! Now, in 2007, people are seeing that potential for their own.

Talk about a transformation in such little time! It's an exciting time to be involved with software development.

Is something missing in the Agile Manifesto?

Brian Marick believes so. His post, "Six years later: What the Agile Manifesto left out" explores some missing values that aren't readily apparent by reading the Manifesto but are essential to have to be successful in Agile. Here's a summary of it (I've made bold the values that he believes is missing):

Now Agile is more respectable, a safer choice. The challenge isn’t so much getting a chance at Agile as it is executing once you’ve gotten the chance. There, the values of the Manifesto are not so helpful. Except for “individuals and interactions”, they face outward from the team. They don’t strongly apply to the relationships between team members, between the teams and their environments, and between the teams and their code. That’s a problem, because it seems to me that many new Agile teams are not executing. They’re floundering.

What should teams do with the time they’re not spending going too fast? They should invest in one of the four values I want to talk about: skill. Two skills that apply to pretty much any software project are refactoring and programmer testing (test-driven design). Those are skills that require a great deal of discipline. It’s awfully tempting not to write a test when it’s harder than writing the code, or to refactor some icky code you stumble on when that would mean blowing your estimate. Some of XP’s practices help with discipline. Pair programming turns what could be a solitary vice into a social act: you and your pair have to look at each other and acknowledge that you’re about to cheat. Peer pressure comes into play, as it does because of collective code ownership. Someone will notice the missing tests someday, and they might know it was your fault. Maybe the key driver of discipline is the practice of creating working software—running, tested features—at frequent intervals. If you’re doing that, you just don’t have time for sloppiness. You have to execute well.

I’ve observed that a characteristic of a good code base is that it’s habitable, that changes are comfortable, that the process of programming is one of ease. Agile teams suffer because they don’t think that wanting to make their lives easy is a relevant value, but it should be. There’s absolutely nothing wrong with finishing up a story by spending a half hour or so tinkering with code you’ve touched, just improving it—doing the software equivalent of hanging power within easy reach because the power strip on the desk is always annoying you.

I think Agile is suffering today because these fundamental values didn’t get written down and are too easily forgotten. As Agile moves into bigger companies and into less adventurous ones, those undocumented values are getting watered down. If that continues, I’m afraid Agile will be this decade’s fad that changes nothing. That would be sad.

Read more in his post.

Can CMMI and Agile play well together?

Brad Appleton on his ACME Blog has a very extensive list of links that say "YES". As a follower of CMMI in the past, this will be interesting reading to me to see what others are thinking.