Warning: Table './devblogsdb/cache_page' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_page WHERE cid = 'http://www.softdevblogs.com/?q=aggregator' in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc on line 135

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 729

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 730

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 731

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 732
Software Development Blogs: Programming, Software Testing, Agile, Project Management
Skip to content

Software Development Blogs: Programming, Software Testing, Agile Project Management

Methods & Tools

Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!

Feed aggregator
warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/common.inc on line 153.

What is the Secret to Insane Productivity?

Productivity is truly an advantage.  Imagine if you had boundless energy and could tackle your challenges with all that you are capable of.

What if you could double, triple or maybe even 10X your productivity?

Maybe you can.

But how do you take your productivity to the next level?

In What is the Secret to Insane Productivity, I walk through what it takes to achieve high levels of performance, but I want to summarize some of the key insights here.

One of the most overlooked challenges to your personal productivity is your energy level.  You can chase a bunch of mental tricks, and you can try to organize the heck out of everything you do, and you can apply extreme prioritization, and you can add in some extreme motivation, but if you don’t have the energy you need, you won’t get very far.

The key is that you have multiple sources of energy.  Start with your body.   If you start to move more, you generate more energy.  Energy isn’t something you just have.  It’s something you create.  But you have to kick start your energy factory and the key to that is to move more often.  It could be as simple as parking a little further away, getting up for quick walks, or adding a 20 or 30 minute workout in the morning.

Even Richard Branson says the secret of his extreme productivity is working out.

You can also draw energy from your mind, emotions, and spirit.  So if your body is primed and ready for action, but you have a way of knocking yourself down with negative self-talk, that’s not going to help.  The easiest way to deal with negative self-talk is to talk about to your negative thoughts.  That’s right, challenge them.  This is not a new idea.  In fact, this is a proven practice used by many of the world’s best counselors and coaches to help people get out of depression, defeat limiting beliefs, and find new levels of motivation, inspiration, and boundless energy.

Creating better energy for high performance is a a matter of both reducing negative energy drains, and adding rituals and routines that make you come alive.  A quick way to do this is to stop or limit doing the things that drain you and spend more time in your strengths.  Spend much more time in the things that you could do all day.  And then use your strengths as your creative twist to add more value in everything you do.  This is how you become unstoppable.

Energy is truly the secret of insane productivity because you can’t get more hours in a day, but you can add more energy to everything you do.

But like anything, there is no silver bullet.

So what else really makes the difference when it comes to high performance and insane productivity?

Your strategies.  Your techniques.  There are ways to do things better, faster and cheaper.  And experts around the world know them.  And they tend to share them.  They write them in books.  They share them in videos.  They are all around you.  They might be the unsung hero down the hall.  How do you find them?  You start to look for them.  You ask.  You will soon find the people that will help you take your game to the next level, as they share their best strategies and techniques with you.

OK, now.

So you have this boundless energy.  You are spending time in your strengths.  You have these super strategies and techniques for high performance.  

Have you nailed it?

Are you now super productive?

Well, there is another key you need in your arsenal of insane productivity.   There is one more true secret that is underlies exponential productivity.

The answer is this:

Value is the ultimate short cut.

And value is in the eye of the beholder or stakeholder.

When you know what is truly valued, you can trim away all the waste and want not.

So now then, how do you figure out what’s actually valued?  What is really valued by the system you are in, by your customers, by your team, by your partner, by your friends, by whoever?

Well, one way is to ask.  (Yeah, it sounds simple, but you’d be surprised by how many people don’t actually do this.   Did you ever get a gift somebody swore you would love?)

But people don’t always know.  If Ford asked his customers what they wanted, they would have said faster horses.

And value changes.  Time changes what’s important.  And ultimately the value is in the change.  So if you aren’t changing, you aren’t creating new value.

So then, how do you pursuit value?

You treat value like a verb.

Act on it.  Test it.  Learn it.

Create rapid learning loops where failure is OK and learning is valued.

Learn your way forward.

The value you create in your wake will fill a void in the world that will be your unique dent in the universe.

Categories: Architecture, Programming

Goodbye, Knowledge Workers. Welcome, Creative Workers!

NOOP.NL - Jurgen Appelo - 10 hours 18 min ago
goodbye-knowledge-workers

Twenty years ago, I taught people how to develop their own templates, macros, and solutions in Microsoft Office programs. It was good business, for a few years. But rapid innovation in desktop software quickly eroded my business model. Deep knowledge of Office products became useless and I had to move on to other ideas.

We can see the same happening across many industries and business models nowadays.

I don’t need highly-paid photographers anymore because it’s easier than ever to take great photos with my smartphone. I hardly need my accountant because better software takes care of all the simple bookkeeping rules and answers to complicated questions can easily be found online. And I don’t need to understand how to design my blog because talented, affordable designers can be found all over the world through online marketplaces.

