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/' 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.

Why Engage An External Coach?

IMG_1674

Why would a team and/or organization want an external coach? In previous entries we have discussed the attributes of a good coach  and what a coach delivers, all of which may have whetted your whistle. However, it doesn’t answer the question why you would seek out an external coach. An external coach brings new ideas to the table, different perspectives and a shot of energy.

Software development in general, and Agile specifically, is evolving a rapid pace. New techniques and concepts are developed, vetted and deployed across the globe. Some of those ideas may work for your organization, but if you don’t know they exist, you can’t try them. External coaches, the honey bees of Agile, are a conduit for new ideas to be introduced into a team or organization. I am using the metaphor of a bumblebee to reelect the itinerant nature of coaches  (Coaching techniques used: training and mentoring).

Teams and projects get stuck. Enter the external coach, who can provide a different perspective and to help define a path forward. Often the ability to see a problem or situation with a fresh set of eyes is all that is needed to identify new options or solutions. (Coaching techniques used: cajoling, arbitrating and mentoring).

After teams or organizations implement Agile (or any major development framework), and have begun to accrue the benefits of the implementation, it is easy to relax and get complacent. Complacency is dangerous. An external coach can provide a fresh shot of energy that can keep the transformation moving. (Coaching techniques used: consulting and mentoring.)

Why would you invest in an external coach? External coaches bring new ideas, perspectives and energy into the mix to keep teams and organizations moving forward. As soon as you stop moving forward entropy will set in, and effectiveness and efficiency will suffer.


Categories: Process Management

Hardening the media stack

Android Developers Blog - Thu, 05/05/2016 - 21:44

Posted by Dan Austin and Jeff Vander Stoep, Android Security team

To help make Android more secure, we encourage and reward researchers who discover vulnerabilities. In 2015, a series of bugs in mediaserver’s libstagefright were disclosed to Google. We released updates for these issues with our August and September 2015 security bulletins.

In addition to addressing issues on a monthly basis, we’ve also been working on new security features designed to enhance the existing security model and provide additional defense in-depth. These defense measures attempt to achieve two goals:

  • Prevention: Stop bugs from becoming vulnerabilities
  • Containment: Protect the system by de-privileging and isolating components that handle untrusted content

Prevention

Most of the vulnerabilities found in libstagefright were heap overflows resulting from unsigned integer overflows. A number of integer overflows in libstagefright allowed an attacker to allocate a buffer with less space than necessary for the incoming data, resulting in a buffer overflow in the heap.

The result of an unsigned integer overflow is well defined, but the ensuing behavior could be unexpected or unsafe. In contrast, signed integer overflows are considered undefined behavior in C/C++, which means the result of an overflow is not guaranteed, and the compiler author may choose the resulting behavior—typically what is fastest or simplest. We have added compiler changes that are designed to provide safer defaults for both signed and unsigned integer overflows.

The UndefinedBehaviorSanitizer (UBSan) is part of the LLVM/Clang compiler toolchain that detects undefined or unintended behavior. UBSan can check for multiple types of undefined and unsafe behavior, including signed and unsigned integer overflow. These checks add code to the resulting executable, testing for integer overflow conditions during runtime. For example, figure 1 shows source code for the parseChunk function in the MPEG4Extractor component of libstagefright after the original researcher-supplied patch was applied. The modification, which is contained in the black box below, appears to prevent integer overflows from occurring. Unfortunately, while SIZE_MAX and size are 32-bit values, chunk_size is a 64-bit value, resulting in an incomplete check and the potential for integer overflow. In the line within the red box, the addition of size and chunk_size may result in an integer overflow and creation of buffer smaller than size elements. The subsequent memcpy could then lead to exploitable memory corruption, as size + chunk_size could be less than size, which is highlighted in the blue box. The mechanics of a potential exploit vector for this vulnerability are explained in more detail by Project Zero.

Figure 1. Source code demonstrating a subtle unsigned integer overflow.

Figure 2 compares assembly generated from the code segment above with a second version compiled with integer sanitization enabled. The add operation that results in the integer overflow is contained in the red box.

