I gave a talk at Devs in the ‘Ditch last week when I was in London. I posted the slides on slideshare: Overcoming Three Pitfalls of Transitioning to Agile.

The very nice people at 7digital made a video and posted it, too. If you can take the time, watch the entire video. Rob Bowyer gave a great talk about kanban and theory of constraints. My part about overcoming these three pitfalls starts at about 42 minutes in.

There are many other pitfalls to transition. This talk had just three of them: the stories are too big, you need experts to do the work, and you implement as layers instead of through the architecture.

I hope you enjoy the presentation and the video.

 

Coach or Manager?

Are you a coach or a manager? Most traditional hierarchical IT organizations use managers to plan, organize and control work. Managers make the decisions that matter with greater or lesser collaboration, based on their management style. A coach is a different thing entirely. Coaches exist to assist a team to reach its full potential. In the world of empowered employees and self-managed teams, a coach is an enabler, a guide and a leader.

A coach enables her team by suggesting areas for self-improvement, ideas for using tools and techniques and facilities improving team. The goal of coaching is to help the team become more effective in delivering value to the organization. The act of coaching requires the ability to interact and facilitate both how individuals and groups work within the team.

When a coach provides guidance, they are using their gravitas to influence the direction of the team. In organizations that rely on control environments the manager will tell the team the correct direction with the expectation that telling and doing are sequential acts. A coach provides direction and uses her influence to get the team to internalize that direction. The internalized direction may well reflect a synthesis of the team’s knowledge and the coach’s advice.

The ability to enable and guide is a function of being a leader. Kevin Kruse, author of Employee Engagement 2.0, defines leadership as “a process of social influence, which maximizes the efforts of others, towards the achievement of a goal.” The definition does not include the primary tenants of the definition of a manager, control and positional authority, but rather is focused on getting the most from the team as it pursues its goals through influence.

A coach is an enabler, a guide and a leader. All three of these attributes are inter-related and self-reinforcing, but having one or two is not sufficient. A coach rarely needs to leverage the techniques of a manager – planning, organizing and directing rather they rely on influence and team peer pressure. Are you a manager or a coach? The distinction is fairly stark. Is your role to help the team maximize its value through a process of facilitation? If the answer is yes, then you are a coach.

Posted by Mark Thomas, Product Manager, Google Wallet

A key focus of Google Wallet is to simplify commerce for merchants and shoppers; for over a year now, consumers on Google Play have been using Wallet to make their purchases, to the benefit of the entire ecosystem. Helping merchants benefit from the growing consumer adoption of mobile commerce is where we believe we can make the most impact. And that’s why today we're focusing our efforts on the new Google Wallet Merchant Center and retiring Google Checkout over the next six months.

Most Google Play apps developers will seamlessly transition to the Wallet Merchant Center, which provides new reporting and analytics features and much more. A small number of Google Play developers, however, will see some changes:

• Developers using Google Checkout on their website to sell physical goods or services will no longer be able to use Checkout after November 20, 2013. We have provided some discounted migration options to help with this change. If you are a U.S. merchant selling physical goods and services who does have payment processing, you can apply for Google Wallet Instant Buy, which offers a fast buying experience to Google Wallet shoppers.
• Developers who use the Google Checkout for the Notifications and/or Order Reports API(s) will need to migrate to replacement APIs, made available through Google Play, before November 20, 2013. Watch for announcements on the new APIs soon.

If you sell apps or in-app products in Google Play, you’ll soon have access to the new Wallet Merchant Center. Watch for an email notifying you that that it’s now available to you. We expect to transition all merchants to the Wallet Merchant Center over the next several weeks.

We invite you to join us for our live merchant webinar on May 23, 2013 at 10AM PDT to learn more and ask any outstanding questions. As always, feel free to contact us at any time during this transition. Finally, be sure to check out the exciting updates launched last week at Google I/O (including Instant Buy and Wallet Objects) and stay tuned for more great developer features coming soon!

The conversation on Twitter around No Estimates #NoEstimates brings a smile. Here's some samples

• Marketing needs a rough idea of when alpha-level code will be available. Allowing a few weeks for alpha testing and a few more for beta testing provides a time line. That may well be good enough. 

That's called an estimate. A rough estimate for sure, but it's an estimate

From the same blog (a good one BTW)...

• We're on an enterprise system now and management needs to know how long and how much cost it will take to get to a Minimal Viable Product. The first release has to be functionally complete in order to be competitive. Everyone understands that this effort will take several months to get to beta-level code.  Management needs some idea of what they’re getting into, how long it will take, and how much it will cost.

Now we're into the realm of actual estimating

Are No Estimates Better Than Estimates?

Before answering this another question needs to be answered...

What is the value at risk?

This means how much money and time are you willing to risk without understanding how much time and money is at risk.

So before anyone can answer the question about estimating value, that question needs to be answered by the owner of the money. NOT to consumer of the money. 

This at risk question rarely comes up in the agile world. It doesn't come up enough in our formal FAR/DFARS acquisition work either. The at risk question is a risk management question. Agile claims to be a risk management process - which of course is laughable in our DOD/NASA/NRC/FDA/NNSA risk management world. All software intensive by the way.

So before venturing further, what's the value at risk must be answered. Then the owner of that risk, can tell those who should be working in the best interest of the owner of the risk, if an estimate is needed. Not the other way aorund.

