Skip to content

Feed aggregator

Certified Scrum Product Owner Course

ScrumSense.com - Peter Hundermark - Tue, 04/01/2014 - 15:38

The Scrum Product Owner must lead the project strategically, collaborate with customers and team on a daily basis, and manage the business value.The Scrum Product Owner takes back the accountability from the traditional project manager for delivering the right solution to the customer and end-user. This two-day CSPO course will provide you with the core […]

The post Certified Scrum Product Owner Course appeared first on ScrumSense.com.

Categories: Blogs

Certified Scrum Master Course

ScrumSense.com - Peter Hundermark - Tue, 04/01/2014 - 15:37

The Scrum Master is a leader and a change agent on a mission. Her duty is to help the Scrum Team unlock its potential to deliver more value to its stakeholders. During this intensive two-day course we will teach you how to make a development team, a project or an organisation agile and successful. This […]

The post Certified Scrum Master Course appeared first on ScrumSense.com.

Categories: Blogs

Kanban Foundation Level Training

ScrumSense.com - Peter Hundermark - Tue, 04/01/2014 - 15:33

This 2-day training course provides a deeper understanding of Kanban for knowledge workers. The training is therefore particularly suitable for those who: want to start with Kanban and are looking for initial support have already introduced Kanban and want to check if the implementation complies with state-of-the-art Kanban knowledge This is a certified Kanban training […]

The post Kanban Foundation Level Training appeared first on ScrumSense.com.

Categories: Blogs

Courses

ScrumSense.com - Peter Hundermark - Tue, 04/01/2014 - 15:31

The post Courses appeared first on ScrumSense.com.

Categories: Blogs

Course Events

ScrumSense.com - Peter Hundermark - Tue, 04/01/2014 - 15:02

Certified Scrum Master The Scrum Master is a leader and a change agent on a mission. Her duty is to help the Scrum Team unlock its potential to deliver more value to its stakeholders. During this intensive two-day course we will teach you how to make a development team, a project or an organisation agile […]

The post Course Events appeared first on ScrumSense.com.

Categories: Blogs

Certified Scrum Master Course Events

ScrumSense.com - Peter Hundermark - Tue, 04/01/2014 - 15:01

The Scrum Master is a leader and a change agent on a mission. Her duty is to help the Scrum Team unlock its potential to deliver more value to its stakeholders. During this intensive two-day course we will teach you how to make a development team, a project or an organisation agile and successful. This […]

The post Certified Scrum Master Course Events appeared first on ScrumSense.com.

Categories: Blogs

Managing the Impossible with an Agile Budget

Leading Agile - Mike Cottmeyer - Tue, 04/01/2014 - 14:13
agile budget The Agile Budget

Release planning is without a doubt one of the most challenging responsibilities for agile teams… at least that’s what I’ve experienced both personally and while coaching enterprises through transformations.

Most teams are working to deliver solutions where the question of “what will I get” at the end of a release can not be left open ended. Furthermore, these teams don’t have an unlimited capacity. They are working within what appears to be a constrained iron triangle, cost, time and scope are all fixed. Mike Cottmeyer’s recent blog about the agile home builder, discusses this challenge from the perspective of establishing a categorized budget.

It is an approach that I’ve seen work on several occasions.  The process is pretty straight forward, not easy… but also not complex :)

Here’s a script that I like to use to help move teams from “this is impossible” to, “hey I think we can deliver!”

Getting Started

Before determining how much of the budget should be spent on features, its important for the team to understand the goal of the eventual release.  To help with this, I usually encourage the team to form of a mock press release, announcing their successful release to the world.  Typically this includes key areas or attributes of the release that have made the release impactful to the reader. These are now key success areas for the release

Establishing your Budget Categories

Each of these key success areas start to emerge as high-level categories within the context of a releases budget that can be used to help focus initial scope conversations. From here the key stakeholders can allocate their budget across each of the category areas.

Quick sidebar, the asset that is available for budgeting is usually the delivery system’s planning velocity.

Keep your Eye On the Ball (successful release, budget available)

Now that budget categories are set, the teams need to start working through their release plans and refining their needs for the “right” implementation based on the budget available.  There are many methods for going about this process; but, by far my goto method starts with high-level acceptance criteria for each category, or feature area, that can be clarified through a mix of example user journeys or system interactions. The funds available to each of the categories should be brought down and further applied to each of these so that the planning team remembers to keep its eye on the ball.  A successful release will need to both (1) deliver the functionality needed, and (2) live within the budget that is available.

