Product vision is super important to the success of your product. I know, its just a simple statement, right? How much impact can it really have? More than you can imagine. A product vision gives us the direction and focus we need to deliver something, anything, that will ultimately solve the problems of a customer segment and deliver value to both your business and to your customer. If it is well-crafted and well-communicated, product vision should permeate everything you do, from business models and product roadmaps to the stories in your backlog and how you execute them.
Here’s a test for you. Take a minute and scribble down the vision statement for the product you’re currently work on. Now here’s another test. Have the co-workers who sit near you do the same without discussing it. Compare notes. Do your notes match? Are some notes still blank? Are any of the notes the same? Do the same test across your organization. If your notes match, you can stop reading now…well, not really, but you obviously work on a product with a clear vision. If you have blank notes or notes that vary widely, read on.
Test number two. When you finally find your product’s vision statement on the company website or wiki, how does it read to you? Is it delusional? Cloudy? Confusing? Dismissive? Heady? Wordy? Lengthy? Boring? Uninspiring? Generic? Maybe a little of all of those.
Don’t feel bad. Some of the best organizations in the world have difficulty using words to define what it is they do, who it is they serve, and what success looks like to them. You are NOT alone, trust me. But you don’t have to wallow in the words of your vision statement much longer. There are some very simple tools that can help you clearly define your product and use it to drive your product’s business model, your product roadmaps, your product-market fit experiments, and your backlogs for your teams. In this post and posts to follow, we’ll introduce several of these tools and discuss how they can help you create a vision that resonates with customers and the people who you work with, and help you constantly align the work you do with the vision you have created.Defining Your Initial Product Vision
When most organizations develop their vision statements, they default to some standard template. One of the more popular templates comes from Geoffrey Moore. While I love Geoffrey Moore and consider him a mentor, I think his traditional vision template leads to rather unexceptional vision statements that all sound the same: “For blah blah blah customer who needs blah blah blah, our blah product is a blah blah blah that will blah blah blah. Unlike our competitors (insert list of competitors that are usually not competitors) our product blah blah blah blah blah…”
You’ve heard vision statements like this before. Somehow, they hit all the right points, but more often than not, every time I see this template used, the vision statement gets very long winded and all I can hear is “blah, blah, blah…”
What I’d rather have is a simple, concise, visual representation of the vision that I can understand and relate to. I’d rather see an inspiring overarching vision that I can get excited about and say “Yes! That’s where I want to go!”. I’d like some detail too…about who it is we’re building for, what problems they have, and how our idea solves that problem. I might even want some info on how our company gets value from what we build, but really I’m more interested in who we are addressing and what their problems are.
Enter Roman Pichler’s super simple Product Vision Board. It’s the tool I turn to most often when I start working with teams to define their product vision. It simple, concise, AND visual. Check it out:
Let’s walk through the sections and see what we need to think about.Steps to Create a Product Vision
First, we need to craft a vision statement. Here’s some simple advice on what to write in this box: Say a lot in just a few words. Pick your words wisely. Don’t be generic. Describe a long-term vision but don’t be overly restrictive. Clear, concise. Calls people to action. Oh, and if you took the two tests above with your co-workers, they’d all remember it…or at least a pretty close flavor of it.
Need some examples? Try something like Innocent Drinks’ vision statement: “Make natural, delicious food and drink that helps people live well and die old”. Too simple for you? Want something a little more “corporate”? Here is Ikea’s: “To create a better everyday life for the many people, we shall offer a wide range of well-designed, functional home furnishing products at prices so low that as many people as possible will be able to afford them.” A little wordy for me, but it does get the point across.
After you’ve wordsmithed your awesome, clear, thoughtful, inspiring vision statement (and if you have, share it here, I’d love to read them), write it in the box, pat yourself on the back, high-five your teammates, and move forward one space.
The next four boxes should be easier. Mostly because they are all hypotheses, or guesses at what you think the right answer is. The first box “Target Group” is all about our customer hypothesis. Who do we believe we are trying to serve? Typically, for a new product, or even existing products, we’re looking at the earlyvangelists. We’re looking for customers who clearly identify with our vision. Notice I did say our solution? We want customers who to buy into our vision. They fall in love with the idea, not the solution. So try that out and see if turns out to be different than the customers you currently view as your target segment. Got it? Good, write one sentence in the box that simply describes these people, pat yourself on the back, high-five your teammates, and move forward one space.
The next box, “Needs”, addresses our problem hypothesis. What do we think the problems of our customers are? Again, don’t fit the problem to your solution. Empathize with your customers and truly try to understand what their problem is. Not what you want it to be. When you think you have a good problem hypothesis, write it in the box in clear, simple terms, pat yourself on the back, high-five your teammates, and move forward one space.
Box number four: “Product”. This is your solution hypothesis. Based on the customers you described, and the problem you identified, what is the minimal thing you can do/build to solve that problem and make them smile? Again, this isn’t rocket science. It’s a guess. First guess. It doesn’t have to be right. It just has to be something you can build, test, and see if your customers smile. Got it? Awesome! Write it in the box in clear, simple terms, pat yourself on the back, high-five your teammates, and move forward one space. You are nearing the end of this game.
Last box: “Value”. This box vexes me a bit and to be honest, I don’t usually fill it in the first time around. So first timers, leave it blank. It’s OK. The world will not end if you do not define the value to your business right now. Why? Because so far, the other boxes have been guesses. Hypotheses need to be tested, validated. Chances are very high that the things you wrote in those boxes will change as soon as you start using the tool we’ll be covering in our next post, the Validation Board.
So for now, feel good that you’ve defined an initial product vision and you are ready to start testing in the real world. Pat yourself on the back, high-five your teammates and grab a beer…or maybe one of Innocent Drinks’ product, they might make you live well and die old.
For specific information on designing teams check out Product Owner Team Design Considerations.
The post Product Vision Tools Part 1: The Product Vision Board appeared first on LeadingAgile.
Then I got an email from a hotel director I stayed at. "If you liked us, click here to tell TripAdvisor. If not, click here to tell me."
Boy, what a decision! He has no idea if I'm happy or not, but an immortal comment on the Social Media is just one click away! Feedback is about more than listening to the customer, it's about guiding the conversation, before it goes viral! Steve Holyer and I made a video, to explain the problem:
Does this resonate with you?
I don’t estimate software defects. Well, I have two exceptions: If I have a backlog of old defects to burn down, I may estimate those. If I have found some new bug that we plan to fix in some later sprint, I may estimate those (though I really don’t like to defer defect fixes). Otherwise, I don’t estimate defects.
Why Not Estimate Software Defects?
Before explaining why, it’s important to pause and consider my context. To get away with not estimating software defects you must have high quality standards, a strong suite of unit tests and a habitual practice of TDD, and you must fix all defects as soon as they are discovered, or at most, 1 sprint later. If that’s not your context, stop reading this and go put TDD into place.
Deciding not to estimate software defects under these conditions is just easier and makes for more conservative release and iteration planning to not estimate defects (or at least not include them in velocity). It’s a simple rule, simple to explain.
Here’s the problem with doing it any other way: If you estimate new defects and include their points in your velocity as you fix them, then you can’t just divide backlog size by velocity to figure out when you’ll be done. By doing this, you are including in your velocity fixed defects but excluding from your backlog the stuff you haven’t found yet. It’s safe to assume you’ll find more defects and so your backlog is growing, whether you recognize that or not. Dividing an inflated velocity number by an underestimated backlog is risky planning. Sure, your burn-up chart may show you a projection of the growth of your backlog and burn-up intercept, but that’s only if you estimate your defects correctly relative to your stories. There’s enough guessing in estimating the rate of growth of your backlog when only considering new story scope increase. Why make it harder by including defects in the computation?The Challenges of Estimating Software Defects
For sake of example, let’s say we have one new defect each sprint, and let’s assume they are each 1 point on average. Also assume an initial velocity of 10 (without estimating the defects) and backlog of 200 points (without any measure for unknown future defects). If I fix the defect without an estimate, I’ll continue to have a stable velocity of 10 . I’ll have a stable backlog of 200. My math is easy: 200/10=20 sprints. This is easy to teach. And it’s conservative.
The alternative, estimating the defect, gives me a stable velocity of 11 but a backlog that increases by 1 point each sprint. This math is, let’s see, the slope is… uh…. something, and we’ve got the intercept, and, uh… oh I don’t know. We can compute this easily if we know the average defect size and the defect arrival rate, but most teams don’t know their average defect size or defect arrival rate. This is harder to teach. It’s even harder to get people to remember and account for an increasing backlog when they are doing back of the envelope figuring in their head.
Additionally, defects are hard to estimate and the estimates we make for defects often do not reflect the same behavior as for stories – they have a different variance, a different distribution and the mean effort per point is typically significantly different than for stories. Relative estimation between a defect and a story is not the best thing.Summary
Finally, if an organization finds themselves not ready to start the next release and they’re going to have the otherwise idle teams fix defects until the Product Owner team gets ready, then why estimate the defects?
Similarly for spikes: I tend to not estimate them, and I execute them as quickly as possible.
I lean towards velocity measuring effort put toward Value Delivered, not for defects, rework, or research. I do this because I care greatly about my release commitment/budget. If I inflate my velocity due to defects and spikes (i.e. things that were unplanned) then I’ll end up over-committing to the release: my velocity number will be higher than the actual known value to be delivered.
Let me remind you that there is a lot of context here that is important. If your team has high quality standards and they fix all defects as soon as they find them or perhaps 1 sprint later, then my approach of not estimating works because they do not allow an increasing backlog of defects to accumulate. If, however, your team defers defects, AND intends to fix them later in the release, then my approach is really, really bad poison and you should estimate all your defects and understand the current arrival rate and the historical defect load per release.
I do make exceptions to this rule and I’ve not always held the same belief. An older post on this subject, Estimating Defects – Using Principled Negotiations, discusses what you might do for a myriad of different contexts.
Bottom line: Track, quantify, and represent the effect of software defects separately.
Zweck des Meetings: Sprint Planning 1
Die Beteiligten meiden Augenkontakt. Hochrote Köpfe, betretene Stille. Es geht nicht mehr weiter. Soeben haben sich zwei erfahrene Entwickler des Teams mit dem Product Owner angelegt.
Streiten. Der Product Owner fordert eine sehr große Story für den zu planenden Sprint, weigert sich jedoch, sie zu splitten. Sie in zwei zu teilen. Die Gründe dafür verstehen die Entwickler nicht. Sie verweigern das Commitment. Als ScrumMaster kann ich der Diskussion aus fachlicher Sicht schon lange nicht mehr folgen. Ich fühle mich gelähmt, frustriert, fast unfähig, zum Ziel des Meetings, dem Commitment zu führen. Klar ist mir nur eines: Die Gründe für diese Bewegungslosigkeit liegen im Verborgenen. Weit unter der Oberfläche, denn die Entwickler überzeugen sachlich und argumentatorisch auf ganzer Linie.
Als klar wird, dass es nicht mehr weitergeht, wird das Commitment um einen verträglichen Zeitraum verschoben, um eine Klärung herbeizuführen und die Gemüter zu beruhigen.
Nach ca. einer Stunde kommt der Product Owner zum Team, lenkt ein und stimmt sichtlich erbost zu, die Story doch noch anzupassen. Die Situation scheint gelöst.
Nach ein bis zwei Stunden taucht die Story im Computersystem wieder auf und … ist unformuliert, aber nicht gesplittet. Die Verärgerung ist den Entwicklern am ganzen Körper und vor allem an ihrer Gesichtsfarbe anzusehen. Die Entwickler bitten mich mit meinen „politischen Fähigkeiten“ – so die Entwickler – um Hilfe und darum, zum Product Owner zu gehen und letztlich zu erbitten, was er doch zugesagt hatte: Die Story in zwei kleinere zu splitten. Ich stimme zu und mache mich sofort auf den Weg.
Ich, als Fachfremder, sehe meine Chance, mir weiteres Standing beim Team zu verdienen. Nun bin ich gefordert und kann meine Fähigkeiten unter Beweis stellen. “Hoffentlich”, denke ich. Es fühlt sich wie ein bewegender Schlüsselmoment für mich und die weitere Zusammenarbeit mit meinem Team an. Ist doch sonst so schwer spürbar, was man an einem langen Tag geleistet hat.
Reden. Ich betrete das Büro des Product Owners. Leider sitzt er noch nicht beim Team. Änderung ist jedoch in Sicht. Ich begebe mich freundlich zum Product Owner und frage ihn mit einem einladenden Lächeln, ob er mir drei Minuten seiner Zeit schenken kann. Ich setze mich zu ihm und danke für die Bereitschaft, über die Story zu sprechen. Ich nehme eine ähnliche Körperhaltung ein wie er, um eine positive Stimmung zu erzeugen und bitte ihn erneut, die Story zu teilen. Es braucht drei Minuten freundliche Worte und ein wenig Small Talk. Der Product Owner stimmt zu, die Story gemeinsam mit mir so umzuformulieren, dass das Entwicklerteam umgehend bereit ist, sein Commitment abzugeben.
„Wie leicht war das denn?“, frage ich mich, kehre voller Stolz zum Team zurück und verbreite die gute Nachricht. Das Team kann nun die neu entstandene und kleinere Story committen.
Verbinden. Ich spüre Freude, Stolz und Erfolg auf ganzer Linie. Mir wird bewusst, was es heißt, ScrumMaster zu sein. Wir ScrumMaster sind das Sprachrohr zwischen den Gemütern, die Mittler zwischen den Parteien, die Mediatoren und Psychologen. Die mit den geheimnisvollen Soft Skills, die Impediments jedweder Art aus dem Weg räumen. Es wird klar, wozu es uns ScrumMaster braucht. In vielen Fällen blockieren die Dinge aufgrund von Befindlichkeiten, Ängsten, Politik oder zwischenmenschlichen Themen.
In meinem Fallbeispiel wird sehr deutlich, dass es oft nur der richtigen Ansprache oder dem Schaffen einer positiven Stimmung braucht, um ein gemeinsames Ziel zu erreichen.
Erschöpft und zufrieden zugleich sinke ich in meinen Bürostuhl und kann kurz darauf das Sprint Planning 1 mit einem einstimmigen Commitment des Teams beenden.
Was habe ich aus meinem Erlebnis mitgenommen? Zum einen wird mir klar, wie wichtig regelmäßige und qualitativ wertige Estimation-Meetings sind, an denen immer alle Teammitglieder teilnehmen. Zum anderen sehe ich die Vorteile, als externer ScrumMaster tätig sein zu können. Frei von Ängsten oder gar Abhängigkeiten kann ich mit verschiedensten Vertretern eines Unternehmens kommunizieren.
- 10 Things about ScrumMasters
- Die Skills eines guten ScrumMasters
- ScrumMaster can not be the Product Owner | 10 reasons
Set-based design is the idea that we keep considering the set of all possible solutions until we learn more through execution. A classic example of this is the design of the Toyota Prius. The vision for the Prius was for a “green car”, but the decision of whether to use a efficient gas, all electric or a hybrid power-train was deferred until all possibilities were explored to the point of knowing about the efficiency and production cost of each. As a result of this approach, this revolutionary car was designed in half the time of more conventional designs.
Avoiding detailed estimates supports set-based design by avoiding the early, uninformed, commitment to a single solution that is required to assign a number (hours, days, points). As mentioned, a no-estimates approach only works with a mature team. The team has to execute in a way to produces the knowledge to refine the set of possibilities first.
For a game mechanic epic, this means that the team finds a way to demonstrate the core gameplay of the mechanic first and refines it every iteration. Teams that build a bunch of parts of the mechanic that later integrates into a fun experience are really doing point-based design; they are choosing the solution first.
From experience, I’ve learned something which sounds intuitively wrong at first:
Set-based design is one of the biggest cost savers you will find.
As demonstrated, it halved the design of the Prius for Toyota. I’ve seen the same on game teams. Set-based design forces teams to focus on the simplest things first and to maximize the work not done. An example I’ve seen is with complex AI systems. Many games start off by creating a list of everything the AI has to do in the game (point-based design). Then an AI engine is created to do them. Although integration is frequent, the AI isn’t really demonstrating emergent value to the player yet. It’s a “work-in-progress that will payoff before alpha”. Somewhere on this road to value, there is a major rewrite of the AI, a reduction in the AI requirements or an admission that “our game’s AI is not going to be very good”.
A set-based approach to this problem starts with asking “what does our AI need to do first?”. The answer shouldn’t be “create path-finding NPCs”. The player doesn’t care about the NPCs path-finding if they don’t add anything to their experience. Perhaps having only NPCs that are close by and interact in a meaningful way is enough. Maybe we’ll discover that we don’t really need them to path-find as much or in the way we'd planned. Maybe there’s some “little trick” we can do to make the player think the NPCs are doing something complex when they are out of sight.
The additional benefit of a set-based approach is that the team is much more connected with the game. They are asking themselves “how do we make the game better” daily. This is better than the question being asked once every two weeks during sprint planning and far better than asking once every three months during release planning! Teams that are more connected to the game have increased opportunities to add value and subtract work that doesn’t need to be done.
Again, I want to emphasize that abandoning estimation is not the goal, but a side effect of teams maturing. The goal is to coach teams to maturity and continuous improvement. When I train new teams, I don’t train them to abandon estimation. That would be like training a snowboarding novice to do a 1080: it’s a fast path to crashing. When a team has reached a level of maturity, they’ll find this on their own (with a bit of coaching along the way).
Like many developers, I’ve been protected from apparently difficult customers by my managers and left to get on with the important job of “writing code”. But this week I left our office and headed out to a technology park to work directly with one of our customers, and after a couple of days of understanding each others needs I’ve rarely felt so excited about “writing code”, because I know it will be valued.
XP & Scrum talk about a customer on the team but I’ve never seen it happen, well not a “real” customer. Proxies aren’t the same, particularly when they are neither dev or customer. With little understanding of either side, they’re stuck on the fence, helplessly documenting and relaying demands with seemingly unquestionable priorities to an increasingly demoralised team. It’s a world away from the customer and developers really understanding each other, so why can’t we do better than this?Fear gets in the way
The developer fears the customer. I’ve spent years assuming developers would love to talk to customers given the chance, but when it came down to it, I’m seeing fear come between us. I feared being asked to do dumb things and not knowing how to say no. I feared having to explain failure and the difficult conversations that follow. Without letting myself be vulnerable I grew conservative, inward looking and start making assumptions based on what works best for me rather than what’s really needed.
The customer fears the developer. She fears being taken for a ride by these alien geeks and looking stupid when they try to dazzle her with their technical prowess. Who can blame them, I see defensive developers making an art out of making people looking stupid rather than be open and share what they don’t know.
The manager fears relationships. It sounds like a terrible thing to say, but it looks to me like many managers want people ‘under’ them to have exclusive relationships with them rather than each other. Holding tightly to our relationships lets us stay in control, but interesting things only happen when loosen our grip and let people collaborate freely.Enlightenment
This is hard, but there is some enlightenment available to those willing to step into the unknown. When we open ourselves up to sharing and learning from each other, we can start to collaborate. Once we begin to understand and attend to each others needs we can start to create something that’s a bit special.Time to build relationships
Can I propose that when it’s not possible to have a real customer on the team, that developers spends at least a couple of days a month with a customer and users? To help build the desperately needed relationships and mutual understanding, Scrummasters and Managers can help facilitate this relationship building. I think this collaboration is perhaps the most important thing we can do if we want to build something that has real value.
I want to move beyond the classic three variable problem of the project (scope, schedule & cost) and envision a model that describe the value that a project represents while maintaining the constraint relationship that these classic triangular relationships represent. Enter the Tetrahedron - a platonic solid. The tetrahedron has four faces, each face is a triangle, it is the simplest form of a pyramid with the base in the form of a triangle.
Highsmith's Agile TriangleJim Highsmith introduce the concept of treating the PM triangle of cost, schedule, and scope as constraints in his Agile Triangle by adding a fractal triangle at the vertex of his triangle of value, quality and constraints. While other's had explained the iron triangle as having an aspect of quality on the inside that one obviously would never vary. Well then if one is not varying quality while do we talk so much about technical debt? Jim does a great job explaining that the traditional aspects are constraints and that the desire of a business is to derive out of these constraints something of significantly larger value than constraint space represents.
"Quality is a value to some person." -- Jerry WinbergDiscussing this with my colleague Rick Stephenson we envisioned a more physical and tactile model. A model that retained the constraints concept from Highsmith, but added the multiple aspects of value -- business, technical and customer value. We desired to represent these three types of value as separate and independent aspects that must be attended to by the project team while staying within the constraints. Yet it is the desire of the project's sponsors to raise the values as high as possible while minimizing the surface area of the constraint space. When these desires are modeled in the tetrahedron with physical objects one can start to get a gut feeling for the tradeoffs that directors and managers must make in the project. Build upon a small constraint base and the pyramid may become unstable. Imagine the table upon which you are building your model to be the platform for your application - when the platform is shaky and unstable the application needs much more base surface area to attain a sufficient height (values).
In the model of the Agile Tetrahedron I made above I cut the business value face a bit and the technical value face even lower. The idea was to show that those faces may not be completely required to deliver customer value within a given release (constraint). Yet, one can see that extending that idea to an extreme may prove dangerous with a shaky platform.
Agile Tetrahedron model: print, cut, fold, play...PDF of Agile Tetrahedron model ver 2.3 - print, cut, fold, play...
How to make the classic PM Iron triangle out of plastic drinking straws.
Beyond Scope, Schedule, and Cost: The Agile Triangle by Jim Highsmith
Join me for a webinar on March 10, 2014 at 7pm Eastern. My topic is “Overcoming 7 Common Pitfalls of Transitioning to Agile in Software Engineering.” I’m speaking as part of the Graduate Professional Studies Spring 2014 Guest Speaker Series.
P.S. If you missed the webinar, here is the audio recording. Enjoy!
Partnership & Possibilities: A Podcast on Leadership in Organizations
EPISODE 9: WORK WITH US
“When I see inequity, here is how I’m responding to it, here’s how I’m trying to shift the behavior, both in myself and in creating the conditions to shift it in others.”
Running time 28:10
What are you seeing in your organization relating to gender roles and gender equality? What type of things are you doing that are helping these more subtle gender equity and equality shifts occur?
Leave a comment on this blog or email us at firstname.lastname@example.org
[Intro] Conundrum faced by women in leadership roles and in the workplace.
[01:14] Review of “Work with Me” by Barbara Annis and John Gray.
[04:54] Gender issues in the workplace, but what are the solutions?
[06:09] Stereotypical male informal networks still exist in most industries.
[10:25] How men and women view gender differences and opportunities in the workplace.
[14:23] Stay-at-home dads becoming more common, but still viewed as a threat by peers.
[18:16] Becoming aware of one’s behavior gives power back to the individual.
[23:48] Women are helping change the leadership paradigm to a more collegial participative way.
WORK WITH ME: The 8 Blind Spots Between Men and Women in Business by Barbara Annis and John Gray
GENDER INTELLIGENCE: How Our Differences Create Value in the Workplace by Barbara Annis and Keith Merron
LEADERSHIP AND THE SEXES: Using Gender Science to Create Powerful Organizations by Barbara Annis and Michael Gurian
The global gender agenda: Women continue to be underrepresented at senior-management levels in Asia, Europe, and North America. McKinsey research suggests some answers.
Study: More men on the ‘daddy track’
Marked Women, Unmarked Men by Deborah Tannen
Lean In: Women, Work, and the Will to Lead by Sheryl Sandberg
Sounds silly, doesn’t it? Yet many traditional command-and-control organizations think they can work this way.
Manager types go behind closed doors and through a series of many meetings come forth with “The Plan.” The plan directs what is to be done, how it is to done, when it is to be done, and by whom it will be done. The software developers who must implement the plan are informed of the plan and directed to “Make It So.”
Almost immediately it seems a question will be raised with the realization of, “oops, that was not considered… it is not in the plan.”
But, the Project Manager’s job is to create and then deliver based on “The Plan.” They will be evaluated based on that ability. Their performance and success is measured by variances to the plan and they report these variances every month to their superiors. As is typical with human behavior, it does not take long for a savvy Project Manager to realize that, “hey, if I want to keep my job, or better yet, get a good raise or promotion, I better not have variances.” Variances to a plan are bad. So the project management function seeks to control and, thus, essentially prevent change. Change becomes a threat to success of the plan.
So, you must follow “The Plan” and stay on schedule and on budget – deliver the hours and the planned activity and events.
But, the Customer wants everything they asked for, so you must deliver all content as well. No, they cannot add anything that will change the plan.
If the developers cannot stay on task as defined, they simply must work harder and longer because “The Plan” must be good. Then they must explain in detail why they could not accomplish what they were told to do within their budgeted hours. Just Make It So.
Waterfall project management wants fixed schedule, budget, and content. Actually what they really want is that big raise for demonstrating how great their plan was and how well they controlled the project through the plan.
If this project is actually well understood up front and what’s to be accomplished is pretty stable, then this approach may actually work. Project managers are smart people too, and they can effectively apply experience and judgment to make good plans under the right conditions. Some industry is very heavily regulated and only a very precise and specific requirement is acceptable. This approach can work well and, if it does for you, then great…. Make It So.
But, what if the software product must evolve to changing conditions and needs? Today’s rapidly advancing technology means end-users are increasingly fickle about what they want. Many agile software project management products now are being provided to model business processes and interactions, either for internal or external customers. These processes are under pressure to constantly change and improve meaning that the supporting software must also change. Companies cannot maintain a competitive edge unless they change and evolve rapidly. Software projects must be prepared to do the same. Does it really make sense to tell your customer they cannot have the thing they discovered they really need now because it was not in your plan you made months ago?
Like science fiction, plans rarely mirror actual reality. Trying to fix schedule, budget, and content is a real challenge for a number of software projects in organizations today. In reality, one of these parameters must be allowed to flex. End-user software is very hard to define up front. Users often do not know what they want, and even when they think they do, they quickly evolve to need something else. Plans must be able to adapt and yet still provide the business with the insight that it needs to manage teams effectively.
This “Make It So” approach must evolve and, with it, the behaviors of project management and the measurements of project/plan success. Even really good project managers cannot control the future.
Maybe it is time to “boldly go” and explore a new “agile software development” approach – one that provides immediate visibility into the health and status of the project real-time, and readily allows for a changing parameter (content, schedule or budget) to be understood immediately.
What do you think?
What does it mean for an estimate to be right? Does that mean that later actuals had the same numerical value? That the project length, or cost, or end date was the same as the estimate? Is it an indication of the “correct length of the project,” whether or not the project is done in that time? Or is there some better definition of “correct estimate” that we can use?
If we choose conformance to actuals as the definition for the “rightness” or “goodness” of an estimate, we’re certainly encouraging overestimation. It’s easier to overestimate and then waste effort as needed to be “accurate” than to underestimate and try to hit a possibly impossible target. Those who ask for estimates using this definition know this, so they are likely to arbitrarily cut the estimate in order to put pressure on development and prevent padding. Of course, those creating the estimate notice this tactic right away, and have incentive to pad even more.
Once upon a time, I was working on a hardware development project. We were breadboarding a design for a custom Large Scale Integrated Circuit using off-the-shelf logic ICs. As we were preparing to prototype our second revision of the design, we calculated how many of what chips we would need. Then we added another ten percent for chip failures, and some more of certain chips we might need if we had to expand the design. Knowing that the boss had a tendency to cut parts orders in half, we then doubled the amount before taking it to him. Unbeknownst to us, he had just come from a meeting where our project was declared to be top priority. To better support us, instead of halving the order, he doubled it. That’s right, the order was placed for four times our best estimate plus padding for contingencies. We couldn’t, of course, admit that we had doubled our estimate. So, we said nothing. The crowning blow came when, a few weeks later, the project was cancelled before the parts were all received.
This story illustrates the sort of dysfunction we create when we play games with estimates rather than treating them as what they are. Estimates are not promises. Nor are they controls on what development teams can do. They are rough calculations that allow us to make decisions before we have all the facts. They may be gut-level seat-of-the-pants guesses based on past experiences, or they may be carefully calculated based on considerable knowledge. In either case, they are the best answer we can give based on the current knowledge and the amount of effort we wish to spend on them.
What, then, makes an estimate right?
1. It didn’t cost more than it’s worth. If we spend a lot of time and effort estimating something that won’t change any decisions, then the estimate is wrong because it’s all a waste. If we estimate an entire project by breaking it down into hundreds of small pieces and estimating all the pieces, it’s likely more work than the resulting estimate is worth. And if the result is close to the decision threshold, we’re probably working on something of too little value.
2. It errs on the appropriate side. The calculation of ICs needed for the breadboard was intended to err on the side of too many, so that we wouldn’t run short and risk delaying the project. If we’re estimating time so that we know when to start other activities that need to be delivered with our project, we might want the earliest time we have to reconsider when to start these activities. If we’re choosing how much work will fit in our next iteration, we might want to be wrong in both directions an equal amount over time so that our long-term projections are more accurate.
3. It has an appropriate level of precision. If we’re estimating what we can get done in the next year, we don’t want to be working at the level of minutes and hours. False precisions is just noise. When I was a poor college student doing my grocery shopping, I estimated to the nearest dime because I found it embarrassing to have to remove an item after it was rung up. That high level of precision was important to me. The shopping cart held only a dozen dollars or less, though, not a hundred.
4. It’s the right thing to estimate. If we estimate the amount of programming time for a project, but ignore significant interruptions for other work, we’re not going to have a good answer for the elapsed time of the project. My estimate of the cost of the grocery cart contents in my college days was the right thing to estimate, because when I reached my limit, I could make substitutions in my menu plans to fit.
These are some of the things that make an estimate right, as an estimate. You can probably think of more, and I’d love to hear your suggestions.
Getting out of the Tardis and back into “posting” here on a regular basis is going to be like getting back on a bike after a long hiatus. I may fall and skin a knee sometimes; heck, I may even break a limb… but I promise nobody is going to die on this trip.
Sit back and enjoy and engage here when possible.
In my last posting I received many many encouraging comments (thank you!) and some that caused me to pause in some of my thinking about this whole blogging thing. It seems so very 2012 and earlier (remember this blog has been around since 2006 and contains a TON of content — some crap and some jewels).
Zooming into 2014 and I am spending a lot of time out on Twitter and with my business out of Facebook because for me this is more engaging and real-time (well… face-to-face rocks but I am not able to be everywhere at once). Google+ also seems to be an interesting place.
Apparently people still read blogs (eh hem, YOU are and I sincerely want to thank you). So… I promise to answer each and every comment here (the valid non-spam ones!) and engage with you and others here. It’s another way. It seems sort of one-way to me so let’s see how it goes.
While I stated in my last post that I’ve been “dark” — it does not mean I have not been working (and enjoying it immensely). I’ll share some of the current stories and travel stories and, more importantly… I will ASK FOR YOU HELP.
Asking for help is something I TOTALLY SUCK AT DOING. I don’t think I am alone at that.
Scrum specifically helps individuals, teams, programs, portfolios and organizations show you where the dysfunctions ARE TODAY.
And. As humans, we learn to live with these dysfunctions and they become the normal noise in life.
This noise can be obvious to people looking from the outside. People like me. And. You.
Here is what I am becoming more and more aware of on a daily basis:
Instead of just treating it like noise… listen to it.
Do ONE thing to make a change.
Who needs to do this?
Ask for help to solve it.
Stop with the idea that, “I’ve got this Mike” — because I will call bullshit on you my friend (well — if we have not met yet we are still virtual friends).
In my travels lately I have been really focusing on two messages — #DELIVER and SLOW DOWN.
People. We still suck at Agile (and Scrum) at the individual and team levels.
Now the rage is scaling agile (and Scrum).
This is not a new thing kiddos (or old people here #getoffmydamnlawn).
My experience is something to learn from — scaling the RUP (Rational Unified Process) from the team level to the Enterprise with the EUP (Enterprise Unified Process) [circa 2005 and earlier].
Is that experience applicable for all situations? Of course not; however, perhaps the next post will focus on what all the new “Silver Bullet” scaling methods, frameworks, and processes look like in 2014 (and what’s coming — because there is always something coming!).
There are patterns that work well. This is “noise” we need to examine a bit more and we will do that here together.
Blogging — it’s a chance for me to share experiences.
And. I will (wahoo right?!!?).
Until the next posting, let me know how you are doing with exposing things using Scrum – and how that experience is like turning up the amplifier to eleven all the time.
Ask SOMEONE for help.
I am going to do that shortly too (because as it has been pointed out — I cannot be a “one man show” on this journey).
The early adopters of Scrum were seeking a method of controlling the chaos of emergent product development processes. They needed empirical methods to discern if the product was moving in a meaningful direction. They were willing to risk accepting technical debt to validate working solutions in the hands of real customers. They were focused on delivering value, they wanted a process that optimized on value delivery and embraced the learning process required to explore new product domains. They were organizations capable of thriving on the edge of chaos. Organizations in the early adopters phase seek to keep options open (decide at the last responsible moment), to pivot upon learning about the opening market space, to fulfill an undefined emergent need.
"Intelligence should be viewed as a physical process that tries to maximize future freedom of action and avoid constraints in its own future." -- Alex Wissner-Gross
Tardigrade - an extremophileThese organizations are perhaps a small subset of all corporations - perhaps these are extreme examples - but they exist.
But extremophiles do not live in the calm waters of the Caribbean reef.
"Most executives I’m meeting with nowadays aren’t fundamentally trying to solve the adaptability problem." -- Mike Cottmeyer - Are we Solving the right problem?
The Agile movement has reached the late majority of the diffusion of innovation curve.
The Late Majority: "Individuals in this category will adopt an innovation after the average member of the society. These individuals approach an innovation with a high degree of skepticism and after the majority of society has adopted the innovation. Late Majority are typically skeptical about an innovation, have below average social status, very little financial liquidity, in contact with others in late majority and early majority, very little opinion leadership." -- Everett Rogers
My opinion is that this group is seeking a different answer than the early adopters or early majority. Studying Rogers' diffusion curve and synthesizing some other really observant human behavioral ideas; I think it's very obvious that the late majority have a very different answer to the fundamental questions around why they are adopting Scrum. I've asked this question for years in workshops. The answer's haven't changed. But the meaning behind the answers must be different than they were before.
Is it the value system of Agile that draws these companies into the Scrum trainers classroom? No. Is it the promise of the more collaborative and humane software development lifecycle for the employees? No, many of these companies have already shed their employees by adopting the staff augmentation model of the 20th C. consultant/contractor model.
The answer this group of late majority scrum adopters are seeking is: a lowering of the cost of development and maintenance of software systems that run and maintain the business. Very few projects that these organizations attempt are in the domain of seeking an innovative or emergent solution. Sure they speak the current lingo of innovations but few are seeking disruptive innovation (what must of us think when the "I" word is mentioned), most are seeking frugal innovation (15 Types of innovation).
"Frugal Innovation is about doing more with less. Entrepreneurs and innovators in emerging markets have to devise low cost strategies to either tap or circumvent institutional complexities and resource limitations to innovate, develop and deliver products and services to low income users with little purchasing power."
This group is not seeking to open up the future options that an emergent process may afford them.
See Mike Cottmeyer's blog series What Problems Are Executives Trying To Solve With Agile? It is a very good list - if you need an answer, pick one from his list - it's sure to impress.
Start with WHY - Simon SinekPerhaps we should start our agile transition with a serious question - Why?
I've asked this question, but just getting a few mid-level managers and the executive level sponsor answering this question may not be enough. Is there a method of hearing the organization - rather than the designated spokesperson for the organization? Enter Open Space Technology. Why yes, yes I believe this may provide a collaborative way to answer the question without the filter imposed by a leadership visor. Inside of the Agile movement it may best be expressed by Open Agile Adoption techniques.
Is Agile a solution for this cost reduction and predictable deliver of replacement solution domain of the late adoption mindset? I believe they can see benefits of adopting the basic foundations of Scrum. Of adapting the underlying Extreme Programming techniques that power the Scrum framework. Yet the agility of the processes might be antithetical to the organizations purpose of delivering software.
A case in point: a client in the data management of health care actually has the policy of allowing their clients to pick and choose (ala-carte) the software development process aspects that they are willing to pay for. For example - the client may not wish to pay for the QA on a project, so the development group conceives that it is their role to deliver a software product without doing the QA. Or perhaps the client doesn't want to pay for the project management aspect, or the architectural analysis of the solution. Now this is an extreme situation - true. One that none of us would like to be in - but can this organization adopt the Agile mind-set? When the various directors and VPs of this organization say they want to do the Scrum/Agile thing - do they mean what I think they mean - or are we talking about very different purposes?
Alex Wissner-Gross - A new equation of intelligence - TED Talk
Agile Scout's SAFe Review
In a recently published article, A Product Owner’s Syllabus, I shared how we educate product owners in our company. A product owner’s job requires competence in a number of domains, as it turned out. There’s one more consideration that I want to highlight. It’s rather related to the environment where this product owner works, not to personal skills or knowledge. Sometimes, though, it’s quite hard to draw the distinction between personal skills and how those skills are influenced by the environment.3 Levels of Product Ownership
Product owners can act on the following levels:
Mix of innovative and market-driven
Why is it important to single out these levels prior to doing drills in narrow disciplines included to the PO syllabus? This helps the trainees realize the high-octave “why” of this work. They say that philosophy is the mother of all sciences. In the same fashion, knowing the very reasons of why a product exists at all is the necessary first step. This knowledge and reasons are very product-specific. That’s why I’m skeptical about all kinds of “certified” courses, because attending a course and taking part in abstract drills (such as the ones brilliantly mocked at in here) will not turn anyone into a mature product owner overnight. To me, the best credentials for a product owner would be the history of the product that this person owned or managed, at least for some time, and the thinking that stood behind their decisions. There’s no better learning than by doing.
Just as in my recent post, where I anchored our evolving as a company with the way we do visual process management, I will look back at the history of our product yet again. We’re cool big guys, because we can look back as far as 10 (!) years ago. Targetprocess 1.0 was launched in 2004. Targetprocess 2.0 was released in 2006. Targetprocess 3 came on the scene around 2012-2013. The 1.0 version was the minimal viable and marketable software for agile project management. Targetprocess 1 had 7 releases, from 1.0 to 1.7. Targetprocess 2 had 24 sub-releases, from 2.0 to 2.24. With Targetprocess 3, we released the version 3.0.11 last week, and the next release will be 3.1.The Market-Driven Suite and Innovation
Looking at the releases from 1.0 — 1.7, and 2.0 — 2.24 (click the hyperlinked words above), one can draw some interesting conclusions. Targetprocess progressed with the agile movement and with what the market wanted( I wish we had a decision sequence timeline to track this better). The 1.0 version appeared as a result of market-based thinking, because agile was a rising new trend back then, and our product owner and founder (who has the project management background) wanted to do a decent software for agile project management. Then, with time, the 2.0 version was released. This was a re-written software with completely new UI. The product owner sensed that the product needs a robust core and an improved UI, before any new features could be added. That was a strategic market-based decision. Then after about 8 years of following the market, the product owner hits the level of innovation with Targetprocess3. It is indeed an innovative project management software as it brings along a new paradigm in visual project management. I do not intend to go too deep into praises, I just want to show with this story that it takes 8-10 years for a product owner to become mature and operate on the level of innovation. Some product owners never get to this level. They implement the features that make their product more appealing to users, to outperform the competitors, or both. There’s nothing good or bad about it, just the way it is. It’s quite rare nowadays that a completely new product comes as “innovative”. Start-ups are mostly busy discovering smaller niches in the established market and filling them in.A Basic Drill for Newbie Product Owners
Well, a product owner may or may not reach the innovation level. Let’s get down back to earth. I have this list of questions ready for trainee product owners to help them exercise their minds in product-based thinking as they consider implementing new features:
How often will people use this new feature?
How many people will use it?
Will this feature address any particular pain of users?
How it will help users save their time, if at all?
Will it make any difference, or will users be just as fine without this feature in the product?
Will this feature make the product easier-to-use or more complex?
Will it help bring new business, or is it meant for established users, mainly?
Formulating such questions can be a good exercise at an internal company training. The road to success starts with one first step, and this simple drill might be a nice first move in a career of a product owner, who might become an Innovator some day.
Over the years I’ve done lots of work with Scrum teams and I appreciate that Sprint Demo/Review meetings can be a useful way to give stakeholders visibility of features implemented prior to pushing out a product release. Teams that find this way of working helpful typically work in larger organisations, where they don't have the capacity to make frequent software releases due to restricted access to servers or a heavy reliance on manual regression testing. However, the ceremony of Sprint Review may be propping this system up allowing teams to work in a pseudo-Agile way placating stakeholders while delaying the release of valuable software.
Nowadays I work with XP teams who don’t hold such demos because we practice continuous deployment. Code is deployed to live environment at the earliest opportunity and often in use within our business a couple of days after planning. Where we don’t want all of our users see new features, we can put in a toggle to restrict visibility. When features are already live, the ceremony of getting together in a meeting room with stakeholders is pretty pointless. Although we do ensure that stories are signed-off by business people, often a single story owner who we’ve been working closely with during development.
How do our wider stakeholder group (Sales, Marketing teams, etc) know what product features are currently released and find out details of how they can be used? As each story finished, developers send a release email out to internal users and organise education sessions for whoever needs to know how the new feature works. We also took some inspiration from Joe Walnes’ Testing on the Toilet and Aimy (our product manager in New York) creates newsletter-style posters for our company washrooms to illustrate and explain new features now available. We have even tried Release-Email Driven Development for a few stories, where we write the release email before starting development to ensure we've thought things through from a user perspective.
The only situation we might consider holding Scrum style demo meetings is when we are working on a totally new unlaunched product. But even then, our practice has been to make a live version available to a restricted group of internal stakeholders so they can access the product and play around with it themselves. Last year, for our Unruly Analytics product we even integrated wireframes and sketches (see pics below) into the evolving product as placeholders for screens that had not been implemented yet to provide some context for the live features.
Scrum Sense welcomed Joanne Perold to our expanding team in February. Joanne has written our latest blog post on what makes a retro good. Follow this link to find out more…… Peter Hundermark has finished revising his ‘Do Better Scrum’ booklet. This booklet will give you practical tips on how to do better Scrum. To download the […]
The post News update 2014/03 – Kanban Training: 3-for-2 Special Offer! appeared first on ScrumSense.com.
Rally believes that for-profit business can -- and should -- be a force for social good. That means we join companies like Ben & Jerry's, Patagonia, Method, and Seventh Generation in measuring business success by the triple bottom line: people, planet, and profit.
Rally is part of a growing community of nearly 1,000 Certified B Corporations from 32 countries and 60 industries, working together toward one unifying goal -- to redefine success in business as being not just the best in the world, but the best FOR the world.
Rally just completed its third, rigorous B Lab assessment, demonstrating our positive impact on community, employees, and the environment. The B Corp model helps us benchmark that we are living up to our own mission and that we push it even further.
What makes Rally a Certified B Corp? Here are a some highlights:
- Giving back to the community. In 2013, following our successful IPO, Rally donated $1.4M of founding equity to charitable causes and created the Rally For Impact Foundation, which enables engineers to apply their skills and expertise for positive social change.
- Providing free Agile education. Rally is working with innovative social impact organizations such as Rocky Mountain Microfinance Institute, where employee volunteers provide Agile coaching, training, business planning and team facilitation. In 2013, our employee experts also delivered “Act Like An Agilist” courses to social entrepreneurs at the Unreasonable Institute and Impact HUB Boulder.
- Treating employees well. We were honored in 2013 as "Best for Workers," scoring in the top 10% of all Certified B Corporations for our positive impact on the people of Rally.
- Paying People to Give Back. Our culture of giving encourages employees to spend 1% of their paid time volunteering, as well as giving back to their community on their personal time. As a result, in 2013 Rally employees contributed nearly 4,700 volunteer hours, or almost 600 worker days.
- Encouraging volunteerism from day one. Beginning this month, when new employees go through Rally’s onboarding “boot camp” they spend two hours volunteering.
- Shrinking our carbon footprint. Rally’s products are primarily deployed as Software as a Service (SaaS), which minimizes the creation or shipment of physical goods and optimizes the energy-efficiency of modern data centers.
- Recycling and composting at scale. At our office headquarters in Boulder, Colorado, where we employ about 60% of our staff, we’ve partnered with internationally-recognized nonprofit Eco-cycle to recycle and compost 74% of our waste.
- Getting to work with pedal power. Rally’s Boulder and Denver offices have a large bike-to-work population, and we offer all Colorado employees a company-paid EcoPass for public transportation.
As a Certified B Corp, Rally supports the movement for business to play a leading role in providing social and economic benefits to the world while delivering great products and services at a profit. Values-led businesses like Rally deliver shareholder value, while building trust among our customers and partners that we are in service to the global community.
We have a shared responsibility: we are collectively striving for shared and durable prosperity. Let’s B the Change.Geri Mitchell-Brown