Without this answer, the discussion on #NoEstimate is just sharing of personal opinions in the absence of any value at risk.

Related articles Time to Revisit The Risk Discussion When We Say Risk What Do We Really Mean? More Uncertainty and Risk Measurement of Uncertainty Estimates in Software Development. New Frontiers. Risk Management

It's being reported Yahoo bought Tumblr for $1.1 billion. You may recall Instagram was profiled on HighScalability and they were also bought by Facebook for a ton of money. A coincidence? You be the judge.

Just what is Yahoo buying? The business acumen of the deal is not something I can judge, but if you are doing due diligence on the technology then Tumblr would probably get a big thumbs up. To see why, please keep on reading...

Posted by Xavier Ducrohet, Tor Norbye, Katherine Chou

Today at Google I/O we announced a new IDE that’s built with the needs of Android developers in mind. It’s called Android Studio, it’s free, and it’s available now for you to try as an early access preview.

To develop Android Studio, we cooperated with JetBrains, creators of one of the most advanced Java IDEs available today. Based on the powerful, extensible IntelliJ IDEA Community Edition, we've added features that are designed specifically for Android development, that simplify and optimize your daily workflow.

Extensible build tools

We know you need a build system that adapts to your project requirements but extends further to your larger development environment. Android Studio uses a new build system based on Gradle that provides flexibility, customized build flavors, dependency resolution, and much more.

This new build system allows you to build your projects in the IDE as well as on your continuous integrations servers. The combination lets you easily manage complex build configurations natively, throughout your workflow, across all of your tools. Check out the preview documentation to get a better idea of what the new build system can do.

Powerful code editing

Android Studio includes a powerful code editor. It's based on the IntelliJ IDEA editor, which supports features such as smart editing, advanced code refactoring, and deep static code analysis.

Smart editing features such as inline resource lookups make it easier to read your code, while giving you instant access to edit code the backing resources. Advanced code refactoring gives you the power to transform your code across the scope of the entire project, quickly and safely.

We added static code analysis for Android development, helping you identify bugs more quickly. On top of the hundreds of code inspections that IntelliJ IDEA provides, we’ve added custom inspections. For example, we’ve added metadata to the Android APIs, that flag which methods can return null and which can’t, which constants are allowed for which methods, and so on. Android Studio uses that data to analyze your code and find potential errors.

Smoother and richer GUI

Over the past year we’ve added some great drag-and-drop UI features to ADT and we’re in the process of adding them all into Android Studio. This release of Android Studio lets you preview your layouts on different device form factors, locales, and platform versions.

Easy access to Google services
within Android Tools

We wanted to make it easy for you to harness the power Google services right from your IDE. To start, we’ve made it trivial to add services such a cloud-based backend with integrated Google Cloud Messaging (GCM) to your app, directly from the IDE.

We’ve also added a new plugin called ADT Translation Manager Plugin to assist with localizing your apps. You can use the plugin to export your strings to the Google Play Developer Console for translation, then download and import your translations back into your project.

Open source development

Starting next week we’ll be doing all of our development in the open, so you can follow along or make your own contributions. You can find the Android Studio project in AOSP at https://android.googlesource.com/platform/tools/adt/idea/

Try Android Studio and give us feedback

Give Android Studio a try and send us your feedback! It's free, and the download bundle includes includes everything you need, including the IDE, the latest SDK tools, the latest Android platform, and more. .

Note: This is an early access preview intended for early adopters and testers who want to influence the direction of the Android tools. If you have a production app with a large installed base, there’s no need to migrate your development to the new tools at this time. We will continue to support Eclipse as a primary platform for development.

If you have feedback on the tools, you can send it to us using the Android Studio issue tracker.

Join the discussion on

+Android Developers

As many of you know, I jog.  It is a hobby with side benefits.  Four times as year I run in a race.  This morning I ran a 10k along with several thousand other runners (20,000 in total between the 10k and marathon events). The moments just before the race start is always emotional for me as I mentally prepare around all that pent-up energy. Starting a new, cool project has a similar emotional profile.  Project teams begin with the excitement of pent-up energy and the possibilities of a yet unrealized common goal.

In a race hundreds or thousands of people press toward the starting line; the press becomes greater as the time for starting gun gets closer.  Everyone is ready to go.  Project teams feel the same way.  Retrospectives from previous projects are completed, desks cleaned off and the team and the individuals that make up the team begin to build up restless energy that will be challenged into the next project.

At the starting line of a race everyone knows that the ultimate goal is to get to the finish line.  The possibilities of the run are as limitless as the runner’s imagination.  As a new project closes in on the starting line it is very much an unbounded set of possibilities. While we might have an understanding of where the finish line is, we know that the journey will be filled with learning and adventures.

As we wait at the starting line there have been no late nights, no failed tests and no arguments about design decisions, only possibilities of delivering value.  We might not run a four-minute mile, but we will learn something new about our self and our team.  Several years ago, at the starting gun I went out much faster than I normally run and suffered for the rest of the race. When your next project is green-lighted, use the excitement and energy that new possibilities bring, but remember to pace yourself.

As I mentioned in my previous blog post I’ve been hacking on a product taxonomy and I wanted to create a ‘CHILD’ relationship between a collection of categories.

For example, I had the following array and I wanted to transform it into an array of ‘SubCategory, Category’ pairs:

taxonomy = ["Cat", "SubCat", "SubSubCat"]
# I wanted this to become [("Cat", "SubCat"), ("SubCat", "SubSubCat")

