This is the second in a series of posts about building great software. The series started here.
In my last post, I introduced the idea that great agile teams exhibit a set of attributes that clearly distinguish them from legacy teams using waterfall approaches. Their techniques are also quite different from software teams who claim to practice agile software development but don’t. Here are the attributes I listed in that post:
- They are highly cohesive, loosely coupled and decentralized.
- They implement constant feedback cycles and continuous improvement.
- They are known for rapid responsiveness and swarming behavior.
- They have diverse skill sets and share a common vision.
This post focuses on the first entry on the list — They are highly cohesive, loosely coupled and decentralized. What does that mean? Let’s break it apart.
In simple terms, a cohesive team is one that is closely united. The team members stick together. Their activities are logically consistent and supportive of one another.
These characteristics can’t be fully developed during the course of a single software release cycle — for example, 3-4 months. It takes time for great teams to “gel”. It’s not easy. Some companies fail at agile software development simply because they expect too much, too soon. Invest in training and coaching, and give it time.
Great software teams are able to split large chunks of work (often called “epics”) into smaller elements (“stories”) and deliver working software iteratively and incrementally. They don’t rely upon a single individual to fully define or implement a major system capability. Anyone can select a portion of the system and work on it.
This doesn’t mean that everyone on the team needs to know everything. Refer back to “highly cohesive”. Team members help each other and accomplish their tasks collaboratively.
This term is self-explanatory and one of the most difficult attributes for enterprise organizations to implement. Enterprise managers are measured by their ability to control and execute. There is usually an expectation that every decision the team made — everything the team did — was pre-approved by a manager. If the team succeeds, it’s because of the manager. If the team fails, the manager takes the heat. If you were a manager in that situation, how would you handle it?
Great managers lead. They do not control. Great managers do not make all the team decisions. They do not approve everything. They most certainly do not make everyone wait while they “think about” the situation.
Great organizations decentralize. That does not mean that software development teams are allowed to run wild and do whatever they want. No! Great organizations enable their managers to lead. They establish goals. They offer guidance. They monitor and measure. They remove impediments.
How does your software development team measure up?
Is your team highly cohesive in your opinion?
Is your team loosely coupled?
Is your organization decentralized?
If you answered “no” to any of these questions, implementing Scrum, Kanban or any agile approach will be difficult. You are likely to end up with some form of iterative (or incremental) waterfall. That’s not a bad thing but it’s neither agile nor adaptive.
I’ll continue this discussion in my next post. In the meantime, please join the conversation.
[The next post in this series is here.]
Leave a comment
- June 2013 (8)
- May 2013 (13)
- April 2013 (13)
- March 2013 (13)
- February 2013 (12)
- January 2013 (12)
- December 2012 (7)
- November 2012 (11)
- October 2012 (12)
- September 2012 (8)
- August 2012 (11)
- July 2012 (13)
- June 2012 (12)
- May 2012 (13)
- April 2012 (13)
- March 2012 (13)
- February 2012 (12)
- January 2012 (13)
- December 2011 (12)
- November 2011 (12)
- October 2011 (13)
- September 2011 (14)
- August 2011 (18)
- July 2011 (13)
- June 2011 (18)
- May 2011 (19)
- April 2011 (16)
- March 2011 (21)
- February 2011 (20)
- January 2011 (22)
- December 2010 (21)
- November 2010 (16)
- July 2010 (2)