Saturday, January 31, 2009
Agile Twittering
In case you haven't already been bitten by the twitter virus (what else to call it?) the whole Agile world seems to be on twitter. Now, I'm there too! What's next? The hive mind? :-)
Tuesday, January 20, 2009
Getting Management and Engineers Out of Each Other's Hair
This is the fifth in a series of posts on self-management that began with "The Use of Self-Managing Teams Outside the Context of Software Development."
Short Iterations Increase Management Leverage
One of the hardest jobs of a manager is discovering and resolving problems. If you don’t know about a problem, you can’t resolve it. If you discover a problem late, you can’t do much about the negative effects it has already had. If you don’t get feedback on the results of the actions you take for a long time, it is difficult if not impossible to judge the effectiveness of your actions. Short iterations, the practice of breaking up a release into 1-4 week development cycles that each produce a shippable increment of work, vastly increase the amount of feedback available to management for making good decisions. It also provides more opportunities to make adjustments and judge their effectiveness.
Burndown Charts are a Management Dashboard That Everybody Loves
A burndown chart is a useful tool for measuring the amount of progress, positive or negative, during an iteration which clearly illustrates trends which may indicate problems. It is simply a day-by-day chart of how much effort remains. At the beginning of an iteration, 100% of the work for that iteration remains. At the end of the iteration, there should be 0% remaining.
An important multiplier of the effectiveness of a burndown chart is its visibility. A clearly visible burndown chart makes it obvious to everybody how the project is progressing. Nobody wants to see a burndown chart that isn’t making progress, and nobody wants other people to see lack of progress for a significant period of time. The burndown chart helps to motivate and inspire. If your own work is going well, but the chart isn’t going down in general, you’ll be more engaged in helping to solve problems that the team is having overall. When used effectively, the burndown chart reduces the effort required for a manager to determine that there is a problem and also reduces the need for the manager to cajole the team into taking corrective action.
Retrospectives Emphasize That You Are All In This Together
A retrospective provides a forum for the team to talk on a regular basis about what worked and what didn’t work as a team, to discuss ideas for improvement and to work out problems. Instead of a manager having to unearth all problems and come up with all solutions, a retrospective accomplishes much of this, providing the manager with more bandwidth to deal with sensitive issues and to focus on people management. Retrospectives are particularly effective when combined with short iterations because problems have less time to fester and there are more opportunities to take corrective action.
User Stories Reduce Micro-Management
Agile prefers user stories over requirements. User stories are simply stories that describe what is needed from the user’s perspective. User stories help to separate business value from implementation and focus all parties on the desired outcome. The separation removes the invisible constraints which can appear when the engineer assigned to a task is given a specification which completely constrains the problem such that only one solution is available. By focusing on the outcome desired by the user, the engineer working on the task has more freedom to utilize their creativity and ability to innovate without the risk of implementing something that the user doesn’t want.
There are two reasons that user stories support self-managing teams. First, they reduce the temptation of technically minded managers from becoming an implementation bottleneck. Second, they encourage team members to innovate and take on more responsibility which increases their self-sufficiency. This is much easier to do within an Agile environment because there are more practices in place such as short iterations, burndown charts, and retrospectives which encourage learning while reducing the risk of making mistakes.
I hope you have enjoyed this series on how Agile practices reduce and redistribute the job of management and thereby increase your capacity for self-management. If you missed the beginning, the first posting is "The Use of Self-Management Outside the Context of Software Development" .
You may also enjoy reading the the online mini-version of the book that I am working on called "Zero to Agile in 90 Days or Less."
Short Iterations Increase Management Leverage
One of the hardest jobs of a manager is discovering and resolving problems. If you don’t know about a problem, you can’t resolve it. If you discover a problem late, you can’t do much about the negative effects it has already had. If you don’t get feedback on the results of the actions you take for a long time, it is difficult if not impossible to judge the effectiveness of your actions. Short iterations, the practice of breaking up a release into 1-4 week development cycles that each produce a shippable increment of work, vastly increase the amount of feedback available to management for making good decisions. It also provides more opportunities to make adjustments and judge their effectiveness.
Burndown Charts are a Management Dashboard That Everybody Loves
A burndown chart is a useful tool for measuring the amount of progress, positive or negative, during an iteration which clearly illustrates trends which may indicate problems. It is simply a day-by-day chart of how much effort remains. At the beginning of an iteration, 100% of the work for that iteration remains. At the end of the iteration, there should be 0% remaining.
An important multiplier of the effectiveness of a burndown chart is its visibility. A clearly visible burndown chart makes it obvious to everybody how the project is progressing. Nobody wants to see a burndown chart that isn’t making progress, and nobody wants other people to see lack of progress for a significant period of time. The burndown chart helps to motivate and inspire. If your own work is going well, but the chart isn’t going down in general, you’ll be more engaged in helping to solve problems that the team is having overall. When used effectively, the burndown chart reduces the effort required for a manager to determine that there is a problem and also reduces the need for the manager to cajole the team into taking corrective action.
Retrospectives Emphasize That You Are All In This Together
A retrospective provides a forum for the team to talk on a regular basis about what worked and what didn’t work as a team, to discuss ideas for improvement and to work out problems. Instead of a manager having to unearth all problems and come up with all solutions, a retrospective accomplishes much of this, providing the manager with more bandwidth to deal with sensitive issues and to focus on people management. Retrospectives are particularly effective when combined with short iterations because problems have less time to fester and there are more opportunities to take corrective action.
User Stories Reduce Micro-Management
Agile prefers user stories over requirements. User stories are simply stories that describe what is needed from the user’s perspective. User stories help to separate business value from implementation and focus all parties on the desired outcome. The separation removes the invisible constraints which can appear when the engineer assigned to a task is given a specification which completely constrains the problem such that only one solution is available. By focusing on the outcome desired by the user, the engineer working on the task has more freedom to utilize their creativity and ability to innovate without the risk of implementing something that the user doesn’t want.
There are two reasons that user stories support self-managing teams. First, they reduce the temptation of technically minded managers from becoming an implementation bottleneck. Second, they encourage team members to innovate and take on more responsibility which increases their self-sufficiency. This is much easier to do within an Agile environment because there are more practices in place such as short iterations, burndown charts, and retrospectives which encourage learning while reducing the risk of making mistakes.
I hope you have enjoyed this series on how Agile practices reduce and redistribute the job of management and thereby increase your capacity for self-management. If you missed the beginning, the first posting is "The Use of Self-Management Outside the Context of Software Development" .
You may also enjoy reading the the online mini-version of the book that I am working on called "Zero to Agile in 90 Days or Less."
Three Cures for the Management Bottleneck
This is the fourth post in a series on self-management that began with "The Use of Self-Managing Teams Outside the Context of Software Development"
One of the ways that Agile, especially when using Scrum, reduces the management bottleneck and enables self-managing teams is by having clearly identified roles and responsibilities. Two very useful roles are those of Scrum Master and Product Owner. The Scrum Master role clearly frames the project management function. The Product Owner role clearly frames business management related to the product that a team produces. Both of these roles clearly delineate an area of responsibility that would normally be done by a traditional manager and makes it possible to delegate those responsibilities.
The Scrum Master
In Scrum, the Scrum Master is the person making sure that the (Scrum) process is working, looking for and removing impediments, and acting as a liaison between management and the team. Regardless of what you call the role of Scrum Master, the role itself does not require you to be doing Scrum.
The Product Owner
The role of Product Owner also comes from Scrum. As with a Scrum Master, the use of Scrum is not required in order to have a Product Owner. However, the effectiveness of the Product Owner is definitely leveraged by Scrum. The Product Owner is the person who is solely responsible for the content of a release. They are responsible for all decisions related to what changes are made to the product, including all defects and enhancements. Of course, the Product Owner is most effective if they gather information from a wide variety of sources and work closely with all stakeholders. A Product Owner that regularly makes decisions without consulting with stakeholders or acts on a whim won’t be a Product Owner for long.
The Product Owner Needs a Product Backlog
The role of Product Owner goes hand in hand with the use of a product backlog. A product backlog is simply a list of high-level product requirements (preferably in the form of user stories), prioritized by business value as determined by the product owner.
A backlog gives a clear context to discussions of priority. Anybody can go and look at the backlog to see the position of something they have a stake in. If it is lower than they think it should be, they can examine the backlog to see what is higher in order to help frame a discussion around either moving it higher or moving other things lower. Thus, many people can be leveraged to collectively groom the backlog. This distributes the work of grooming the backlog and helps to ensure that the team is focused on the highest value to the organization.
Reducing the Management Bottleneck
Even if the roles of manager, Scrum Master, and Product Owner were all handled by a single person, the use of these roles and their artifacts simplifies the job of management while at the same time amplifying its effectiveness. And of course, that makes it even easier to delegate these roles. The more that management is delegated, the less chance that management will become a bottleneck.
Monday, January 19, 2009
No-Brainer Self-Management Practices in Agile Part 2
This is a continuation of "No-Brainer Self-Management Practices in Agile Part 1"
Whole Teams Improve Coordination and Communication
A whole team is a small group of people (no more than 12) that work together towards a common purpose, primarily spend their time as part of the team, and as a team have all of the skills they need in order to be self-sufficient. These skill sets may include server side programmer, web designer, tester, technical writer, scrum master, product owner, etc. The whole team practice contributes to self-management by reducing the amount of coordination required in order to achieve a goal. For instance, instead of having to coordinate with a QA group in order to find somebody that can test a piece of software, having a QA person as part of the team means that there is always somebody familiar with the software available to test it.Another benefit of having a whole team is that it makes it more obvious if you have resource imbalances. If the QA folks in the team can’t keep up with the developers, then you either have too many developers on the team or too few QA folks. If your front end developers can’t keep up with the folks working on the back end, then you have a resource imbalance. You either need to add more folks with the right skill set, or you need to reduce the amount of work being done on the back end.
When you have a whole team, you spend less time waiting for other groups and bringing part-time participants up to speed, you lose less time due to communication delays, and individuals spend less time multi-tasking between multiple projects. Taken together, the benefits of whole teams can have a significant impact on reducing management complexity which makes it easy for teams to do more self-management.
Collocation Further Improves Coordination and Communication
Collocation is closely related to whole teams. Collocation is simply having everybody in close proximity to each other. This compounds the coordination benefit of whole teams.
If you have a large group of people that are not all near each other but they are all working towards a single deliverable, collocation may seem impractical on the surface. However, collocation at the whole team level is more important than collocation of multiple teams. Focus on creating whole teams that can collocate rather than collocating the whole group of people.
The challenge with both whole teams and collocation is that they often require either relocating people, changes to management structures, or both. However, the benefits of having a tightly coordinated team working towards a common goal far outweighs the difficulties associated with creating collocated whole teams.
Friday, January 16, 2009
“No-Brainer” Self-Management Practices in Agile
While there may be some confusion over the meaning of self-management in Agile, not to mention some contention as to whether or not it is a good idea, many of the Agile practices contribute to self-management without requiring the wholesale adoption of self-management. For simplicity, I will define “self-management” as anything that is done by a team member that would traditionally be done by a manager. The practices contribute to self-management either by reducing the amount of management required or by encouraging the delegation of management tasks to team members. Some practices do both. As a result, managers have more bandwidth for dealing with things which are a more leveraged use of their time.
The Agile practices related to self-management include:
Let’s start with a simple example: task assignment. Traditionally, tasks are assigned to engineers by their manager. In Agile, tasks are selected by the engineers themselves. It may take some time for everybody to get used to this and to work out the kinks, but the practice itself is not particularly earth-shattering.
The Agile practices related to self-management include:
- whole teams
- collocation
- short iterations
- using a scrum master
- using a product owner
- user stories
- maintaining a product backlog
- assignment of tasks by team members
- estimation of tasks by team members
- producing a burn down chart
- retrospectives
Let’s start with a simple example: task assignment. Traditionally, tasks are assigned to engineers by their manager. In Agile, tasks are selected by the engineers themselves. It may take some time for everybody to get used to this and to work out the kinks, but the practice itself is not particularly earth-shattering.
Certainly, somebody may find themselves struggling with a task they don’t fully understand, or one engineer may accomplish a task more slowly than whoever the manager might have chosen to do the task. But is that really all that different than what typically happens when the work is assigned by a manager? How likely is it that a manager has enough time to devote to the minutia required to optimize task assignment? Wouldn’t it be better for the manager to spend their time mentoring team members on how to pick tasks that are appropriate for them while at the same time encouraging engineers to stretch their capabilities?
Monday, January 05, 2009
The Use of Self-Managing Teams Outside the Context of Software Development
[Note: this post was heavily edited on Jan 18th to take into account comments on the earlier version.]
Most of what you need to do to become Agile requires only re-arrangement of what you are already doing. For instance, managing a backlog is still a process of deciding which work to do and in which order to do it, it isn't something that boggles the mind and makes people say "some people might be able to do that, but I don't see how we could." Managing what work to do with a backlog is like tuning an engine. It is straight-forward to explain, learn, and implement. Whereas, moving from conventional management to self-managing teams sounds like moving from steam to internal combustion. It is completely different and not well understood. But wait, what exactly are self-managing teams?
The terms “self-organizing,” “self-managing,” and “self-directing” have been used to mean many things, but are generally thought of as being in the same ballpark. In this post I will use the term “self-managing.” While looking for other writing on the topic prior to writing this post, I found that it is a poorly defined topic within the Agile literature.
What the Heck is a Self-Managing Team Anyway?
What sort of management does self-management apply to? What is the scope? Does it just apply to how I manage myself on my pre-assigned tasks? Does it only apply to project management? Does it mean dealing with hiring and firing? What about budgets? Some folks have taken it to mean that there is no manager, that the Scrum Master is the manager, etc. Sure, there are lots of short sections on self-managing teams in Agile books and articles, but it is not much more than a vague description of the concept repeated in different ways by different authors. This is not a criticism, only an observation that self-management it is an underdeveloped area of Agile.
In the Poppendieck's "Implementing Lean Software Development" there are four pages on "Self-Directing Work", most of which talks about project management. Kent Beck's "Extreme Programming Explained" takes self-management for granted without specifically talking about it. Ken Schwaber's book "Agile Software Development With Scrum" contains a couple of paragraphs on self-organization but mostly takes it for granted. In general, most of the material on the topic assumes that you will be doing it and there are practices which are meant to support it, but there is no in-depth discussion of exactly what it is and how to do it.
In searching the web for a more in-depth treatment, I did find one really good article by Esther Derby in the December 2008 issue of Better Software Magazine entitled "What's a Manager to Do?" This article gives a good overview of the concepts as well as some pitfalls and how to avoid them.
I had better luck finding reference material on self-management by looking outside of software development all together. At some point during my searching, I accidentally left off the keyword "Agile" and discovered that there are whole books on self-managing teams, and they have nothing to do with software development at all. I ordered three of them and am currently in the process of reading them. I'll post new entries as I go.
Here are the books on my reading list related to self-managing teams:
Business Without Bosses
Leading Self-Directed Work Teams
The Wisdom of Teams
Apparently, people have been promoting and practicing self-managing teams completely outside the realm of software development for quite a while. While it holds promise, it does not yet seem to have become a widespread practice. If it is still in its infancy in general, is it really a good idea to promote it in conjunction with all of the other parts of Agile which, IMHO, are much more straight-forward and are closer to our core-competencies as an industry?
Even though self-managing teams are not well defined or described in Agile, it doesn’t really matter. There are actually many no-brainer “self-management” oriented Agile practices that are straight-forward and beneficial in their own right. The fact that they may get us closer to creating self-managing teams is a side benefit.
Most of what you need to do to become Agile requires only re-arrangement of what you are already doing. For instance, managing a backlog is still a process of deciding which work to do and in which order to do it, it isn't something that boggles the mind and makes people say "some people might be able to do that, but I don't see how we could." Managing what work to do with a backlog is like tuning an engine. It is straight-forward to explain, learn, and implement. Whereas, moving from conventional management to self-managing teams sounds like moving from steam to internal combustion. It is completely different and not well understood. But wait, what exactly are self-managing teams?
The terms “self-organizing,” “self-managing,” and “self-directing” have been used to mean many things, but are generally thought of as being in the same ballpark. In this post I will use the term “self-managing.” While looking for other writing on the topic prior to writing this post, I found that it is a poorly defined topic within the Agile literature.
What the Heck is a Self-Managing Team Anyway?
What sort of management does self-management apply to? What is the scope? Does it just apply to how I manage myself on my pre-assigned tasks? Does it only apply to project management? Does it mean dealing with hiring and firing? What about budgets? Some folks have taken it to mean that there is no manager, that the Scrum Master is the manager, etc. Sure, there are lots of short sections on self-managing teams in Agile books and articles, but it is not much more than a vague description of the concept repeated in different ways by different authors. This is not a criticism, only an observation that self-management it is an underdeveloped area of Agile.
In the Poppendieck's "Implementing Lean Software Development" there are four pages on "Self-Directing Work", most of which talks about project management. Kent Beck's "Extreme Programming Explained" takes self-management for granted without specifically talking about it. Ken Schwaber's book "Agile Software Development With Scrum" contains a couple of paragraphs on self-organization but mostly takes it for granted. In general, most of the material on the topic assumes that you will be doing it and there are practices which are meant to support it, but there is no in-depth discussion of exactly what it is and how to do it.
In searching the web for a more in-depth treatment, I did find one really good article by Esther Derby in the December 2008 issue of Better Software Magazine entitled "What's a Manager to Do?" This article gives a good overview of the concepts as well as some pitfalls and how to avoid them.
I had better luck finding reference material on self-management by looking outside of software development all together. At some point during my searching, I accidentally left off the keyword "Agile" and discovered that there are whole books on self-managing teams, and they have nothing to do with software development at all. I ordered three of them and am currently in the process of reading them. I'll post new entries as I go.
Here are the books on my reading list related to self-managing teams:
Business Without Bosses
Leading Self-Directed Work Teams
The Wisdom of Teams
Apparently, people have been promoting and practicing self-managing teams completely outside the realm of software development for quite a while. While it holds promise, it does not yet seem to have become a widespread practice. If it is still in its infancy in general, is it really a good idea to promote it in conjunction with all of the other parts of Agile which, IMHO, are much more straight-forward and are closer to our core-competencies as an industry?
Even though self-managing teams are not well defined or described in Agile, it doesn’t really matter. There are actually many no-brainer “self-management” oriented Agile practices that are straight-forward and beneficial in their own right. The fact that they may get us closer to creating self-managing teams is a side benefit.
Subscribe to:
Posts (Atom)