In this century, there is less need to know things and more need to make things.

The half-time of knowledge has been shrinking steadily over a decade or two. Has anyone recently read a manual for a tool or application? For me, the last time was five years ago, when I bought a digital camera. The only thing I remember from the manual was how to set picture quality to automatic. This turned out to be a fine setting for 99% of the photos I took with it, for two years, until smartphones stole its job.

In the 21st century, there is little value in knowing how to use a tool because tools emerge and disappear faster than piercings in a teenager’s body. The value now is in making great-looking photos with any tool you happen to have in your hands. Likewise, there is little value in knowing which tax rules to apply to which invoices. The value is in making the software that does this automatically for its users. And maybe there is some value in knowing HTML for ordinary writers and publishers. But the real value is in making blog posts and articles that are so inspiring or remarkable that they get many views.

All of this means that Peter Drucker’s knowledge workers are on their way out. Investing in knowledge and then trying to charge a good price putting this knowledge to good use is a dead business model. Knowledge can be found everywhere, at almost no cost. This century is for creative workers, who invest their time in experimentation and practice while continuously updating and replacing their knowledge.

Thanks to ubiquitous information, the knowledge economy has turned into the creative economy.

photo: (c) 2016 Jurgen Appelo

The post Goodbye, Knowledge Workers. Welcome, Creative Workers! appeared first on NOOP.NL.

Categories: Project Management

Goodbye, Knowledge Workers. Welcome, Creative Workers!

NOOP.NL - Jurgen Appelo - 10 hours 18 min ago
goodbye-knowledge-workers

Twenty years ago, I taught people how to develop their own templates, macros, and solutions in Microsoft Office programs. It was good business, for a few years. But rapid innovation in desktop software quickly eroded my business model. Deep knowledge of Office products became useless and I had to move on to other ideas.

We can see the same happening across many industries and business models nowadays.

I don’t need highly-paid photographers anymore because it’s easier than ever to take great photos with my smartphone. I hardly need my accountant because better software takes care of all the simple bookkeeping rules and answers to complicated questions can easily be found online. And I don’t need to understand how to design my blog because talented, affordable designers can be found all over the world through online marketplaces.

In this century, there is less need to know things and more need to make things.

The half-time of knowledge has been shrinking steadily over a decade or two. Has anyone recently read a manual for a tool or application? For me, the last time was five years ago, when I bought a digital camera. The only thing I remember from the manual was how to set picture quality to automatic. This turned out to be a fine setting for 99% of the photos I took with it, for two years, until smartphones stole its job.

In the 21st century, there is little value in knowing how to use a tool because tools emerge and disappear faster than piercings in a teenager’s body. The value now is in making great-looking photos with any tool you happen to have in your hands. Likewise, there is little value in knowing which tax rules to apply to which invoices. The value is in making the software that does this automatically for its users. And maybe there is some value in knowing HTML for ordinary writers and publishers. But the real value is in making blog posts and articles that are so inspiring or remarkable that they get many views.

All of this means that Peter Drucker’s knowledge workers are on their way out. Investing in knowledge and then trying to charge a good price putting this knowledge to good use is a dead business model. Knowledge can be found everywhere, at almost no cost. This century is for creative workers, who invest their time in experimentation and practice while continuously updating and replacing their knowledge.

Thanks to ubiquitous information, the knowledge economy has turned into the creative economy.

photo: (c) 2016 Jurgen Appelo

The post Goodbye, Knowledge Workers. Welcome, Creative Workers! appeared first on NOOP.NL.

Categories: Project Management

A Working Definition of Agile

In a recent workshop, a participant asked me, “What does agile mean? How do you know if you are agile?” He wants to use kanban to see the flow of work through his group. Someone told him he needed to use iterations to be agile. (I had a little rant about this in What Does Agile Mean to You?)

I suggested this could be his working definition:

  • You can deliver what you want (some form of value).
  • You can deliver that value  when you want.
  • You can then change to the next most important chunk of valuable work.
  • You learn from the previous work you did, both about the work and the process of doing the work.

That’s not all agile is, but it might be a good working definition. If you work towards being able to deliver what and when you want, move to the next thing, and learn, you have the feedback cycles. (You might also look at the agile principles behind the Manifesto.)

These are practices that increase your agile capabilities:

  • Iterations, because they limit the work a team can commit to in a given time period.
  • Kanban with work in progress limits, because they limit the work a team can do, and show the flow of work.
  • Retrospectives because you learn from previous work. (Someone important said if they only did one practice it would retrospectives. I can’t remember who said that. Sorry.)
  • Standups because they reinforce micro-commitments to finishing work.
  • Technical excellence practices from XP, because they make changing the code and tests easier.

