November 09, 2007
Agile Contracts
One of the Certified Scrum Trainers, Chris Sterling from SolutionsIQ, recently posted a good set of links on Agile Contracts. Hopefully these links will help you understand how to "sell", set up and execute on agile contracts. Here are the links:
Chris wrote:
Mary and Tom Poppendieck have great presentations and a workshop on this topic. Here is a URL to a Powerpoint presentation from them:http://www.poppendieck.com/pdfs/AgileContracts.pdf
Also, here is some data from a workshop:
http://www.poppendieck.com/agilecontracts.htm
And Alistair Cockburn has a great page on Agile Contracts here:
http://alistair.cockburn.us/index.php/Agile_contracts
Martin Fowler has a page on “Scope Limbering” here:
http://martinfowler.com/bliki/ScopeLimbering.html
Hope these help.
Thanks Chris! Here are a couple more links:
Leading Answers - Agile Contracts - blog entry with some good references.
Contracting Agile Projects - by the Cutter Consortium
I'm not an expert on agile contracts myself. I would be interested in hearing from people if they have any stories about actually using (or failing to use) contracts in an agile environment.
Posted by Mishkin Berteig at 07:17 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 | |
Agile Benefits: Responding to Change
The fact that agile methods increase return on investment, accelerate learning, increase stakeholder satisfaction, and enable better control of work are all an interesting result of this final benefit: responding to change.
Responding to Change
The whole idea of "agile", and one of the primary reasons for the choice of this word is the final item of the Agile Manifesto: "Responding to Change". It is clear that this is one of the distinguishing features of agile as compared to a more traditional waterfall or phase-based approach to working. Not so obvious is that this is also true about agile compared to a more chaotic or ad-hoc way of working.
Agile and Waterfall - Change "Control"
In most waterfall or phase-based approaches to working, change control is a technique used to evaluate change requests and then accept or reject them. The practical consequence of this is that "control" often becomes a euphemism for "prevent at almost any price", and we end up with results that satisfy no-one because life changes.
There are, of course, some changes that are accepted even in a change control environment. These changes tend to be the ones that have both a powerful sponsor and a "wealthy" sponsor. The next problem with change control relates to the fact that change becomes very expensive in a phase-based process. It usually means going back to the "beginning" and re-examining the other requirements, the analysis, the design/architecture, the development/construction, the testing and the impact is necessarily large for all but the most trivial changes.
Agile methods turn this on it's head. By allowing (nay, building in!) change every iteration, every cycle, the team and the organization start to get good at accommodating change. The value of this effect cannot be over-estimated; getting good at doing change is a natural consequence of accepting change all the time in a structured manner, and in fact, leads to all the other four benefits: increased learning, increased ROI, increased stakeholder satisfaction, and increased control. The cost of change stabilizes over time instead of increasing exponentially!
Agile and Chaos - The Illusion of Changability
Unfortunately, I am not aware of any studies that target chaotic (non-process) environments to see what kind of results they have in delivering results. (If anyone is aware of such studies, please let me know in the comments!) That said, I think almost everyone has had some experience in environments where the winds of change were so severe and fickle, and the structures to support working with change were non-existent, that chaos reigned. These environments are almost completely negative: things don't get done in a timely manner nor with an acceptable level of quality.
Often the reason for this lack of structure is about flexibility, needing to work in an environment which is also extremely chaotic. Sometimes its worse though: management or stakeholders are the cause of chaos without understanding the consequences of their actions.
Agile methods put a sufficient structure in place to build some discipline, and still remain adaptable. This sufficient structure is often built by gradual application of various agile practices until there is "just enough". This process does require dedication and will, but because it is gradual, it is often much easier than trying to suddenly put in place a full-scale disciplined process.
As these practices are implemented, the team and organization gradually become better and better at accommodating change.
Agile Benefits: Rapid Learning
Agile Benefits: Early Return on Investment
Agile Benefits: Satisfied Stakeholders
Agile Benefits: Increased Control
Agile Benefits: Responsiveness to Change
Agile Benefits: Summary Article
Posted by Mishkin Berteig at 07:35 AM | |
September 20, 2007
Agile Benefits: Increased Control
One of the reasons that agile provides stakeholder satisfaction is because of increased control. This increased control is a benefit in its own right. The word "control" must be used carefully... some agile approaches and practitioners are justly wary of the word and its common uses. This particular benefit of agile is often a little surprising to people how have believed the myths around agile that it is a chaotic-anything-goes type method. Let's look at how an agile approach provides more control.
Increased Control
The person responsible for prioritizing the work (the Product Owner, Queue Master, Product Manager) is the locus of business control in an agile environment. This person exercises this control in a number of ways. First and foremost is through the constantly evolving queue of features or results to be delivered by the agile team. Here the Queue Master has final authority based on influence, knowledge, experience and formal appointment. The Queue Master can control the immediate and long-term work of the team through the use of this prioritized, never-frozen list of work. Every iteration, the team will accept the highest priority items according to their capacity (or velocity) and complete those. This fine-grained direction of the team is impossible in a traditional phase-based approach to working where often the "change control" process is a bureaucratic nightmare whose end result is the team preventing the business from getting what it needs.
Clearly there is more control. At what cost? Well, the previous three benefits of agile mentioned indicate that there is no financial cost (in fact there is a benefit), there is no intellectual cost (again there is a benefit), and there is no decrease in satisfaction (yet again, there is a benefit). So what is the cost? There is, unfortunately, one very deep and difficult cost: the team doing the work loses control over deciding what is valuable (cost-benefit). I know that in many IT organizations, this is a terrible political cost to pay for IT management and it is a terrible "status" cost to pay for technical folks.
Fortunately, even these losses are offset by other aspects of the agile process and its benefits... again, around the question of control.
In exchange for taking complete control over value determination, the Queue Master must grant complete control over solution discovery and implementation to the team. Of course, ideally there is close collaboration. However, if there is disagreement, this is the standard dividing line of responsibility in an agile environment. So now, to the benefit of those doing the work, they are given complete control over how to do the work and this can be an incredible benefit: it allows the full run of creativity and problem-solving skills to come into play.
Agile Benefits: Rapid Learning
Agile Benefits: Early Return on Investment
Agile Benefits: Satisfied Stakeholders
Agile Benefits: Increased Control
Agile Benefits: Responsiveness to Change
Agile Benefits: Summary Article
Posted by Mishkin Berteig at 09:17 PM | |
September 17, 2007
Agile Benefits: Satisfied Stakeholders
So far, we've discussed learning and value as benefits of agile. Now we turn to a more human side: satisfied stakeholders. Agile methods provide multiple roads to satisfaction for customers, users, business people, bureaucrats (okay, maybe not _all_ bureaucrats), team members, managers, shareholders, and interested passer-by. There are three primary mechanisms by which this occurs: engagement, trust-building and feedback-control. [UPDATED: added link to explanation of Commitment Velocity]
Satisfied Stakeholders
There are so many different stakeholders for any given project or work effort, it is impossible to make generalizations that apply to them all. This is one reason why methods such as Scrum do not define any roles for the stakeholders. Nevertheless, as a concept, stakeholders are important people to consider when thinking about an agile approach to working. How is this method going to improve the satisfaction of our stakeholders?
Engagement
Some stakeholders are satisfied simply to be involved, to know what's going on, to be part of something that is progressing. They have no need for specific results or specific contributions. Rather, these stakeholders might be looking to learn, trying to increase their influence, or simply curious about the work being done.
Agile methods provide improved engagement for these stakeholders using two simple mechanisms: visibility and frequency of delivery. Visibility comes in that anyone is welcome to come to the demos, to walk through the team room, to examine the burndown charts or task boards, or simply to ask questions of the team members. Frequency of delivery through short iterations gives a stakeholder the opportunity to see progress (or change) on a regular basis. This visible change satisfies engagement simply because of the potential it represents: hope for the future, opportunity to influence.
Trust-Building
Another set of stakeholders are more concerned about results. And not just any results, but reliable, predictable results. Results that you can depend upon. Agile methods are ideally suited to help these stakeholders. The visibility, capacity measurement and commitment aspects of agile methods all help these stakeholders come to understand, rely-upon and ultimately trust the work of the team and the organization.
Here there is a substantial pitfall. There are a few agile practices that _must_ be put in place and followed rigorously in order to develop this trust. First, the team must keep a consistent time box for both duration and effort of work. Every iteration or Sprint must be the same amount of work time. Secondly, the team must use estimation and tracking of tasks that is compatible with "commitment velocity". Thirdly, the team must use iterations short enough that these stakeholders don't get frustrated waiting for the commitment velocity to stabilize. Fourth, the team must get it's work up to a level of quality where defects are rare rather than expected. Finally, the team must be protected from interruptions. Don't forget: two hours can waste two weeks!
All this is not easy, and doesn't happen quickly. Trust is a deep and important quality for both people and organizations so it is worth the investment.
Feedback-Control
Then there are the contributors. The people who, for various reasons, some legitimate, need to make their mark on the work. This group should include the team members themselves! These stakeholders are interested in providing input into the process, seeing the results of that input, and then being able to have another chance based on those results. Business people want to see the results of their work in the marketplace and use those results to get better. Users of software, consumers of media want to have a say in what the next version looks like. This is the level of active engagement.
Agile methods provide opportunities for active engagement, for feedback and control, through the backlog or queue of work, through the demos, through participation in the team's discussion about the work, and through the visibility of seeing their contributions take effect in "real time".
Now control is obtained through the specific rules of engagement in one's particular agile method. In Scrum, this is through the role of the Product Owner and the Product Backlog, the daily Scrum, etc. Each agile method has a defined set of practices and guidelines about how ideas, suggestions and criticisms are handled. Fortunately, those mechanisms are oriented around visibility, adaptability and speed so that frustrating delays in seeing results are rare.
Other Satisfactions
In some methods, team members are ignored or downplayed as stakeholders. In many agile methods, the importance of the team's well-being is given high priority. Agile methods reduce micro-management, reduce command-and-control management, reduce shoddy workmanship. Agile methods increase the need for creativity and problem-solving, the level of responsibility, support an honest working environment, increase the chances of delivering something that will actually be useful (and used), increase the challenge without causing "death marches". All that said, agile methods are not for everyone!
Agile Benefits: Rapid Learning
Agile Benefits: Early Return on Investment
Agile Benefits: Satisfied Stakeholders
Agile Benefits: Increased Control
Agile Benefits: Responsiveness to Change
Agile Benefits: Summary Article
Posted by Mishkin Berteig at 11:12 PM | |
September 11, 2007
Agile Benefits: Early Return on Investment
We wouldn't do agile if we didn't think it was better in some way. More and more, I am seeing the adoption of agile methods being driven by business management (rather then engineering). There is a clear reason for this: agile methods offer the possibility of early return on investment compared to other methods of working. This benefit is only one of five essential benefits of agile, but it is one of the most practical and easiest to measure. Therefore it is important to clearly understand how agile methods can deliver this benefit... and how they can fail to do so!
Early Return on Investment
The basic process structure of agile methods consists of the short cycles (iterations, Sprints) of delivery of valuable results. The key word there (aside from "short") is "Valuable". Now in software, "valuable" is relatively easy to define. One definition that works nicely is "Running Tested Features". In other industries or types of work, valuable is defined in some other way.
An agile process delivers valuable results every single iteration. This provides the basis of early return on investment. The organization can then take those results and start to realize their benefits immediately after the very first iteration... ideally... (which we will come back to in a moment).
Here's a graphical contrast between a traditional waterfall approach versus an agile approach that maps value delivered vs. time.
The waterfall project delivers all its value at the end - the red spike. An agile project starts delivering value very early on, increases to a maximum rate of value delivery and then gradually tapers off. The reason for the shape is simple: at the start of the project there is often a fair amount of uncertainty, and some dead-ends are pursued before getting to the really valuable work, and then as that work is completed, the team starts working on lower and lower priority features.
The early delivery of value has an additional benefit. By delivering value early, the time value of that investment is increased. Revenue or cost savings can be realized sooner and therefore more funds are feed up for other investment.
Sounds great, what's the catch?
Agile Pitfall: Not Getting Done
This benefit being realized rests completely on the assumption that the work delivered at the end of each iteration is actually valuable. If for some reason it's not, then this benefit falls apart completely. Most organizations when starting with agile, cannot realize this value immediately because their teams do not deliver completed valuable results. Rather, most organizations are set up so that a team delivers an intermediate result which is useless on its own. Realizing this benefit of agile methods often requires substantial, strenuous, disciplined change in the way that people work, teams are set up, bureaucracy functions, and management supports it all. Perfecting agile is sometimes a lengthy process. Fortunately, the other benefits of agile do not depend so heavily on this assumption.
Agile Benefits: Rapid Learning
Agile Benefits: Early Return on Investment
Agile Benefits: Satisfied Stakeholders
Agile Benefits: Increased Control
Agile Benefits: Responsiveness to Change
Agile Benefits: Summary Article
Posted by Mishkin Berteig at 03:08 PM | |
September 10, 2007
Agile Benefits: Rapid Learning
So what exactly are the benefits of agile? Why are people, teams and organizations so interested in agile processes? What about agile caused it to become a popular and rapidly growing approach to working? I have seen five essential benefits that come from implementing an agile methodology. Here I describe what I think of as the most important benefit of agile: rapid learning.
Rapid Learning
Ken Schwaber tells an anecdote about Scrum:
I was talking with the CIO of a large organization. He complained to me that he would run projects that would take 12 to 18 months and at the end of the project he would get something that he didn't actually want. I told him that I can deliver what he doesn't want in one month.
This is one of the clearest advantages of an agile approach: rapid deliver helps you learn what you truly want and need because you can see actual results instead of "intermediate" results. If you are building software, you can see a working system and get real concrete feedback about it. Users, consumers, and other stakeholders can participate more effectively in determining what you are building.
That's learning about the product... but agile methods also allow you to learn about the process used to build the product. Every time a team of people goes through an iteration of work, they learn how to do that work more effectively, more efficiently. At the end of each iteration there is an opportunity to change the style of work.
Learning about product and learning about process are both accelerated by an agile approach. The shorter your cycles (iterations, Sprints), the faster and more effective your learning.
Unfortunately, the catalyst for learning tends to be crisis or "failure". As Ken's anecdote describes, the first iterations will almost certainly deliver incorrect or poor results. Not only that, but the compressed time cycle is challenging for those not used to it. The crisis comes out in many different ways, and being aware of this feature of agile methods is critical to gaining the benefit of rapid learning.
Agile Benefits: Rapid Learning
Agile Benefits: Early Return on Investment
Agile Benefits: Satisfied Stakeholders
Agile Benefits: Increased Control
Agile Benefits: Responsiveness to Change
Agile Benefits: Summary Article
Posted by Mishkin Berteig at 09:54 AM | |
February 22, 2007
Strategic Plan
Okay, this is only marginally related to agile, but I thought it was interesting nevertheless: How to Write a Detailed Strategic Plan. The main connection to Agile Work, is that you need to have a clear performance goal in mind towards which you are working. This may be a great way to clarify your thoughts about such a goal.
Posted by Mishkin Berteig at 11:43 AM | |
January 27, 2007
The Freedom of Limited Capacity
Something that I would have thought impossible has happened. By understanding how incredibly limited my capacity to do work is, I am getting a greater and greater sense of freedom and contentment.
My "experiement" to run my business using Agile Work practices is starting to bear some fruit. The trouble is, that so far, that fruit is simple better knowledge of my extremely limited capacity to get things done during a single week-long iteration. I can do 3 or 4 items from my Work Queue which works out to about 15 or 20 tasks. This seems ridiculous to me! Surely one hard-working guy can get more than that done!
But I can't. I'm getting to the end of my fourth iteration and it's the same thing again!
I know some of the reasons for this: interruptions, unexpected work, unremembered work, and my general nature of being easily distracted by shiny things!
In some ways this has been quite frustrating. I have a huge queue of work I want to get done for my business. But the other side of the coin, the one that looks different than I expected, is that knowing just how limited my capacity is... is liberating! I don't feel nearly as stressed as I did four weeks ago. I have the courage to commit at an appropriate level. I can start to believe my plans. I can see - realistically - just how much I need help to achieve my goals. I can see how soon I will be able to do cost/benefit analysis on hiring vs. doing the work myself (can't do that yet). I can even start to believe that I might be able to reach my original goal of reducing my working hours from 80+/week to 50 or less... as long as I make sure that my Work Queue is properly prioritized with that goal in mind.
I have worked with a number of teams that have gotten to this point of certainty about their capacity. I've seen this happen in others... and now I recognize it for what it is: relief. One team I worked with after only two iterations had a very clear idea of their capacity, and you could feel the comfort level of everyone with this new agile thing skyrocket. Another team I worked with got a clear sense of its capacity after only three iterations. This team settled in and then started to work to increase their capacity and did a fabulous job by using automation tools, eliminating various organizational bottlenecks, etc. They wow'ed the rest of the organization with their incredible, consistent delivery of value. One of my former students, Dmitri Zimine, gave a presentation at the XPToronto group where he talked about the incredible level of trust that developed between his team and the rest of the organization after consistently, iteration after iteration after iteration meeting their commitments.
All of this is only possible by a rigorous application of timeboxing, careful and consistent task breakdown, and good, honest tracking of results. I wrote a previous article called Seventeen Tips for Iteration Planning. Look it over and see what new ideas you can apply in your situation. If you are frustrated by a team continually over-committing, you will find a lot of valuable advice there.
As a parting shot: consider how you feel right now. Are you stressed out? Over committed? Failing to meet your commitments? Feeling guilty? Working insane hours? Not spending enough time with your family? Killing yourself!?
What about the team or organization you work in? Is it constantly being bombarded by problems it can't handle? Surviving on pure heroics?
I can't tell you that following a careful iterative planning approach will fix your problems... but I can tell you that it will reduce your stress levels, help you (or your organization) make appropriate commitments, and let you see the reality of your situation (good or bad).
Posted by Mishkin Berteig at 03:07 AM | |
January 22, 2007
Cancelled Iteration
Last week went totally wonko for Berteig Consulting. My planning was bad, bad, bad!
For planning, I totally forgot about three very important scheduling things:
- a ScrumMaster certification course on Thursday and Friday which required not just time in class, but also three hours of commuting each day.
- my birthday for which I had planned a very informal party on Saturday (normally a very productive work day) which consumed the whole day from morning to late at night.
- the departure of my brother Alexei and his wife Ma Jin so that Sunday would be my last day of visiting, again, taking up my whole day from morning to late at night.
Suffice it to say, a 3-day work week was not what I was expecting when I did my planning. Sometime on Thursday I gave up.
I decided to delay starting a new iteration until I could recover a bit. Over the course of four days I get nearly 200 emails that I actually need to pay attention to at some level or another. So, today has been a recovery day and at the end of the day I will plan my next iteration. Since I did not have a delivery meeting (since I cancelled the iteration), I can only do an informal review of the accomplishments:
- some progress on development work for my client
- some progress on invoicing my client
- some progress on automation of my course listings (Selenium is great!)
- no progress on providing a statement to my other client
The causes of this massive failure are obvious. It should be noted that by doing the ScrumMaster training, I did actually deliver value to Berteig Consulting... it just wasn't the value that I had planned!
Posted by Mishkin Berteig at 05:58 PM | |
January 15, 2007
End of Iteration 2 ("Capacity") and Start of Iteration 3 ("Automation")
This second iteration when much better than the first. I committed to an amount of work that was much closer to my real capacity, and I stayed more focused on that work. Here are the results of my demo, retrospective and planning for Iteration 3 which I am calling "Automation" for reasons which will be described below.
Demo
I committed to the following items from my Work Queue:
- 1 day intermediate team course
- phone consult details
- QA/tools coaching
- email proposal
- get template from them
- collect hours
- collect receipts
- image receipts
- currency convert receipts if needed
- type up hours
- type up receipts
- email/submit
- 4 hour task
- 4 hour task
- 4 hour task
- 4 hour task
- 4 hour task
- 4 hour task
- 4 hour task
- 4 hour task
- ping Contact1 "V"
- ping Contact2 "N"
- ping Contact3 "M"
- ping Contact4 "S"
- ping Contact5 "V"
- air reservations
- prepare visa application
- submit visa application
- hotel reservations
- equipment
- invoice 1
- invoice 2
I also added these in the middle of the iteration (which is really a "no-no", but I did it anyway to my regret).
- change individual entry archive template
- remove technorati links from 6 articles
- rebuild site
- work with Alexei on structure
- incorporate Alexeis feedback on writing
- work with Alexei on layout and design
What did I actually get done? Here are the stats:
For Iteration 002 - "Capacity":
# Work Queue Items At Start: 5
# Work Queue Items Completed: 3
# Tasks at Start: 32
# Tasks Remaining: 17
What is scary is that my velocity is exactly the same in terms of number of tasks: I really need to start my iterations with only 15 tasks.
Anyway, what I need to do for my next iteration is schedule my "demo" with my other stakeholder (my wife Melanie). Demo'ing to myself in the wee hours of the morning is not really practical in terms of my overall goal for this project (running my business at a sustainable pace).
Retrospective
Here are the things that went well:
- Came much closer to getting everything done that was in my iteration. This was great - I continued to use Tiddly Wiki to track my Work Queue and Tasks.
- Felt less stress. Although I still worked very hard, I was not worried nearly as much about the things still on my Work Queue that weren't in this iteration. I also decided on certain boundaries to work: generally work 4 to 6 hours during the day and another few hours after lights out (usually after 11pm).
- The prioritization worked well - didn't feel impelled to do too much that was _not_ in the iteration. Althought I did take a couple more items in, it was more because of opportunity than anything else. My brother Alexei wanted to help me with my book (for example). Next time around, perhaps I should be more explicit about negotiating with myself about taking something out of the iteration if I bring something in.
Here are the things that need improvment:
- Get even better at judging capacity and committing to an appropriate amount of work. The numbers speak loudly! This next iteration I have to limit myself to 3 items from the Work Queue and about 15 tasks. I have to remind myself that I can always bring more work in if I complete my work early and I still have time.
- Care with long term scheduling - made a mistake in my scheduling with a Client - hopefully it will be okay! This is a bit of a nit, but I need to keep my daybook up-to-date even with long-term stuff.
- Spending time with my family - e.g. playing with kids, helping around house, assisting with homeschooling. This was better than I was doing in Dec., but I need to continue to improve here. I would really like to work with Justice and Haifa on learning Chinese. We've got tons of materials to do it, just need the discipline to get through it together.
Planning
Okay, maybe I'm a glutton for punishment, but I've decided on four items from my Work Queue:
Client2 Invoice
Client2 Work
Automate Listing of Scheduled Courses on 3 Sites
Client3 Statement of Account
The key one is the automation since that will be an investment to save me time later on. In my task breakdown it looks like this (tasks with an "x" are already done from the previous iteration):
x- get template from them
x- collect hours
- determine expense policy
- invoice R0001-001:
-- collect receipts
-- image receipts
-- currency convert receipts if needed
x-- type up hours
- invoice R0001-002:
-- type up hours
- invoice R0001-003:
-- type up hours
- email/submit
- 4 hours
- 4 hours
- 4 hours
- 4 hours
- 4 hours
- 4 hours
- ScrumAlliance
- Google Base
- Berteig Consulting
- laptop
- Visa
- old Visa
So, that's 4 items from the Work Queue and 17 tasks (the ones with "--" in front of them are sub-tasks... not sure how to handle those, but for now I'm not counting them separately.
I'm really excited about this. It sucks to see that I get so little done in a single week, but on the other hand, knowing my capacity allows me to understand just how much work I have on my plate and how badly I need two things: automation and assistance! I'm going to start with automation, but I'm also looking for assistance. The trouble is that I can't affort to hire someone on a salary... (if you know anyone who would be interested in working on commission/revenue-sharing basis, I would love to talk!).
One final note: I did manage to include my wife Melanie in my planning for this iteration. She seemed pleased :-)
Posted by Mishkin Berteig at 03:09 PM | |
January 08, 2007
Planning Iteration 0002 "Capacity"
I've completed my iteration planning for my second iteration. As a reminder, I'm doing this because I want to be working only 50 hours per week by July 2007. My sole improvement item from last iteration was to use get better at committing to an amount of work within my capacity. Here's what I have planned:
I have included my complete list of work to be done broken down into tasks. It is anonymized:
Client1 Proposal Writing
- 1 day intermediate team course
- phone consult details
- QA/tools coaching
- email proposal
Client2 Invoice
- get template from them
- collect hours
- collect receipts
- image receipts
- currency convert receipts if needed
- type up hours
- type up receipts
- email/submit
Client2 work
- 4 hour task
- 4 hour task
- 4 hour task
- 4 hour task
- 4 hour task
- 4 hour task
- 4 hour task
- 4 hour task
India Training
- ping Contact1 "V"
- ping Contact2 "N"
- ping Contact3 "M"
- ping Contact4 "S"
- ping Contact5 "V"
- air reservations
- prepare visa application
- submit visa application
- hotel reservations
Client3 Statement of Account
- equipment
- invoice 1
- invoice 2
As you can see, I have committed to only five items off the Work Queue for this iteration and they add up to thirty-two tasks. This is more than I indicated last night in my retrospective results. I'm nervous about this in two ways. One, I think that I am under-committing and that I'll get into huge trouble if I don't do more than this. Two, I think that I'm over-committing and that with my brother visiting, even doing this much smaller amount of work will be challenging. Still, I have tried to make both the items from the Work Queue and the tasks smaller than in my previous iteration. I guess I'll see in a week!
Posted by Mishkin Berteig at 11:01 AM | |
First Interation Ending
My first iteration using Agile Work for my business development has come to a close. Here is what I did for a "demo" and retrospective.
Demo
This was simple. I looked at my selected Work Queue items and my tasks and check to see what I had accomplished (finished or partially finished). Here are the statistics (grim and discouraging as they are):
For Iteration 001 - "Beginnings":
# Work Queue Items At Start: 11
# Work Queue Items Completed: 2
# Tasks at Start: 43
# Tasks Remaining: 28
From these numbers, for my next iteration I should probably be hesitant about committing to any more than 2 items from the Work Queue and any more than 15 tasks.
Considering how many work hours I have in a week, 43 tasks is absolutely ridiculous... unless they are really small, which many of them weren't. For example, I had one task as "Integrate part one of Alexei's feedback into my eBook" which when I did it actually took about three hours. Its just one sample, but 3 x 43 is 129 hours and is just not possible for a single human being in 7 days.
Aside from the value-oriented items from the Work Queue, I also did the work to finish a more complete Work Queue. It now has 37 items including those which remain un-finished from this first iteration. It is poorly prioritized, but that will improve over time. As well, I suspect there are quite a few things missing that I forgetting. I should probably get my wife, Melanie, to look over it and make some suggestions. I also have some old "to do" lists for my business which might remind me of some things to add onto it near the bottom.
Retrospective
I did a little mini-retrospective to find the three things that went well this iteration, and the three things that need improvement. I also decided on a clear action item to take to try to improve my next iteration. (Another clear reason to use Card Meeting - worked great for my retrospective :-) .)
Three Things that Went Well:
- Referred to my iteration tasks frequently. I kept my TiddlyWiki up in my browser and checked it several times a day.
- Spent time with my family and friends despite huge workload. We had guests and family visiting and I got some good time in with them. I also spent a good amount of time with Melanie and my kids. I had to make a conscious effort to do this, but since this is the goal of my using Agile Work (to have a good life/work balance), I figured I might as well start making some progress on it right away!
- Had courage to do some development work which required changes to other developers' work. I ran into a problem with some of the work I am doing as a contract. I dug around and realized that any fix I made would be felt by other parts of the codebase as API's changed. I made the fix and then tracked down the dependencies and fixed everything up. Fun!
Three Things that Need Improvement:
- Pay more attention to my schedule / calendar so as to reduce problems with work/family boundaries. Still a loooooong way to go on this one!
- Spend more work time "on-task", rather than on things not on my list. I ended up doing a bunch of work stuff that wasn't in my iteration plan. Partly I did it because I got bored of what I had planned, and partly becuase I forgot to focus on my plans. It would probably help if I had a Process Facilitator breathing down my neck :-)
- Make realistic plans given my capacity for work. This is the biggie! It is going to be very hard for me to keep to a small commitment. But considering the my brother is visiting from Beijing with his wife this week and next, I really have to try to get this right.
It is that last point that I will use as the basis for my next improvement. For my next iteration planning meeting (to be held in the morning after a far-to-brief sleep), I will commit to a maximum of 3 items from the Work Queue. This may mean breaking the items down into smaller bits. I'll talk with the Queue Master (myself) tomorrow morning about it :-)
Posted by Mishkin Berteig at 04:37 AM | |
January 03, 2007
My First Challenge
Wednesday is nearly done and I'm looking at my list of tasks and cringing! I've only done a few out of the forty for this week. What's going on?!
Well, for one thing, I'm over-committed, and I know it. This is why my goal is to eventually time-box my effort to 50 hours per week. As it is, I expect I'll have a few more short nights this week in order to get even a reasonable amount of my commitment done.
Also, I've been cherry-picking. I'm doing the easy/nice/comfortable tasks first. I'm avoiding the paperwork tasks. I'm avoiding the administrative tasks. These are the ones that I hate and I always procrastinate about. (Hmm... writing this is actually procrastination too... just a few more words and then I'll get back to work.)
Finally, I've got some obstacles which I'm not sure I will overcome this iteration. First of all, I'm spending less time on work than I anticipated. Secondly, I'm getting distracted by tasks that are not directly related to my work items, but which seem to be pre-conditions. For example, I need to do a bunch of administrative follow-up for recent courses I have delivered. Part of that is to send of images of the attendees license forms. I've got the images on the SD card in my digital camera. I've also got a lot of other images on there. So, instead of focusing purely on the task at hand, I am actually cleaning up the whole card. Which is getting rid of technical/administrative debt, but it is slowing me down. Hmm... "administrative debt"... that's gotta be a common theme for the procrastinator!
Anyone out there want to write an article for Agile Advice about administrative debt?
Posted by Mishkin Berteig at 05:16 PM | |
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 | |
My First Iteration Planning
I've done my iteration planning for my first iteration called "Beginnings". The length of my iterations is one week (including weekends). Here is the list of backlog items that I have committed to (some detail removed):
Catch up on Scrum course follow-up work
Advertize future courses
Finish eBook 2nd Draft
- email request for feedback return
- go through feedback
- finish references
- finish diagrams
Invoice
Finalize India Trip
Interview
Meet up with
Continue development work for
I have broken all of these into tasks, but only put here the ones for finishing my eBook since the rest get into lots of private detail.
I'm currently using TiddlyWiki to track my Work Queue, my tasks and my recurring/scheduled duties. I create a new wikiword for each iteration and copy items from the Work Queue into that section. I also have a menu that has links to my daily, weekly and monthly tasks.
I'm not doing any estimation on either Work Queue items or tasks. This may become a problem, but for now I'm going to try doing the work without the estimation overhead.
I also spoke with my wife, Melanie who is my business partner about all this. She agrees that using Agile Work is a good step to take and looks forward to all the benefits of my being more organized :-)
Posted by Mishkin Berteig at 12:05 PM | |
November 15, 2006
The Case for Context Switching
Recently, Dimitri Zimine wrote an excellent little story about context switching. Joel Spolsky writes in "From the 'You Call this Agile' Department":
Dmitri is only looking at one side of the cost/benefit equation. He's laid out a very convincing argument why Sarah should not interrupt her carefully planned two week iteration, but he hasn't even mentioned arguments for the other side: the important sale that will be lost.
Okay... I'll bite.
Let's look at that argument from the perspective of the sales person first since that is where Joel's concern starts:
The Sales Guy Perspective
"I need the 'ezhibal' feature now! Big bucks coming soon if we can get it now."
Let's suppose that this urgent email has come in somewhere near the start of our two week iteration. The normal response to this in Scrum is to push back a little. The ScrumMaster says something to the effect of: "Look if you wait 7 days we can put this on the top of the list for our next iteration."
First reaction, and it's a normal one, is for Sales Guy to freak out. I've actually heard people saying things like "You're going to lose your job over this! I'm getting the VP involved and he's not going to like it" and then they stalk off to find the big dog to come and bark at us. Anyway, let's pretend that the Sales Guy is willing to be reasonable and not instantly escalate the "problem". So what he actually says is: "Look, this is super important, it'll probably only take a few minutes for us to talk about it and then we can figure out how long it will take to fix. Let's just do a quick phone call and yadda, yadda, yadda, blah dee blah..."
Enough of the Sales Guy perspective.
Nowadays, if I'm in this situation, I do a value assessement. I tell the team to keep working on their plan, nothing's changed yet, and I sit down with Sales Guy and the person who's sponsoring the current work and we start a discussion about the options of which there are really only two that work in Scrum:
- Stay the Course
- Cancel the Iteration
First, let's talk about how we decide which option to take. Then we'll talk about why.
Deciding on the option is easy. You look at the value of the work currently being done and compare it to the value of the work that Sales Guy needs. You take into account probabilities. If Sales Guy doesn't have a signed contract, then it's hard to day if there's going to be any real revenue from the 'ezhibal' feature. Still, you might be able to do an assessment of the probabilities based on your level of trust and history with the client, etc. You also need to take into account the time value of money. Does delaying the current work have consequences for another client or stakeholder? What is the cost of those consequences.
This is a relatively simple cost/benefit analysis and comparison. If you're not comfortable with money and numbers and spreadsheets, you better get comfortable!
Okay, so we have a way of comparing the two bits of work. Now let's look at the two "allowed" responses and a third "bad" response.
Stay the Course
Turns out that the potential benefit of the stuff Sales Guy wants is not quite as high as the potential benefit of the stuff that Suzie Stakeholder prioritized for the current iteration. Well, that's easy. Put the request from Sales Guy in our prioritized list of work and get to it when there is an appropriate level of benefit relative to the other work.
Cancel the Iteration
The stuff Sales Guy wants is super-valuable. So let's get the whole team to stop what they are doing and everyone supports this very valuble work. Stopping the whole team is appropriate because obvioulsy, the stuff they're working on isn't as valuable. Oh, and because we treat a team as a unit in Scrum. And because the team needs to commit to work, not individuals. This isn't so obvious... more later.
Peel Sarah off to do the 'ezhibal' Feature
This is what normally happens, and in a "normal" non-agile environment, it's probably okay. In a non-agile environment, Sarah hasn't made any commitments (she's been forced to agree to dates and scope, etc., but she hasn't made a commitment that she is empowered to live up to). So if she goes off and does this one little thing, it probably will be just business as usual. In an agile environment, the team has made a commitment and doing this work this way invalidates the team's commitment.
Why do we do it this way? The main reason is around trust and commitment. Yup, it's that soft icky stuff that we're so incredibly bad at that customers think that bugs are normal, that management shoves the kitchen sink into projects in the frustrated hope that they'll get something out of the IT team at the end of the project. Sound familiar to anyone?
Anyway. An iteration is a commitment. It is a firm and solid commitment. The team as a group of smart and honorable people is making a definite commitment to the rest of the organization to get a certain amount of work done in a fixed amount of time. In return, management is agreeing to give the team every support in reaching this commitment. When a team is new at this, they might get it wrong. But having done this with dozens of teams now, I know that after a few tries, the team gets the hang of it and commits to appropriate amounts of work, and management provides appropriate levels of support.
This commitment is essential for developing trust. And anything that comes in the way of the team meeting its commitment is considered "BAD". An obstacle to do away with.
This is interesting, because Joel's second example is about defects. And I strongly agree that defects are "BAD" and need to be dealt with at a very high level of priority. The reason is simple: they prevent a team from meeting its commitment.
One team I was coaching was constantly bombarded by these types of it'll-just-take-a-few-minutes-need-it-asap requests. They had many stakeholders and very very limited resources to service these requests. They had several small projects that were taking literally years to do because they couldn't get enough concentrated time on any one thing. This was considered normal and good in their environment.
The trouble is, no one had really looked at the overall consequences. Everyone was doing local optimization. For us geeks, we all know that local optimization is something to be avoided if possible. We climb a peak only to discover that we have to climb back down a ways to get up to the higher peak we now see is next to this one. We climb up that one only to discover yet another higher peak even further along thus requiring us to climb down and up again... When really what we should have done is stepped back a ways, looked at the lay of the land and said, "hey, that peak over there is the highest of them all, let's go climb that one."
Scrum helps us avoid local optimization by forcing all feature requests for a team to be prioritized in a list of work, and by allowing the team to complete small pieces of work so it actually gets _something_ done that you can learn from.
Joel said:
Agile is not supposed to be about swapping out one set of bureaucratic, rigid procedures for another equally rigid set of procedures that still doesn't take customer's needs into account.
True enough! But it also demonstrates a serious lack of understanding about what is being done in Dmitri's example! First of all, without being agile at all, it is possible to switch from 18 month projects to two week projects. Both can be bureaucratic as you please (well, actually, there's only so much bureaucracy you can cram into two weeks and still get something done). The shorter projects will allow you to be much more responsive to customer needs... by definition!
So what happens when you add in all the other things that agile really is about? Transparency. Truthfulness. Creativity. Learning. Meta-Learning. Prioritization. Self-Organizating Teams. Eliminating Waste.
Well, first of what you get is something that's damn hard to do right. It goes against almost everything we've been taught to do: the extreme of heroics of the extreme of careful planning and process.
Secondly, what you get is something that needs safety zones and meta-rules. Like mutual, freely-given, team-to-stakeholders commitment. Like assuming positive intent.
And thirdly, what you get is an environment where not only is the business getting what it needs more than it used to, but also, the team likes working with the business, and the business likes working with the team.
I admit that the point Joel is making isn't too different. Yes: look at the costs and the benefits. But agile isn't quite about instantaneous responsiveness. That's a red herring and I'm suprised that Joel threw it's stinky carcass into the discussion. Agile is also about balancing that responsiveness with the overall view of value for the team and the organization. The tool for doing that is the prioritized list of work, not the email message from Sales Guy to Sarah.
Posted by Mishkin Berteig at 04: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 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 | |
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 | |
June 30, 2006
Agile Project Engagement Roadmap
(Parts of this posting were adapted from an email written by my business partner, Dale Kiefling)
We recently had the disconcerting experience of having a client cancel our engagement because they'd felt that we weren't being agile enough. In hindsight there were a number of reasons why this might have happened but I think the most important one was simply that we did not provide a clear overview of the engagement. This meant that the client was confused about the value of what we were doing. I myself am confused about how the situation arose. I thought we had been very clear but obviously that was not the case.
In our practice we typically combine a discovery phase and a prototyping analysis and design phase. What some people in the agile world might call iteration zero. For our client this discovery seemed open ended and they didn't have a clear understanding of how it fit into the project as a whole. This was a communication failure on our part. The process of discovery can indeed feel open-ended as it is the very nature of discovery to explore the domain of the business opportunity in an open way. The purpose of this "openness" is to find the appropriate scope, workflow, practical boundaries, and hidden benefits in an exploratory and visual manner.
The primary advantage of doing this work at a high level early on in the process is that it is much easier and cost-effective to identify boundaries and priorities on a whiteboard rather than during the construction phase or even during prototyping. We should have done a better job explaining this prior to our first discovering meeting which might have helped our client better understand our process and purpose. We also never really established a timeline beyond having one or more discovery meetings which may have added to their confusion.
Let's chalk this up to another lesson on the importance of managing client expectations.
Posted by David Chilcott at 01:16 PM | |
June 02, 2006
Cueing Agility - Creating a Supportive Environment for Agile Teams
In Blink : The Power of Thinking Without Thinking
In one experiement, researcher John Bargh designed a scenario to test how sensitive we are to written cues that are structured in a way that we are not consciously aware of being cued. Bargh created two lists, each composed of five words per list item. Of the five words, four were chosen to form a sentance, and the fifth word was selected so that it would not fit with the other four. Then the five words were jumbled.
For example:
rang phone peace the loudly
The people who came as subjects of the experiement were given one of the two lists and told to go through their list as quickly as possible and un-jumble the sentances.
Unbeknownst to the participants in the experiment, each group of five words also contained a word that was selected to suggest a feeling or attitude. In the first list, each group of five words contained one word that would suggest impatience, rudeness and aggressiveness. The second list contained words to suggest patience, politeness and calm.
All the subjects of the experiment were also given additional instructions to come to a particular office once they had completed their lists. At the office they were to receive final instructions. At the office, each participant encountered the experiment administrator deep in conversation with another person. Neither the administrator nor the other person acknowledged the just-arrived subject. Now the real purpose of the experiment was tested: how long would the subjects wait before interrupting the ongoing conversation?
The results were astonishing: those people who were cued with the list containing words suggesting impatience, rudeness and aggressiveness
eventually interrupted - on average after about five minutes. But of the people primed to be polite, the overwhelming majority - 82 percent - never interrupted at all. If the experiment hadn't ended after ten minutes, who knows how long they would have stood in the hallway, a polite and patient smile on their faces? (p 55)
Gladwell gives several more similar examples in his book. I strongly recommend reading this book to see just how powerful this cueing or priming effect can be.
For organizations, teams and even individuals, this effect can be harnessed. The most obvious ways include using posters, screen savers, banners etc. to constantly impress people with positive messages about teamwork, effectiveness, creativity and other values and qualities that might be deemed valuable. This should obviously go hand-in-hand with a conscientious removal of all negative messages.
For agile teams, there are some particular values that should be emphasized: truthfulness, courage, creativity, teamwork, trust, cooperation, hard work, learning, adaptability.
The message can also be communicated in more subtle ways - and this is actually likely to be more effective! Incentives, the power of exemplary behavior, and the physical environment itself all can contribute strongly. In Built to Last : Successful Habits of Visionary Companies
(p 122)
- Fervently held ideology...
- Indoctrination
- Tightness of fit [for employees]
- Elitism
Interestingly, agile methods do tend to require "buy-in". In order to fully feel comfortable in an agile environment, people need to understand and fully accept a small number of very important beliefs:
(These are the generic, non-software version of the Agile Software Manifesto.)
See also: Optimizing a Team Room
Posted by Mishkin Berteig at 11:26 AM | |
November 12, 2005
Agile Work Business Case - Pragmatic Reasons for Using Agile Work
Time to market/process cycle time is improved, possibly to reducing the time to that of a single iteration. This reduced time to market can produce an incredible competitive advantage both by increasing an organization's ability to respond to change and by proactively instigating change that other organizations will not be able to respond to adequately.
Using Agile Work practices and focusing on Agile Work disciplines improves the chance of projects being delivered under budget. In fact, the whole notion of budget becomes meaningless when agile projects are delivering incredible value incredibly quickly. Profit-oriented organizations will see their budgets expand as their profit grows and non-profit organizations will see the value they deliver grow far beyond expectations with a constant budget.
Stakeholders, in particular end-users have ownership of the solution and are more likely to accept it. Whatever system or result Agile Work is used to create, that result will have very low levels of waste due to non-acceptance. This is also a reduction of the risk that the wrong solution or a poor solution is delivered.
Improvements in staff development and retention by providing a positive learning culture. In some industries and sectors staff turnover is a major expense or source of waste. Agile Work is interesting, exciting and satisfying. People who have experienced Agile Work actively promote it and seek it out because it creates a situation where their talents are valued and used effectively. Adopting Agile Work will attract talented team players to your organization.
Posted by Mishkin Berteig at 09:09 AM | |
October 10, 2005
Agile, the Adult Educator and Ethical Considerations
A review of Tara J. Fenwick's “Limits of the Learning Organization: A Critical Look” (article found in Learning for life: Canadian readings in adult education
This article is a critique of learning organization literature (as presented in the works of Peters, Senge, Watkins, Marsick, Argyris, Schon and others). I chose to do a review of it because learning organization literature can and does inform the work of Agile practitioners. The writer, Tara Fenwick, offers a critique of this literature as an academic and practitioner in the field of adult education. Even though the language and tone of the article is judgmental and at times affronting to the corporate trainer audience, it is never-the-less challenging and valuable because she raises interesting ethical questions that can serve as cautions against potential trends that can distort agile practice. I will summarize her argument in the some of the areas most relevant to Agile practice.
Fenwick's summary of the model of learning organization found in the literature, is an organization that: “creates continuous learning opportunities, promotes inquiry and dialog, encourages collaboration and team learning, establishes systems to capture and share learning, empowers people toward collective vision and connects the organization to its environment.”
The following is a summary list of some of Fenwick's critiques:
Who's Interests are Served
Although the learning organization literature holds great promise for a more humanitarian and egalitarian workplace, it has the potential to distort learning “into a tool for competitive advantage” and in turn, exploit people as resources in the pursuit of profit. To explore this idea she asks a valuable question: “Who's interests are being served by the concept of learning organization, and what relations of power does it help to secure?” She argues that learning organization literature tends to serve the interests of educators working as trainers in organizations and managers interested in their own self preservation.
How Learning is Defined
Learning, in learning organization literature seems to be defined as that which benefits the organization, all other learning falls into the dysfunctional category. This perspective negates other ways that people create meaning and learn and potentially causes a person to become “alienated from their own meaning and block flourishing of this learning into something to benefit the community.”
Assumptions about Learners
The learning organization literature subordinates employees by seeing them as “undifferentiated learners-in-deficit”. Educators and managers are the architects of the learning organization while employees are busy “learning more, learning better and faster” trying to correct their knowledge deficit. In the learning organization workers become responsible for the health of the organization without the authority to determine alternative ways to reach that health. The fear of being left behind in a quickly changing market environment is used to create anxiety and fear as motivations for learning. All of these factors serve to put serious limits on the potential of people to learn in the work environment.
Diversity and Privilege Overlooked
Perspectives of race, class and gender -which research has shown affects the way people learn and collaborate- are lacking in the literature. Fenwick challenges the notion of achieving a democratically ideal situation for open dialog -that the learning organization literature calls for- when all people in the work place do not “have equal opportunity to participate, reflect, and refute one another” (for example because of the status of ones job, character, gender, class, age etc.)
Fenwick sheds a clear light on where the good philosophies of the learning organization are found wanting. The Agile community can benefit from asking some of the same ethical questions she asks in relation to our work. Her critique is a good challenge for Agile practitioners. It challenges us to:
- Continue to strive for higher levels of ethical excellence in our work
- To consider issues of power in our work
- To become conscious of how we use our own power
- To give thought to what voices are included / excluded in the creation of the learning organization
- Pay attention to how we motivate learners
- How to foster collaborative environments that are conscious of the privileging of some over others
- Think about who decides what is valuable knowledge and learning and how that affects the knowledge creation process
Reflecting on these issues will go a long way to contributing to the development of agile practice.
The full text of an old version of Fenwick's article can be found here.
Posted by Shabnam Tashakour at 09:35 PM | |
August 23, 2005
Agile Offshoring References
Many people are trying out Agile Work in software development. The current industry climate is one that has focused business stakeholders' attentions on re-examining their core priorities. Where Agile optimizes on "Time to market", the offshoring "over-the-wall" approach to software development seeks to optimize on raw dollar cost.
What do you do if your organization is attempting both? There are some good resources on-line about this already, however I have yet to see good case-studies with published figures. Also, much of what's out there comes in the form of mini-articles that are no more than promotional ads for X proprietary "agile-offshore" solution. Regardless, some of the following may help avoid the worst problems of integrating two quite different approaches.
- Using an Agile Software Process with Offshore Development: by Martin Fowler
- A look at Valtech's approachfrom within the project. This calls itself a case-study, but no metrics are provided
- The sad and understandable ruminations of Jonathan Nolen on his blog, regarding Agile offshoring and his expectations of the project. These attitudes and cocerns are quite common - this is a good poster for the kind of feeling you might find from developers.
- Vincent Massol's presentation to Javapolis. No proofs or metrics, though some lessons learned are provided.
- A forrester research article on Agile Outsourcing. Note: this is only the abstract - the article is $350. (I should ask for a commission. :)
- Some practical advice on agile offshoring from a Thoughtworks fellow.
- Good points about customer proxies that are very applicable to offshoring with agile
- A very good summary of an ongoing conversation about fixed-bid contracts and Agile. It relates to the agile-offshore issue given that often projects are offshoring because of cost-sensitivity, and are thus fixed-bid.
- A look at criteria for choosing offshore partners based on Agile business readiness.
- Article by Scott Ambler on agile outsourcing.
- Article by Scott Ambler on agile outsourcing.
Posted by Christian Gruber at 03:47 PM | | | TrackBack
August 18, 2005
Harvard Business Review Article
I highly recommend this article on Collaboration Rules. Great stuff in there about developing teams, developing organizations and how important communication and trust are to doing so. The article draws examples from and compares the open-source development and maintenance of the Linux kernal and the operation of the Toyota Production System.
Posted by Mishkin Berteig at 10:48 PM | |
August 12, 2005
Just-In-Time Value Delivery and Waste Elimination
Lean Manufacturing
If I am manufacturing computers, and I receive a large batch of CPU's... say... Intel Pentium IIIs, I put them in inventory. There is a recurring montetary cost associated with keeping this inventory. There is, however, also a hidden cost. If I use up half my inventory to build computers, and then I inventory those computers, and I ship half of those computers, I now have 3/4 of my initial chips waiting around, earning me no money at all.
Then, Intel ships the new Pentium 4. What happens now? Well, I basically have to throw out my Pentium 3 stock (either by making low-cost, reduced-margin computers just to get rid of them, or by trying to sell the chips wholesale at cut rates). I also have to either slash prices on my remaining stock of computers, or re-fit them with the new processors. All of this is very expensive, and may eliminate most or all of the profits I was expecting to make on the original purchase. It is a scenario that is rife with waste.
Most manufacturing industry players have figured this out, and moved to a Just-In-Time model of production. Toyota pioneered much of this in the 1970s, and now inventory is seen as a liability, rather than an asset. This waste-free approach is a centrepiece of the Lean manufacturing revolution
Waste and Inventory in Software Development
Unfortunately, there is a parallel in computer software creation that has been rather poorly understood by businesses that need custom software development. Waste can be considered as anything that is unfinished, and/or unused. In software development terms, this can be applied to documents that will never be read or that might be unnecessary, and other such things. It is also true of unfinished software.
Traditional Software Development Example
Let us suppose that we ask someone to develop a piece of software with thirty features. Let us further suppose that this software will take about twelve months to produce. Let's further suppose that ten of these are business-critical features, and that all of the features' definitions are highly market-driven.
So a traditional software project starts to develop them. First there is a requirements analysis phase, then a design phase. Throughout there are lots of approval stages, sign-offs, etc. Then some team codes up the software starting somewhere around month five. Coding proceeds for about three months, after which the software goes through