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.
Subscribe to:
Posts (Atom)