The Periodic Table of Visualization Methods (aside: why people abuse the notion of the Periodic table of elements is puzzling to me - it's not just a table with iconic status - it's a predictive model in action; ... meanwhile, back to the visualization methods...) awesome chart with wonderful pop-ups to explain all the visualization methods.
Periodic Table of Visualization Methods
So let's just go right ahead and include the predictive model of Mendeleev's table.
Example of the Periodic Table style applied to Scrum by my friend and colleague KaTe.
by Kate Terlecka
When you're into visual info, books on work processes, wonder and humor... you need a crateful of grateful - bet ya can get it at www.getlit.me here's a sample of Todd's book review info graphics.
Succeeding with Agile Governance
Want to visualize what that conference call really looks like - watch this video.
from Tripp and Tyler
Visualize the 5 SOLID class design principles.
Visualize what an org. chart should look like (if it was to be a useful tool; rather than an ego booster):
The most powerful pattern in Agile Results is:
Monday Vision, Daily Wins, Friday Reflection
I introduce Agile Results in my best-selling book on time management Getting Results the Agile Way. (For a quick overview, benefits, testimonials, and videos, check out the landing page for Getting Results the Agile Way.)
The Monday Vision, Daily Wins, Friday Reflection pattern a big deal.
Because it creates a simple approach for personal results in work and life.
You learn how to quickly flow value each day and each week. Through Friday Reflection, you add a learning loop. By setting simple targets, chunking things down, and delivering little chunks of value, you get better and better at driving results.
You’ll astound yourself, and you’ll awaken new levels of resourcefulness and productivity you didn’t even know you had.
How do you get started?
It’s real simple.Add 3 Reminders to Your Calendar
One of the simplest ways to build your Agile Results habit is to add 3 reminders to your calendar:
- Add a reminder on Monday Morning. Call it Monday Vision: "What are your 3 Wins for this week?"
- Add a reminder to each day. Call it Daily Wins: "What are your 3 Wins for today?
- Add a reminder to Friday: Call it Friday Reflection: "What are 3 things going well? What are 3 things to improve?"
You can literally prompt yourself to better performance.
It’s so simple in fact that you have to wonder how could something so simple create such profound results.
In fact, if you’re not sure how significant this can be to your life, watch Alik on Getting Results the Agile Way (Video), and how it changed his life.
Keep in mind, there is a lot to Agile Results.
But you don’t need it all at once.
Start small and go from there.
The Rules of Scrum: Your Product Owner always lets the team freely decide how many Product Backlog Items to do in a Sprint
The Product Owner controls the order of the items in the Product Backlog, but not how many are done each Sprint. Instead, the team decides how many to do. This decision is made in Sprint Planning and, of course, should be made in collaboration with the Product Owner, but ultimately the Product Owner must let the team freely decide how many items are planned. This freedom allows the team to be truly motivated and committed to the work as well as being collectively accountable for getting that work done. If the Product Owner forces a team to take on more work than it feels is within its capacity, then that dis-empowers the team, moves accountability for getting work done to the Product Owner, and completely dis-ables the team from getting to a high-performance state.
To learn more about Product Owners, visit the Scrum Team Assessment.
Gabriel asks: Can you suggest a few relevant papers on Agile contracts? I am interested in both the ad-hoc, non-commercial agreements, to maximize, based on Pareto law naive application, the output of PO-development team through collaboration, and the commercial agreements that best support such an objective. I read this: http://www.agilecontracts.org/agile_contracts_primer.pdf but I would like to read more materials on the topic.
Here is a short answer. And maybe too basic for you.
1. You can have a waterfall contract (old style) and use agile to deliver. And probably things will turn out better. One problem could be getting progress paid for ‘interim deliverables (documents); I won’t do there now.
2. I like Jeff Sutherland’s idea about an ‘agile contract’ half-way house. It is between a waterfall contract and a real agile relationship between the buyer and the seller.
The basics are: you get a BRD from the client, and convert that to a product backlog. You organize the PB by business value, add story points, and give it a fair overall cost. Estimate the ‘final delivery date’ and then discuss contract terms.
In summary, the terms include:
- Client will inspect every sprint. Change for free (if we did something wrong…obviously we built in some padding for this…aka ‘contingency’).
- Equal substitution. If the client wants to add a feature, then a feature (story) of equal size comes out.
- Addition. Client can still just add a feature, at the same old price (high).
- Early Termination. The client can terminate early if the client pays X% of the remaining contract. (X=20%?)
This gives the vendor a strong incentive to terminate early and aligns the vendor with the customer’s need to ‘complete’ faster. Also, the features are built (mainly) in BV order.
Jeff Sutherland calls it ‘money for nothing and change for free’. Smile. A good step in the right direction. Often the biggest first step one can make away from the old waterfall contract.
3. A real agile contract.
This is more like a T&M contract. The client becomes the PO. Or, at least can change the PB at any time.
The key term is that the client ‘owns’ the team continuously, for as long as they want and at a monthly price. The client can cancel the contract at any time, with X months’ of notice. (X=2?)
This gives both parties an incentive to work well together, and gets it done early (get the next release out early). The vendor does good work each month to justify continuing to be employed by the client. The client gives good PB items (stories) to the team to maximize the BV from the team.
This contract maximizes the ability to change. And, reduces ‘early termination’ costs for the client. Typically the vendor should charge a higher rate, since the customer is getting in every other way a great deal.
If I were the client, the first work for the team would be agile release planning, where they helped me establish an initial sense of the scope, dates and costs for the first release or two. But, I would understand that this initial plan will change. Largely due to me — due to business side changes. But, not only due to that….due to other learning’s as well.
Nowadays, the key problem with the real agile contract is often the lawyers. The business guys at the client understand the need to do things this way, but they can’t explain it to the lawyers well enough. So, the contract does not get changed enough. See comment on Larman/Vodde below.
Other resources for contracts include earlier blog posts on this topic:
* The Poppendiecks focus on the larger goals of agile contracts and give you some specific examples of how it worked. How do we get the vendor and the client in alignment, and share risks appropriately?
* Larman and Vodde talk about getting the lawyer(s) in the mindset of agile. The details come out better if the underlying thinking is agile.
* It is of course still true that some people are still stuck on keeping the waterfall contract: scope, date and budget locked down, and the vendor gets some progress payments based on waterfall ‘deliverables.” So, the first thing is to discuss how this is working for them so far. Typically, not very well. So, gathering some examples of the failures of waterfall contracts might be needed to loosen up the thinking.
If there’s one thing every screencaster needs, it’s high speed, high capacity storage for raw materials. I just finished up my 15th episode of WatchMeCode (and have recorded probably another 15 or 20 episodes other than those) - here’s the progress bar copying my raw materials over to my Western Digital Thunderbolt Storage device.
Yes, that’s 52 GIGS of raw material! And yes, it transferred in less than 5 minutes! Seriously, I’ve edited screencasts directly on this thunderbolt drive before, it’s that fast… well, it’s fast enough. I don’t really recommend doing that when you have access to an SSD, like my Macbook Pro Retina has… but I have done it, and it does work. Instead, I leave the raw materials for the episode that I’m currently editing on my internal SSD. Once I’m done, I transfer it over to the storage device for – you guessed it – storage! I also put virtual machines that I don’t currently need on this device, as well as photos and other things that just need storage.
But this brings up a question: why do I need so much storage space, and how did my episode grow to over 50 gigs of raw material?!Retina Display: File Size And Storage Killer
Normally I use an Apple Thunderbolt monitor. It’s an awesome monitor. But I record my screencasts on my Macbook Pro Retina. I do this because I record in my closet. It’s a large closet, full of clothing and it gives me great sound. So it’s worth hauling my computer in to my closet for this. But I don’t want to haul may monitor in there, too. So I just set up a TV tray and use my laptop directly, with the retina monitor.
The only problem is that the retina monitor is 4x the resolution that I actually need. When I record on the retina and add audio from my Rode Podcaster, I end up with a raw ScreenFlow project of near 18 gigs! It’s gigantic! I always end up with multiple copies of the original, as well. I usually hold one as “original” and use this for the “OH, CRAP!” moments when I break something so badly that I can recover it in my editors. I also create a “preview” video for my screencasts, which creates yet another copy. By the time things are done, I’ve usually got 3 and sometimes 4 copies of the original source. It gets large, fast, but it’s the best way for me to record and work, I’ve found.
Instead of letting these copies eat up 52 gigs of space on my MBPr, though, I have the Western Digital storage device. It’s a 4TB version, but there are 6 and 8 TB versions as well. It is well worth the money to have a good storage device, too. Keeping the raw materials on that device lets me keep all the files that I do need on my hard drive, without worry about space.
Post Footer automatically generated by Add Post Footer Plugin for wordpress.
Here are some additional resources for Agile Contracts.
A good presentation via video. From 2011.
A slide deck of a presentation in 2011. Not the same one as the video.
And be aware that the Poppendiecks did presentations on agile contracts over years, and typically each presentation was a bit different.
A while back I was invited to the AITP Atlanta Chapter for a CIO roundtable discussion that involved questions on agile. The event was a great success and I came away with a bunch of great insights into what topics are on the minds of today’s CIO. One statement that night has really stuck with me. A wise, retired CIO told me, “Don’t sell me your solution, solve my problem.”
That statement further solidified my belief that I am not “implementing agile” (hang with me), but rather I am solving a problem or a set of problems that commonly occur in enterprise environments.
We don’t sell vials of snake oil. Here’s why that may be the perception.
Let’s consider the state of affairs for a moment. When I get the opportunity to have a discussion with a new organization, the person I am talking to needs me to solve a problem. They might not know anything about agile, scrum, kanban, or any other process. Alternatively, they may have experienced a poor implementation and have an immediate bias to any of the “agile” words (i.e. sprints, daily scrums).
If I am selling them something, I genuinely want to solve the problem, not implement agile. That allows me to be a pragmatic partner with knowledge of agile systems that can benefit my customer. It breaks down zealotry and keeps me honest.
In the end, I am directly and intentionally not talking about agile, scrum, kanban, or lean or anything else that is under the agile umbrella. I simply want to know, what is the most impactful issue that their enterprise is facing right now in their unique context. Can I solve it? No, but we (myself and the enterprise) can. It must to be a partnership though to be an effective sustained transformation.
Here’s the catch. Most, but not all, issues will fall into one of several categories.
- Time To ROI
Though categorically these problems are recurring across many business enterprises, the underlying causes can be a complex, interwoven gobbledygook of methods, procedures, and people.
That’s why it’s important to listen and offer up expertise when you understand the problems. It’s an engaged dialog that I am targeting to create a shared understanding of their problem so we can work to create a vision of our solution. I’m not there just to lend an ear. That’s why I need all this experience stuff.
Speaking of experience, I have found commonality among the solutions for each of the categories listed above.
Let’s take Predictability. In order to become predictable, most organizations will need to learn how to systematically decrease batch size, reduce WIP at the enterprise and team levels, and stabilize teams. Inherently, this will increase quality and decrease Time To ROI. To further improve those, I will need to run experiments on their unique context.
How do they begin to get predictable? That’s what they need help doing. It’s what scaling agility is really all about. Getting more value out of the system to decrease time to ROI and predictably make and meet corporate goals. Informed, predictable returns on investment.
At my core, I believe a predictable system is one that we can run experiments on and get most other problems solved. That’s my key to unlocking the shared potential of both parties.
An Agile Education Vision is an education roadmap that a team iteratively plans and applies. It is meant to be self-organized by the team focused on their education needs toward being Agile. Since people are critical to the success of agility, it is only fair to allow the “power of the people” to self organize around their own educational needs. As a team approaches Agile, they periodically consider various education elements that can be used to help them build their Agile knowledge, skills, and capabilities toward achieving a mindset. As education gets applied, the team periodically visits the education vision and updates it based on their current level of Agile need.
A good way to think of this is that the Agile Education Vision is a prioritized product backlog of education elements based on team needs. Each sprint or timeframe, the team visits the vision, determines what education is needed, and then applies those educational elements throughout that period. Another approach that engages the power of the people is an Education Led Transformation. Established by Emergn, this is a work-based approach where learning occurs through action. Experience is gained over time by the team and they become better equipped to gain the full benefits of agility.
When I say education, it is more than just training. It takes a repertoire of educational elements. These education elements can help a team develop skills, understand their roles, and navigate a process or practice, and most importantly achieve an Agile mindset. Training is just one of those educational elements. What are some of the others? Here is a sampling:
- Simple brochure, flyer, or short presentations.
- In-person training such as Instructor-led and seminars
- Web-based training such as pre-recorded and webinars
- Work-based learning with activities and on-the-job training
- Reading in the form of books, articles, and more being done individually or in a book club
- Hosting such as agile practices website and wiki
- Coaching providing in-session education to a team or an individual based on domain knowledge and experience.
- Community contributing includes giving back via forums, blog articles, or seminars.
How will your teams be educated? An accumulation of education elements at different points in time will provide the comprehensive focus to help you, your team, and your organization. Consider applying an self-organized education vision or an education-led approach that best serves your goal toward being Agile. Ultimately you want to create a self-organizing educational culture where employees are willing and eager to learn, act, and give back to their community. How are your teams currently being educated in agility?
PS - to read more about establishing an Agile Education Vision and how education elements can help you be Agile, consider reading Chapter 16 of the new Agile book entitled Being Agile.
Fail Better - Dublin Science Gallery
"The goal of FAIL BETTER is to open up a public conversation about failure, particularly the instructive role of failure, as it relates to very different areas of human endeavour. Rather than simply celebrating failure, which can come at great human, environmental and economic cost, we want to open up a debate on the role of failure in stimulating creativity: in learning, in science, engineering and design."
By Kevin Meyer
Rules are a funny thing. We like some of them because they make us feel protected, aligned, and perhaps operating on a fair playing field. We dislike them because they can protect us to the point of being smothering, align us to the points of being constraining, and fair to the point of being unfair. Regardless of perspective, there are an increasing number of them. Over 3,000 new laws and regulations each year, for starters.
I won't get into the political side of the increasing number of rules, but what are we doing to ourselves as a society? Or individually as humans? Stay tuned...
Years ago I visited Italy and was surprised at the traffic.
There are very few traffic signals in Italy. The town of Naples, with a million people, has about three (and I'm being serious). Signage is basically ignored. Miniature cars, and the rare larger sedan or SUV, rush all over the place intermingling with Vespas, buses and trucks. Sorrento, Rome, Florence... all roughly the same. This seems like pure mayhem and insanity to visitors from the U.S. with our highly disciplined traffic control... until you start to realize something:
Traffic flows continuously, everywhere.
Ahh... but it can't be as safe, right? Wrong. Statistics show that Italy has a motor vehicle accident rate that is about 30% better than the United States.
In fact, the chaos associated with traffic in developing countries is becoming all the rage among a new wave of traffic engineers in mainland Europe and, more recently, in the United Kingdom. It's called "second generation" traffic calming, a combination of traffic engineering and urban design that also draws heavily on the fields of behavioral psychology and -- of all subjects -- evolutionary biology. Rejecting the idea of separating people from vehicular traffic, it's a concept that privileges multiplicity over homogeneity, disorder over order, and intrigue over certainty.
"One of the characteristics of a shared environment is that it appears chaotic, it appears very complex, and it demands a strong level of having your wits about you," says U.K. traffic and urban design consultant Ben Hamilton-Baillie, speaking from his home in Bristol. "The history of traffic engineering is the effort to rationalize what appeared to be chaos," he says. "Today, we have a better understanding that chaos can be productive."
And another from Der Spiegel with a story on how seven European cities are participating in an experiment to remove all traffic signs. Not just signs, but parking meters, lights, sidewalks, and even the painted lines on streets.
Drivers [in regulated areas with many signals] find themselves enclosed by a corset of prescriptions, so that they develop a kind of tunnel vision: They're constantly in search of their own advantage, and their good manners go out the window.
The new traffic model's advocates believe the only way out of this vicious circle is to give drivers more liberty and encourage them to take responsibility for themselves.
Chaos can be productive, liberty creates responsibility. A month ago I wrote about how some enlightened companies are applying this concept to their own internal rules.
[At Neflix] there is no vacation policy, and the travel and expense policy is literally five words: "Act in Netflix's best interests." Netflix believes high performance people people should be free to make decisions, and those decisions need to be grounded in context.
In the world of Netflix, flexibility is more important long term than efficiency. To inhibit the chaos that too much flexibility in a large organization can create, hire (and keep) only high performance people. High performance people make great decisions, which are better than rote rules.
Now we may have more psychobiological understanding on why this is the case. And it comes from some interesting experiments with school playgrounds in New Zealand.
Ripping up the playground rulebook is having incredible effects on children at an Auckland school.
Chaos may reign at Swanson Primary School with children climbing trees, riding skateboards and playing bullrush during playtime, but surprisingly the students don't cause bedlam, the principal says. The school is actually seeing a drop in bullying, serious injuries and vandalism, while concentration levels in class are increasing.
"When you look at our playground it looks chaotic. From an adult's perspective, it looks like kids might get hurt, but they don't."
Swanson School signed up to the study by AUT and Otago University just over two years ago, with the aim of encouraging active play. However, the school took the experiment a step further by abandoning the rules completely, much to the horror of some teachers at the time, he said.
I bet there was some horror, but what are the results?
When the university study wrapped up at the end of last year the school and researchers were amazed by the results.
Mudslides, skateboarding, bullrush and tree climbing kept the children so occupied the school no longer needed a timeout area or as many teachers on patrol. Instead of a playground, children used their imagination to play in a "loose parts pit" which contained junk such as wood, tyres and an old fire hose.
"The kids were motivated, busy and engaged. It was expected the children would be more active, but researchers were amazed by all the behavioural pay-offs.
Schofield urged other schools to embrace risk-taking. "It's a no brainer. As far as implementation, it's a zero-cost game in most cases. All you are doing is abandoning rules," he said.
"All you are doing is abandoning rules." If only it was that easy.
Society's obsession with protecting children ignores the benefits of risk-taking, he said.
Children develop the frontal lobe of their brain when taking risks, meaning they work out consequences. "You can't teach them that. They have to learn risk on their own terms. It doesn't develop by watching TV, they have to get out there."
Risk creates engagement, and engagement creates understanding - be it of the environment, consequences of actions, or simply new concepts. Understanding creates high performance decisionmaking.
Whether it's in the chaos of traffic, the corporate offices of Netflix, or on the playground.
So what about all those rules? In the quest for structure, equality, and serenity, what are we doing to ourselves? And the next generation? Instead, how can we create and leverage chaos and risk to improve engagement?
So scientific processes have a little trick up their sleeves called the Null Hypothesis. The null hypothesis, or default answer, is generally assumed true until evidence indicates otherwise. How often do you use this process to mutate your software development process? How do you protect yourself from the confirmation bias during your process improvement experiments? Do you see this null hypothesis at work in the TDD process of proving a unit test fails before the implementation code creates evidence to indicate otherwise?
Since this scientific process is not very natural for us humans; it leaves me to wonder how we learned this process. One common answer is Bacon! Francis Bacon to be precise - Voltaire called Bacon the father of the experimental method.
Solving technical problems is the job of the product developers on the Scrum Team, not the Product Owner. The Product Owner is responsible for the product from a business and user perspective and has authority over the team only in this limited realm. By overstepping the bounds of authority in this way, the Product Owner becomes an obstacle for the team by reducing its ability to self-organize. A Product Owner who is part of a team that has reached a high-performance state may be able to safely make technical suggestions, but should always be careful not to push the team to accept those suggestions.
To learn more about Product Owners, visit the Scrum Team Assessment.
Back when I was a Director of many things at one company, we had an urgent patch to go to a customer. My VP wanted it “yesterday.” Well, time only goes in one direction.
I gathered my continuing engineering team, explained the pickle we were in. “Everyone wants this patch right away. However the customer is truly pissed. I want to know that we have a fix that works. And, while you are working on it, I will need to know updates every morning and every afternoon. I will run interference for you, as well as I can.”
Everyone groaned. They knew what this meant. We had a small company. The corporate management was just down the hall from our offices. Even though I said I would run interference, nothing would prevent the VP of Engineering, the CEO, or the CTO from popping their heads in “to see what’s going on.” Everyone wanted to make the customer happy, right now.
At the time, I didn’t know about kanban boards. I knew about spreadsheets and email. I had four people working on this fix. I knew what they were all doing. So did they.
They managed themselves. Their offices were close to each other. Every day, about noon or so, they gathered in my office, so I would have the most up-to-date status. It wasn’t quite a standup, because some of the work was what we would now call spikes. (At first, we had no idea what was causing the problem.)
As we identified the problem, I explained to management on behalf of the team how they narrowed down the problem and identified it. Then I explained to management on behalf of the team how they were debugging the problem. Then I explained to management on behalf of the team how they were testing the fixes they proposed. Then I explained to management how they were packaging the fix they had decided on.
If we’d had a visual board, this might have been easier. I used email. It took close to a month. It was a very difficult fix.
Notice what I did:
- I explained to the team the results I wanted: as quickly as possible, but it had to be right. Right trumped shoddy.
- I explained that I needed information, and how often I needed it.
- I ran interference and kept the rest of the management team informed, daily. My goal was no surprises.
- I explained things on behalf of the team, so they got the credit. I was doing my management job, not technical work.
Because our management, and I could share the interim results with the customer, the customer was not happy during this month, but they were pleased to know we were working on the fix. By the time they got the patch, they were very pleased. It worked.
I did not micromanage my people. I understood their state. There is a big difference. And that is the topic of this month’s management myth, Management Myth 26: It’s Fine to Micromanage.
If I had stood over their shoulders, and asked, “Is it done yet?” I suspect I would have had different results.
My team understood that I was doing my management job. I didn’t prevent all other senior management interference. But, I prevented most of it. In return, they were free to work together to accomplish their goal: a fix that didn’t upset the rest of the system and really fixed this customer’s problem.
It’s easy to fall into micromanagement. We, as technical people are terrific problem solvers. We excel at it. We want to help other people solve their problems. Micromanagement is inflicting help on other people. It’s not helpful. It’s irritating and prevents other people from doing their jobs.
Have you caught yourself micromanaging? If so, what made you stop?
A post or so ago I used the process of designing and building a house as a metaphor for how to plan an agile project. I was basically making the case that we would never spend our own money the way we are asking our stakeholders to spend their money. We would never give a home builder $500K dollars without some sort of commitment around what we were going to get for our time and money. As consumers, we want to know what to expect.
That said, I don’t think it’s reasonable for us as consumers to expect that nothing is ever going to change as we begin building and learn more about the kind of house we really want to build. We can’t go back to the builder and demand changes for free because we didn’t understand exactly what we wanted. We create high level plans, set budgetary estimates, collaborate through out the process to guide the build to successful completion and a satisfactory outcome.Why This is Relevant to Software
Software projects are all over the place in terms of risk and uncertainty. If I am building an e-commerce site from scratch, and we are using known and well understood technologies, that is a pretty straightforward type of project. I might not know everything that I want on day one, but I can understand the major parts and pieces. I can understand the underlying implementation, create a budget, and probably come pretty close to meeting that budget at the end of the project.
This is the type of project where the metaphor of building the house makes sense. Create a high level plan, develop budgetary estimates, establish constraints, and work collaboratively with the customer to guide the solution into a successful outcome. As the consumer, I should be able to show up with my money, spend a minimal amount of time up front, and get started on the project. I should have a pretty good idea of what to expect when the project is done.
Not every project though follows this same kind of rule. Some projects are much more uncertain. Some projects are funded and neither us nor the customer know much of anything about the target product. They might know they have a need, but understanding how to solve for that need is elusive. Some projects are being built for customers that don’t even exist yet. We are creating a market and trying to figure out what we are going to sell as we go.
Some projects are built on top of legacy systems that have a ton of technical debt, poor automated testing, no ability to produce a daily build… let alone do continuous integration. Some products have so many defects and undocumented edge cases that interacting with or changing that software is an exercise in futility. How do you estimate for a project where requirements are unknown and the technology platform is virtually unknowable?Estimating the Un-estimateable
I do believe there are projects out there which defy estimation. Projects where the requirements are truly unknown and maybe even unknowable. Projects where the risk and technical uncertainty are just too great to have any idea what it is going to take to do the project. When you couple this with the fact that people are not fungible resources and don’t burn estimates at necessarily the same rate, trying to predict anything doesn’t seem to make much sense.
It seems to me that we should look at these unknowable kinds of projects differently and apply a different approach to managing them. For the first kind, it seems reasonable to create a high level plan, look into the future to identify and mitigate risk, provide estimates, and plans, and have a pretty good idea of what we are going to get. We can still do agile, we can still inspect and adapt, we can still change requirements in the small while converging on our higher level goals in the large.
The second kind of project can’t be handled the same way. We don’t know the requirements are or what it will actually take to build them. We can’t do high level plan, or look into the future to identify and mitigate risk, estimates are nonsense, planning is an exercise in futility, and (if we are honest with ourselves) have to admit that we really don’t have any idea of what the customer is going to get for their time and money. It’s a bit of a crapshoot.
If we can fundamentally agree that both kinds of projects exist, maybe we need a different way to talk about each of them. Maybe for the ones we can predict, we use adaptive planning techniques… user stories, timeboxes, estimates, roadmaps, rolling wave planning, or whatever… to make sure we are driving up communication and collaboration, delivering early, getting feedback, and tailoring as we go. For the ones we can’t… I think we need to start use the language of investments.Why Do We Call It a Project Portfolio?
If we use the notion of an investment portfolio as a metaphor to talk about a project portfolio… we can start to think about our collection of projects as a series of investments. In a balanced portfolio, I might have some of my money in lower yield, relatively safe, municipal bonds. I might put some of my money in a higher risk mutual fund and hope for a bigger return. I could allocate the remainder to even higher risk, higher reward mutual funds, individual stocks, or maybe even a startup.
The goal of my investment strategy is to preserve some of my capital if things go really bad, while at the same time, putting some my money at greater risk to get a faster payoff. The general principal is that the more risk I assume the more money I should make on the backside. The corollary is that the more risk I take, the greater chance I have of loosing everything. Let’s tie this back to our project discussion.
Projects are investment increments in our Project Portfolio. If I am investing in something that is well understood, in a well understood market, one where we can adequately predict outcomes, chances are I’m not the only one that can see the opportunity or has the capability to build it. I am probably in a more commoditized market and there is a pretty good chance that my long term yield on the investment will be lower. It’s important to control cost because margin isn’t as great.
What if I am investing though in something that is difficult or unknown? Chances are I won’t have the same level of confidence I’ll see a return on my investment. If I am successful, I might be able to change the world and get rich. If I fail, I might run out of money and be unable to feed my family. That is the nature of risk. I think the fundamental problem with projects and estimates is that companies are putting money in very high risk investments expecting a guaranteed return.Managing Portfolio Risk and Return
Personally, I think we should estimate and plan for the stuff that is estimateable. Many, many software products fall into this category and with proper forward planning, risk identification, and a willingness to inspect and adapt and get continuous feedback, we would greatly increase the odds that these projects could deliver a relatively fixed scope within a set of established time and cost constraints. We’ll adapt in the small to deliver in the large… just like my house example.
The projects which can’t be done this way need to use a language of investment and risk. These are not safe investments. We are putting money at risk in hopes of getting significant return. In these projects, we are spending money to learn, and based on what we learn, we adapt and we change, and maybe we even pivot into something entirely different we never even expected. As an investor, I can continue to invest as long as I want, but I never get a guarantee.
The fundamental disconnect is when we start to blur that which is safe and that which is risky and try to use the same language to describe both. We try to use predictive techniques for stuff that needs to be adaptive and we try to converge on outcomes that need to be inherently emergent. Many companies see this and separate development from R&D. Some though are accidentally investing in R&D when they think they are doing safer product development.
When you are doing R&D, an inherently high risk investment, with the expectation of safety and safe returns… that is when we get into trouble. We get ourselves into an irrational place where we are making bets without understanding the risk profile of the bet. You can’t manage your business that way… you can’t manage ANY business that way. My take is that this fundamental disconnect is what is driving the discussion around estimating in software right now.Quick Summary
I get really tired with the never ending debate around should we have projects in product development. I get really tired of the debate over estimating or not estimating. There are fundamentals underneath these debates which are seldom addressed. What is our domain? What is our context? What are the goals of our delivery system? What is the nature of our customer and their needs? What do they have to spend? What do they expect in return?
How I manage my consulting company is often quite different from how I recommend that companies run their product delivery. The world I live in is often quite different from the world my customers live in. We have different constraints and different variables. We have different customers with different needs and sell different products. I like this notion of looking at projects or products as investment vehicles with different risk profiles. Understand your risk and invest accordingly is good advice.
Check out the previous post, Should You Use Agile To Build Your Next Home?
In allen Unternehmen, bei denen ich bereits eine Scrum-Implementierung begleiten durfte, war das Thema Reporting immer ein schwieriges und kontrovers diskutiertes. Meistens sind der Hintergrund die Statusreports aus dem klassischen Projektmanagement mit einer Ampel, Ergebnissen, Aktivitäten, Risiken und Handlungsbedarf – in mehr oder weniger abgewandelter Form. Vielleicht fehlt mir ein bestimmtes Gen, aber ich konnte aus diesen Statusreports noch nie relevante Infos rausziehen.
Was man sich ansieht und was bei den Report-Lesern hängen bleibt, ist die Ampel. In der Regel steht sie auf Grün – höchstens mal Gelb – niemals jedoch würde man sich die Blöße geben, dass man auf Hilfe von außen angewiesen ist. Die Personen, die diesen Report erstellen müssen, halten ihn in der Regel für überflüssig und nicht aussagekräftig. Schreibt man etwas Unerwünschtes hinein, muss man sich mit Nachfragen rumquälen, die jedoch nur davon abhalten, das Problem zu lösen – denn Unterstützung und Hilfe sind eher ein Ausnahmefall.
Und dann kommt plötzlich Scrum. Die POs müssen erst die neuen Artefakte kennen- und nutzen lernen. Das Management und sonstige Reporting-Anforderer sind aber in der Regel etwas schneller als dieser Gewöhnungsprozess. Sie hatten ja vorher einen Status-Report und auf einmal haben sie nichts – oder vielleicht ein paar Zettel. Also fängt man an, sich Gedanken zu machen: Wie könnte ein Reporting in Scrum aussehen?
- Kann man eine Ampel in das Burndownchart einbauen (denn auf die Ampel verzichten wollen wir eigentlich nicht!)?
- Wie können wir abbilden, was gerade im Team los ist (z.B. ein Entwickler fällt für 3 Monate aus)?
- Wie können wir uns im Nachhinein rechtfertigen, wenn in einem halben Jahr doch etwas schief geht?
Oft vergisst man dabei, dass das Reporting in Scrum eigentlich “Built in” ist! Pflegt der Product Owner die ureigenen Artefakte wie den Releaseplan kontinuierlich und wird ein Burndownchart für das aktuelle Release geführt, sollten alle relevanten Informationen vorliegen und sogar aussagefähiger sein als jede Prosa. Diese Artefakte zeigen genau, was tatsächlich bereits geliefert wurde und was in Zukunft geplant ist. Eine Erklärung, warum das so ist, ist natürlich in keinem der beiden Reporting-Vorgehen ausgeschlossen.
Was muss der Kunde oder das Management über diese Form des Reportings wissen? Wie ein PO auf einem meiner Projekte so schön anmerkte: “Es wird viel zu oft in vorauseilendem Gehorsam etwas erstellt, das für den Kunden vielleicht zu viel, zu wenig oder in anderer Art und Weise unzureichend ist. Wir müssen erstmal verstehen, was der tatsächliche Bedarf ist!” Daher:
- Versucht so wenig wie möglich ausschließlich auf schriftliches Reporting zu setzen. Nehmt die Artefakte und geht damit zu den Stakeholdern!
- Erfragt genau, was die Stakeholder an Information benötigen. Kommt ihnen ggf. entgegen und versucht einen Weg zu finden, wie es möglichst wenig Aufwand für euch bedeutet. Betrachtet die Anforderungen jedoch kritisch – warum wird danach gefragt? (mangelndes Vertrauen, Reporting nach oben, Vergleichbarkeit zu anderen Reports, die der Stakeholder bekommt etc.). Macht es wie mit eurem Produkt: Versteht den Kunden bzw. in diesem Fall den User des Reportings.
- Bezieht euer Team in die Pflege der Artefakte mit ein. Macht das Reporting zum Reporting des Teams, nicht zum Reporting für die Stakeholder. Eine Kopplung, nicht eine Entkopplung muss stattfinden.
Welche Erfahrungen habt ihr gemacht? Was braucht euer Kunde? Wie integriert ihr das in den Prozess bzw. nutzt es gleichzeitig als Reporting für das Team?
Cal Newport recently wrote a blog post questioning the value of ignoring gatekeepers in the publishing world. He took a quote from a podcast about self-publishing, and ran with it in the other direction. The original quote is:
The podcast that’s all about getting your words out into the world without contending with agents, publishers, or the other gatekeepers in traditional publishing.
And Cal turns this around to offer some advice on why you would want to use a traditional publisher with it’s gate keepers. This is an interesting conversation, IMO. As a self-published eBook author, published article writer for various magazines, and rejected print-book author, I’ve seen enough of both sides of the story to see benefit on both sides.Sidebar: Read Cal’s Book
As a quick side-bar, Cal is the author of one of my favorite career book: So Good They Can’t Ignore You. If you haven’t read this one yet, you should. It dispels the myth of “do what you love” and aptly replaces it with “love what you do” early in the book, and it only gets better from there.
I tend to have an over-reaction of agreement with statements like the one you quote. But on the other hand, I also appreciate the gate keepers. I’m an aspiring author of technical books. I’ve blogged for 10 years, have published articles in print magazines and online magazines and have recently completed my first eBook which is self-published through leanpub.com. I decided to go with LeanPub and self-publishing for 2major reasons:
- I wanted to iterate the book with paying customers providing feedback on early drafts
- i wanted to avoid the gate keepers
The gatekeepers in this case, may have told me no or they may have helped me alter the concept in to something more marketable. But I wanted to avoid them, because I wanted to get something done and not worry about whether it would be a success. I just wanted to get something done.The Market Size GateKeeper
I didn’t want to worry about whether or not the market size was large enough for a traditional publisher. This is actually one of the reasons I got rejected from a publisher, a few years ago. The idea that I pitched was not a large enough market, and even this small time publisher which I was talking to couldn’t afford to spend the time and money on a market of only ~5 to 10 thousand people.
Yes, a market of 10,000 people is a small market for publishing print books, by most standards. You have to consider the cost of acquiring a customer, conversion rates from interested in to actual customer, etc. You’ll never get 100% of your potential market to buy. It’s usually a pretty low number, percentage-wise. So it makes sense that a publisher needs to avoid small audience sizes.The Motivation GateKeeper
I sat on the book for months, after getting started. It went nowhere while I waited for time to perfect my pitch to a publisher (that I already have a relationship with, through publishing screencasts). After sitting for so long, I decided that waiting for myself to perfect the pitch was not worth it. Even if I would get a bigger audience and produce a better book, getting it launched and getting paying customers would be more of an advantage for me. The income of paying customers helped drive me to make time for the book.
In this case, I’m the gatekeeper. I have a hard time being motivated by potential. I don’t want to spend a year writing a book or an app, with the hopes that it will sell. I want to get something done quickly, start selling it, and use the initial sales to gauge interest and opportunity. My motivation is a gate keeper, but it’s me in this case, not someone else.Hiring My Own GateKeepers?
Having completed my Building Backbone Plugins book, I’m hoping to find a middle ground for my next book(s). What I would really like to do is hire my own gate keepers, to help me work through all of the things that a traditional publisher would do (vetting ideas, transforming mediocre in to masterful, etc, copy and structural editing, etc). I know my book could be 100x better if I would invest in these resources. But I’m ok with what I have now. It has earned $11K of income for me so far, and is still selling. It’s not huge. It’s not even 10% of my annual income. But it was a worthwhile learning experience for me, and will provide
Post Footer automatically generated by Add Post Footer Plugin for wordpress.