P&P Summit Day Three: Agile talk on Agility
This talk was given by Peter Provost and Michael Puleio. They spoke about how the P&P team does their Agile development process. They ran the presentation like they would a project. Pretty neat concept. They asked us what they want, then created 10 minute iterations on providing those expectations.
They stated that iteration zero for an agile project is usually getting an idea of the overall goal and vision of the project. Iteration zero for this talk was a chance for them to throw out some questions to get started with.
They then opened up the floor to gather their backlog.
- When does it not work
- How do you do design and architecture in an agile project.
- How do you get budget
- Distrusted teams
- Scope creep
- How to explain agile up and down
- Pick team members and Size of team
- How do you organize work
- Distributed customers
- Coordinate separated agile teams
- Sell into your organization
- Business buy in on an agile process
- Hot fixes
- How do you train your customers
- How do you sell to customers
They then had us stack rank the backlog by applause. I’ve organized the backlog above to what they came up with.
They then started with their first 10 minute iteration with estimation. Peter’s point of the estimation is that as more iterations go by the estimation starts to get really good. You have to know that up front it will probably be not accurate. Peter stated that he gave up using the “gummy bears” unit of times for estimates, he uses actual units of time. In P&P they use real time estimating that the team has to agree upon the estimate. The MSDN team used cards that had times on it (half day, one day, up to five days, etc.). They then on the count of three the whole team raises their card, then discuss the times. Again team consensus. This helps where some people over or over estimate. They also advocate that the people doing the work are the ones with input into the estimate.
The second question was when does it not work. Michael stated that it doesn’t work when the team does not buy into the process. It doesn’t work if team members have the rock star, hero complex and will not work together. It also doesn’t work if you take a 3 month waterfall process, break it down into one month iterations and call it SCRUM (scrumerfall). Peter talked about the Last Responsible Decision time. Its based on lean manufacturing at Toyota that states make the decision when it would be irresponsible to not make the decision. Then the timer ended and they stopped this iteration.
They then asked if the answers to the questions were valid and what we wanted. They also reviewed the process and verified their due date (time). They also asked if there were any stories that needed to be added to the list.
They added:
- How do you gather requirements?
- Do you need an onsite customer?
- Split sprint? Things look bad in the middle.
- Different skill levels of the team? - later deleted and merged with 8
- Dedicated team rooms?
- Dealing with project dependency trees.
Since they completed only two questions last iteration they now select two more questions for the next iteration. Looks like they will get about two or three more answered.
The next questions was how do you design and architect an agile development project. Michael’s answer was to do little amounts at a time to get started while you get the skeleton in place. Peter followed this up with the statement that architecture needs to be up front, but don’t over do this. Just get the overall goal of the architecture planned out and then get going. Either the first few iterations are on only on this skeleton or you break off a group of people to do this after a contract has been established.
The next question is on distributed teams. Peter states that P&P uses a lot of vendor resources for Dev and test. They effectively have a distributed team. His favorite approach is to bring the team together as much as possible, but not constantly. What they do now is have the team come together about once a month and in the interim they use internet sharing tools. They also do a little bit more spec work so that everyone is on the same page since not everyone can directly collaborate at the same time. Michael took over with only a minute left in the iteration. He states that each distributed team should be a complete team in and of itself.
During this process review they added the following questions:
- How do you do performance reviews for developers?
- How do you measure the effectiveness of the process?
- Maintenance documentation - separation of teams.
- How do you get the project back on track when you gets off track?
- Risk Mitigation.
We also moved some of the questions around. I’ll not worry about making changes to the list….
The last iteration started and the question is scope creep mitigation. Peter’s comments on this was to adjust by reprioritizing and performing the stack ranking. Also, make sure when you are executing your project you are doing so in way that could help embrace change. Make sure you have tests that can help ensure changes and scope creep can be mitigated. Peter actually recommends a two to one ratio for testers to developers. Understand that there is always a backlog and work with that understanding. Michael chimes in that you should always ensure that the project backlog is stack ranked all the time by the customer.
Michael finished the iteration with 30 seconds to go for Risk Mitigation. Identify what the risks are and work the customer to get them into the backlog to mitigate.
This was an excellent way to get the point across of how agile works. What was funny was the one guy repeatedly asking if they would get question 6 done by the end of the talk to get the point across that managers push for this type of answer all the time during the process.
I’m sorry if the text here is very jumbled and not grammatically correct. They were firing this stuff pretty quick.