This is key, without a focus on the budget available (cost) most teams will struggle to limit the scope of a release until its too late. Early budget constraints help to drive out scope that is not critical to the success of a release.

What do you think, what are your favorite ways to vary scope to successfully deliver on previous market commitments?  For more on this topic, take a look at an earlier blog about calculating the budget, in cost, for agile teams.

 

The post Managing the Impossible with an Agile Budget appeared first on LeadingAgile.

Categories: Blogs

Dealing with team conflict and problem solving – Drama Triangle Model

ScrumSense.com - Peter Hundermark - Tue, 04/01/2014 - 13:49

As a Team Coach or Scrum Master, conflict within a team is something we often have to deal with. Over the years I have come across a number of techniques that help resolve team conflict. Regardless of the technique you decide to use, its important to understand or try to see each individuals map of […]

The post Dealing with team conflict and problem solving – Drama Triangle Model appeared first on ScrumSense.com.

Categories: Blogs

Centers of Excellence Revisited

Agile Elements - Tue, 04/01/2014 - 13:30

I first wrote about Centers of Excellence about 5 years ago and it remains one of the most popular topics here. This post summarizes and updates thoughts on Centers of Excellence (CoE) as a way to build a capability to deliver value when specialty skills are needed. It covers:

  • The rationale for creation
  • The qualities of a good CoE
  • How to grow a CoE
  • Getting started

Rationale

A Forrester study demonstrates that building a Center of Excellence (CoE) significantly enhances the ability of an organization to meet or exceed the goals that center supports (in this case getting results from BPM.)

clip_image002

Source: Forrester US and UK Enterprise Architecture and Business Process Management Online Survey

When governance, a support structure, guidance, measurements and shared learning exists across an organization, success is far more likely. Success supports organizational and specific projects goals. A need to gain results should be the primary motivation for creating a center of excellence and serves as the foundation for its creation.

Our own experience bears this out. We recommend and assist in developing CoEs to support various objectives. These CoEs increase the long-term effectiveness of an ongoing program. Because few organizations are able to support a fully functioning CoE at the start of a lean, six sigma, agile, BPM or other improvement program, we recommend starting by deploying a steering committee and getting help with training and mentoring to grow it through a maturity cycle into a full-fledged, effective CoE.

Qualities of a Center of Excellence Definition:

A Center of Excellence (CoE) consists of a team of people that promote collaboration and using best practices around a specific focus area to drive business or customer-valued results.

Some key words:

Team: No one person can possess all the skills necessary nor fill all the roles required for a CoE. It will take multiple dedicated people to deliver results. This does not mean that they need to work full-time in the CoE, but all team members must be fully dedicated to success.Collaboration: Value comes from sharing knowledge, skills, experiences and ownership both inside and outside the CoE. Working well in and across team and organization structure is essential.Best Practices: These take the form of methods, tools, templates, approaches and ideas that have shown to have beneficial application across multiple customers, needs, issues and projects.

Focus Area: The area cannot be too narrow nor too broad. It must be just sufficient to meet a specific, long-term, priority business objective. Example focus areas may be process, product development, six sigma, cardiology, program management, strategy, risk, or other technologies, skills, methods, or areas of study.

Results: A CoE is not a library to create and store knowledge. It can only justify its existence if can deliver value significantly greater than the costs of staffing and running it.

Ego: Leave it at the door. Success is shared and celebrated among all participants. A humble willingness to learn, adapt and improve while helping others grow is necessary at all times.
Responsibilities:

CoEs should serve five basic needs:

1. Governance: Allocating limited resources (money, people, etc.) across all their possible use is an important function of CoEs. They should ensure organizations invest in the most valuable projects and create economies of scale for their service offering.

2. Support: For their area of focus, CoE’s should offer support to their customers. This may be through services needed, project work or providing subject matter experts. Other resources like share facilities for working together and specialty equipment may also be part of the offering.

3. Guidance: Standards, methodologies, templates and knowledge repositories are typical approaches to filling this need.

4. Shared Learning: Training and certifications, skill assessments, team building and formalized roles are all ways to encourage shared learning.

5. Measurements: CoEs should be able to demonstrate they are delivering the valued results that justified their creation through the use of output metrics.

Roles:

A well functioning CoE is built from full and part-time resources:

· Specialty Skill Practitioners: CoE’s staff, build and borrow resources with deep specialty skills as needed from across and outside the organization. The mix depends on the specific vertical and the current priorities and objectives being deployed.

· Analysts: At the core of a CoE are strong analytic problem solvers that understand how to apply skills across a variety of situations to get the best results. This can include traditional business analysts as well as process improvement specialists with skills in six sigma, lean, and agile concepts.