You don’t need any of these to be agile. They help. You might find other practices to be more helpful in your context.

I have some previous posts that might be interesting if you also are wondering what agile means for you:

For me, practices are interesting, especially if I choose to experiment with them. What could I do to increase my throughput and learning, and therefore, my ability to adapt? Agile is not about specific practices. It is about a mindset of finishing small valuable chunks, feedback, and change.

Categories: Project Management

GTAC Diversity Scholarship

Google Testing Blog - 12 hours 20 min ago
by Lesley Katzen on behalf of the GTAC Diversity Committee

We are committed to increasing diversity at GTAC, and we believe the best way to do that is by making sure we have a diverse set of applicants to speak and attend. As part of that commitment, we are excited to announce that we will be offering travel scholarships this year.
Travel scholarships will be available for selected applicants from traditionally underrepresented groups in technology.

To be eligible for a grant to attend GTAC, applicants must:

  • Be 18 years of age or older.
  • Be from a traditionally underrepresented group in technology.
  • Work or study in Computer Science, Computer Engineering, Information Technology, or a technical field related to software testing.
  • Be able to attend core dates of GTAC, November 15th - 16th 2016 in Sunnyvale, CA.


To apply:
Please fill out the following form to be considered for a travel scholarship.
The deadline for submission is June 1st.  Scholarship recipients will be announced on June 30th. If you are selected, we will contact you with information on how to proceed with booking travel.


What the scholarship covers:
Google will pay for standard coach class airfare for selected scholarship recipients to San Francisco or San Jose, and 3 nights of accommodations in a hotel near the Sunnyvale campus. Breakfast and lunch will be provided for GTAC attendees and speakers on both days of the conference. We will also provide a $50.00 gift card for other incidentals such as airport transportation or meals. You will need to provide your own credit card to cover any hotel incidentals.


Google is dedicated to providing a harassment-free and inclusive conference experience for everyone. Our anti-harassment policy can be found at:
https://www.google.com/events/policy/anti-harassmentpolicy.html
Categories: Testing & QA

GTAC Diversity Scholarship

Google Testing Blog - 12 hours 20 min ago
by Lesley Katzen on behalf of the GTAC Diversity Committee

We are committed to increasing diversity at GTAC, and we believe the best way to do that is by making sure we have a diverse set of applicants to speak and attend. As part of that commitment, we are excited to announce that we will be offering travel scholarships this year.
Travel scholarships will be available for selected applicants from traditionally underrepresented groups in technology.

To be eligible for a grant to attend GTAC, applicants must:

  • Be 18 years of age or older.
  • Be from a traditionally underrepresented group in technology.
  • Work or study in Computer Science, Computer Engineering, Information Technology, or a technical field related to software testing.
  • Be able to attend core dates of GTAC, November 15th - 16th 2016 in Sunnyvale, CA.


To apply:
Please fill out the following form to be considered for a travel scholarship.
The deadline for submission is June 1st.  Scholarship recipients will be announced on June 30th. If you are selected, we will contact you with information on how to proceed with booking travel.


What the scholarship covers:
Google will pay for standard coach class airfare for selected scholarship recipients to San Francisco or San Jose, and 3 nights of accommodations in a hotel near the Sunnyvale campus. Breakfast and lunch will be provided for GTAC attendees and speakers on both days of the conference. We will also provide a $50.00 gift card for other incidentals such as airport transportation or meals. You will need to provide your own credit card to cover any hotel incidentals.


Google is dedicated to providing a harassment-free and inclusive conference experience for everyone. Our anti-harassment policy can be found at:
https://www.google.com/events/policy/anti-harassmentpolicy.html
Categories: Testing & QA

GTAC 2016 Registration is now open!

Google Testing Blog - 12 hours 25 min ago
by Sonal Shah on behalf of the GTAC Committee

The GTAC (Google Test Automation Conference) 2016 application process is now open for presentation proposals and attendance. GTAC will be held at the Google Sunnyvale office on November 15th - 16th, 2016.

GTAC will be streamed live on YouTube again this year, so even if you cannot attend in person, you will be able to watch the conference remotely. We will post the livestream information as we get closer to the event, and recordings will be posted afterwards.

Speakers
Presentations are targeted at students, academics, and experienced engineers working on test automation. Full presentations are 30 minutes and lightning talks are 10 minutes. Speakers should be prepared for a question and answer session following their presentation.

Application
For presentation proposals and/or attendance, complete this form. We will be selecting about 25 talks and 300 attendees for the event. The selection process is not first come first serve (no need to rush your application), and we select a diverse group of engineers from various locations, company sizes, and technical backgrounds.

Deadline
The due date for both presentation and attendance applications is June 1st, 2016.

Cost
There are no registration fees, but speakers and attendees must arrange and pay for their own travel and accommodations.

