« August 2006 | Main | October 2006 »
September 29, 2006
The story-driven standup
We all know the three questions of the daily SCRUM standup. In every standup we go around the room one way or the other and give a status on our tasks. This is what I've come to call the status-driven standup. In my article I've proposed a different style of standup I've come to call the story-driven standup.
You can find the article here: The Story-Driven Standup
Posted by Guest at 08:55 PM | |
September 22, 2006
A Good Agile Blog
I have found a good blog about agile software development. Although software-focused, there are several articles I have read that deal with teamwork, personal dynamics, management and other topics that are generally applicable.
Posted by Mishkin Berteig at 11:56 AM | |
September 21, 2006
Agile Advice Recommended Materials (Updated)
Agile Advice Recommended Materials page of links has been updated with six items. This page is slowly growing into a substantial reference. Please feel free to suggest things to add: web sites, blog articles, pdf's, books, etc. Any thoughts on turning this page into a wiki? Is there an existing wiki to which I can move these?
Posted by Mishkin Berteig at 07:15 AM | |
September 20, 2006
Recipe for Effective Meetings
I was running late for a meeting. Frustrated over being late, the meeting itself that looked like a waste of time, and overall number of meetings we have, I got an enlightment:
Meetings are a penalty for the lack of effective [face to face] communication.Meetings are overhead. Trash. Wasted time, multiplied by the number of participants. They grow in length and numbers and the process becomes Meeting Driven Development.
But in a real world software organization we do have meetings, and no chance to eliminate them in any foreseeable future. The best we can is keep them under control.
A simple recepie of effective meeting:
* Own a meeting
* Define the goal, and expected outcome.
* Publish Agenda
* Come prepared
* Keep it short. Consider timeboxing.
* Close the meeting explicitly.
Comments on the bullets:
Coming prepared made easier when the goal, agenda, and expectation are set and known in advance. But still takes a commitment, discipline, and some training. If you see the participants didn't do their homework, stop and reschedule the meeting. It doesn't pay to continue the meeting; so you better send a strong message and the next time it will certanly be better.
Why timeboxing? Look at those people! When they come to an air conditioned board room, dive into those nice executive leather cheers, and got ready to a nap, buddy, good luck with your agenda! To keep the energy level high, keep the meeting short. Timebox it to 30 minutes, and say so. Keep a timer. Stand up. Make everyone physically participate - write on a white board, take notes, walk, move! Don't steal the whole meeting (oh, is it Dmitri saying that? who can believe!?)
Sometimes the meeting subject should be resolved and finished no matter what. Even then an incremental iterative approach to meeting pays off.
How to know when the meeting is done? How to know if it went well? The answer to this is a goal and expectations posted with agenda, and restated first thing in the beginning of the meeting. Write them down on the white board, have everyone look at it throughout the meeting.
Define the type of the meeting. Is it a brainstorming session? Is it a presentation? Is it an open discussion, feedback generation exercise? Are you gonna consume this feedback or throw it away? Decide, and define.
In closing, recap the goal, outline results, next actions, assigments. If the meeting was effective and productive, say so. Make your mates feel well (even if they missed their nap).
The final bullet:
* Foster communication beyond formal meetings. Remember that "Meetings are a penalty for the lack of effective communication."
Originally posted on Software Frontier
Posted by Dmitri Zimine at 06:53 PM | | | TrackBack
Intro to Scrum - and Excellent Data from Yahoo!
Yahoo! has been using the Scrum methodology for quite some time now and two of the key people there have written up an excellent description of Scrum [pdf] along with a set of survey results from the 600 people using the method at Yahoo!. The best highlight from the results is that 85% of team members said that they would continue using Scrum if the decision was left up to them!
Posted by Mishkin Berteig at 03:58 PM | |
September 19, 2006
Agile Challenges - A Good List of the Common Problems with Agile Methods
Aaron Korver writes a list of ten ways that agile can have problems. Here's the list in brief with my comments:
1) Increased Visibility can cause organization crisis. Use an understanding of corporate culture to help prepare for this crisis.
2) Loss of titles. Agile tends to flatten organizational hierarchies.
3) People have to work together. And most people in large organizations work in groups, not teams. Small organizations might not have this problem.
4) Projects fail fast. They also can succeed fast... either way this can cause budgetting problems and all the corporate politics that goes along with this.
5) Sustainable pace. Some people like heroics, and most organizations respect and reward heroics - this is very very hard to change.
6) Feeling of micro-management. But teams are actually supposed to be self-organizing.
7) Less up front design. Getting started is one of the most difficult things for many organizations.
8) Flawed implementation of agile. Setting up the environment and the support a team needs is not trivial.
9) Physical reorganization costs. Although usually these costs are recovered in productivity increases.
10) Loss of privacy. It takes time for people to get used to working together.
This is a good list and I have seen all of these things be challenges to teams and organizations adopting agile methods. I've linked each one of the above to one of my previous Agile Advice articles.
Posted by Mishkin Berteig at 04:21 PM | |
Learning Circle - Interview with Garry Berteig (Updated)
The Learning Circle is a graphical description of the cyclical stages of learning and the qualities that are necessaary to go from one stage to the next. This method has been developed by the artist and teacher Garry Berteig as part of the application of Agile Work to his instruction. What follows is a short iterview with Garry after he attended one of my Agile Project Management / ScrumMaster Certification courses.
AA. Why should people be interested in this Learning Circle?
GB. Usually, the action/reflection cycle is one of trial and error... it's a very common experience for us, say learning to ride bike, through trial and error we actually learn. We also learn by modeling behaviors. We learn to speak, we learn to socialize. So that's a very short feedback loop. It's very effective.
What interested me about this model comes out of recognizing that my students didn't really know how to identify their own learning. And so they expected the teacher to determine what they had learned by giving them exams and other sorts of assignments with marks. Then I came across a development model in the "Building Momentum" document issued by the Baha'i World Center around 2003. There were very interesting considerations that focused on learning by using short three month cycle with reflection gatherings that ended a sequence of action, reflection, learning and planning. I thought it would be interesting to apply features of this Building Momentum document to my art classes because there it would be possible to increase the frequency of the cycle from three months to say six to twelve cycles in three months. Further to increasing the frequency of cycles, the student grouping in my class is quite diverse and it would be a way of testing what the model could generate in a group that was usein the model as a tool for artistic growth.
After explaining it to the students I tried it and applied as best as I could in the context of several art classes. The students were delighted with how easy it was to apply to their own lives! Not only to art. And so they bought into it as a method. Gradually we began to use the Action Reflection Learning Planning model in our method of conducting a critique. This circle was applied to work that the students did based in assignments. It became clear that this model had generated learning attributes in these students - these were exciting for me to recognize. I gradually recognized these attributes were arising from the movement from one stage to the next in the learning circle.
AA. Describe how this learning cycle was applied in your class.
GB. [In my sculpture class we used] a four-step process and in each step we use the circle as a critique method. The first step was to make an egg shape out of clay. Because it's the first time, it takes them about 45 minutes to make an egg shape about 6” long and 5” wide. Then I had them do it again. And this time it would only take them about 10 minutes. And the third time they did it they could probably make the same thing in about 5 minutes. Clearly, practice was the key learning in that first cycle or iteration. It gave the students an understanding that repetition reinforces learning and confidence. That's one iteration if you will. Making that set of three eggs is one group of activities that we then applied the learning circle to. We talked about the actions of doing it three times. Their reflection on those actions gave them an insight about learning which was that by repeating something they got better at it and they became more confident. An important outcome was that the first iteration established trust between them and me so they would accept guidance from me.
Then we began to do the second step in making a head and remember the head is based on the egg shape. I then showed them how to make a kind of a blank where you have the location for the eyes and the nose and the mouth in terms of the egg shape where the point of the egg is the chin and the large part is the back of the head. We do that several times. And each time we do it students become more confident in making this generic human head. As before, we have a critique and use the learning circle to help consolidate the experience with the students.
Then the third iteration is to bring a model into the studio, having a blank prepared, and now make a portrait of the model. What happens is that students end up with self-portraits! Because they have a prejudice, unknown to themselves of what the human face looks like. This prejudice of how a face should look is derived from looking in the mirror 10000 times and only looking at the model once.
In the reflection process then, some students resist this recognition of the result being mostly a self portrait. But as the group identifies details of the portraits they've made, for example the nose of the model is like a ski jump but the nose the student has made is like a hump... the student realizes they have made a self-portrait. This comes as a real eye-opener... a real revelation to the student! The insight that comes into focus is that they have predispositions. Therefore to make an action reveal it's true potential, detachment from preconceptions and/or benchmarks is necessary. So detachment is the first condition of really learning.
AA. So is detachment one of the attributes that you mentioned earlier?
GB. Well we haven't listed them, but it is one of the key learning attributes. Detachment comes into focus through the instrumentality of the group consultation and the role of the mentor in the reflection part of the learning circle.
The next thing that becomes evident is that in order to identify the learning that has occurred, there has to be a search for the principle that arises out of the action and the reflection. Identification of that principle may be quite elusive to the group and the individual at the stage they're at in the discipline. It may be [obvious] to the mentor, but not to the group. Certainly patience is required in that quadrant. However, when you identify that specific principle, for example the importance of contrast in two dimensional art, you move to the learning part of the circle and begin to investigate what other practitioners have donewith that principle as applied in their work. In our case sculptures or paintings. But it might be some practice in medicine. The learning is accelerated because of the work that other people have done. The acceleration of learning seems to be linked to love of learning. Love of the discipline is an attribute that emerges in the individual. There's a kind of fire or heat ... an urgency that comes along with it to learn more. It causes excitement in the person that is involved and the group that is involved. This love and this learning prepare a space or condition to receive guidance. Guidance comes in many forms but often seems to be a gift and a bit of a mystery.
In the individual [guidance] may emerge as inspiration and insight. In the group it emerges through consultation. It may also come from a mentor. The next thing that happens then is that what was learning now becomes conscious knowledge. This gives people courage. Conscious knowledge and courage seem to be hand-in-hand in the planning part of the process. It makes it possible to plan in a very strategic way and also in a very flexible way. It takes courage to go to a new level of action where you've never been before. And that's the power of this process. It caries people through identifiable stages with attributes that become strengthened as you go around and around and around the cycles. So that's basically why it's useful. The iterations generate detachment, search, love and courage. Attributes that give rise to the realization of individual and group potentials.
The term guidance is very significant. Because it's not prescriptive. It enables people to find solutions ...often unpredictable solutions... to the problems, the assignments.
AA. So what does this look like in your media class?
I won't go into detail, but I have the students do a single movie still a la Cindy Sherman that is a shot indicating a story that came before and will continue after that single momemnt. The first cycle is to develop a story. So the Action Reflection Learning Planning is to develop a story, present it to the group, take their responses and plan a modification to the story. We do that several times so that each student has a story that is coherent. That's the first step if you will.
Second step is to go and shoot, to photograph, the single shot that is a movie still that represents the whole story at some juncture in the story. Bring it to class, and the group reflects on it and makes recommendations to the author who learns something from the group, plans and re-shoots the still. The learning that emerges is powerful. Again, there's a kind of amazement at how perceptive individuals are about the image. And how you can't fool anybody. Of course, this creates in every student a search mode. They have to search within themselves for a better solution... and they do and they find it. It's really exciting.
The third step is a second still photo that rounds out the narrative of the story and the fourth step is to do a video of the scene, with all of the angles, lighting, make-up, costumes and mis en scene concerns looked after.
Garry Berteig is an instructor at Keyano College in Northern Alberta where he teaches Sculpture, Media and other visual arts. Some feedback from Garry's students about the use of Agile Work and Scrum has been posted here on Agile Advice before: Scrum Saves the Day for Media Student and A Student Documentary Film Project.
Posted by Mishkin Berteig at 12:16 PM | |
September 18, 2006
Offshore/Distributed Agile: Challenges, Productivity and Tools
On the agile-usability Yahoo! group, someone asked about tools to mitigate the consequences of having an off-shore team doing some of the work. I have strong feelings about this.
I've seen lots of tools/techniques tried for this.
But it basically comes down to this: as a team, if you are not all colocated in an effective team room, you are going to take a hit in productivity. That hit averages out to about half the productivity level. Everything you do to mitigate this by alleviating the communication difficulties will only get you up to that half-way point. Any desire to get close to the productivity levels of a colocated team is bound to be frustrated.
On the other hand, if you don't have colocated teams now and if in fact your "teams" aren't really teams, then putting in some good communication tools can help increase your productivity. Whatever your current state, you can make improvements. Focus your improvement efforts on two things: reducing the cycle time for communication, and improving the richness of the communication channels.
For offshore teams, high-speed access to the same work environment as the "onshore" team is critical (for software, this means code base, development environment, test environment, db environment, tools, etc.). If you have them on separate system (for example due to paranoia about data going outside your company), then getting them on the same system as your onshore guys is going to result in a big improvement. This is a way to improve communcation that for some reason is often overlooked.
If your offshore team is on the opposite side of the earth, then you are going to have to stick mostly with "batch" communication. Every day, a batch of questions, requests, comments, feedback, etc. is going to be batched up by one group or the other and there will be a 24 hour lag time in responses. If you are doing two-week iterations, this is 10% of your time (!!!) just to do what might be a very simple communication. Compare that to people sitting beside each other who might be able to have the same exchange in 15 seconds. If it's a tough problem, the batching will make this lag even more pronounced. (BTW, some off-shore companies offer people who will work the night shift in order to be available to your team. I ask a simple question: would your on-shore team be willing to work the night shift? Hopefully you can guess my feelings about this practice from that question.)
So, if you are early on in adopting agile methods, I strongly recommend that you don't use your offshore resources. If the organization insists on paying for them, then let them sit idle. Yes, that's right: IDLE. Your on-shore team will probably be more productive without them.
If you have lots of experience with agile, then do the experiment: find out if it makes sense. But make sure you have a good way of measuring productivity so that you can tell if the cost savings are worth the hit in productivity.
If the bulk of your team is offshore, and you simply don't have the expertise on-shore, then send a couple of your customer/business/ requirements experts over to stay full-time with the off-shore team. This is often worth it.
And of course, if you just can't do it any other way than the "standard" split on and off shore teams, then make the best of it by constantly trying new ways to communicate. The guidance that Martin Fowler gives is sound, and everything else is left up to you to discover based on corporate culture, resources available, etc.
Posted by Mishkin Berteig at 02:04 PM | |
Agile Documentation Tool: Tiddly Wiki
This is super cool: TiddlyWiki - a wiki that you can run locally. Just download the empty TiddlyWiki.html file onto your hard drive or a USB key or an SD card, etc. Put it into a subversion repository and you have a way of treating documentation just like code: nicely versioned, flexible, easily editable by anyone, and just generally really really cool!
Posted by Mishkin Berteig at 08:44 AM | |
September 15, 2006
Agile Survey: Lots-o-good
An agile consulting group in the US has run a survey on the results of adopting agile methods. Some highlights:
Scrum was the most-used methodology at 40% of respondants.
Time to market was a big benefits with 60% of respondants indicating an improvement of 25% or more.
And a lack of people with agile experience was the single largest factor cited in preventing or slowing the further adoption of agile in the organizations.
Thanks VersionOne!!!
Posted by Mishkin Berteig at 11:45 AM | |
How to Prioritize a SCRUM Backlog
A prioritized list of work items is a key artifact of any Agile development process. Take a SCRUM Project Backlog or eXtreme Programming User Stories as examples. Armed with such lists, the development team will be working on the most important tasks at any given time.
The problem, however, is that assigning priorities to real tasks on a real projects doesn't follow a simple recipe. The act of prioritizing is the art of prioritizing. And as with any art, there are always tips and tricks. I will share a few from my experience.
Before We Plunge
I assume that a "collection" of items and a "time estimation" are already done. We have produced the list is of items with rough estimations waiting to be prioritized. I recommend a brisk borders between "Collection", "Estimation" and "Prioritization" stages. Have the "collection" and "estimation" sessions officially "closed", switch to "prioritizing". Don't let the talk to drop back until we have the priorities done.
Backlog Prioritization
The default strategy a project owner tends to take is "everything is important". As a SCRUM master you will try and convince him to use priorities, and explain that the Project Backlog "is a prioritized list so that the item on the top is the single most important one, with items below that being successively lower priority."
But how to do it in reality? Let's get a feeling: for the lack of a real project backlog, try to prioritize a vegtables in a grocery store. It is obvious that Oranges (10 lb) beats Potato (20 lb). But should onion (3 lb) go before tomatos (5 lb) or just after? What about lemons and garlic (1 lb)? Man, it just feels silly. Frustrating. Makes no practical sence. Discriminates the whole prioritizing session. Doesn't work for me.
This is my approach: In assigning priorities, usually ranged from 1 to 5. Why 5? Just cause I've got 5 fingers on my hand, and got so used to it.
On the first round we quickly go through the list and a project owner assigning the priorities from 1 to 5 as he feels. Don't think too much on computing exact priority to an item: use intuition. When in doubt, give it 3, and move on. Make it fun, and move it fast. We are not going for precision for now.
The result of this quick round is already good enough: look, we got some priorities! So many projects around work with no priorities AT ALL. We are light years ahead of our competitors! Cheer up! Great start!
The second round: refine. Compare equal priorities, escalate more important items, put down tasks that appear less important. Not sure? Appears equal? Fine, keep them. Try it out and you'll find that adjusting the original rough draft is easy. Few mintues later we are looking at a refined prioritized list that makes sense.
The final touch: count estimated time per priority, write them down on a whiteboard. It will look something like: Prio 1: 3 weeks, Prio 2: 12 weeks, Prio 3: 6 weeks, and so on. This simple math exercise is often incredibly revealing: a collective oh... sh.t are often heard. We brought to our conscious mind how much time we are going to spend on what we named "important". But how much time we actually have? This conflict usually triggers another burst of thoughts, and some final jiggling of priorities.
At this point our list of items is prioritized just fine to use it for planning the iteration. And it doesn't take much time to do: we did prioritize lists of 20 items in 10 minutes.
Final tips
Cross-posted from Software Frontier
Posted by Dmitri Zimine at 11:12 AM | |
September 14, 2006
Agile Work for Publishing
Michael Fitzgerald got the idea to apply agile methods to publishing. The article I have linked to is a good description of what he is thinking.
He could take the idea a lot further. For example, he staggers the work of the writer and the editor. This is "mini-waterfall". Sure, it's better than one big bang of editing at the end, but it's still not doing the work simultaneously. Or writing one chapter per iteration. That only works if you can publish each chapter on its own. Each iteration should end with a potentially shippable result. It would be better to write a prose-style outline of the whole book, with maybe a little bit more detail in some key part.
Those observations aside, it is nice to see someone thinking about applying agile outside of software.
Posted by Mishkin Berteig at 10:17 AM | |
September 13, 2006
Last Call: Discount on Agile Project Management Courses this Fall
Two days left to take advantage of an 15% discount for Agile Project Management / ScrumMaster Certification courses being offered across Canada this fall. Locations include Toronto, Edmonton, Calgary, Halifax, and Kitchener/Waterloo. This offer ends on Fri. Sept. 15th 2006, 23:59 EDT. You must follow the above link in order to receive the discount.
Posted by Mishkin Berteig at 04:48 PM | |
A Manager's Introduction to Agile Work - PDF Download
I have just finished writing a first draft of A Manager's Introduction to Agile Work. With feedback from you, my loyal reader, I hope to do two or three iterations of this over the next weeks and develop something that you feel comfortable presenting to middle and upper management. The draft can be downloaded from the Berteig Consulting Inc. Agile Work Resources page. I look forward to your comments, questions and suggestions.
Posted by Mishkin Berteig at 10:24 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 | |
September 11, 2006
Agile Team Launch - a Howto Guide for Managers
Starting off on the right foot is just as important as it ever was. However, with Agile Work, this takes on a significantly different meaning than it does in other methods as the emphasis of what is "right" is also significantly different. This is a short guide on how to successfully launch a team using Agile Work.
0. Do what you need to in your organization to get a project and its budget approved. This usually involves some sort of business case, project charter and approval process. This may sound obvious, but the organizational support that this provides is essential.
1. Management must have a basic understanding of the method and in particular the roles: Queue Master, Process Facilitator and Team. This can be accomplished in a number of ways: reading, attending a workshop, or bringing a coach in to do a brief presentation. By "management" is meant at least the person sponsoring the launch of an agile team.
2. Individual people must be identified to fill the Queue Master and Process Facilitator roles. At first, these people should be assigned to these roles full-time and relieved of their previous duties. Ideally, the people filling these roles are volunteers from a pre-selected group of appropriate candidates.
3. The Queue Master and Process Facilitator must both get some initial training. For this, the following books are recommended for both roles: Agile Estimating and Planning (Robert C. Martin Series)
4. Form up the team. Getting this right is not easy: the team needs to remain relatively small (5 people is about right), but at the same time include people with all the skills necessary to deliver the whole project. You need people who are good at the various technical skills needed, the people skills needed, the problem-solving and analysis skills needed, and the administrative skills. All these people need to be part of the team right from the start. Again, for emphasis: do not start the project before all these people and their skills are dedicated to the team and they have been relieved of their previous duties. Forming the team includes logistical concerns such as where the team will sit, making sure they have the right equipment for their work, etc.
5. If you are trying agile for the first time, don't consider using a distributed team or off-shore resources. Nor telecommuters. This type of stuff is better left for once your organization has more experience with agile methods.
6. Provide initial training to your team. Include the Queue Master and Process Facilitator in this training (they are considered part of the team). Also include any significant stakeholders in the results of the project. Give them, at a minimum, a one-day introduction to agile.
7. The Queue Master creates an initial Work Queue. The rest of the team should participate in this process. The creation of this Work Queue must be timeboxed. I advise that it should only be given 1 or 2 percent of the overall project time. Decide before you start on how long will be given to this. The end result of this is a Work Queue that has some number of work items defined, understood by the team, valued, costed, and prioritized. The Work Queue does not have to be "finished". It is more important to hold to the timebox than to get the Work Queue "right". Remember that the Work Queue will continue to be refined as the team progresses in its work. Do not under any circumstances create the initial Work Queue in the absence of the team!
8. Run a brief project workshop. In this workshop, the team answers basic questions about the nature of the project run with agile methods such as:
- what is the length of our iterations?
- what are the team's core hours (when do all the team members commit to working together as opposed to working on administrivia)?
- what other teams/groups do we need to work with?
- are we missing any critical skills (now that we have seen the initial Work Queue)?
- what are the priorities of the project (quality, scope, time, budget, experimentation, etc.)?
9. OPTIONAL ITEMS:
- Consider doing a workshop on corporate culture and agile methods to help the team understand some of the challenges it will face and where it can find support
- Consider doing some initial team building exercises. Particularly if people on the team haven't worked together previously, this can help the team to get over some initial hurdles.
- Consider getting junior members of the team some additional training on the techniques, technologies or tools used in the team's work. This can be arranged so that it is done simultaneously with some of the team's early iterations.
- Consider engaging a coach or mentor for your Process Facilitator. This coach can be someone inside the organization who has extensive experience with agile methods or an external consultant who comes for a limited time to help your Process Facilitator.
None of these optional items should unduly delay the start of the first iteration.
10. Start your first iteration. There should be little or no delay or waiting between the creation of the team and the start of the first iteration. At this point the Process Facilitator is responsible for the process, the Queue Master is responsible for the value delivered, and the Team is responsible for delivering results.
Posted by Mishkin Berteig at 11:36 AM | |
Agile Software Development Forums
This is still new, but it looks to be shaping up to be a good place to go to talk about agile software development.
Posted by Mishkin Berteig at 12:35 AM | |
September 08, 2006
Communication Comic
Many of you have probably already see this, but it's a good Friday post: http://www.flickr.com/photo_zoom.gne?id=134931180&size=o. Courtesy of Scott Adams.
Posted by Mishkin Berteig at 09:27 AM | |
September 07, 2006
Seven Days Left for Discounted Courses
Berteig Consulting Inc. is offering a 15% discount on its fall courses being held in Canada. To make sure that you receive your discount, please follow this link and save your spot:
15% Discount on Agile Project Management / Scrum Courses in Canada
The discount is no longer available after Sept. 15, 11:59pm EST
Posted by Mishkin Berteig at 03:14 PM | |
Queuing Theory and Agile Backlogs
Queueing theory (1, 2, 3) and Lean pull-based queue systems provide some insights into why agile backlogs such as the product backlog found in Scrum are done they way they are.
Updated! (originally published April 6, 2005)
Typically, an agile team works by taking iteration-sized chunks of work off of the project backlog. Even though items on the backlog do not need to be the same size, by taking several off the backlog at a time, the total package of work for the iteration can be made a consistent size. The backlog is prioritized so the agile team is always working on the highest-priority stuff. So far, this is great: the work packages are consistently sized (iterations are always the same duration and with the same team), and generally small so the team is working at high utilization. However, individuals in the team may not be at a high level of utilization.
A basic lean pull-based system operates so that as a "server" (i.e. the project team) completes a piece of work, it pulls another piece off of a queue of work items and begins processing that item. However, agile methods say nothing about how long work is waiting in the queue. The work in this queue is in progress as far as the customer/client is concerned. Therefore, from the customers perspective, the time-to-delivery of an agile team is not managed because the size of the queue of work is not being managed. In most agile methods, including Scrum, there is no "gating function" that determines what work can be added to the backlog and when to add it. The Product Owner controls the backlog priority and maintains it. However the backlog
represents everything that anyone interested in the product or process has thought is needed or would be a good idea in the product. It is a list of all features, functions, technologies, enhancements, and bug fixes that constitute the changes that will be made to the product for future releases. (Agile Software Development with Scrum, p33.)
So what is happening? There is an implicit gating function occuring that releases work into the team's iteration. That gating function is based on the Product Owner prioritizing the backlog and refining the items so that they are small enough for a single iteration, and the team estimating the high-priority backlog items so that only enough for one iteration is released.
In terms of Little's Law, the team has deliberately pre-determined the average time a work item spends "in the system" (iteration). Therefore, the number of items taken from the backlog varies per iteration.
Is there another way to do this? What if the team, instead of being considered a single server, was examined from the perspective of the individual people doing the work?
In this case, the backlog would have to be managed differently in order for the system to work efficiently. First of all, the size of the backlog would need to be fixed. Then, items put on the backlog would all need to be of the same size in terms of man-hours. Instead of having iterations, the people on the team could each take items off the backlog independently. Finally, everyone on the team would have to be fully capable of doing any item on the backlog from start to finish. The Product Owner would then be responsible for replenishing the backlog.
In this scenario, iterations do not really make sense. However, this way of managing the backlog is only possible under the following conditions:
1. Work can be normalized into independent equal-sized packages.
2. Individuals work at roughly the same rate.
3. A single person is able to take full responsibility for a single work package.
We can see from this list of conditions, that for most creative endeavors, this is not realistic. This in turn points us back to the way that Scrum and other agile methods are designed. A team's velocity (rate of work completion) can be determined after a few iterations because work packages are broken into iteration sized chunks and because the team represents a single server in the queueing system. This in turn leads to much more flexibility in both the type of work packages that can be handled and the level of skill and specialization that the people constituting the team can have.
Check out the short whitepaper I've written about the relationship between lean and agile.
Posted by Mishkin Berteig at 08:59 AM | |
September 06, 2006
The Product Owner Role
I've been researching the requirements and variations on the Product Owner Role for a client that I am assisting. Here is a small collection of links and notes.
Updated (Originally posted Nov. 18, 2005).
Being an Effective Onsite Customer or Product Owner - great description of the ideal Product Owner.
Agile Product Owner Boot Camp - nice little bit in here about collaboration.
Certified Scrum Product Owner Course - don't know how good this is, but might be useful.
Here is my suggestion for a definition of the Product Owner role:
The Product Owner holds the final authority for determining the value, priority and details of all work done by an Agile team. The Product Owner wields this authority by virtue of a deep knowledge of the goal and end results desired as well as a respected position among all the stakeholders.
The Product Owner role is also known as the Queue Master, the Customer. People who have done the Business Analyst and Product Manager roles are often good candidates to fill this role.
Posted by Mishkin Berteig at 11:02 AM | |
September 05, 2006
The Seven Core Practices of Agile Work
Agile Work consists of seven core practices. These practices form a solid starting point for any person, team or community that wishes to follow the Middle Way to Excellence.
Self-Organizing Team
Any group of people that wish to be an Agile Team need to take the initiative to determine for themselves how they are going to work (process) and how they are going to do the work (product). The term "team" really applies quite broadly to any size group of people that are working together towards a common goal.
Teams go through stages of development as they perform their work. The most important result of team development is the team itself, and not the specific skills and abilities that the individuals learn.
If the team is part of a broader organization, that organization must give the team the authority, space and safety to learn to be self-organizing. The organization's leadership is responsible for determining the "why?", some constraints on "how?", and then letting the team respond to the need as best as it can.
Also Known As: Whole Team (Extreme Programming), Cross-Functional Team (business management).
Deliver Frequently
Agile Work uses short fixed periods of time to frame the process of delivering something of value. Each of these iterations or timeboxes is structured so that the team or group actually finishes a piece of work and delivers it to stakeholders. Then, the team builds on what has previously been delivered to do it again in the same short amount of time.
The sooner that valuable results can be delivered, the more value can be obtained from those results. This extra value is derived from opportunities such as earlier sales, competitive advantage, early feedback, and risk reduction.
There is an explicit tradeoff: the shorter the time to delivery, the smaller the piece of value will be. But, like investing in one's retirement account, the earlier you start, even with small amounts of money, the better off you are in the long run.
Also Known As: Sprint (Scrum), Iteration (Extreme Programming), Timeboxing (generic), Time Value of Money (accounting).
Plan to Learn
Every type of work is governed by a Horizon of Predictability. Any plan that extends beyond this horizon of predictability is bound to fail. Agile work uses an explicit learning cycle tied in with the planning of work to accomodate this inevitable change.
First, a goal is required. This goal can be long-term. Teams using Agile Work then create a queue of work items to be done in order to reach this goal. Each iteration, some of these items are selected, finished and then the queue is adjusted. The changes in the work queue are based on external factors, and learning that the team does as it goes.
One of the most effective methods for the team to learn about how it is doing its work is the retrospective. After each delivery of results, the team holds a retrospective to examine how it can improve.
Also Known As: Inspect and Adapt (Scrum), Kaizen (Lean), Adaptive Planning (generic).
Communicate Powerfully
A team needs to have effective means of communicating, both amongst team members and also to stakeholders. To Communicate Powerfully, a team needs to prefer in-person communication over distributed communication. Synchronous over asynchronous communication. High-bandwidth over low-bandwidth communication. Multi-mode communication over single-mode communication.
The results of failing to communicate powerfully include wasted time for waiting, misunderstandings leading to defects or re-work, slower development of trust, slower team-building, and ultimately a failure to align perceptions of reality.
The single most effective means to communicate powerfully, is to put all the team in a room together where they can do their work, every day for the majority of the work time.
Some types of work do not lend themselves to this approach (e.g. creating a documentary video), but every effort should be made to improve communication.
Also Known As: Visibility (Scrum), Whole Team and Team Room (Extreme Programming), War Room (business management).
Test Everything
Defects are one of the most critical types of waste to eliminate from a work process. By testing everything, by driving all the work of a team by creating test cases to check the work, a team can reach extremely high quality levels. This ability to prevent defects is so important that only an executive level decision should be considered sufficient to allow defects into a work process. Quality is not negotiable.
In Agile Work, removing a defect is the only type of work that takes priority over any new features/functionality/production. If the end result desired is to maximize value, then removing defects is an important means to that end.
A team has an ethical duty to discover new ways to effectively test their work. This can be through the use of tools, various feedback mechanisms, automation, and good old problem-solving abilities.
Also Known As: Canary in the Coal Mine (Scrum), Test-Driven Development (Extreme Programming), Defects per Opportunities (Six-Sigma).
Measure Value
Since Reality is Perceived, it is important for an agile team and organization to have a clear method of describing and perceiving what is important for the organization. Measuring value is a critical method for describing and perceiving what is important.
A single metric can be used to drive all the measurement and goal-setting and rewards in an organization. All other measurements are secondary and must be treated as such: limited in use and temporary.
There are many things which are easier to measure than value. It is often easy to measure cost, or hours worked, or defects found, or estimate vs. actual... etc. However, all of these other measurements either implicitly or explicitly drive sub-optimal behavior.
Also Known As: Measuring Results (Scrum), ROI (business management), Economic Driver (Good to Great), Running Tested Features (Extreme Programming).
Clear the Path
Everyone in an organization using Agile Work takes responsibility for clearing the path, removing the obstacles that prevent work from being done effectively. Clearing the Path doesn't just mean expedient, quick fixes to problems, but rather taking the time to look at an obstacle and do the best possible to remove it permanently so that it never blocks the path again.
In the Agile Work method, the Process Facilitator is the person who is responsible for tracking obstacles and ensuring that the path is cleared. To do this, the Process Facilitator maintains a Record of Obstacles.
Clearing the Path is sometimes painful work that exposes things we would rather not deal with. As a result, it is critical that people build their capacity for truthfulness and work to develop trust amongst each other. Building a capacity for truthfulness is not something that can be done by using an explicit process.
Also Known As: Removing Obstacles (Scrum), Stopping the Line (Lean).
Remember also, that these practices must always be viewed and implemented in the context of the Agile Axioms. These axioms provide a check to ensure that the practices are not being applied blindly, but rather applied appropriately to the given situation.
Posted by Mishkin Berteig at 09:09 AM | |
September 04, 2006
Pair Problem Solving - Sudoku!
In a training course I recently delivered, I tried a new simulation exercise. Using the game Sudoku, I divided the class into two groups: a group that would solve the game in pairs, and a group that would solve the game solo. My hope was that I would be able to demonstrate some interesting aspects of working in an agile team, particularly around communication and problem solving.
The setup for the simulation exercise was fairly simple: print out the same Sudoku puzzle multiple times, give the group basic instructions about how to do the puzzle, divide the room (1/3 are solo, the other 2/3 pair up), hand them out flipped upside down, make sure people had pencils, and then let people work on the puzzles for ten minutes.
After ten minutes, everyone put down their pencils and we listed out how many spaces had been filled in for each solo/pair. Since some people did not know how to do the puzzle, there was a large variation in the actual times.
The interesting part came with the discussion.
One important observation was that a person who was experienced at solving Sudoku puzzles felt hindered by having to work with someone who wasn't experienced. It was difficult for the experienced person to take the time and explain every time why he was putting a number in a particular spot.
Someone else mentioned that she felt time-pressure and did not enjoy that.
These two observations together led to a good discussion about how agile methods timebox everything and therefore there is always time pressure. However, scope pressure is meant to be relieved somewhat so there should be time to help bring junior / new team members up to speed. The frustration we feel when trying to work with someone who doesn't know how to do the work is often because we feel time pressure - we are impatient. Agile methods use timeboxing as a counter-intuitive way of relieving the time pressure.
There was also some discussion about how problem-solving for Sudoku may be easier in pairs because it is easier to search the overall solution space. Some of the pairs tried putting numbers in randomly and then seeing if the placements resulted in inconsistancies. Although no one solved the puzzle in the ten minutes given, there was a feeling by the pairs that their approach may have been able to solve the puzzle fairly quickly. This is something to explore further!
One person working solo said that she had felt frustrated because she did not understand the puzzle. That immediately led to a pair piping up and saying that even though both of them had never done Sudoku before, they felt mutual support and therefore it was fun rather than frustrating.
The next time I try this, I would like to try solo, pair and trio work. I would also like to give better instructions: that the puzzle should be solved purely using logic, no guessing, that the puzzle has exactly one correct solution (and making sure I have it available for comparison). I would also like to give the class fifteen minutes instead of ten minutes to work on it. I will start collecting times to see if there are any statistically significant relationships between group size and number of cells correctly filled in.
Posted by Mishkin Berteig at 03:15 PM | |
September 02, 2006
Scrum and SVO-p
SVO-p is an English syntax well suited for use in Agile processes such as Scrum. SVO-p stands for Subject-Verb-Object, Present Tense. Communicating in SVO-p requires defining who is acting, what they are doing, and to whom. It requires placing the thought in the now. The special features of the SVO-p syntax make it particularly well suited for use in Agile communications.
For more information, please read the blog entry: Scrum and SVO-p (Dan Mezick, APLN Hartford Chapter)
Posted by Guest at 12:21 AM | |
September 01, 2006
Developing Trust
Agile Work is a set of methods that are useful in working effectively and delivering value to stakeholders. There are many good business reasons to use Agile Work. There is also a very important human reason to use this method: developing trust and the capacity for truthfulness.
Everyone has struggled at some time or another with being truthful. At work, this may happen out of fear or embarrassment; if I've done something wrong or made a mistake, I don't want others to know about it. Many work environments push people to a CYA (Cover Your Ass) attitude.
Agile Work has a few practices that help move us away from this and towards greater visibility and truthfulness.
First, frequent delivery of value: this practice, using iterations with strict timeboxes allows us to make a commitment to get something done, and then do it, and then show everyone that we did it. Often this one thing alone is sufficient to start the process of removing distrust and replacing it with visibility and truthfulness.
Second, status meetings and retrospectives: these practices allow team members to regularly report on obstacles and things that need improvement. These obstacles and needs for improvement are often the things we hide out of fear or embarrassment. By using these practices on a regular basis, we become more and more comfortable with raising our concerns. As well, the fact that these practices are an explicit accepted part of the process helps to legitimize and provide a safe environment for people to raise obstacles and needs for improvement.
Third, powerful communication: by having the team use highly visible information radiators, and by having the team work together in an open team room, there is more physical visibility of what is happening. It is harder to hide the fact that I spend 5 hours a day surfing the net. It is harder to hide the fact that I spend 3 hours a day on the phone. It is harder to hide the fact that I come in late every single day. This can be uncomfortable for those who have something to hide! Powerful communication also includes working face-to-face jointly on many problems and their solutions. If you are insecure about your own skills or knowledge, this also can be challenging. Nevertheless, this practice also helps develop visibility, truthfulness and trust.
It is important for the team and management to realize that it does take time to develop trust. Depending on how many of these practices you use, and how sincerely you work on them, the development of trust may happen quickly or it may happen slowly. This has implications for deciding on trade-offs. If trust develops slowly, then it will take longer to get a team into the performing stage of its development and therefore it will take longer to get to a hyper-productive state. Just to be clear: for a business this means that value is delivered slower!
What other ways do agile methods help develop trust and the capacity for truthfulness?
Posted by Mishkin Berteig at 08:14 AM | |