· Managers: Project, program and change managers stitch together the complex dependencies that ensure readiness for working differently.

· Leadership: Supporting a CoE are visionaries moderated by an enterprise prioritization and resource allocation process. These visionaries focus on expanding use of the competencies and challenging others to improve existing and explore new opportunities and relationships to keep the business relevant for an ever changing world.

Growing Centers of Excellence

Different enterprises are at different levels of sophistication in their use of centers of excellence (CoEs) and view them at different levels of strategic importance. Organizational Maturity Models are a good approximation to the stages enterprises will experience in creating CoE’s. This model helps focus an organization, identify the right times for adding capabilities and leaderships and help and move it to deliver increasing levels of value. Our CoE maturity model identifies five increasing levels of maturity for an organization deploying a CoE:

  1. Initial (chaotic, informal, ad hoc, heroic) the starting point for use of a new process.
  2. Repeatable (managed, documented, process discipline) the process is used repeatedly.
  3. Defined (institutionalized, integrated) the process is defined/confirmed as a standard business process.
  4. Managed (strategic, quantified) best practices are shared and process management and measurement takes place.
  5. Optimized (continuous improvement) includes deliberate and continuous process optimization/improvement.

The Initial stage usually exists before organizations begin to recognize the need for CoE’s. Capabilities may initially live in functional organizations or with individuals. In the earliest stages, establish a steering committee or create initial pilot projects to begin to identify and focus skills in an organization.

Organizations begin to move to a Repeatable stage when they start viewing CoEs as an asset to project teams. With this project centric view, they know that teams need support and are looking for a home for the deeper skills they require. Identify leaders for the CoE and other resources with the skills needed for the roles given above. CoE leadership begins to coordinate across projects, train and mentor others, help plan and set scope, and monitor the capabilities they were responsible for building.

To move to the Defined stage, they begin to define and document the standards and practices for their competency. By this stage, a team charter should define the center. Team members should capture best practices in a wiki or similar format and began to more actively manage associated risk and quality. Training and reference best practices should be standardized and help to actively communicate the competencies across the organization.

Making the leap to the next higher level requires strong coordination and, therefore, strong commitment across executive levels. CoE sponsors and leaders should coach executive leadership so that Organizations can gain this commitment to begin to build Managed, strategic CoEs. The focus becomes across an organization with clear support for corporate plans, integrated with corporate score cards, and an actively managed portfolio of initiatives that use their service. The true power of CoE’s begins to be unleashed as more formal career paths are created and development and mentoring become available for the competencies the CoE supports.

Optomized CoE’s continue to build increased corporate value. At this level, the CoE is an asset that is recognized across the organization. They feel ownership for corporate goals and ensure success of projects supporting those goals. Assessments ensure consistent application and improvement of the competencies needed to meet the goals. They take responsibility for the corporate score cards and their associated value. Audits, skill assessments and certifications further improve capabilities. A well functioning, optimized CoE will improve existing business practices and help grow new capabilities within an organization to maximize value to a changing enterprise.

Getting Started

Consider creating a Center of Excellence to build capabilities to deliver business value when strategic objectives or critical capabilities in an organization require ongoing focus and specialty skills. The above discussion defines what is important. Creating a CoE from scratch cannot happen overnight. But, if you are serious about getting started, follow these broad steps:

  • Gain support at the right level with a focus on delivering value
  • Identify people for leadership and other key roles that are passionate about deepening their skills and delivering results using them
  • Document and share skills and methods; get training and mentoring where skills fall short
  • Apply the skills in pilot projects that are important to the enterprise while mentoring others to expand the capabilities
  • Put in place output measures that track results delivered
  • Formalize the team, integrate it with strategic planning and expand it across the organization
  • Continue to improve, adapt and advance capabilities

Categories: Blogs

Coming Soon: WatchMeCode Screencast Subscriptions!

Derick Bailey - new ThoughtStream - Tue, 04/01/2014 - 13:09

Leadbox ad

I’ve finally decided to do it, after so many times I’ve put it off and so many people asking for it… I’m putting together a WatchMeCode streaming service with monthly subscriptions!

The Early Access Program

I’m not switching everything over to the subscription model, just yet. Instead, I’m getting this released and out the door as quickly as possible, with an early access program.  

If you join the early access program, you’ll get:

  • Streaming access to all current WatchMeCode episodes, before anyone else
  • A chance to influence the direction of WatchMeCode by providing early feedback
  • Discounts on additional services as they are added

