In todays world, the mantra is innovate or die.
You’re either climbing ahead or falling backward … there’s no hanging out in the middle.
And some folks are actually leap frogging ahead.
Disruptive innovation is keeping everybody on their toes.
Whether you are re-imagining you or your company, or you are driving innovation in your process, product, or capabilities, there are skills you can learn to be a lot more effective in your innovation efforts.
It’s a crazy world where a One-Man Band can write an app, serve it up on the Cloud, and change the world. It’s also a strange world where a little idea can be a big shot heard round the world. It’s a scary thing for businesses when a handful of developers can spin up a new service in the Cloud and instantly make a business obsolete.
What can you hold on to in this crazy world? What can you latch on to, if you want to rise above the noise, and instead of getting washed out by a wave, be the one that makes the waves?
There are several things, but I’ll boil them down to this:
- Use your customer as the North Star (and remember that some customers are better for you than others)
- Share and scale your unique value to the world
- Adapt or die
What happens to a super successful business or a super effective person when the landscape changes under their feet?
It depends on how they adapt
Nature favors the flexible. Darwin taught us that.
You have to get your bold on, and embrace innovation as your shiny sword to do battle against challenge and change, but most importantly, to create the change that serves you, and those you serve.
I’m taking a fresh look at innovation, as well as going back through hard, expensive lessons I’ve learned in the past. Whatever doesn’t kill us makes us stronger, so my battle scars are a healthy reminder of the lessons I’ve learned on how we can use innovation to leap frog ahead, as well as change the playing field (heck with changing the game, change the field and be the disruptor.)
Believe it or not, Peter Drucker was a wealth of wisdom when it comes to innovation. Many of you know him as the wise and wonderful professor of business and guru of management. But when you read through a lot of his work, he was incredibly insightful and pragmatic when it comes to creating a culture of innovation.Innovation Nuggets to Get You Started on Your Innovation Journey
I’ve got a ton of innovation books, but one that I’m really liking lately is Out Think: How Innovative Leaders Drive Exceptional Outcomes, by G. Shawn Hunter. I’ve been sharing some nuggets from the book, and it’s been reminding me what it takes to build a culture of innovation.
If you want to start your innovation journey, and create a culture of innovation, here are a few posts to help you on your way:
If you need to remind yourself what innovation feels like or what’s possible, be sure to soak up some powerful words of wisdom:
In my Innovation Quotes, I’ve also included a special section to light up what Bill Gates, Steve Jobs, and Walt Disney teach us about building a culture of innovation.
Let’s boldly go where we have not gone before.
Note: this is not an April Fool – honest!
I’ve been watching the #NoEstimates conversations with interest and decided its about time to pitch in with my own perspective. I don’t want to take any ‘side’ because like most things, the answer is not black or white. Estimates can be used for both good and evil. For me they are useful as a sensing mechanism. Put another way, by estimating, I can get a sense of how well I know my actual capability.
Lets take an example. I’m taking part in a 10K run this Sunday (*) and I am estimating that I will complete the distance in 55 minutes. This is based on an understanding of my capability from participating in regular 5K runs, and more general training runs over a 10K distance. I’ve never run an official 10K race, let alone this course, and I don’t know what the conditions will be like, but I’m aiming for 55 minutes. If I run quicker and do better than my estimate, then my actual 10K capability is better than I thought. If I run slower and do worse than my estimate, then my actual 10K capability is worse than I thought. Either way, I will learn something about how well I know my 10K capability.
What helps even more with that learning is regular feedback! I use MayMyRun on my phone to track progress and give me feedback every kilometre for total time, average pace and last split. This could be considered a distance-based cadence. I could probably also use a time-based cadence to give me equivalent feedback every few minutes. This feedback on a regular cadence helps me decided whether my estimate was way off, or if I should slow down because my pace is probably unsustainable, or speed up because I feel I can push harder.
How does this relate to product development? Well, we can use estimates in the same way to get a sense of a teams delivery capability, and use regular feedback to learn whether we’re making the progress we thought, and need to re-plan, slow down or speed up. Time-boxing, with Story Point estimates and Velocity can provide this time-based cadence and feedback. Alternatively, how long it takes to complete 10 User Stories can be used as a distance-based cadence and feedback.
To sum up, I recommend using estimates to sense capability and create feedback for yourself. I don’t recommend using them to make promises and give guarantees to others. Or maybe we could just call them sensors instead of estimates?
(*) Of course this post is primarily an excuse to invite readers to sponsor me. If you’re so inclined, or would like to show support for this post in a charitable and financial way, then please head over to my JustGiving page and do so there
Update: My final time was 49:23 based on the timing chip, or 49:30 from the starting gun. I’ve learned that I’m better than I thought I was, and next time I’ll be estimating 50 minutes!
Another great article by Mike Caspar: Consider the ability of your Stakeholders to come to your Sprint Review or Demo before declaring it. From the article:
If you are in an environment that is struggling to get stakeholders to your review, ask yourself if you have chosen an impossible day of the week for this ceremony.
Please, for the sake of your team(s)….
When considering when your Sprint will end,
think of the ability of your stakeholders
to actually show up once in a while!
Stakeholders are people too. They don’t want to let the team down either.
Mike has great experience working with Scrum teams and I hope you read through his other articles as well.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!
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 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 […]
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 […]
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 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 […]
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 releaseEstablishing 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.
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.
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
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.)
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.
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.
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:
- Initial (chaotic, informal, ad hoc, heroic) the starting point for use of a new process.
- Repeatable (managed, documented, process discipline) the process is used repeatedly.
- Defined (institutionalized, integrated) the process is defined/confirmed as a standard business process.
- Managed (strategic, quantified) best practices are shared and process management and measurement takes place.
- 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
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
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
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?
- Erfolgreiche Meetings in drei Minuten
- Agile Brazil 2010 in Puerto Alegre
- 5 min on Scrum | Es gibt noch viel zu tun
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!
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.
Christian Johner u.a. (2011): Basiswissen Medizinische Software. dpunkt.verlag
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.
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.)
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:
- We have knowledge workers. As soon as we recognize that they are knowledge workers, it changes things.
- Minimize WIP. Simple version: Only one project per Team. Forget keeping all these other projects ‘in-flight’.
- A Team learns. Have a Team, and appreciate the Team as a learning unit. Help them be a great Team.
- Self-organization. Allow them, within some basic constraints, to self-manage and self-direct.
- “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.
- Subtle control. Use it, and do not use ‘power’ control. Includes ‘control by love’ as Takeuchi and Nonaka say.
- “Failure is good”. Failure where we learn and improve leads to real innovation. Embrace it.
- “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