In the early days of Scrum, we talked a lot about chaos theory and self-organization. We wanted to believe that “management” was unnecessary and even counter productive to getting software built. Well, after 15 years and many, many agile projects (some more successful than others), I’ve formed some pretty strong opinions on how self organization and team leadership impact a software project’s success.
(1) A team has to have a strong, management supported leader. For purposes of this discussion, this is the team lead. Its not important what title is on the team lead’s business card. It may be Development Manager, Project Manager, ScrumMaster, Program Manager or whatever other label your organization is comfortable with. What is important is the knowledge and experience of the team lead.
(2) The team leader must have at least five years hands-on experience actually building software (I am assuming here that we’re talking about building software products). By this, I mean that the lead has spent 5 years designing, coding, testing, delivering and supporting software products. Ideally, the team lead has some experience with domain for which the product is being built, but this is not a requirement.
(3) The team lead has equal and balanced knowledge, respect and appreciation for all disciplines required to get software built. This is essential to successfully manage a cross-functional agile product development team. As such, the team lead can dive into details with team members to help remove impediments regardless of whether it’s a development, test, scope, or documentation issue. If one discipline is favored, the product will be out-of-balance. The classic pitfall is for a team lead to be too engineering focused. The end result is often that “technology” is produced rather than a product. The features become internally driven. Market focus and the customer connection is lost.
(4) The team lead owns the resources and schedule. The team lead has authority and control to direct and modify project resources. Also, operating with-in bounds defined by the business, the team lead can alter the schedule.
(5) With authority and control comes accountability. The team lead is held accountable for resource and schedule issues.
(6) The team lead does not control scope. The primary owner of scope is the “customer proxy.” The customer proxy may actually be the end user on consultative and internal projects, a business analyst or business unit representative, or a Product Manager for commercial software products. The team lead can influence and negotiate scope changes with the customer proxy. I’m going to avoid a deeper discussion on scope change control at this point.
So… self-organization… As a leader in many past businesses, I am unwilling to put my business at risk. I am a strong advocate of preemptive, proactive business and team leadership. There is an important balance though. Management and the team lead must not squelch innovation with heavy-handed oversight and control. There does need to be self organization within the team. During any project of significant scope and duration, priorities will shift. Certain skills and attributes will become more important than others. A well functioning agile team reflexively compensates and the team member with appropriate skills and knowledge steps up. This is important. If the team is functional, this just happens. It’s not planned, managed, or dictated. A good team lead recognizes when its happening, and when its not, the team lead takes action.
Comments