More information
Please read our FAQ for most common questions
https://developers.google.com/google-test-automation-conference/2016/faq.
Categories: Testing & QA

GTAC 2016 Registration is now open!

Google Testing Blog - 12 hours 25 min ago
by Sonal Shah on behalf of the GTAC Committee

The GTAC (Google Test Automation Conference) 2016 application process is now open for presentation proposals and attendance. GTAC will be held at the Google Sunnyvale office on November 15th - 16th, 2016.

GTAC will be streamed live on YouTube again this year, so even if you cannot attend in person, you will be able to watch the conference remotely. We will post the livestream information as we get closer to the event, and recordings will be posted afterwards.

Speakers
Presentations are targeted at students, academics, and experienced engineers working on test automation. Full presentations are 30 minutes and lightning talks are 10 minutes. Speakers should be prepared for a question and answer session following their presentation.

Application
For presentation proposals and/or attendance, complete this form. We will be selecting about 25 talks and 300 attendees for the event. The selection process is not first come first serve (no need to rush your application), and we select a diverse group of engineers from various locations, company sizes, and technical backgrounds.

Deadline
The due date for both presentation and attendance applications is June 1st, 2016.

Cost
There are no registration fees, but speakers and attendees must arrange and pay for their own travel and accommodations.

More information
Please read our FAQ for most common questions
https://developers.google.com/google-test-automation-conference/2016/faq.
Categories: Testing & QA

Quote of the Day

Herding Cats - Glen Alleman - 13 hours 50 min ago

Predictions are always difficult - especially about the future ― Niels Bohr
― Neandertal's Guide to Cost Estimating, Naval Aviation Systems

This is a quote often used by those conjecturing that estimating is a waste. The quote is true of course. Making predictions about the future is difficult. But that has nothing to do with the need for predictions and the estimates that support them.  When making decisions in the presence of uncertainty about some outcome in the future - this is the basis of Microeconomics of decision making.

Categories: Project Management

What Does An Agile Coach Deliver?

OLYMPUS DIGITAL CAMERA

Agile Coaches help teams and organizations embrace Agile and help maximize the delivery of business value.  We use terms like enable and facilitate to describe how they help organizations and teams transform.  But what does an Agile Coach actually do?  If we unpack enable and facilitate what do we actually find?  We actually mean a variable mix of activities that includes: consulting, cajoling, training, arbitration and mentoring.

Coaches sometimes act as consultants.  A consultant will actively involve him or herself in the game. Sometimes an Agile Coach will have to actively involve themselves in performing a task or activity so that the team can see the technique in action.

Coaches cajole, with gentle urging or coaxing, the team or organization to change behaviors that don’t live up to Agile principles and values. In many cases this cajoling is underscored by the war stories a Coach can deliver about the trials and tribulations that will ensue if the behavior is not corrected. The experiential base is important for the Coach to be able to hold the moral (metaphorically speaking) high ground needed to persuade the team or organization.

Coaches deliver training.  Training comes in many shapes and sizes.  Coaches will be able to deliver training on a just-in-time or ad-hoc basis based on their own observations of how work is being done.  The goal of ad-hoc training is to ensure the team or teams understand how to apply specific techniques as they are applying them. I liken this to a form of just-in-time training, which leverages a principle from adult learning, that holds that adults retain knowledge better when it can be immediately applied.  This does not exclude leading and organizing training as part of more formal organizational change program.

Coaches arbitrate conflicts and difficult decisions.  Projects, whether to transform whole organizations or to implement a set of simple user reports, always include the need to make decisions. Coaches help organizations make decisions so that they can move forward with a minimal loss of inertia.  Facilitation for an Agile organization is a skill that is part art and part science – think emotive negotiation (or as a friend of mine calls it “family counseling for teams”).  The best Coaches teach the team or organizations they are working with these skills.

Coaches mentor.  A mentor is a trusted counselor who provides guidance, advice and training usually at an intimate (one-on-one) level.  A mentor needs to be dependable, engaged, authentic, and tuned into the needs of the mentee, so that the transfer of guidance is safe and efficient.

When an Agile Coach enables and facilitates, they really  consult, cajole, train, arbitrate and mentor. The art of being a good Coach is knowing what the mix of these activities are appropriate for any specific situation.


Categories: Process Management

