Coade introduction

Editor's Notes

• #5: Health Reviews said that “scope freeze” = “project red”Resulted in “death march” projects, lower quality of life and lower moraleTime taken to get new functionality out the door is getting longer and longer; cycle time longerEven when the functionality is delivered we get “that’s not what we want” from the customerEverything we did to get more control, seemed to make things worseAs soon as the software is delivered, it’s the start of crisis issues and problems, as we slipped quality to meet datesEveryone (the executives, sales, field, customers) regarded software development as a problemWorse we’d come to believe that that was “just the way it was” especially for “our complex products”
• #7: Reality is that agile is not “bleeding edge” any more.642 respondents:54.8% were developers, 29.4% were in management41.6% had 10-20 years IT experience, 37.2% had 20+ years37.7% worked in orgs of 1000+ people71% worked in North America, 17% in Europe, 4.5% in Asia
• #10: Image courtesy of The Borg –Rule Number 6 is “Don’t Take yourself too seriously”Also discussion about “quality of life”
• #22: Sprinters team. Temporary housing in conference room. This was first time we tried “co-location” in Huntsville and was an area of high concern. From a management perspective our approach was to say “try it and see”. Recommendation from Bob that people try sitting facing each other, so we did that.
• #23: By the time the Sprinters team got to design their real home, this is what they came up with. The management approach was “here is your team space – design it as you see fit”. The result was a more formal version of the temporary space. Fundamentally the team liked how co-location worked and were happy to have a similar set up in their case. There are in fact two team in this bay – the Sprinters and the Alphas. At the time the plan was put together, there was a lot of concern about how the noise from the team behind the partition would effect the Sprinters work.
• #24: The team room one year later. As a result of a need to integrate another team member into the Sprinters team, the plans were reviewed by all on the team. When they proposal was seen by the team members, they decided that it did not make sense to have any partitions at all, that everyone could work together, and so this is the layout they came up with. So from a team that started with fear and worry about co-location, they went to a team driving the plan for co-location. Note that there was no management interaction with this process – team decided and it happened.
• #29: Once we’ve defined “done”, how does it actually get done. At the heart of this work is a sprint team who is going to do the work. So far you have seen how a product backlog is put together, and you have seen a representation of the “sprint board” where all the tasks for a sprint are defined against the user stories. The sprint board is the detailed plan of what is going to happen in the next 30 days. Lets say you have a user story that says “Engineer defines a “typical” so that they can reduce the number of manhours expended on a P&ID”. After the team has accepted this story (which happens during Sprint Planning 1), the Sprint Planning 2 meeting takes place. This meeting is just with the team. They take this user story and say break it down into 1-16 hour chunks of work.For example, this user story might require some UI development, so the team writes down the task on the post it note and the number of hours it will take, say 5 hours, and slaps it up on the board. It might take some documentation – write down task, hours and slap it up on the board. And so on.Now some of these tasks might come from the definition of done. For example, perhaps an automated test is part of the definition of done for every user story. Then their might be a task that says “develop a QTP” and again the task and hours go up on the board.This third picture shows a team working through their definition of done to understand what they need to do. The second shows a team working through the tasks during a sprint.This is how a lot of the definition of done items are addressed. But as we pointed out before, that is not the only way. We can look at other mechanisms to get things done:. Special teams to address integration issues, for example.. Division of labor so that one team bears the brunt of one item, another for another itemAnd so on. In each and every case the definition is public and transparent and we know who is addressing that item. We also review the definition regularly while keeping in mind the overarching goal – to provide potentially shippable software at the end of every Sprint.