AGILE IN ACTION

In my ideal team anyone can do anything. Sadly it's just not realistic. Some skills are just too specialized. That said, if you need the specialized skills get a specialist in the team and avoid sharing some centralized service. Don't worry if the specialist is not utilized 100%. That's a good thing! If he has the right attitude he will muck in, contribute in other areas you did not anticipate, and he should use the opportunity to acquire complementary and even new skills by working with and learning from the rest of the team. And of course, it goes without saying that he should be helping others acquire a level of competence in his specialized skill set to build resilience into the team.

If you're a specialist then you probably have some expertise that enables you to objectively state a case for doing something or doing something in a certain way. And you should be able to persuade others that it is the right thing to do. Being the expert doesn't give you the right to make unilateral decisions in a team. Give your knowledge freely. You have an obligation to help people learn from you. Be approachable and share.

Think of a product stream as a small company working exclusively on a product and delivering features that excite users to maximize profit and growth. The stream invests in its relationship with users and is set up to compete on the basis of speed. It has everything it needs to conduct business, from concept to production to operational support, and unlike a project it persists as long as the product is in service. It includes a dedicated and diverse technical team that is actually part of the business and helps them use software more effectively. It self-organizes for optimum delivery and minimum risk, and produces flexible software that responds as the business learns from user and market feedback.

We're enjoying ourselves so much I'm wondering if it's illegal. We're working in a 4-man team with a new client (who consult for the Lean Enterprise Academy) and we're experimenting with some new techniques. Our goal is to create a product that is very kind to its users, so we're trying to stay as close as possible to the users' conceptual model and stop thinking like programmers all the bloody time. When we catch one another 'flipping' to techie mode we quickly 'flop' them back to user mode.

The product stream concept is a simple one. A product stream contains a self-organizing team and a product owner, yet it engages with the Business more deeply than just having business representation in the Product Owner. Engagement is the wrong word, I suppose, because it's more than that. Software development is absorbed back into the Business. It's no longer just aligned, it's integrated; it's part of the business.

Short posts with deep wisdom from Jason Yip: Over-specialisation leads to over-sized teams . Over-specialisation means that there is no small team that has enough knowledge to accomplish any project. Prioritise to maintain options . Every feature implemented before its time removes an option to defer that feature to protect schedule. Customers aren't disappointed when you don't meet your commitments ; they're disappointed when it means they can't meet theirs.