Get your apps and games ready for space with Google Play (April Fools')

Android Developers Blog - Wed, 05/04/2016 - 00:14

Posted by Lily Sheringham, Google Play team

Google Play lets you distribute your apps and games to over 1 billion active Android users around the world. With advances in space exploration and the advent of galactic tourism, there will be a high number of users beyond this world that developers need to start thinking about, too. Google Play can now help you reach them. We’ve added new features to the Google Play Developer Console and updated the material design guidelines, to help you design, test, and distribute your apps and games in space.

Here’s a look at how The Guardian, one of the largest English-news organizations in the world, enhanced its Android app to enable astronauts and space travellers to stay informed and up-to-date, while in orbit or on the surface of the moon.


"I am pleased to have The Guardian's application to test the growing Interplanetary Internet" says Vint Cerf, distinguished visiting scientist at the Jet Propulsion Laboratory and Google's Chief Internet Evangelist. "The interstellar version is in development and I'm looking forward to having more Google Play apps and games tested in space flight."

Get your apps and games ready for take off today.

Categories: Programming

SE-Radio Episode 256: Jay Fields on Working Effectively with Unit Tests

Stefan Tilkov talks with Jay Fields, author of the book “Working Effectively with Unit Tests,” about unit testing in practice. Topics include how to write good unit tests, what mistakes to avoid, and different categories of unit tests. Jay explains the value of unit tests and why you might want to delete them if you […]
Categories: Programming

Can You Make a Decision in Presence of Uncertainty Without Estimating?

Herding Cats - Glen Alleman - Tue, 05/03/2016 - 23:06

The answer to this question starts with a simple principle based notion.

Can you make a non-trivial (not de minimis) decision in the presence of uncertainty?

The #Noestimates advocates didn’t start there. They started with “Estimates are a waste, stop doing them.” Those advocates also started with the notion that estimates are a waste for the developers. Not considereing those who pay their salary have a fiduciary obligation to know something about cash demands and profit resulting from the investment work in the future.

The size of the “value at risk” is also the starting point for estimates. If the project is small (de minimis) meaning if we over run significantly no one cares, then estimating is likely a waste as well. No matter the size of the project, from multi-million’s to smaller, it's actually determined by “value at risk,” and that is determine by those paying not by those consuming. So the fact we work on larger projects does not remove the principle of “value at risk.” Your client’s (internal or external) V@R may be much different than mine – but it’s not our money.

Next comes an original post from Woody – “you can make decisions with No Estimates.” If we are having a principled based conversation (which NE’er don’t) then that statement violates the principles of Microeconomics. Making decisions in the presence of uncertainty (and I’m assuming all projects of interest have uncertainty), than estimates are needed to make decisions. Those decisions are based in MicroEcon on the Opportunity Cost and the probability of making the best choice for the project involves assessing the probability outcome of those choices, estimating is required.

Real options are a similar process in IT based on estimating. Vasco stated long ago he was using RO along with Bayesian Decision Making. I suspect he was tossing around buzz words without knowing what they actually mean, since we never saw an example of how he used RO when asked to show one.

From the business side, the final principle is Managerial Finance. This is the basis of business management of its financial assets. The balance sheet is one place these are found. Since the future returns from the expenses of today and the “potential” expenses of the future are carried in that balance sheet, estimating is needed there as well for the financial well being of the firm.

These three principles - Value at Risk, MicroEconomics of Decision Making, and Managerial Finance appear to be ignored by the NE advocates when they start with the conjecture that “decisions can be made without estimates,” and continuing on with “estimates are a waste of developers time, they should be coding not estimating.”

It’s the view of the world, that as a developer “it’s all about me.” Never looking at their paycheck and asking where did the money come from. That’s a common process and one I did when I started my career 35 years ago as a FORTRAN developer for Missile Defense radar systems and our boss had us get out our paychecks (a paper check in those days) and look at the upper left hand corner. “That money doesn’t come from the Bank of America, El Segundo, Blvd, Redondo Beach, it comes from the US Air Force. You young pups need to stay on schedule and make this thing work as it says in the contract.”

In the end the NE conversation can be about the issues in estimating and there are many - Steve McConnell speaks to those. I work large federal acquisition programs –  IT and embedded systems. And many times the “over target baseline” root cause is from “bad estimating.” But the Root Cause of those bad estimates is not corrected by Not Estimating as #Noestimates would have us believe.

As posted on this blog before and sourced from the Director of “Performance Assessment and Root Cause Analysis,” unanticipated growth in cost has 4 major sources:
1. Unrealistic performance expectations – that will cost more money.
2. Unrealistic cost and schedule estimates – the source of poor estimating.
3. Inadequate assessment of unmitigated risk exposure.
4. Unanticipated technical issues.

Research where I work some times (www.ida.org) has shown these are core to problems of cost overruns in nearly every domain from ERP to embedded software intensive systems. It is unlikely those 4 root causes are not universal.

So what’s #NoEstimates trying to fix? They don’t say except - “exploring” new ways.” In what governance frameworks are they exploring? They don’t say. They don’t actually say much of anything, just “estimates are waste, stop doing them and get back to coding.”

As my boss in 1978 reminded us newly minted physical Master’s degree'd coder, “it ain’t your money it’s the USAF’s money, act accordingly – we need an estimate of this thing you’re building can be used to find SS-9’s coming our way?” Since then I’ve never forgotten his words, “business (in that case TRW) needs to know how much, when, and what, if it’s going to stay in business.”

Related articles Managing in Presence of Uncertainty Here, There Be Dragons Estimating Processes in Support of Economic Analysis
Categories: Project Management

Process Improvement In the Second Grade

Herding Cats - Glen Alleman - Tue, 05/03/2016 - 22:31

Our daughter is an elementary school teacher in Austin - and a Graduate student at UT Austin in the Board Certified Behavioral Analyst program. When I hear about some corrective action to an unnamed cause - not the symptom but the cause -  like estimates are the smell of dysfunction, I think of a chart she has hanging in her room for her students, where they are learning critical thinking skills they will need in life. 

Screen Shot 2016-04-02 at 5.45.46 PM

  • Focus Question - what is the question we're trying to explore? Is that question clearly formed?
  • Prediction - is there a prediction of what the possible outcomes might be when we discover the answer to the question? This is important, because we need to separate the answers into plausible answers and implausible answers. That way we can sort out the Wheat from the Chaff. Which is a nice way of saying sorting out the BS from the plausible.
  • Plan - OK, now what's our plan to start exploring. This is exploring is a directed exploring. Not a wandering around looking for Unicorns in the forest. That is called a Snipe Hunt. There is no Snipe to hunt, but it's a fun thing to do for novice and naive tenderfoots in the scout pack or the business of spending other people's money. 
  • Data - what data will we need to develop to support our search for the answer to the Focus Question? Where would we  find this data? How will we be able to validate this data. Is this data personal anecdotes or is it from a principled framework that can be tested in the absence of the person providing  the data.
  • Claims & Evidence - when claims are made, is there any testable evidence of that data? And most importantly is there any testability that supports the Focus Question?
  • Reflection - with this process, what do we learn? Was there a prediction that could be tested - estimates are the smell of dysfunction? How would you test that conjecture? What would the predicted outcome of that Focus Question and Prediction in terms of measurable evidence? Do we have a Plan to explore that question - or are we  just going to wander around looking for that mythical Unicorn that will bring Rainbows and Sunshine to our project? Where is this data? How did we find it? Journal papers, books, actual data collected ourselves using good data analysis techniques - not the pesky Flaw of Averages approach, but an actual data collection process? For claim to be credible there needs to be evidence to support the claim.

So in the end if 2nd graders in Austin Texas can figure this out, why can't adults tasked with spending other people's money do this as well?

Related articles Everything I Learned About PM Came From a Elementary School Teacher Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management
Categories: Project Management

The Ultimate Tester: Curiosity

Xebia Blog - Tue, 05/03/2016 - 16:15
In 2014 Bill Sempf posted this Tweet: QA Engineer walks into a bar. Orders a beer. Orders 0 beers. Orders 999999999 beers. Orders a lizard. Orders -1 beers. Orders a sfdeljknesv. — Bill Sempf (@sempf) September 23, 2014 His message caused a chain reaction of awesome responses from people thinking of all the edge cases in this

How to Prevent Estimate Inflation

Mike Cohn's Blog - Tue, 05/03/2016 - 15:00

I spoke with a Scrum Master recently who told me his team had nearly doubled their velocity in only two months. Rather than be happy about this, though, he was concerned.

He knew the team had not suddenly become twice as productive. In fact, he doubted they'd actually sped up at all. Yet their velocity showed they had.

The cause of this sudden and dramatic increase was story point inflation. Or, more generally, estimate inflation, because the problem can happen with estimating units other than just story points.

Estimate inflation is when the estimate assigned to a product backlog item (usually a user story) increases over time. For example, today the team estimates something will take five points but previously they would have called it three points.

Why Does Estimate Inflation Happen?

There are a few possible causes of estimate inflation. One of the most common, though, is excessive pressure on the team to improve or deliver more points per sprint. This often comes from bosses or possibly stakeholders outside the team who are pushing the team.

Velocity becomes a really tempting (but bad) metric in these cases and teams are pushed to demonstrate that they’re going faster by increasing velocity.

 

When a team is under pressure to increase velocity, team members will often start to round estimates up during story point estimate meetings (often done with Planning Poker). For example, consider a team that is debating whether a particular story is three or five points. They’re having a legitimate debate about this.

At some time during that discussion, one or more people will remember the team is under pressure to increase velocity. And some might shift in favor of calling the story five points instead of three.

I want to be clear this isn’t lying. It’s not blatant padding. The team was truly debating three versus five. And when someone remembers the team is under pressure, that person switches to favor five.

And so that story is called a five.

Now consider another story being estimated perhaps a week or two later. In considering the new story, someone compares it to the five-point story and thinks, “Well, this new one is a little bigger than that five,” and proceeds to estimate it as perhaps an eight.

And this is how estimate inflation happens.

How to Prevent Estimate Inflation

I’ve found the best way to prevent estimate inflation from occurring is to always compare the item being estimated against two (or more) previously estimated product backlog items. In my “Agile Estimating and Planning” book, I referred to this as triangulation, borrowing the old nautical term for fixing a ship’s location.

So, when a team thinks about estimating a story as five points, they would first compare that story to two other stories--ideally one smaller and one larger. In deciding if a story should be estimated as five points, they would compare the story to a three-point story and think, Will the effort to do this new story be a little more than this three-pointer?

They would next compare that story against an eight- or 13-point story. And they’d want to see if the story felt appropriately sized as five in comparison to one of those. These comparisons are shown in Figure 1.

 

Triangulating a 5-point story by comparing it with 3-point and 13-point stories.

When an item being estimated is compared to two or more previously estimated items, it helps ensure the internal consistency of the estimates.

Ideally we’d love to consider each estimate in comparison to all previous estimates. But that would be way too much work. Triangulating a story by comparing it to two others is generally sufficient.

If we think about the stories as nodes in a graph, triangulating can be visualized by drawing lines between each of the nodes the team explicitly compared while estimating. This can be seen in Figure 2.

 

 

Each story, A-F, has been compared with two or three other stories.

Here we see that product backlog items A and B have been compared to three other items each. Backlog items C through F have each been compared twice.

Triangulating Stops Estimate Inflation

Triangulating prevents estimate inflation because the use of two comparisons helps point out when estimates are beginning to inflate.

To see this, consider the team that is trying to decide between estimating a story as either three or five. Remembering they are under pressure to increase velocity, they decide to call it a five. And it may legitimately seem just a bit bigger than some other three-point stories.

But, when the team triangulates that story against another five or an eight, they’ll most likely realize that the story is not really a five.

There’s One More Good Way to Prevent Estimate Inflation

There’s at least one more very good way to prevent estimate inflation. But, since this post is already long, I’ll save that for the weekly tip I share each Thursday by email. If you’re not already subscribed, consider signing up now if you’re interested in learning more.

What Do You Think?

Has estimate inflation been a problem on your team? How do you handle it? Please share your thoughts in the comments below.

How to achieve Ultimate Agility?

Xebia Blog - Tue, 05/03/2016 - 10:20
In reaction on the Era of Big Transitions we currently live in, many organizations are reinventing themselves as we speak.  How can we survive?  Or rephrased more positive: How can we turn this threat into a unique chance? Most organizations start with this journey by redesigning their culture, way of work and organizational structure.  But

Effective Programmers Learning

From the Editor of Methods & Tools - Tue, 05/03/2016 - 08:50
Allison Kaptur gave a keynote at Kiwi PyCon 2015 in New Zealand on effective learning for programmers. There were two pieces to the talk: one about the mindset needed by programmers for learning and one about particular strategies that software developers can use. Video Producer: https://nzpug.org/ Slides of the presentation: http://www.slideshare.net/akaptur/effective-learning-strategies-for-programmers Further reading: http://akaptur.com/blog/2015/10/10/effective-learning-strategies-for-programmers/

Find success on Google Play: What app developers can learn from games

Android Developers Blog - Mon, 05/02/2016 - 18:14

Posted by Matteo Vallone, Business Development Manager at Google Play

(As a way to reach more app developers and help them grow successful businesses on Google Play, this post was first published on The Next Web – Ed.)

There is much common ground between freemium apps and games businesses when it comes to achieving success. Users are, however, more used to paying for games than apps, stemming from the history of traditional gaming consoles. Moreover, mobile games are also able to easily offer ‘virtual goods’ across a range of price points to suit every pocket. This means that game developers have had plenty of opportunity to learn about how to improve onboarding, conversion, and ultimately the user Lifetime Value (LTV). So what can app developers learn from game developers? Here are some best practice tips and insights from successful game developers that can be applied to many apps, today.

Drive app success the game developer way:

1. Optimize retention before investing in acquisition

Retention is king, and retention drives conversion. For games developers, retention is the key measure of game quality and whether it appeals to players.

Most game developers will “soft launch” to beta testing communities or test markets. During this phase, the game is tweaked to optimize retention by looking into specific areas, such as tutorial completion, level difficulty and conversion. Developers can then track retention using the Cohorts reports in Google Analytics. Once retention is satisfactory, the developer can go to full launch and start investing in user acquisition.

2. Retain users with step-by-step engagement

The first seven days after install are the most critical for retention: users install several apps to try them, and decide in the first few days which ones they want to keep using. If you can retain for that time span, your app is more likely to become part of the user’s daily routine.

There are some simple ways to progressively build user engagement. It’s important to present a strong story that explains why that app is relevant to the user, while introducing them to key features. Then place features that offer the user value early, so they can be found without much effort.

This is a not a one-size-fit-all. To find the right solution, a developer needs to first make assumptions on what user flows can improve retention and then run A/B tests to validate or correct them. For example, a developer could think that introducing sign-in later in the user flow might improve retention. Also, the developer needs to keep in mind what the key long term engagement metrics are for the individual app (such as photos uploaded or the number of articles read) and measure the impact of the different onboarding flows on those metrics as well.

In general, these principles are good places to start optimizing your onboarding:

  • Look for ways to let the users experience the app straight away, rather than taking them through a long, complex setup.
  • Present “activation moments” — such as registering an account, uploading a video, or finding friend — gradually
  • Start by requiring minimal investment by the user, then ask them for more details as they are needed to use the apps features.
  • Treat permissions as a service for the user. For example, if you want users to register, show them in advance that, by making their experience more personal, they’ll get more value from the app.

In this example, OkCupid tried different onboarding flows and found the most engaging version increased seven-day retention by over 20 percent.

Finally, ensure the user can understand the value of your app before you start asking them to pay. Game developers are particularly good at letting their users try most or all product features for free in in a set number of days or sessions.

A great tool to help analyze how users are engaging (or not) with the app is through the Flow Report in Google Analytics. Using this report, a developer can see how users navigate through the app and where they leave to identify potential roadblocks.

3. Target the right offers at the right users

Understanding different groups of users in-app purchase behavior is the key to devising strategies to encourage them to spend.

Start by identifying groups of users by how they spend and much they are likely to spend. It may be by age group, the channel that brought the install, or in-app behaviour. Use the Segment builder in Google Analytics to identify and define these groups of users. Then, tailor in-app purchase offers to match the segments spending behavior. For example, for segments where multiple users tend to spend more in one go, but spend infrequently, offer them in-app features bundled together.

4. Offer in-app purchases when users are most likely to spend

Users are also more likely to spend, if the purchasing experience is frictionless, and even more so when they can see how the expenditure will add value. So:

  • Present purchase opportunities to users when they’re most likely to need or want it — and explain to the user why it’s relevant.
  • Make purchasing accessible easily from within the app with a minimum number of taps. For example, offer an upgrade button on the footer of relevant screens.

TomTom added a countdown to indicate when the free service runs out (counted in kilometers travelled). The counter includes a button to upgrade offering a one tap in-app purchase.

Like all good game developers, they focus on building good experiences that retain and engage users through constant testing and analytics. First impressions are important, so users need to be able to quickly understand the importance of the app and easily navigate through the onboarding experience. And to start generating revenue, it is important to be thoughtful about how to make in-app purchases actionable.

Watch Matteo’s Playtime 2015 session ‘The rules of games, for apps’ to hear more in-depth insights which app developers can learn from games with best practices and developer examples:

You can also watch the other sessions from Google Playtime 2015 to learn more about tools and best practices which can help you find success with business on Google Play.

Categories: Programming

Game developers, get ready for our Developer Day at GDC 2016

Android Developers Blog - Mon, 05/02/2016 - 18:14

Posted by Morgan Dollard, Product Manager of Google Play Games

Next week, we’ll be in San Francisco to host our annual Developer Day at the Game Developers Conference (GDC). Join us to get a first look at our latest efforts to help developers of all sizes build successful mobile games businesses with powerful tools to develop high quality apps, grow a valuable user base, and earn more revenue.

Our Developer Day will take place in room 2020 of the West Hall of Moscone Center on Monday, March 14. Based on your feedback from last year, we're going to keep presentations short and informative with lightning talks around virtual reality, the cloud, ads, and so much more, while dedicating more time to interactive discussions with Google engineers and your peers in the industry.

Here’s a glimpse of the agenda on Monday, March 14:

Opening keynote || 10AM: Be the first to see what’s new and hear about the investments Google is making to help mobile developers grow their game business.

Best practices for success on Google Play || 10:30AM: In this talk, you’ll learn how successful mobile game developers acquire users and bring them back to keep them playing longer.

Lightning talks || 11:15AM: A series of 5-minute talks on innovative technologies to tantalize players, like Project Tango, software to speed and simplify game development, and new ways to predict and prevent user churn.

Interactive roundtables || 2:00PM: After lunch, we’ll break up into interactive roundtables to interact with Google experts and peers on how to build better and more successful games. Ask questions, tell Google product teams what you need, and learn from fellow game developers.

Visit the agenda page to get a full list of our talks and speaker details. Please note that these events are part of the official Game Developer's Conference, so you will need a pass to attend.

For everyone who can’t make it in person, we’ll be live streaming our event on YouTube. Tune in from 10am on Monday, March 18.

Categories: Programming