Wir segeln rückwärts
31.07.2011 
Kommentare deaktiviert | 
Fotos, Unterhaltsames | Tagged: Project management, Projektmanagement, Segeln | 
Permalink 
Posted by Andreas Heilwagen
Scrum Pattern: Thought Leader
29.07.2011
| Context | A Scrum Team is learning self-organization. |
| Problem | The Scrum Team does not see a recommended change. When Scrum Teams develop, they may not yet see the broad picture with all implications like a manager, working on a different level. But a manager should not bring problems or risks to the teams attention himself, otherwise the process of becoming self-organized will be harmed. |
| Forces | too little/too much external guidance too little/tto much risk of failure for the Scrum Team |
| Solution | Bring the issue to the team’s attention via a proxy Choose a Thought Leader in the team like a wise fool, public character or somebody you want to grow and bring the issue to his/her attention. Thus the team does not become alianated by a manager interfering, although it may take more time until the issue will be successfully managed. |
| Resulting Context | The Scrum Team continues on its path to true self-organization and the issue gets the required attention. |
Kommentare deaktiviert | Scrum | Tagged: Project management, Projektmanagement, Scrum | Permalink Posted by Andreas Heilwagen
Scrum Pattern: Feature Team
28.07.2011
| Context | A Development Team is being set up. |
| Problem | Which are the right candidates and skill sets? It is already well known how to combine suitable characters to build a successful Development Team, but often teams are build around layers and modules like frontend development, database etc. |
| Forces | too little/too much specialization too little/too much dependencies on other teams |
| Solution | Build a Development Team with minimal depedencies and a complete skill set When choosing team members, put together a list of required skills first. These skills should be suitable to build a done increment with a minimum to work required by teams and collegues outside the team. The self-reliant Development Teams can produce increments faster and with a higher probability to meet the forecasted scope per Sprint, than teams waiting for dependencies. Besides that, team morale is higher because the Development Team knows, that is has all the necessary skills on board and can do the increment on its own. |
| Resulting Context | A potential high-performance Development Team can start with a Sprint. |
Kommentare deaktiviert | Scrum | Tagged: Project management, Projektmanagement | Permalink Posted by Andreas Heilwagen
Scrum Pattern: Sustainable Pace
27.07.2011
| Context | A Scrum Team is working overtime during a Sprint. |
| Problem | Working hours are increasing while productivity and quality is decreasing. Development Teams are often driving/driven hard to reach a goal by working overtime (“crunch time”). And if this tactic seems to produce the desired result, it is being done again and again. Driving a team too hard produces errors and burn out. |
| Forces | too little/too much working hours vs. results too little/too planning |
| Solution | Keep a constance pace and avoid deviations External dependencies may lead to “crunch time”, but the cost of increasing working hours has to be paid afterwards because there is a limit to how many hours team members are productive and deliver high-quality results. And above that, people take their problems home which they encountered at work. So problem solving continues outside the office, often on the subconscious level. Working 8 hours a day is a good goal if the productivity during that time is high. Trying to work longer often means distributing the same work throughout a longer timespan. So get the Scrum Team to perform during a fixed timespan each day and limit overtime at all costs. To support the Development Team, it is highly recommended to plan for unexpected complications in advance and product high-quality input for the Development Team. Try to avoid delays and bad planning on the product management level as it backfires during the realization phase. |
| Resulting Context | Velocity, quality and working hours are brought back to normal. |
Kommentare deaktiviert | Scrum | Tagged: Project management, Projektmanagement, Scrum | Permalink Posted by Andreas Heilwagen
Deep-diving into the new Scrum Guide – the new events
26.07.2011
As discussed yesterday, the Scrum Guide 2011 brings updated roles. Besides that, the events have changed too:
Sprints
A new requirement is, that Sprints have the same length throughout the development of a product. In my opinion, Sprint lengths may vary if there are good reasons, but the Sprint length should be kept the same if possible.
While the Sprint length is now fixed, the scope is not as written down in the old Scrum Guide (“[…] team commits to doing a PBI in the sprint […]“). The Development Team now does its best to create a “forecast” of what it can achieve during a Sprint. If necessary, the scope can be renegotiated while the Development Team learns more during the Sprint as long as the Sprint Goal is still valid.
Daily Scrum
There is a now goal for the Daily Scrum now: “create a plan for the next 24 hours”. The exchange of information between the Development Team members is still there, but it is more important to assess progress towards the Sprint Goal and to formulate how to reach it each day.
Sprint Backlog
Again, the Sprint Backlog does not contain Technical Tasks anymore. It contains Product Backlog Items (PBIs) which denote the plan to deliver the product increment and realizing the Sprint Goal. New PBIs are added by the Development Team during the Sprint as more is learned. During the Sprint Planning, PBIs from the Product Backlog are moved to the Sprint Backlog, so they are estimated. The Scrum Guide does not requires estimates for PBIs added to the Sprint Backlog, although it is implicitely required to estimate the remaining work. How that is done is up to each organization.
Read the rest of this entry »
1 Comment | Best-of, Scrum, Standards | Tagged: Project management, Projektmanagement, Scrum, Standards | Permalink Posted by Andreas Heilwagen
Deep-diving into the new Scrum Guide – the new roles
25.07.2011While reading the 2010 and 2011 Scrum Guides side-by-side, I got a deeper understanding of the update. While the Scrum Guide has been stripped of some best practices to contain only the core, the language and structure have improved a lot. The new guide ends with the clear rule, that you do Scrum if you implement at least the framework described in the guide, otherwise you do something, but not Scrum. To get the removed back practices back to the light, a Best Practice Compendium is planned by the authors.
Now let’s have a look at the changes in more depth.
Product Owner
The rules in Scrum have been defined more clearly and new responsibilities have been added. E.g. the Product Owner is not only responsible for the value of the Product Backlog Items, implemented in a Sprint. He is now also responsible for “ensuring the value of the work the Development Team performs” and that the Product Backlog is “visible, transparent, and clear to all”.
While adding slightly more responsibilities, that borders between Product Owner and Development Team have been blurred as the Product Owner can now have the Development Team do some of his tasks. He remains accountable for the delegated work in any case.
Development Team
Form my perspective, a major change is the reduction of the minimum recommended Development Team size from 5 to 3 team members. The old rule was “7 +/-2″, the new one is 3 up to 9 team members. If a small team is the right choice depends on the scope of a Sprint as the Development Team has to able to turn all Product Backlog Items into Done Increments without delying on dependencies.
Read the rest of this entry »
2 Comments | Best-of, Scrum, Standards | Tagged: Project management, Projektmanagement, Scrum, Standards | Permalink Posted by Andreas Heilwagen
