Estimates provide project leadership with a view of the project reality to make good decisions, but there is rarely certainty in software development. While estimates solve problems for businesses that want cost and schedule certainty, the problems can potentially be solved differently. The #NoEstimates approach eliminates much of the planning work in favor of collaborating with customers to develop high-level goals and deliver working software frequently, forming a partnership rather than a contractual negotiation. It moves away from committing to requirements that will not be worked on immediately and allows requirements to evolve over time.
How to Get the Most Out of Your Product ManagerAdam Nash
This is a light-hearted walkthrough of product managers for designers, intended to help bridge the gap in understanding about the different roles and how to make the product manager / designer relationship stronger and more productive.
This is part one of the Lean UX workshops outlining in a practical way, the Lean UX processes. These workshops are run as part of the Lean UX Labs experiment.
How to Get the Most Out of Your Product ManagerAdam Nash
This is a light-hearted walkthrough of product managers for designers, intended to help bridge the gap in understanding about the different roles and how to make the product manager / designer relationship stronger and more productive.
This is part one of the Lean UX workshops outlining in a practical way, the Lean UX processes. These workshops are run as part of the Lean UX Labs experiment.
There’s no way around it — any design system project comes with disagreement and spirited debate. Because a design system serves not just many products, but also many stakeholders, from designers and engineers, to marketers and content strategists. Each product team and each discipline brings a unique set of goals and perspectives, and often they’re at odds. These disagreements, if left unresolved, can K.O. your design system before it even gets started. I know, because it’s happened to me. The good news is — it doesn’t need to be this hard. Through my successes and failures building design systems, I’ve uncovered some strategies you can use to keep your team moving forward in harmony. You’ll leave this talk with an understanding of the following: - How to document governance processes to help your team answer the most polarizing questions surrounding design systems, such as when to use an existing component vs create a new component. - How to involve stakeholders across your organization, without stalling your design system or falling victim to design by committee. - How to define your design system team’s roles and responsibilities, as well as how others can contribute to the system.
The Product Mindset- Jonny Schneider (ThoughtWorks Live)Thoughtworks
Jonny explores achieving customer value in the digital age. More than just experiments and customer centricity, adaptive strategies are required, where decisions are based on learning through doing.
Creating Value and Flow in Product DevelopmentAmplitude
Let's consider the time it takes to go from agreeing to do something to a customer receiving value. It may come as a surprise, but most of that time is not spent working. It's spent waiting.
John Cutler, Product Evangelist at Amplitude explains why most of a product developers time is spent waiting and how limiting work in progress, the scope of work and handoffs can increase flow and value.
Are you ready to build an MVP? Where do you start? How do you know what features to build? How do you know how many people you need to build it? How do you know that they are building a right thing in a right way? This presentation and conversation will explore strategies for assembling effective teams for building and deploying an MVP while incurring minimal Product and Technical Debt. We will also discuss implementing an effective process to make sure that your MVP will be built on time and on target.
Design Systems - JD Jones | UMD Monday Tech TalksJD Jones
I discuss what design systems are, how to build one, and how to overcome some common challenges. These slides are from a tech talk for the University of Maryland's Human-computer Interaction Master's program.
Different ways to pay for product development presentationSteve Owens
Different Ways to Pay for Product Development
There are many more ways to pay for product development than you may realize, including not paying for it at all. What is right for your situation will depend on your exact circumstances. You may wish to review the following before starting your next product development project
Different ways to pay for product development presentationSteve Owens
Sometimes it is just as important to know what not to do as it is to know what to do. Ignoring Product Development will result in your business going away.
There’s no way around it — any design system project comes with disagreement and spirited debate. Because a design system serves not just many products, but also many stakeholders, from designers and engineers, to marketers and content strategists. Each product team and each discipline brings a unique set of goals and perspectives, and often they’re at odds. These disagreements, if left unresolved, can K.O. your design system before it even gets started. I know, because it’s happened to me. The good news is — it doesn’t need to be this hard. Through my successes and failures building design systems, I’ve uncovered some strategies you can use to keep your team moving forward in harmony. You’ll leave this talk with an understanding of the following: - How to document governance processes to help your team answer the most polarizing questions surrounding design systems, such as when to use an existing component vs create a new component. - How to involve stakeholders across your organization, without stalling your design system or falling victim to design by committee. - How to define your design system team’s roles and responsibilities, as well as how others can contribute to the system.
The Product Mindset- Jonny Schneider (ThoughtWorks Live)Thoughtworks
Jonny explores achieving customer value in the digital age. More than just experiments and customer centricity, adaptive strategies are required, where decisions are based on learning through doing.
Creating Value and Flow in Product DevelopmentAmplitude
Let's consider the time it takes to go from agreeing to do something to a customer receiving value. It may come as a surprise, but most of that time is not spent working. It's spent waiting.
John Cutler, Product Evangelist at Amplitude explains why most of a product developers time is spent waiting and how limiting work in progress, the scope of work and handoffs can increase flow and value.
Are you ready to build an MVP? Where do you start? How do you know what features to build? How do you know how many people you need to build it? How do you know that they are building a right thing in a right way? This presentation and conversation will explore strategies for assembling effective teams for building and deploying an MVP while incurring minimal Product and Technical Debt. We will also discuss implementing an effective process to make sure that your MVP will be built on time and on target.
Design Systems - JD Jones | UMD Monday Tech TalksJD Jones
I discuss what design systems are, how to build one, and how to overcome some common challenges. These slides are from a tech talk for the University of Maryland's Human-computer Interaction Master's program.
Different ways to pay for product development presentationSteve Owens
Different Ways to Pay for Product Development
There are many more ways to pay for product development than you may realize, including not paying for it at all. What is right for your situation will depend on your exact circumstances. You may wish to review the following before starting your next product development project
Different ways to pay for product development presentationSteve Owens
Sometimes it is just as important to know what not to do as it is to know what to do. Ignoring Product Development will result in your business going away.
Вы слышали о движении #NoEstimates? Разработчики во всем мире отказываются от оценки! Не надо оценивать проекты, фичи и таски — говорят они. Это занимает много времени, да и процесс это не особо приятный.
Вам нравится эта идея? Вижу, что нет.
Вот например, как объяснить заказчику свое новое безоценочное восприятие? Хотите вы или нет, сроки придется называть! Что делать с обязательствами на спринт? А как же прозрачность? Предсказуемость?
По большому счету вы правы. Нельзя просто выкинуть оценку и все. Идея #NoEstimate в том, что можно увеличить прозрачность и предсказуемость разработки, если заменить оценку более эффективными инструментами.
Мы поговорим, что такое на самом деле #NoEstimate и чем практически можно заменить оценку.
#NoEstimates does not mean "No estimates!" - Agile Cambridge 2015Seb Rose
A new version of the talk that describes what software estimates are used for, and alternatives that might serve you better. (This time with added logs ;)
Getting started with #NoEstimates was an interesting topic for last Scrum Breakfast in HCM. We can find some better ways to approach project faster and more efficiency rather than spend a lot of time for estimation.
Estimates or #NoEstimates by Enes PelkoBosnia Agile
Do we need estimates? Are the estimates abused so much that they became unusable? There is a new emerging movement behind #NoEstimates that thinks so. But is it for anyone and in any situation?
No estimates - a controversial way to improve estimation with results-handoutsVasco Duarte
Often we hear that estimating a project is a must. "We can't make decisions without them" we hear often.
In this session I'll present examples of how we can predict a release date of a project without any estimates, only relying on easily available data.
I'll show how we can follow progress on a project at all times without having to rely on guesswork, and we will review how large, very large and small projects have already benefited from this in the past.
At the end of the session you will be ready to start your own
#NoEstimates journey.
#NoEstimates - Stop lying to yourself and your customers, and stop estimatinggerardbeckerleg
After his successful session last year on Agile Scrum, our resident Scrum White Robe Gerard Beckerleg is at it again, except this time he's taking on one of the most divisive topics in software development: Estimation.
In this video recorded at the Sydney SSW offices, Gerard Beckerleg takes a dive into the depths of this controversial topic and extracts the most interesting ideas and raises some very difficult questions about the big white elephant in the room that is Software Estimation.
After examining the pros and cons of estimation Gerard lays the blueprint for a better way to help you and your clients get what they are really looking for.
This is a concept I devised a couple of years ago, and it seems there is a new #NoEstimates audience that would like to know more about it.
A Slicing Heuristic is essentially:
An explicit policy that describes how to "slice" work Just-In-Time to help us create consistency, a shared language for work and better predictability.
The Slicing Heuristic seeks to replace deterministic estimation rituals by incorporating empirical measurement of actual cycle times for the various types of work in your software delivery lifecycle.
It is based on the hypothesis that empiricism leads to smaller cycle time duration and variation (which in business value terms means quicker time to market and better predictability) because it requires work to be sliced into clear, simple, unambiguous goals. Crucially, the heuristic also describes success criteria to ensure it is achieving the level of predictability we require.
Its application is most effective when used for all levels of work, but can certainly be used for individual work types. For example, a User Story heuristic can be an extremely effective way of creating smaller, simpler work increments, allowing teams to provide empirical forecasts without the need for estimating how long individual stories will take. However, if you are able to incorporate this concept from the portfolio level down, the idea is that you define each work type (e.g. Program, Project, Feature, User Story, etc.) along with a Slicing Heuristic, which forms part of that work type’s Definition of Ready.
We are giving estimation for planing budget, sales proposals etc. but we can not estimate variablility and complexity of software systems. So we need a better approach to forecast team throughput by using past infomation, here is the #noestimation.
Budgeting, Estimation, Planning, and #NoEstimates: They All Make Sense for Ag...Josiah Renaudin
Many levels of estimation are practiced in agile, including budgeting, high-level estimation, and task planning (detailed estimation). That might seem like an anathema to agile, but it is not. Mike Harris shares a case study that provides an approach that “checks the box” for standard corporate estimation requirements while staying true to the agile planning and estimation processes. Using the Agile Planning Onion popularized by Mike Cohn, this approach includes team and project level implementations of #NoEstimates concepts. Take away an approach that you can apply to testing for both small and large agile efforts. Most planning and estimating activities for agile testing focus on answering a few very basic questions: When will it be done? How much will it cost? What will actually get tested? Using agile development and testing techniques doesn’t abrogate the need to answer those questions, but it also does not mean testing has to revert to waterfall planning and management techniques.
#NoEstimates project planning using Monte Carlo simulationDimitar Bakardzhiev
Here is the text behind the slides http://www.infoq.com/articles/noestimates-monte-carlo
Here is a video I prepared in order to help people understand how to plan a release using the Monte Carlo simulation in MS Excel http://youtu.be/r38a25ak4co
And here is an Excel file to show how Monte Carlo is done http://modernmanagement.bg/data/NoEstimate_Project_Planning_MonteCarlo.xlsx
Here are the SIPs for the baseline project http://modernmanagement.bg/data/SIPs_MonteCarlo_FVR.xlsx
Here is the planing simulation in Excel http://modernmanagement.bg/data/High_Level_Project_Planning.xlsx
The video ( after the 3:00 minute) http://youtu.be/GE9vrJ741WY on how to use the Excel files
The incumbent’s playbook for launching a vertical SaaS product (Directions EM...Martin Karlowitsch
Presentation held at Directions EMEA 2017 in Madrid.
Been on the market for decades? Living from upfront license revenues and services that you sell alongside? Think of developing a SaaS product, but not sure where to start? Think of building a vertical Microsoft Dynamics 365 SaaS app/product? Come and join me, and I will share my experiences with you from building www.just-plan-it.com on Azure and integrate it with Dynamics 365. I will provide real life experiences, share tips and tricks, books to read and tools to use on that journey. My purpose is encouraging you to go the SaaS development route as you as an incumbent have a huge advantage over funding series driven start-ups: you know your market and have you a sustained cash flow to finance growth. In essence, I will cover the following questions:
1) How to identify and validate market demand?
2) What the heck is an MVP (minimum viable product) and how can it help?
3) How can I easily start the inbound lead generation journey?
4) How to organize development to stay at the “pulse of the market”?
5) How to measure and manage initial success?
6) Why is user onboarding so crucial and difficult?
7) How to prepare for scale?
Becoming an Enterprise SaaS Company | DecisionDesk @ TechPintJohn Knific
DecisionDesk has been through a big journey, starting as a college B2C startup idea, turned successful SMB B2B SaaS product, with an eventual large pivot into Enterprise SaaS servicing the Education market. This is a compilation of lessons learned, originally shared at the December @TechPintNews in Cleveland
Often as developers we are stuck evaluating only the negative artifacts of technical debt. However, what if we looked at the debt metaphor from the point-of-view of our business executives. Would we reach the same conclusions?
In this presentation, I demonstrate that technical debt is not always something to be avoided. In fact, when debt is incurred responsibly, it can become a powerful tool that improves the communication between stakeholders and technologists.
As we inspect this concept, I offer rules and guidelines for evaluating when debt is good and when it is toxic. Once we have a firm understanding of this framework, I present strategies for prudently measuring, paying, and using debt. At the end of the presentation, both developers and business stakeholders will gain a new vocabulary for describing project decisions that will maximize the collaboration between both teams.
This presentation explores the reasons why software projects are significantly more difficult to manage than other types of projects. Software-specific issues related to scope, resources, and time are explored, as well as how software projects differ from other projects in the physical world. An argument for why software constitutes a “Wicked Problem” is expanded, and numerous software development myths are attacked with real-world anecdotes and solutions.
Chapter 9 Changing Your Requirements-Gathering Mind-Set Th.docxchristinemaritza
Chapter 9
Changing Your Requirements-Gathering Mind-Set
The success of any IT project is determined at the very beginning of the project life cycle,
when the IT staff meets with the business clients to gather the requirements. But IT's
track record with this important phase is similar to its history with project management
itself: abysmal. Requirements have been gathered for decades, but most IT
organizations have yet to discover a consistently successful way of sitting down with
business clients, discussing their needs, and translating those needs into a useful
system, enhancement, customization, or software package selection.
In fact, according to some statistics, poor requirements gathering is the cause of about
70 percent of today's technology project failures. That's because passing along one bad
requirement is akin to throwing a stone into a pond and watching how far the ripples go.
According to some calculations, each badly defined requirement results in 10 bad design
statements, which then can multiply to 100 incorrect coding statements. Even if that's
an exaggeration, you can easily see how poor requirements negatively affect application
integrity, maintenance costs, and client satisfaction. This is true whether you're looking
to build a custom system, buy a new software package, or enhance an existing system.
Skipping requirements gathering is like building a house without a plan. For example,
I've seen companies buy software that didn't meet their business needs, mainly because
they wanted to save time on the requirements step. When they tried to modify the
package to meet their needs, they discovered they didn't know the requirements. They
sadly concluded that the step they skipped really did need to be done to make the
package useful.
I often see organizations turn to yet another vendor tool or methodology in their
attempt to improve this situation. But just as with project management, IT is facing a
problem that requires less of a scientific fix and more of a mind-set change that
emphasizes the up-front work of really communicating with business clients to discover
what they need.
From what I've seen in my 24 years in the IT profession and from working with clients
across the country, this is a mind-set change that's way past due, as business leaders
grow increasingly frustrated with the gap between what clients need and what IT
delivers. I learned about the importance of good requirements throughout my varied IT
career, which included stints in analysis, development, production support, project
management, and relationship management. It became clear to me that to have success
in any of these roles, it all starts with good requirements. Everyone who has to read and
use them appreciates them, they increase productivity and quality, and they add
accountability. Finally, a good requirement is measurable because either the end
product delivers on that requirement or it doesn't.
Specificall ...
From Technical Debt to Technical HealthDeclan Whelan
Everyone agrees that technical debt is a burden on software innovation that we would rather avoid, and certainly clean up whenever possible. However, in most organizations, people don't prevent technical debt nearly as much as they should, and they don't ever get the time to clean it up. Why, then, if there are clear incentives to deal with technical debt, is it a rampant problem?
In this session, we will focus on how to deal with technical debt on several levels, including the individual developer, the team, the software value stream, and the larger organization. While technical debt may manifest itself in a developer's IDE, the problem starts long before the developer decides to copy and paste some code, or creates an overly-complex and under-documented class. The pressures on teams and individuals to take on more debt than they should come from many sources. Therefore, the solutions to the technical debt problem must extend beyond the team.
Pin the tail on the metric v00 75 min versionSteven Martin
This presentation shows a different approach to metrics. Instead of listing the Top 10 field-tested metrics, we first talk about goals as prerequisites for metrics. Next, we discuss characteristics of good and bad metrics. We end with walking through an activity called “Pin the Tail on the Metric,” a technique to facilitate the critical thinking needed to determine what types of metrics can help your organization discuss trade-offs, options, and ultimately make better forward-looking decisions.
Entrepreneurship has exploded across the globe in recent years, but intrapreneurship is largely ignored. Intraprenuers are the men and women creating new products and experimenting with new business models within large corporations. Unlike entrepreneurship, they do this with the backing of their corporation and their full salary, decreasing their risk exposure to zero. It's fun, it's impactful, and it's a great stepping stone to venturing out on your own. Learn how to get started in intraprenuership by getting a copy of our new free book.
https://www.codelitt.com/intrapreneur.html
Small Business Survival Guide: 28 tips to unlock you own success story [eBook]Line//Shape//Space
For all the advice you need to make your small business survive and thrive check out this small business tips ebook, bought to you by Line Shape Space.
Check out: http://lineshapespace.com/
Data Con LA 2022 - Customer-Driven Data EngineeringData Con LA
Emad Georgy, CTO, Georgy Technology Leadership
Getting customers engaged and excited about data architecture plans How to integrate UX practices into Data Engineering Data Governance is bullshit - why? Applying performance, scale and usability tests to your Data Engineering journey
IT Executive's Guide to Design thinking | AlgarytmPropel Apps
Understand what design thinking is. Learn how to use design thinking in SAP, Oracle EBS projects to understand what your customers/users really need. Seize the business benefits and innovate.
Steve McConnell is CEO and Chief Software Engineer at Construx Software where he writes books and articles, teaches classes, and oversees Construx’s software engineering practices.
Oprah Winfrey: A Leader in Media, Philanthropy, and Empowerment | CIO Women M...CIOWomenMagazine
This person is none other than Oprah Winfrey, a highly influential figure whose impact extends beyond television. This article will delve into the remarkable life and lasting legacy of Oprah. Her story serves as a reminder of the importance of perseverance, compassion, and firm determination.
Artificial intelligence (AI) offers new opportunities to radically reinvent the way we do business. This study explores how CEOs and top decision makers around the world are responding to the transformative potential of AI.
Modern Database Management 12th Global Edition by Hoffer solution manual.docxssuserf63bd7
https://qidiantiku.com/solution-manual-for-modern-database-management-12th-global-edition-by-hoffer.shtml
name:Solution manual for Modern Database Management 12th Global Edition by Hoffer
Edition:12th Global Edition
author:by Hoffer
ISBN:ISBN 10: 0133544613 / ISBN 13: 9780133544619
type:solution manual
format:word/zip
All chapter include
Focusing on what leading database practitioners say are the most important aspects to database development, Modern Database Management presents sound pedagogy, and topics that are critical for the practical success of database professionals. The 12th Edition further facilitates learning with illustrations that clarify important concepts and new media resources that make some of the more challenging material more engaging. Also included are general updates and expanded material in the areas undergoing rapid change due to improved managerial practices, database design tools and methodologies, and database technology.
The Team Member and Guest Experience - Lead and Take Care of your restaurant team. They are the people closest to and delivering Hospitality to your paying Guests!
Make the call, and we can assist you.
408-784-7371
Foodservice Consulting + Design
3. a good estimate is one that
provides clear enough view on the
project reality to allow the project
leadership to make good
decisions about how to control the
project to hit it’s targets.
4. Making an Estimation
while estimates solve a problem, what
problem do they solve, exactly?
TIME COST DATE
• “the business as a whole is trying to make a
decision — about how to spend it’s money (your
time)” Dan Milstein
• Businesses need certainty about what they will
get and when
• Unfortunately for most businesses there is very
rarely any certainty in software design and
development
5. • You can break the work down into
chunks and add it up
• you can look at a variety of similar
projects to compare
• you can stick your finger in the air
and guess
HOWTO
ESTIMATE
6. Vacations Holidays Sick days Training Weekends
Company meetings Department meetings
Setting up new workstations Installing new
v e r s i o n s o f t o o l s o n w o r k s t a t i o n s
Troubleshooting hardware and software
problems Ramp-up time for new team members
Mentoring of new team members Management
coordination/manager meetings Cutover/
deployment Data conversion Installation
Customization Requirements clarifications
Maintaining the revision control system
Supporting the build Maintaining the scripts
required to run the daily build Maintaining the
automated smoke test used in conjunction with
the daily build Installation of test builds at user
location(s) Creation of test data [Steve McConnell]
MISS ME?
9. What The Hell
We’ll define #NoEstimates as
running a software project
without any human estimation
process. If customers asks,
"How long will it take?" that's
estimating. If they ask what’s
next, that's #NoEstimates.
10. "My boss would never go for that" may
sound like an invitation for dialogue,
but it's actually a fiat.
A term used in policy
debate, the
affirmative's power to
pass the plan in order
to debate impacts.
Allows the debate to
progress instead of
debating whether or
not the plan will be
passed.
• Clearly, many software
customers want estimates. In
many cases, those are
reasonable.
• next logical question: What
problems do estimates solve,
and can we solve them a
different way?
11. ” #NoEstimates is not about
ditching estimates. It is about
improving the way we work such
that estimates become redundant.“
Neil Killick
12. When you tell the customer this
task will take 1-2 day
the customer hear 1 day
you hear 2 days
!
always the way
22. #NoEstimates
J.B. Rainsberger, the author of “jUnit Recipes”,
points out that his first solo software project was
just like this. Rainsberger made no promises up
front, offering instead to show working software
every two weeks — and also allowing the client to
fire him with as little as two weeks' notice.
1. Make Starting Amount of Money
Small; Deliver Working Software Often
23. John Carmack, CEO of Id Software, is famous for the
expression "it's done when it's done," so much so
that the phrase appears under Carmack's name
on WikiQuote.
!
It's worth noting that Apple, one of the largest
publicly traded organizations in the world, is
secretive about upcoming products and refuses to
make quarterly earnings estimates for shareholders
or Wall Street. It doesn't seem to be hurting them.
2. Drop Estimation From Your
Development Process Entirely
#NoEstimates
24. • Most planning work is eliminated here in favor of
developing high-level goals in collaboration with
the customer. !
• At the same time, that's essentially the business
model of Menlo Innovations.!
• By the end of a budget period, the customer could
steer to a place very different that the original
goal. The customer gets what it needs in the
moment — not what it thought it needed six
months ago.
3. Move From Contract Negotiation to
Partnership
#NoEstimates
25. !
•Troy Magennis, a former executive at Sabre
Holdings and Travelocity, has done some of the
most prominent work in this space. Magennis has
also developed predictive models that include
complex elements like deviation, cycle time,
defects/time for repair and so on…!
•Even without a complex model, most agile teams
are capable of producing a burn-down chart that
can answer the question, "Is this date and this
scope possible?"
22. Fund a Pilot That Delivers Working
Software; Then Use Modeling to
Forecast Schedule
#NoEstimates
• sounds crazy though
28. With the #NoEstimates approach we don't commit to
requirements that we are not going to immediately
work on
The reason is simple: requirements have a "best
before" date and expire.