PM Hut » Blog Archive » Schedule Questions: Pair Programming and July 31, 2007 | Author: PM Hut | Filed under: Agile Project Management, Scheduling, Time Management Schedule Questions: Pair Programming and the PNR Curve By Mike Griffiths Converting effort estimates into project durations and team sizes is an important part of project planning. How this is done varies from project manager to project manager, to some it is an art, others a science, and to many a case of living with everyday constraints. If your initial project estimates indicate 72 person months of effort how do you best resource it? 1 person for 72 months? Intuitively we know that 1 person for 72 months might work (providing they had all the right skills) but typically business wants the benefits of a project as soon as possible. 72 people for 1 month is extremely unlikely to work, unless the project is simple and massively parallel, like cleaning oil off rocks on a beach. The curved blue line is the PNR staffing curve, the X axis shows time and the Y axis shows costs. The Agile Angle
Scrum : ça ne marche pas votre truc ! Back to Waterfall !!!! J'entends, je vois et je constate ceci : On a fait tout ce que l'on avait lu, on a dit tout ce que l'on avait à dire, on fait du Scrum et notre constat est que ça ne marche pas. Voici quelques résultats des mauvais fonctionnements que j'ai pu constaté. L'équipe L'équipe n'était pas dédié : elle était partagé entre plusieurs projets non Scrum. Donc pas d'implication de l'équipe pas ou peu d'esprit d'équipe Le contenu du Sprint On l'a dit, on le répète, le contenu du Sprint ne doit pas bouger et lors de mes audits, je vois que le "Product Owner" n'hésite pas à modifier le contenu du Sprint, les fonctionnalités, ce qui est attendu. Un objectif qui bouge tout le temps est un objectif qui ne sera pas atteint. La vélocité Bah c'est simple, à chaque fois elle n'était pas calculée !!!! Les estimations Les estimations n'étaient pas faites par l'équipe mais par "l'ancien chef de projet". Confiance et Transparence Aucune ou peu de confiance entre l'équipe, le PO et le ScrumMaster.
About Scrum Features et stories Une feature est décomposée en stories. Une story est planifiée dans un sprint et une feature dans une release. Imaginez que vous développez une application comme Dotclear mon moteur de blog, mais qui n'offrirait pas encore la gestion des tags, ni la possibilité d'attacher un fichier à un billet. Gestion de tags et attachement de fichiers sont des features. Pour savoir à quel moment on les développe, on s'intéresse à leur utilité et on estime l'effort de développement nécessaire. Pour commencer à développer une feature, il faut la décomposer en stories. Par exemple pour la gestion de tags : en tant que blogueur je peux ajouter un tag à un billet afin de faciliter sa rechercheen tant que visiteur je peux obtenir la liste des billets associés à un tag On dit qu'une story apporte une utilité. Le nombre de stories dans une feature varie. supprimer un tag d'un billetchanger le nom d'un tagfaire un nuage de tagsfiltrer par tagssupprimer un tagfusionner des tags Billets en relation :
Managing Software Development: Top 100 Blogs for Development Man Note: The newest edition of this list is available here! Finally, it’s here! The new list I’ve been working on for more than two weeks! This is the top 100 most popular blogs for software development managers. You might already have seen my earlier list: the Top 100 Best Software Engineering Books, Ever. Do you seek more advice for Software Developers, Team Leaders & Development Managers? Get the book! Management 3.0 Leading Agile Developers, Developing Agile Leaders About the NominationsOnly blogs that were nominated are present on this top 100 list. The idea of this list is to promote popular blogs that are interesting to software development managers. About StatisticsThe nominated blogs have been rated using five different statistics. Google Page Rank (PR): The page rank for each blog indicates a blog’s relative importance on the Internet (by analysis of the weight of other sites linking to it). Let it be known that I don’t care if people think my system sucks. There, I admitted it.
Working with the Product Backlog Agile Product Management with Scrum is the product owner’s guide to creating great products with Scrum. It covers a wide range of agile product management topics including envisioning the product, stocking and grooming the product backlog, planning and tracking the project, working with the team, users and customers, and transitioning into the new role. This article is an excerpt (Chapter 3 'Working with the Product Backlog') from the book; it introduces the product backlog together with its DEEP qualities. Few artifacts in Scrum are as popular as the product backlog. This chapter discusses the product backlog along with techniques for effectively grooming it. The deep qualities of the product backlog The product backlog has four qualities: It is detailed appropriately, estimated, emergent, and prioritized, making it DEEP (I owe the acronym DEEP to Mike Cohn) (. Detailed Appropriately The product backlog items are detailed appropriately, as illustrated in Figure 3.1. Estimated Emergent
Introducing Scrum At Large Animal Games: A Look Back at the Firs Introducing Scrum At Large Animal Games: A Look Back at the First Year of Agile Development Large Animal Games has been in business in New York City since January 2001. For the first several years, Large Animal developed games using informal, homegrown software development methods. "We did a lot of experimentation," says Wade Tinney, co-founder of Large Animal. To track project schedules, for example, teams at Large Animal tried using MS Excel, MS Project, FogBugz, and even tried different visualizations of the project schedule using Adobe Illustrator and Visio. Despite success with some of their practices, teams at Large Animal were still looking for improvements. More critically, Large Animal was finding it difficult to grow, since a set of key team members were needed in certain roles on every project. In early 2006, Large Animal discovered agile development (and Scrum more specifically) and began incorporating some of the techniques into its project teams.
Introduction to User Stories 1. Introduction to User Stories A good way to think about a user story is that it is a reminder to have a conversation with your customer (in XP, project stakeholders are called customers), which is another way to say it's a reminder to do some just-in-time analysis. In short, user stories are very slim and high-level requirements artifacts. 2. As you can see in Figure 1 user stories are small, much smaller than other usage requirement artifacts such as use cases or usage scenarios. Figure 1. Important considerations for writing user stories: Stakeholders write user stories. Figure 2. 2. Figure 3. 4. There are two areas where user stories affect the planning process on agile projects: Scheduling. Figure 4. 5. As you can see in the Disciplined Agile Delivery (DAD) life cycle of Figure 5, there are several distinct "phases" or seasons in the life cycle (some people will refer to the agile delivery life cycle as a release rhythm). Inception. Figure 5. Figure 6. 6. Figure 7. 7. 8.
A Leaner Start: Reducing Team Setup Times Face facts: Teams change I've worked with lots of teams in the past few years, some for very long periods, others for very short times. One common theme I've noticed with many of those teams is that the team composition always changes. Usually, events beyond the control of any project trigger these changes: people fall sick or take holidays, project demands grow, new project opportunities arise or people simply want a change. Agile practices, like daily stand up meetings and pair programming, provide new members with all kinds of incidental information which may in fact be useless if they don't have enough context to hang it on. Queuing theory applied to teams In manufacturing, lead time is traditionally split into four components, including: Setup - The time it takes to prepare the process before you can actually start running. Apply the same concepts to teams and the addition of a new team member and you get something that looks like the diagram below. About the author
Scrum and Long Term Project Planning for Video Games [The agile methodology known as Scrum is rapidly gaining development credence, and High Moon Studios CTO Clinton Keith (Darkwatch, The Bourne Conspiracy) presents this in-depth Gamasutra article explaining how publishers and developers can benefit through regular, focused iteration.] Scrum, an agile methodology, is emerging as a powerfully beneficial toolset for building games. The approach of finding the fun through iteration rather than trying to plan and predict it completely up front is appealing to many developers who have repeatedly been surprised by all the unanticipated problems and discoveries made on the path to creating a game. One of the common misunderstandings of agile is that it avoids any long-term planning in favor of only planning a few weeks out. What agile does not do is support highly detailed long term plans up front. Agile methodologies, like Scrum, focus on continual planning for the entire range of the project.
Adzic » The waterfall trap for “agile” projects Jeff Patton from Thoughtworks held a very interesting session at XpDay last month in London, focusing on a common misconception that causes “agile” projects to fall into the same trap that the waterfall ones typically do. Incremental is not iterative Using a very interesting combination of pop music and rock star images, Jeff Patton told a story of a failed agile project in his XpDay keynote “Embrace Uncertainty”. The problem was that the concept of iterating had been lost and iterations were replaced by increments – making the project fall into the same trap as waterfall projects do. Although both these plans aim for the same thing, the incremental plan does not really reduce the risk of delivering something unsuitable to the client. Dealing with uncertainty However, iterative planning is harder to sell. Follow the money: focus the project on business goals, not on features nor user stories. Image credits: Malene M.
The Future of Software Development In 1975, Frederick Brooks wrote a classic book on software project management called The Mythical Man-Month. In the book, he famously argued that adding more people to a development project will hinder rather than help to get things done faster. The reason is that having more people working on the project introduces a non-linear overhead in communication. Five years before Brooks' book, a software development methodology called the Waterfall Model was coined. We have come a long way since then and learned a lot about making software. With the advent of modern programming languages (Java, PHP, Python and Ruby), rich libraries, and unprecedented infrastructure services like those from Amazon, we are arriving at yet another evolutionary step. Why The Waterfall Model Failed Non-technical people tend to think that software is soft or easily changeable. Yet the accelerating pace of business requires constant changes to software. The problem was that the Waterfall Model was arrogant. Conclusion
Object Technology Jeff Sutherland: High Moon Wins Awards with Sc High Moon produced a great video on Scrum. Check it out! High Moon Studios, part of Vivendi Games, is a game developer currently working on titles for next-generation consoles. The company is founded by game veterans who are passionate about creating compelling, original entertainment experiences. High Moon employs more than 100 people at a state-of-the-art game development facility based in San Diego County, California. High Moon's innovative development methods and employee programs have been recognized by the San Diego Society for Human Resource Management with a "2005 Workplace Excellence Award" and IT Week Magazine as one of "2005 Top 50 Technology Innovators."
Object Technology Jeff Sutherland: Microsoft Vista: Scrum or Not Peter Krantz rants on Scrum, Lies, and Red Tape at the Microsoft Vista project (see below). He's in Stockholm and I'm on a SAS flight over Greenland returning from two weeks in Sweden and Denmark doing several ScrumMaster Certification Classes. While Microsoft adopted Scrum on many programs large and small, I'm not aware of the Windows Vista team using it. Scrum is built on truth, transparency, and trust and was designed to emulate the productivity of the Borland Quattro project where the each developer delivered 1000 lines of quality production C++ code per week. Vista only delivered 1000 lines per developer per year. Philip Su thinks Vista is the largest software project in the world and maybe the longest. Scrum, Lies, and Red Tape by Peter Krantz Philip Su from Microsoft gives us a glimpse of the inner workings of one of the most complex software projects in the world. Broken Windows Theory by Peter Su Vista.