All for a discounted monthly subscription price of $5/mo! After the early-access period ends, you’ll get to keep the $5/mo price tag. Everyone that signs up after that will have to pay $9/mo.

How To Get In On This

Sign up for my mailing list to get the early access discount!

I’m expecting to have the early access available in the first weeks of April, with the regular pricing hitting sometime in May. So don’t wait too long to join the mailing list! You won’t be able to get the early adopter price if you’re not there.

     Related Stories 
Categories: Blogs

Don't Limit Your Challenges; Challenge Your Limits

Rally Agile Blog - Tue, 04/01/2014 - 13:00

With all the recent talk about agile being dead, we’ve been feeling a dark cloud hanging over us.

Could it really be that it’s time to throw in the towel on agile, to hang up the gloves? Is agile so broken, its principles so polluted? Should we just relinquish ourselves to the couch to watch "Office Space" on permanent loop?

Despite vigorous amounts of coffee and Thriller dance moves, we couldn’t seem to chase this dark cloud away. And then ...

Then it occurred to us that maybe what we really need -- what all of us really need -- is a little inspiration. We need to recharge the very values that make agile so awesome.

We considered agile energy drinks, agile bracelets, and agile ringtones; but then realized, what’s everyone’s favorite form of inspiration? Why, motivational posters, of course.

So, to celebrate this special day, the occasion of our inspiration, we thought we’d share these motivational posters with you, too. Feel free to print out your own copies and frame them for your workspace. We hope you’ll soon feel as inspired as we do!

Teamwork

Leadership

Rally Software
Categories: Companies

Refactor your Specs!

TV Agile - Tue, 04/01/2014 - 12:29
Even in an agile world, specifications often go too far and describe solutions with too much details; all these premature decisions constraint the implementation and remove opportunities. There is a remedy: refactoring the specs, even before refactoring the code. In the TDD cycle, refactoring is the art of restructuring the code to make it simpler, […]
Categories: Blogs

In kleinen Schritten Feedback fördern

Scrum 4 You - Tue, 04/01/2014 - 07:30

Wie kann es sein, dass ich immer wieder aufs Neue erlebe, dass in Unternehmen keine Feedback-Kultur gefördert wird? Die Richtlinien des lösungsorientierten Feedbacks sind zwar meist auf dem Unternehmenslaufwerk zu finden, aber dort verstauben sie in ihrer virtuellen Existenz, statt real angewendet werden. Das ist wirklich schade. Feedback ist unwahrscheinlich wichtig, um das Verständnis rund um die kontinuierliche Verbesserung zu fördern. Gegenseitiges Feedback im beruflichen Kontext zu geben und zu nehmen ist elementar, um eine lernende Organisation aufzubauen.

Aus diesem Grund habe ich es mir zur Gewohnheit gemacht, (fast) nach jedem Meeting, Training bzw. Workshop das Feedback meiner Teilnehmer einzuholen und – wichtig – auch Feedback an meine Teilnehmer zu geben. Hier meine drei Lieblingsmethoden.

Feedback-Tür

Einfach 4 Post-its an die Tür kleben (++, +, -, –) und die Teilnehmer bitten, beim Verlassen des Raumes einen Punkt auf das zutreffende Post-It zu zeichnen. Das geht schnell, ermöglicht Anonymität, und ist wenig disruptiv. Ich wende das häufig bei „Feedback-Neulingen“ an, obgleich die Methode eigentlich immer passt. Man kann bei dieser Feedbacktür den Schwerpunkt auch konkret auf „Return On Time Invested“ (kurz: ROTI) legen, um herauszufinden, wie viel Mehrwert der Termin den Teilnehmern gefühlt gebracht hat. (Achtung: Bei einem überwiegend negativen Resultat sollte jedoch unbedingt eine Nachbesprechung mit den Teilnehmern erfolgen.)

Blitzlicht-Gewitter

Beginnend bei mir selbst, sagt jeder reihum einen Satz. Wie geht es mir jetzt nach dem Termin, wie empfand ich das Meeting, was fand ich gut, was hat mir gefehlt – all das sind Elemente, die hier erwähnt werden dürfen. Kleiner Tipp: Es hilft, einen „talking stick“ herumzureichen (Stift, Ball, Spielzeug o.ä.), um sowohl die Disziplin als auch den Fokus zu fördern. Und wer eine sehr redselige Truppe an Teilnehmern hat, kann ruhig zur Packung Streichhölzer greifen. Wer länger redet, als ein Streichholz abbrennt, der verbrennt sich wortwörtlich die Finger ;)

