In The Five Dysfunctions of a Team: A Leadership Fable
, written by Patrick Lencioni, he discusses--well, five dysfunctions of a team.
Lencioni's style with his books seem to be a sort of fable-story-type narrative in the first part, and then real meat in the latter part. I have to confess I skipped about half of the fable stuff, but found the meat at the back to be very interesting.
The five dysfunctions he examines are:
- Absence of Trust
- Fear of Conflict
- Lack of Commitment
- Avoidance of Accountability
- Inattention to Results
Being a single guy, I could most readily identify with #3, Lack of Commitment. And the more I think about it, all of these dysfunctions could be more-or-lesss applied to dating.
His book comes complete with a team-assessment worksheet, and directions on how to identify and overcome these five dysfunctions. A good read for any manager.
Mike J Berry www.RedRockResearch.com
So I attended our SLC-based agile development forum yesterday. Alistair Cockburn was there, along with some other associates from around the valley. We discussed various successes and challenges with using the Agile Development Model for software development.
One particular topic that became a main discussion point was how to get government agencies to accept Agile Development Model contract bids. Fortunately, executives from several companies were represented in the room that use the Agile Development Model and pursue government contract work. They gave us some insight on how to proceed. The challenge is that the Waterfall Development Model (SDLC) is the traditional project development process for government contract submissions. They like it because it expresses a project in terms of scope, components, time-lines, and milestone dates. All of this is measurable, so it works very well with the government procurement types.
Agile is a less structured methodology--where you build requirements and code more in a module, by module format. These modules, called user-stories, aren't spec'd in detail until they are actually being worked on. Because of this, milestones and time-lines for an Agile project are not as predictable. The Agile Development Model accepts this reality, and suggests that most projects are not really so predictable anyway.
The trick with the Government is to bid your first project as a waterfall project. Then, after you have a relationship, suggest that forthcoming projects have an Agile model. You can also submit a Waterfall project with some additional requirements listed on the contract. ie: "Requirements base-lined at a high-level" or "Progress reported via Project Backlog" or "Prioritization by Need" or "Daily Scrum" or all of these things.
Mike J Berry www.RedRockResearch.com
There seems to be no set standard for development meetings. Some groups complain about being 'meeting'd to death,' while others complain about a lack of communication, direction, or group cohesion.
Given the two options, it is generally agreed that over-communication is much better than under-communication. One of the more innovative approaches to cutting down on meeting drain is the concept of the 'stand up meeting.' This is where all participants (except maybe senior citizens) stand for the duration of the meeting. Amazingly, during this process, nobody seems to have long weekend stories to tell the group, and answers and discussion points become more concise.
Normal development meetings ought to serve the following purposes.
- Communicate transparency from development to corporate.
- Communicate direction and prioritization from corporate to development.
- Communicate present-status and next-step planning regarding a project.
- Promote team-workload communication among team-members.
- Six month employee review.
- Deployment rehearsal.
More on these later...
Mike J Berry www.RedRockResearch.com
Many Software Development Managers find their way into the "coveted" position from attrition after being a development team lead, or senior architect. Having a technical background is an obvious advantage in terms of understanding the complexity dynamics the team deals with. One big reality, however, is that these vast technical skills are only a subset of what is required to become a great manager, and the new manager soon discovers he needs to learn much more about the role.
In Jack Welch's book Winning, he explains that being a good leader means you shift the focus from you to them--from being the only one able to solve the latest problem, to being the proverbial "dumbest person in the room." Accountability should come hand in hand with empowerment. Learning to empower your teams can be difficult, and seem like a leap of faith at first. You soon learn, however, that letting your team originate the solution, predict the schedule, perform the work, and solve the problem builds their trust in you and in themselves.
Another effective technique is to make your team accountable to the executive staff themselves--in person--instead of you being the go-between, shielding them. Have the team leads accompany you to the Executive Committee meeting to report their progress. This way, they can feel a sense of accomplishment for their victories, and feel the pressure from the top, instead of from you! Teach them to be commitment oriented. Develop a commitment-oriented culture by keeping track of their commitments and holding them accountable for each one. Base their bonus structure on their ability to keep their commitments. This will teach them to be more accurate, which translates into better predictability that that is better for everyone.
Joel Spolsky has a simple solution for this. It's called Evidence Based Scheduling and you can read about it here.
Mike J Berry www.RedRockResearch.com
I remember my grandmother explaining what it was like to teach grade-school. She said to be a good teacher, you had to be part teacher, part nurse, part referee, part coach, part police officer, part mother, and part collections agent. Fortunately, software development management requires a smaller skill-set. Software Development Managers really have four areas of responsibility. These four areas are:
- Responsibility to the corporation
- Responsibility to the development department
- Responsibility to the customer
- Responsibility to the product
To the corporation, the development manager owes efficient yield, predictability of delivery dates, and transparency regarding the health and status of each project. To the team, he owes corporate transparency (what goes on in the executive meetings), clarity of direction, priority of tasks, empowerment, and accountability. To the customer, he owes the highest reasonable product quality, and highest reasonable product relevance. And to the product, he owes the best tools, architectures, and programmers he can find.
Mike J Berry www.RedRockResearch.com