Agile Buzzwords in Action
•
1 j'aime•8,608 vues
A session co-presented by Pk and me at Agile NCR 2010 conference in Gurgaon, India, and also at Agile Tour Philly 2010 in Philadelphia, USA. It is targeted at those new to Agile and who want to see buzzwords come out of glossaries and be applied to real day-to-day settings.
Recommandé
Contenu connexe
Similaire à Agile Buzzwords in Action
Similaire à Agile Buzzwords in Action (20)
Plus de Aman King
Dernier
Dernier (20)
Agile Buzzwords in Action
- 1. Agile Buzzwords in Action Aman King king@thoughtworks.com Prashant “Pk” Srivastava pk@thoughtworks.com
- 2. Agenda
- 3. Roles
- 4. Practices
- 5. Tools
- 6. Terms
- 7. Context
- 8. A typical day starts…
- 33. Last day of iteration starts…
- 38. First day of iteration starts…
- 44. How it all started…
- 49. Conclusion
- 50. Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.
- 51. Q & A
Notes de l'éditeur
- * Aman and Pk, both of us, work in ThoughtWorks Pune on the same project team: it is a Java project run in a distributed fashion between US and India. The team size is considerable with about 8 dev pairs, 4 BAs, 4 QAs and 2 PMs, in addition to client team members.
- * Our agenda is “Putting …”
- “… in context.” agile blogs, articles, etc throw words around and typically explain things in glossary-like fashion; this session is aimed at putting terms in context to help understanding better format (set up a chart paper titled “Buzzwords”): we’ll capture “buzzwords” from audience, and then go through visuals, ticking off those terms we come across, spending a little time explaining them (the audience will contribute too) Disclaimer: please note that the following will show how Agile is typically followed in ThoughtWorks projects but is open to adaptation according to project needs; also the following need not necessarily conform to other known definitions of the various “buzzwords”
- “Typical day” stands for any of the days in the middle of a running iteration. An iteration is a timeboxed period where user stories are developed, starting off with stories slotted according to an iteration plan, and ending with a showcase to the customer. An iteration is typically either a 1 week or 2 weeks.“iteration”“sprint”
- Team standup at start of day Everyone speaks briefly: typically, what I did yesterday, what I’ll likely do today, what blockers I face Shares token one after the other“standup”“daily scrum”“token”
- BA sharing updates of overnight call/emails that he may have had with client-side Product Owner and/or onshore BA. Business Analyst: proxy for a customer for the team. “Onsite Customer”Proxy for “Product Owner” aka “Customer Proxy”
- QA talking about functional automation progress and environmental blockers. QAs are an integral part of the delivery team, including during active development.“Quality Assurance”“Tester”“automation”“automate, automate, automate”
- Devs sharing boring “will continue on story” updates. “Developer”
- PM: His updates are typically about the status of blockers. Day to day, the Project Manager is responsible for tracking blockers, managing operational concerns like infrastructure, staffing, etc, and communicating with client management. He plays an important role during project planning.Closer to “ScrumMaster” than traditional PM.“ScrumMaster”
- The sign-up process where devs choose new stories as BA prioritizes, or devs switch pairs on running stories (collective code ownership entails that folks work across the code base; switching between stories encourages this further)“Pair programming”“Promiscuous pairing”“Pair rotation”“Sign up”“Story wall”“Collective code ownership”
- A closer look at the swim lanes in the story wall. Could have an online version additionally: Mingle. Swim lanes are flexible, catered to project needs, including accommodating client processes. Note that the cards are color coded: typically, red is defect, yellow is tech task, white or blue is user story.Our swim lanes: In Analysis (BAs working on fleshing out upcoming user stories), Ready for Dev (stories that are functionally analyzed and have Acceptance Criteria, and can be “played”), In Dev (stories being implemented/played), BA/QA Volleyball Done (BA/QAs have taken a first pass at the implementation and are happy that they satisfy requirements), UxD in Dev (UI enhancements in progress… this one is client-specific), Ready for Automation (QAs can pickup the story for writing automated functional tests), QA Complete (functional automation done and showcase-able), Tech Task Done (completed non-story tasks), Blocked (stories that need more analysis or functional/technical clarifications)“swim lane”“story lifecycle”“sprint backlog”“color coding”“story”“tech task”“spike”“bugs” or “defects”
- What a story card looks like. This one has an identifier (one for Mingle, one for client-side JIRA), a story title, and an estimate. The business value is implicit by the sort order in the story wall.“story format”“backlog item”“task”“estimates”“business value”“priority’“Ron’s 3 C’s: Card, Conversation, Confirmation”“tracking number”
- Dev checking emails. We are a distributed team after all, and no matter what, emails remain a main channel of communication.“distributed team”“colocation”“communication”
- When a pair picks up a story, a BA, a QA, and the dev pair get together to talk about the story and its acceptance criteria… this info is captured with some detail and mockups on a wiki“story kickoff”“collaboration”“documentation”
- Story narrative: BAs capture requirement details, assumptions, out-of-scope clarifications, and mockups around a user story in wiki pages. The narrative usually starts off with “As a <role>, I want to <perform action> so that <business goal>” and ends with a set of Acceptance Criteria in the format of “Given… When… Then…”(Note: this picture is a fake demo screenshot as we could not use a real story narrative for client-sensitive reasons)“narrative”“acceptance criteria”“assumptions”“business value/context”“story format”
- Pair-programming: the two developers who got the story kickoff continue with development. Sometimes when a pair switch happens, the person who continues on the story takes some time to get the new pair up to speed.“pair programming”
- Devs read through the narrative again, this time tasking technical decisions/steps at high level. Some devs use physical sticky notes while others use the wiki page itself to list out the tasks.(Note: this picture is a fake demo screenshot as we could not use a real story narrative for client-sensitive reasons)“dev tasks”“tasking”“sticky notes”
- Devs developing at lower design level with “ping pong” style of pairing, follows the TDD mantra of red-green-refactor where one person writes a failing unit test, another writes code to make it pass, and then together they refactor while keeping test green. This enhances the code design incrementally.“red-green-refactor”“tdd”“refactor”“evolutionary design”“feedback”“fail fast”“ping pong”“ball and board”
- One can also break from ping pong for real ping pong: benefit of pairing, you’ll always have someone to play with“pair programming”“feedback”“team bonding”
- A break from ping pong to discuss stuff. Discuss blockers, tech updates of general dev interest (like an important class introduced) or more likely seek input on how to solve a problem technically. A huddle should be short or else it becomes “dev hurdle”“dev huddle”“colocation”“blockers”“evolutionary design”“inclusivity”“collective ownership”“feedback”“collaboration”
- Continuous integration: every code commit triggers a series of automated test suites, including the dev-written unit tests as well as the QA-written functional tests. No one checks in on a broken build until resolved. This helps catch integration issues early.“continuous integration”“information radiator”“build”“working software”“smoke tests”“automated tests”“fail fast”“feedback”
- BA/QA volleyball: a quick validation that all acceptance criteria have been met satisfactorily at a high level glance. This includes the devs who worked on the user story as well as a BA and a QA.“validation”“confirmation”“acceptance criteria”
- The wall is typically up to date: as soon as a story gets dev complete, it is moved from one swim lane to another, similarly for a blocked story, and so on.“visibility”“transparency”“story wall”“information radiator”
- Velocity chart or barometer: another information radiator of how well the iteration is going“story points”“velocity”“information radiator”“big visible chart”“visibility’
- BAs working with stories for the next iteration“iteration planning”“just in time”“changing requirements”“business analysis”
- QAs are writing automated functional tests for stories; simultaneously they identify scenarios of upcoming stories based on BA/client inputs“automation”“functional tests”“scenarios”
- PM is working on staffing plans: while taking care of blockers and internal/external communication
- Evening catch-up call: Remember we are distributed… time to mention any follow-upsneeded. This is attended by entire offshore team and the onshore team as well, including client developers“distributed”“colocated”“communication”“transparency”“customer involvement”“collaboration”
- Last day of iteration: mostly preparing for showcase and Iteration Planning Meeting
- This is a pic of another day’s standup (doesn’t matter if we’re wearing the same clothes!!)… anyways, it’s not very different except…
- PM: “Guys, we have a showcase today! How many stories will be done by noon? Who is preparing the sandbox?”
- Iteration Planning Meeting: sharing of current iteration’s achievement and upcoming iteration’s plan, typically done over webex involving client stakeholders and the entire team.“Iteration Planning Meeting”“IPM”“sprint planning”“just in time”“adaptive planning”
- Showcase: the stories completed in the iteration are functionally demoed to client stakeholders by onsite BAs, highlighting working software as a measure of progress and a way of getting feedback.We thought not to embarrass our clients with pictures of onsite… but yeah, some projects have their showcase during overlap hours and are driven from offshore using webex. BAs need not drive the showcase always, anyone from the team can do so.“showcase”“demo”“working software”“feedback”“collaboration”
- First day of the iteration: mostly spent in sharing results of IPM including story overview, and also a retrospective of past iteration
- This is a pic of another day’s standup yet again (yes, doesn’t matter if we’re wearing the same clothes!!)… anyways, it’s not very different except…
- PM: “Guys, we had a great showcase yesterday! Excellent job everyone! We planned for 81 points and delivered 78! Some points are still in dev… Oh, and remember retrospective at 12 noon!”“points”“iteration”“velocity”
- Burn-up chart: this gets updated every iteration end… simple chart but says a lot: cumulative tracking of story points completed per iteration, plotted against planned burn-up. Another similar chart is Burn-down which plots story points remaining after each iteration.“information radiator”“burn-up chart”“burn-down chart”
- Retrospective: we have a meeting every iteration end to discuss, based on experiences in the past iteration, what went well, what could be improved, and what needs more thought or discussion. Such a meeting is typically facilitated by someone outside the project.“retrospective”“facilitator”“transparency”“honesty”“feedback”“continuous improvement”“adaptation”
- Post-IPM: the team gets functional/business insight into all the stories planned for the iteration, and shares a realistic feel of how long each story could take (each story has a pair look into it before the meeting)“Post-IPM”“context sharing”“estimation”“replanning”
- The project typically continues similarly from iteration to iteration. The times when different sort of activities take place are during the start of a release and during the end of it: the start involves a phase of discovery (functional and technical), and the end involves a phase of deployment-related tasks. We’ll talk a bit about the start of a project:Before a project starts, we need a product discovery or requirements gathering/understanding phase. This leads to an initial project plan.“requirements gathering”“business context”“technical overview”“high-level architecture”“release planning”“product backlog”
- Whiteboarding: devs and architects collaborate to talk about existing systems and how the new system to be developed might look like at a very high level architecturally“technical overview”“architecture”
- Estimation in story points: relative units. A representative sample of devs sit together, understand one story at a time from the BAs or Product Owner and estimate in Fibonacci units (or similar relative units). If a story is estimated at 3, it is assumed to be about 3 times as complex as a story estimated at 1. If different devs throw separate numbers for a story, they talk out their reasoning and assumptions, and then throw again until a close enough consensus is reached.“estimation”“story points”“Fibonacci”“powers of 2”“t-shirt sizes”“ideal days”“planning game”
- Team room during discovery phase. Run as a mini-project: deliverables are project release plan, staffing plan, master story list“product backlog”“release planning”“planning game”
- We still manage to have fun after spending hours on coming up with stories and estimates.Can you recognize one of the Agile Manifesto’s original signatories in this pic?
- Agile Manifesto: following it in spirit in the things we do. Different teams may do so differently but the process and practices do not matter as much as the principles and values.