I have started an account at WordPress:
http://mwpolen.wordpress.com/
The editor here and the fact that when I logged into my google docs with a different email than I use for my blog I lost my saves made me mad :-)
I might come back, but for now look there for any new posts and here for old posts.
Sunday, May 25, 2008
Saturday, May 24, 2008
Jim Shore on what seperates high performing agile teams from just good ones
I found a talk by Jim Shore at the Dallas chapter of the APLNtalk on what separates the great teams from the average agile teams (it is over an hour long):
http://jamesshore.com/Blog/Secrets-of-Agile-Success-Live-Recording.html
Since I had no good ideas this morning I just took notes.
1. High Bandwidth Communication
High performing teams sit together. People complain that it gets noisy. Pair programming can help with the noise because the adhoc communication is less chaotic (mostly between pairs and not cross the table all the time). They also are cross function and have an involved product owner. Get real-time feedback on features and priorities. Without one the questions take more time to get answered correctly.
Teasley study shows that sitting together doubles productivity and time to market is one third:
http://www.sciencedaily.com/releases/2000/12/001206144705.htm
If you separate a team because of convenience is it worth the cost.
2. Passion
Cult of quality: the believe they are special and are accomplishing something special.
Talks about teams forming: http://en.wikipedia.org/wiki/Forming-storming-norming-performing. In his opinion it takes months, up to and over 12, to get to performing. As teams really form they are inwardly focused and from the outside they look weird. He warns that you should use cross functional teams to prevent this teamness from harming the organization. Sometimes organization break up the team in the norming phase, before performing. The fifth stage is adjourning (breaking up) and the team members will go through some mourning. The team will be naturally self organizing (teams take ownership of work).
Someone asks if you lose one member does it take another year to incorporate a new team member. He says one of two things happen: assimilation or rejection. One person states that sitting together can speed up the time to get to the performing phase.
There is a focus on continuous improvement (much like Lean's perfection principle). They have pragmatic idealism: you don't stop doing something just because it is uncomfortable or hard. (e.g. TDD - it can be hard in certain situations, high performing teams don't give in to the desire to short cut the hard parts - reminds me of a recent Tim Ottinger post). The ideals or principles are pragmatic because they directly relate to a goal (e.g. TDD is there for the goal of high quality or in Lean terms low Muda.) Regular retrospectives are the one thing he would recommend to any agile team that isn't - not just going through the motions but selecting an area to improve each time. He conducts them for an hour.
Marick's missing motivators: Marick states that the agile manifesto (that he signed) is missing four values:
He states Scrum is good because it focuses on ease, but not good enough to get work done (I agree of course :-). Talks about distributed teams. He recommends Pubs & Planes :-) He references some research by Monica Yap (might be this: http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel5/10705/33795/01609825.pdf?arnumber=1609825) that shows how hard distributed teams are.
3. Lash of Jeffries
Running tested features on a schedule every iteration. Ship like clockwork. Requires that done means done (or as he says "Done-Done"). He means that even though all the work is done it isn't done until it is a running tested feature. IMO: There are often gaps in a feature if it is split among people. He says the velocity is rock solid and the features are nearly defect free. They prevent defects from entering into the product. Flickr deploys software every day!
Asks the audience if anyone has gotten to this point and the room was quiet for a while. One guy says they are just now able to deliver every iteration on a Monday (with Tuesday as a back-up in case of any defects found with the push on Monday). If the user isn't ready for a feature have the ability to turn off the GUI (but deliver the feature anyway) You don't want long lived branches in your code. Sometimes the team will overwhelm the business team. Isn't that a cool place to be! He states that the business will adapt.
He tells a story from his book about a team working on an embedded application. They had 60k LOC, 51 defects (over 3 years of development) never had more than 2 open defects at a time. Delivered software after 6 months and supported engineering as well as new features. They delivered 21 defects. Capers Jones statistics said a best in class team working on this size project would have had 461 defects, found 95% and delivered 23. The team above found only 59%. They prevented defects!
4. Agile Engineering
Great teams use agile engineering. He busts on Scrum again because it lacks AE. AE Practices are TDD, continuous design, rigor & mindfulness. Software engineering practices taught in school come from large and long DoD projects doing some version of waterfall or spiral. These practices can't support weekly or even bi-weekly deliveries. Great teams avoid technical stories (taking time off to refactor). AE doesn't require an A-team. He works with ordinary people in great teams.
He does think every team needs someone who is passionate about quality and pays attention. This person doesn't need to be senior but needs courage to speak up when things are going wrong.
He didn't plug his book, but I was impressed so I will. He publishes added stuff to his book every Wednesday here: http://jamesshore.com/Agile-Book/
http://jamesshore.com/Blog/Secrets-of-Agile-Success-Live-Recording.html
Since I had no good ideas this morning I just took notes.
1. High Bandwidth Communication
High performing teams sit together. People complain that it gets noisy. Pair programming can help with the noise because the adhoc communication is less chaotic (mostly between pairs and not cross the table all the time). They also are cross function and have an involved product owner. Get real-time feedback on features and priorities. Without one the questions take more time to get answered correctly.
Teasley study shows that sitting together doubles productivity and time to market is one third:
http://www.sciencedaily.com/releases/2000/12/001206144705.htm
If you separate a team because of convenience is it worth the cost.
2. Passion
Cult of quality: the believe they are special and are accomplishing something special.
Talks about teams forming: http://en.wikipedia.org/wiki/Forming-storming-norming-performing. In his opinion it takes months, up to and over 12, to get to performing. As teams really form they are inwardly focused and from the outside they look weird. He warns that you should use cross functional teams to prevent this teamness from harming the organization. Sometimes organization break up the team in the norming phase, before performing. The fifth stage is adjourning (breaking up) and the team members will go through some mourning. The team will be naturally self organizing (teams take ownership of work).
Someone asks if you lose one member does it take another year to incorporate a new team member. He says one of two things happen: assimilation or rejection. One person states that sitting together can speed up the time to get to the performing phase.
There is a focus on continuous improvement (much like Lean's perfection principle). They have pragmatic idealism: you don't stop doing something just because it is uncomfortable or hard. (e.g. TDD - it can be hard in certain situations, high performing teams don't give in to the desire to short cut the hard parts - reminds me of a recent Tim Ottinger post). The ideals or principles are pragmatic because they directly relate to a goal (e.g. TDD is there for the goal of high quality or in Lean terms low Muda.) Regular retrospectives are the one thing he would recommend to any agile team that isn't - not just going through the motions but selecting an area to improve each time. He conducts them for an hour.
Marick's missing motivators: Marick states that the agile manifesto (that he signed) is missing four values:
- skill - good at your job
- discipline - don't cut corners
- ease at work - don't make it hard to do the job (remove obstacles)
- joy - enjoy your work
He states Scrum is good because it focuses on ease, but not good enough to get work done (I agree of course :-). Talks about distributed teams. He recommends Pubs & Planes :-) He references some research by Monica Yap (might be this: http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel5/10705/33795/01609825.pdf?arnumber=1609825) that shows how hard distributed teams are.
3. Lash of Jeffries
Running tested features on a schedule every iteration. Ship like clockwork. Requires that done means done (or as he says "Done-Done"). He means that even though all the work is done it isn't done until it is a running tested feature. IMO: There are often gaps in a feature if it is split among people. He says the velocity is rock solid and the features are nearly defect free. They prevent defects from entering into the product. Flickr deploys software every day!
Asks the audience if anyone has gotten to this point and the room was quiet for a while. One guy says they are just now able to deliver every iteration on a Monday (with Tuesday as a back-up in case of any defects found with the push on Monday). If the user isn't ready for a feature have the ability to turn off the GUI (but deliver the feature anyway) You don't want long lived branches in your code. Sometimes the team will overwhelm the business team. Isn't that a cool place to be! He states that the business will adapt.
He tells a story from his book about a team working on an embedded application. They had 60k LOC, 51 defects (over 3 years of development) never had more than 2 open defects at a time. Delivered software after 6 months and supported engineering as well as new features. They delivered 21 defects. Capers Jones statistics said a best in class team working on this size project would have had 461 defects, found 95% and delivered 23. The team above found only 59%. They prevented defects!
4. Agile Engineering
Great teams use agile engineering. He busts on Scrum again because it lacks AE. AE Practices are TDD, continuous design, rigor & mindfulness. Software engineering practices taught in school come from large and long DoD projects doing some version of waterfall or spiral. These practices can't support weekly or even bi-weekly deliveries. Great teams avoid technical stories (taking time off to refactor). AE doesn't require an A-team. He works with ordinary people in great teams.
He does think every team needs someone who is passionate about quality and pays attention. This person doesn't need to be senior but needs courage to speak up when things are going wrong.
He didn't plug his book, but I was impressed so I will. He publishes added stuff to his book every Wednesday here: http://jamesshore.com/Agile-Book/
Saturday, May 3, 2008
Threes Dog and Pony
I found this buried in my email folders:
Threes Dog and Pony
Rev. 1.1 By Duane Elms and Leslie Fish
Nitpicks 1.2 by Rich McCabe
Deep in engineering, where mortals seldom go
A manager and customer come looking for a show
They pass, amused, among us and they sign in on the log
They've come to see our pony and they've come to see our dog
We bring our dog and pony, 'cause we know they'll want a show
Watching while we enter, with a shifty, restless eye
The customer sits waiting in his pinstriped suit and tie
The pony kicks his heels up as the doggie does his trick
And hams it up with vigor as we lay it on real thick
The customer just watches as we do this song and dance
Then reaches for his briefcase, only giving us a glance
And all but four within the room are taken by surprise
And all but four are thinking of their last job with remorse
(The customer, the manager, the doggie, and the horse)
Then, thirty-seven changes show up, much to our chagrin
And this thing's just inadequate, and that thing's just plain wrong
And, by the way, your schedule's about three months too long
Threes Dog and Pony
Rev. 1.1 By Duane Elms and Leslie Fish
Nitpicks 1.2 by Rich McCabe
Deep in engineering, where mortals seldom go
A manager and customer come looking for a show
They pass, amused, among us and they sign in on the log
They've come to see our pony and they've come to see our dog
Three things to be wary of: A new kid in his prime,Summoned from our cubicles, to conference room we go
A man who knows the answers, and code that runs first time
We bring our dog and pony, 'cause we know they'll want a show
Watching while we enter, with a shifty, restless eye
The customer sits waiting in his pinstriped suit and tie
Three things to never trust in: the vendor's final bill,
The promises your boss makes, and the customer's good will
The pony kicks his heels up as the doggie does his trick
And hams it up with vigor as we lay it on real thick
The customer just watches as we do this song and dance
Then reaches for his briefcase, only giving us a glance
Three things that see no end: A loop with exit code done wrong,From briefcase then there comes a list of things we must revise
Requirements unspecified, and the change that comes along
And all but four within the room are taken by surprise
And all but four are thinking of their last job with remorse
(The customer, the manager, the doggie, and the horse)
Three things hold no secrets: Files that somehow hit the net,First, twenty-one new features that we somehow must add in
The boss' secretary, and what makes the customer upset
Then, thirty-seven changes show up, much to our chagrin
And this thing's just inadequate, and that thing's just plain wrong
And, by the way, your schedule's about three months too long
Three things it is far better that only you should know:
How much you're paid, the schedule pad, and what is just for show
The customer proceeds to go through each change, line by line
Excruciating detail which no logic can divine
And when it ends, there's only four not sitting there agog
The customer, the manager, the pony, and the dog
Three things never anger: First, the one who runs your deck
The one who does the backup, and the one who signs your check
Now we are contract software types who spend our days and nights
Embedded in the system, down with all the bits and bytes
And none but us can tell full well the damage done today
It's what they do not know for which they're gonna have to pay!
Three things are most perilous: Connectors that corrode
Unproven algorithms, and self-modifying code
The manager and customer are quick to leave this bunch
They take the dog and pony, and they all go out to lunch.
Now how will we avenge ourselves on those who raise our ire?
Write code that self-destructs the day the warranties expire!
Three things trust above all else: Your knowledge of your craft
That someone turns a profit, and that you will get the shaft
My take on YAGNI
Recently there has been a long going post on the Extreme Programming newsgroup (http://tech.groups.yahoo.com/group/extremeprogramming/?yguid=198635929) about YAGNI. For those of you who do not know what YAGNI means please read this: http://c2.com/xp/YouArentGonnaNeedIt.html. Basically it started when some guy said that he thought XP got some things wrong and one of them was YAGNI. This of course caused lots of people to inquire/question him and out of it came several good posts. I sent some of these posts to an old colleague and he thought some people were over zealous about YAGNI. I do not doubt that people can become over zealous, no matter what you are talking about, but in this case I think the opposite is the larger problem.
Let me start with a story. At work a project came up that was for the CEO, and thus had high priority,vague requirements and an unmovable deadline! I pitched tackling this problem in an iterative fashion (Agile is becoming such a buzzword that I rarely use it in public anymore). The IT lead agreed and off we were. The team was me and a colleague (new to agile techniques and principles but liked all he had read). We couldn't dedicate much time to it as we had 2-3 other projects that had to take larger chunks of our time during any given week. We didn't have a prioritized list yet (customer was working on it with the CEO), but we did have the notion that the important thing was the landing page (the CEO doesn't like to click unless compelled). In our first working session we set up the project and hooked it up to a test page and viola we had a landing page...what next. We knew the whole point of the project was to display data and this data was coming from multiple sources (some internal, some external and some typed in) so we thought database. Then we asked, do we need it? One day yes, but not now. So we created a class and hard coded all the starting values in the code behind. This was obviously throw away code as the data must come from a database, but we got a landing page with real data in from of the team lead for direction in 2 hours spread over 2 days. He loved it and seems willing to stand up to the political forces that want us to design it all up front!
The moral I choose to draw from this story is that not doing something now even though one day, maybe even tomorrow, you will do it is a powerful tool. One reason is that software developers love to get ahead of themselves. My colleague came into my cube yesterday with a technical solution for a problem that we don't have yet. It was good that he was excited, but his (and mine) tendency is to solve the problem we sees coming because the problem we imagine is somehow more romantic than the problem right in front of us.
Our manager, not in line with the IT lead, did not feel comfortable with our approach, even though we are the two best developers in the company, because he wanted us to have solved all problems he could envision. Forget the fact that the customer wasn't even sure what he wanted...lets go solve "the problem he should be asking for" and ignore what he needs right now. It is hard to fight these forces, but knowing the technique works gives us stength to resist and carry on (I hope :-)
I am not saying that you should be blind of the future. You should always use your best judgement with the best information possible. I am just saying, and I think YAGNI is saying, be careful of your tendency to solve tomorrow's problem when today's problem can be just as challenging. In fact our last working session my colleague (the agile neophyte) re-directed our task list because I was focusing too much on back-end data issues on not enough on giving the customer value. I loved it! Our next set of tasks is still database free. It's coming...but we don't need it yet.
Let me start with a story. At work a project came up that was for the CEO, and thus had high priority,vague requirements and an unmovable deadline! I pitched tackling this problem in an iterative fashion (Agile is becoming such a buzzword that I rarely use it in public anymore). The IT lead agreed and off we were. The team was me and a colleague (new to agile techniques and principles but liked all he had read). We couldn't dedicate much time to it as we had 2-3 other projects that had to take larger chunks of our time during any given week. We didn't have a prioritized list yet (customer was working on it with the CEO), but we did have the notion that the important thing was the landing page (the CEO doesn't like to click unless compelled). In our first working session we set up the project and hooked it up to a test page and viola we had a landing page...what next. We knew the whole point of the project was to display data and this data was coming from multiple sources (some internal, some external and some typed in) so we thought database. Then we asked, do we need it? One day yes, but not now. So we created a class and hard coded all the starting values in the code behind. This was obviously throw away code as the data must come from a database, but we got a landing page with real data in from of the team lead for direction in 2 hours spread over 2 days. He loved it and seems willing to stand up to the political forces that want us to design it all up front!
The moral I choose to draw from this story is that not doing something now even though one day, maybe even tomorrow, you will do it is a powerful tool. One reason is that software developers love to get ahead of themselves. My colleague came into my cube yesterday with a technical solution for a problem that we don't have yet. It was good that he was excited, but his (and mine) tendency is to solve the problem we sees coming because the problem we imagine is somehow more romantic than the problem right in front of us.
Our manager, not in line with the IT lead, did not feel comfortable with our approach, even though we are the two best developers in the company, because he wanted us to have solved all problems he could envision. Forget the fact that the customer wasn't even sure what he wanted...lets go solve "the problem he should be asking for" and ignore what he needs right now. It is hard to fight these forces, but knowing the technique works gives us stength to resist and carry on (I hope :-)
I am not saying that you should be blind of the future. You should always use your best judgement with the best information possible. I am just saying, and I think YAGNI is saying, be careful of your tendency to solve tomorrow's problem when today's problem can be just as challenging. In fact our last working session my colleague (the agile neophyte) re-directed our task list because I was focusing too much on back-end data issues on not enough on giving the customer value. I loved it! Our next set of tasks is still database free. It's coming...but we don't need it yet.
Saturday, April 5, 2008
Why I Recommend One-Week Iterations
Over the years I have worked with, talked to and/or read about many agile teams. Almost none of the teams did agile software development the same way which has reinforced my belief that there is no "one way" of doing agile. One aspect of agile development I have always been drawn to is iteration length. Most teams seem to be falling in the 2-3 week range. In fact, recently a friend of mine said they were doing scrum with 3 week iterations becuase "any thing shorter caused too much overhead." I tried to point out that that isn't always the case as it depends of what overhead you are doing. I am a firm believer in minimuzing overhead as much as possible. I have always found ways to decrease or shift overhead to take less time in an iteration than previously believed possible. My favorite technique is process impedance matching.
I believe that lean thinking should be applied to software development. Given the principles of flow and value along with agile development practices it is obvious to me that the shorter the iteration the better. One of the competing forces is as the team size increases so does the overhead. To combat this I recommend capping team size to 9 (I am a slave to the magic number :-) Another consideration is the team's schedule. All the agile teams I know of work Monday to Friday and have a daily standup in the AM (9AM seems to be a popular time). People also like to forget work on weekends...some would argue it is the point of the weekend. Given these factors releasing on a Friday make the most sense to me. Monday's typically are hard... catching up on emails from people you didn't get to on Friday, remembering what it was you were doing when you left Friday...so planning meetings are best suited for Monday's. As you plan you are refreshing your memory as to the features you plan on bulding. All of this seems to point to a week long schedule of Monday mornings are planning and Friday afternoons are releasing. It's a nice package for an iteration in my opinion. I am open to shorter, but longer seems wastefull.
Many people will immediately think some version of the following: "That can't be a good idea becuase I'm not doing. If it was a good idea I would have thought of it when we decided to do >1 week iterations" or "I am sure it is >1 week here for a good reason...I just don't know exactly what that reason is." Given that I would like to convince you that my belief should be your belief (one of my many weaknesses) let me try and lay out common arguments against the one week iteration.
A1) One week iterations will have too much overhead.
I have found that the most people say this because they they they have to cram all the overhead they currently do in 3-4 weeks into one thus it is obvious to them this makes no sense. This assumption does not hold because of the lean principle of waste reduction and thus the goal is to minimize overhead. I challenge everyone to examine what overhead is actually needed in EVERY week? We already have blocked of 2 half days (Monday morning planning and Friday afternoon release & retrospective) as well as the 15 min stand up every day. Everything else should be avoided or at least minimized. If your organization requires a weekly status report and meeting. Use process impedance matching (e.g. let the team lead do it for the whole team; rotate through the team). Most all obstacles can be overcome if you use a brainstorm session with you team. If you have trouble solving a problem use the many internet sources (websites, groups, blogs...) If you seem stuck it is probably due to a lack of true teamwork (The Core has some iteresting ideas).
A2) Weekly releases are wasteful
Usually this comes from a management type who is thinking that all releases must have the business customer present (or some overhead thing like A3). If your business customer isn't engaged enough to commit to 2 half days a week then improvise and have a team member play a surrogate customer in those meetings. Different people have different skills, but hopefully one member of your team can think from a customer's point of view long enough for you to move forward. Once the customer makes time then re-validate. I am not saying it isn't ideal to have a fully committed business customer, but don't throw the baby out with the bath water.
A3) We can't do X in one week iterations
X is usually some localized practice that has evolved from a problem that wasn't solve, but is now. Like passing all releases to some QA team. If your organization is one with a separate QA team that must "sign off" on all external releases then simply use process impedance matching and send them your final release (the one that has all features needed in the time allowed) and then they test and they few if any defects (if you used proper agile development techniques) . You fix them as they find them and send them one more release when they are done (if they can manage to test in one week...doubtful if your organization hasn't embraced continuous testing..then send them one per week without needing to change your process much). Pretty simple if your team thinks about how to fit what needs to be done for organization reasons with what has to be done for agile development reasons.
I am sure there are more arguments out there that don't neatly fit into one of the above. Please comment with them. I think Tom Gilb once challenged an audience that over lunch he could figure out a way to release early then they currently do (Gilb's guidance was 2-5% of budget/schedule for each release). He got at least one free lunch out of that challenge. I am willing to take the few who read this on :-)
I believe that lean thinking should be applied to software development. Given the principles of flow and value along with agile development practices it is obvious to me that the shorter the iteration the better. One of the competing forces is as the team size increases so does the overhead. To combat this I recommend capping team size to 9 (I am a slave to the magic number :-) Another consideration is the team's schedule. All the agile teams I know of work Monday to Friday and have a daily standup in the AM (9AM seems to be a popular time). People also like to forget work on weekends...some would argue it is the point of the weekend. Given these factors releasing on a Friday make the most sense to me. Monday's typically are hard... catching up on emails from people you didn't get to on Friday, remembering what it was you were doing when you left Friday...so planning meetings are best suited for Monday's. As you plan you are refreshing your memory as to the features you plan on bulding. All of this seems to point to a week long schedule of Monday mornings are planning and Friday afternoons are releasing. It's a nice package for an iteration in my opinion. I am open to shorter, but longer seems wastefull.
Many people will immediately think some version of the following: "That can't be a good idea becuase I'm not doing. If it was a good idea I would have thought of it when we decided to do >1 week iterations" or "I am sure it is >1 week here for a good reason...I just don't know exactly what that reason is." Given that I would like to convince you that my belief should be your belief (one of my many weaknesses) let me try and lay out common arguments against the one week iteration.
A1) One week iterations will have too much overhead.
I have found that the most people say this because they they they have to cram all the overhead they currently do in 3-4 weeks into one thus it is obvious to them this makes no sense. This assumption does not hold because of the lean principle of waste reduction and thus the goal is to minimize overhead. I challenge everyone to examine what overhead is actually needed in EVERY week? We already have blocked of 2 half days (Monday morning planning and Friday afternoon release & retrospective) as well as the 15 min stand up every day. Everything else should be avoided or at least minimized. If your organization requires a weekly status report and meeting. Use process impedance matching (e.g. let the team lead do it for the whole team; rotate through the team). Most all obstacles can be overcome if you use a brainstorm session with you team. If you have trouble solving a problem use the many internet sources (websites, groups, blogs...) If you seem stuck it is probably due to a lack of true teamwork (The Core has some iteresting ideas).
A2) Weekly releases are wasteful
Usually this comes from a management type who is thinking that all releases must have the business customer present (or some overhead thing like A3). If your business customer isn't engaged enough to commit to 2 half days a week then improvise and have a team member play a surrogate customer in those meetings. Different people have different skills, but hopefully one member of your team can think from a customer's point of view long enough for you to move forward. Once the customer makes time then re-validate. I am not saying it isn't ideal to have a fully committed business customer, but don't throw the baby out with the bath water.
A3) We can't do X in one week iterations
X is usually some localized practice that has evolved from a problem that wasn't solve, but is now. Like passing all releases to some QA team. If your organization is one with a separate QA team that must "sign off" on all external releases then simply use process impedance matching and send them your final release (the one that has all features needed in the time allowed) and then they test and they few if any defects (if you used proper agile development techniques) . You fix them as they find them and send them one more release when they are done (if they can manage to test in one week...doubtful if your organization hasn't embraced continuous testing..then send them one per week without needing to change your process much). Pretty simple if your team thinks about how to fit what needs to be done for organization reasons with what has to be done for agile development reasons.
I am sure there are more arguments out there that don't neatly fit into one of the above. Please comment with them. I think Tom Gilb once challenged an audience that over lunch he could figure out a way to release early then they currently do (Gilb's guidance was 2-5% of budget/schedule for each release). He got at least one free lunch out of that challenge. I am willing to take the few who read this on :-)
Subscribe to:
Posts (Atom)