« July 2007 | Main | September 2007 »
August 30, 2007
Agile Retrospectives and the Plan of Action
Bas Vodde has published a good article about making goal oriented action plans for agile projects. It is a nice piece of the puzzle on how to do effective retrospectives. It also nicely ties into the "Learning Circle" Reflection/Learning/Planning/Action steps.
Posted by Mishkin Berteig at 04:59 PM | |
August 23, 2007
Meta-Announce: Agile-ANN
Joe Little has created a yahoo! group called agile-ann. It will be used for all types of announcements for agile events, conferences, meet-ups, courses, seminars, calls for papers, etc. etc. It will probably become fairly high volume with all the agile stuff that goes on! I strongly encourage everyone reading this site to sign up for the list.
Posted by Mishkin Berteig at 02:04 PM | |
August 22, 2007
Stuck? Try Extreme Obstacle Removal!
What happens when you are iterating away, your team is totally groking agile, delivering great results every couple of weeks, and then unexpectedly, suddenly and firmly everyone is stuck!? An obstacle has come along that forces a full stop. A barrier has been placed in the path. What do you do?
I know of a team that was in exactly this situation. They were building software on BEA's Weblogic platform. They discovered that a defect in the platform made any forward progress impossible (until the defect was remedied). So they canceled their iteration (good), tried to work in an open ended mode without iterations (really really really bad!) and then got absolutely nothing done for four months...
Encountering large obstacles like this puts a team in a nasty danger zone!!!!
Me, I like to consider the extremes:
1) Dump the vendor. This means building the component from scratch or replacing it with a component from another vendor or changing the whole platform. Although this sounds extreme, a self-organizing team should be aware that this is an option that might make the most sense given the circumstances. Keep iterating.
2) Make the vendor part of the team. Insist that they provide a dedicated, on-site person who is expert on the component you are using, insist that they provide you with source code. Both of these are so that you can cross-train in-house team members to solve this problem. Keep iterating.
3) Cancel the entire effort until the vendor (or some other entity) resolves the problem. Get the team to stay together but work on something else in the corporate portfolio that is valuable enough to justify the cost of the team. Let them work in short iterations so that there is little delay from the time the component is fixed until the team finishes an iteration on the other project. Keep iterating.
In my opinion, if you can't do one of the above three options, it is because your project is not valuable enough and no one is willing to admit it. (Actually, there might be other reasons too, but this is the one I would really be worried about.) Don't forget the Art of Obstacle Removal!
That said, there are of course half measures... just make sure you KEEP ITERATING!!! Whatever your current iteration length, find a way to deliver potentially shippable software at the end of every iteration.
Posted by Mishkin Berteig at 12:40 PM | |
August 21, 2007
Agile and Lean Defect Tracking
Lisa Crispin has written an excellent article about defect tracking in agile environments. The article is a couple of months old now, but if you haven't read it yet, you definitely should! I particularly like the perspective that Mary Poppendieck offers in the article...
Since Quality is Not Negotiable, and since defects in both XP and Scrum are meant to be dealt with immediately, there is a good argument to be made for doing away with any type of automated tool-based defect tracking.
One team I coached really struggled with this. They were working on the first every agile project in their organization and none of the team members had any prior experience with agile or with test-driven development. It was a small project, but management wanted to do things "right". They had a team room, a cross-functional team, short iterations, etc. etc.
One member of the team was a person who was their Quality Assurance expert. This person was extremely capable: able to write excellent test scripts (in Excel) and able to think carefully about quality. However, the organization was not set up to support an agile approach to quality: QA folks were measured on how many defects they found and logged in their defect tracking system.
Since the team had decided to use test-driven development, they soon found that they had an odd question: when does incomplete work become defective work that needs to be logged? In other words, since the tests are written first and they start out by failing, and since this is normal and happens for every single feature, exception condition and even method of code, tracking all these as "defects" would be meaningless. So how do you decide that something is a defect instead of test-driven work that just isn't yet making the tests pass?
After a great deal of discussion and confusion and consternation, we finally agreed to a simple and effective practice: inside of an iteration, any issues or problems that come up are written on the whiteboard. The whiteboard needs to be clear by the end of the iteration. If it is not, then the items that are still there are logged into the defect tracking system. These items also become top priority for the next iteration. As well, any items which had non-passing tests by the end of the iteration were also put into the defect tracking system and became top priority for the next iteration.
This helped... and we only ended up with at most one or two items at the end of each iteration that could be logged... and often there were no known defects.
This was legitimately painful for the QA person whose defect logging rates went way down. Fortunately, since this was a pilot project, it was easy to explain to management what was going on. This is a very good example of how a management practice that makes a lot of sense in a non-agile environment becomes a huge obstacle in an agile environment.
Posted by Mishkin Berteig at 07:46 PM | |
Agile/Scrum Training - Fall Schedule: Toronto, Edmonton, Beijing
The fall schedule is up for Agile/Scrum training. For Canadian training, prices are currently discounted and will be raised on Sept. 15th. For Beijing, the course date is tentative based on pre-registrations up to Oct. 15th. Pre-registrants for the Beijing course will get the pre-registration price of 8000 RMB and after Oct. 15th, the price will go up to 10000 RMB.
Posted by Mishkin Berteig at 11:13 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 16, 2007
Agile 2007 Conference Notes - Mary Poppendieck on Leadership
Okay, I'm only here for one day, and the first part of the day was me giving a workshop and then the next part was a presentation on Ruby and Selenium which was interesting (but unfortunately nothing to write home about) and then...
Mary Poppendieck spoke. Here are my notes.
The Role of Leadership
Notes from a talk by Mary Poppendieck with some commentary by Mishkin Berteig.
History:
Taylor: "The Principles of Scientific Management"
- Assumptions: workers do as little as possible, they don't care about quality, and they are not smart enough to know the best way to do the work.
-> experts therefore define the best way to do a job and you pay your workers extra to follow the expert's instructions
-> results in happy workers and profits for the company
!!!
Note: this is almost exactly the opposite of the Agile Axioms
Charles R. Allen: "Industrial Training"
- method: Preparation -> Presentation -> Application -> Testing
Here's another example of the Learning Circle.
- on the job training best
- 1917 this approach tested w/ shipbuilding training
- - train the supervisors to train workers
- - 88000 people trained
- wrote a book: "The Instructor, The Man and The Job"
- "If the learner hasn't learned, the teacher hasn't taught."
WWII: "Training Within Industry" (TWI)
- inexperienced workforce to build weapons and munitions
- train first line supervisors
- - job instruction: how to train
- - job methods: how to do the work
- - job relations: how to work with workers
- abandoned after the war
BUT
-> exported to Japan to help them rebuild
TWI Premises: Good Supervisor
- knows the work
- knows responsibilities
- skill in instruction
- skill in process/work improvement
- skill in leadership
Toyota Production System (TPS)
- in 1950's Toyota looked at Ford and GM and saw that they were far more productive than Toyota
- Taiichi Ohno (1912-1990) founded TPS
- - Just in Time Flow (eliminate waste)
- - Stop-the-Line culture (mistake-proof the process)
- - - originally made LOOMS
- - - 1st self-stopping automated looms that stopped with defects
- - Relentless Improvement
- - Books: "Taiichi Ohno's Workplace Management
about "Standard Work":- Standard Work
- - document the way work is done
- right now
- - often used by experts to create an ideal process - this is a
- big mistake
- - standards evolve
Deming: 1980 "System of Profound Knowledge"
- Appreciation of the System
- - never sub-optimize by focusing on one part of the system
- - look at everything: suppliers, producers, customers
- Knowledge of Variation
- - most variation is inherent in the system therefore don't blame workers for systemic problems
- - provide leadership in changing the system
- Theory of Knowledge
- - Scientific Method (PDCA)
- - Use data
- Psychology
- - don't use #'s for people
- - Skill, Pride, Expertise, Confidence, and Cooperation motivate people
Respect People
- move responsibility and decision-making to the lowest possible level
-> when workers are annoyed by their job... do they:
- - complain (stone cutters)
- - ignore it (making a living)
- - fix it (cathedral builders)
Leadership
(adapted from "The Toyota Way
Top Down and General Management Expertise:
-> bureaucratic: "follow the rules"
Top Down and In-Depth Understanding of Work:
-> task manager: "here is what to do and how to do it - now do it!"
Bottom Up and General Management Expertise:
-> group facilitator: "you're empowered"
Bottom Up and In-Depth Understanding of Work:
-> builder of learning organizations: "here's our purpose now let's do it and learn along the way"
- this last type of manager is where most of Toyota's managers fall
John Shook (www.lean.org)
Three Models of Leadership from the Lean Management and the Role of Lean Leadership Webinar:
- Old "Dictator": do it my way
- 1980's Empowerment: do it your way
- Lean: follow me and let's figure it out together
@ Toyota a leader:
1. acts as a teacher who knows how to do the job and how to teach it
2. gets each person to take the initiative to solve problems and improve his or her job
3. ensure that each person's job is aligned to provide business and customer value
Brilliant Products
- require deep understanding of both business and technical domains
- who decides?
- priority by committee: no responsibility
- marketing by checklist: no innovation
- behind every great product is a single person
- - great customer empathy
- - deep technical insight
- - distinguish between essential and incidental
- Chief Engineer at Toyota
- Product Champion at 3M
Leadership Roles for Products:
- Champion:
- - marketing leader
- - technical leader
- Functional Leader
- - job instruction
- - methods improvement
- - job alignment
- process leader (temporary): coaching
the process facilitator?
- project leader (temporary): funding/tracking
Case Study: Zara (Fashion Clothing Stores)
- from design to store in 2 wks
- twice weekly orders
- - deliver globally in 2 days
- - on hangers, priced
- - shipping prices are not optimized!!!
- manufactured in small lots
- - coops in Spain
- - West European labor rates
- - labor costs are not optimized!!!
In order for Organizations to perform brilliantly, there are 2 pre-requisites:
- everyone in management agrees what they want
- everyone in management agrees on cause and effect
-> does everyone on the Management team speak the same language?
Mary then went on to discuss the topics of Cost Cutting, Conformance to Plan, Standards, Utilization, Accountability, and Measurement and contrasted a non-lean with a lean approach or attitude. Most of these ideas can be found in essays on her web site www.poppendieck.com or in her books:
Lean Software Development: An Agile Toolkit for Software Development Managers
and
Implementing Lean Software Development: From Concept to Cash (The Addison-Wesley Signature Series)
Both of which are excellent.
Here is her pdf of the presentation materials.
Posted by Mishkin Berteig at 02:01 AM | |
August 14, 2007
Agile 2008 Conference - In My Town!
I'm pleased to see that Agile 2008 conference is in Toronto! I'll be there the whole time... The web site doesn't have any information yet except the hotel.
Posted by Mishkin Berteig at 04:09 PM | |
August 09, 2007
A Cautionary Tale - Delaying Agile Adoption
What happens when you delay adopting agile? Well, one large client I have worked with has found out...
Because this story is a story of failure, and because most people don't like to have their failure's exposed, I have anonymized this story and changed some details to protect the innocent (and they are innocent! Failure is a learning opportunity, not something that's bad).
I started working with BigCom about two years ago. They got a whole bunch of training from me; in total about 60 people received some in-depth training in agile methods. They also decided, wisely, to get me to help coach them organizationally and for some of their Process Facilitators. What they didn't do is heed some good advice: start iterating.
They decided that they needed to do some important up-front architectural research on their huge product re-write/porting project. They had an existing product used by many clients and built over the course of several years. This product was implemented in a legacy programming language and in order to make it easy to add features and keep it up to date, BigCom decided to re-write it in a more modern programming language... but they couldn't decide which one: Java or .NET. Because it was a pure porting job with little if any functional change, they already had a good detailed knowledge of the functional requirements. But this one question of the platform to build upon stalled them. Their research committee studied this questions (and some other less important ones) for four months.
I had advised my client that they should feel free to go ahead and do the research, but that they would be well served by starting to iterate and build the new version of the product, even if it meant building it on two platforms simultaneously. The actual experience of trying to implement real functionality in both Java and .NET might seem like a waste, but actually would provide valuable information for the research effort and help speed the decision-making.
Perhaps my advice was too scary. Or perhaps there was some legitimate reason for many capable people to sit idle for four months while the committee researched, deliberated and failed to make this important decision. In any case, product management and dev management finally got tired of waiting, and they started up the work.
Of course, without the decision made, the work initially was a real mess: developers were left to choose when to use Java and when to use .NET. Sometimes functionality was duplicated in both languages. Sometimes it made connecting functionality extremely difficult. It wasn't systematic. But it was experimental, and it did help clarify the issues quite quickly. After only four weeks of doing actual work on the functionality of the product, it became clear how to use these platforms (for the curious: Java on the UI and .NET on the back end).
The research committee had very little to do with the final decision other than to rubber-stamp it.
Time passed. BigCom continued the development work, features were implemented, and eventually the deadline for releasing the product loomed. And then it passed. Six weeks after the deadline, the product was finally released. Nine months after the start of iterations. Thirteen months after I recommended that they "just start".
Four months wasted... and a deadline missed by six weeks. Was it worth it? Might have been nice to distribute some bonuses for coming in ten weeks early instead. Oh well!
Please, just start iterating!
Posted by Mishkin Berteig at 09:55 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 | |