In the unsanitized version, size (r6) and chunk_size (r7) are added together, potentially resulting in r0 overflowing and being less than size. Then, buffer is allocated with the size specified in r0, and size bytes are copied to it. If r0 is less than r6, this results in memory corruption.

In the sanitized version, size (r7) and chunk_size (r5) are added together with the result stored in r0. Later, r0 is checked against r7, if r0 is less than r7, as indicated by the CC condition code, r3 is set to 1. If r3 is 1, and the carry bit was set, then an integer overflow occurred, and an abort is triggered, preventing memory corruption.

Note that the incomplete check provided in the patch was not included in figure 2. The overflow occurs in the buffer allocation’s add operation. This addition triggers an integer sanitization check, which turns this exploitable flaw into a harmless abort.

Figure 2. Comparing unsanitized and sanitized compiler output.

While the integer sanitizers were originally intended as code hygiene tools, they effectively prevent the majority of reported libstagefright vulnerabilities. Turning on the integer overflow checks was just the first step. Preventing the runtime abort by finding and fixing integer overflows, most of which are not exploitable, represented a large effort by Android's media team. Most of the discovered overflows were fixed and those that remain (mostly for performance reasons) were verified and marked as safe to prevent the runtime abort.

In Android N, signed and unsigned integer overflow detection is enabled on the entire media stack, including libstagefright. This makes it harder to exploit integer overflows, and also helps to prevent future additions to Android from introducing new integer overflow bugs.

Containment

For Android M and earlier, the mediaserver process in Android was responsible for most media-related tasks. This meant that it required access to all permissions needed by those responsibilities and, although mediaserver ran in its own sandbox, it still had access to a lot of resources and capabilities. This is why the libstagefright bugs from 2015 were significant—mediaserver could access several important resources on an Android device including camera, microphone, graphics, phone, Bluetooth, and internet.

A root cause analysis showed that the libstagefright bugs primarily occurred in code responsible for parsing file formats and media codecs. This is not surprising—parsing complex file formats and codecs while trying to optimize for speed is hard, and the large number of edge cases makes such code susceptible to both accidental and malicious malformed inputs.

However, media parsers do not require access to most of the privileged permissions held by mediaserver. Because of this, the media team re-architected mediaserver in Android N to better adhere to the principle of least privilege. Figure 3 illustrates how the monolithic mediaserver and its permissions have been divided, using the following heuristics:

  • parsing code moved into unprivileged sandboxes that have few or no permissions
  • components that require sensitive permissions moved into separate sandboxes that only grant access to the specific resources the component needs. For example, only the cameraserver may access the camera, only the audioserver may access Bluetooth, and only the drmserver may access DRM resources.

Figure 3. How mediaserver and its permissions have been divided in Android N.

Comparing the potential impact of the libstagefright bugs on Android N and older versions demonstrates the value of this strategy. Gaining code execution in libstagefright previously granted access to all the permissions and resources available to the monolithic mediaserver process including graphics driver, camera driver, or sockets, which present a rich kernel attack surface.

In Android N, libstagefright runs within the mediacodec sandbox with access to very few permissions. Access to camera, microphone, photos, phone, Bluetooth, and internet as well as dynamic code loading are disallowed by SELinux. Interaction with the kernel is further restricted by seccomp. This means that compromising libstagefright would grant the attacker access to significantly fewer permissions and also mitigates privilege escalation by reducing the attack surface exposed by the kernel.

Conclusion

The media hardening project is an ongoing effort focused on moving functionality into less privileged sandboxes and further reducing the permissions granted to those sandboxes. While the techniques discussed here were applied to the Android media framework, they are suitable across the Android codebase. These hardening techniques—and others—are being actively applied to additional components within Android. As always, we appreciate feedback on our work and welcome suggestions for how we can improve Android. Contact us at security@android.com.

Categories: Programming

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 - Wed, 05/04/2016 - 17:34
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 - Wed, 05/04/2016 - 17:34
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 - Wed, 05/04/2016 - 15:32
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 - Wed, 05/04/2016 - 15:32
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 - Wed, 05/04/2016 - 15:27
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 - Wed, 05/04/2016 - 15:27
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 - Wed, 05/04/2016 - 14:03

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/