October 23, 2007
Scrum Rules Cheat Sheet - Updated!
A few weeks ago, after my last update of the Scrum Rules Cheat Sheet, I decided that it might be a good idea to ask Ken Schwaber about what I had developed... He immediately asked if I had checked it against the rules listed in his book Agile Project Management with Scrum. Of course, I hadn't. In fact, although I've read the book, I neglected to read the appendix in which the rules are contained. So, I read it and updated the cheat sheet. I found that there were a few rules that I was "assuming" because I work with Scrum so frequently. As well, there were a few rules that I actually didn't remember. The cheat sheet is now getting to the point where I would like to break it into two pages, but then it wouldn't be a cheat sheet anymore... so with smaller font size... presenting, the new and improved Scrum Rules Cheat Sheet. Here is the original article about the Scrum Rules Cheat Sheet.
Posted by Mishkin Berteig at 08:19 AM | |
September 24, 2007
Agile Benefits: Five Essential Reasons to Try Agile
Although there many other benefits of agile, and although those provide us with other reasons to try agile, the five essential benefits of agile are:
Rapid Learning - disciplined application of the scientific method to explore the best ways to deliver valuable results.
Early Return on Investment - opportunity to use the results of work starting with the work delivered at the end of the first iteration.
Satisfied Stakeholders - engagement in the process in a way that allows meaningful contributions from all stakeholders.
Increased Control - mechanisms to track/measure and therefore steer the direction that work is going so that it meets goals.
Responsiveness to Change - processes, tools, roles and principles that allow a team and an organization to embrace change rather than reject, control or suffer from change.
These reasons are sufficient and apply to operations work, project work and open-ended research work, whenever humans are involved. The above links take you to more detailed descriptions of each of these benefits.
What are some of the other benefits of agile?
Posted by Mishkin Berteig at 10:47 PM | |
September 22, 2007
Scrum Rules Cheat Sheet - Updated!
Okay, here's yet another draft of the Scrum Rules Cheat Sheet. I've added two optional rules, a note about Truthfulness as well as re-wording or clarifying a few other rules. This is an update worth checking out! I would love to hear comments from people about how well this is communicating, how useful it is, if there are things missing or if you have any other suggestions for changes. Thanks! This is the original article about the Scrum Rules Cheat Sheet.
Posted by Mishkin Berteig at 04:33 PM | |
September 06, 2007
Four Methods of Perfecting Agile
Most organizations start doing agile (or Scrum or lean or ...) imperfectly. Someone introduces a few practices or a manager gets a team some training, or a person starts using agile terminology. And things might improve, particularly with the use of iterations. One of the core ideas of agile methods is to have frequent delivery of valuable results. In fact, this core idea can be used to drive the improvement of an agile process. How? Here are four methods of perfecting agile by expanding the definition of done.
Perfecting Agile
Let's suppose you already understand the benefits of agile. With these benefits in mind, you would like to improve the organization's ability to deliver working, valuable results at the end of every iteration so that you can get better at realizing those benefits. The primary way to do this is by expanding the definition of done. You can imagine this like so:
On a regular basis, the team/organization find ways to bring work done in either the preparation stage or the close stage into every iteration of the agile portion of the project. By moving the work from these "bookend" stages into the iterations, you reduce the amount of time spent in those stages and simultaneously create a more complete delivery every iteration. The "definition of done" is now expanded to contain the results or value delivered by the work that was taken out of the startup and shutdown stages of the project. By expanding the definition of done, each iteration delivers a more "complete" increment of value, and there is less work done before or after iterations in order to plan or deliver. This gradual process allows the team to get better at doing agile.
There are four methods for transferring work from the start and end of a project into the iterations of a project.
Expand the Agile Team's Skill Set
In some ways, this is the simplest and most common approach to expanding the definition of done in the agile portion of a project. By training, coaching, mentoring, re-assigning or hiring, a team's capacity to do work is expanded and used to expand the definition of done. As a simple example, a software developer might learn to use an automated unit testing framework and therefore expand the definition of done to include some amount of unit test coverage of delivered code. In general, training, coaching and mentoring existing team members should be preferred over adding people to the team since the addition disrupts the team's development and can increase communication overhead among team members.
Expand the Agile Team's Authority
Sometimes, a team is not able to do part of the preparation work or close up work because they are not authorized to do so. This may be a policy, a unspoken assumption or a bureaucratic procedure. By giving the team (or some person on the team) the authority to do this work, the team can find ways to do it every iteration instead of having to work through another non-team individual. Again, a simple example here is a situation where a technical person is given permission to talk directly to an end user in order to reduce the need for up-front requirements gathering and analysis and reduce the need for end-of-project user acceptance testing. The obvious challenge to do this is the question of trust (or lack thereof).
Automate an Existing Manual Process
Automation is often given far less than its due consideration. This is primarily be cause automating a process is an investment of work in and of itself. Fortunately, it is often easy to measure the ROI or savings involved with automation. In many agile environments, heavy automation is critical and a huge enabler for very short iterations. Automated testing, automated translation, automated build processes, are all common areas of improvement. Agile teams should always be looking for opportunities to automate their own work. In this way, the automation work itself is transformed from a separate project to a responsibility of the team.
Remove Wasteful Processes
There are some parts of the project preparation work and the project close up work that are pure waste! There is no independent value to these activities, nor is there indirect value to them. An excellent example of this sort of thing is an approval process that _always_ grants approval ("rubber stamping"). One insurance organization I worked with as they were converting to an agile approach discovered that their "second stage" approvals always allowed proposed projects to proceed. Since they often incurred a 4-6 week delay for this approval process, it became obvious that they should "get rid of it". Now, what they actually did is made it so that it became a parallel review process rather than a gated approval process; this was so that the true purpose of the activity could still be met: to help stakeholders understand the projects that were being worked upon. Here, there is no need to take this approval process and somehow work it into every iteration. An agile approach tends to increase the visibility of the work anyway, so it may be discovered later on that the review process can also be done away with.
Agile is often implemented in a limited fashion when it is first adopted by most teams and organizations. The four methods of expanding the definition of done can help a team or organization get better at doing agile and therefore reap more of the benefits of agile. These methods are simple: expand the agile team's capacity, their authority, have them automate manual processes and remove wasteful activities from the process.
Posted by Mishkin Berteig at 03:32 AM | |
September 03, 2007
Scrum Rules Cheat Sheet - Updated!
After feedback and use in a number of different circumstances including training and coaching, Berteig Consulting has made a new Scrum Rules Cheat Sheet (pdf) available. Corrections to the old version include a "Basic Rule" about managing defects, as well as several changes to improve clarity.
Posted by Mishkin Berteig at 02:40 PM | |
May 24, 2007
Scrum Rules
Recently in my ScrumMaster Certification courses, I have been ending the course with a list of the rules of Scrum. This list of rules is based on my understanding and practice and may not be 100% the same as that found in the Scrum books or in other Scrum practitioners' models. Nevertheless, I just recently checked it against some other online reference material and it seems like a reasonable list of rules. I am interested in any feedback or variations or disagreements...
[Updated: 20070922]
Without further ado, here they are, categorized into Required Rules, Basic Rules and Optional Rules, plus a downloadable PDF version.
Required Rules to Start – the “Agile Skeleton”:
- Full-Time ScrumMaster Identified and Team Members Available to Do Work
- Team Agrees to Demonstrate Working Software in No More Than 30 Days
- Stakeholders Invited to Demonstration
Basic Rules of Scrum to Implement As Soon As Possible:
- Full-Time Product Owner (with Expertise and Authority) Identified
- Product Owner Works With Team and All Other Stakeholders
- Product Backlog Created and Managed by Product Owner
- Daily Scrum Meeting with 3 Questions (Completed? Will Complete? Obstacles?)
- Daily Scrum Meeting Same Place and Time and Less Than 15 Minutes
- Regular Sprint Length (no more than 30 days)
- Sprint Planning Meeting to Create Sprint Backlog of Estimated Tasks
- Sprint Burndown Chart
- Team Room with All Needed Equipment and Supplies
- Retrospective Meeting for Process Improvements
- Definition of “Done”
- Commitment Velocity Calculated (from Sprint Backlog Estimates)
- Team Size 7 +/-2, Maximum of 12
- Cross-Functional Team Including ScrumMaster and Product Owner
- Team Self-Organization - Team Members Volunteer for Tasks
- ScrumMaster Tracking and Removing Obstacles
- Team Safety – No Interruptions to Team's Work During Sprints
- No “Break” Between Sprints
- Sustainable Pace - Timebox Effort, Not Just Schedule
- Quality is Not Negotiable - Defects Go on Top of Product Backlog
Optional Rules of Scrum to Implement Depending on Context:
- Test Driven Work and Continuous Integration
- User Stories as Product Backlog Items (As a
- Project Burndown Chart
- Release Burndown Chart
- Planning Velocity Calculated (from Product Backlog Estimates)
- Scrum of Scrums for Multiple Teams
- Canceling the Sprint Early
- Financial Modeling for Product Backlog
- Sprint Backlog Tasks on Big Visible Chart on Wall
- Backup Product Owner Identified
- Team of Volunteers - Self-Selecting
- Rotate the ScrumMaster Duties
And here is the downloadable version of the Scrum Rules Cheat Sheet [pdf].
Finally, you can purchase a poster-sized version of this from Cafe Press AgileAdvice Shop for $22.99.
Posted by Mishkin Berteig at 03:01 AM | |
January 02, 2007
Top Ten Most Popular Entries from 2006
If you are new to Agile Advice, these are not just some of the most popular articles, they are also some of the best! Take a look around; you will find ideas to inspire you, challenge your thinking and maybe that one little thing that will make the difference in applying agile methods in your situation.
1. How Two Hours Can Waste Two Weeks - 25,617 unique views
This little hypothetical story by Dmitri Zimine was very popular on Reddit, and Joel on Software ranted a bit about it.
2. The Case for Context Switching - 2,936 unique views
My rebuttal to Joel's rant. Goes well with Dmitri's article. Emphasizes the idea of building trust in an organization.
3. The Qualities of an Ideal Test - 1,579 unique views
Six qualities that will help make your tests as valuable as can be. Similar to the ACID properties of databases or the INVEST properties of user stories.
4. The Pros and Cons of Short Iterations - 1,555 unique views
A few words that will help you decide how long to make your iteration length. This is an important decision, and most teams and organizations don't know the factors involved.
5. Five Signs of Trouble in an Iteration - 1,489 unique views
A good howto on using burndown charts to discover problems in an iteration.
6. Seventeen Tips for Iteration Planning - 1,427 unique views
A good list of hints and tips that can make the difference between struggling with iteration planning and having it go smoothly and effectively. This is a key part of the Agile Work process, so getting good at it is a high priority for any team new to Agile Work.
7. Change is Natural - "Embrace Change" - 1,397 unique views
A short riff on the universality of change. Also introduces the idea of the "horizon of predictability".
8. The Art of Obstacle Removal - 1,287 unique views
This is a good reference article on types of obstacles and methods for removing them... a critical practice for Process Facilitators.
9. The Seven Core Practices of Agile Work - 1,285 unique views
Agile Work is really quite simple. This is a concise list of the practices that make up this effective methodology.
10. Interview with Alistair Cockburn - Agile and House Renovations - 902 unique views
Applying agile methods to home and garden renovations! Learn a bit about how this luminary of the agile world has taken agile practices out of the software world and into the hardware world.
Posted by Mishkin Berteig at 06:32 PM | |
December 12, 2006
Glossary of Agile Terminology
There are quite a number of agile methods that are being used around the world in many different types of environments. This glossary provides a quick-reference translation between the various terms used in these methods. I have also included terms that may come from other non-agile disciplines that are strongly related.
If you are using terminology in an agile environment that is different from the terms listed here, please add your comment and I will update this list. In particular, I am looking for people with practical experience with DSDM and FDD to contribute their expertise.
Glossary of Equivalent and Related Agile Terms
Self-Organizing Team: Chickens and Pigs (Scrum), Whole Team (Extreme Programming), Cross-Functional Team (business management), Real Team (The Wisdom of Teams).
Deliver Frequently: Sprint (Scrum), Iteration (Extreme Programming), Timeboxing (generic), Time Value of Money (accounting).
Plan to Learn: Inspect and Adapt (Scrum), Kaizen (Lean), Double-Loop Learning (Organizational Learning), Adaptive Planning (generic).
Communicate Powerfully: Visibility (Scrum), Whole Team and Team Room (Extreme Programming), War Room (business management).
Test Everything: Canary in the Coal Mine (Scrum), Test-Driven Development (Extreme Programming), Defects per Opportunities (Six-Sigma).
Process Facilitator: ScrumMaster (Scrum), Coach, Lean Six-Sigma Black-Belt, Agile Project Manager
Queue Master: Customer (Extreme Programming), Customer Proxy, Product Owner (Scrum), Business Analyst, Product Manager
Work Queue: Product Backlog (Scrum), Stories (Extreme Programming), Business Requirements, To-Do List, Project list + Tickler (Getting Things Done)
Task List: Sprint Backlog (Scrum), Work Breakdown, Components, Tasks, Context lists + Next Actions (Getting Things Done)
Test-Driven Work: Test-Driven Design/Development, Test-First Development (Extreme Programming)
Retrospective: Reflection Meeting, Post-Mortem, Debrief, Weekly Review (Getting Things Done)
Team Status Meeting: Daily Scrum (Scrum), Daily Stand-up (Extreme Programming), Daily Reviews (Getting Things Done)
Record of Obstacles: Meta-Backlog (Scrum), Open Loops (Getting Things Done)
Work Period: Day (Scrum, Extreme Programming).
Measure Value: Measuring Results (Scrum), ROI (business management), Economic Driver (Good to Great), Running Tested Features (Extreme Programming).
Clear the Path: Removing Obstacles (Scrum), Stopping the Line (Lean), Collect to have "mind like water" (Getting Things Done).
Agile Methods and Other Disciplines Included
Scrum
Extreme Programming (XP)
Lean Software Development
Where I Need More Help!
The following disciplines need better representation in this glossary. Please help out!
* Project Management Institute's Project Management Body of Knowledge (PMBoK)
* Dynamic Systems Development Method (DSDM)
* Crystal Clear
* Rational Unified Process (RUP)
* Lean Manufacturing
* Personal Software Process (PSP)
* CMMI
* Feature Driven Development (FDD)
* Getting Things Done (book)
* Others?
Posted by Mishkin Berteig at 08:20 AM | |
November 12, 2006
More on Scaling Agile
One problem with having multiple teams working on the same project will be the tendency to compare the teams' performance. Why is this a problem?
Why Not Compare Team Performance?
One of the main reasons is that the teams need to be collaborating not competing. There can be a small amount of friendly competition that might come naturally, but as soon as management starts paying attention to differences in team performance, the competition starts to get serious.
In the case of multiple teams working on the same project, the goal should be to maximize overall performance, not individual team performance. Too much competition can lead to unintentional or deliberate sabotage: failed communication, incomplete communication and downright dishonesty.
Motivating Teams without Comparing Them!
As Mary Poppendieck has written, measure up [pdf]. In a single-team situation this means that individuals are measured and rewarded based on team performance (their sphere of influence). In a multi-team environment, that means that the group of teams should be measured as a group and compensated as a group. This will encourage all teams to work towards the success of the overall project. I personally believe there is some room for individual-based compensation, but the way it is handled needs to be done so that it does not encourage sub-optimal behavior.
As well, each team can keep track of their velocity. Some coaches recommend using "ideal hours" or some other units to determine velocity (velocity = estimated work remaining completed / iteration). The trouble with doing this with multiple teams is that there will be a very real tendency to want to compare each team's velocity. Since velocity is a useful measure for team capacity, it is important to still have a way to measure it. One simple way to do this to prevent comparison is to use different units for each team. Team One might be measuring velocity in Estimated Ping Pong Balls Completed / Iteration... Team Two in Estimated Bananas Completed / Iteration... Team Three in Estimated Bogo-MIPS Completed / Iteration... etc. etc.
Motivating Collaboration
First off, management must make visible commitments to eliminating barriers to collaboration. For example, it is a great sign of commitment to re-organize office spaces so that all the teams are sitting near to each other. Every time the Process Facilitator identifies an obstacle that relates to collaboration (tools, process, physical environment, etc.) management should get right on it and fix it.
An ongoing investment in team-building training, workshops and exercises is also helpful. This type of investment helps people gain the skills necessary to work effectively with other people. Again, individuals need to see and believe that management cares about and values teams.
Finally, one of my pet peeves: when a project is over, keep the team together! Do not break them up and redistribute your "resources" to other efforts. The value of those people working together is substantial. The value of those people working together as a high-performance team is incredible! In a multi-team situation, it is reasonable to take teams from the overall group and re-distribute their efforts... but just don't break up the individual teams.
Miscellaneous Notes on Scaling Agile:
Twelve is still the maximum recommended size for a single agile team. Seven is really the sweet spot. A team larger than twelve people just takes too long to get into the Performing stage of team development. If you feel like your project needs more than twelve people actively involved, then you probably want to split into two or more teams... and then you have "scaled" agile.
If you have three teams of five people (or some similar configuration of people just over the 12 person limit), then they will work as a very close-knit group and a lot of the time will act as if they were a single team. They will probably plan iterations and do demos and retrospectives together.
Twelve teams working on the same project at once is about the maximum number before communication overhead is slowing everyone down too much. This is largely a factor of trust: with 150 or fewer people involved in an effort, it is possible for everyone to know everyone. More than that many people and it is no longer possible. Trust is just not an option anymore and bureaucratic controls take over.
If for some reason you need to do something in a small amount of time and you think it's going to take more than twelve teams of twelve people...? Break the effort into smaller chunks. Divide and conquer. Division can be across functional areas, structural areas or time.
Although I have heard of agile methods being used with groups larger than this, I haven't heard any success stories :-)
Check out my earlier introductory article on Scaling Agile in a large project situation.
Dean Leffingwell has an article about practices needed for scaled-up efforts at the Agile Journal. I glanced through it, but I admit that after I disagreed with his very first point (Intentional Architecture), I started to pay less attention.
He claims that refactoring of large systems is not possible (or at least infeasible). The odd thing is, most large projects that I have been involved with are being done exactly because an old system is not refactorable. A large telecom system, a large insurance system, a large data warehouse and a large GIS system are all being done with scaled up agile methods exactly because the old systems that are currently in place have become ossified to the point where they must be replaced.
These old systems were originally built with phase-based development approaches. At some point, people stopped refactoring because they were not given the space to do so. This drop in code quality turned into technical debt. The technical debt accumulated to the point where it was unbearable (maintenance costs, cost of change, etc.).
The problem with intentional architecture is that it goes back to the old assumption that you can do a good design for a system without the constant feedback from review, deployment and use done on a very short cycle time. Over and over, we are faced with the painful consequences of this attitude, and that is one of the key reasons we started to work with agile methods in the first place.
Martin Fowler makes a good case that scaling agile is the last thing you should do. I don't disagree! Scale your agile teams at your own risk!
It's nice for me to be able to say that I've worked on some agile projects over $10,000,000 in size, but the fact is that the cost could have been reduced substantially if the team size was lowered and the deadline extended. It is (relatively) simple to do a cost/benefit analysis of cross-team-coordination-overhead vs. the time value of early delivery of more functionality... although I've never seen anyone do it! If you know of an example of an organization doing this in a realistic way, I'd love to hear about it!
Are there other ways of supporting cross-team collaboration that you have seen?
Posted by Mishkin Berteig at 09:13 AM | |
November 07, 2006
Scaling Agile Projects
More and more, organizations are applying agile methods to large projects or efforts that require more than a single team. There are three dimensions or concerns of coordination. It is critical that all three be addressed, but there are many ways of addressing them. Here I will simply list these three types of coordination and make some simple suggestions of how to implement them.
I have now had the opportunity to work with several clients where they are applying agile methods to projects with budgets that are greater than $10,000,000. All of them are using multiple teams to work on the same overall project/program. Out of this experience (along with some good reading along the way), I have come to understand that the following three types of coordination are the essential ones:
Value
In order to maintain the "early and frequent" delivery of value that agile methods propose, it is important that the work of the effort be coordinated to maximize early delivery of value. From this perspective, there are often many cooks in the kitchen. I have seen a "Product Owner Team", a "Customer Team", and a number of variations of this type. In order to do the coordination work effectively, it is still necessary to make sure of two things:
- Maintain a single Work Queue that prioritizes the work and from which all the teams select items.
- Have a single person in the "buck stops here" role who can make final binding decisions about work priority and content.
These two items have some implications for the organization.
First, the teams must be organized to be generalist: each team should be able to handle any item on the Work Queue. Not every team is going to be equal in abilities and this can be accomodated in a number of ways. My favorite so far comes from an excellent agile coach Dave West
The second implication is that the customer or product team (Queue Master) must have the availability to support multiple teams in a timely fashion. Ideally, there are individuals on each team who can make judgement calls about features, functionality, constraints etc. on the work and provide quick answers to questions. This is not always easy since the people doing this often have a special area of expertise and it is difficult for them to work outside this area. Just as team members are asked to become generalizing specialists, so must the people who are responsible for determining value in a project.
Process
An agile process endeavors to provide a minimally structured way to do three things: deliver value early, then learn about what is high in value and deliver that more, and finally, learn how to deliver value more effectively.
That third activity, learning how to deliver value more effectively, is facilitated by the Process Facilitator. The Process Facilitator keeps a visible list of obstacles and works collaboratively with the Team and the Stakeholders to resolve obstacles on the list.
In a multi-team environment, there may be a single Process Facilitator working with each team. Like with the Work Queue, it is often necessary to have a single Record of Obstacles for the entire project.
Technique
People develop skill and knowledge in the use of their tools. Most types of work have a special vocabularly that only makes sense to other people also doing that work. For example, the field of computer programming has programming languages, integrated development environments, build tools, testing tools, algorithms, and a host of other techniques. The field of film-making has cameras, film, directorial techniques, lighting, story structure, it's own esoteric vocabulary, and other techniques. Likewise for construction, law, medicine, drama, education, etc. etc. etc.
In a large Agile Work project, teams need a way to coordinate their technique to produce integrated, consistent and compatible results. As well, individuals on the teams may discover or create new ways of doing things that would be valuable for the other teams to know about and use.
The most effective way of coordinating technique across teams is for strong members of each team to gather regularly to review the way work is being done. This "technical support group" can look at tools, reuse, automation, patterns, vocabularly and any other "how to" aspects of the work. It is critical that these people are actively involved in work being done on a delivery team so that efforts of the technical support group do not become academic or "ivory tower".
In certain environments, it may be useful to have this techincal support group become a team with a clear allocation of time apart from the regular delivery teams. In this case, this technical support team would have its own Work Queue that consisted of requests, ideas, concerns, and opportunities presented by the regular delivery teams.
I have seen all three aspects of coordination implemented in large multi-team projects. Some of the common challenges include:
- Generalist Teams.
It is difficult enough to create cross-functional teams where people are willing to become generalizing specialists. While it is important to create generalist teams, most organizations should expect to set up non-ideal specialist teams (sometimes by line-of-business) and support their development into generalist teams. - Technical Coordination.
Often organizations have a design or technical review group composed of the "experts". These people are often isolated from the actual work being performed by the teams. It is difficult, yet critical, that these people actually be involved in day-to-day work on the teams.
Posted by Mishkin Berteig at 09:15 AM | |
September 12, 2006
Yet Another Big Picture of an Agile Process
I created this image for a presentation targetted to management. It's a good high-level overview of what goes on in an Agile Work effort. Feel free to use this or the high res version... just keep the copyright notice on and put a link somewhere in your email/document/presentation/webpage/etc. back to Agile Advice. Suggestions on ways to improve the diagram would be greatly appreciated. I will try to update it... and maybe even get my incredibly talented visual artist brother Alexei to re-do it.
Here's the high resolution version, good for nice printed material: Agile Work - The Whole Process.
Posted by Mishkin Berteig at 08:52 AM | |
August 29, 2006
Seventeen Tips for Iteration Planning
Agile Work requires a team to take work items from a prioritized list, break those items into small tasks and then execute those tasks inside of the timebox of an iteration. When first trying agile, many teams have trouble with the task breakdown done in the iteration planning meeting. Here are some hints and tips for making this critical part of the agile process more effective.
1. Work items are, among their other qualities, valuable to the customer or stakeholders. Think of these work items as being built out of many smaller pieces. You can imagine a toy model made out of Lego bricks. Each brick, by itself, is of no value. It is only when they are put together that they become useful. The tasks you create for each work item are often small enough that they do not have any value on their own.
2. The word "task" implies activity... but the tasks you create for your work items do not need to be activity based. Tasks can be effective if they are written as components or pieces of the work item you are building. Here is an article about creating good tasks.
3. Sometimes if the work item is not well understood, you might find that a "research" or "experiment" task is a good starting place. Try to be as specific as possible. When writing the task description, spell out what exactly is the goal of your research, and possibly list what options you are going to research.
4. When first starting out with Agile Work, many teams find it difficult to do a good job of iteration planning in the fixed amount of time allocated to it. Consider shortening your iteration length so you can practice this skill more frequently. (Remember to make the planning meeting shorter too!)
5. Make sure that everyone has index cards and a pen to write with! Team members shouldn't have to wait for a "scribe" to write down a task. In many ways this is a brainstorming session. The Process Facilitator can collect all the cards after the meeting is finished if they need to be recorded more formally.
6. Do a first pass by creating "big" tasks... then break them up into smaller tasks if you have time. Since this meeting is timeboxed, it is better to get all the work broken down into big chunks than to break down only a small part of the work into very fine chunks.
7. If the same task keeps showing up for all your work items, it probably shouldn't be a task... instead it should probably be a process step or constraint or condition of satisfaction for the work you are doing. For example, if you always have to write a document that follows a template to record what you have done for each work item, then writing that document can be shown as part of your task board.
8. It's okay for tasks to be _very_ small.
9. Share your tasks! If you write a task down without telling the rest of your team, they can't use your idea to generate more tasks, nor can they improve on your idea.
10. Generating tasks in the iteration planning meeting is a problem solving and creative process. This is where you do a lot of your analysis and design work. This is where you struggle through options and choose _how_ to build/do your work.
11. Consider creativity technique such as light-weight brainstorming for generating lots of ideas quickly. Any technique you use should be streamlined for quick results.
12. Don't worry about administrative stuff while you are generating tasks. For example, if you normally put task cards up on a wall, wait until after the meeting is over to do this. Likewise, if you normally enter them into an electronic tools, wait until the meeting is over to do this.
13. Make sure you have scrap paper or a good whiteboard convenient for notes and drawings so that you can quickly model your solution for the work item. (Check out Agile Modelling for a discussion of this in the software realm.)
14. Remember that it's okay if you end the meeting with an imperfect list of tasks. You will make corrections throughout the iteration. It is more important to maintain the discipline of the timeboxed meeting length, than to get the tasks right up front.
15. The whole team must participate: everyone's experience, skill, expertise and insight are needed to do the best job of generating tasks. Just because it won't be a perfect list doesn't mean you can do a shoddy job of it!
16. You need quick access to information about the work items you are planning. You also need quick access to other relevent information. A computer with a web browser open to Google is a great tool to have at hand.
17. If you don't have anyone on your team who has lots of diverse experience and expertise, then consider inviting someone like this as a guest to help you out. It is much more difficult to do the necessary problem solving if you new to the medium in which you are doing the solving. Such a guest would need some time before the meeting to be prepared.
Posted by Mishkin Berteig at 10:44 PM | |
June 06, 2006
Agile Work Artifacts - the Work Queue
Agile Work requires only a very small number of simple "artifacts". The most basic is the Work Queue. This is very similar to the Scrum Product Backlog but there are some differences too. The Work Queue is like a carefully managed To-Do list. This article details the use of the Work Queue.
Basic Description
The Work Queue is a list of work to be done by a person, team, organization or community. The list consists of brief descriptions of what to deliver, not how to do it. The list is prioritized so that the item on the top of the list is the single most important thing to get done, with items below that being successively lower priority. All items on the Work Queue contribute directly to an overall goal. The person holding the Product Owner role manages the list.
Place in the Process
The place of the Work Queue in the process is very simple. The Work Queue is initially created after the overall goal is determined. Ideally, it is created before work towards the goal is started, but often Agile Work will be adopted for an ongoing effort, in which case work has already started. The Work Queue is constantly maintained by the Queue Master so that it maintains the above mentioned qualities. One or more of the items from the top of the Work Queue are selected to be worked on. As an item on the list is completed, it is removed from the Work Queue. The number of items on the list that are being worked on simultaneously will depend on the capacity of the people doing the work. If iterations are being used to plan work, then the Work Queue is updated every iteration.
How is it Created/Managed
The Product Owner is responsible for creating and managing the Work Queue.
The initial creation of this Work Queue is a simple process: based on the goals to be attained, and based on an other factors that are relevent, the Product Owner drafts an initial version of the Work Queue. The time spent on creating this initial version should be minimized using three techniques:
1. Keep the Work Queue small by recording only high priority items that need to be done immediately. Don't add items that are uncertain or will be done far in the future. (See "The Horizon of Predictability" for more information about this.)
2. Keep the Work Queue simple by focusing on point-form high-level descriptions of the items in the list. Don't worry about any details about how the item will be accomplished, who will do it, when it will be done, dependencies with other items, or technical or conditional details.
3. In advance, allocate a fixed amount of time to draft the Work Queue... and don't spend any more time on it than that. Get the assistance of the Process Facilitator to keep on track. The list doesn't have to be perfect or complete... you only need enough on the list to allow the work to start.
Ongoing management of the Work Queue consists of removing completed items or items that are no longer needed, adding new items as they are discovered, merging or splitting items as more is learned about them, and reprioritizing items. All of these tasks can be performed at any time. As well, the Work Queue should always be in a state of readiness such that the top items are ready to be selected for work.
The Product Owner is responsible for answering any questions that may arise about the work as it is progressing. If someone doesn't know what is meant by an item, then work on that item should halt until the Product Owner can clarify.
At no time is the Work Queue "frozen" or finalized. It is changing throughout the entire time that people are working towards the goal. Items that are completed are removed from the list, and do not need to be archived or recorded anywhere else, nor is it necessary to save versions of the list as it is changed.
Gating/Queuing
The Work Queue is a queue of work in process (WIP) that is built up in front of the people who are doing the work. As such, it is advisable to keep the list short. The Product Owner acts as a gate to the list: only those things that reasonably contribute to the goal and which are relatively immanent in implementation should be added to the Work Queue. If someone suggests something be added to the Work Queue, the Product Owner must, of course, take that under advisement and collaborate with the suggestor, but is not obligated to add the suggestion to the list.
The Product Owner can manage the size of the Work Queue by deciding how many iterations of future work are allowed on it. In other words, the number of items on the Work Queue is limited to how many can be accomplished in a fixed number of iterations. As the Team takes a number of items off the Work Queue, space is freed to add an equivalent amount of work back onto the Work Queue. The specific number of iterations chosen for this will vary depending on your circumstances.
Differences from the Scrum Product Backlog
The Work Queue does not require two things that are part of the Scrum Product Backlog: item estimates and item values. Adding this information to the Work Queue can be useful in many situations, but is not an essential part of the list.
As well, the management of the Work Queue is different from the Scrum Product Backlog in that the Product Owner is not obligated to put every suggestion that comes their way onto the list.
Advanced Use of the Work Queue
Consider adding the following information to each item on the list:
1. An estimate of effort. Make sure that these estimates are created by the whole group of people who will be doing the work.
2. An estimate of value. The Product Owner needs to be responsible for determining value, but the whole group of people doing the work and all the other stakeholders need to understand how that value was determined.
3. Cycle time tracking. When an item is added to the list, record the date/time it is added, then record the the date/time it is completed and removed from the list. The use of cycle time can assist in making a work process more efficient.
Posted by Mishkin Berteig at 04:24 PM | |
March 02, 2006
Five Signs of Trouble in an Iteration
During the course of an iteration, an agile team is able to track it's own progress through the use of burndown charts. The team and the process facilitator can use the burndown chart to watch for signs of trouble. As a coach, I find the following five burndown shapes are common indicators of trouble.
But let's first show the idealized "normal" burndown. This burndown shape shows that the team is on-track to get to done exactly at the end of the iteration. The work remaining has had a constant slope down through the course of the iteration.
Now the warning signs:
1. Too Much Work
In this burndown, the team sees that it has likely selected too much work for the iteration. The process facilitator and the product owner need to work with the team to decide how to change the scope so that the team can get done. One might be tempted to add people to the team to get the work done faster, but this is rarely successful.
2. Not Getting Done
Frequently, when a team is just starting out with agile work, it commits to slightly too much work. It is hard to detect this at the beginning of an iteration. Instead, it is only near the end of the iteration that it becomes apparent that the team isn't quite going to make it to done. The process facilitator must work with the team to determine the root causes of this and change things so it doesn't happen again.
3. Early Learning
When a team is starting the iteration, it can discover new things about the work it has committed to accomplishing. This can include dependencies, new tasks, extra components that need to be built, etc. This discovery process is normal, but needs to be monitored closely. If the burndown doesn't start going down again after about 15% of the iteration is over, then there is likely trouble brewing.
4. Unresolved Obstacles
Sometimes the team will run into an obstacle that will completely stop their progress. Although the process facilitator is responsible for dealing with obstacles, it may be impossible for an obstacle to be fixed quickly. If the team finds that all the work it committed to for the iteration is dependent on someone who is sick or on vacation, that can lead to an unresolvable dead halt. This may be an opportunity to cancel the iteration.
One interesting example of this was observed by a coach I work with frequently, Deborah Hartmann. She was away from her team for a few days and when she came back, she observed this "flatline" burndown. After poking around a little bit to try and find the obstacle, someone finally described what had happened. At the time of the flatline, a Vice President in the organization had come into the team's area, looked around, and loudly declared something to the effect of, "I don't know why you guys are doing this project. It's totally worthless!" Suffice it to say that the team was seriously demoralized. It wasn't a technical obstacle, it wasn't a procedural or bureaucratic obstacle, it wasn't even a cultural obstacle. It was just a serious blow to morale. Of course, to fix this, the actual sponsor of the project had to be brought in to assure the team that it was actually an important project and that there were people in the organization who needed the work that the team was doing.
5. Scope Creep
This last case is rarer for an agile team if the team and the product owner have been educated well about the rules. Nevertheless, it can happen. The product owner, or some other stakeholder, pushes the team to add scope to the iteration. The process facilitator is normally responsible for preventing this from happening. If despite this it does happen, the burndown chart makes the consequences of this scope creep.
Special Quiz Section!!!
What are the possible explanations for the following burndown shape? I have heard/experienced at least six different possible reasons. Leave your answers in the comments.
Update: at Agile Chronicles, there is a short article about this topic which mentions one more burndown chart pattern that is a bad sign: the "Late-Breaking Decline".
Posted by Mishkin Berteig at 01:34 PM | |
November 28, 2005
Agile Advice Recommended Materials
This page contains a number of links to recommended web sites, books or tools relating to Agile Work. This page will be updated from time-to-time and as this is done, announcements will be posted on the Agile Advice blog. As such, this page will always be "under construction". If you have links to suggest, I will examine them and put them up in my own time. Please feel free to email suggestions to topics@agileadvice.com.
Update 20070115: 1 new reference!
Introductory Material:
Agile Axioms
Agile Manifesto
Agile Work Cheat Sheets and White Papers - Berteig Consulting Inc. [pdf]
Agile Software Focus:
Extreme Programming
Methods and Tools
A Scrum Primer - Report from Yahoo! [PDF]
Control Chaos - Ken Schwaber and The Scrum Methodology
Agile Software Development by Alistair Cockburn
Agile vs. Lean - Thad Scheer
No Silver Bullet by Frederick Brooks
Agile Planet - agile blog aggregator
Buildix - agile software dev tools on a CD
Agile Forums
Implementing Scrum
Project Management:
Project Management Institute
Agile Project Management Yahoo! Group
Burndown and Burnup Charts
Huge List of Software Project Management resources
Scrum Alliance - Agile Project Management and Training
Project Management Resources - by Michael Greer. I don't agree with everything on this site, but if you are looking for traditional PM stuff this is a good place to go.
Lean and Theory of Constraints:
Lean Software Development - Mary and Tom Poppendieck
Evolving Excellence - by Kevin Meyer, Bill Waddell, Dan Markovitz NEW!
Theory of Constraints - Eliyahu Goldratt
Agile Work for Flow Projects - Mishkin Berteig
The Toyota Production System
Practice Without Principles - TPS Without the Toyota Way - Victor Szalvay
Agile Work Uses Lean Thinking - Whitepaper [pdf] by Mishkin Berteig
Management:
Agile Management Yahoo! Group
Slow Leadership - the opposite of Agile?
Adaptive Management - Jeffrey Phillips
Adult Education:
The Self-Educative, Narrative and Metaphorical Faculties of the Soul - Alexei Berteig (pdf)
Infed
Team Building:
The Wisdom of Teams: Creating the High-Performance Organization
Retrospectives
Retrospective Patterns by William Wake
How to Win Friends & Influence People - Dale Carnegie
Community Development:
Corporate Culture:
Catastrophic Organizational Change - Tobias Mayer
The Corporate Culture Survival Guide - Edgar H. Schein
Good to Great (fastcompany article) - Jim Collins
Agile Services:
Berteig Consulting - Agile Work Coaching, Training and Consulting
CC Pace
Digital Focus
Israfil Consulting Services Corporation
Scrum Alliance
Tobias Mayer
David Chilcott
Joe Little
Michael Vizdos
Agile in Other Domains:
Extreme Project Management for Architects
Experiences and Stories of Applying Agile in Other Domains:
Agile Documentary Video Project
Agile Publishing
The following sections of material are based on the Agile Work Cheat Sheet.
We are Creators
Reality is Perceived
An Introduction to General Systems Thinking
Change is Natural
About "Resistance" by Dale H. Emery
Trust is the Foundation
Agile or Not Agile?
Trust and Small Groups
Empower the Team
Launching an Agile Team - A Manager's Howto Guide
Amplify Learning
Abe Lincoln’s Productivity Secret - a nice little bit about being properly prepared (although caution should be taken not to over-prepare!)
Eliminate Waste
Self-Organizing Team
Variations on the Daily Standup - Rachel Davies
Scrum from Hell - William Wake
Team Formation Stages - Forming Storming Norming Performing
Iterative Delivery
Are Iterations Hazardous to Your Project? - Alistair Cockburn
Adaptive Planning
Maximize Communication
Edward Tufte's web site with lots of great info about the visual display of information
Human Tools for effective communication
Eight Barriers to Effective Listening
Facilitation Skills [pdf]
Test-Driven Work
The Qualities of an Ideal Test
Appropriate Metrics
Appropriate Agile Measurement White Paper (pdf)
Removing Obstacles
Intros and Summaries
The Seven Core Practices of Agile Work
Posted by Mishkin Berteig at 02:02 PM
|
|
Here's an excellent introductory article on the wideband delphi estimation technique. Typically wideband delphi is used to estimate software development efforts, but can be used in almost any domain of work. This method might be applied to estimating effort for items in a work list at either a project level or tasks in an iteration work list. The way it is described, it sounds fairly heavy-weight, potentially taking several hours for a relatively small list of work items. However, it is worthwhile for process facilitators and product owners to be aware of these sorts of methods if problems with estimating occur in a project team. The wideband delphi model is related to the Delphi method. [Update 2007/05/24] Agile Work and Scrum use a very different method of estimating work that has one very important and incredible property: people don't have to get better at estimating for them to get better at committing to work! The basic idea can be thought of as "commitment velocity". The method here is to use an arbitrary unit of effort that the team applies to estimating all tasks relative to each other. At the start of an iteration, the team can use any collaborative method (including wideband delphi) to come up with estimates for tasks. The team sums up the estimates for all the work of the iteration. Then, at the end of the iteration the team looks at the estimates for all the remaining undone work (if any) and subtracts that from the start of iteration sum. This is the Commitment Velocity. Now on their next iteration, they do their estimation work again, relative to the tasks in the previous iteration. If the sum of the estimates is larger than the Commitment Velocity, then the team needs to de-scope or find more efficient solutions to their work. This process usually converges after only three iterations (assuming: constant team composition, constant iteration length). This method is taught in detail in my Agile Project Management courses, and there is a little bit more information here: Planning vs. Commitment. The agile estimation method of Commitment Velocity is an application of the Central Limit Theorem from statistics. [Update: 2007/09/11] Wikipedia now has an article on Wideband Delphi. The article points out some interesting potential problems with the wideband delphi method including corruption of the group doing the estimation and suppression of minority opinions. I know that in my experience as a coach, I have seen numerous occasions of both types of problem with estimation processes. The fact that wideband delphi is susceptible to these problems is more a factor of the human side of things than the method itself. Interestingly, the wideband delphi method of estimation is very similar to the "Planning Poker" method of estimation used in many agile and scrum project environments. This method is also covered in the Agile Project Management courses. Other links to wideband delphi: Wideband Delphi Estimation Process The ProjectInitiation.com website has a wideband delphi worksheet (MS Word) available. Project Estimation: Wideband Delphi
Posted by Mishkin Berteig at 12:40 AM
|
|
In her workshop "Advanced Scrum: Collaboration Skills for Scrum Teams", Esther Derby includes a brief discussion on the five parts of a decision. 1. Define the Problem At each step, it is instructive to examine who is "responsible" or involved. In an agile team where team empowerment and self-organization are considered critical success factors, the answer to "who?" fore each step should usually be "the team". There are however, some situations where decisions are outside the realm of a team's empowerment. As well, some decisions are so trivial that it is wasteful to have the whole team involved. In these trivial decisions, usually another person can take responsibility for all the steps of a decision as a service to the team. Over time, a team and the organization in which a team operates can evolve a set of standards that describe who acts in each step of a decision under what circumstances. Many thinking tools described by Edward de Bono in his various books (such as Six Thinking Hats, Lateral Thinking : Creativity Step by Step (Perennial Library), Textbook of Wisdom etc.) can be used at various steps in the decision making process.
Posted by Mishkin Berteig at 11:48 PM
|
|
As part of the Advanced Scrum Training, Esther Derby presents a section on conflict. One very insightful part of the presentation is a description of four reasons for the existance of conflict or disagreement. They are as follows (adapted from "Advanced Scrum: Collaboration Skills for Scrum Teams" (c)2004-2005 Esther Derby): 1. Lack of Clarity - the communication between parties is missing information or the information is not being communicated in a consistant manner. 2. Position Focus - the parties involved have already each decided on their own solution and are failing to discuss the problem those solutions are addressing. 3. Different Values - the parties are unable to agree because they are holding different sets of values but not articulating those values as part of the discussion. 4. Past History/Personalities - the parties have a previous unresolved conflict that is negatively affecting their ability to work together. All of these types of conflict are based on either conscious or unconscious failure to be truthful... and therefore the different parties have incompatible perceptions of reality. The Agile Work axiom "Reality is Perceived" then gives us a hint as to how to resolve all of these types of conflict. Find a way to share perception among the parties in conflict so that they have a compatible view of reality.
Posted by Mishkin Berteig at 10:52 PM
|
|
| TrackBack
Summary: In this well-written, engaging book, author Jim Collins describes six critical factors that he and his research team found common in companies that transformed themselves from a long period of mediocre or bad results to a long period of great financial results. Although focused on publicly-traded companies in the United States, the results of this research can easily be extended to apply to other types of organizations. Good to Great describes the following six concepts:
September 26, 2005
Wideband Delphi Estimation Technique
May 10, 2005
Steps in Making a Decision
2. Establish Focus and Boundaries
3. Identify Options
4. Choose Among Options
5. ImplementMay 09, 2005
Reasons for Conflict or Disagreement
April 18, 2005
Book Review: "Good to Great" by Jim Collins
Some of these concepts are very close to the underlying prinicples of agile work. For example, in the Scrum methodology, the first five principles are all represented. The Scrum Master embodies some of the attributes of level 5 leadership. A self-organizing team gets the right people in the right position. The daily scrum and the sprint planning meetings are designed to help the team confront the brutal facts. The sprint goal embodies at a local level the simplicity of the hedgehog concept. And the practices in general are a manifestation of a culture of discipline.
Who Should Read this Book? Anyone interested in creating a lasting positive transformation in an organization should read this book. In particular, individuals who are coaching teams or organizations should read this book since the concepts also appear to apply at a sub-organizational level.
Posted by Mishkin Berteig at 07:29 PM | |