Abraham Lincoln used to ask a riddle: “If you call a tail a leg, how many legs does a dog have?”
Answer: Four, because calling it a leg doesn’t make it a leg.
Hiring the right people
April 10, 2008 By 1 Comment
General Colin Powell in his Leadership Primer says that:
“Organization doesn’t really accomplish anything. Plans don’t accomplish anything, either. Theories of management don’t much matter. Endeavors succeed or fail because of the people involved. Only by attracting the best people will you accomplish great deeds.”
So, how do you attract and choose the best people to work in your organization? What are the qualities that you look for when hiring people – is it the length of their resume, their past positions, their degrees or where they obtained them? Is it their familiarity and expertise with the specific technology or domain that the company needs at the moment?
Instilling a Sense of Urgency
April 7, 2008 By Leave a Comment
When people ask for “a sense of urgency” or “ownership” what they are really saying is “show me that you care about delivering this as much as I do”. Here are a few suggestions in an Agile context in no particular order of importance:
- Schedule the end of iteration demonstrations for the next 6-12 months – highly visible deadlines prevent teams from over-engineering solutions.
- Hold team members collectively accountable for team performance and for fulfilling job responsibilities. When things do not get delivered it is the team that has failed – freeloaders or those who are completely unsuited for the job will usually not be tolerated by high performing teams for long.
- A team’s performance is limited by the least invested individual. Such people dampen everyone’s morale and it is essential to quickly counteract people who habitually over-promise, make excuses, reject responsibility, complain, and lack commitment. While some skepticism up-front is healthy, perpetual grousing is not. To counter this, it is essential to clearly define and communicate behavioral expectations up-front and the consequences of not changing (if any).
- Clearly define and communicate expectations for decision-making including span of control and scope. This is to ensure that the team is not waiting around to be told what to do next.
- Require teams to develop corrective action plans for performance that is not meeting goals.
- Set a good example by promptly responding to questions, concerns, and escalated problems. Clearly communicate time frames for follow-up and consistently follow-up within these time frames.
- Help team members separate facts from emotional baggage.
- Recognize individuals and teams that respond with urgency.
- Discuss Chris Avery’s Responsibility Process Model or Roger Conners’ Oz Principle early in the transition process and refer to either at appropriate junctures.
Lean software development at current client
April 5, 2008 By 1 Comment
I recently got invited back, for the third time, by a client in the “Leisure, Travel & Tourism” industry to develop applications for their Cruise business. I play the role of an Engagement Manager and Business Demand Manager, whereby I am responsible for business idea harvesting and business idea vetting for the client
In the past two years, this client has moved from a crappy Agile implementation to doing Agile the right way to implementing a lean software development system. They have taken the concept of smaller batches, removal of waste, and continuous flow of value to heart.
[Read more...]
Breaking Agile Rules!
April 5, 2008 By Leave a Comment
I recently encountered a situation where we had three development teams working on the same product. Two separate clients that were supposed to act as one had jointly financed the project and were planning to individually sell it to educational institutions in their respective states (Texas and New Mexico). Needless to say the goal of acting as one never happened and conflicting requirements became the norm. Conversations were not working as the clients could not agree amongst themselves; prioritization wasn’t working as the clients had different short-term needs and were afraid that the other client’s needs would be given preference.
RUP isn’t agile but some of its principles are worthwhile
April 5, 2008 By 5 Comments
Why RUP isn’t Agile?
I work with a number of people who come from a RUP background and who claim that RUP is Agile because RUP calls for iterative development. While a cursory reading of RUP literature may show that the RUP framework doesn’t really mandate anything — it is a framework not a process — and leaves things up to the team and organization, it’s spirit couldn’t be further from Agile. I just have a hard time reconciling some of the ideas behind RUP to Agile values and principles