Wie war der Termin?

Bei einer kleinen Gruppe, die sich ohnedies öfter sieht (z.B. Dev.Team), lohnt es sich, nach Abschluss des Termins die ganze Runde bzw. einzelne Personen zu fragen: Wie war der Termin? Was war gut? Was sollten wir das nächste Mal anders machen? So bekommt man Feedback und der nächste Termin kann nur noch besser werden.

Habt ihr auch das Gefühl, dass eine tatsächliche Feedbackkultur im beruflichen Kontext sehr selten zu finden ist? Wie geht ihr damit um?

Related posts:

  1. Erfolgreiche Meetings in drei Minuten
  2. Agile Brazil 2010 in Puerto Alegre
  3. 5 min on Scrum | Es gibt noch viel zu tun

Categories: Blogs

Announcement: Scrum Team Assessment updates

Learn more about our Scrum and Agile training sessions on WorldMindware.com

The Scrum Team Assessment has been used by 36 teams so far including 15 teams in Asia.  The organizations that have used it are involved in many industries including high tech, mining, media, human resources, engineering, telecomm, and financial services.  We launched the official “Professional” version in January and have great success with teams using it to improve their Scrum and Agile practices.

Two interesting results to come out of the Scrum Team Assessment so far:

  • Most Scrum teams are scoring “B’s” and “A’s” on the Scrum rules
  • Organizations are doing a poor job of supporting their Scrum teams to encourage high-performance

Of course, this is still a pretty small sample size.  I’m looking forward to that growing significantly over the next few months.

The latest update of the Scrum Team Assessment includes the following changes:

  • More complete statistical data about how your team compares to other teams
  • Updated expert system rules (these will continue to evolve!)
  • New and updated recommendations
  • Numerous report formatting improvements for better clarity
  • Several minor bug-fixes

This is a minor revision to our “Professional” level tool.  We are still planning a big announcement for new “Basic” and “Advanced” pricing levels soon!  Stay tuned…

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
facebooktwittergoogle_plusredditpinterestlinkedinmail
Categories: Blogs

Announcing Rally Insights (Beta)

Rally Agile Blog - Mon, 03/31/2014 - 15:00

If you’re like us, you want to improve the productivity, quality, predictability, and responsiveness with which you build things. But what’s the best way to really improve your performance? You need to first understand where you are, have the means to get better, and measure your progress over time.

Now Rally can help you improve with new benchmarking tools that let you understand, adapt, and measure your performance.

Welcome to Rally Insights.

Rally Insights, currently in beta release, gives you the ability to compare your own performance against a benchmark of over 13,000 teams. Compare the performance of a single team (or program, or entire organization) to its history … or compare it to the average of teams in the workspace … or compare it to an industry benchmark.

To use Rally Insights, just look in the upper left corner of Rally: it's now a product picker! 


Select the Rally Insights icon to get started.

You’ll see an overview of your team’s performance compared across the industry; after providing qualitative information about your team through a quick (10-15 minutes) survey, you can even drill down to see details for each dimension of your performance (productivity, predictability, quality, responsiveness.)


Rally Insights builds on the Software Development Performance Index (SDPI) and research that quantifies what behaviors lead to the best performance. This research already has helped teams improve and make essential tweaks that drive more value in their work. To learn more, check out the video series on the Impact of Agile Quantified.

Try the Rally Insights Beta and get your own Rally Insights. Contact your Rally technical account manager or email us at insight-feedback@rallydev.com for more.

Larry Maccherone
Categories: Companies

Medizintechnik – im Dickicht der Normen

Scrum 4 You - Mon, 03/31/2014 - 07:30

Keine Frage: Die Medizintechnik ist ein stark regulierter Bereich. In forschenden und entwickelnden Unternehmen kann das Dickicht an Richtlinien, Normen und Verordnungen zu einem permanenten schlechten Gewissen führen. Gerade in Entwicklungsteams hängt das Thema Dokumentation dann wie eine schwarze Wolke über dem Projekt – nicht selten wird die Umsetzung der regulatorischen Anforderungen so lange wie möglich hinaus gezögert, um sie dann ganz zum Schluss mehr schlecht als recht auf Papier zu bringen.

Dabei geht es auch ganz anders. Regulatorische Anforderungen sind weder Metaphysik noch Mystik. Wer sie kennt und beherrscht, der wird sie bald so normal und banal finden wie Zähne putzen oder Hände waschen. Es geht am Ende darum, sie in den Entwicklungsprozess so einzuflechten, dass sie permanent eingeübt werden. Dazu muss man sie jedoch erst einmal kennen.

