Friday, November 24, 2006
Agile CMMI blog
From a comment on this blog, I discovered the Agile CMMI blog. Seems like a great resource to find out about the growing interest in reconciling these 2 worlds.
Friday, November 17, 2006
Agile CMMI - it is possible
BoldTech Systems just achieved CMMI Level 4 at their Hangzhou, China office, where I'm currently working as an agile coach. And they did so legitimately, while following essentially agile practices. I say legitimately because many companies appear to finagle a CMMI via a smoke-and-mirrors appraisal process. In fact, BoldTech's Hangzhou organization went from level 1 to level 4 in just 2 years.
BoldTech was a pioneer in the adoption of agile methodologies, practicing hard-core XP when I starting working there in 1999. And I do mean hard-core, including 100% pair programming. Since then, the methodology has evolved from pure XP fundamentalism to a pragmatic adaptation of agile techniques based on years of hard lessons learned. Some of the practices in the trenches are not nearly as agile as I would like them to be, but on the macro level it's definitely agile.
I'm not a big fan of CMMI, but that's primarily because it's so often misapplied to enforce a rigid process for the sake of the process, and not because the process provides value to customers. If you keep the right focus and do a sensible tailoring of the CMMI practice areas, you can be agile and CMMI compliant at the same time.
BoldTech was a pioneer in the adoption of agile methodologies, practicing hard-core XP when I starting working there in 1999. And I do mean hard-core, including 100% pair programming. Since then, the methodology has evolved from pure XP fundamentalism to a pragmatic adaptation of agile techniques based on years of hard lessons learned. Some of the practices in the trenches are not nearly as agile as I would like them to be, but on the macro level it's definitely agile.
I'm not a big fan of CMMI, but that's primarily because it's so often misapplied to enforce a rigid process for the sake of the process, and not because the process provides value to customers. If you keep the right focus and do a sensible tailoring of the CMMI practice areas, you can be agile and CMMI compliant at the same time.
Friday, October 27, 2006
The seating chart
What formation is your team in during the daily stand-up meeting? Hopefully it's close to a circle, where each team member can make eye contact with every other team member. Many studies have shown that a significant amount of the information conveyed in a conversation is non-verbal, so make sure everyone is getting the full story.
Is everyone facing the leader/scrum master? This could be a problem. The leader should be a facilitator for the meeting which is held primarily to share information among all the team members. It's not just a status report to the leader/facilitator.
For longer meetings such as iteration planning sessions, pay attention to the seating; the same principles apply. Arrange chairs in a circular or semi-circular fashion.
Is everyone facing the leader/scrum master? This could be a problem. The leader should be a facilitator for the meeting which is held primarily to share information among all the team members. It's not just a status report to the leader/facilitator.
For longer meetings such as iteration planning sessions, pay attention to the seating; the same principles apply. Arrange chairs in a circular or semi-circular fashion.
Wednesday, October 18, 2006
The 3 Scrum questions and the language impediment
"What is your name?"
"What is your quest?"
"What is the velocity of an unladen swallow?"
Wait, sorry - those 3 questions are for the bridge of death - they have nothing to do with agile software development.
One of the 3 questions each team member answers during the daily Scrum (daily stand-up meeting) is, "are there any impediments to your work?"
I am currently working in China with a team building a web app for a US-based client. One of our impediments is the language barrier. In fact, the word "impediment" itself isn't in the vocabulary of my Chinese colleagues. So how do you ask if there are any impediments?
I ask if they have any "problems or issues", but that's not quite the right. As the scrum master/agile coach, I've found that the following question hits the mark:
"What is your quest?"
"What is the velocity of an unladen swallow?"
Wait, sorry - those 3 questions are for the bridge of death - they have nothing to do with agile software development.
One of the 3 questions each team member answers during the daily Scrum (daily stand-up meeting) is, "are there any impediments to your work?"
I am currently working in China with a team building a web app for a US-based client. One of our impediments is the language barrier. In fact, the word "impediment" itself isn't in the vocabulary of my Chinese colleagues. So how do you ask if there are any impediments?
I ask if they have any "problems or issues", but that's not quite the right. As the scrum master/agile coach, I've found that the following question hits the mark:
What can I do to help the team?With those eight short words, I've found that I get much more insightful responses, and can root out some important impediments.
Monday, October 16, 2006
One developer per feature
When you're planning an iteration, you start with user stories, break them into tasks, make estimates, commit to the iteration scope, and then begin working (as a collaborative, sel-organizing team, of course).
My past 2 project teams have both concluded that it's better to have 1 person (or pair of programmers) develop an entire feature than to have different people working on different sub-tasks. Avoid the temptation to break a story into layered tasks such as "build the DB", "build the domain objects", and "build the UI" -- with each task worked by different people. You may have people who specialize in only one of these layers, but your team will be more productive and flexible in the long run if everyone has broader skills. Besides, having 3 different people working on 1 feature requires lots of coordination and presents lots of opportunities for miscommunication. Instead, have one person (or pair, for you pair-programming zealots) build the whole shebang.
In OO development, we aim to minimize coupling between components and maximize cohesion within components. This is the same concept. Each developer is a component of the team, and you want to minimize the amount of coupling required between developers; when coupling (communication) is required, you use the most effective means of communication possible - face to face conversation. At the same time, you want to maximize developer's internal cohesion - by letting him/her focus on a single feature.
Of course, to do this, you need to have stories/features which are small enough for 1 person to complete within a single iteration. But that's a worthy goal for many other reasons, too.
My past 2 project teams have both concluded that it's better to have 1 person (or pair of programmers) develop an entire feature than to have different people working on different sub-tasks. Avoid the temptation to break a story into layered tasks such as "build the DB", "build the domain objects", and "build the UI" -- with each task worked by different people. You may have people who specialize in only one of these layers, but your team will be more productive and flexible in the long run if everyone has broader skills. Besides, having 3 different people working on 1 feature requires lots of coordination and presents lots of opportunities for miscommunication. Instead, have one person (or pair, for you pair-programming zealots) build the whole shebang.
In OO development, we aim to minimize coupling between components and maximize cohesion within components. This is the same concept. Each developer is a component of the team, and you want to minimize the amount of coupling required between developers; when coupling (communication) is required, you use the most effective means of communication possible - face to face conversation. At the same time, you want to maximize developer's internal cohesion - by letting him/her focus on a single feature.
Of course, to do this, you need to have stories/features which are small enough for 1 person to complete within a single iteration. But that's a worthy goal for many other reasons, too.
Saturday, August 12, 2006
The 7 Habits of Highly Effective Agile Teams
After reading Stephen R. Covey's The 7 Habits of Highly Effective People, I was struck by the commonalities between some of the principles in his book and those of agile development.
This is how I see the two come together.
Habit 1: Be Proactive
The essence of this habit for me can be summarized with a single quote from Covey:
Our behavior is a function of our decisions, not our conditions.
When the team is subject to outside influences, changing priorities, and “scope creep”, it can complain, or it can:
1. choose to explain to these outsiders from management, marketing, etc., the consequences of changing direction in mid-iteration
2. choose to drop lower priority features
3. choose to abort the sprint/iteration and plan a new one
4. choose to accept that stakeholders, not developers, have responsibility and accountability for setting product priorities
A strong product owner and scrum master should provide the leadership and courage to make this happen.
Habit 2: Begin with the end in mind
Agile teams should start a project, a release, an iteration, and each day with a clear vision of the goal. The 5 levels of planning provide that vision:
- Product vision statement
- Product roadmap
- Release plan
- Iteration/sprint plan
- Daily plan (from daily stand-up/scrum meeting)
Habit 3: Put first things first
This habit emphasizes personal management to prioritize your life; allocate plenty of time for activities which are important, but not urgent (What Covey calls “Quadrant II” activities).
Scrum and XP both emphasize the importance of prioritizing. XP in particular, with it’s rigorous discipline around engineering practices, ensures that the team is investing time to achieve a high and sustainable velocity.
Particularly, the XP practices of refactoring and test-driven development are prime examples of Quadrant II activities. In Scrum, an effective product owner, scrum master, and team should collaborate to ensure that the product backlog and spring backlog address not only the highest priority business features, but also technical activities required to maintain a productive team environment.
Habit 4: Think win/win
Because agile teams are:
1. Self-organizing and self-motivated by a personal commitment to achieve the sprint goal
2. Not bound by a rigid and prescriptive process
3. Able to quickly adapt to changing business priorities
4. Empowered to insist on high quality
5. Working in a sustainable manner
Then they are free to seek solutions which meet the needs of customers and at the same time provide developers with opportunities to learn, grow, and produce the highest quality product.
Habit 5: Seek first to understand, then to be understood
An agile team’s number one focus is to deliver value to the customer. The team collaborates closely with customers to fully understand the product, it’s goal, and it’s features. Once the team has this understanding, and has proven that it can quickly deliver value, then it will build the trust required for those occasions when negotiating with customers and stakeholders is required. (We value customer collaboration over contract negotiation. But we still gotta negotiate sometimes!)
Habit 6: Synergize
Agile teams are deliberately cross-functional; they consist of people who specialize in fields such as database development, UI development, and testing. In agile development, we intentionally throw people with these diverse skill sets into close quarters and “shake well” to ensure that they collaborate closely. Agile teams truly value the specific strengths of each team member and seek to get the maximum synergistic benefit from the creative combination of everyone’s skills.
On agile teams, we don’t stifle creativity and cooperation by putting team members in competition with one another; we reward the entire team for meeting it’s collective goal. We don’t manage by command-and-control; we let self-organizing teams use their collective wisdom to find the best method to reach the goal.
Habit 7: Sharpen the saw
This habit is about the importance of physical, mental, spiritual and social self-renewal.
Agile teams have frequent retrospectives. This is the time when the team re-examines the effectiveness of it’s practices and reconsiders it’s activities in light of the project goal and agile principles. This is one form of renewal.
By creating a culture and environment which values sustainable development, individual self-renewal is possible. But it should also be encouraged. An agile team should also provide team members the personal time to research technologies, tools, and topics that interest them and will expand their knowledge and understanding. Even if the topic doesn’t have an apparent application on the current project or iteration, the investment of time will pay big dividends in the long term.
This is how I see the two come together.
Habit 1: Be Proactive
The essence of this habit for me can be summarized with a single quote from Covey:
Our behavior is a function of our decisions, not our conditions.
When the team is subject to outside influences, changing priorities, and “scope creep”, it can complain, or it can:
1. choose to explain to these outsiders from management, marketing, etc., the consequences of changing direction in mid-iteration
2. choose to drop lower priority features
3. choose to abort the sprint/iteration and plan a new one
4. choose to accept that stakeholders, not developers, have responsibility and accountability for setting product priorities
A strong product owner and scrum master should provide the leadership and courage to make this happen.
Habit 2: Begin with the end in mind
Agile teams should start a project, a release, an iteration, and each day with a clear vision of the goal. The 5 levels of planning provide that vision:
- Product vision statement
- Product roadmap
- Release plan
- Iteration/sprint plan
- Daily plan (from daily stand-up/scrum meeting)
Habit 3: Put first things first
This habit emphasizes personal management to prioritize your life; allocate plenty of time for activities which are important, but not urgent (What Covey calls “Quadrant II” activities).
Scrum and XP both emphasize the importance of prioritizing. XP in particular, with it’s rigorous discipline around engineering practices, ensures that the team is investing time to achieve a high and sustainable velocity.
Particularly, the XP practices of refactoring and test-driven development are prime examples of Quadrant II activities. In Scrum, an effective product owner, scrum master, and team should collaborate to ensure that the product backlog and spring backlog address not only the highest priority business features, but also technical activities required to maintain a productive team environment.
Habit 4: Think win/win
Because agile teams are:
1. Self-organizing and self-motivated by a personal commitment to achieve the sprint goal
2. Not bound by a rigid and prescriptive process
3. Able to quickly adapt to changing business priorities
4. Empowered to insist on high quality
5. Working in a sustainable manner
Then they are free to seek solutions which meet the needs of customers and at the same time provide developers with opportunities to learn, grow, and produce the highest quality product.
Habit 5: Seek first to understand, then to be understood
An agile team’s number one focus is to deliver value to the customer. The team collaborates closely with customers to fully understand the product, it’s goal, and it’s features. Once the team has this understanding, and has proven that it can quickly deliver value, then it will build the trust required for those occasions when negotiating with customers and stakeholders is required. (We value customer collaboration over contract negotiation. But we still gotta negotiate sometimes!)
Habit 6: Synergize
Agile teams are deliberately cross-functional; they consist of people who specialize in fields such as database development, UI development, and testing. In agile development, we intentionally throw people with these diverse skill sets into close quarters and “shake well” to ensure that they collaborate closely. Agile teams truly value the specific strengths of each team member and seek to get the maximum synergistic benefit from the creative combination of everyone’s skills.
On agile teams, we don’t stifle creativity and cooperation by putting team members in competition with one another; we reward the entire team for meeting it’s collective goal. We don’t manage by command-and-control; we let self-organizing teams use their collective wisdom to find the best method to reach the goal.
Habit 7: Sharpen the saw
This habit is about the importance of physical, mental, spiritual and social self-renewal.
Agile teams have frequent retrospectives. This is the time when the team re-examines the effectiveness of it’s practices and reconsiders it’s activities in light of the project goal and agile principles. This is one form of renewal.
By creating a culture and environment which values sustainable development, individual self-renewal is possible. But it should also be encouraged. An agile team should also provide team members the personal time to research technologies, tools, and topics that interest them and will expand their knowledge and understanding. Even if the topic doesn’t have an apparent application on the current project or iteration, the investment of time will pay big dividends in the long term.
Tuesday, July 18, 2006
Managing your personal life with Scrum
Pete Deemer posted this thought-provoking message on the yahoo scrumdevelopment group about using Scrum to manage his personal time. His "life backlog" consists of everything from chores, to exercise, to quality time with his family.
Sprint planning takes place weekly, where he typically commits to about 10 hours' worth of personal tasks. He always keep some free time unallocated, to maintain his spontaneity (and sanity). He also has a daily scrum meeting with himself each day, and tracks his personal burndown chart on the kitchen wall.
I love the idea of using Scrum's simple techniques for organizing one's life. What do you think?
Sprint planning takes place weekly, where he typically commits to about 10 hours' worth of personal tasks. He always keep some free time unallocated, to maintain his spontaneity (and sanity). He also has a daily scrum meeting with himself each day, and tracks his personal burndown chart on the kitchen wall.
I love the idea of using Scrum's simple techniques for organizing one's life. What do you think?
Thursday, July 13, 2006
Book summary: Collaboration Explained
I read Jean Tabaka's book: Collaboration Explained: Facilitation Skills for Software Project Leaders. It describes many techniques an agile leader should keep handy in his/her toolbox - I recommend it.
Here is a brief summary of some of the salient points from the book.
Collaboration and servant leadership
In a collaborative culture, teamwork and self-organizing teams are highly valued. A collaborative culture is on the opposite end of the spectrum from a command and control culture. Leaders seek to get the best out of the team by optimizing their collaboration and protecting the team from outside influences which work against collaboration. The agile leader should be a servant leader:
Teams go through 4 stages on the route to high performance, and they need different leadership techniques at each stage.
A good rule of thumb is for the leader/facilitator to spend 2 hours preparing for every 1 hour of meeting time.
Teams should strive for consensus on major decisions, but it can take considerable time and effort to reach a consensus. Teams should decide in advance which decisions require consensus and which can be decided more quickly (by majority vote, for example).
Use the "fist of five" technique to measure consensus. When someone in the group has proposed a decision, ask everyone to simultaneously to show a number of fingers indicating their level of agreement:
Thomas-Kilmann conflict resolution mode
The following lists the modes and how often teams should strive to resolve conflict via that mode:
The book is full of useful techniques in these areas:
Here is a brief summary of some of the salient points from the book.
Collaboration and servant leadership
In a collaborative culture, teamwork and self-organizing teams are highly valued. A collaborative culture is on the opposite end of the spectrum from a command and control culture. Leaders seek to get the best out of the team by optimizing their collaboration and protecting the team from outside influences which work against collaboration. The agile leader should be a servant leader:
...in a position of strength, they determine that the greatest power they can wield is in service to their teams as leader.Some attributes of a servant leader
- Goal setting to guide the team rather than prescribing tasks
- Listening as a means to lead - ask questions!
- Clear sense of values
- Personal growth
- Tolerance of imperfection - trust the team's decisions
- Positive attitude
Teams go through 4 stages on the route to high performance, and they need different leadership techniques at each stage.
- Forming
- Storming
- Norming
- Performing
- Self-organizing (vs. title or role-based)
- Empowered to make decisions
- Members believe they can solve problems for themselves
- Committed to success as a team
- Motivated by trust, mutual respect and mutual accountability
- Engage in participatory decision making
- Decisions are consensus-driven
- Constructive disagreement is healthy
A good rule of thumb is for the leader/facilitator to spend 2 hours preparing for every 1 hour of meeting time.
- Interview the meeting sponsor
- Survey participants
- Set the agenda
Teams should strive for consensus on major decisions, but it can take considerable time and effort to reach a consensus. Teams should decide in advance which decisions require consensus and which can be decided more quickly (by majority vote, for example).
Use the "fist of five" technique to measure consensus. When someone in the group has proposed a decision, ask everyone to simultaneously to show a number of fingers indicating their level of agreement:
- 5 fingers: I'm wildly enthusiastic about it
- 4 fingers: I like the idea and fully support it
- 3 fingers: It's not perfect, but I can support it
- 2 fingers: I don't like it, and can't fully support it
- 1 finger: I am very much opposed to this idea
Thomas-Kilmann conflict resolution mode
The following lists the modes and how often teams should strive to resolve conflict via that mode:
- Collaboration: 65%
- Compromise: 20%
- Avoidance: 10%
- Accomodation: 5%
- Competition: never!
The book is full of useful techniques in these areas:
- Meeting organizing tools, e.g. the parking lot
- Kicking off a meeting
- Gathering information
- Project & task estimating
- Processing and organizing information
- Retrospection and visioning
- Managing meeting participants
- Managing conflict
- Closing a meeting
- Action plans
- "A bridge to each desk"
- Practices for distributed teams
Thursday, June 29, 2006
Selenium: the 10-minute test
I spent some time today getting familiar with Selenium, an open-source web app test tool. Along with the Selenium IDE, which runs as a Firefox plug-in, it passed the 10-minute test with flying colors. It looks promising, and soon I plan to put it through a more rigorous test to see how well it handles javascript and DHTML.
Tuesday, June 27, 2006
Switching roles: scrum master to developer
I'm the Scrum Master (team leader) for a team of 5 developers working on a complex enterprise application at StorePerform Technologies. I haven't worked very closely with most of the team members prior to this project, but most of them worked on the same project for a long time. I started the project hoping that I could serve both as the team leader (following the Scrum principle of servant leadership) and a part-time developer. I reluctantly came to the realization that it doesn't work, at least not with a new team which is still in the Forming & Storming stage. As my colleague Yuri Gadow helped me understand, the likely result is that I will be a bad leader and a bad developer - the worst of both worlds.
The team has taken the concept of self-organizing teams to an extreme, and they resent any suggestions from the Scrum master. My goal is to gain more trust and respect from the developers so they'll be more open to my suggestions. My solution was to switch roles for a few sprints (iterations) - I will be a full-time developer, and hand over the Scrum Master duties to Yuri. I believe this approach has several benefits:
The team has taken the concept of self-organizing teams to an extreme, and they resent any suggestions from the Scrum master. My goal is to gain more trust and respect from the developers so they'll be more open to my suggestions. My solution was to switch roles for a few sprints (iterations) - I will be a full-time developer, and hand over the Scrum Master duties to Yuri. I believe this approach has several benefits:
- I can focus on doing one thing well: writing code
- I can keep my development skills honed
- As an equal peer to the other team members, they'll (hopefully) learn to respect my technical skills and experience
- I have the opportunity to "feel their pain" first-hand
- The team (including me) will experience a different leadership style from Yuri
Monday, June 26, 2006
Outsourced!
My job got outsourced to India. The rumors had been floating around StorePerform for a few days that something was up, and I figured there would be a few layoffs, but I got cold cocked. I didn’t expect that they’d offshore the entire product development, QA and support teams to India.
“I hope you got a good severance,” several people told me. Not a chance. Not at SP. Taking care of employees was never high on the executives’ list of priorities.
Fortunately, I’ve got a good network of friends and colleagues and it shouldn’t be too difficult jump back out of the unemployment line.
“I hope you got a good severance,” several people told me. Not a chance. Not at SP. Taking care of employees was never high on the executives’ list of priorities.
Fortunately, I’ve got a good network of friends and colleagues and it shouldn’t be too difficult jump back out of the unemployment line.
Subscribe to:
Posts (Atom)
Posts
