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 | |
October 12, 2007
Agile Classroom Management
I'm fascinated by the idea of applying agile methods outside of software... be it to business management, family and household, or, as I and my father have been exploring over the last two and a half years... agile classroom management. Here's how I do it in my Agile Project Management / ScrumMaster Certification courses:
My father, Garry Berteig, had been using agile methods in his classroom for over two years before I tried it myself. I had gone into one of his courses at Keyano College in Fort McMurray to give a presentation to his second-year media students on agile and Scrum. They used it for a video project (see "A Student Documentary Film Project" and "Scrum Saves the Day for Media Student". Out of that experience, and others, he developed the idea of the Learning Circle as the basic cycle in an agile learning environment.
In the meantime, I became a Certified Scrum Trainer. Back when I did it, this just meant co-teaching a Scrum class with Ken Schwaber. He had a standard slide deck which he presented as he masterfully guided a class through two days of Scrum training. I (as expected) took that deck and made it my own by reformatting, rewording, changing a few of the exercises, and changing the emphasis in a couple of spots. And then I used that deck with minor corrections and updates and some expansion over the course of the next 16 months.
In the meantime, I was also doing a fair amount of training for teams and organizations that didn't care particularly for Scrum, but just wanted to know more about this "agile" thing. Sometimes it would be a one-day course, sometimes as much as five days (that was exhausting!!!). I developed a substantial body of modules including exercises, case studies, and special topics. Eventually, I found that I was having a hard time fitting my fixed agenda materials into the time I had allocated. For example, I was commonly doing a three-day course and would find that by the end of the first day I was a little behind on my agenda and by the middle of the third day I would certainly be running out of time and miss possibly even two or three modules in the agenda.
Finally, last Sprint, I got a big client who asked for training for a large number of their staff. This gave me the opportunity to: a) work with the same materials and agenda at least three times, and b) involve an assistant in all three deliveries. The first time through, I had the typical problem where the third day was a terrible rush. The second time through, it happened again, but I had de-scoped and re-arranged some of the material so it didn't seem as bad. After that second time, my assistant, an excellent coach, David Chilcott, suggested that I try to apply a more flexible... agile... approach to handling the materials. We did a quick revision of the materials to support this idea and then the third class was run as an "agile training environment". What did this mean?
The main insight was that the time allocated to the class was timeboxed. This meant finding a way to prioritize the work of the class so that the majority of the participants would get the best value possible for their time in the class. We did this in two ways:
1) As questions came up, we found that some of them needed to be deferred because they would be answered in a later module or because there was background material that needed to be covered first. So, for every question that needed to be deferred, we wrote it up on a 3x5 note card and put it up on the wall. Now, in order to keep track of this, we also had all the course modules written up on 3x5 note cards and up on the wall too. Most of the question cards would immediately be put up with the associated module card.
2) We drastically cut back the core required modules for the three days and made everything else optional. We then decided on a simple in-class mechanism to choose from those optional modules. At the end of the first day, we had time for one optional module so the class voted and we chose the module based on that vote. Likewise at the end of the second day. By the third day, we had a substantial portion of the day un-allocated. As soon as we finished with the required materials, we got the class to choose the next module to cover. As soon as that module was covered, the class chose again from all those still remaining.
It was a bit of a mess and our mechanisms didn't work perfectly, but it got the job done. At the start of our second day, the cards we were using to track modules and questions looked like this:
After we finished the course, we did an in-depth reflection and decided on some changes to be made. One of the most important was actually very simple: make the module cards much larger so that it was possible to put many question cards right on the module card. Here is what this looked like in a recent class:
The left is the module card at the start of the course with questions that were generated by the course attendees when asked what they wanted to learn from the course. The right is the same module at the end of the course. You can see that one additional question card was added between the start of the course and the time when the module was actually covered. You can also see that I use big check marks to show to the class that the module is complete.
Another change to the method of doing this agile classroom management came in the further refinement of the module content and sizing to be more appropriate for doing the modules in unpredictable sequence. This included things like checking definitions, improving some of the introductory material (to make sure all the concepts were introduced, not just some of them), finding references to other modules and removing them, and in some cases moving material from one module to another. There are still improvements to be made in this area.
Thirdly, we now are better at explaining to the class how this will all work at the start. We are modeling an agile process in the way we run the course. This means that the attendees will have an opportunity to influence what material is covered and in what depth. It also means that if the class takes a lot of time with questions early on with the basic material, it leaves less time at the end for optional modules. The people in the class can now visibly see these tradeoffs.
Here are two photos from a recent class. The first was taken at the end of the first day (note that I forgot to use the check marks on these cards). The second was taken at the end of the third day. You can clearly see how the modules of the third day were chosen entirely by the participants from the available optional modules.
This mechanism of managing a classroom using an agile approach has had some very interesting results:
1) Every class is substantially different. Before, the differences were always in the details: timing, specific questions, etc. Now, the actual material covered is uncertain. I always make adjustments to the course materials after every course. Now, not only are those differences in play, but also the actual modules covered might be different. The fascinating thing is that now, by the time we get to the last module, most of the people in the class are giving off a palpable sense of satisfaction: their urgent questions have been answered. Sometimes, this is so strong that I do the graduation "ceremonies" right before covering the last module so that people not interested in that last module can leave a little early.
2) I get far fewer comments in my feedback forms that indicate a desire that the course was longer. Before I started using this agile learning environment, I would get a substantial number of comments to the effect that it was really too bad there was not another day. Now I rarely get those comments.
3) The attendees in the class see how an agile approach actually works in a real life situation. They see that allowing the requirements to change over time is actually a good thing. Every single time I do this, there is a pattern that shows up on the third day that relates to the way the class prioritizes the next module. I count up the votes and choose the next module to cover. All the other modules have their scores written on them as well. After a module is covered, instead of using those old scores, the class takes another vote. Every single class, the priority changes between votes. This clearly demonstrates the power of allowing stakeholders to change their minds after seeing real results.
4) Participants in the course are engaged at a deeper level. There are lots of "tricks" for keeping people engaged: discussions, exercises, simulations, questions, presentation eye candy, etc. All of those things have their place and are important. However, by having participants steer the course itself, the level of engagement suddenly becomes much more substantial. The participants are responsible for the results of the class in a way that is quite unusual in most educational environments. This responsibility is granted to them and they take it seriously. I rarely see anyone refuse to participate in this process, and I never see anyone attempt to subvert it.
If you are interested in learning this mechanism of classroom management, I strongly recommend:
1) Learn up on agile. The openagile.org web site is starting to define an agile method that is abstracted away from the software legacy that agile methods currently are shackled with. This site is still in its infancy so treat it gently :-)
2) Come try one of my courses! (Yes, that's a blatant shameless plug!) You will get to experience and learn the agile method in a focused setting. The courses are IT/software focused in some respects, but since they are non-technical courses, and really about agile project management and human interactions, almost anyone can attend (I've had dancers, administrative assistants, educators, artists, community workers, executives, and actors all attend).
3) Get in touch with me to find out more of the details that didn't make it into this blog entry. The best way to do this is (really) through my business web site: berteigconsulting.com where you can find both email and phone contact information.
Well, I finally got around to writing this up. This is part of a series of related articles "tagged" as USEFUL started by Scott who writes at Tyner Blain. His article, which started the game of tag, is called Software Product Success Stories. Scott... I'm sorry this article isn't about software!!!
I would like to now tag a few people who write useful blogs:
Mike Vizdos who writes the Implementing Scrum blog. This blog is best known for the fabulous cartoons of the Chicken and the Pig, but also has a lot of great and practical insight on the challenges of, you guessed it, implementing Scrum!
Tobias Mayer who writes at Agile Thinking. He doesn't write often, but his articles are always fantastic! I hope that Tobias will take the time to write something in this "useful" stream and pass along the tag.
Mark Levison writes Notes From a Tool User and discusses many things, not just agile. His writing is fun and he's in the trenches doing real serious work getting his company to use agile. He's got good insight.
Posted by Mishkin Berteig at 03:46 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 06, 2007
Four Methods of Perfecting Agile
Most organizations start doing agile (or Scrum or lean or ...) imperfectly. Someone introduces a few practices or a manager gets a team some training, or a person starts using agile terminology. And things might improve, particularly with the use of iterations. One of the core ideas of agile methods is to have frequent delivery of valuable results. In fact, this core idea can be used to drive the improvement of an agile process. How? Here are four methods of perfecting agile by expanding the definition of done.
Perfecting Agile
Let's suppose you already understand the benefits of agile. With these benefits in mind, you would like to improve the organization's ability to deliver working, valuable results at the end of every iteration so that you can get better at realizing those benefits. The primary way to do this is by expanding the definition of done. You can imagine this like so:
On a regular basis, the team/organization find ways to bring work done in either the preparation stage or the close stage into every iteration of the agile portion of the project. By moving the work from these "bookend" stages into the iterations, you reduce the amount of time spent in those stages and simultaneously create a more complete delivery every iteration. The "definition of done" is now expanded to contain the results or value delivered by the work that was taken out of the startup and shutdown stages of the project. By expanding the definition of done, each iteration delivers a more "complete" increment of value, and there is less work done before or after iterations in order to plan or deliver. This gradual process allows the team to get better at doing agile.
There are four methods for transferring work from the start and end of a project into the iterations of a project.
Expand the Agile Team's Skill Set
In some ways, this is the simplest and most common approach to expanding the definition of done in the agile portion of a project. By training, coaching, mentoring, re-assigning or hiring, a team's capacity to do work is expanded and used to expand the definition of done. As a simple example, a software developer might learn to use an automated unit testing framework and therefore expand the definition of done to include some amount of unit test coverage of delivered code. In general, training, coaching and mentoring existing team members should be preferred over adding people to the team since the addition disrupts the team's development and can increase communication overhead among team members.
Expand the Agile Team's Authority
Sometimes, a team is not able to do part of the preparation work or close up work because they are not authorized to do so. This may be a policy, a unspoken assumption or a bureaucratic procedure. By giving the team (or some person on the team) the authority to do this work, the team can find ways to do it every iteration instead of having to work through another non-team individual. Again, a simple example here is a situation where a technical person is given permission to talk directly to an end user in order to reduce the need for up-front requirements gathering and analysis and reduce the need for end-of-project user acceptance testing. The obvious challenge to do this is the question of trust (or lack thereof).
Automate an Existing Manual Process
Automation is often given far less than its due consideration. This is primarily be cause automating a process is an investment of work in and of itself. Fortunately, it is often easy to measure the ROI or savings involved with automation. In many agile environments, heavy automation is critical and a huge enabler for very short iterations. Automated testing, automated translation, automated build processes, are all common areas of improvement. Agile teams should always be looking for opportunities to automate their own work. In this way, the automation work itself is transformed from a separate project to a responsibility of the team.
Remove Wasteful Processes
There are some parts of the project preparation work and the project close up work that are pure waste! There is no independent value to these activities, nor is there indirect value to them. An excellent example of this sort of thing is an approval process that _always_ grants approval ("rubber stamping"). One insurance organization I worked with as they were converting to an agile approach discovered that their "second stage" approvals always allowed proposed projects to proceed. Since they often incurred a 4-6 week delay for this approval process, it became obvious that they should "get rid of it". Now, what they actually did is made it so that it became a parallel review process rather than a gated approval process; this was so that the true purpose of the activity could still be met: to help stakeholders understand the projects that were being worked upon. Here, there is no need to take this approval process and somehow work it into every iteration. An agile approach tends to increase the visibility of the work anyway, so it may be discovered later on that the review process can also be done away with.
Agile is often implemented in a limited fashion when it is first adopted by most teams and organizations. The four methods of expanding the definition of done can help a team or organization get better at doing agile and therefore reap more of the benefits of agile. These methods are simple: expand the agile team's capacity, their authority, have them automate manual processes and remove wasteful activities from the process.
Posted by Mishkin Berteig at 03:32 AM | |
August 18, 2007
Agile Management Tools
Ah, tools...
For agile training and consulting, I always recommend starting with the standard physical tools of note cards on a wall plus a whiteboard and digital camera. However, I am still interested in what tools people have used when they have found that note cards are not sufficient. Here is a list of the tools that I am aware of, as well as a link to a survey...
This list is in alphabetical order:
Custom In-House Tool
Defect/Enhancement Tracker (e.g. Jira)
Spreadsheet
Wiki (e.g. Fitnesse)
The survey is extremely short (four questions) and will be closed on Sept. 15th:
Click Here to take the Agile Management Tools survey
I will publish the results here.
If you know of other tools (open source, products, etc.) please let me know in the comments!
Here are more tools for managing agile projects/requirements/planning that have been mentioned by folks in the comments:
Thanks to everyone for including the urls in the comments!!!
Posted by Mishkin Berteig at 02:36 AM | |
August 01, 2007
Agile Estimation and Pairing
I just read a recent article on PMHut called "Schedule Questions: Pair Programming and the PNR Curve". There is much in this article that is important for agile project management... and much that should be avoided at all costs!
Estimating Projects
The bulk of the article is an explanation of the PNR curve (Putnam Norden Rayleigh curve). The explanation is sufficient and can be checked against other web articles about software estimation. The basic idea of the PNR curve is to find an ideal number of people with which to staff a project based on an estimate of overall project size (e.g. 72 man-months).
Take a moment to go read Fantasy Estimation (the comments here provide good additional material).
It should be clear now that any initial sizing estimate based on units such as man-months is ridiculous. So what is our alternative? What about an agile approach to estimation and planning?
Agile Estimation
Well, at a minimum, in an agile approach to estimation, we need to resolve some of the problems identified in "Fantasy Estimation". So, we:
- Get the whole team that will be doing the work to do the estimation
- We weight estimates based on team maturity, knowledge of tools, knowledge of the business domain and the physical proximity of team members to each other
- We adjust our estimates of work remaining based on our results for work completed
The great thing about an agile approach is that it allows all these things to be done and to be done well. Scrum has a specific set of "Drag Factors" that can be used to weight the team's estimates. And using a team's past estimates vs. "actuals" is possible on an iteration by iteration basis... and this is possible because every iteration the team is doing the "same thing": delivering an increment of valuable results (working software, edited video, organizational change, whatever is contributing to the project goals).
The other thing that agile methods allow is to make a distinction between estimation for planning and estimation for commitment.
So. It's cool to learn about the PNR Staffing curve and the thinking behind it. It's a little scary to see it being applied in an agile context when we have tools that are much better.
Pairing and Estimation
At the end of the PMHut article, the author, Mike asks a question:
What about pair programming? When using pairs on a team we could either:
- Continue as is, use the model to determine optimal team size and then encourage pairing to increase efficiency.
- Treat a pair as one hyper-effective person, so count pairs not individuals and increase team sizes accordingly.
This second option seems counter intuitive to agile, we strive for small teams to reduce communication channels, so I’m not convinced by this idea. I would be very interested to hear people’s thoughts on agile staffing curves. So, lots more questions than answers in this post, please let me know if you have any research or thoughts on the matter.
I wrote in response:
Mike, I feel like the options you present in your question at the end actually miss the true point of pairing… which has to do with communication. I have never seen pairing done in such a way that two people always work together as a pair. Rather, pairing is promiscuous: people switch pairs frequently throughout a day, iteration or project. This switching has two communication effects: 1) the human interaction and gradual diffusion of information as people switch pairs 2) helping everyone understand all parts of the work as a result of frequently working on many different things. From an estimation standpoint, I expect that neither of your two options is quite right. Rather, the third option is to continue as is with existing estimation and then encourage pairing to increase communication. Increased communication shows up in a number of different ways, not just efficiency: risk mitigation, accelerated individual and team learning etc.
I would like to expand on this just a little. To me, pair programming or pair work of any kind has always been able to provide a number of benefits to projects. Problem avoidance is one benefit (lower defect rates, better code quality through constant inspection, spotting each other). Better communication is another benefit. Increasing the Truck Factor is yet another benefit.
None of these benefits have any direct bearing on estimating a project at the start, particularly since most projects sacrifice quality for schedule. From an agile perspective, since planning estimation is not commitment, it actually doesn't even really matter! Get a conservative estimate for you project using whatever method you like, then start working and get a commitment velocity and see what the team can really do.
Posted by Mishkin Berteig at 10:04 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 16, 2007
The Wisdom of Teams - Generalizing Specialists
I've almost finished reading The Wisdom of Teams: Creating the High-Performance Organization
The [Connectors Team] made several decisions that solidified its common team approach and sense of mutual accountability. First, it set some rules. Everyone on the team had to identify two others who could serve as backups during vacation and sick days. To eradicate the attitude of "it's not my job" from the team, it was agreed that whenever anyone needed help, the person asked had to respond even if the activity was not in his or her area of expertise. And the team also agreed on a peer appraisal system that gave everyone the opportunity to evaluate everyone else and, through [their team leader], feed it back to the person being evaluated. Clear-cut rules of behavior like these are an important element of all successful teams.
Second, the team eliminated the two managerial positions that had retarded empowerment. This effectively modified the membership of the team because only one of the two managers whose jobs were eliminated chose to stay. The other believed he could not take a perceived demotion and left. By January 1991, however, the Connectors Team was a dramatically more effective group of people than it had been at its formation a year earlier.
Energy and enthusiasm reached higher levels as the team started pushing itself harder and in more innovative ways. One of the engineers, for example, decided to become completely qualified as a purchaser as well. Instead of being threatened, the purchasers on the team worked hard to teach her the basics of the job. The peer review approach worked so well that the team agreed on the additional - and, for many teams, difficult - step of directly providing each other feedback instead of relyinng on the team leader for this task.
There are several great points in the above story:
Backups: many agile methods do not explicity talk about this, but there is a need to make sure that the Truck Factor increases. A low truck factor can be a real problem and I strongly recommend that the Queue Master (Product Owner, Customer) in particular needs to have backup. As well, this hints at the idea that eventually the roles of Process Facilitator and Queue Master should eventually go away to be taken on by the team as a whole.
Skills: the example of the engineer learning to be a purchaser is a great example of a brave soul really taking to heart the idea of working for the good of the team by becoming a generalizing specialist. In my own coaching work, I have seen purely business-oriented Queue Masters become technical contributors to the team through a process of both deliberate and "accidental" learning. Every human being has an incredible capacity for learning. In a high-performance team, everyone takes that ability very seriously - to the point of it becoming a responsibility.
Rules: one of the simplest, yet most profound, ways that a group of people can start on the process to becoming a high-performance team is by working together to agree on some ground rules about team behavior. One team I worked with, among other rules, decided that no "stinky food" was allowed in the team room. The passage above notes the non-trivial rules. Both "trivial" and non-trivial rules are important to the team for two reasons:
1. Develop a set of expectations that individuals can hold each other to in order to avoid or deal with conflict.
2. Become aware of the team's power to set their own working conditions, independently of management or other "leadership".
Management: regrettably for most managers, in a high-performance team the value of formal, traditional management is much reduced. However, there is now an opportunity for two different types of work: the generalizing specialist work on the team, and the servant leader work of supporting the team. The servant leader is someone who is exceptionally good at problem solving, organizational change, and working through influence rather than authority.
This book is incredible. Every time I read a few pages I think "Oh! I've got to write about that on Agile Advice!" Unfortunately if I did that, I'd be in serious copyright violation. So all I can do is encourage you to read the book.
If you have already read the book, I would love to hear your impressions, particularly if there were things about it that you really didn't like. What didn't you like and why? What are the holes in it's argument?
Posted by Mishkin Berteig at 04:05 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 | |
December 07, 2006
Peformance Goals - The Wisdom of Teams
As I continue my enthralled read through "The Wisdom of Teams: Creating the High-Performance Organization
The Performance Goal
This concept and practice is an essential condition for a team to become a high performance team. The Performance Goal is a specific, measurable, challenging goal that is given to and/or adopted by the team. It is a statement or description of a goal that answers "why?" and "what?" questions, but specifically avoids answering "how?". It is not a description of activities, it is a statement of desired results. The team is left with the full authority to answer "how?" and implement it.
This concept is essential for setting the initial boundaries of self-organization. By defining "what" and "why", the team is left free to be creative about the solution. The Performance Goal is also essential to building team accountability (as opposed to individual or externalized accountability). Every action, plan, mistake and success are oriented around the Performance Goal.
From the book:
The hunger for performance is far more important to team success than team-building exercises, special incentives, or team leaders with ideal profiles. In fact, teams often form around such challenges without any help or support from management. Conversely, potential teams without such challenges usually fail to become teams.
I would also like to point out a great blog entry I found that shows some of the other side of dealing with teams and present some cautionary words about the potential pitfalls of working in teams.
In an Agile Work environment, the starting point for a performance goal is simply the delivery of valuable work at the end of their very first iteration. This is often a substantial challenge to a team and an organization. For some teams that have worked for a long time in a "waterfall" or phase-based project environment, it can be almost unthinkable that valuable results could be delivered in one tenth or one twentieth of the "normal" amount of time.
However, simply delivering value at the end of each iteration is probably not going to sustain the development of a high performance team for very long. Rather, the overall objective or goal of the project has to be important and compelling. Much work these days is _not_ important and compelling. In fact, many people become cynical about work because they are stuck doing a high proportion of work that is bureaucratic or due to chaotic circumstances.
As a reminder, the books "Good to Great
I frequently work with organizations where a team has been formed up, told to use agile methods, and then also told how to do their work. Really great examples of this are things like: "we want you to self-organize, but you have to build this huge system using J2EE." The the problem with this is simply that it may in fact be ten times less expensive to build the system with Ruby. However, someone has decided (possibly for defensible reasons) that J2EE is the technology platform that must be used. In this circumstance, someone external to the team has stepped over the boundary of "why" and "what" and also included some "how" in the team's goals. The team is not even allowed to consider the possibility that something might work just as well and be much less expensive. Not only that, but the stakeholders haven't even really stated "why" the system is being built and so the team can't evaluate technology choices. There is no standard around which to self-organize. I admit that I am using a simplistic example here, but the pattern is something that I have seen over and over again.
Posted by Mishkin Berteig at 11:44 PM | |
November 24, 2006
How to Avoid Context Switching
Given the huge interest in the article by Dmitri Zimine about context switching, and despite a couple of good articles about how to determine iteration length, there has been no empirical method described, only reasoning processes. This article describes a simple method to quickly determine iteration length by experimental means.
Step One
Start with an iteration length that feels right. Use the two articles below to try decide a reasonable length. In software development, this should be no longer that four weeks. In larger volunteer communities it might be as long as three months. In a work environment where you have to deliver daily, your iteration length might be two hours.
Step Two
Build your Work Queue, and plan your first iteration. Mark the tasks that come out of your iteration planning meeting so that you know that they are tasks that were planned. As you go through this first iteration, track all the interruptions you get by writing up a task for each interruption. Each interruption task should be marked so that you know it was an interruption. If you are using note cards on a visible task board, I like to have "normal" tasks on white cards and interruption tasks on fluorescent orange cards to help them stand out!
Step Three
At the end of your iteration, determine which interruption tasks could have been deferred. In other words, determine which were truly urgent and needed to be handled in the already short time of your iteration, and which could have been put on the Work Queue, prioritized, and therefore deferred to a later iteration. This will require collaborating with your Queue Master and possibly other stakeholders.
Step Four
Count how many non-deferrable interruption tasks your team had in the iteration. For this experimental method, you can assume that this is going to be your normal number of interruptions. Divide the length of your iteration by the number of non-deferrable interruptions. For example, if you had a ten day iteration, and two non-deferrable interruptions, you would have a result of five days. Also consider what was the maximum reasonable response time for these non-deferrable interruptions. The lower of these two values becomes your experimentally determined iteration length. But you are not quite done!
Step Five
Do it all again to verify your iteration length. Note that because of your shortened iteration length, you hopefully will have far fewer non-deferrable interruptions. After your second (shortened) iteration, you can adjust the iteration length shorter if necessary... but don't adjust longer (for now).
I've worked with enough teams to know that for a substantial portion of them, this method would result in very very short iterations. In the software world, a team is often asked to work on a project and support their previous project. This support work tends to mean dealing with various bugs in deployed software. This is one reason why I have become such a strong advocate that quality is not negotiable.
I worked with one team that did something similar to this method (although not as rigorously) and we decided that we needed to try an iteration length of two days. This was painful for the team, but they badly wanted to build trust with their stakeholders. Their interruptions were causing them to constantly fail on their commitments. By switching to these two day iterations, they were able to defer the bulk of their interruptions and meet the commitment they made as a team in the iteration planning meeting.
Articles about iteration length:
Mike Cohn's article: "Selecting the Right Iteration Length for Your Software Development Process"
Mishkin Berteig's article: "The Pros and Cons of Short Iterations"
Now that you have gotten to the end of the article, I can admit something to you: this article is badly named. It should be named "How to determine how often to context switch so that you can meet your commitments and build trust with your stakeholders."
What this article doesn't help with is the pain of context switching. The teams that I have see that use short iteration lengths all find ways of making context switching less painful. Automation, good tool choices, workspace arrangements, etc. all play a part in this. But there is no secret ingredient to make context switching painless. Sorry!
Posted by Mishkin Berteig at 07:55 AM | |
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 14, 2006
Process Facilitator "Smells"
I have now trained over one hundred people in my Agile Project Managmenet / ScrumMaster Certification course. I'm starting to see and hear some of the results of this training. There are a couple specific "smells" that I have become aware of.
Fortunately, I've been able to provide coaching to some of the organizations that have sent people to my course. There are quite a number of good things that happen, but there are a couple of things that seem to be "natural" misunderstandings.
- Spectating
I put a lot of emphasis on the idea of a self-organizing team in my course. There are a number of exercises, an hour-long section, and many other points during the course when it comes up. With all of this emphasis, it seems that a few people have come away from the course with an extremely hands-off approach to the Process Facilitator role (ScrumMaster/Agile Project Manager). I think this is a natural and probably good reaction to the heavy-handed command & control approach that these people come from. However, there are a few things that should be considered minimum levels of engagement (listed below). - Problem Solving
There is also a great deal of emphasis put in the course on removing obstacles. I have seen several cases where it becomes the habit of the Process Facilitator to start solving every problem. This can happen in day-to-day work, and also in the retrospectives. Again, this seems to be a natural consequence of the desire to get in there and be of value. However, if the Process Facilitator writes down all the "things that need impovement" from the retrospective and then says "Okay! I'll take care of these things." then you know that the Process Facilitator has gone too far.
Appropriate Process Facilitator Engagement
Here are a few ideas on an appropriate level of engagement. Finding the right balance of enagement is not easy and there is no exact formula to follow. Partly it depends on your personality and skills as a Process Facilitator, partly it depends on the capabilities of the team, and partly it depends on the constraints of your work environment. Nevertheless, there are some types of engagement that you can persue with confidence. Here are a few concrete guidelines:
- Team Membership
If you aren't saying "we" when referring to the team, you aren't engaged enough. The Process Facilitator is a member of the team. - Colocation
Most of your time should be spent sitting with the team. If the team isn't colocated, then you should be spending most of your time physically visiting each team member. - Obligations
The Process Facilitator is a catalyst. You must track all the obstacles and "needs improvement" things that the team raises, and then make sure that they get fixed... without going in and fixing everything yourself. Ultimately, your job is to work yourself out of a job. - Assertiveness
The organization that the team is working in will be creating some of the obstacles that the team is facing. Being assertive is critical to helping the organization face and then overcome some of these obstacles.
Posted by Mishkin Berteig at 01:49 PM | |
November 12, 2006
More on Scaling Agile
One problem with having multiple teams working on the same project will be the tendency to compare the teams' performance. Why is this a problem?
Why Not Compare Team Performance?
One of the main reasons is that the teams need to be collaborating not competing. There can be a small amount of friendly competition that might come naturally, but as soon as management starts paying attention to differences in team performance, the competition starts to get serious.
In the case of multiple teams working on the same project, the goal should be to maximize overall performance, not individual team performance. Too much competition can lead to unintentional or deliberate sabotage: failed communication, incomplete communication and downright dishonesty.
Motivating Teams without Comparing Them!
As Mary Poppendieck has written, measure up [pdf]. In a single-team situation this means that individuals are measured and rewarded based on team performance (their sphere of influence). In a multi-team environment, that means that the group of teams should be measured as a group and compensated as a group. This will encourage all teams to work towards the success of the overall project. I personally believe there is some room for individual-based compensation, but the way it is handled needs to be done so that it does not encourage sub-optimal behavior.
As well, each team can keep track of their velocity. Some coaches recommend using "ideal hours" or some other units to determine velocity (velocity = estimated work remaining completed / iteration). The trouble with doing this with multiple teams is that there will be a very real tendency to want to compare each team's velocity. Since velocity is a useful measure for team capacity, it is important to still have a way to measure it. One simple way to do this to prevent comparison is to use different units for each team. Team One might be measuring velocity in Estimated Ping Pong Balls Completed / Iteration... Team Two in Estimated Bananas Completed / Iteration... Team Three in Estimated Bogo-MIPS Completed / Iteration... etc. etc.
Motivating Collaboration
First off, management must make visible commitments to eliminating barriers to collaboration. For example, it is a great sign of commitment to re-organize office spaces so that all the teams are sitting near to each other. Every time the Process Facilitator identifies an obstacle that relates to collaboration (tools, process, physical environment, etc.) management should get right on it and fix it.
An ongoing investment in team-building training, workshops and exercises is also helpful. This type of investment helps people gain the skills necessary to work effectively with other people. Again, individuals need to see and believe that management cares about and values teams.
Finally, one of my pet peeves: when a project is over, keep the team together! Do not break them up and redistribute your "resources" to other efforts. The value of those people working together is substantial. The value of those people working together as a high-performance team is incredible! In a multi-team situation, it is reasonable to take teams from the overall group and re-distribute their efforts... but just don't break up the individual teams.
Miscellaneous Notes on Scaling Agile:
Twelve is still the maximum recommended size for a single agile team. Seven is really the sweet spot. A team larger than twelve people just takes too long to get into the Performing stage of team development. If you feel like your project needs more than twelve people actively involved, then you probably want to split into two or more teams... and then you have "scaled" agile.
If you have three teams of five people (or some similar configuration of people just over the 12 person limit), then they will work as a very close-knit group and a lot of the time will act as if they were a single team. They will probably plan iterations and do demos and retrospectives together.
Twelve teams working on the same project at once is about the maximum number before communication overhead is slowing everyone down too much. This is largely a factor of trust: with 150 or fewer people involved in an effort, it is possible for everyone to know everyone. More than that many people and it is no longer possible. Trust is just not an option anymore and bureaucratic controls take over.
If for some reason you need to do something in a small amount of time and you think it's going to take more than twelve teams of twelve people...? Break the effort into smaller chunks. Divide and conquer. Division can be across functional areas, structural areas or time.
Although I have heard of agile methods being used with groups larger than this, I haven't heard any success stories :-)
Check out my earlier introductory article on Scaling Agile in a large project situation.
Dean Leffingwell has an article about practices needed for scaled-up efforts at the Agile Journal. I glanced through it, but I admit that after I disagreed with his very first point (Intentional Architecture), I started to pay less attention.
He claims that refactoring of large systems is not possible (or at least infeasible). The odd thing is, most large projects that I have been involved with are being done exactly because an old system is not refactorable. A large telecom system, a large insurance system, a large data warehouse and a large GIS system are all being done with scaled up agile methods exactly because the old systems that are currently in place have become ossified to the point where they must be replaced.
These old systems were originally built with phase-based development approaches. At some point, people stopped refactoring because they were not given the space to do so. This drop in code quality turned into technical debt. The technical debt accumulated to the point where it was unbearable (maintenance costs, cost of change, etc.).
The problem with intentional architecture is that it goes back to the old assumption that you can do a good design for a system without the constant feedback from review, deployment and use done on a very short cycle time. Over and over, we are faced with the painful consequences of this attitude, and that is one of the key reasons we started to work with agile methods in the first place.
Martin Fowler makes a good case that scaling agile is the last thing you should do. I don't disagree! Scale your agile teams at your own risk!
It's nice for me to be able to say that I've worked on some agile projects over $10,000,000 in size, but the fact is that the cost could have been reduced substantially if the team size was lowered and the deadline extended. It is (relatively) simple to do a cost/benefit analysis of cross-team-coordination-overhead vs. the time value of early delivery of more functionality... although I've never seen anyone do it! If you know of an example of an organization doing this in a realistic way, I'd love to hear about it!
Are there other ways of supporting cross-team collaboration that you have seen?
Posted by Mishkin Berteig at 09:13 AM | |
November 10, 2006
How Two Hours Can Waste Two Weeks
Your developers have just planned a two week iteration. The next day Sarah continues her work on the completion of an important New Project. And here it comes - Urgent Stuff...
Your developers have just planned a two week iteration. The next day Sarah continues her work on the completion of an important New Project. And here it comes - Urgent Stuff:
>From: Project Manager
>Sent: 2nd Day Of Iteration
>To: Sarah, the Developer
>Cc: Yo, Dev Manager
>Prio: HIGH
>Subject: Coarechon needs Ezhibal
>
> I need you guys to find out if we can add "ezhibal" functionality to our old "Tounaf" project, and how much time this fix is going to take. We have a hot deal with an important customer who is almost ready to buy.
> Sarah please investigate ASAP. We can arrange a phone call to clarify requirements.
Soon there is a dialog that might go like this:
Project Manager: "Sarah, how long do you think it takes to check if it is feasible to add this 'ezhibal' feature?"
Programmer: "Well, I don't remember the old project details, but I can spend 2 hours to see if I can come up with something."
Development manager: "Sarah has her iteration planned. Why don't we stick to the plan?"
Project Manager: "What's the problem? It just takes 2 hours! What harm can it do?"
"It just takes 2 hours. It can't hurt!"
It can. We development managers learned it the hard way. We know how programmers think. We know how expensive switching their context is. If Sarah spends just two hours thinking of her old project, she loses a day of productive work on the new one. One day is 10% of a carefully planned iteration wasted if she spends 2 hours sidetracked.
In the wild nature of software development shops, however, it never takes 2 hours. 2 hours is the time Sarah is on the phone trying to clarify the problem. 2 hours is the time she is waiting for this phone call, reluctant to get into anything serious. 2 hours is the time Sarah is tweaking her development environment to build her old project. 2 hours is the time Sarah is spending to see if she can come up with a very restricted workaround. 2 hours is the time Sarah is on another phone call, explaining the potential workaround. Not enough time for real solution, no time spent on actually resolving the problem. 10 hours of unplanned and unproductive time is spread out over 3 days. 30% of iteration wasted.
At this point the planning goes down the toilet. The iteration is dead. The new project is slipping late. The rush around the old project yields little results either: with no time for a real solution the best bet there is a quick and dirty fix.
But the harm goes further. Sarah was eager to spend time on programming - she wasted it. She is robbed of her professional satisfaction, the good feeling of achieving the iteration goal and releasing project on time. On the next iteration planning session Sarah can't help thinking "Why kill time if we don't stick to the plan anyways?" The team gets the message: "We are NOT seriously doing iterative development. We are going ad-hoc".
Here is what I do:
* Tell the developer to stick to the original plan. Offer to protect her from switching her mind context. Remind her how cool it is to work single-mindedly on an important and interesting project. Ensure her that I'll handle the pressure. This is the good part; it is always well received :-)
* Tell the project manager that the iteration is carefully planned with a goal to release the new project by expected date. The plan leaves no space for switching the context daily. Our options are:
1) Put the issue to the back log and plan it for the next iteration.
2) Cancel the iteration, suspend the "new project", replan and work on the issue.
Let them make their call. This is the tough part; it is never well received. But I have to take a stand. I don't have the luxury not to do this.
The iterative development is an act of fine balance between adopting the continuous change and securing some stability for the developers to perform. We as development managers are responsible for keeping this fine balance. We do it for our team. We do it for our project. And we do it for our fellow project managers.
Cause we know something they don't always know: "How two hours can waste two weeks"
First published on SoftwareFrontier
It's great to have all the visitors here from Reddit and Joel on Software - thanks!. Joel brings up a great question about the other side of this: what about the sales guy who wants the new feature?
Posted by Dmitri Zimine at 02:22 PM | | | TrackBack
November 07, 2006
Scaling Agile Projects
More and more, organizations are applying agile methods to large projects or efforts that require more than a single team. There are three dimensions or concerns of coordination. It is critical that all three be addressed, but there are many ways of addressing them. Here I will simply list these three types of coordination and make some simple suggestions of how to implement them.
I have now had the opportunity to work with several clients where they are applying agile methods to projects with budgets that are greater than $10,000,000. All of them are using multiple teams to work on the same overall project/program. Out of this experience (along with some good reading along the way), I have come to understand that the following three types of coordination are the essential ones:
Value
In order to maintain the "early and frequent" delivery of value that agile methods propose, it is important that the work of the effort be coordinated to maximize early delivery of value. From this perspective, there are often many cooks in the kitchen. I have seen a "Product Owner Team", a "Customer Team", and a number of variations of this type. In order to do the coordination work effectively, it is still necessary to make sure of two things:
- Maintain a single Work Queue that prioritizes the work and from which all the teams select items.
- Have a single person in the "buck stops here" role who can make final binding decisions about work priority and content.
These two items have some implications for the organization.
First, the teams must be organized to be generalist: each team should be able to handle any item on the Work Queue. Not every team is going to be equal in abilities and this can be accomodated in a number of ways. My favorite so far comes from an excellent agile coach Dave West
The second implication is that the customer or product team (Queue Master) must have the availability to support multiple teams in a timely fashion. Ideally, there are individuals on each team who can make judgement calls about features, functionality, constraints etc. on the work and provide quick answers to questions. This is not always easy since the people doing this often have a special area of expertise and it is difficult for them to work outside this area. Just as team members are asked to become generalizing specialists, so must the people who are responsible for determining value in a project.
Process
An agile process endeavors to provide a minimally structured way to do three things: deliver value early, then learn about what is high in value and deliver that more, and finally, learn how to deliver value more effectively.
That third activity, learning how to deliver value more effectively, is facilitated by the Process Facilitator. The Process Facilitator keeps a visible list of obstacles and works collaboratively with the Team and the Stakeholders to resolve obstacles on the list.
In a multi-team environment, there may be a single Process Facilitator working with each team. Like with the Work Queue, it is often necessary to have a single Record of Obstacles for the entire project.
Technique
People develop skill and knowledge in the use of their tools. Most types of work have a special vocabularly that only makes sense to other people also doing that work. For example, the field of computer programming has programming languages, integrated development environments, build tools, testing tools, algorithms, and a host of other techniques. The field of film-making has cameras, film, directorial techniques, lighting, story structure, it's own esoteric vocabulary, and other techniques. Likewise for construction, law, medicine, drama, education, etc. etc. etc.
In a large Agile Work project, teams need a way to coordinate their technique to produce integrated, consistent and compatible results. As well, individuals on the teams may discover or create new ways of doing things that would be valuable for the other teams to know about and use.
The most effective way of coordinating technique across teams is for strong members of each team to gather regularly to review the way work is being done. This "technical support group" can look at tools, reuse, automation, patterns, vocabularly and any other "how to" aspects of the work. It is critical that these people are actively involved in work being done on a delivery team so that efforts of the technical support group do not become academic or "ivory tower".
In certain environments, it may be useful to have this techincal support group become a team with a clear allocation of time apart from the regular delivery teams. In this case, this technical support team would have its own Work Queue that consisted of requests, ideas, concerns, and opportunities presented by the regular delivery teams.
I have seen all three aspects of coordination implemented in large multi-team projects. Some of the common challenges include:
- Generalist Teams.
It is difficult enough to create cross-functional teams where people are willing to become generalizing specialists. While it is important to create generalist teams, most organizations should expect to set up non-ideal specialist teams (sometimes by line-of-business) and support their development into generalist teams. - Technical Coordination.
Often organizations have a design or technical review group composed of the "experts". These people are often isolated from the actual work being performed by the teams. It is difficult, yet critical, that these people actually be involved in day-to-day work on the teams.
Posted by Mishkin Berteig at 09:15 AM | |
September 12, 2006
Yet Another Big Picture of an Agile Process
I created this image for a presentation targetted to management. It's a good high-level overview of what goes on in an Agile Work effort. Feel free to use this or the high res version... just keep the copyright notice on and put a link somewhere in your email/document/presentation/webpage/etc. back to Agile Advice. Suggestions on ways to improve the diagram would be greatly appreciated. I will try to update it... and maybe even get my incredibly talented visual artist brother Alexei to re-do it.
Here's the high resolution version, good for nice printed material: Agile Work - The Whole Process.
Posted by Mishkin Berteig at 08:52 AM | |
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 | |
August 29, 2006
Seventeen Tips for Iteration Planning
Agile Work requires a team to take work items from a prioritized list, break those items into small tasks and then execute those tasks inside of the timebox of an iteration. When first trying agile, many teams have trouble with the task breakdown done in the iteration planning meeting. Here are some hints and tips for making this critical part of the agile process more effective.
1. Work items are, among their other qualities, valuable to the customer or stakeholders. Think of these work items as being built out of many smaller pieces. You can imagine a toy model made out of Lego bricks. Each brick, by itself, is of no value. It is only when they are put together that they become useful. The tasks you create for each work item are often small enough that they do not have any value on their own.
2. The word "task" implies activity... but the tasks you create for your work items do not need to be activity based. Tasks can be effective if they are written as components or pieces of the work item you are building. Here is an article about creating good tasks.
3. Sometimes if the work item is not well understood, you might find that a "research" or "experiment" task is a good starting place. Try to be as specific as possible. When writing the task description, spell out what exactly is the goal of your research, and possibly list what options you are going to research.
4. When first starting out with Agile Work, many teams find it difficult to do a good job of iteration planning in the fixed amount of time allocated to it. Consider shortening your iteration length so you can practice this skill more frequently. (Remember to make the planning meeting shorter too!)
5. Make sure that everyone has index cards and a pen to write with! Team members shouldn't have to wait for a "scribe" to write down a task. In many ways this is a brainstorming session. The Process Facilitator can collect all the cards after the meeting is finished if they need to be recorded more formally.
6. Do a first pass by creating "big" tasks... then break them up into smaller tasks if you have time. Since this meeting is timeboxed, it is better to get all the work broken down into big chunks than to break down only a small part of the work into very fine chunks.
7. If the same task keeps showing up for all your work items, it probably shouldn't be a task... instead it should probably be a process step or constraint or condition of satisfaction for the work you are doing. For example, if you always have to write a document that follows a template to record what you have done for each work item, then writing that document can be shown as part of your task board.
8. It's okay for tasks to be _very_ small.
9. Share your tasks! If you write a task down without telling the rest of your team, they can't use your idea to generate more tasks, nor can they improve on your idea.
10. Generating tasks in the iteration planning meeting is a problem solving and creative process. This is where you do a lot of your analysis and design work. This is where you struggle through options and choose _how_ to build/do your work.
11. Consider creativity technique such as light-weight brainstorming for generating lots of ideas quickly. Any technique you use should be streamlined for quick results.
12. Don't worry about administrative stuff while you are generating tasks. For example, if you normally put task cards up on a wall, wait until after the meeting is over to do this. Likewise, if you normally enter them into an electronic tools, wait until the meeting is over to do this.
13. Make sure you have scrap paper or a good whiteboard convenient for notes and drawings so that you can quickly model your solution for the work item. (Check out Agile Modelling for a discussion of this in the software realm.)
14. Remember that it's okay if you end the meeting with an imperfect list of tasks. You will make corrections throughout the iteration. It is more important to maintain the discipline of the timeboxed meeting length, than to get the tasks right up front.
15. The whole team must participate: everyone's experience, skill, expertise and insight are needed to do the best job of generating tasks. Just because it won't be a perfect list doesn't mean you can do a shoddy job of it!
16. You need quick access to information about the work items you are planning. You also need quick access to other relevent information. A computer with a web browser open to Google is a great tool to have at hand.
17. If you don't have anyone on your team who has lots of diverse experience and expertise, then consider inviting someone like this as a guest to help you out. It is much more difficult to do the necessary problem solving if you new to the medium in which you are doing the solving. Such a guest would need some time before the meeting to be prepared.
Posted by Mishkin Berteig at 10:44 PM | |
July 03, 2006
Agile Work Artifacts - Record of Obstacles
The Process Facilitator has only a few key responsibilities. One of those is to remove obstacles that are preventing the team for completing its work quickly, effectively and with high quality. The team's primary tool for tracking this work is the Record of Obstacles. Like the Work Item List, this is a fairly simple artifact.
The Record of Obstacles is a list where each entry in the list has three bits of data: a short description of the obstacle, the date the obstacle was identified, and a checkmark if it has been completed.
This list can be maintained on index cards, a whiteboard or an electronic tool such as a spreadsheet or wiki. The Process Facilitator maintains this list and all additions to the list go through this person. The primary source of items for the Record of Obstacles is the team's status meeting where each team member identifies any obstacles preventing them from doing their work. Additional obstacles may be revealed at the retrospective, or during the regular course of work.
The Process Facilitator should do his or her best to resolve an obstacle immediately. Lean manufacturing has an extreme example of this called "Stop the Line".
Ideally the Record of Obstacles is highly visible to all members of a team. This is so that everyone is aware of the current status of the obstacles listed.
Although this list is not normally prioritized, it is useful to do so if the list of un-resolved obstacles is lengthy. The Process Facilitator is responsible for prioritization of this list.
Posted by Mishkin Berteig at 09:33 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 23, 2006
Managing "Leaderful" Groups
In agile development circles self-organizing teams are all the rage nowadays. And I often hear people bemoaning the "evil managers". And no doubt in many circumstances and organizations there is real work to do here and real dysfunction to resolve. But I'm less concerned with the analysis of what's wrong and more concerned with what can we do differently and better. IE: How can we develop the skills necessary to practice effective self-organization.
So what does it mean to be a participant in a "leaderful" group?
The implication of "leaderful" is that many or most of the people in the group are exercising leadership. It seems that leadership is necessary, humans can't engage in group activity successfully without leadership. Successful group action always requires leadership and leaders. Someone, at least one person, must think about the effort as a whole and not only about her or his individual role in it in order for the group effort to succeed. A group can have more than one leader, but must have at least one to function successfully. Leadership is thinking about the well-being of the group as a whole as well as that of the individual group members. The essential commitment of a leader is to see to it that everything goes well.
I assume that leadership is an inherent capacity of every person and that leadership is not a "special" role or activity only for "special" people. The skills of successful leadership can be taught, learned, mastered, and practiced.
Further, I assume that people are fundamentally peers and that we are all doing the very best that we can at the moment. So the question becomes how do we reconcile assuming leadership with our peers? And how do we support each other in developing our leadership skills together?
More on this later...
Posted by David Chilcott at 04:58 PM | |
June 14, 2006
Agile Work Artifacts - Tasks
I recently described the Work Item List. The second type of artifact used in an Agile Work environment is the Task. At its most basic, a Task is a simple description of how to do some bit of work towards completing an item in the Work Item List. However, there are some important things to remember when using Tasks.
What is a Task
Normally, an item from the Work Item List is broken down into multiple Tasks. These Tasks are all the things that need to be done or built to get the item into a deliverable state.
In general, the process of creating a bundle of Tasks for a given Work Item is a design or analysis process. It is a problem-solving process. The Tasks themselves represent the solution: the building blocks of the structure of the Work Item. Tasks do not normally represent the problem solving or analysis process.
Here are two contrasting (somewhat contrived) examples of Tasks generated for a "Home Office Addition" to make this clear:
Example 1 Bad:
- determine requirements for home office
- design home office layout
- check home office layout with client
- choose furniture and decor
- build home office
- install furniture and decor
- unpack books and files into home office
Example 2 Good:
- 300 sq. ft. maple hardwood
- 4' x 7' custom desk
- Aeron chair
- red leather sofa
- 16' custom bookshelves
- 22" double French doors
- 8' 4-panel vinyl triple glaze bay window
- 36 2x4x10' metal studs
- ... drywall
- ... other building materials and furniture and decor
Generating Tasks
The whole team works together to come up with the Tasks for every Work Item being worked upon during the iteration. The majority of the Tasks are determined during the timeboxed iteration planning meeting. Sometimes, the iteration planning meeting is not long enough to get all the Tasks defined. Sometimes new Tasks are discovered during the course of the iteration. Either way, it is fine to make changes to the bundle of Tasks as the work proceeds.
Special Tasks
Due to the timeboxed nature of the iteration planning meeting, a Team will sometimes find itself knowing that there is more analysis or problem-solving needed for a given Work Item. In this case, a special Task can be created to indicate that this analysis work needs to be completed. For example, the task might be labled "Finish analysis for Work Item 62", or it might say "Team meeting to finish Task generation for Work Item 62". Other ways of writing these Tasks include "Research...", "Solve..." or "Discuss...". Everyone needs to recognize that these tasks represent risk and uncertainty about how to get the work of the iteration complete.
Sometimes work needs to be done that is outside of the control of the Team. The Team should always try to find creative solutions to avoid this situation, but it is almost inevitable that Tasks will come up for which the Team does not have the expertise or the authority. These Tasks need to be treated very carefully since they can seriously hinder a Team's forward progress. The Process Facilitator should usually consider these Tasks as obstacles to be removed.
Working on Tasks
Typically, a single person takes responsibility for a single Task at a time. A person may end up working on other tasks for two reasons. First, if the Task he/she is responsible for has an unavoidable wait, then that person may go find someone else to assist until the Task is ready to be worked on again. Secondly, another person may have an urgent need for assistance and call other people away from their current Tasks.
Tracking the Work
In their most basic form, Tasks are assumed to all be roughly the same size or effort and small enough that they are only done or not-done. Therefore, tracking the work on the Tasks throughout the course of the iteration is kept very simple: how many tasks are remaining to complete in the remaining time of the iteration? There is no ambiguity: Team members report on completion of tasks to the Process Facilitator who updates a burndown chart to show the quantity of remaining work.
Gotcha's
Tasks must be written to avoid including wait time. For example, a Task that says "Get the parts delivered" actually includes three steps: make the request for the parts, wait for the parts to be delivered, receive the parts. Since it is often hard to predict how long a "wait" will be, it is important to break this down into two separate tasks: "order the parts" and "receive the parts" and then treat the wait time as an obstacle to be removed/minimized.
Posted by Mishkin Berteig at 09:34 AM | |
June 13, 2006
Fantasy Estimation
In software development (and in many other types of projects), there is a typical non-agile approach to estimation of project size. This method starts with a high-level understanding of the work to be done, the requirements, and uses that to make an initial estimate of the project size. This estimate is often stated in units such as man-months. There is a very important piece missing here that makes this estimate completely useless... that makes it pure fantasy.
The Team
Any estimate made by anyone other than the team doing the work is useless. For any sort of project, software or otherwise, estimates made by a project manager or leader on behalf of an existing, or, even worse, a non-existant team, must be subject to the highest degree of scepticism.
Team Maturity
Not only does the team need to make the estimates for its own work, but the team must be mature! If the team is newly-formed, the team members will have no sense of the team's capacity other than their own individual capacity.
Work History
Not only must the team be mature to make reasonable estimates, it must have a recorded history of their own work capacity in order to be able to estimate their capacity to do work in the future. If there is no record of their capacity, then the usual factors of optimism will be unaccounted for, and the team will almost always over-estimate its capacity.
Knowledge of Domain and Tools
Not only must the team use a recorded measure of their capacity, but they also must be experienced with and knowledgeable of both the subject of the work and the tools they will do to perform the work in order to come up with a reasonable estimate of a project's size. If they need to learn about the project and how to execute it, then again, the team will almost always over-estimate its capacity.
Fantasy
If someone gives you an estimate for project duration, ask them the following questions:
1. Was this estimate made by the team which will actually be doing the work?
2. How long has this team worked together?
3. Has this team measured their own actual capacity and used that measurement for this estimate?
4. How well does the team know the domain and tools to be used?
If the answers to these questions are unsatisfactory, then the estimate is pure fantasy, it is a lie.
Posted by Mishkin Berteig at 09:06 AM | |
June 06, 2006
Agile Work Artifacts - the Work Queue
Agile Work requires only a very small number of simple "artifacts". The most basic is the Work Queue. This is very similar to the Scrum Product Backlog but there are some differences too. The Work Queue is like a carefully managed To-Do list. This article details the use of the Work Queue.
Basic Description
The Work Queue is a list of work to be done by a person, team, organization or community. The list consists of brief descriptions of what to deliver, not how to do it. The list is prioritized so that the item on the top of the list is the single most important thing to get done, with items below that being successively lower priority. All items on the Work Queue contribute directly to an overall goal. The person holding the Product Owner role manages the list.
Place in the Process
The place of the Work Queue in the process is very simple. The Work Queue is initially created after the overall goal is determined. Ideally, it is created before work towards the goal is started, but often Agile Work will be adopted for an ongoing effort, in which case work has already started. The Work Queue is constantly maintained by the Queue Master so that it maintains the above mentioned qualities. One or more of the items from the top of the Work Queue are selected to be worked on. As an item on the list is completed, it is removed from the Work Queue. The number of items on the list that are being worked on simultaneously will depend on the capacity of the people doing the work. If iterations are being used to plan work, then the Work Queue is updated every iteration.
How is it Created/Managed
The Product Owner is responsible for creating and managing the Work Queue.
The initial creation of this Work Queue is a simple process: based on the goals to be attained, and based on an other factors that are relevent, the Product Owner drafts an initial version of the Work Queue. The time spent on creating this initial version should be minimized using three techniques:
1. Keep the Work Queue small by recording only high priority items that need to be done immediately. Don't add items that are uncertain or will be done far in the future. (See "The Horizon of Predictability" for more information about this.)
2. Keep the Work Queue simple by focusing on point-form high-level descriptions of the items in the list. Don't worry about any details about how the item will be accomplished, who will do it, when it will be done, dependencies with other items, or technical or conditional details.
3. In advance, allocate a fixed amount of time to draft the Work Queue... and don't spend any more time on it than that. Get the assistance of the Process Facilitator to keep on track. The list doesn't have to be perfect or complete... you only need enough on the list to allow the work to start.
Ongoing management of the Work Queue consists of removing completed items or items that are no longer needed, adding new items as they are discovered, merging or splitting items as more is learned about them, and reprioritizing items. All of these tasks can be performed at any time. As well, the Work Queue should always be in a state of readiness such that the top items are ready to be selected for work.
The Product Owner is responsible for answering any questions that may arise about the work as it is progressing. If someone doesn't know what is meant by an item, then work on that item should halt until the Product Owner can clarify.
At no time is the Work Queue "frozen" or finalized. It is changing throughout the entire time that people are working towards the goal. Items that are completed are removed from the list, and do not need to be archived or recorded anywhere else, nor is it necessary to save versions of the list as it is changed.
Gating/Queuing
The Work Queue is a queue of work in process (WIP) that is built up in front of the people who are doing the work. As such, it is advisable to keep the list short. The Product Owner acts as a gate to the list: only those things that reasonably contribute to the goal and which are relatively immanent in implementation should be added to the Work Queue. If someone suggests something be added to the Work Queue, the Product Owner must, of course, take that under advisement and collaborate with the suggestor, but is not obligated to add the suggestion to the list.
The Product Owner can manage the size of the Work Queue by deciding how many iterations of future work are allowed on it. In other words, the number of items on the Work Queue is limited to how many can be accomplished in a fixed number of iterations. As the Team takes a number of items off the Work Queue, space is freed to add an equivalent amount of work back onto the Work Queue. The specific number of iterations chosen for this will vary depending on your circumstances.
Differences from the Scrum Product Backlog
The Work Queue does not require two things that are part of the Scrum Product Backlog: item estimates and item values. Adding this information to the Work Queue can be useful in many situations, but is not an essential part of the list.
As well, the management of the Work Queue is different from the Scrum Product Backlog in that the Product Owner is not obligated to put every suggestion that comes their way onto the list.
Advanced Use of the Work Queue
Consider adding the following information to each item on the list:
1. An estimate of effort. Make sure that these estimates are created by the whole group of people who will be doing the work.
2. An estimate of value. The Product Owner needs to be responsible for determining value, but the whole group of people doing the work and all the other stakeholders need to understand how that value was determined.
3. Cycle time tracking. When an item is added to the list, record the date/time it is added, then record the the date/time it is completed and removed from the list. The use of cycle time can assist in making a work process more efficient.
Posted by Mishkin Berteig at 04:24 PM | |
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 | |
April 21, 2006
Agile Adoption Stages for Teams
We know that teams go through identifiable stages of development: forming, storming, norming and performing (1). What exactly does this look like for an Agile team?
Forming
Here the team is typically innundated with three sources of new information: the Agile process and practices, the nature of the project and the other people in the team. This can be overwhelming and people will react in diverse ways: calm wait-and-see, rebelliousness, passive-aggressive, excitement, etc. If the team has an effective coach or mentor shepherding them through this, then feelings will tend towards excitement. The reality of learning so much at the same time will make the first few weeks of the team's time together quite exhausting. People will be actively fighting old habits, and people around the team will be asking lots of questions. Retrospectives will usually show that the team is impressed with their own teamwork and communication and will also show some disappointment with specific agile work practices.
Storming
After only one or two iterations, the team will transition into the Storming stage of development. Because Agile methods "front-load" the learning and the crisis, this forming stage comes fast, but it is also relatively mild. (Front-loading the learning means that all the problems that an organization has that hold it back from delivering quality work quickly are made visible in the first couple of iterations.) People are not used to a project being in crisis right at the start. It is critical for a coach or mentor or manager to be aware of this effect and expecting it. Again, for emphasis: an Agile project is in crisis immediately!... and this is perfectly normal and healthy. If the organization and the team are able to find means of dealing with this early crisis, then the project will continue and build larger and larger successes. On the other hand, if the organization or the team try to ignore or hide the problems, then very quickly work will revert to the old way: bureaucracy or chaos.
Norming
After about four to eight iterations, the team will reach a fairly comfortable place: the basic agile processes and practices are understood, the organization and the team have removed some basic obstacles to getting work done (and consciously left some obstacles in place in all likelihood), and everyone on the team has a basic level of comfort with their role. The challenge at this stage is to avoid falling into the trap of complacency. Although comfortable, this level of performance is probably not all that much better than the old way. There will be real advantages: regular delivery of work, good communication between stakeholders and the team. But there will be many obstacles still to be removed, and the team has a long way to go in its development. If the team becomes complacent, then it is critical that a catalyst be introduced to incite the team to further development. Often, this can be as simple as a systematic and intensive program of capability building. As team members learn and practice new skills: process skills, technical skills, people skills, strategic skills, business skills... and as they become more and more aware of each other's capabilities, they will also become more and more aware of areas for improvement. Incentives need to be provided to help team members focus dilligently on self-improvement and team improvement. The iteration retrospectives become critical to help with this process... the tricky bit is that this is the stage when people start to think the retrospectives are no longer necessary!
Performing
The transition into the Performing stage for an agile team is gradual and happens over a fairly extended period of time. The definition of "getting to done" will gradually expand to allow the team to go from zero to full delivery of the end results every single iteration. There will be a temptation to split up the team and use these experienced team members to seed new agile teams - resist this temptation! Breaking up the team at this point destroys the value of time and effort invested in the team. It is much more effective to start a new team from scratch. The essence of a performing agile team is not the transferrable knowledge about agile processes and practices. Rather, the most important result of the team-building process combined with the agile process is the team itself.
Posted by Mishkin Berteig at 11:57 PM | |
April 20, 2006
An Introduction to General Systems Thinking
I recently completed reading An Introduction to General Systems Thinking
The Subject
This book is about science, philosophy, behavior, organizations, organisms, problems, solutions, faith, reason, and everything in between. Specifically, it is about a general approach to dealing with systems given the limitations of our human abilities.
The Ideas
One of the strongest ideas in the whole book is that there is a class of systems for which we have only very poor tools to understand them. These systems, which he calls "organized complexity" are contrasted to "organized simplicity (machines)" and "unorganized complexity (aggregates)". Machines can be dealt with purely analytically and in a deterministic manner. Aggregates can be dealt with statistically. Systems that are in the organized complexity category are too complex for a purely analytical approach but too simple for a reasonable statistical analysis. The book is focused on methods for dealing with this class of systems.
The Writing
Mr. Weinberg's writing is, first and foremost, engaging. He writes in an informal voice that is a wonderful complement to the subject matter. Even with the informal tone, he is nevertheless able to communicate some tricky ideas with a great deal of precision and clarity. His use of examples, diagrams, stories and quotes throughout the book is excellent. Although I did not do the exercises he includes, upon reading them, I was satisfied to see that they are all interesting. Since I intend to re-read the book in six months or so, I will also publicly commit to doing a good chunck of the exercises too. Maybe you'll see some of my efforts here since many of them are apropos to Agile Work.
How Does This Apply to Agile Work?
Much of the emphasis in agile methods is on the intractability of building a perfect plan for a set of work (particularly in software projects). The group of human beings that are building something is in itself a system of "organized complexity". As a result, it is impossible to treat that group of people as a system that can be made to work in a deterministic manner. We simply can't account for all the variables. At the same time, we would like to have a lot more certainty about the behavior of the group than we could just using statistical methods. (Check out Systematic HR for some related articles.) Agile methods help us find this middle way that gives us a very good shot at reaching our goals, but acknowledges our inability to determine precisely how we'll get there. A good understanding of Systems Thinking helps us comprehend the necessity and applicability of agile methods.
The Table of Contents
The chapter and section titles of this book tell a great deal about the scope of the work. I have reproduced the table of contents here for your reference.
Chapter 1 The Problem
- The complexity of the World
- Mechanism and Mechanics
- The Square Law of Computation
- The Simplificiation of Science and the Science of Simplification
- Statistical Mechanics and the Law of Large Numbers
- The Law of Medium Numbers
Chapter 2 The Approach
- Organism, Analogy, and Vitalism
- The Scientist and His Categories
- The Main Article of General Systems Faith
- The Nature of General Systems Laws
- Varieties of Systems Thinking
Chapter 3 System and Illusion
- A System Is a Way of Looking at the World
- Absolute and Relative Thinking
- A System is a Set
- Observers and Observations
- The Principle of Indifference
Chapter 4 Interpreting Observations
- States
- The Eye-Brain Law
- The Generalized Thermodynamic Law
- Functional Notation and Reductionist Thought
- Incompleteness and Overcompleteness
- The Generalized Law of Complementarity
Chapter 5 Breaking Down Observations
- The Metaphors of Science
- Boundaries and Things
- Qualities and the Principle of Invariance
- Partitions
- The Strong Connection Law
Chapter 6 Describing Behavior
- Simulation - The White Box
- State Spaces
- Time as a Standard of Behavior
- Behavior in Open Systems
- The Principle of Indeterminability
Chapter 7 Some Systems Questions
- The Systems Triumvirate
- Stability
- Survival
- Identity
- Regulation and Adaptation
- The Used Car Law
Also, check it out, Mr. Weinberg has started a blog on writing fiction. He also helps run the AYE Conference (amplifying your effectiveness).
Posted by Mishkin Berteig at 05:18 PM | |
April 13, 2006
Agile Management is Servant-Leadership
Agile Work holds that process improvements are most effectively planned by those who perform the work. So, what happens to the manager role when we empower teams to self-organize? I recently turned up this old email, outlining how Scrum, an Agile project management method, reframes management responsibilities...
Wanted: Cat Herder
One of the methodologies in which I am trained, and which I teach to others is Scrum Project Management. The team lead in this approach is called the "ScrumMaster" (tongue firmly in cheek) or sometimes referred to as "the sheepdog" because he or she must care for the team, keeping out intruders and distractions. At the beginning, some folks have a hard time wrapping their mind around this role, because it feels to them like the old Project Manager role, but with strange twists. Here is an excerpt from an email conversation with an apprentice, in which we discuss how the ScrumMaster can be accountable without having authority. It starts with something written by the co-creator of Scrum, Ken Schwaber:
> Subject: Day in the life of a Scrum Master, according to Ken
>
> 1. Ensure everyone is doing what they have agreed to do;
>
> 2. Determine where this iteration is compared to where it could be
> and update your work-remaining tracker ( & task board, if used);
>
> 3. Work the product backlog (list of work for next iterations);
>
> 4. A dead Sheepdog is a useless Sheepdog; and,
>
> 5. Use all of your senses, including common sense, and remember
> that you have no authority.
>
> (from the CSM methodology v5)
after which the apprentice asked:
> No authority sounds rather scary!...in what context?:)
My reply:
The Team is FULLY responsible for the outcome of the work, the product, what is demonstrated to the Customer at the end of the iteration. It is in this context that the ScrumMaster is not a performer, and has no authority (i.e. to say 'we should do this' or 'here's how to approach it' or 'you missed that'.) The ScrumMaster must keep the team aware of this fact, so they have motivation to solve problems themselves in a 'whole team' manner, and not a CYA manner.
How to deal with this? Try 'I've noticed...', 'have you missed that?', 'I have an idea - what do you think?' 'It's up to you', or asking an OPEN question: 'I've noticed we have Requirements in 5 places. Do we need all of these?' At first people find this threatening, assuming I am passive aggressively saying we DON'T need these. No, it really is an open question, and you can assert that all you want, but the best way is to show it - ask them and REALLY let them tell you - no answer is wrong. For example: During the Requirements discussion, I saw BL tense up when another team member asked "do we really need to write JUnit tests?" So I asked "BL, what do we lose if we get rid of them?" and from his answer, the questioner quickly realized that quality and thrashing is at stake, and the issue died right there. Now that they have discussed it THEMSELVES they will hopefully continue to manage that issue themselves. If not, another question may be in order.
The ScrumMaster is the remover of obstacles (looking ahead, taking them out of the way, but not too far ahead in case of YAGNI: you ain't gonna need it). This includes getting things ready for the team, in time: room, needed materials and tools (computer, markers, paper, whiteboards, chocolate, DBA, lunch, meeting rooms, onboarding etc.) This is why the ScrumMaster should start work before the team, so they can hit the ground running.
The ScrumMaster is responsible for facilitation (getting people to play nicely together - oh my gosh, is this a challenge some days!! :-) But it is also rewarding, when you look and everyone is quietly collaborating and putting their best skills into the work.
The ScrumMaster is responsible for having the big picture (not of the work itself - the team is responsible for that) but the big picture of the Working of the team - the process. This includes stakeholder relations: getting things off on the right foot and letting the team handle it from there.
The ScrumMaster IS responsible for herding the cats in the right general direction (have you seen that wonderful EDS video ad about cat herders? It's hilarious!
Thanks for the good question. Hope this is helpful, or raises more good questions.
ciao
deb
Posted by Deborah Hartmann at 09:20 PM | |
April 12, 2006
Follow the Principles and Adjust the Practices
In "Built to Last : Successful Habits of Visionary Companies
Follow the Principles
What exactly are the principles? The foundation starts with Trust and Truthfulness. "Truthfulness is the foundation of all human virtues." Everything we do with agile should be about truthfulness (visibility, transparency) and building trust.
With this as a strong foundation, we can look at the Agile Axioms:
We are Creators
Reality is Perceived
Change is Natural
All of the other principles and practices associated with Agile Work flow from these basic assumptions about the world. We can't prove that the above three axioms are "true". But they either resonate with us or they don't. If they do, then it will be easy to use these axioms as a checkpoint for all the activities we engage in using Agile Work, wherever we apply it.
We are creators... therefore we derive our sense of value from our ability to create. If our creations are accepted by others, our team, our stakeholders or our community, all the better. But fundamentally, this is inherent to us as human beings. However, sometimes this natural drive is suppressed or repressed. In order to activate it, we need to work in empowered teams.
Have you ever experienced inspiration or "flow" or joy when working with someone else? Perhaps you were solving a problem. Perhaps you were playing a musical instrument - jamming - and got into a fertile groove. Perhaps you were teaching your children and created the light of understanding in them. Perhaps you built a beautiful set of bookshelves for your home. Or maybe you told a joke that created a brief moment of genuine levity in a group of friends. We are all constantly creating!
This basic principle then means that Agile Work methods and practices should not be imposed. Taught to us, perhaps... given to us as a template, perhaps... but once we understand the practices and are familiar with them, we should immediately be given the freedom to use the learning cycle to be creative with the process and practices of Agile Work itself. If we do not participate in creation, we become dis-empowered and that eventually leads to resentment or apathy.
Reality is perceived... therefore we need to work hard to build a common perception of reality if we are to work together effectively. We need to amplify our learning. We can't assume that our own understanding of a situation is going to be shared by others. At the very least we need to check: "do you see this?"
Let's recognize that in some way or another we are all blind:
Again, the learning cycle comes into play. The guidance, detachment, love, courage and search we go through all help us to build a common understanding of reality. This allows us to see new ways to apply the Agile Work principles and practices that make sense not only to our context, but also to everyone else participating in the work.
Change is natural... therefore instead of fighting change, we need to anticipate it, adjust to it, embrace it, and be gracious or even enthusiastic. Not only does change happen to us, but we also instigate change. If things get to boring, whatever the circumstance, we find ways to change things. We rebel at stasis and ennui.
Each practice and procedure done in the context of Agile Work must be explicity and implicitly accomodating of change. If a procedure can't tolerate change it will either lead to a dissonance or conflict... or if we are embracing change, then we will modify or discard the procedure. Our creative nature loves to create, but if we become too attached, too "in love" with our creations, we will support them past their point of relevance.
Our latest greatest idea will be good for a while. But eventually change will make it irrelevent.
So we see that all three Agile Axioms are also interrelated.
Our creations will be washed away through change and if we are lucky or wise we will perceive the change in reality - be truthful to ourselves and others - and allow a new creation to take the place of the old one.
When we perceive a certain truth, and try to share that with others, we will be asking those others to change their own perceptions. This change can be difficult and may even require the destruction of a mental model created with love and care over a lifetime. Sensitivity to this loss and encouragement to build a new creation will help build a shared perception... as long as we too are open to new perceptions!
Adjust the Practices
And of course, all this foundation of creation, perception and change must be connected to the practical day-to-day reality of our lives. Our family lives, our work lives, our social lives, our volunteer lives, our intellectual lives, our emotional lives, our spiritual lives... our whole lives.
The Agile Work practices are simple to state:
Manage Ourselves
Deliver Frequently
Adapt our Plans
Communicate Powerfully
Test Everything
Measure Value
Remove Obstacles
These practices provide a starting point. A basic set of activities that will assist you, your team or your organization to advance quickly towards whatever goal you have set for yourselves. The way these practices succeed is by making sure that the Agile Axioms are always remembered and their implications accepted. These practices will set up a virtuous circle by building trust and allowing truthfulness. More trust and truthfulness will allow a fuller and more nuanced expression of the practices...
But if these practices become canonized, if they become a rote process imposed and followed blindly, then it means that we have lost sight of the Axioms. We have forgotten to check our practices against the context of creation, perception and change.
The reason we follow these practices is because we believe that we are all creators, that we can learn from our diverse perception of reality and that change is a force of growth. We don't believe these Axioms because we blindly perform these practices.
This is all available as a nicely formatted pdf: Agile Axioms - a Brief Exposition.
Posted by Mishkin Berteig at 01:45 AM | |
March 31, 2006
How the Process Facilitator can Help the Team Handle Out-of-Scope Work Requests
Sometimes an agile team is innundated (or maybe just slightly distracted) by requests for individuals on the team to do work for people or groups outside the team's official stakeholders. This can happen, for example, in a corporate culture that promotes the exchange of favors. This past weekend at our Agile Coach's gathering, Deborah Hartmann shared her method of detecting, exposing and discouraging this unofficial work.
The mechanism is actually very simple: track the work in the team space using cards and a variation on the burndown chart.
The Cards:
During the team's status meeting, or any other time that a team member mentions doing some of this outside work, immediately request that that person write it down on a task card. The task card should be visibly distinct from normal task cards: either a different color or a different size or in a substantially different location. The task should also get an estimate in the same units you are using for the other tasks.
For each task identified, contact the person who requested the extra work. If the person who is doing the work has made a committment to the requestor then let the requestor know that the team has accepted the work but that there is a consequence: the team may not get all its other work done on time. As well, the requester should be informed that in the future, all extra work for individuals on the team must be prioritized by the team's product owner.
Encourage the team to reveal this work by mentioning it at the start of the status meeting, in any iteration planning or retrospective meetings, or in any one-on-one meetings you have with team members.
The Burndown Chart:
Now that all the extra work is reflected in cards with estimates, the burndown chart can track this work too. The key difference is that it is tracked as a separate part of the work. If there are 80 units of normal work remaining, and 20 units of this extra work remaining, then the burndown chart will have a mark at 20 and a mark at 100. The mark at 20 should be made in a different color (I recommend red) so that it is highly visible. One ends up with a burndown chart that looks something like this:
The Product Owner:
It doesn't take much more than a single iteration for the Product Owner to get the message loud and clear: this extra work is eating up the team's capacity! The Product Owner now sees the consequences of not being the go-to person for all work items.
Deb's experience with this was that by the next iteration there were no further requests of the team for unofficial work, and the team's capacity to do work for the Product Owner took a nice leap upwards.
Posted by Mishkin Berteig at 11:26 AM | |
March 20, 2006
Methods of Prioritization
In Jean Tabaka's new book, "Collaboration Explained : Facilitation Skills for Software Project Leaders
1) Round the Group prioritization:
group size 3-8
item list size < 15
Items are written on cards and placed in random order linearly either vertically or horizontally.
The members of the group each take turns placing the items in the order they think is the proper priority order. While doing so, each person moving the cards is welcome to explain their reasoning. However, the other group members refrain from commenting on the new prioritization.
This continues around the group as many times as it takes to find a stable order.
2) Ping Pong Balls:
group size 1-12
item list size > 15
(Thanks to Ken Schwaber for this method)
A fixed number of ping pong ball units are given to the group. The ping pong balls represent units of one dimension for prioritization such as value, risk or cost.
The group discusses how to allocate ping pong balls to each item in a dynamic fashion until everyone agrees that the allocation makes sense.
For very large lists, this is easiest to do in a spreadsheet with fewer people involved.
3) Variation: 2-stage multi-voting with voter freedom
group size 5-20
item list size < 50
This is identical to the public multi-voting system Jean describes with the following changes:
First, there is no restriction on how votes are allocated to items. A person can put multiple votes on a single item and can withhold some or all of her votes.
Second, after everyone has "finished" voting, the facilitator calls for everyone to step back and think about the results. Some discussion is allowed about the consequences of the results. Finally, everyone is given an opportunity to move their votes.
For large groups with large lists this can be somewhat awkward as people might forget where they voted. In this case, and if anonymity is not required, each person can use small post-it tabs with an identifying mark on them so that they can easily be moved around in the second stage.
Posted by Mishkin Berteig at 01:25 PM | |
March 14, 2006
Agile or Not Agile?
Every once in a while the del.icio.us tag for Agile turns up something really interesting. This evening, I found this article about the ongoing use of the term "Agile". The article is brief and a little weak, but it brings up a concern that is always niggling in the back of my mind. Interestingly enough, a good friend of mine, Christian Gruber, emailed me another web page of similar import...
In this registration page for Rules of Enterprise Agility, we read about something that really has nothing to do with the Agile Manifesto, nor the Agile Axioms.
Both of these examples are signs of two things:
1. The growing popularity of the term "Agile".
2. The growing dilution of the meaning of the term.
How can we fight this? Should we fight this?
I think it is very important to constantly call attention to the fact that Agile is about the minimum process and tools that can possibly work, and only in the context of valuing individuals, interactions and teams more than those tools and processes.
Trust is the Foundation of Agile Work
Technology, tools, process, even good ideas and good organizations do not create trust. People create trust by being trustworthy: honoring their commitments, striving for excellence, truthfulness, courage. One of the fundamental problems afflicting organizations is the lack of trust: between management and employees, between business and IT, between experts of various sorts, between coworkers.
This lack of trust is institutionalized in many ways including bureaucracy and legal frameworks.
The only way to change this state of affairs is to build trust. And the only way to build trust is to embody trustworthiness in yourself so that by example and by your words you can help others to become more trustworthy.
Agile methods put in place mechanisms that assist in building trust. But those mechanisms are merely a means to an end. Let us never forget that.
Posted by Mishkin Berteig at 12:27 AM | |
March 12, 2006
Work Item Backlogs as Queues - Agile vs. Lean
A recent discussion on the Scrum Development list (Start of Discussion) provides a good follow up to my parting words in The Art of Obstacle Removal about agile practices themselves becoming obstacles. I have excerpted a small amount of the discussion and added my own comments here.
In the agile community, most of us have bought into and adopted the Agile mental model. But that mental model has assumptions embedded into that may not be correct under all circumstances. Part of that mental model includes the efficacy of the work item backlog as a tool for tracking, prioritizing and communicating work to be done in the future.
I will be the first to say that Agile is far better than waterfall in almost every situation (the exception being the mythical project with stable requirements, business environment, technology and team).
That said, let's look at backlogs from another perspective: if a backlog was the only thing you delivered to the customer, would they pay for it? If you spent even just a few hours coaching a business representative to build a backlog, but there was no team to implment it, would that person really find value in the backlog itself? Would they be able to deliver ROI just from a backlog? I think the answer is a clear "no".
That set of questions may seem silly, but from a lean perspective, they are among the most important questions. Is an artifact/process value-added or non-value-added?
Since the backlog is clearly not a value added artifact/process (pause for effect)... it is waste!
When one is doing agile effectively, the backlog may in fact be one of the larger sources of waste! If the team has a stable velocity, there will come a point when the backlog becomes the constraint on the overall cycle time going from idea to ROI. If the backlog is large/long, and as Mary Poppendieck said if there is more than ...maybe two or three
sprints of work.... in there, then it may be time to find ways of constraining the size of the backlog. I have two suggestions:
Capacity of Team(s):
Find a way to increase the capacity of the team so that the backlog size reduces and then goes into a steady state. This may mean augmenting the staff.
Gate Backlog Items by ROI
(This is just theory to me at this point.) Make it a condition that all backlog items must have a positive ROI. In other words, the cost of building the backlog item needs to be less than the value delivered, taking into account time value of money. Don't let items onto the backlog unless this positive ROI can be demonstrated.
I believe the lack of this second discipline (assigning ROI to work items) is one of the main reasons that most agile methods such as Scrum allow an unlimited backlog size: there is no realistic way to gate the work that gets onto the backlog!
Until teams get to Agile nirvana (stable velocity, continuous delivery of business value, high-performance cohesive teams), having an unlimited backlog seems like a very reasonable thing: it's not the constraint or the primary source of waste. However, eventually the backlog will become a primary source of waste and it needs to be treated in a disciplined manner.
With a stable and well-functioning team, what other ways might there be to reduce the size of the backlog so that cycle time is substantially reduced?
Posted by Mishkin Berteig at 03:31 PM | |
March 10, 2006
The Art of Obstacle Removal
One of the best ways to go faster is to remove the things that slow you down. This "obstacle removal" is an integral part of many agile methods including Scrum and Lean. Sometimes it is obvious where an obstacle is. There are a few small things that can be done easily to go faster. But to get going really fast, we need to have a deeper understanding of obstacles... and the Art of Obstacle Removal.
What are Obstacles?
An obstacle is any behavior, physical arrangement, procedure or checkpoint that makes getting work done slower without adding any actual contribution to the work. Activities that do add value to our work may be slowed down by obstacles, but are not obstacles in and of themselves.
Obstacles and Waste
Obstacles are the causes of waste in a process. There are many types of waste, and for every type of waste there are many possible sources (obstacles).
Types of Obstacles
Personal
Personal obstacles are related to us as individuals. There are several levels at which these obstacles can show up.
Outside factors in our lives such as illness or family obligations can become obstacles to our work at hand. These obstacles are hard to remove or avoid. Even if we would want to avoid an obstacle such as illness, it is hard to do anything about it in an immediate sense. However, as part of our committment to the group we are working with, we should consider doing things to generally improve our health. Good sleep, healthy and moderate eating, exercise and avoidance of illness-causing things and circumstances are all possible commitments we can make to the group. Likewise, we can make sure our personal affairs are in order so that unexpected events have the least impact possible. This topic is vast and there are many good sources of information.
Physical Environment
Obstacles in the physical environment can consist of barriers to movement or communication, or a lack of adequate physical resources. Sometimes these obstacles are easy to see because their effects are immediate. For example, if a team room lacks a whiteboard for diagrams, keeping notes, etc., then the team may not be able to communicate as effectively.
Other physical obstacles are not so obvious. The effects of physical environment can be subtle and not well-understood. Poor ergonomics take weeks, months or years for their effects to be felt... but it is inevitable. A too-small team room can lead to a feeling of being cooped up and desperation to get out... and eventually to resentment. Again this can take weeks or months.
Here are some guidelines on a good team room.
Knowledge
A lack of knowledge or the inability to access information are obstacles. A team composed of junior people who don't have diverse experience and who don't have a good knowledge of the work they are doing will have trouble working effectively. There may be barriers preventing the team from learning. Common barriers include over-work leading to a lack of time or mental energy for learning. With junior people in particular, there is a lot of pressure to be productive and that can often be at the expense of a solid foundation of learning.
Other times, knowledge-related barriers can be more immediate. If a critical piece of information is delayed or lost this can have a large impact on an Agile team that is working in short cycles. The team may be temporarily halted while they wait for information. Building effective information flow is critical to a team's performance.
Organizational
One of the best sources of information about this is the two books by Jim Collins: "Good to Great" (Review) and "Built to Last" (Review).
Cultural
In organizational culture, one thing I constantly see is a public espoused value of teamwork, but a conflicting behavior of individual performance reviews and ranking. This is cultural. It is also a barrier to the effective functioning of an Agile team. For corporate environments I highly recommend the Corporate Culture Survival Guide by Edgar Schein.
Dis-Unity
Dis-unity is one of the most subtle and common forms of obstacle. Competition, legal and cultural assumption of the goodness of "opposition" and habits of interaction including gossip and backbiting all combine to make united action and thought very difficult.
This is an extremely deep topic. There are many tools and techniques available to assist with team building. If you are interested in this topic, I highly recommend reading "The Prosperity of Humankind".
Removing Obstacles
The ability to identify obstacles and understand why they are causing problems is only the first step in removing obstacles. In Agile Work, the person primarily responsible for identifying and removing obstacles is the Process Facilitator. The Process Facilitator has several approaches available for the removal of obstacles. A process facilitator has similar responsibilities to a change agent.
Direct
Deal with the obstacle directly without involving other people. This can be as simple as getting up and moving an obstacle impairing vision, or as nuanced as running interviews and workshops throughout an organization to gradually change a cultural obstacle.
Command and Control
Identify the obstacle and give precise instructions for its removal to a person who will directly perform the removal. This can sometimes work if removing an obstacle takes a great deal of time, effort or specialized skills that you yourself do not posess. However, the overall approach of "command and control" is not recommended for Agile environments since it is disempowering.
Influence
Identify the obstacle and suggest means to deal with it to a person who has the authority or influence to get others to deal with it. This indirect method of obstacle removal can be slow and frustrating. However it usually has better long-term effects than command and control.
Support
Offer to assist and encourage the removal of obstacles that have been identified by other people. In many respects this is a very effective method. It can assist with team-building and learning by example. People are usually grateful for assistance.
Coaching
Train others on the art of obstacle removal including obstacle identification, types of obstacles and strategies for dealing with obstacles. Observe people's attempts to remove obstacles and give them feedback on their actions.
Creating a Culture of Obstacle Removal
Encourage and measure obstacle removal at all organizational levels until it becomes habitual. In many ways this is the essense of the lean organization.
Strategies for Dealing with Obstacles
Diagrams are a great way of communicating the essense of a concept. Feel free to share the following diagrams with anyone (but of course keep the copyright notice on them).
Remove
Remove the obstacle altogether. This method of dealing with an obstacle is usually the most immediately effective, but is also one of the most difficult methods.
The best way to actually remove an obstacle is to get at the root cause of the obstacle and change that. This type of change results in the longest-lasting and most stable elimination of an obstacle.
Move Aside
Take the obstacle and put it in a place or situation where it is no longer in the path of the team.
In a team's physical environment, this may be as simple as changing the tools that the team is using. For example, if the team is all in a room together, move computer monitors that are blocking team member's views of each other. If there is a useless checkpoint that work results have to go through, get management to eliminate it.
Shield
Build a shield or barrier to hide the obstacle so that it's effects no longer touch your team.
If a team is distracted by noisy neighbors, put up a sound barrier. If a team is unable to see their computers due to late afternoon sunlight, put up window shades. If a manager is bothering the team with meetings or tasks unrelated to the work of the team, then put yourself between the team and the manager (or get someone in upper management to do that).
Shielding is excellent for immediate relief, but remember that the obstacle is still there and may become a problem again if the shield cannot be maintained.
Transform
Change the structure or form of the obstacle so that it no longer affects effectiveness.
In general, this method requires a great deal of creativity and open-mindedness. This is one that works particularly well on people who are obstacles: convert them into friends of the team!
For example if the team needs approval of an expert who is not part of the team, this can cause extra work preparing documentation for this person and long delays while the expert revies the documents. If the expert becomes part of the team, then they are well-informed of the work being done and can give approval with very little overhead.
If done well, this can be a very long-lasting method of dealing with an obstacle. Make sure that the transformation is true and that it takes hold... and beware that the obstacle doesn't revert back to its old nature.
Counteract
Find an activity that negates the effects of the obstacle by boosting effectiveness in another area.
As a coach or Process Facilitator, this is what we spend our time in early in a team's adoption of Agile Work: we get them to work in the same room, use iterations and adaptive planning, we focus them on delivering work valued by the stakeholders as defined by the Product Owner. All these things are enhancing the team's ability to get work done without actually directly dealing with any obstacles.
Watch out for barriers avoided this way to come back and bite you later on.
Removing Obstacles and Learning
Organizational learning, as well as adult learning have a strong relationship to obstacle removal. Organizational learning can be either single-loop or double-loop learning. Adult learning can be either normal or transformative. We can approach obstacle removal from a surface level where we only deal with the immediate symptom, or we can work at a deeper level where we deal with the symptom and its chain of preceding causes. One effective method for examining the deeper causes is the 5-why's exercise.
Obstacles Inherent in Agile
Agile methods do not perfectly eliminate all obstacles. Some obstacles that are inherent in agile methods include overhead due to planning meetings at the start of iterations, the use of a dedicated process facilitator. As well, the use of iterations can become a barrier to certain types of work items: repeating items, investment in infrastructure, one-off tasks that are not directly related to the work at hand.
At some point, our teams will have matured to the point where agile methods are no longer necessary and we can pick and choose what parts of agile we use.
Go Forth and Demolish Obstacles!
As a Process Facilitator, coach, ScrumMaster, manager, change agent or stealth agile advocate, you have the ability and the knowledge to make a big difference in people's lives and in the success of the organizations they work within. Removing obstacles is one of the most important duties you have.
Do you have stories about obstacles you have removed or seen removed that have made a big difference? We would love the hear the anecdotal side of this as well!
Posted by Mishkin Berteig at 01:10 PM | |
March 07, 2006
Visualizing Agile Value
One of the most important benefits of Agile Work is the early and continuous delivery of value to stakeholders. When I am coaching or presenting on Agile Work, almost inevitably I draw a very simple diagram on a convenient whiteboard or flipchart that demonstrates this benefit and contrasts it to a big-bang, waterfall approach to work.
The horizontal axis is time and the vertical axis is dollars/euros/whatever. The blue line represents the value that the agile team is delivering to stakeholders at any moment in time. (To be precise, it is the instantaneous net-present-value delivered... and therefore the area under the curve represents the total value delivered.) The red line is a spike of value delivered at the end of a waterfall project. The grey horizontal line is the constant cost (opportunity cost should be factored in) of a cross-functional agile team.
We can see clearly that an Agile team delivers value continuously. However, the shape of the curve also indicates that most of the value is delivered early on. This is the result of having a backlog of work items that are prioritized primarily by value. The initial up-slope of the curve represents the agile team getting accustomed to the work (and each other) and speeding up as they do so.
The waterfall delivery of work has the big disadvantage that if for some reason the project doesn't get completed, you are left with nothing of value!
And here's another Bonus Quiz Question:
The point where the blue curve of value delivery crosses the grey line of the cost of the team is a very important point... what does it represent?
Posted by Mishkin Berteig at 01:41 PM | |
March 02, 2006
Five Signs of Trouble in an Iteration
During the course of an iteration, an agile team is able to track it's own progress through the use of burndown charts. The team and the process facilitator can use the burndown chart to watch for signs of trouble. As a coach, I find the following five burndown shapes are common indicators of trouble.
But let's first show the idealized "normal" burndown. This burndown shape shows that the team is on-track to get to done exactly at the end of the iteration. The work remaining has had a constant slope down through the course of the iteration.
Now the warning signs:
1. Too Much Work
In this burndown, the team sees that it has likely selected too much work for the iteration. The process facilitator and the product owner need to work with the team to decide how to change the scope so that the team can get done. One might be tempted to add people to the team to get the work done faster, but this is rarely successful.
2. Not Getting Done
Frequently, when a team is just starting out with agile work, it commits to slightly too much work. It is hard to detect this at the beginning of an iteration. Instead, it is only near the end of the iteration that it becomes apparent that the team isn't quite going to make it to done. The process facilitator must work with the team to determine the root causes of this and change things so it doesn't happen again.
3. Early Learning
When a team is starting the iteration, it can discover new things about the work it has committed to accomplishing. This can include dependencies, new tasks, extra components that need to be built, etc. This discovery process is normal, but needs to be monitored closely. If the burndown doesn't start going down again after about 15% of the iteration is over, then there is likely trouble brewing.
4. Unresolved Obstacles
Sometimes the team will run into an obstacle that will completely stop their progress. Although the process facilitator is responsible for dealing with obstacles, it may be impossible for an obstacle to be fixed quickly. If the team finds that all the work it committed to for the iteration is dependent on someone who is sick or on vacation, that can lead to an unresolvable dead halt. This may be an opportunity to cancel the iteration.
One interesting example of this was observed by a coach I work with frequently, Deborah Hartmann. She was away from her team for a few days and when she came back, she observed this "flatline" burndown. After poking around a little bit to try and find the obstacle, someone finally described what had happened. At the time of the flatline, a Vice President in the organization had come into the team's area, looked around, and loudly declared something to the effect of, "I don't know why you guys are doing this project. It's totally worthless!" Suffice it to say that the team was seriously demoralized. It wasn't a technical obstacle, it wasn't a procedural or bureaucratic obstacle, it wasn't even a cultural obstacle. It was just a serious blow to morale. Of course, to fix this, the actual sponsor of the project had to be brought in to assure the team that it was actually an important project and that there were people in the organization who needed the work that the team was doing.
5. Scope Creep
This last case is rarer for an agile team if the team and the product owner have been educated well about the rules. Nevertheless, it can happen. The product owner, or some other stakeholder, pushes the team to add scope to the iteration. The process facilitator is normally responsible for preventing this from happening. If despite this it does happen, the burndown chart makes the consequences of this scope creep.
Special Quiz Section!!!
What are the possible explanations for the following burndown shape? I have heard/experienced at least six different possible reasons. Leave your answers in the comments.
Update: at Agile Chronicles, there is a short article about this topic which mentions one more burndown chart pattern that is a bad sign: the "Late-Breaking Decline".
Posted by Mishkin Berteig at 01:34 PM | |
February 27, 2006
Organization Pitfall: Specialization and Cost Cutting
In a discussion with another coach earlier today, I described what I have observed is a common path that organizations take. A path that leads to stagnation and business failure.
The coach I was speaking to was my father, Garry Berteig. Among other things, he uses agile in his classrooms for class projects. He also has a great deal of experience with business and organizational administration.
Garry and I were talking about learning, energy and teams. We started to talk about the implications of agile teams for organizational cultures. At one of the organizations Garry has worked, the department he was working in suffered from substantial log-jams due to lack of resources to get specific types of work done.
Here is the common organizational pitfall: Specialization and Cost-Cutting.
1. The Organization Grows
Most businesses and other organizations start with an idea, a need or a person with an itch to do something different. With any small measure of success, the organization starts to grow. If it grows large enough, the people involved become specialists.
2. People Become Specialists
When a business grows large enough there is enough work to be done that it becomes natural for the business to hire specialists: people who are experts at a small part of the overall work of the business. This is allowed by the business having greater cash flow to hire more people. This also allows people to focus more and more on their favorite tasks since there will often be someone else who is better at the not-so-favorite tasks.
3. Specializations Become Canonized
As the organization continues to grow and as people become comfortable in their areas of specialization, there is a self-protective instinct that causes these specializations to become canonized in the organization's bureaucracy. Career paths, pay scales, management chains, centers of excellence, checks and balances, tracability, defined processes, handoffs, approvals, councils. It becomes difficult to step in and do someone else's job without stepping on toes or getting reprimanded.
4. Cost-Cutting Layoffs
The large organization with clearly defined roles and procedures becomes slow and inefficient. Inefficiency leads to higher expenses, lower profit margins and eventually even losses. The natural reaction of management is to try to reduce costs. Since people tend to be the most expensive part of most organizations, the natural place to look is to "do more with less" and lay off those who aren't really contributing that much to the bottom line. Multiple rounds of layoffs can occur until eventually, you are left with...
5. ...Fully Utilized Experts
Now the organization is operating at a somewhat more efficient pace by virtue of everyone being fully utilized at their particular role. People are busy 100% or more of regular working hours working on multiple projects or tasks or work streams. This is of course not terribly fun, but everyone keeps with it for fear of their jobs. Unfortunately it can't last long.
6. The Experts Leave/Get Sick
So when someone drops the ball in a fully-utilized cost-cut organization it is usually because they are sick of the environment either literally or otherwise. Anyone who is really an expert will likely find greener pastures and move on permanently. Anyone who is just barely holding on will eventually become exhausted and get sick.
7. Log-jam!
The work for the now-departed expert starts to pile up. There is no flex left in the system: no one can step in who isn't "authorized" and all the authorized people are already at 120% capacity. The system breaks down.
This patterns of organizational behavior is something I have personally observed and heard anecdotally from a number of other people. The end result is always the same: the organization ossifies into bureaucracy that may have seemed useful with the original large organization size, but has become constrictive with the post-layoff smaller size. (Actually, the bureaucracy was constrictive of the larger organization too.) The cause of this? A fundamental mis-understanding of people and organizations.
People are Creators, not resources that mechanistically perform work. Trust your people to find creative ways to do things. Only punish individuals for ethical lapses; don't punish the organization, nor punish people for honest mistakes. Instead, encourage experimentation, learning, individual initiative, creativity, role-breaking, role-playing and cross-training. Check out this brief discussion on generalizing specialists for a little more information.
Posted by Mishkin Berteig at 11:38 AM | |
February 03, 2006
What Management Wants
The recent discussion on the ScrumDevelopment list about the waterfall method & management control has finally pushed me, a lurker, to post my $0.02: I know what management wants... management wants transparency.
Management constantly struggles to figure out what the heck their company is actually DOING all the time, while also trying to figure out what the competition is doing, what customers want but can't articulate, whether or not they have the right organization and management structure to effectively execute, etc. They have to predict the future direction of our customers, and figure out how to steer the corporation so that it is best positioned to deliver value to our customers both today and in the future.
It's hard to get to where you want to go if you don't know where you are at. That's why they want transparency.
Or at least, that's what my Management Team wants. I know this because I've asked them. And when they can't articulate what it is that they want, I study them. I study their line of questioning. I study their decision making style.
This is what my Managers think (all the time):
Should we be developing this application at all? Can we buy or license a solution instead? Are we in the right business? Are there other ways to squeeze more out of our value chain? Competitor XYZ is repositioning itself -- what new threats and what new advantages are there of this shift?
Folks, what I'm trying to say is that your Management Team is simply another customer. People that meet customer needs are a more successful that people that don't.
Did you ever have a customer try to dictate Design Details to you? Of course. Did you accept what the customer said, or did you dig a little deeper and determine their true, hidden requirements, that they weren't able to articulate?
Treat "Management" the same way. Do they demand weekly schedule updates? Did you ever ask them why? Have you sat down with your Management Customer to find out what their needs are, and how you can best fulfill them?
Sure, my Management Team suffers from Dashboard-of-the-Month Syndrome, where they keep changing the format and content of the "1 page project snapshot" evey 4 weeks. I live with it, just like I live with the customer that we've all had that keeps changing their minds about what they want. It takes me just 5 minutes to fill out my dashboard, regardless of the format, because my manager's already know what's going on with my project.
We're Agile, right? So doesn't that mean we're all about delivering value in the face of uncertain requirements? ASK YOUR MANAGER WHAT HE REALLY WANTS. I don't have problems with my Management Team, because they always KNOW WHAT THEY WANT TO KNOW about my project. They don't know this through the Dashboards, I don't delay important updates until the next Stage-Gate meeting, or wait until the next Monthly Review to request additional resources. I make sure I know what is important to them and deliver exactly that.
Because of this, I've earned their trust, and they rarely micromanage. I never deliver what was promised, instead, I deliver what they need. Sound familiar?
When I've come across a pointy-haired middle manager that REALLY wants to control, again, I treat them just like any other customer. I observe them to determine what their real needs are.
Do they need to be in control, or do they need to APPEAR to be in control? If its appearance, then I can go ahead and get the key decisions agreed upon ahead of time, and run it through the middle manager for official approval, with the appropriate deference to the Alpha Male Manager.
Do they just want to be informed of bad news 24 hours before upper management, because they've been burned by the grapevine before and looked stupid when upper management knew more than they did? If so, then absolutely make sure they never look stupid because of you or your team.
Do they think that they are the Savior, and therefore I need to find a crisis that they can save us from? (Golly gee, there's this one vendor that we're just having a lot of trouble with, and I hate to ask with how busy you are and all, but I know that with your experience...)
Please don't take this as a cynical view of human behavior; I've managed to successfully work with some real jerks just by finding out what made them act like jerks, and finding ways to address their legitimate concerns and insecurities.
Watch. Listen. Then deliver value.
Pat Baird
pat_baird@hotmail.com
Posted by Guest at 12:42 PM | |
November 28, 2005
Agile Work and the PMBoK - Definition of "Project"
This is the first in a series of articles comparing Agile Work with the knowledge and practices "generally recognized as good practice on most projects most of the time" as described in the Project Management Body of Knowledge Third Edition (PMBoK) published by the Project Management Institute.
Definition of "Project"
The PMBoK starts out with a discussion of the question, "What is a project?" and immediately answers: "A project is a temporary endeavor undertaken to create a unique product, service or result." (page 5) The PMBoK then elaborates on the ideas of "temporary" and "unique product, service or result".
The PMBoK also contrasts projects with operational work. It states that "operations are ongoing and repetitive" (page 6) in contrast to projects. Further, the PMBoK states:
Projects are different because the project concludes when its specific objectives have been attained, while operations adopt a new set of objects and the work continues. (page 7)
Agile Work: Project or Operation or ...?
If we accept the definitions given by the PMBoK for project and operational work, then we can conclude that Agile Work divides a goal up into many small projects (iterative delivery), that are managed operationally (adaptive planning).
Do iterations really count as projects? According to the PMBoK, they do indeed! An iteration is certainly temporary as it is a time-constrained effort with a definite beginning and end. And an iteration also creates a unique product, service or result by delivering valuable results.
And do Agile Work endeavors really count as operational efforts? Again, according to the PMBoK, there is little doubt: Agile Work adopts a new set of objectives between each iteration. In fact, like operations, an Agile Work endeavor continues for exactly as long as it is valuable to the organization or sponsor.
The Roots of Agile: Software Development
Software development is often conceived as project-based work. However, there is much evidence and commentary to suggest that this is not really the case. A software product company like Microsoft, or a software development community like that associated with Linux, both work in a fashion that is much more like an operational model than a project model. The core value that these organizations deliver is rooted in the actual software they build... and they never stop building it (unless it turns out to be a market failure).
In the book "Software Craftsmanship: The New Imperative
The Value of Projects
To be clear: operations end when they stop delivering value, and projects end when they do deliver value. Project work is all non-value-added until the very end, whereas operational work is (as much as possible) all value-added.
The consequences of this are clear. Make projects as short as possible!!! If all the work of a project is NVA up until the delivery date, then in order to maximize value, we should be finding ways to make projects as short as possible, eliminating every last little bit of unecessary non-value-added work.
Agile Work, using iterative delivery and adaptive planning, describes a means to treat an endeavor as operational work and therefore as delivering value early, continually, and for as long as desired.
Posted by Mishkin Berteig at 02:45 PM | |
November 09, 2005
Agile Work Uses Lean Thinking - Empirical Process Control
This is Part 2 of a 3 part series.
Part 1
Part 3 - not posted yet :-)
Some work processes cannot be perfectly controlled nor perfectly defined. There may be non-linear interactions between steps in a process or there may be creative input from a human required. Processes with these qualities require empirical process control.
The basic attribute of empirical process control constitutes a continuous cycle of inspecting the process for correct operation and results and adapting the process as needed. A simple example of this is detecting impending failure of equipment by constantly monitoring the operation of that equipment. For Agile Work, the book Agile Software Development with Scrum provides an excellent chapter about this topic of Empirical Process Control.
In human processes like those to which Agile Work applies, the frequency of inspecting and adapting must match the needs of the process. Many projects occur in the context of constant change. This constant change makes long-term planning a wasteful effort. Rather, short-term planning with constant feedback provides a simple inspect and adapt cycle. This cycle can play out at different levels: daily for a team, monthly for a client of the team. The team inspects and adapts daily at the level of the tasks that it is performing. The client inspects and adapts monthly at the level of the team's actual delivered results.
Both lean and agile methods claim to increase both speed and quality. Many people believe that there are four constraints in a system that can be controlled: speed (or schedule, or time to market, or process cycle time), quality (number of defects), scope (how much functionality), and cost savings (how much to spend on the work). Frequently, management believes that one has to trade off between these four constraints; spend more money, get more scope; lower quality, go faster. But in fact, lean and agile strongly support the idea that as you increase quality, you also increase speed... you just have to do it right.
In Agile Work, increasing speed and quality is done in three ways. First, increase the frequency and quality of communication among team members so that errors are detected early or avoided altogether. Second, drive the work with the creation and execution of automated testing. No work is done without a test in place to check if it is done correctly. This constant testing means that work is always defect-free and therefore very little time/money is spent on fixing defects. Third, eliminate wasteful work steps or obstacles to performance of work. This last one is difficult to do an bears closer examination.
Wasteful work is done in every process, no matter how efficient. Lean tells us that there are several types of waste in a manufacturing process. Those types of waste have analogies in Agile Work. For example, documenting something you plan to do instead of just doing it is wasteful. Another example is waiting while someone completes work that you depend upon. Any step or task that does not add value to the final product of an effort is waste. This standard is very high and most organizations have about 80% of their efforts going into wasteful tasks. An organization that has done an initial cut of wasteful work might stand at about 50% waste. The leanest organizations, such as Toyota, stand at about 20% waste.
Agile work eliminates waste in the form of barriers or obstacles that come up when a team is trying to go fast. Sometimes this is in the form of waiting for another group to do something for the agile team... an outsourced request for service. Sometimes waste is in the form of corporate standards or policies around documentation of work. The Process Facilitator role in an agile team has responsibility for working with the team and others to help overcome these obstacles.
Posted by Mishkin Berteig at 02:08 PM | |
November 08, 2005
ScrumMaster Certification Course for Software Project Management
Berteig Consulting Inc. is offering a ScrumMaster Certification course on Dec. 28 and 29 in Toronto, ON. This course is focused on software and IT projects, but will cover many of the basic Agile Work principles and practices. This is always a slow time at work and if you have already used your vacation time, consider getting your employer to send you to this course.
Posted by Mishkin Berteig at 10:38 PM | |
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 | |
October 07, 2005
Agile Coach/Mentor Job Description (Process Facilitator)
Given the Agile Axioms and Disciplines then an agile coach or mentor should have some really specific experience and capabilities. This list constitutes a first attempt at a job description.
Experience:
- working in strictly timeboxed iterations with adaptive planning using some sort of prioritized work list
- working in a "test-driven" manner (e.g. writing a document for a client where the client specifies acceptance criteria)
- participating in frequent status meetings where the team members report to each other, commit to work and identify barriers
- building and maintaining big visible charts to show progress and status (e.g. the standard thermometer chart to show progress towards a numerical goal)
- fashioning appropriate tracking and performance metrics that encourage team work rather than individual competition
- helping other people to adopt and adapt all these practices
Capabilities:
- promoting collaboration in challenging circumstances
- searching for truth/a solution relentlessly
- honesty and trustworthiness
- a learning attitude (proactive and learning from mistakes)
- humility and assertiveness
- guiding people without controlling them
- detachment (ability to step out of a situation)
- an attitude of service without expecting recompense
- understanding of transformative learning
- conflict resolution as learning (not negotiation)
- encouraging creativity
Not Required:- technical experience related to the work of the team - the Agile Coach (process facilitator) should not be a performer on the team
- domain experience related to the goal of the work - the Agile Coach should not be a direct stakeholder in the results of the work
However, technical experience and domain experience can sometimes help...
Suggestions and ideas are greatly appreciated!
Posted by Mishkin Berteig at 12:33 PM | |
September 30, 2005
Agile Executive Blog
Pete Behrens has a very interesting and relatively new blog called Agile Executive. His recent entries have included thoughts about High Performance Teams, Executive Priorities, and some book reviews.
Posted by Mishkin Berteig at 12:07 PM | |
September 28, 2005
Agile Infrastructure Projects - Lessons Learned
I've worked as an agile coach on three infrastructure/maintenance projects in a row. One was a software/hardware upgrade, one was implementing agile for a defects/enhancements team, and my most recent was a data warehouse decommissioning project. In all cases, the interesting part for me was taking the basic principles of agile and applying them in a way that works when not doing new product development. Here are some lessons I've learned:
1. Figure out what is going to deliver value (usually cost savings). In the case of infrastructure projects, one is usually focused on cost savings. Find a way to tie your work items directly to cost savings. You need a good financial model to do this. Mary and Tom Poppendieck talk about this a little in their Lean Software Development book. In the decommissioning program, there was a very explicit dollar cost associated with disk space and cpu utilization. Every user/MB decommissioned saved a measurable amount of money. As well, it allowed us to easily prioritize our backlog.
2. Focus project/program organization more on Lean principles than agile. A good understanding of queuing theory will go a long way to helping with throughput. In a team doing defects/enhancements work, the small pieces lend themselves well to certain types of streaming through the team. Iterations are not necessary to chunck work. Instead, iterations become checkpoints solely for process reflection.
3. Technical infrastructure projects can benefit greatly from automation. Test automation including test generation can sometimes be possible. Automating parts of a regularly repeated process that is used for every work item can be extremely beneficial for increasing speed. In the case of the decommissioning effort where every database table needs to be considered separately and where they all go through the same process for decommisioning, there are many opportunities for automation. The project/program/team can invest in doing this automation to great benefit to NPV.
4. The basic axioms (We are Creators, Reality is Perceived, Change is Natural) and disciplines (Empower the Team, Amplify Learning, Eliminate Waste) still apply. Even though it is not "new" product development, the creativity of people is essential for problem solving, and finding ways to do the work faster. Stakeholders still need to have their perception of reality acknowledged, and the teams still has to do constant checking to make sure they are on track with that perception. And of course, things are always changing including priorities, our understanding of the work, resource availability etc. Having an empowered team makes short work of many obstacles, but that wouldn't happen without an explicit acknowledgement that we have to constantly be learning and eliminating waste. Teams get better and better at these disciplines over time.
I would be very interested to hear other peoples experiences with infractructural/operational projects.
Posted by Mishkin Berteig at 12:00 PM | |
September 26, 2005
Wideband Delphi Estimation Technique
Here's an excellent introductory article on the wideband delphi estimation technique. Typically wideband delphi is used to estimate software development efforts, but can be used in almost any domain of work. This method might be applied to estimating effort for items in a work list at either a project level or tasks in an iteration work list. The way it is described, it sounds fairly heavy-weight, potentially taking several hours for a relatively small list of work items. However, it is worthwhile for process facilitators and product owners to be aware of these sorts of methods if problems with estimating occur in a project team. The wideband delphi model is related to the Delphi method.
[Update 2007/05/24]
Agile Work and Scrum use a very different method of estimating work that has one very important and incredible property: people don't have to get better at estimating for them to get better at committing to work!
The basic idea can be thought of as "commitment velocity". The method here is to use an arbitrary unit of effort that the team applies to estimating all tasks relative to each other. At the start of an iteration, the team can use any collaborative method (including wideband delphi) to come up with estimates for tasks. The team sums up the estimates for all the work of the iteration. Then, at the end of the iteration the team looks at the estimates for all the remaining undone work (if any) and subtracts that from the start of iteration sum. This is the Commitment Velocity. Now on their next iteration, they do their estimation work again, relative to the tasks in the previous iteration. If the sum of the estimates is larger than the Commitment Velocity, then the team needs to de-scope or find more efficient solutions to their work. This process usually converges after only three iterations (assuming: constant team composition, constant iteration length).
This method is taught in detail in my Agile Project Management courses, and there is a little bit more information here: Planning vs. Commitment. The agile estimation method of Commitment Velocity is an application of the Central Limit Theorem from statistics.
[Update: 2007/09/11]
Wikipedia now has an article on Wideband Delphi. The article points out some interesting potential problems with the wideband delphi method including corruption of the group doing the estimation and suppression of minority opinions. I know that in my experience as a coach, I have seen numerous occasions of both types of problem with estimation processes. The fact that wideband delphi is susceptible to these problems is more a factor of the human side of things than the method itself.
Interestingly, the wideband delphi method of estimation is very similar to the "Planning Poker" method of estimation used in many agile and scrum project environments. This method is also covered in the Agile Project Management courses.
Other links to wideband delphi:
Wideband Delphi Estimation Process
The ProjectInitiation.com website has a wideband delphi worksheet (MS Word) available.
Project Estimation: Wideband Delphi
Posted by Mishkin Berteig at 12:40 AM | |
August 25, 2005
The Role of the Process Owner
The following is an edited version of a post to the Scrum Development Yahoo! group made by Dave Barrett (CSM) (used by permission):
The ScrumMaster (Process Owner) role itself doesn't automatically imply any degree of authority, although at times it does help when you need a little clout to clear some impediments or to negotiate with other departments. More than that, the ScrumMaster role does carry a responsibility to provide some leadership to the team. Even a self-organizing team needs leadership!So I would say that it helps if the ScrumMaster has a little bit of
seniority over the rest of the team, it also helps if the ScrumMaster
approaches the role as a coach and leader, rather than as a supervisor.On paper it looks like the ScrumMaster only has a few tasks:
1. Chair the Scrums, and make sure they happen each day. (The self-organizing team's regular status meetings.)
2. Chair the Sprint (Iteration) Review and Planning meetings.
3. Produce the burndown chart. (An information radiator used to indicate the amount of work left in the product work item list and in the iteration work item list.)
4. Do the team's "paperwork" - publish the Sprint Backlog (product work item list) once it has been set and so on.
5. Clear impediments brought up during the Scrums.In reality, the ScumMaster needs to do a lot of other things. There's all of the leadership stuff, keep the team happy, productive and motivated. There's the political aspect, keeping other groups and
departments happy and out of the team's hair. As the in-house "expert" on Scrum, you need to referee on points of procedure and theory. Often you need to champion Scrum within the organization.Really, I don't see a huge difference between the roles of Project Manager and Scrum Master. Semantics mostly. Project Manager almost seems to imply a "command and control" approach, Scrum thrives best
without that. I wouldn't make a junior programmer a project manager, nor would I make him a Scrum Master.
Posted by Mishkin Berteig at 09:32 AM | |
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 17, 2005
The Viable Systems Model
Agile Work is a system that can be created inside many types of organizations and work environments. I recently came across an interesting article about the viability of systems. The article describes an interesting recursive breakdown of systems into sub-systems of specific types. Over the course of the next few weeks, I will use this model to try to analyze Agile Work to see if it is viable.
Posted by Mishkin Berteig at 08:36 AM | |
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 a testing process in month nine. In theory, at the end of this testing process (month twelve), we are supposed to receive the software for use, and we should be able to receive the value it was supposed to offer. However, defects are found in testing, requiring some re-work. The software is delayed by a further three months, and we finally receive it. By the time we receive it, our competetors have defined new features, and we have to submit new feature requests, whose results will not be seen for several months.
So for the entire development process, we received no business value, and continued to pay. Fifteen months from first investment until we started to achieve results that could mean revenue from the system. At this point, the software is partially obsolete. This is quite similar to the manufacturing scenario above.
Lean and Agile Software Development
Agile and Lean software development practices change this process by delivering business value a little-bit at a time. In an Agile software project, the business specifies what the most important features are (in our case the ten business-critical ones). The team then begins working in small time-boxes - say, two to four weeks. In each time-box, the team works on a small but well-defined list of features taken from the top of the prioritized feature list that we specified. At the end of the time-box, those features that were worked on are delivered to a degree of quality that each of the delivered features would be suitable for use by the customer. The whole might not be ready, but any features worked-on would be complete and production-ready.
If the team can average about three features per month (about what they pulled off in the above example), then by month four, the team could deliver a piece of software that has all ten business-critical features ready for use. The whole might not be ready, but the customers could determine whether those ten were worth taking the software in its current state, and packaging it up and deploying it. Quite simply, the software may not be "done", but it's "done enough". Then the team can continue to roll-out less valueable features from the prioritized list.
Market and customer needs volatility
This becomes even more important when we consider the competition's changes. In the traditional example above, after fifteen months, additional features were required. These may have been discovered in month six. Traditionally, these could only be considered in month sixteen. In Agile and Lean software development, however, work on these changes could be started in month seven or sooner. So the business received value early, or "just-in-time", and they could get high-value changes "just-in-time".
Quality
Because testing is built-in to the process, the customer is able to validate the product at the end of every time-box, so there are no large batches of re-work. The only time large batches of rework are necessary are when large changes to the basic requirements are requested. And then, Agile does not resist the customer's desire to change, but recognizes it as an essential part of software delivery, and adapts to the changing consditions. As a result, the Agile and Lean methods are optimized to produce quality product in small increments, so quality doesn't suffer from customers or markets changing their minds.
Summary
Agile and Lean principles are very powerful, and allow for business value to be delivered sooner to end-customers. This allows for better quality and risk management. It also allows strategic and tactical decision-making by executives to be undertaken when such decisions are most needed - not six months too late.
Firms that embrace Lean and Agile development principles are beginning to see the competetive differentiation that Toyota saw vis-a-vis the rest of the automotive industry throughout the 70's and 80's. It is only in the last two decades that, after adopting Lean practices, Toyota's competitors have begun to close the gap. Agile software shops are beginning to achieve these same competetive gains. Those who don't adapt to just-in-time value delivery - who don't eliminate waste in their processes - will feel the results as their competitors take products and services to market far faster, and with more responsiveness to their customers.
"If you're not on the steam-roller, you're part of the asphalt." - Lighthouse Design, circa 1996.
Posted by Christian Gruber at 01:30 PM | | | TrackBack
August 11, 2005
Agile Work Roles
There are three simple roles in Agile Work. All other roles, titles, duties or responsibilities are not part of Agile Work.
The Process Facilitator is responsible for the process used by the team. Normally, the Process Facilitator role is held by a single person who does not have any other duties.
- Keeps the team on-track by gently reminding the team of the process rules, e.g. having a completed chunk of work at the end of the iteration
- Facilitates process improvements, usually by doing a process reflection between iterations
- Coaches and instructs the team and individuals on the Agile Work axioms, disciplines, practices and how to apply them
- Works closely with the Product Owner to ensure that the quality Work Item List is maintained
- Focus on the "Clear the Path" practice of removing obstacles
Here is a short statement on the Process Facilitator Role. And here is a Process Facilitator Job Description.
The Product Owner is responsible for working with stakeholders to develop the Work Item List and understanding, maintaining and prioritizing it. Normally, the Product Owner role is held by a single person who does not have any other duties.
- Responsible for working with the team when the team has questions about items in the Work Item List
- Makes on-demand/immediate decisions about priority and meaning of items in the Work Item List
Here is a short set of links and another description of the Product Owner Role.
The Team Members are responsible for organizing and executing the work they have committed to doing.
- Extend themselves beyond their field of specialization
- Volunteer for tasks to complete the work (no one on the team or outside the team assigns tasks)
- Responsible as a team for determining how to complete work and then completing it
This new set of roles, along with other agile practices and principles, often results in a huge shift in responsibility. Decision-making and accountability is transferred from managers to the team. This change can be very difficult for managers who are accustomed to direction, delegation, control. Instead, managers must become facilitators and enablers.
Posted by Mishkin Berteig at 10:03 PM | |
August 06, 2005
Generalizing Specialists
The term "generalizing specialists" has come to mean an individual who has a particular area of deep expertise but also has experience in a large number of other areas that may not be directly related to their core area. This type of person typically has strong talent in their specialty but also has a generally strong talent for learning new skills and ideas quickly. The origin of the term seems to be in the software industry referring to programmers who can do other software-development related tasks.
In self-organizing teams, a generalizing specialist is a more valuable team member than a pure specialist. The pure specialist often has an attitude that they should not need to do work outside their specialty. This can be destructive to the team's morale. On the other hand, the generalizing specialist is willing and able to learn new skills - to stretch as the needs of the team change. And since change is natural, this is an essential attitude for team members.
However, we are usually trained, and strongly encouraged to have a deep specialty. This approach to education and training is a natural consequence to the typical organizational model for work and society. Therefore, if a team is converting to agile work methods, people need to be coached to stretch themselves and learn new things. For some people, particularly those who already have multiple hobbies outside work, this is an easy transition to make. For others, it is a very difficult transition. In some extreme cases, this may call for the removal of someone from the team. (Note: I have never seen this myself and I only mention it with great reservation. I strongly feel that only those who could be called "ill" will be so incapable of changing their way of working. For other recalcitrants, it is usually a matter of motivation.)
Other terms that are similar to "generalizing specialist" include "craftsperson", "renaissance man", and "polymath".
Posted by Mishkin Berteig at 08:05 PM | |
August 04, 2005
Just In Case You Haven't Seen It Yet
There is a fantastic article about software productivity: http://www.joelonsoftware.com/articles/HighNotes.html. I love Joel's writing style, and this article in particular has important lessons for us all, regardless of our profession: find what you can be the best at, and do that. Interestingly enough this is part of the message of the book Good to Great but applied to a whole corporation. It also applies in the context of self-organizing teams: each individual should be able to find/learn in what way they can best contribute and do that more than they do other stuff.
Posted by Mishkin Berteig at 11:41 AM | |
August 01, 2005
Broadcast Mode Communication
The book "The Mythical Man-Month"* discusses some of the reasons that larger teams are inefficient. The main concern is with the number of possible connections between team members. If you have two team members, there's only one channel of communication. However, if you have n team members, then you have n(n-1)/2 channels... which grows quickly (order n^2) as n becomes larger. If one is required to work with a large team, say more than 10 to 12 people, it becomes imperative to find ways to improve communication efficiency.
One of the best ways to do this is to use broadcast mode communications. Information radiators are a simple broadcast mode tool. In a subtler way, having the team co-located** also takes advantage of broadcast mode communication: if everyone can overhear all the conversations that are going on in a room, then people can tune in when they hear something of relevance.
It is important to note that there are several other forms of broadcast communication that are useful in certain circumstances: e-mail, blogs with RSS or Atom feeds, analog radio, television (if you can think of others, please let me know in the comments). These tend to be more useful for very large communities. Radio and television have severe limits: they are not easily used in a communal fashion.
Some forms of communication may seem to be broadcast, but in fact are not. A simple web site is not because it requires that people poll it to see if it has been updated. Conference calls are marginally broadcast in that while they are occuring, everyone participating hears everyone else. However, a conference call requires active synchronized attention on the part of all the participants.
The subject of media and communication is a vast one. Some of the best writers include Marshall McLuhan and Gregory Bateson. However, there are many many more.
*Highly recommended!
**A search on dictionary.com for collocation indicates that three spellings are all correct: collocate, colocate, and co-locate, this latter spelling being the most common on the web.
Posted by Mishkin Berteig at 11:18 AM | |
July 30, 2005
A Simple Rule of Thumb
Make your product/service development lifecycle shorter than your horizon of predictability. For example, if you can't predict your competitive environment or your own capabilities outside of 4 months, then any new product/service should be initially launched at most 4 months from the time it is conceived. Once initial launch has occured, it is possible to examine the environment and make adjustments for an additional launch. One might call this experimental marketing. Ideas that just can't be accomplished inside of one's horizon of predictability should be considered very risky. In order to reduce this risk, these larger projects can either be broken up into smaller pieces, or efforts can be made to extend the horizon of predictability out further (this second task is extremely difficult).
Posted by Mishkin Berteig at 11:09 PM | |
July 28, 2005
Applicability Matrix Tool for Colocated Team
Notes:
1. Individuals are automatically co-located with themselves.
2. Teams can greatly increase the effectiveness and efficiency of their communication by working in a shared space. For rote and adaptive work, sharing a space is highly recommended, but not always essential. Some teams have found mechanisms for working effectively in a distributed fashion. In these circumstances a great deal of effort is put into frequent use of rich communication channels. In purely creative and innovative work, it is very difficult to do the work without co-location. Risks of misunderstandings or waste due to handoffs increase a great deal if co-location is not used in these circumstances.
3. In community work, co-location is difficult in general due to the large numbers of people involved. A “command centre” open to all members of the community is usually as close as it is possible to come to co-location. With rote work, it is not necessary to even attempt co-location. Adaptive and creative work benefit greatly by increased communication so some efforts to co-locate may be worth the effort, but care should be taken in determining the return on investment.
Posted by Mishkin Berteig at 11:46 PM | |
July 25, 2005
Applicability Matrix Tool for Iterative Delivery
Notes:
1. Iterative Delivery is a specific way of managing queues of work. As such, rote work is generally better served by other applications of queuing theory.
2. There is one universal condition under which iterative delivery is awkward, if not inadvisable. If one's horizon of predictability is longer than the size of a work package by some substantial amount (e.g. 2:1 ratio), it can be more natural to use queuing theory and a pull system to flow work through the team. The actual ratio between the horizon of predictability and work package size that is used to switch over to a queue system must be determined empirically in your own circumstances. This empirical analysis can be done using a regular process reflection meeting.
Posted by Mishkin Berteig at 03:14 PM | |
July 23, 2005
Book Review - "The Tipping Point"
Overview
The Tipping Point: How Little Things Can Make a Big Difference is a book that is about the way ideas, things and behaviors go from obscurity to ubiquity in a very short period. The basic model is that of an epidemic in which three types of factors contribute to quick dissemination: 1) the network of people involved including "connectors", "mavens" or respected experts, and "salesmen", 2) the ability of that which is spreading to stick around, the "stickiness factor", and 3) the importance of small physical, mental and social factors, in creating a conducive environment. The Author, Malcolm Gladwell, includes some excerpts on his web site.
- Introduction
- One: The Three Rules of Epidemics
- Two: The Law of the Few: Connectors, Mavens, and Salesmen
- Three: The Stickiness Factor: Sesame Street, Blue's Clues, and the Educational Virus
- Four: The Power of Context (Part One): Bernie Goetz and the Rise and Fall of New York City Crime
- Five: The Power of Context (Part Two): The Magic Number One Hundred and Fifty
- Six: Case Study: Rumors, Sneakers, and the Power of Translation
- Seven: Case Study: Suicide, Smoking, and the Search for the Unsticky Cigarette
- Eight: Conclusion: Focus, Test, and Believe
- Afterword: Tipping Point Lessons from the Real World
- Endnotes
- Acknowledgements
- Index
Assessment
This is a fascinating book, well written. Some of the anecdotes and "case studies" are mind-blowing. However, there is a bit of weakness in parts. In particular, the Afterword and the sections on The Power of Context are weakly put together - ideas do not flow well, or are too stream-of-consciousness. As well, the weight of evidence, while strong, is not totally convincing. That said, there are a couple of really fabulous stories.
One story that stands out is the study related to the "Good Samaritan". In brief, researchers set up an experiment to test what factors influenced a person's behavior when presented with someone obviously in need of help. At a seminary, the researchers had students prepare and deliver a brief talk on some topic. One of the topics given randomly to some of the students was the story of the Good Samaritan. The students were to take a short amount of time to prepare their talk and then immediately go to another building to deliver it. Planted by the researchers along the path to the second building was an actor made up to appear in a great deal of physical distress. As each student was sent out the door, the researchers would breifly comment either that the student was running a little early, or that they were late and needed to hurry to deliver their talk. The results were astounding: of those students who were told that they were late 90% ignored the person in distress regardless of the topic of their presentation, while 63% those with a few minutes to spare stopped to help (pages 163-165).
Relevance
There are several ways in which this book is relevent to those of us practicing Agile Work and related methods. Most obviously, the ideas in The Tipping Point suggest some lines of action we can take to promote Agile: finding the connectors, mavens and salespeople, working to make Agile sticky, and making the environment hospitible to the spread of Agile. This applies both inside organizations and in the world at large.
In my own opinion, the drafters of the Agile Software Manifesto, either by design or otherwise, came up with an incredibly sticky term: Agile.
Finally, when coaching a team to adopt agile practices, it may be most important to focus on the Power of Context. Small suggestions, small physical changes, body language, all can have a large influence on the success or failure of an agile adoption. If a coach (Scrummaster/Team Lead/etc.) can find the connectors, mavens and salespeople in the sphere of influence of the team, and convince those people of the efficacy of Agile, then convincing the team will become that much easier.
Posted by Mishkin Berteig at 09:59 AM | |
July 22, 2005
Applicability Matrix Tool for Self-Steering Team
Notes:
1. Self-Steering may be difficult to implement in some cultural circumstances. An organization that is very comfortable with a command-and-control system can benefit from self-steering teams, but the effort to shift the culture should be realistically assessed. An excellent reference for corporate culture change is "The Corporate Culture Survival Guide" by Edgar H. Schein.
2. Self-Steering in a rote work environment boils down to teams empowered to learn how to do the rote work as effectively as possible. This learning process must include the power to change the process with the goal of doing the work faster or with fewer defects. For example, in a manufacturing environment, this means people being able to identify problems and make improvements to the manufacturing process. In a rote work environment, not all changes the team makes will be improvements, but they must be accepted. A mechanism for measuring the result of changes must be in place so that the team can assess the effect of their changes, and make corrections as appropriate.
Posted by Mishkin Berteig at 06:38 PM | |
July 21, 2005
Waste and Value: Basic Lean Concepts
In assessing a process, it is important to understand what activities in the process actually add value to the end result. All other activities are wasteful.
CVA (Customer Value Added - or just VA for Value Added): adding form fit or function to a product or service, an activity that the customer would be willing to pay for in isolation if they knew it was being done – e.g. Creating code, implementing functionality.
BVA (Business Value Added - non-negotiable waste): an activity that is required to operate the business but the customer is unwilling to pay for – e.g. Budget tracking, code documentation.
NVA (Non-Value Added): an activity that is not required by the business nor is the customer willing to pay for – e.g. Waiting for resource allocation, requirements documents.
In the book Lean Six Sigma : Combining Six Sigma Quality with Lean Production Speed
(p 52-53)
- Customer Value-Added (CVA) Questions:
- Does the task add a form or feature to the product or service?
- Does the task enable a competitive advantage (reduce price, faster delivery, fewer defects)?
- Would the customer be willing to pay extra or prefer us over the competition if he or she know we were doing this task?
- Business Value-Added (BVA) Questions:
In addition to customer value-added activities, the business may require you to perform some functions that add no value from the customer's perspective.Recognize that these activities are really non-value-added but you are currently forced to perform them. You need to try to eliminate or at least reduce their cost.
- Is this task required by law or regulation?
- Does this task reduce the financial risk of the owner(s)?
- Does this task support financial reporting requirements?
- Would the process break down if this task were removed?
- Non-Value-Added (NVA) Questions:
- Does the task include any of the following activities: counting, handling, inspecting, transporting, moving, delaying, storing, all rework loops, expediting, multiple signatures?
- ...
Links:
Its About Time - an article about the importance of time in lean and value.
Reducing NVA Office Work - applying lean in an office environment.
Lean Six Sigma on the Electronic Business - some lean six sigma success stories.
Inventory is Ignorance - reasons that lean is so hard to do.
Posted by Mishkin Berteig at 04:22 PM | |
July 19, 2005
Applicability Matrix Tool for Adaptive Planning
Notes:
1. For rote work, it is rare to need an Adaptive Planning style prioritized backlog. Rather, simple queues tend to be sufficient. The adaptive backlog is designed to allow for reprioritization of work as more is learned about the work itself. With rote work most of the learning is involved with improving the process of creating the work and reducing defects rather than changing the work product itself.
2. Individuals can benefit from using a backlog to organize their work, keep a history, and track progress. However, it may be sufficient to keep a simpler to-do list. The adaptive planning practice allows an individual to gain the benefit of explicit collaboration points with stakeholders.
Posted by Mishkin Berteig at 10:39 PM | |
July 18, 2005
Sociometry and Team Building
I was recently introduced to the term "sociometry". As it turns out, my introduction to it was a little mis-defined. If you follow the link, you will find that sociometry is basically a measurement of relationships between people. What I was introduced to has some aspects of sociometry in it. I tried it out on a team that I am coaching. Here is what we did:
Team Building
1. If the members of the team have not worked closely together previously, start with introductions, name and role/experience.
2. Go around the group again, this time each person describes something about themselves that the others likely do not know. It could be something personal, like a hobby, or it could be something professional, like a previous career. The idea here is for everyone to learn something new about everyone. This usually can end up with exclamations of suprise, laughs, and general fun for the group.
3. Simple self-organizing starts with a group exercise of sociometry. The people in the team organize themselves into a line based on length of time they have been involved with the current organization/workplace/community/association. This is a fairly easy exercise since it is an easily quantifiable measure. Sometimes interesting things come up like that everyone has "been there" for a long long time, or that everyone is really new.
4. The team then does another sociometric self-organizing exercise. Here, each individual asks themselves what proportion of the creative or innovative capacity is actually put into use in their current role. How much opportunity is there to be creative? Again, the group organizes itself into a line from least creativity to most creativity. Note: this is not a self-assessment of how creative one is, just how much of one's creativity is in use! After the group gets lined up, it is important for the facilitator to get people to describe why they placed themselves in their location and to encourage discussion around creativity in their work.
Posted by Mishkin Berteig at 11:09 AM | |
July 17, 2005
A Nice Little Intervention
Esther Derby wrote about a great, incredibly obvious, but sometimes missed never-the-less, intervention for helping teams make a decision: write the options down (20050724: corrected link).
Posted by Mishkin Berteig at 02:42 PM | |
July 16, 2005
Applicability Matrix Tool for Information Radiators
Notes:
For individuals, the use of Information Radiators is usually not applicable in rote work since the individual can keep track of status of such work easily. However, for adaptive and creative work, an information radiator can be quite useful as a constant reminder of what is happening or for organizing work to be done. A cork board for the status of tasks or for categorizing ideas can be a simple information radiator used by an individual. A whiteboard can be used for free-form notes.
For teams, information radiators are ideal for easily maintaining broadcast communication with team members. A team is usually small enough that an information radiator can be maintained by individuals making updates as appropriate. Project status of tasks, issues parking lots, and group calendars are examples of information radiators used by teams.
For a community, the difficulty of using an information radiator comes in the logistics. With a large number of people performing work, possibly never all coming together at the same time, the broadcast nature of information radiators can be severly curtailed. It is difficult to efficiently represent information that is relevent to the whole communit in a way that can be easily accessed and easily understood at a glance. As well, it is difficult to have community members directly and (relatively) equally participate. That said, there are some exceptions. The most obvious one is the various wikis that are maintained by communities... and the largest of these is Wikipedia.
Posted by Mishkin Berteig at 06:45 PM | |
May 17, 2005
The Qualities of an Ideal Test
These six qualities of tests describe how to make a test as effective and as useful as possible. The qualities are similar in style to the INVEST qualities of user stories - but they don't form a nice acronym.
Decisive: The test contains all the information required to automatically determine success or failure. Manual inspection of test results is not necessary to determine success or failure. The test is expressed in a way that produces a pass/fail answer rather than a numerical or qualitative result. Decisive tests are often expressed as assertions.
Valid: The test produces a result that matches the intention for the work artifact under test. Test failure indicates failure in the artifact under test and test success indicates correct operation or configuration of the artifact under test. Simply put: the result of a test should be true.
Complete: The test contains all the information it needs to run correctly with a given test harness and work artifact under test. The test performs all activities and provides all the data necessary. The test does not require any input outside of itself in order to run.
Repeatable: The test always gives the same results if the test harness and the artifact under test are the same. The test is created in such a way that the result is deterministic. Even if the system under test is not deterministic, the test should be created to account for that (possibly with statistical analysis) and produce a deterministic result.
Isolated: The test result is not affected by other tests run before it nor does a test affect the results of tests run after it. The test and the test harness work together to clean up after every test is run. A collection of tests can be run in any order and always produce the same results. Any test that depends upon the results or side-effects of a previous test is not isolated.
Automated: The test requires only a start signal in order to run to completion in a finite amount of time. No manual intervention is required after the test is started. Tests that are automated can be put together into a test suite and run one after another without human intervention. Automation of tests requires the creation of a test harness system.
Update 20060106
I've added a little bit more detail to the above qualities. I also wanted to say a few words about my experience with testing:
I first started doing test-driven development almost seven years ago after reading the book Refactoring by Martin Fowler. I picked it up in Windsor Ontario while I was driving to San Francisco for my first contract position as an independent. I had to stay the night there due to the immigration office being closed so I read a lot of the book in my motel room that night. By time I got to California four days later, I was totally convinced that I should be using JUnit and refactoring for everything I did. Fortunately my project was ammenable to this approach. Over the next four months I built a Java JMS layer on top of Tibco Rendezvous. In the process I discovered methods for doing unit tests for asynchronous multi-threaded distributed functionality. And my tests satisfied all the above qualities. I delivered code with 100% test coverage and zero defects discovered until more than two years later when a very rare and obscure deadlock issue was found. Suffice it to say, I was convinced from a quality perspective.
But there is more. To build tests that follow all the above qualities, you need code that is testable. I have come to believe that testability is the most important architectural attribute of code for most software. The implications of having testable code include code that is easily changed, that is verifiable, and that is easy to understand. Refactoring plays a big role here too.
For getting a basic but very practical sense of test driven development, I strongly recomment Test Driven Development: By Example 
I have also written a couple of articles recently about quality:
Quality is Not Negotiable in which I talk about how to handle defects - by always treating them as top priority work items.
and
Technical Debt in which I expand on this common analogy between lack of testing and debt to show that technical debt is even worse than financial debt.
Posted by Mishkin Berteig at 06:48 PM | |
May 15, 2005
Truck Factor
Truck Factor (definition): "The number of people on your team who have to be hit with a truck before the project is in serious trouble"
Clearly "hit by a truck" is an extreme thought however you could easily substitute "take vacation at the same time" to get the same idea. If any part of your project has a truck factor of one then you are in a particularly fragile situation. If that one person leaves or is unable to work on the project, you will suffer the consequences.
Over time, anyone can be replaced. Truck factor is an indication of how expensive it will be to replace specific people.
In an ideal situation, everyone on the team will know all parts of the system so that the loss of any one person would have minimal impact. In reality, many projects rely on one or more "heros" who are the only one who understand certain critical parts of the system. When these heros leave (and you should assume they will), you must be prepared to recover.
If you have a hero on your team, the best thing you can do is reassign that person to a different part of the system. This will allow the replacement to ramp up while the hero is still available for support. If you wait until the hero has left then the ramp-up will be significantly more expensive.
An added benefit to reassigning the hero is that this person will now have the opportunity to work on something different. Since the hero's tend to be the most technically competent members of the team, this will usually mean that the new area will improve once the hero has worked on it for a while.
Truck factor is a quick metric that will highlight potential problems in your project. Having hero's on your team can be very beneficial but only if you don't become dependant on them. Truck factor is one metric that will highlight your dependencies.
Cross posted from Mike Bowler's Weblog
Posted by Michael Bowler at 06:42 PM | |
What To Do With the Horizon of Predictability
In a previous entry about constant change, the idea of a horizon of predictability was introduced. This concept, along with the agile discipline of amplifying learning, suggest a strategy for addressing problems in a project.
Shorten the length of the iterations you are using. Contract your "planning horizon". The length of your iterations should be motivated by the horizon of predictability for your environment. If your project encounters trouble, particularly of the sort where it looks like you might not accomplish your commitments for an iteration, then shortening the length of iterations will enable you to resolve your problems.
First off, by shortening your iteration length, your opportunities for learning become more frequent.
Secondly, a contracted planning horizon will put you more firmly inside the horizon of predictability... and therefore there will be fewer unexpected changes (on the whole, not in any specific iteration).
A related article is The Pros and Cons of Short Iterations.
Posted by Mishkin Berteig at 06:34 PM | |
May 11, 2005
Appropriate Metrics
At the Advanced ScrumMaster Training, Ken Schwaber presented a substantial amount of thinking about metrics used with Scrum. The main driver for thinking about metrics has come from implementing Scrum in enterprise situations. Management expects metrics to be used in order to provide visibility into the progress of the Scrum implementation.
While this driver has some legitimacy, there are three main concerns to prescribing metrics for use with Scrum.
1. Planned/Engineering Approach - metrics such as "ideal person days" smell like the bad old way of treating people as resources that can be swapped in and out of a project.
2. Normative vs. Empirical - metrics are often used to set a standard for reasons such as prediction, and expectation. Scrum is about discovery and improvement not prediction and planning.
3. Is Something in Scrum not Working? Is adoption being hindered? Are too many Scrum implementations failing? Are metrics a critical success factor?
Keep these concerns in mind while considerig the uses of metrics.
What are Metrics for?
1. Self-Evaluation over Time - use a metric to track the progress of a group. A measurement is taken at a certain point in time, and then taken repeatedly over intervals. Example: the velocity at which a team completes work can be used to identify problems and opportunities for a team.
2. Control - use a metric to legislate the qualities of some process or attribute of work. A goal or standard is set for a measurement. The size of a queue of projects waiting to be worked upon by a team can be controlled in order to limit the size of work in progress and therefore project inventory.
3. Prediction - use a metric with values collected over time in order to predict future values of that metric. By implication, the metric is used to predict the performance of a system. The number of additional tasks discovered inside an iteration can be tracked and used to determine future expectations on extra tasks discovered.
4. Performance Measurement - use a metric in order to determine rewards and/or punishments and/or adjustments to behavior. An individual on a team may be evaluated based on their productivity as measured by lines of code completed and rewarded or penalized on that basis (not recommended!).
5. Behavior Motivation - use a metric to guide behavior by setting a context for thinking, action and reflection. Focus on an important measure in order to draw attention to improving the attribute with which the metric is associated. Measuring the time elapsed from conception of a project idea to the time it actually delivers valuable results can draw attention to improving speed.
The Lesson from Good to Great
Good to Great: Why Some Companies Make the Leap... and Others Don't by Jim Collins discusses the attributes and behavior that are common and unique to companies that have gone from a long history of mediocre results to a long run of great results. One identified aspect is referred to as the "Hedgehog Principle". In this principle, three questions are answered: "what can we be the best in the world at?", "what can we be passionate about?", "what is my one economic driver?"
The economic driver is a metric. For example, at Walgreens, their driver is profit per customer visit. Other large institutions have other metrics. But all good to great companies have a single economic driver metric that guides all their decision making.
See also: A Metric Leading to Success.
Posted by Mishkin Berteig at 05:21 PM | |
May 10, 2005
Empower the Team
Empowerment is the ability of a team to make decisions about how to do their work and execute on those decisions without outside interference. If a team is empowered, then it will be more capable of responding to change, and it will be able to focus on manifesting the members' creative potential. Empowerment comes from a combination of several factors:
1. members of the team have a deep sense of self-worth that includes nobility, and contribution to the progress of humanity
2. tacit or explicit authority and responsibility for results as a team and as individuals
3. a team environment which is honest, trusting and allows for mistakes
4. the absence of personal attacks against individuals on the team and in particular a total lack of gossip and backbiting
There are several ways that team members will demonstrate their empowerment. People will derive joy from their work. Team members will be dedicated to the work and the team. Individuals on the team will frequently take individual initiative to accomplish tasks, share insights, and develop improvements. Spontaneous leadership will become common. Individuals will step out of comfort zones or areas of specialization in order to assist the team.
Empowering a team is a process that can sometimes take a great deal of time and effort. In order to start on this process, the team members should carefully listen to each other and ask many questions. More mature individuals should lead and teach by example. And all the team members can start to question and challenge the rules and procedures of an environment that are preventing effective work. If the team is in an organizational environment where team members have management to report to, then management must be aware of this opportunity for empowerment and support it.
An empowered team can gradually understand and internalize the agile work principles (People are Creators, Change is Constant, Perception mediates Reality). By internalizing these principles, a team can move beyond specific agile work practices and become a high performing team setting their own work practices.
Jeff Sutherland has a very brief blurb about the progress of teams as they evolve in their use of Scrum.
Future entries here will discuss the methods of creating empowered teams.
Posted by Mishkin Berteig at 11:04 PM | |
May 04, 2005
Can dying plan-based projects be recussitated?
We've all seen this. A one-year project in its 13th month, and the Project Manager has been reporting 80% of the tasks at 90% and has been doing so for the last 120 days. There's no end in sight, and the customer is leaking cash every day the product fails to go into production. What can be done? Agile project management principles can help this all-too-frequent scenario.
First, let's look at how this situation comes about. In a typical task-oriented project plan, one is required to decompose the tasks down to a fairly reasonable degree of specificity. The tasks are organized around a dependency graph, estimated, resources are assigned, and the schedule is calculated and/or nudged. (Well, usually the initial estimates don't match the customer's expectation and deadlines, so there's a revision step here where estimates are shortened) But how does change get reflected? If a PM is doing an excellent (if frustrating) job, they are constantly updating the schedule, the plan, and re-conceiving the tasks as new information comes to him.
More often than not, however, this gets so messy and unwieldly that the PM holds fast, and starts to estimate completion based not on a proper decomposition and a completion of each of these tasks, but based on his guess, or his workers' guesses. Complexity of the tasks is hidden, and becomes often quite invisible. Tasks at 80% which suddenly need to be re-decomposed and re-conceived do not, in the main, get moved back down to 40% after certain roadblocks are discovered.
The result? The customer is increasingly afraid, trust between delivery staff and client (and management) are eroded, pressure is increased, mistakes under pressure become more frequent, less sleep is had by all, and 90% complete becomes an asymtote, rather than a milestone.
Now what is to be done with such a project? How can Agile project management approaches help this situation? We can examine this by playing out such a scenario...
We can start by identifying a few key practices of Agile project management, and examine their benefits to the business client.
Timeboxing and Iteration
The first thing we can talk about to the fearful client is timeboxing. Timeboxing caps his investment into small chunks. We look at it and say, OK, you're in deep trouble, but you don't know how deep your trouble is. By timeboxing into a very short timeframe, and making a large project into many little short projects, we can get more visibility into the process - we can see things as they are, rather than how they're reported on a project plan. Speaking of visibility...
Daily Meetings and Iteration Review
Part of the value of iteration and timeboxing is increased visibility, so we really need to have a mechanism for visibility. Already distrustful of project plans, we can tell the client, "Don't believe the paperwork, let's look at what's actually built. At the end of each iteration, we'll review the current situation, and demonstrate existing functionality." His eyes perk up. "Wah?" he asks incredulously? What do you mean? So we say, "we don't want you to guess at how ready this thing is. We'll show you. That way, you can decide if it's ready enough. ...Or your product marketing people, if you prefer. It's up to you, but you get to see it, touch it, and sense for yourself how ready it is, and you won't have development managers and developers waving their hands pretending it's further than it is."
"Oh wierd," says he. "So what are these daily meetings?"
We tell him that the daily meetings have several purposes. Only project members get to speak, and they report on what they did yesterday, what they plan to do today, and what, if anything, is blocking their path. No one else gets to speak, but others who are not on the team itself can listen in. This way, the whole project team is clearly aware of how they're working, what's left to do, and what each other are doing.
"Why do they need this? They have the plan." "True," we reply, "but how often do you have two people who need something, and both do it because they don't know that someone else already did it. With your current project delays, do you want any duplication of effort? Just by way of example?"
Feature Lists, not Task Lists
We also talk to him about working from feature lists, not task lists. The team will be implementing features, and fulfilling requirements. How they do it is up to them. "Why should I care," he'll ask. "You don't," we reply, except to assure him that if people are working against features, then they can choose to re-order their tasks in such a way as to most quickly get to the goal. No wasted effort, we tell him. Sounds good to him.
Customer-Prioritized Features
What's more, we assure him, we will be first working on the highest-priority features. What "needs" to get to market. Everything else slides down the list. Even if the wonderful plan we all love had it earlier. High-value features (as prioritized by the client) and their necessary dependencies. That's it.
"So no features that I didn't ask for?" He looks hopeful.
"That's right," we reassure him, "and you can change your mind."
He faints.
Smelling salts are brought.
"What do you mean, 'I can change my mind?'" he asks.
"If, when we get to the iteration review, and you test drive the thing, Acme corporation has come up with the killer feature that you absolutely must have or the whole thing is useless, you put it at the top priority on the list we use to drive the next iteration."
"And no one will complain that it's out of scope?" he marvels?
"If you put it at the top of the list, it is the scope for the next iteration. We are at your service," we comfort him.
"So when will this be finished?" he asks us desperately.
"When you say it's ready," we reply. He boggles. What does that mean, he thinks.
"What does that mean," he asks.
"It means that we will tie it off, when you think it has enough juice to go to market. If, after you re-prioritize what's left, you find that it's 'ready enough', then we'll roll with it, take a couple of weeks to steady it and ship it, and then we can pick up your next-highest priority things, or anything new you want in it." He looks near fainting again. "And we stop when you feel that spending money on it is no longer bringing you enough value, ideally because we've done all the high-value stuff already, and we're working on less valueable stuff."
"So I have discretion to pull the plug whenever I want to?"
"Yep."
"Please help me..."
Conclusion
This little scenario is fictitous, but in the end, it's consistent with the experiences of many Agile practitioners (particularly Scrum) that I have spoken with. We've only covered a small sampling of Agile practices that may help a project in crisis. Others may help quality, may improve developer productivity - but the above can help a key client or stakeholder begin to see a light at the end of the tunnel. While many people cannot get their heads around it, they may be willing to try new things when they're in enough pain with the existing process.
And it can turn a project failure into an ever-increasing success, because success is defined monthly, re-defined at the desires of the business client, and executed in bite-sized chunks that are digestible and estimable.
Just don't forget that people have the strangest reactions to things that break their expectations... so make sure to bring the smelling salts...
Posted by Christian Gruber at 09:08 PM | | | TrackBack
April 24, 2005
Agile HR - Sort Of
An article called Are You Ready for the Agile Future presents a brief discussion about the role of HR in an agile organization. There are several very good ideas. The basic idea is that the HR function must adapt to the nature of agility. This in turn means, for example, hiring people that are agile, nimble, adaptable etc.
There are however some mis-steps in the article.
One is an ommission: the HR organization must itself become agile. In one organization that I worked, it took at a minimum 4 weeks and typically 12 weeks to get a contractor onto a project. Three months lead time!!! Now admittedly, it is not easy to bring an individual on-board quickly. However, it is possible. Some organizations I have worked at have lead times for getting new people into the organization that are on the order of 2 weeks including search, selection, administration and orientation. In these organizations, the HR organization maintains an attitude to their own work as service to the larger organzation... and the faster the service (without sacrificing quality), the better.
The article also misses the mark on employee performance. Employees should be measured on their sphere of influence, not their sphere of responsibility. In other words, if a person is a member of a team, their own performance should be judged by the performance of the team as a whole. This mitigates people's competitive habits and positively reinforces collaboration. People should not be measured against their role discription.
One of the recommendations in the article is to "Create selection, testing and hiring criteria that identify diverse, resilient, nimble people." Unfortunately, there is no guidance on how to do this. Here are some ideas: look for people who have moved between projects, roles, employers and even locations frequently, look for people whose resumes contain lots of work that doesn't fit their job titles, look for people who have hobbies and interests that are outside their field of specialization, look for people who have diverse volunteer experience, look for people who ask lots of questions.
(Thanks to Deb Hartmann for the link.)
Posted by Mishkin Berteig at 09:48 PM | |
April 20, 2005
Scrum Scorecards - Measurements to See Progress of Agile Adoption
Two interesting visual presentations of the progress of adoption of Scrum practices. These are marginally software-specific but could very easily be adapted to non-software agile work situations.
http://wiki.scrums.org/index.cgi?ScrumScoreboard
Posted by Mishkin Berteig at 04:31 PM | |
April 18, 2005
Book Review: "Good to Great" by Jim Collins
Summary: In this well-written, engaging book, author Jim Collins describes six critical factors that he and his research team found common in companies that transformed themselves from a long period of mediocre or bad results to a long period of great financial results. Although focused on publicly-traded companies in the United States, the results of this research can easily be extended to apply to other types of organizations.
Good to Great describes the following six concepts:
- Level 5 Leadership: personal humilty and professional discipline in an organization's leader are the starting point for the transformation.
- First Who... Then What: don't worry about what to do until the right people are in the right positions in an organization.
- Confront the Brutal Facts (Yet Never Lose Faith): careful and honest examination of an organization's current situation is the foundation for finding a path forward.
- The Hedgehog Concept (Simplicity within the Three Circles): discover a simple business concept that people can be passionate about, that works with a single key economic driver and that the organization can be the best in the world.
- A Culture of Discipline: disciplined people removes the need for heirarchy, disciplined thought removes the need for bureaucracy and disciplined action removes the need for excessive controls.
- Technology Accelerators: pioneer the application of carefully selected technologies without relying on technology for transformation.
Some of these concepts are very close to the underlying prinicples of agile work. For example, in the Scrum methodology, the first five principles are all represented. The Scrum Master embodies some of the attributes of level 5 leadership. A self-organizing team gets the right people in the right position. The daily scrum and the sprint planning meetings are designed to help the team confront the brutal facts. The sprint goal embodies at a local level the simplicity of the hedgehog concept. And the practices in general are a manifestation of a culture of discipline.
Who Should Read this Book? Anyone interested in creating a lasting positive transformation in an organization should read this book. In particular, individuals who are coaching teams or organizations should read this book since the concepts also appear to apply at a sub-organizational level.
Posted by Mishkin Berteig at 07:29 PM | |
April 13, 2005
Backlogs in an Organization - Levels of Queues
Queues of work form at three types of levels in an agile organization.
At the largest level is the project portfolio. The queue for this level contains all the projects that are not yet being actively worked upon by project teams.
At the intermediate level is the backlog of project functionality. The queue for this level contains packages of business function or infrastructure components necessary to implement business function. These packages are selected by a project team to fit into a single iteration.
The packages in turn are also elements in a queue. This smallest level of queue contains individual tasks required to implement all the business function and infrastructure that make up a selected package of work. The team members select tasks off this queue based on priority and dependencies.
In many agile methods, the queue management approach is fairly explicit at the intermediate and small levels. However, very little is said about the largest level. Some organizations have solved this by limiting the size of projects:
To be successful, high-tech CIOs recommend biting off projects in small chunks.... Gregoire notes that Dell is growing so fast that at the end of an 18-month project, the company would be significantly different from when it began. "A project has to take less than six months [to complete]. That's the only way we can make sure [it stays] with the business," he says. (http://www.cio.com/archive/120198/tech.html)
Posted by Mishkin Berteig at 06:19 PM | |
April 09, 2005
Article on CIO Insight
The online CIO Insight has a great article/interview about a forthcoming book: "The World Is Flat: A Brief History of the Twenty-First Century". Choice quote:
What I am trying to do is say that something important really is happening. The value-creation model is moving away from a vertical silo model to an increasingly collaborative horizontal model, from command and control to collaborate and connect, and that's going to change everything.
This comment alone is a fairly close hit at the essense of Agile Work. The rest of the article is very interesting and touches on many topics of interest relating to globalization, business, information technology, outsourcing and politics.
There is an interesting article at The Economist also about this book. It is very critical.
Posted by Mishkin Berteig at 11:49 PM | |