Ein guter Überblick über die gängigen Anforderungen ist recht schnell hergestellt. Denn die regulatorischen Anforderungen in der Medizintechnik beziehen sich im Wesentlichen auf vier Bereiche, für die es in Europa jeweils eine maßgebende Norm gibt:

  • Qualitätsmanagement mit der Norm EN ISO 13485.
  • Risikomanagement mit der Norm EN ISO 14971.
  • Lebenszyklus-Prozesse mit der Norm EN 62304.
  • Gebrauchstauglichkeit mit den Normen EN 62366 und EN 60601-1-6.

Jedem dieser Bereiche wird in den kommenden Wochen ein einzelner Beitrag gewidmet sein. Heute geht es um die Entkräftung einiger Vorurteile, die einen normalen Umgang erschweren.

Vorurteil eins: Die Anwendung der oben genannten Normen ist verpflichtend.

Falsch. Hersteller von Medizinprodukten sind allein dazu verpflichtet, die Anforderungen bestimmter Richtlinien zu erfüllen (v.a. die Medizinprodukt-Richtlinie 93/42/EWG). Die dort formulierten Vorgaben sind jedoch so allgemein gehalten, dass sie nicht unmittelbar handlungsweisend sind. Beispielsweise findet sich dort die Forderung, dass “durch Anwendungsfehler bedingte Risiken aufgrund der ergonomischen Merkmale eines Produktes” so weit wie möglich reduziert werden sollen. Wie die Umsetzung geschehen soll und welcher Prozess dafür anzuwenden ist – darüber sagt die Richtlinie nichts. Die europäischen Normen füllen dieses Vakuum und treten als Umsetzungshilfen der Richtlinie an. Mehr noch: Wer die europäischen Normen einhält, der kann davon ausgehen, dass die entsprechenden Anforderungen in der Richtlinie ebenfalls erfüllt sind (im Fachjargon sagt man, die Norm sei mit der Richtlinie “harmonisiert”).

Vorurteil zwei: Die Normen für die Medizintechnik sind ganz spezieller Natur.

Nicht überall. Die Norm zum Qualitätsmanagement (EN ISO 13485) ist beispielweise in großen Teilen deckungsleich mit der weit verbreiteten ISO 9001.

Vorurteil drei: Software-Entwicklung ist den gleichen Richtlinien unterworfen wie die Hardware-Entwicklung.

Seit ihrer Überarbeitung im Jahr 2007 findet sich in der Medizinprodukt-Richtlinie die Forderung, dass der Software-Lebenszyklus nach dem Stand der Technik entwickelt werden soll. Die dazu korrespondierende Norm EN 62304 beschäftigt sich nur mit der Software-Entwicklung und beschreibt die einzelnen Phasen von der initialen Produktplanung bis zur Wartung. Spannenderweise legt sie sich nicht auf einen Entwicklungsframework fest, sondern bleibt hier offen. Inkrementelle und evolutionäre Ansätze werden als mögliche Herangehensweisen explizit erwähnt.

Literatur:
Christian Johner u.a. (2011): Basiswissen Medizinische Software. dpunkt.verlag

Related posts:

  1. Mit Agil richtig dokumentieren
  2. Scrum und Festpreis
  3. Scrum History | Ken´s Talk über Qualität

Categories: Blogs

Short Overview of Estimation

George Dinwiddie’s blog - Sun, 03/30/2014 - 21:16

Back in 2008, Bob Payne and I were working with a team learning to practice Agile Software Development. They were doing quite well at a lot of things, but their sprint velocity bounced up and down like a yo-yo. The sawtooth velocity chart indicated, since they were clearly delivering value at a pretty steady pace, that they were not very good at estimating stories. Bob suggested to me that they might do as well, with less effort, by counting the stories instead of estimating them.

We did a bit on number crunching on the data we had, and it seemed to support that hypothesis. We put out a call on some mailing lists seeking other datasets to examine.

Bob Payne and I have been considering the effectiveness of story estimates for planning via Yesterday’s Weather.  We’ve looked at some historical data from a team we’ve worked with, comparing the power of story points and a simple count of the story cards.  The results looked interesting to us, so we’d like to look at a wider set of data.

If you’d be willing to send us data from your team(s), we need historical data for a series of iterations of a team, containing
- the number of story points completed for the iteration
- the number of stories completed for the iteration
- the range of story points (low to high) for the stories of the iteration.
If this last value isn’t easily available, then the range of story points generally used by the team will do.