In order to do this we need to zip the first 2 items with the last which I found reasonably easy to do using Python:

>>> zip(taxonomy[:-1], taxonomy[1:])
[('Cat', 'SubCat'), ('SubCat', 'SubSubCat')]

Here we using the python array slicing notation to get all but the last item of ‘taxonomy’ and then all but the first item of ‘taxonomy’ and zip them together.

I wanted to achieve that effect in Ruby though because my import job was written in that!

We can’t achieve the open ended slicing as far as I can tell so the following gives us an error:

> taxonomy[..-1]
SyntaxError: (irb):10: syntax error, unexpected tDOT2, expecting ']'
taxonomy[..-1]
           ^
	from /Users/markhneedham/.rbenv/versions/1.9.3-p327/bin/irb:12:in `<main>'

The way negative indexing works is a bit different so to remove the last item of the array we use ‘-2′ rather than ‘-1′:

> taxonomy[0..-2].zip(taxonomy[1..-1])
=> [["Cat", "SubCat"], ["SubCat", "SubSubCat"]]

I’ve been playing around with modelling a product taxonomy and one thing that I wanted to do was find out the full path where a product sits under the tree.

I created a simple data set to show the problem:

CREATE (cat { name: "Cat" })
CREATE (subcat1 { name: "SubCat1" })
CREATE (subcat2 { name: "SubCat2" })
CREATE (subsubcat1 { name: "SubSubCat1" })
CREATE (product1 { name: "Product1" })
CREATE (cat)-[:CHILD]-subcat1-[:CHILD]-subsubcat1
CREATE (product1)-[:HAS_CATEGORY]-(subsubcat1)

I wanted to write a query which would return ‘product1′ and the tree ‘Cat -> SubCat1 -> SubSubCat1′ and initially wrote the following query:

START product=node:node_auto_index(name="Product1") 
MATCH product-[:HAS_CATEGORY]-category, taxonomy=category<-[:CHILD*1..]-parent 
RETURN product, EXTRACT(n IN NODES(taxonomy): n.name)

which returns:

==> +--------------------------------------------------------------------+
==> | product                    | EXTRACT(n IN NODES(taxonomy): n.name) |
==> +--------------------------------------------------------------------+
==> | Node[888]{name:"Product1"} | ["SubSubCat1","SubCat1"]              |
==> | Node[888]{name:"Product1"} | ["SubSubCat1","SubCat1","Cat"]        |
==> +--------------------------------------------------------------------+
==> 2 rows

I didn’t want to return the first row since that isn’t the full tree and Andres suggested that looking for nodes which didn’t have any incoming children would help me do that:

START product=node:node_auto_index(name="Product1") 
MATCH product-[:HAS_CATEGORY]-category, 
      taxonomy=category<-[:CHILD*1..]-parent 
WHERE NOT parent<-[:CHILD]-() 
RETURN product, EXTRACT(n IN NODES(taxonomy): n.name)

==> +--------------------------------------------------------------------+
==> | product                    | EXTRACT(n IN NODES(taxonomy): n.name) |
==> +--------------------------------------------------------------------+
==> | Node[888]{name:"Product1"} | ["SubSubCat1","SubCat1","Cat"]        |
==> +--------------------------------------------------------------------+
==> 1 row

If we want to reverse the taxonomy so it’s in the right order we can follow Wes Freeman’s advice from the following Stack Overflow thread:

START product=node:node_auto_index(name="Product1") 
MATCH product-[:HAS_CATEGORY]-category, taxonomy=category<-[:CHILD*1..]-parent 
WHERE NOT parent<-[:CHILD]-() 
RETURN product, 
       REDUCE(acc=[], cat IN EXTRACT(n IN NODES(taxonomy): n.name): cat + acc) AS taxonomy

==> +-------------------------------------------------------------+
==> | product                    | taxonomy                       |
==> +-------------------------------------------------------------+
==> | Node[888]{name:"Product1"} | ["Cat","SubCat1","SubSubCat1"] |
==> +-------------------------------------------------------------+
==> 1 row

Chris and I were looking at the neo4j log files of a client earlier in the week and wanted to do some processing of the file so we could ask the client to send us some further information.

The log file was over 10,000 lines long but the bit of the file we were interesting in was only a few hundred lines.

I usually use Vim and the ‘:set number’ when I want to refer to line numbers in a file but Chris showed me that we can achieve the same thing with e.g. ‘less -N data/log/neo4j.0.0.log’.

We can then operate on say lines 10-100 by passing the ‘-n’ flag to sed:

-n By default, each line of input is echoed to the standard output after all of the commands have been applied to it. The -n option suppresses this behavior.

$ sed -n '10,15p' data/log/neo4j.0.0.log
INFO: Enabling HTTPS on port [7473]
May 19, 2013 11:11:52 AM org.neo4j.server.logging.Logger log
INFO: No SSL certificate found, generating a self-signed certificate..
May 19, 2013 11:11:53 AM org.neo4j.server.logging.Logger log
INFO: Mounted discovery module at [/]
May 19, 2013 11:11:53 AM org.neo4j.server.logging.Logger log

We then used a combination of grep, awk and sort to work out which log files we needed.

Welcome to the Software Process and Measurement Cast 238   

The Software Process and Measurement Cast features my interview with Bram Meyerson.  We discussed benchmarking.  Benchmarking is the process of knowing yourself and it is the first step in process improvement. 

Bram Meyerson is the founder and CEO of QuantiMetrics and QVIP. He holds a double major BSc degree in Applied Mathematics and Computer Science and an Honours degree in Computer Science, both from the University of the Witwatersrand.

For the last 20 years, Bram has managed and delivered a range of assessment and benchmarking services. In this role, Bram has worked closely with CIOs, IS directors and systems development managers in assessing, benchmarking and optimising their project performance. Currently much of this activity involves the ongoing independent assessment and benchmarking of supplier (outsourced) performance on behalf of IT user organisations.  

Email: bram@quantimetrics.net
Website: http://www.quantimetrics.net/default.asp 

Do you have a Facebook account?  If you do please visit and like the Software Process and Measurement Cast page on Facebook. http://bit.ly/16fBWV

The Daily Process Thoughts is my project designed to deliver a quick daily idea, thought or simple smile to help you become a better change agent. Each day you will get piece of thought provoking text and a picture or hand drawn chart to illustrate the idea being presented. The goal is to deliver every day; rain or shine, in sickness or in health or for better or worse! Check it out at www.tcagley.wordpress.com. 

Shameless Ad for my book! 

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: "This book will prove that software projects should not be a tedious process, neither for you or your team."

NOW AVAILABLE IN CHINESE! 

Have you bought your copy?

Contact information for the Software Process and Measurement Cast

Email:  spamcastinfo@gmail.com
Voicemail:  +1-206-888-6111
Website: www.spamcast.net
Twitter: www.twitter.com/tcagley
Facebook:  http://bit.ly/16fBWV

One more thing!  Help support the SPaMCAST by reviewing and rating the Software Process and Measurement Cast on ITunes!  It helps people find the cast. 

THe Software Process and Measurement Cast is a proud member of the Tech Podcast Network.  Listen to the SPaMCAST and othe great podcasts, like Day In Tech History a podcast on tech hitory 365 days a year at http://www.techpodcasts.com/

Next:

The Software Process and Measurement Cast 239 will feature my essay on commitment. Committed individuals are the building blocks for building committed teams.  While teams are generally required for achieving results in software development, individuals are never optional.

Daniel Cook has a great PDF on the 8 Laws of Productivity.  The subtitle is “8 Productivity Experiments You Don’t Need to Repeat.”

It’s the synthesis of Dan’s learnings and research over the years on how to create more productive teams.

Right up front, Dan defines productivity as work accomplished, minus work required to fix defects, and minus work required to fix bad design decisions.   He adds that it’s possible for productivity to be negative when workers end up doing more harm than good.  Dan says, “People commonly measure ‘what was accomplished’, but often this is a poor measure of productivity. It is possible to check in code and design decisions that must be later fixed or removed at great cost. If you only measure work accomplished, you could generate great ‘productivity’ numbers but never ship a working product. The real measure of productivity is valued working code in customer hands.”

Here are the 8 Laws of Productivity according to Cook:

1. Law #1 - Working more than 40 hours a week leads to decreased productivity
2. Law #2 - There is Always a Cost to Crunch
3. Law #3 -- Repeat experiments on knowledge workers, not factory workers
4. Law #4 -- Teams on overtime feel like they are doing more, but actually accomplish less
5. Law #5 -- Productivity is maximized in small teams of 4-8 people
6. Law #6 -- Seat People on the Same Team Together in a Closed Team Room
7. Law #7 -- Cross-Functional Teams outperform siloed teams
8. Law #8 -- Scheduling at 80% produces better products

 

Law #1 - Working more than 40 hours a week leads to decreased productivity

What happens if you try to improve productivity by working longer, either through more hours in a week, or more hours in a day?

 

 

Cook summarizes the results:
<40 hours and people aren't working enough
> 60 hour work week gives a small productivity boost
The boost lasts 3 to 4 weeks and then turns negative

Cook tells us that according to Ford, and 12 years of experimentation, 40 hours was the most effective.  

Interestingly, an early XP practice was 40 Hour Week, before it became Sustainable Pace.  The main idea is that "productivity does not increase with hours worked."

A key point here is that "After a certain tipping point, teams tend to be more destructive than productive." (see InfoQ on Sustainable Pace)

I've experience the benefits of a 40 hour work week and wrote about it in 40 Hour Work Week at Microsoft.

An interesting data point is that 6 of the top 10 competitive economies prohibit employees from working over 48 hours/week.  (See MBA on Bring Back the 40 Hour Work Week.)

 

Law #2 - There is Always a Cost to Crunch

What happens if we work harder in bursts?  Can we take advantage of the burst that comes from working overtime?  What happens if we crunch for a week and then 'only' 40 hours for another week?  Are there other patterns of scheduling work that might be more efficient?

 

Cook summarizes the results:

Anything over 40 hours results in a recovery period, no matter how you split it up.
35 to 40 hour weeks can be divided in a variety of ways, such as four 10-hour days on and three days off.
These 'compressed work weeks' can reduce absenteeism and, in some cases, increase productivity 10 to 70% Law #3 -- Repeat experiments on knowledge workers, not factory workers

Do the same rules apply to creativity and problem-solving as manual labor?

Cook summarizes the results:
Studies show that creativity and problem solving decreases faster with fatigue than manual labor.
Grinding out problems by working longer on average result in inferior solutions.
Lack of sleep is particularly damaging.

Law #4 -- Teams on overtime feel like they are doing more, but actually accomplish less

If many workers self-report that they are the exception to the rule and can work longer with no ill effects, and overtime workers report they are getting more done, is this true?

Cook summarizes the results of measurements where Team A works overtime and Team B does not:
Team A feels like they are doing much more than Team B.
Yet, Team B produces the better product.

Law #5 -- Productivity is maximized in small teams of 4-8 people

Does productivity change for various team sizes and which size team produces the best product?

Cook summarizes the results:
Productivity for small groups is shown to be 30-50% higher than groups over 10
Cost of communication increases dramatically for groups larger than 10
Smaller groups don't have enough breadth to solve a wide array of problems well

Interestingly, the Navy Seal create super teams with teams of 4.

Law #6 -- Seat People on the Same Team Together in a Closed Team Room

What is the most productive physical work environment?  Are cubes, individual offices or team rooms most effective?  Every individual has an opinion, but what is best for the team?

Cook summarizes the results:
Studies show 100% increase in productivity
Being nearby means faster communication and problem-solving
Few external interruptions to the team (not the individual) means higher productivity

Law #7 -- Cross-Functional Teams outperform siloed teams

How should workers of different disciplines be organized?  Should teams be composed of a single discipline? For example, all programmers or all artists?  Or should teams be mixed?

Cook summarizes the results:
Cross-functional teams produced more effective solutions in the same time
Cross-functional teams have more likelihood of generating breakthrough solutions
There is some negotiation of norms of front, but this is a short-term loss

Law #8 -- Scheduling at 80% produces better products

What percentage of team capacity should be officially scheduled?  110% to promote people to 'stretch'?  100% because that's what they can do? 80% because slacking is good?

Cook summarizes the results:
Scheduling people at 100% doesn't give space to think of creative solutions
Not lost time: Passionate workers keep thinking
The 20% goes into new idea generation and process improvements
Producing 20 great features is usually far more profitable than producing 100 competent features

Dan included some of his research sources:

Crunch in the Game Industry
IGDA - Articles - Why Crunch Mode Doesn't Work: 6 Lessons - http://www.igda.org/articles/erobinson_crunch.php
InfoQ - Why Crunch Mode Doesn't Work, by Ben Hughes - http://www.infoq.com/news/2008/01/crunch-mode

Best Team Size
Is Your Team Too Big? Too Small? What's the Right Number? - http://knowledge.wharton.upenn.edu/articles.cfm?articleid=1501
Team Performance and Team Size - http://www.teambuildingportal.com/articles/systems-approaches/teamperformance-teamsize.php

Sickness and Overtime Correlation
Relationship between self-reported low productivity and overtime working - http://cat.inist.fr/?aModele=afficheN&cpsidt=15461524

Prioritization
First Things First (book) - http:///en.wikipedia.org/wiki/First_Things_First_(book)

4 Day Work Week
Alternative Work Schedules and Work–Family Balance: A Research Note - http://rop.sagepub.com/cgi/reprint/28/2/166

Team Spaces
"Rapid Software Development Through Team Collocation" IEEE Transactions on Software Engineering, Volume 28, No. 7, July 2002

Additional Resources

INFOQ: Does Sustainable Pace Mean a 40 Hour Work Week?

MBA on Bring Back the 40 Hour Work Week (Info Graphic)

40 Hour Week (C2 Wiki)

You Might Also Like

10 Big Ideas from Getting Results the Agile Way

40 Hour Work Week at Microsoft

How I Use Agile Results

If you are using ASP.NET, especially if you are using ASP.NET MVC, you need to be using Glimpse.

I’m currently working on a more exhaustive Pluralsight course on Glimpse, but I thought I’d write up a quick getting started tutorial here.

What is Glimpse?

Perhaps you haven’t heard of Glimpse yet, or you are just a little unsure of exactly what it is.

Glimpse is basically an open source and free diagnostics platform for the web.  Right now it works best with ASP.NET and especially ASP.NET MVC, but it can be extended to other platforms as well.  There is already work started for a PHP version and even a Python port.

What Glimpse essentially does is let you see diagnostics information about what is happening on your server directly in your page through a small diagnostics window completely rendered in JavaScript.

Out of the box, Glimpse can show you all kinds of information about your MVC application, like what routes are registered, what the flow was through the MVC pipeline and how the models were bound.

(BTW, if you are looking to brush up on your ASP.NET MVC 4 skills or learn about ASP.NET MVC 4, I recommend Professional ASP.NET MVC 4.  Great book, top notch authors.)

Here is what the Glimpse window looks like on a page.

Glimpse is also fully extendable.

There are already plugins for Entity Framework, NHibernate, Ninject and many, many more

The best part about Glimpse is how easy it is to get setup.

I’ll walk you through the steps below.

Step 1: Get Glimpse from NuGet

All you have to do to get Glimpse installed is simply either:

• Open up the Package Manager Console and type “Install-Package Glimpse.Mvc4” (or “Glimpse.AspNet” if you aren’t using MVC)
• Or, right click on your references, select Manage NuGet Packages, then search for Glimpse and find the appropriate Glimpse package.

One you’ve done that, Glimpse will automatically add a few entries to your web.config for you.

Step 2: Turn on Glimpse

Turning on Glimpse is super easy.

Just launch your app and navigate to glimpse.axd.  Then, click “Turn Glimpse On” to set a cookie that will tell the Glimpse component running on the server to send you Glimpse data.

Go to glimpse.axd

Turn it on!

It’s that simple!

Step 3: Fire it up

Now all you have to do is navigate to any page in your application and you’ll see this little icon at the bottom right hand corner of the screen:

If you click the icon, you’ll see the Glimpse panel, which currently looks similar to the Chrome Dev Tools panel.

Using Glimpse

Each tab contains different diagnostics information about your application.

This data can be extremely helpful in troubleshooting problems and learning about exactly what is going on inside of MVC.

You can also find plugins that can be easily installed from NuGet.

For example, if you add the Entity Framework plugin, you’ll start seeing a tab that shows data about EF queries, like this:

I’m pretty excited about Glimpse and its future.  Anthony van der Hoorn and Nik Molnar, the two creators and main maintainers for Glimpse, have done an excellent job transforming how we get diagnostics information for web applications.

One of the things I find most exciting about this platform is how easy it is to extend.  In my upcoming Pluralsight course, I walk you through creating a Glimpse plugin, which is surprisingly easy.

So if you haven’t checked out Glimpse, what are you waiting for?  Go do it now, it will take you about 5 minutes to get setup.

What do you think?  Are you using Glimpse already?  Post a comment and let me know.

My YouTube video for the week:

Dealing With Burnout

 

And here is the weekly Get Up and Code episode:

Get Up and CODE, Episode 2: Fitnesse And Nutrition Tips For a Busy Schedule
jQuery(document).ready(function($) { $('#wp_mep_1').mediaelementplayer({ m:1 ,features: ['playpause','current','progress','duration','volume','tracks','fullscreen'] ,audioWidth:400,audioHeight:30 }); });

Follow @jsonmez !function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0],p=/^http:/.test(d.location)?'http':'https';if(!d.getElementById(id)){js=d.createElement(s);js.id=id;js.src=p+'://platform.twitter.com/widgets.js';fjs.parentNode.insertBefore(js,fjs);}}(document, 'script', 'twitter-wjs');

The post Getting Started With Glimpse In ASP.NET MVC appeared first on Making the Complex Simple.

Any activity can be turned into a game, if it meets the right criteria.  Wise words from Dan Cook:

     “If an activity can be learned…

     If the player’s performance can be measured…

     If the player can be rewarded or punished in a timely fashion…

     Then any activity that meets these criteria can be turned into a game.”

Gamification is hot.  I called it out in my Trends for 2013 roundup.   When all things are equal, fun is a differentiating factor.

You Might Also Like

Microsoft Secret Stuff

The Gamification of Education

Wearable Computing

Hand Drawn Chart Saturday

Great projects are generally the end result of three types of commitment from three basic sets of actors: individual team members, teams and projects. This cycle of commitment is strongest in great organizations, which is why some organizations are better at delivering projects on-time, high satisfaction projects. However, this cycle can exist in weaker organizations.

The cycle, illustrated above, follows the pattern that team members commit to the team, the team commits to the project and the project influences the commitment of the person. A committed team is defined as a group of individuals that have developed relationships based around a commitment to attain a set of common goals (See Daily Process Thoughts: Environment for Commitment, May, 16, 2013 for further discussion on this point). The strength of the bonds generated by the commitments between the team, people and the project is influenced by the relative importance of the goal that the project supports. Projects that support strategic goals tend to attract the strongest commitment, which keeps the various actors revolving around each other like a classic model of an atom. Industry data suggest that the strength of commitment is strongly correlated to perceived level of value of the project[1][2].

A weak or broken link in the commitment cycle will reduce Hthe likelihood of a project achieving its maximum value or customer satisfaction. Commitment helps the team and individual focus on producing quality work. “The Hewitt Associates research finds that double-digit growth companies have 39% more highly committed employees and 45% fewer highly disengaged employees than single-digit growth companies.”[3]

The cycle of commitment links projects, teams and individuals. When the goals of the oject don’t build toward the more strategic / organizational goals, commitment will be lower. Commitment, anywhere in the cycle, is a precursor to the ability to deliver projects that are of high value and customer satisfaction.

[1] A Study about Employee Commitment and its impact

on Sustained Productivity in Indian Auto-Component Industry http://www.ejbss.com/Data/Sites/1/septemberissue/ejbss-12-1147-astudyaboutemployeecommitment.pdf

[2] Positive Impact on Employee Commitment and Engagement http://workplaceflexibility.bc.edu/need/need_employers_impact

[3] Employee Engagement Higher at Double-Digit Growth Companies http://www.mckpeople.com.au/SiteMedia/w3svc161/Uploads/Documents/016fc140-895a-41bf-90df-9ddb28f4bdab.pdf

There is a twitter discussion going on around Neil's post of People Need Estimates. This is a typical agile approach. No real domain or context, just a principle looking for a problem to solve. 

First let's establish some ground rules:

• I'm a strong advocate of agile development. I work prorgams that use agile. Big programs. Billion dollar programs. 
• When we are spending other people's money it's not about "us" and our favorite method of spending that money. It's about governance. Don't like governance, then don't work on projects that spend other peoples money.

And the final one ...

• Agile - in many cases - is spending people's money to discover the requirements. That's fine. But acknowledge it. Requirements emerge. Requirements change. Requirement are wrong many times. But don't say it'll be OK to use agile and ignore that you're spending - maybe even wasting - other people's money and calling it progress.

Neil says "People need certainty about what they will get and how much they have to spend. " This is not factually true in many domains, not is it actually possible. Those with the money need to know the confidence in the spend plan and the project duration. Certainty is not possible. But don't use that as an excuse for not having a confidence interval estimate:

• We will complete this project on or before the 3rd week in November, 2014 with an 80% confidence and a 12% error band on that confidence. This is easily developed and is done every month on the programs we work.
• We will complete this project at $1.6M or less with 80% confidence and a 10% error on that confidence.

This is what those spending the money need to know. Otherwise the project is Level of Effort. Work producing good things till the money runs out, get some more money continue doing good things. No problem. That is called maintenance. This is how PayPal uses Scrum. They budget annually for features, develop those features within that budget, repeat forever.

I love the notion "When estimating a date or cost you are creating uncertainty around those things, because you are guessing. "

Well stop guessing. Start being a software professional and start estimating. Have you done this before? How long did it take. Has anyone you know done it before? Go ask them. Guessing is lame. No estimates is even lamer. Worse, it's just being lazy. 

One last thing, "People still need 500-page business requirement documents." This is bogus. We work multi billion programs, with 100's of millions of dollars of embedded sofwtare and don't have 500 page requirements documents. Nonsense. 

If you don't know where you are going, if you don't have some notion of what done looks like, if you can't tell me approximately how much and how long, please don't start. You can be a binary search process for duration and cost for any tangible piece of software and within five question get without 20%. That's good enough to start. So start and take corrective actions with ne estimate along the way.

Finally "However, I would argue that #NoEstimates gives greater certainty than estimating does." There is absolutely no evidence for this. This is pure speculation and therefore also nonsense. Think about it,

• A builder comes to your house for a kitchen remodel.
• You tell him roughly what you want done. 
• You ask "how much will this cost, approximately?"
• "Oh I don't know, we're not good at making estimates, let's just get started and see where this takes us."

Are you out of your !@#$'ing mind. It is no different for software. Here's a nice short intro from Target Process, that actually makes sense.

Let's say the CIO comes and says "I need these features", and asks "how much and how long?" You say "Oh we get better outcomes when we don't estimates." Really, and some one believes that nonsense? I guess so.

Related articles Probabilistic Cost and Schedule Processes Estimates and all that... Cost (and Schedule) Estimating Foundations A Point Measures Need A Variance

I’ve written a couple of posts over the last few months about my experiences with A/B testing and one conversation we often used to have was around user experience vs conversion rate.

Once you start running an A/B test it encourages you to focus more on the conversion rate of users in different parts of the flow and your inclination is to make changes that increase that conversion rate.

Another one of our drivers is to provide the best user experience that we can to our customers and since sometimes this means that the best thing for them is not to switch it seems that these two must be in conflict.

I found it particularly interesting seeing how the conversion rate could be impacted by the way that information was displayed to a user.

This was an idea that I first came across when reading about how the Obama campaign used A/B testing where they noticed big changes in conversion rates by making small tweaks to sentences and imagery.

Our goal from a user experience perspective was to put all the information in front of the user so that they could make an informed choice about what to do.

Initially we made the negative features of the plans very prominent and had them in a large font which led to a drop in conversion.

We assumed that people were now giving more importance to the negative features than was warranted e.g. some plans had a cancellation fee but it typically only accounted for 5% of the saving they’d make by switching to the plan.

When the product is a bit more complicated we could argue that we improve the user experience by helping the user to make an appropriate choice.

On a website the way that we do this is by how we display information by changing the font size, font weight, positioning and a variety of other things.

It’s an interesting balance to find between the two drivers but if we veer towards conversion at all costs then although we’ll get a higher conversion rate in the long term we’ll have some frustrated customers who won’t use our website again.

If we look at it that way then the two drivers don’t seem so opposed to each other.

Posted by Ellie Powers, Google Play team

This week at I/O, we were excited to announce some updates to Google Play to help you optimize your business on Google Play: to help you take control of your app publishing, gain insight into your users, and expand your app’s success globally.

Play Store’s new view: apps designed for tablets

Many of you have invested in making great tablet experiences for your users, and we want to ensure that that work pays off and that users are able to discover great apps for their tablets. This week, the Google Play store began providing a view of our top charts highlighting apps which have been designed for tablets according to our tablet app quality checklist.

Be sure you don’t miss out! Check that your app’s optimization tips say that your app is designed for tablets, and upload tablet screenshots for 7” and 10” tablets.

Beta testing and staged rollouts

We have introduced support for beta testing and staged rollouts so that you can get feedback on your new app or app update early in its development and make sure your users are happy with the results. You can test two different versions on two different groups at the same time, such as testing a newer version with your employees first, and a more mature version with a group of external testers.

The beta testing is private on Google Play, and you can specify who gets these versions by adding Google Groups and Google+ Communities. Users give you feedback privately rather than through public reviews. When you’re satisfied that your new version is ready, you can now do a staged rollout to a percentage of your userbase. To give you more flexibility in light of beta testing and help get your whole team involved in the Developer Console, we will soon launch additional access controls.

Localization improvements

We’re collaborating with Google's internationalization team to make translating your app into new languages easier than ever. You can purchase professional translations of your apps from independent providers through the Google Play Developer Console. You can upload the strings you want translated, select the languages you want to translate into, and select your translation vendor based on time and price. If you’re interested in translating your apps with this feature, sign up to be a part of the preview in the Developer Console today on the APK page.

The new optimization tips for localization will help you identify new potential opportunities for global expansion based on popular languages for your app’s users and category. To fully localize your app into a language, you need to translate the strings in an APK, translate your Google Play store listing, and upload localized graphics. The optimization tips will also let you know if you’re missing any of these pieces.

New Analytics and monetization features

Getting better revenue and engagement data has been another key developer request, as developers told us that they check their revenue and stats constantly. New revenue charts in the Developer Console allow you to see your app’s daily revenue and summary figures, and you can filter the data by country. Coming soon, Google Play and Google Analytics are teaming up to bring you better insight into your users. Google Analytics will start showing Google Play views and installs for each campaign, while Google Play will show Google Analytics engagement metrics.

For those of you using in-app billing, we’ve heard your feedback and made some improvements to reduce your development time and costs. Your test accounts will now able to make in-app test purchases without those transactions actually being charged, but everything else works the same as it would for a real user.

In a few weeks, we will launch a new Order Status API, which allows you to verify the status of an in-app order from your servers. We will also be launching a tool for automating downloads of financial reports. Finally, the new Google Wallet Merchant Center is continuing to roll out with enhanced reporting, additional analytics and many other enhancements.

Google Play for Education coming soon

You'll soon be able to offer apps to schools through Google Play for Education, which launches later this year to K-12 schools in the United States. This online destination will allow schools to discover, purchase, and distribute apps to their students. Visit developer.android.com/edu to get started creating or optimizing your apps for schools today.

Join the discussion on

+Android Developers

It is easy to focus on teams and techniques such as the planning game and stand-up meeting to the exclusion of the individual when talking about commitment in Agile. It can feel like Agile is promoting collectivism. I actually had an especially philosophical student jump up in class and shout, “this is communism!” While most IT projects are team-based endeavors, teams developed from individuals plays a central role in making Agile techniques work. Committed individuals are the building blocks that create committed teams.

Individual commitment is a willingness to dedicate one’s self to a goal, and then to work as hard as possible to attain the goal. Commitment is so important that the Scrum Alliance (the entity that certifies Scrum masters, Scrum professionals and trainers) includes commitment in their code of ethics. To quote the code of ethics from the Scrum Alliance

“We take responsibility for and fulfill the commitments that we undertake – we do what we say we will do[1].”

When individual commitment exists then team commitment is possible.  Harnessing the assembled team of committed individuals becomes a coordination activity. Organization or project goals act as a guide to bring committed individuals together into committed teams.

Jeff Sutherland, one of the co-developers of Scrum says that “it is only when individuals and teams are committed that they feel accountable for delivering high value, which is the bottom line for software development teams[2].” Committed individuals are the building blocks for building committed teams. While teams are generally required for achieving results in software development, individuals are never optional.

 

[1] http://www.scrumalliance.org/pages/code_of_ethics

 

[1] Agile Principles and Values, by Jeff Sutherland, http://msdn.microsoft.com/en-us/library/dd997578(v=vs.100).aspx. 5/15/2013

 

 

By Scott Knaster, Google Developers Blog Editor


“Google I/O is an annual developer conference featuring highly technical, in-depth sessions, and showcasing the latest from Google's product teams and partners.”
   – official description

Google I/O 2013 has just ended, and even more than usual, this one was for you, our developers. This year, we focused on providing new tools and services you’ve been asking for, plus a few surprises that we hope inspired and delighted you.

• Android gets its own IDE: Android Studio, based on IntelliJ IDEA Community Edition.
• Google Play Services 3.1 brings game services, location APIs, Google Cloud Messaging enhancements, and Cross-Platform Single Sign On.
• An updated Google Play Developer Console adds a very cool app translation service, revenue graphs, alpha and beta testing and staged rollouts, optimization tips, and referral tracking.
• We showed off a whole new look for Google Maps and Maps APIs, featuring new base map tiles, a new default marker, a new info window style, and a style refresh for controls.
• In Google Cloud Platform news, we announced that Google Compute Engine is now open to everyone and has sub-hour billing, we’ve added a PHP runtime to App Engine, and we introduced Google Cloud Datastore.
• We showed new Google Wallet features: the Instant Buy Android API, which makes buying in native Android apps fast and easy, and the Wallet Objects API, which lets you connect your loyalty programs, offers and more to Google Wallet.

Although we put developer announcements first this year, we didn’t skimp on the cool stuff for everyone: we refreshed the look of the Google+ stream, launched expanded Hangouts, totally revamped Google+ photos, announced Google Play Music All Access, showed off conversational search, and demoed some amazing Chrome Experiments.

Of course, Google I/O isn’t just about announcements. It’s our chance to share what’s new with you in those highly technical, in-depth sessions and for you to meet and interact with our engineers and other Googlers, in person and via the Internet. Once again this year, all sessions were recorded and are being posted to Google Developers Live (GDL) for you to peruse whenever it’s convenient for you.

We love putting on Google I/O, and that’s one reason we created GDL. With GDL, we don’t have to pack all our presentations into a 3-day conference. You’ll find new programs on GDL every week, from the same people who present at Google I/O. Just like during I/O, you can watch live or see recordings whenever you want. You can subscribe to the Google Developers channel on YouTube to be notified when new programs are posted.

Whether you came to San Francisco, participated in I/O Extended, or watched our live streams, we thank you for your attention and dedication. Here’s to Google I/O 2014!