Thanks for your help.

The responses were encouraging. We submitted a session proposal to the “Agile Frontier” stage of Agile 2009. Unfortunately, it was not one of the 18 proposals accepted for that stage. We tried again, a few years later, and presented What’s the Point of Story Points at Agile 2012 to an over-stuffed room.

In this session, we said many of the things that people calling for “No Estimates” are saying.

  • Estimation is not the goal, and can distract us
  • Estimation wastes more time and effort than it’s worth
  • Estimation encourages too-detailed planning, which then encourages “sticking to the plan” due to the sunk cost
  • Estimation is fractal, and grows as we work in finer detail
  • Velocity and estimates get treated as things they are not
  • If we work in priority order and limit work-in-progress, estimating the amount of work that will fit a timebox is less important
  • If we work on things that are an order of magnitude more valuable than the cost of producing them, then estimation of cost is less important

But a funny thing happened. While arguing against estimates, I found some residual benefit for estimation. From a business perspective, it’s quite valuable to project into the future to predict what might happen, and to make contingency plans, if needed. Making estimation less important does not make it unimportant.

Since that time, I’ve been asking different questions. In particular, what is the residual importance of estimation? I’ve come up with a number of ideas. In no particular order:

  • Estimation allows us to bring past experience to bear on future work.
  • Estimation is a valuable technique for making decisions, but it is not the only technique, nor is it always applicable.
  • Estimates can be used to communicate to stakeholders, particularly those outside your organization, that you have the relevant experience to understand the work and have paid serious attention to their request.
  • Estimates can be valuable for routine business activities such as planning release dates, managing risk, summarizing a situation for executive stakeholders, coordinating with parallel efforts, choosing between alternatives, and justifying decisions that spend someone else’s money.
  • Estimates are based on assumptions, and using them as a hypothesis can provide early notice that those assumptions might be incorrect when actuals differ from the estimate.

When we have a clearer idea of what we want an estimate to accomplish, we can then ask how can we achieve the important goals simply?

I’ve previously suggested that “Continuous Estimation” might be a worthy tag, in the vein of continuous integration, continuous improvement, continuous design, and continuous planning. I think “Extreme Estimation” also has merit—pushing the limits of estimation to the extreme. The tagline “No Estimates” seems problematic, to me.

  • Naming something for what it is not gives little information.
  • Telling people not to do what they’ve been doing, or even appearing to tell them that, is needlessly antagonistic.
  • I find that I do not want to eliminate all estimates, after all.

When I wrote the title of this article, before starting it, I estimated a “short” overview. As you can see, it’s not so terribly short. Such is the nature of estimates—they represent our best understanding, and sometimes our hopes, at the time we made them. We should always keep in mind that they are just estimates.

Categories: Blogs

Culture & Agile & Change at the NYC Scrum Users Group

Agile & Business - Joseph Little - Sun, 03/30/2014 - 18:06

We had a great discussion.  The group was great, very active participation. Thanks especially to Rob and Mary.  And to many old and new friends.

Here is the slideshare: http://www.slideshare.net/jhlittle/changing-culture-v6-nyc

We talked mainly about Fearless Change.  This is the work of Mary Lynn Manns and Linda Rising.  And they are soon to publish a second version of their book: Fearless Change (see Amazon, for example).

Here is the Appendix to the book, updated: AppendixFebruary2011
Wonderful list of the Patterns.

Here is an article that roughly summarizes the book: Leading Fearless Change

And here is the URL to more information: http://www.fearlesschangepatterns.com/

We also talked about Open Agile Adoption.  My one sentence summary: inviting everyone to participate in the change. Or even to openly complain that they are bothered.

The second sentence: Use Open Space to enable them to self-organize into participants in the change. (If you don’t know Open Space, then google Open Space Technology.  You need to know about it.)

Related to my ‘Little’s Second Law”: “People are remarkably good at doing what they want to do.”

See the slideshare above for more.  And also see: http://newtechusa.net/open-agile-adoption/

Dan Mezick has the Open Agile Adoption Handbook coming out ‘real soon’.

There is of course much more to the ‘agile culture change’.  Many more wise guides. But these are two great places and 3 great people to start with.  Do not be overly influenced by the characteristics of the people.  The people have their ‘positive’ and their ‘negative’ aspects, depending on who you are.  Give their ideas a ‘fair’ chance, and try to put your positive or your negative biases aside.  For example, I personally find Mary Lynn Manns a completely likeable person, but that does not make her ideas ‘correct’. (Still, I think the ideas are wonderfully simple and useful. And the action is: we must DO them more.)

 

twittergoogle_plusredditlinkedinmail
twitterlinkedinrss
Categories: Blogs

What to tell the Executives?

Agile & Business - Joseph Little - Sun, 03/30/2014 - 17:41

It often turns out that they are not as dumb as you think.  So, first, be patient and be hopeful.  Too many of us start the conversation feeling helpless and defeated.  Do not; they will understand eventually.  (I am of course speaking to ‘an agile guy’, whom I am imagining as not a Manager or Executive, and not too familiar with what their world is like.)

To a Manager or Executive who is approaching Agile-Scrum for the first time: Welcome! It is actually going to be great for you, much better! ….

Make sure someone takes the time to explain it to you. And, please, accept that it will be harder to really understand than you expect.  It is simple, but hard. Is it ok if I use ‘love’ as a metaphor?  In some ways, very very simple.  But how do you explain it to your 18 year old daughter?  Ah, as you see, not so simple anymore. … OK, you might prefer a tennis metaphor or a golf metaphor. Key: It’s a big change.  Give yourself time to fully work through it.  And accept that you will mis-understand a lot at first.  For the first 2 years.  It’s not your fault, it’s not Scrum’s fault.  It’s just hard.

“Some people, if they don’t already know it, you can’t explain it to them.”  (I am talking now, again, to the agile advocate.)  So, find what they already know, and build on that.  And they always know something ‘agile’ already. (And they have also been indoctrinated in the opposite of agile for 10 years.)

So, I have to do a session with Executives next week. Roughly 30 in the room, including the CEO. What should we say to them?

Here is what I have decided to say today.  (I may learn by tomorrow.)  I am focusing on these 8 key ideas or issues:

  1. We have knowledge workers. As soon as we recognize that they are knowledge workers, it changes things.
  2. Minimize WIP.  Simple version: Only one project per Team.  Forget keeping all these other projects ‘in-flight’.
  3. A Team learns. Have a Team, and appreciate the Team as a learning unit. Help them be a great Team.
  4. Self-organization.  Allow them, within some basic constraints, to self-manage and self-direct.
  5. “Random carbon units”.  Accept the uniqueness of each person. They are no longer ‘resources’ (plug-replaceable things).  Treat them like real people, with all the good and bad that means.
  6. Subtle control. Use it, and do not use ‘power’ control.  Includes ‘control by love’ as Takeuchi and Nonaka say.
  7. “Failure is good”.  Failure where we learn and improve leads to real innovation.  Embrace it.
  8. “The bad news does not get better with age”.  “We build quality in from the beginning.” Which leads to “You have to slow down to go fast.”  Which is very obvious if you understand, but an enigma within a paradox if you do not.

To be honest, it is probably 3 too many for the ‘first’ time.  People can only absorb a little at a time.  Step by step.

Comments please!  Or send me an email.

Here is the slideshare: http://www.slideshare.net/jhlittle

twittergoogle_plusredditlinkedinmail
twitterlinkedinrss
Categories: Blogs

Soulver: For all your random calculations

Mark Needham - Sun, 03/30/2014 - 16:48

I often find myself doing random calculations and I used to do so part manually and part using Alfred‘s calculator until Alistair pointed me at Soulver, a desktop/iPhone/iPad app, which is even better.

I thought I’d write some examples of calculations I use it for, partly so I’ll remember the syntax in future!

Calculating how much memory Neo4j memory mapping will take up

800 mb + 2660mb + 6600mb + 9500mb + 40mb in GB = 19.6 GB

How long would it take to cover 20,000 km at 100 km / day?

20,000 km / 100 km/day in months = 6.57097681677241832481 months

How long did an import of some data using the Neo4j shell take?

4550855 ms in minutes = 75.84758333333333333333 minutes

Bit shift 1 by 32 places

1 << 32 = 4,294,967,296

Translating into easier to digest units

32381KB / second in MB per minute = 1,942.86 MB/minute
500,000 / 3 years in per hour = 19.01324310408685857874 per hour^2

How long would it take to process a chunk of data?

100 GB / (32381KB / second in MB per minute)  = 51.47051254336390681778 minutes

Hexadecimal to base 10

0x1111 = 4,369
1 + 16 + 16^2 + 16^3 = 4,369

I’m sure there’s much more that you can do that I haven’t figured out yet but even for these simple examples it saves me a bunch of time.

Categories: Blogs

Knowledge Sharing


SpiraTeam is a agile application lifecycle management (ALM) system designed specifically for methodologies such as scrum, XP and Kanban.