Skip to content

Feed aggregator

The 5 Stages of Developer Grief: SpaceCityJS 2015 Keynote

Derick Bailey - new ThoughtStream - Mon, 03/30/2015 - 00:04

Following from my March 2nd presentation of the 5 Stages of Entrepreneurial Grief, I had the opportunity to turn that presentation in to the keynote address for the SpaceCityJS conference in Houston Texas on March 28th. I recorded the talk and have uploaded it to youtube for everyone to watch.

In this talk, I go through not only the 5 stages of grief, as applied to developers and the work we do, adding my own “Stage 0: Frenetic Energy” and some additional lessons learned.

Unlike the previous 5 Stages of Entrepreneurial work, this version of the talk does not have such an exclusive focus on the entrepreneurial side of software development. Rather, it focuses on the human side of software and the problems that we face as developers. From open source work, to corporate life and client work, the emotions we deal with are an important part of our lives and something that must be discussion more openly and honestly if we are to move ourselves, our communities and our industry forward.

From the denial of the value that we provide, to the anger we face on social media and the acceptance of the work we do, this talk is a raw, open and honest look at the emotions and struggles that we face as software developers.

Resources From The Talk

Along with this talk, I reference a number of resources and links. I also have the slide deck and all of the images from it available on Github. Check out the resources here:

 

Categories: Blogs

InetAddressImpl#lookupAllHostAddr slow/hangs

Mark Needham - Sun, 03/29/2015 - 02:31

Since I upgraded to Yosemite I’ve noticed that attempts to resolve localhost on my home network have been taking ages (sometimes over a minute) so I thought I’d try and work out why.

This is what my initial /etc/hosts file looked like based on the assumption that my machine’s hostname was teetotal:

$ cat /etc/hosts
##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##
127.0.0.1	localhost
255.255.255.255	broadcasthost
::1             localhost
#fe80::1%lo0	localhost
127.0.0.1	wuqour.local
127.0.0.1       teetotal

I setup a little test which replicated the problem:

import java.net.InetAddress;
import java.net.UnknownHostException;
 
public class LocalhostResolution
{
    public static void main( String[] args ) throws UnknownHostException
    {
        long start = System.currentTimeMillis();
        InetAddress localHost = InetAddress.getLocalHost();
        System.out.println(localHost);
        System.out.println(System.currentTimeMillis() - start);
    }
}

which has the following output:

Exception in thread "main" java.net.UnknownHostException: teetotal-2: teetotal-2: nodename nor servname provided, or not known
	at java.net.InetAddress.getLocalHost(InetAddress.java:1473)
	at LocalhostResolution.main(LocalhostResolution.java:9)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134)
Caused by: java.net.UnknownHostException: teetotal-2: nodename nor servname provided, or not known
	at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
	at java.net.InetAddress$1.lookupAllHostAddr(InetAddress.java:901)
	at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1293)
	at java.net.InetAddress.getLocalHost(InetAddress.java:1469)
	... 6 more

Somehow my hostname has changed to teetotal-2 so I added the following entry to /etc/hosts:

127.0.0.1	teetotal-2

Now if we run the program we see this output instead:

teetotal-2/127.0.0.1
5011

It’s still taking 5 seconds to resolve which is much longer than I’d expect. After break pointing through the code it seems like it’s trying to do an IPv6 resolution rather than IPv4 so I added an /etc/hosts entry for that too:

::1             teetotal-2

Now resolution is much quicker:

teetotal-2/127.0.0.1
6

Happy days!

Categories: Blogs

Internet of things

Xebia Blog - Sat, 03/28/2015 - 12:26

Do you remember the time that you were not connected to the internet? When you had to call your friend instead of sending a message via Whatsapp to make an appointment. The times you had to apply for a job by writing a letter with  a pen instead of sending your Linkedin page? We all have gone through a major revolution in which we've all got a digital identity. The same revolution has started for things, right now!

Internet of Things

Potential

Things we use all day, like your watch or thermostat, get suddenly connected to the internet. These things are equipped with electronics, sensors and connectivity. Whether you like it or not, you will not escape this movement. According to Gartner there will be nearly 26 billion devices on the Internet of Things by 2020.
The potential of the Internet of Things isn’t just linking millions of devices. It is more like the potential of Google or Amazon had when building massive IT infrastructure. The IoT is about transforming business models and enabling companies to sell products in entirely new and better ways.

Definition

The definition of IoT is fairly simple. The internet of things involves `every thing that is connected to the internet`. You should exclude mobiles and computers, because they've already become mainstream.

In fact, the Internet of things is a name for a set of trends. First of all we have the trend that objects, we use all day,  are suddenly connected to the internet. For example bathroom scales that compares your weight with others.
Another trend is that devices that were already shipped with CPUs have become much more powerful when they’re connected to a network. Functionality of the hardware depends on local computing as well as powerful cloud computing. Fitness tracker, can carry out some functionality, like basic data cleaning and tabulation, on local hardware, but it depends on sophisticated machine-learning algorithms on an ever improving cloud service to offer prescription and insight.
Besides that we have the makers movement. Creating hardware isn’t for the big companies like Sony or Samsung anymore, just like creating software in the 80’s and 90’s was a privilege for IBM and Microsoft.

What’s new?

Devices that are connected to the internet aren’t new. For many years, we've connected devices to the internet, although not at that size. I think we have to compare it concepts like 'the cloud'. Before I heard the name 'the cloud' I was already using services that run on the internet, like Hotmail. But one swallow doesn't make a summer. When suddenly lots of services are running on the web, we speak of a trend and the market will give it a name to it. The same is happening with the internet of things. Suddenly all kinds of 'normal' devices are connected to the internet and we have a movement towards that direction that is unstoppable. And the possibilities it will bring are endless.

Splitting up in pieces

We can divide the internet of things into five smart categories. First of all we have the smart wearable. It is designed for a variety of purposes as well as for wear on a variety of parts of the body. Think of a bicycle helmet that detects a crash. Next to it we have the smart home. It’s goal is to make the experience of living at home more convenient and pleasant. A thermostat that learns what temperatures users like and builds a context-aware personalized schedule. A third and fourth category are the smart city and smart environment. It focuses on finding sustainable solutions to the growing problems. The last category is very interesting. It is the smart enterprise. One can think of real-time shipment tracking or smart metering solution that manages energy consumption at the individual appliance and machine level.

Changes of business models

There are plenty of new business models due to the internet of things. An example is a system that provides a sensor-embedded trash, so it’s capable of real-time context analysis and alerting the authorities when it is full and needs to be emptied. Another example is the insurance world, which will adopt the internet of things. There's already behaviour-based car insurance pricing available. Customers who agree to install a monitoring device on their car's diagnostic port, get a break on their insurance rates and pricing that varies according to usage and driving habits.

Big data

Other disciplines in software development also have interest in the new movement, like big data. Internet of things will not generate big data, but obesitas data. Did you know that within every flight, there are  3 terabytes of data generated with all the sensors in an airplane? Think about how much data will be generated, that has to be analyzed, when all buildings in a town are equipped with sensors to measure the quality of the air?

Conclusion

The intersection between software and the physical world becomes smaller every day and that is the result of the unstoppable movement of internet of things. It is still at the beginning. Business models are changing and there are lots of opportunities. You just have to find them...

Categories: Companies

What Every Framework/Method Should Have

NetObjectives - Sat, 03/28/2015 - 08:52
I was asked my thoughts about the blog LeSS SAFe.Comparison. It prompted me to think - many people are comparing one approach to another.  I've done this myself as I think it's a way to learn options that are available. But most folks don't go far enough. Instead of asking "how does A compare to B?" perhaps we should be asking "what does A and B need?"   The Key Components of a Framework Or...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

A Structure for Product Management Knowledge and Skills Acquisition

Applied Frameworks - Fri, 03/27/2015 - 20:29

In the last two Certified Scrum Product Owner courses that I taught, people have asked, “What’s next?” A beautiful question indeed. My answer included a path to Certified Scrum Professional that Carlton Nettleton and I have developed, a series of advanced courses that Applied Frameworks offers, and the Scaled Agile Product Management course that we offer.

Let’s go much deeper in how people in the role of Product Owner and people in the software Product Management profession should think about levels of training and knowledge acquisition. I thank Luke Hohmann for the following structure that he attributes to Meiler Page-Jones.

1.     Innocent. You have not been exposed to a given area of knowledge and are unaware of its existence. In other words, you have absolutely no plans associated with the topic in your cognitive library, your preexisting set of solutions and experiences.

2.     Aware. You have been exposed to an area of knowledge (such as a new technique to organize your product backlog), perhaps by reading an article, and can see its relevance, but have not yet applied or used it. Your cognitive library may have one or two plans regarding the body of knowledge. These plans are rudimentary at best. You are still unable to use it for any useful purpose.

3.     Apprentice. You have had some formal training in the structures, processes, and outcomes associated with a topic, perhaps through a two or three day workshop. You have begun the task of creating and storing plans in your cognitive library. At this stage of learning, structures tend to be viewed as absolute, not to be violated. You can produce simple outcomes for well-defined problems, but require the assistance of more expert individuals to solve ill-defined or new problems.

4.     Practitioner. You are able to accomplish moderately difficult tasks without assistance. Your cognitive library is fairly well developed, but you must still rely on experts to accomplish very complex tasks.

5.     Journeyman. You regularly use the body of knowledge in your work, and begin to question and/or modify structures to suit your needs. At this stage your cognitive library is reasonably large. You begin to apply existing plans in novel ways. Individuals at levels 2 through 4 seek your guidance.

6.     Master. You have mastered the body of knowledge, and can effectively apply it in many different situations. Your cognitive library is quite well developed. It contains plans enabling you to solve well-known problems quickly and easily. You are adept at applying plans in novel ways. You can easily adapt or invent appropriate structures to aid in problem solving.

7.     Expert. With substantial expertise, you move beyond the master stage by extending the collective body of knowledge through lectures, writing articles and/or books, or applying the knowledge in new problem domains. The difference between a master and an expert is subtle, but important. Both possess extensive cognitive libraries, but the expert works at externalizing their library in a form suitable for use by others.

All of us at Applied Frameworks focus on how to assist you on your journey to the Expert level of product management in each of the frameworks you need to succeed and excel at your job.

We will help you assess where you are now and your path to the next level.  We absolutely value your input and specific feedback as we work through our minimum viable product to create a service that delivers value.

Categories: Companies

Agile in Context

Agile Learning Labs - Fri, 03/27/2015 - 19:28

“It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is most adaptable to change.”
Charles Darwin

Just about everyone agrees that being “adaptable to change” is important.

At the same time, many people believe that we’re entering an age of acceleration. The models underlying society at every level are being redefined as traditional linear models of change give way to the explosive power of exponential growth. According to computer scientist, inventor and futurist Ray Kurzweil:

“The 21st century will be equivalent to 20,000 years of progress at today’s rate of progress; organizations have to be able to redefine themselves at a faster and faster pace.”

At all levels of engineering, we need a management methodology that is “most adaptable to change.”

Is “Agile” the answer? When we ask people to voice their opinions, doubts emerge around the concept of “agile methodologies.” Is it a new buzzword, yet another management fad or a new paradigm for surviving and thriving in times of rapid change? Or is there something better on the horizon?

Join Cathy Simpson of Agile Learning Labs to explore these questions at the next IEEE Technology and Engineering Management Society meeting on April 2, 2015. In this talk, we will look for the “core of agile” that will endure beyond the fad. We will address agile in context. Everything that is old is new again; and perhaps we will discover together that we’ve been agile all along. We just didn’t have the context to know it.

Categories: Companies

7 Habits of Highly Motivated People

J.D. Meier's Blog - Fri, 03/27/2015 - 19:08

Motivation is a powerful skill.

It can lift you up from the worst of places, and inspire you to new heights.

After all, nothing is worse than slogging your way through your days, or working your way through a bunch of mundane tasks.

But, like I said, motivation is a skill.

You need to learn it.   For many people it does not come naturally.   And chances are, many of us have had bad models, bad advice, and worse, bad habits for a lifetime.

One of the most important insights I found was said by Stephen Covey long ago – satisfied needs don’t motivate.

It’s why we need to stay hungry.

Here’s how you stay hungry -- find a problem you hate, and focus on creating a solution you love.

But how you light your fire from the inside out in a sustainable way?

That’s where the 7 habits of highly motivated people comes in.

I wanted to put together a very simple set of habits and practices that actually work for building your motivational muscle and finding your inner mojo.

Here are the 7 habits of highly motivated people at a glance:

  1. Find Your WHY
  2. Change Your Beliefs About What’s Possible
  3. Change Your Beliefs That Limit You
  4. Spend More Time In Your Values
  5. Surround Yourself With Catalysts
  6. Build Better Feedback Loops
  7. “Pull” Yourself with Compelling Goals

There is a lot of science behind the habits.  If you’re that motivated, you can research it through bunches of books, bunches of sites, and brilliant TED talks.

But, I’d much rather that you spent the time simply adopting and applying the habits, so you can set your motivation on fire.

It’s time to do more of what you were born to do.

It’s time to live and breathe the things that you want to live and breathe.

It’s time to rise again from whatever ashes might have burned you down, and let your phoenix fly.

If you aren’t sure where to get started, first read 7 habits of highly motivated people, and then adopt habit #1:

Find Your WHY.

You’ll be glad you did.

I can see your pilot light is on already.

Categories: Blogs

Design Thinking Meets Civic Tech

Rally Agile Blog - Fri, 03/27/2015 - 16:00

As part of our recently announced partnership with Code for America, Rallyers took a leadership role in supporting the annual CodeAcross event here in Boulder, where Rally is headquartered. On a recent snowy Saturday, Code for Boulder—the local all-volunteer Brigade—hosted “Crafting Civic Tech: The Housing Edition.”

Veteran Rally Agilists, company founder Ryan Martens, and Rally coach Ronica Roth led the group of more than 50 community members on a six-hour design thinking journey. The goal: identify ways to improve and increase civic engagement among community members and local government, with a focus on the issue of housing.

Ronica Roth and Ryan Martens explaining the design thinking approach

Digging into the Topic of Housing

The City of Boulder sums up the area’s housing situation as “Setting + Culture + Opportunities + Quality of Life = High Demand for Housing.” To create a “collaborative community conversation,” the City is teaming with Code for America to increase two-way dialogue with residents and encourage citizens to take a more active role in key local issues.

"The city takes transparency and community collaboration seriously. Communication in the twenty-first century is changing and we want to harness the entrepreneurial spirit of our community—and be part of that change." Jane Brautigam, City Manager

Because the timing of the annual CodeAcross event aligned well with the first few weeks of the project between the City and Code for America, the local Brigade designed the gathering to broaden and deepen the conversation between community members, then share insights and ideas with local government.

Crafting Problem Statements from Empathy Interviews

The Stanford University Institute of Design created a design thinking workbook to lead people through the process of gaining empathy as a critical first step toward creating solutions that solve real human or business needs. Without addressing problems that people want or need solved, products and services are destined to require “push” from the creator rather than “pull” from the user. Participants started the day by practicing empathy interviews on each other. Afterwards, several pairs shared with the whole group the problem statements they crafted after interviewing each other.

“Listening is a critical skill to develop—it was a great setting to practice listening.” Dina Robin, participant

Next we heard from Becky Boone, the Code For America fellow who is conducting an in-depth exploration into the needs and challenges of improving community engagement in Boulder. Becky has done numerous empathy interviews within government as well as the community. As a result, she crafted problem statements on the topic of housing. Here’s a small sampling, written in the design thinking format: [Name] needs a way to [user’s need]. Unexpectedly, in his/her world, [insight].

  • Hugh needs a way to weigh in on housing issues in Boulder. Unexpectedly, in his world, he does not have a computer or internet access.
  • Jake needs a way to feel like his opinion matters. Unexpectedly, in his world, he hasn’t seen public opinion matter when the City Council makes a decision.
  • Tam needs a way to feel like her presence in Boulder matters. Unexpectedly, in her world, she feels her contributions to the local economy aren’t valued, hence her opinions aren’t valued.
  • Bao needs a way to know who to talk to when he wants to talk about housing. Unexpectedly, in his world, he has no awareness of the current structure in place.
  • Darryl needs a way to feel like his demographic is valued in Boulder. Unexpectedly, in his world, people in power have spoken dismissively of what he has to offer.
  • Maxwell needs a way to allow change in his neighborhood. Unexpectedly, in his world, people are squashing ideas for the city, eliminating possibilities in his neighborhood.
Teams Dig Deeper, Craft Possible Solutions

Teams ranging from four to eight people formed around the “problem statements” that attendees had interest in exploring further. For two hours, they talked through potential solutions, continuing to use the design thinking workbook as a guide.

“The Code for Boulder Civic Tech Forum was excellent because we were encouraged to stay in the place of inquiry, rather than racing superficially to find the solution. We worked in small teams with other community members who care deeply about an issue. I am focused on senior housing issues and am thrilled that two very concrete and needed tech solutions arose from our discussions today.” Neshama Abraham, participant

To wrap up the day, each team shared their ideas for solutions with the whole group.

Then participants were encouraged to rate the ideas and solutions that were generated. Each person was encouraged to place two dots next to the idea(s) they believed were most important. Red dots indicated “hot” ideas and blue dots indicated what may be a “quick win.”

The top vote-earning idea was to create a two-way dialogue with citizens, where they could click an online map of current development projects, learn about those of interest, and leave comments that would become part of the public record related to the location. What came to be known as “idea #1” received 12 votes total: 7 blue and 5 red.

Ideas Into Taking Action

The week following the event, both the City Council and Housing Committee received briefings from Becky Boone, and both groups asked to stay informed of how these ideas progressed within the Code for Boulder Brigade.

Brigade members decided at their subsequent meeting to work toward making idea #1 a reality. Because of the bonds formed during the CodeAcross event, there is now open dialogue between the city and this all-volunteer civic tech group to access data sets that have previously not been available to the public or not in a format usable by the latest technology. City employees are attending the Brigade meetups and listening to the requests of how to improve what they offer to residents.

How did the event live up to its goal to identify ways to improve and increase civic engagement among community members and with local government? We’re proud of our “wins”:

  • Over 50 community members worked together for a day of active listening, ideation, and problem-solving. They experienced the design thinking methodology, starting with empathy listening to craft problem statements, before jumping to possible solutions: an approach that they can use in other contexts.
  • Three city leaders and one City Council member joined us throughout the day. They heard firsthand from residents and participated in a collaborative problem-solving process.
  • Three city employees have gotten involved in the Brigade’s new initiative that came out of CodeAcross. The result is not only increased dialogue, but the opening of additional data sets and ongoing project collaboration between civic tech volunteers and local government.
  • The Brigade now has a solid queue of potential projects from other ideas the came out  the event, all of which were generated by community members.
“The event brought together a diverse group of community members and leveraged excellent problem solving approach. Design Thinking brings out the very best in the group by encouraging them to first think broadly, and then to employ a combination of empathy and creativity to find innovative solutions. I believe the event delivered some excellent ideas that may ultimately benefit the entire Boulder community.” Gerry Valentine, volunteer facilitator

Watch a 90-second overview of the day, produced by the City of Boulder’s Channel 8.

Rally’s partnership with Code for America’s Brigade program will continue to bring opportunities to apply approaches like design thinking, Lean Startup, and Agile team processes to the civic tech movement. Our next event? We’re bringing civic tech to RallyON 2015 in Phoenix, June 15-17. Stay tuned for details in the coming months.

Geri Mitchell-Brown
Categories: Companies

What is BDD?

lizkeogh.com - Elizabeth Keogh - Fri, 03/27/2015 - 12:24

At #CukeUp today, there’s going to be a panel on defining BDD, again.

BDD is hard to define, for good reason.

First, because to do so would be to say “This is BDD” and “This is not BDD”. When you’ve got a mini-methodology that’s derived from a dozen other methods and philosophies, how do you draw the boundary? When you’re looking at which practices work well with BDD (Three Amigos, Continuous Integration and Deployment, Self-Organising Teams, for instance), how do you stop the practices which fit most contexts from being adopted as part of the whole?

I’m doing BDD with teams which aren’t software, by talking through examples of how their work might affect the world. Does that mean it’s not really BDD any more, because it can’t be automated? I’m talking to people over chat windows and sending them scenarios so they can be checked, because we’re never in the same room. Is that BDD? I’m writing scenarios for my own code, on my own, talking to a rubber duck. Is that it? I’m still using scenarios in conversation to explore and define requirements, with all the patterns that I’ve learnt from the BDD world. I’m still trying to write software that matters. It still feels like BDD to me. I can’t even say that BDD’s about “writing software that matters” any more, because I’ve been using scenarios to explore life for a while now.

I expect in a few years the body of knowledge we call “BDD” will also include adoption patterns, non-software contexts, and a whole bunch of other things that we’re looking at but which haven’t really been explored in depth. BDD is also the community; it’s the people who are learning about this and reporting their learning and asking questions, and the common questions and puzzles are also part of BDD, and they keep changing as our understanding grows and the knowledge becomes easier to access and other methods like Scrum and Kanban are adopted and enable BDD to thrive in different places.

Rather than thinking of BDD as some set of well-defined practices, I think of it as an anchor term. If you look up anything around BDD, you’re likely to find conversation, collaboration, scenarios and examples at its core, together with suggestions for how to automate them. If you look further, you’ll find Three Amigos and Outside-In and the Given / When / Then syntax and Cucumber and Selenium and JBehave and Capybara and SpecFlow and a host of other tools. Further still we have Cynefin and Domain Driven Design and NLP, which come with their own bodies of knowledge and are anchor terms for those, and part of their teaching overlaps part of what I teach, as part of BDD, and that’s OK.

That’s why, when I’m asked to define BDD, I say something like, “Using examples in conversation to illustrate behaviour.” It’s where all this started, for me. That’s the anchor. It’s where everything else comes from, but it doesn’t define the boundaries. There are no boundaries. The knowledge, and the understanding, and especially the community that we call “BDD” will keep on growing.

One day it will be big enough that there will be new names for bits of it, and maybe those new names will be considered part of BDD, and maybe they won’t. And when that happens, that should be OK, too.

NB: I reckon the only reason that other methods are defined more precisely is so they could be taught consistently at scale, especially where certification is involved. Give me excellence, diversity and evolution over consistency any day. I’m pretty sure I can sell them more easily… and so can everyone else.


Categories: Blogs

7 tips for being an Agile Manager

Growing Agile - Fri, 03/27/2015 - 10:29

We recently gave a talk at the ITWeb Software Development Management Conference in Johannesburg, South Africa. We decided to speak about what should a software development manager of agile teams be focussed on. Personally I think these 7 tips can be applied to anyone in a management or even leadership position.

Here is a summary slide:

SevenTips

 

Here is the full presentation. We tried to put a few notes on each tip, so that even if you didn’t attend the talk – hopefully you can understand what we mean by the slides.

7 tips for managing software development in the age of agile from Growing Agile
Categories: Companies

Neo4j: Generating real time recommendations with Cypher

Mark Needham - Fri, 03/27/2015 - 08:59

One of the most common uses of Neo4j is for building real time recommendation engines and a common theme is that they make use of lots of different bits of data to come up with an interesting recommendation.

For example in this video Amanda shows how dating websites build real time recommendation engines by starting with social connections and then introducing passions, location and a few other things.

Graph Aware have a neat framework that helps you to build your own recommendation engine using Java and I was curious what a Cypher version would look like.

This is the sample graph:

CREATE
    (m:Person:Male {name:'Michal', age:30}),
    (d:Person:Female {name:'Daniela', age:20}),
    (v:Person:Male {name:'Vince', age:40}),
    (a:Person:Male {name:'Adam', age:30}),
    (l:Person:Female {name:'Luanne', age:25}),
    (c:Person:Male {name:'Christophe', age:60}),
 
    (lon:City {name:'London'}),
    (mum:City {name:'Mumbai'}),
 
    (m)-[:FRIEND_OF]->(d),
    (m)-[:FRIEND_OF]->(l),
    (m)-[:FRIEND_OF]->(a),
    (m)-[:FRIEND_OF]->(v),
    (d)-[:FRIEND_OF]->(v),
    (c)-[:FRIEND_OF]->(v),
    (d)-[:LIVES_IN]->(lon),
    (v)-[:LIVES_IN]->(lon),
    (m)-[:LIVES_IN]->(lon),
    (l)-[:LIVES_IN]->(mum);

We want to recommend some potential friends to ‘Adam’ so the first layer of our query is to find his friends of friends as there are bound to be some potential friends amongst them:

MATCH (me:Person {name: "Adam"})
MATCH (me)-[:FRIEND_OF]-()-[:FRIEND_OF]-(potentialFriend)
RETURN me, potentialFriend, COUNT(*) AS friendsInCommon
 
==> +--------------------------------------------------------------------------------------+
==> | me                             | potentialFriend                   | friendsInCommon |
==> +--------------------------------------------------------------------------------------+
==> | Node[1007]{name:"Adam",age:30} | Node[1006]{name:"Vince",age:40}   | 1               |
==> | Node[1007]{name:"Adam",age:30} | Node[1005]{name:"Daniela",age:20} | 1               |
==> | Node[1007]{name:"Adam",age:30} | Node[1008]{name:"Luanne",age:25}  | 1               |
==> +--------------------------------------------------------------------------------------+
==> 3 rows

This query gives us back a list of potential friends and how many friends we have in common.

Now that we’ve got some potential friends let’s start building a ranking for each of them. One indicator which could weigh in favour of a potential friend is if they live in the same location as us so let’s add that to our query:

MATCH (me:Person {name: "Adam"})
MATCH (me)-[:FRIEND_OF]-()-[:FRIEND_OF]-(potentialFriend)
 
WITH me, potentialFriend, COUNT(*) AS friendsInCommon
 
RETURN  me,
        potentialFriend,
        SIZE((potentialFriend)-[:LIVES_IN]->()<-[:LIVES_IN]-(me)) AS sameLocation
 
==> +-----------------------------------------------------------------------------------+
==> | me                             | potentialFriend                   | sameLocation |
==> +-----------------------------------------------------------------------------------+
==> | Node[1007]{name:"Adam",age:30} | Node[1006]{name:"Vince",age:40}   | 0            |
==> | Node[1007]{name:"Adam",age:30} | Node[1005]{name:"Daniela",age:20} | 0            |
==> | Node[1007]{name:"Adam",age:30} | Node[1008]{name:"Luanne",age:25}  | 0            |
==> +-----------------------------------------------------------------------------------+
==> 3 rows

Next we’ll check whether Adams’ potential friends have the same gender as him by comparing the labels each node has. We’ve got ‘Male’ and ‘Female’ labels which indicate gender.

MATCH (me:Person {name: "Adam"})
MATCH (me)-[:FRIEND_OF]-()-[:FRIEND_OF]-(potentialFriend)
 
WITH me, potentialFriend, COUNT(*) AS friendsInCommon
 
RETURN  me,
        potentialFriend,
        SIZE((potentialFriend)-[:LIVES_IN]->()<-[:LIVES_IN]-(me)) AS sameLocation,
        LABELS(me) = LABELS(potentialFriend) AS gender
 
==> +--------------------------------------------------------------------------------------------+
==> | me                             | potentialFriend                   | sameLocation | gender |
==> +--------------------------------------------------------------------------------------------+
==> | Node[1007]{name:"Adam",age:30} | Node[1006]{name:"Vince",age:40}   | 0            | true   |
==> | Node[1007]{name:"Adam",age:30} | Node[1005]{name:"Daniela",age:20} | 0            | false  |
==> | Node[1007]{name:"Adam",age:30} | Node[1008]{name:"Luanne",age:25}  | 0            | false  |
==> +--------------------------------------------------------------------------------------------+
==> 3 rows

Next up let’s calculate the age different between Adam and his potential friends:

MATCH (me:Person {name: "Adam"})
MATCH (me)-[:FRIEND_OF]-()-[:FRIEND_OF]-(potentialFriend)
 
WITH me, potentialFriend, COUNT(*) AS friendsInCommon
 
RETURN me,
       potentialFriend,
       SIZE((potentialFriend)-[:LIVES_IN]->()<-[:LIVES_IN]-(me)) AS sameLocation,
       abs( me.age - potentialFriend.age) AS ageDifference,
       LABELS(me) = LABELS(potentialFriend) AS gender,
       friendsInCommon
 
==> +------------------------------------------------------------------------------------------------------------------------------+
==> | me                             | potentialFriend                   | sameLocation | ageDifference | gender | friendsInCommon |
==> +------------------------------------------------------------------------------------------------------------------------------+
==> | Node[1007]{name:"Adam",age:30} | Node[1006]{name:"Vince",age:40}   | 0            | 10.0          | true   | 1               |
==> | Node[1007]{name:"Adam",age:30} | Node[1005]{name:"Daniela",age:20} | 0            | 10.0          | false  | 1               |
==> | Node[1007]{name:"Adam",age:30} | Node[1008]{name:"Luanne",age:25}  | 0            | 5.0           | false  | 1               |
==> +------------------------------------------------------------------------------------------------------------------------------+
==> 3 rows

Now let’s do some filtering to get rid of people that Adam is already friends with – there wouldn’t be much point in recommending those people!

MATCH (me:Person {name: "Adam"})
MATCH (me)-[:FRIEND_OF]-()-[:FRIEND_OF]-(potentialFriend)
 
WITH me, potentialFriend, COUNT(*) AS friendsInCommon
 
WITH me,
     potentialFriend,
     SIZE((potentialFriend)-[:LIVES_IN]->()<-[:LIVES_IN]-(me)) AS sameLocation,
     abs( me.age - potentialFriend.age) AS ageDifference,
     LABELS(me) = LABELS(potentialFriend) AS gender,
     friendsInCommon
 
WHERE NOT (me)-[:FRIEND_OF]-(potentialFriend)
 
RETURN me,
       potentialFriend,
       SIZE((potentialFriend)-[:LIVES_IN]->()<-[:LIVES_IN]-(me)) AS sameLocation,
       abs( me.age - potentialFriend.age) AS ageDifference,
       LABELS(me) = LABELS(potentialFriend) AS gender,
       friendsInCommon
 
==> +------------------------------------------------------------------------------------------------------------------------------+
==> | me                             | potentialFriend                   | sameLocation | ageDifference | gender | friendsInCommon |
==> +------------------------------------------------------------------------------------------------------------------------------+
==> | Node[1007]{name:"Adam",age:30} | Node[1006]{name:"Vince",age:40}   | 0            | 10.0          | true   | 1               |
==> | Node[1007]{name:"Adam",age:30} | Node[1005]{name:"Daniela",age:20} | 0            | 10.0          | false  | 1               |
==> | Node[1007]{name:"Adam",age:30} | Node[1008]{name:"Luanne",age:25}  | 0            | 5.0           | false  | 1               |
==> +------------------------------------------------------------------------------------------------------------------------------+
==> 3 rows

In this case we haven’t actually filtered anyone out but for some of the other people we would see a reduction in the number of potential friends.

Our final step is to come up with a score for each of the features that we’ve identified as being important for making a friend suggestion.

We’ll assign a score of 10 if the people live in the same location or have the same gender as Adam and 0 if not. For the ageDifference and friendsInCommon we’ll apply apply a log curve so that those values don’t have a disproportional effect on our final score. We’ll use the formula defined in the ParetoScoreTransfomer to do this:

    public <OUT> float transform(OUT item, float score) {
        if (score < minimumThreshold) {
            return 0;
        }
 
        double alpha = Math.log((double) 5) / eightyPercentLevel;
        double exp = Math.exp(-alpha * score);
        return new Double(maxScore * (1 - exp)).floatValue();
    }

And now for our completed recommendation query:

MATCH (me:Person {name: "Adam"})
MATCH (me)-[:FRIEND_OF]-()-[:FRIEND_OF]-(potentialFriend)
 
WITH me, potentialFriend, COUNT(*) AS friendsInCommon
 
WITH me,
     potentialFriend,
     SIZE((potentialFriend)-[:LIVES_IN]->()<-[:LIVES_IN]-(me)) AS sameLocation,
     abs( me.age - potentialFriend.age) AS ageDifference,
     LABELS(me) = LABELS(potentialFriend) AS gender,
     friendsInCommon
 
WHERE NOT (me)-[:FRIEND_OF]-(potentialFriend)
 
WITH potentialFriend,
       // 100 -> maxScore, 10 -> eightyPercentLevel, friendsInCommon -> score (from the formula above)
       100 * (1 - exp((-1.0 * (log(5.0) / 10)) * friendsInCommon)) AS friendsInCommon,
       sameLocation * 10 AS sameLocation,
       -1 * (10 * (1 - exp((-1.0 * (log(5.0) / 20)) * ageDifference))) AS ageDifference,
       CASE WHEN gender THEN 10 ELSE 0 END as sameGender
 
RETURN potentialFriend,
      {friendsInCommon: friendsInCommon,
       sameLocation: sameLocation,
       ageDifference:ageDifference,
       sameGender: sameGender} AS parts,
     friendsInCommon + sameLocation + ageDifference + sameGender AS score
ORDER BY score DESC
 
==> +-------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
==> | potentialFriend                   | parts                                                                                                           | score             |
==> +-------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
==> | Node[1006]{name:"Vince",age:40}   | {friendsInCommon -> 14.86600774792154, sameLocation -> 0, ageDifference -> -5.52786404500042, sameGender -> 10} | 19.33814370292112 |
==> | Node[1008]{name:"Luanne",age:25}  | {friendsInCommon -> 14.86600774792154, sameLocation -> 0, ageDifference -> -3.312596950235779, sameGender -> 0} | 11.55341079768576 |
==> | Node[1005]{name:"Daniela",age:20} | {friendsInCommon -> 14.86600774792154, sameLocation -> 0, ageDifference -> -5.52786404500042, sameGender -> 0}  | 9.33814370292112  |
==> +-------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

The final query isn’t too bad – the only really complex bit is the log curve calculation. This is where user defined functions will come into their own in the future.

The nice thing about this approach is that we don’t have to step outside of cypher so if you’re not comfortable with Java you can still do real time recommendations! On the other hand, the different parts of the recommendation engine all get mixed up so it’s not as easy to see the whole pipeline as if you use the graph aware framework.

The next step is to apply this to the Twitter graph and come up with follower recommendations on there.

Categories: Blogs

Codehaus & Ben: Thank You and Good Bye

Sonar - Thu, 03/26/2015 - 20:55

It seems very natural today that SonarQube is hosted at Codehaus, but there was a time when it was not! In fact joining Codehaus was a big achievement for us; you might even say it was one of the project’s first milestones, because Codehaus didn’t accept just any project. That may seem strange today, when you can get started on Github in a matter of minutes, but Codehaus was picky, and just being accepted was a big deal.

It was also a big deal because being accepted by Codehaus gave us access to a full suite of best-of-breed tools: IntelliJ, JProfiler, and Nexus, plus Jira, Confluence, and the rest of the Atlassian suite… This, coupled with the fact that Codehaus took on the burden of hosting and maintaining that infrastructure, allowed us to focus on the SonarQube platform and ecosystem. It enabled us to make what we think is a great product – a product that wouldn’t be what it is today without Codehaus.

The first ticket ever created for the SonarQube (née Sonar) project was SONAR-1, entered in the Codehaus Jira on Dec. 17th, 2007. The project was just under a year old at the time (SonarSource hadn’t even been founded yet). Over the next 7+ years, that ticket was followed by nearly 14,000 more across 42 projects, more than 60,000 emails across two mailing lists, and countless documentation revisions over the many versions of SonarQube and its plugins.

Of course, “Codehaus” really boils down to one guy: Ben Walding, who has been running the 1,000-project forge on his own time and his own dime from the beginning. No matter what was going on in Ben’s life, Codehaus was up. And he wasn’t just “keeping the lights on”, either; Ben always made things not just possible, but easy. So when he told us a couple of months ago that Codehaus was shutting down, it wasn’t really a surprise. In fact, as he said, the writing had been on the wall for a while. But it was saddening. Because no matter how many other options there are today for open source projects, Codehaus will always have a special place in the history of the open source movement and in our hearts.

We’ll announce what Life After Codehaus will look like in May, but in the meantime, we say: Merci beaucoup, Большое спасибо, Heel erg bedankt, Grazie mille, vielen Dank, Suur aitäh, Nagyon köszönöm, and Thank you, Ben. Goodbye to Codehaus, and thank you very much.

Categories: Open Source

Getting to Done

Scrum Log Jeff Sutherland - Thu, 03/26/2015 - 15:54

One of the key principles in the Agile Manifesto is to have working software at the end of every sprint. Yet, only 20% of teams that call themselves ’agile’ actually do this. That is a lot of bad agile. It doesn’t have to be that way. Getting to Done isn't impossible, it just requires discipline and focus.

Scrum co-creator Jeff Sutherland shares share proven and often quite simple ways to move teams from mediocre to great. This online course will teach you how to quickly identify the reasons why teams aren’t getting to done, and tools to eliminate them one by one.

 

 Scrum Inc.’s online courses are eligible for Scrum Alliance SEUs and PMI PDUs. See FAQ for details.

  Getting to Done .001 Getting to Done .001 Getting to Done .002 Getting to Done .002 Getting to Done .003 Getting to Done .003 Getting to Done .004 Getting to Done .004 Getting to Done .005 Getting to Done .005 Getting to Done .006 Getting to Done .006 Getting to Done .007 Getting to Done .007 Getting to Done .008 Getting to Done .008 Getting to Done .009 Getting to Done .009 Getting to Done .010 Getting to Done .010 Getting to Done .011 Getting to Done .011 Getting to Done .012 Getting to Done .012 Getting to Done .013 Getting to Done .013 Getting to Done .014 Getting to Done .014 Getting to Done .015 Getting to Done .015 Getting to Done .016 Getting to Done .016 Getting to Done .017 Getting to Done .017 Getting to Done .018 Getting to Done .018 Getting to Done .019 Getting to Done .019 Getting to Done .020 Getting to Done .020 Getting to Done .021 Getting to Done .021 Getting to Done .022 Getting to Done .022 Getting to Done .023 Getting to Done .023 Getting to Done .024 Getting to Done .024 Getting to Done .025 Getting to Done .025 Getting to Done .026 Getting to Done .026 Getting to Done .027 Getting to Done .027 Getting to Done .028 Getting to Done .028 Getting to Done .029 Getting to Done .029 Getting to Done .030 Getting to Done .030 Getting to Done .031 Getting to Done .031 Getting to Done .032 Getting to Done .032 Getting to Done .033 Getting to Done .033 Getting to Done .034 Getting to Done .034 Getting to Done .035 Getting to Done .035 Getting to Done .036 Getting to Done .036 Getting to Done .037 Getting to Done .037

Getting to Done Slides

Teams that Finish Early Accelerate Faster: A Pattern Language for High Performing Scrum Teams

  J. Sutherland, N. Harrison, and  J. Riddle,  IEEE HICSS 47th Hawaii International Conference on System Sciences, Big Island, Hawaii, 2014.

Scrum and CMMI - Going from Good to Great: Are You Ready Ready to Be Done Done

C. Jakobsen and J. Sutherland, in Agile 2009, Chicago, 2009.

 

Back to All Topics

The post Getting to Done appeared first on Scrum Inc.

Categories: Blogs

Operationalizing Strategy with a Systems Perspective

Leading Agile - Mike Cottmeyer - Thu, 03/26/2015 - 14:58

While there are many books and much research on organizational development, this system view combined with some validated learning over time is a powerful way to look at organizational challenges as a coach/consultant.

OD Model

Let’s take a closer look to define these areas then apply some validated learning from my own experience.

Business Outcomes – the outcomes desired from the business strategy selected

Org Structure – the structure of power and authority to facilitate decision making

Incentive Systems – rewards for individual and group performance

Work Systems – how people get work done in the organization

Collaboration Systems – systems to overcome the friction to collaboration introduced by the org structure

People Systems – hiring, firing, development, HR systems – both tactical and strategic

Validated Learning (observations and experiences over time)
  • Business outcomes are required to think about the other dimensions; and interestingly, in my experience even some top leaders can struggle to articulate these, so it may require some elicitation and dialogue. I like to use the pithy term “operationalize strategy” when discussing this topic.
  • Incentive systems usually mirror org structure fairly closely.
  • The org structure will help determine both work systems and collaboration systems; however, collaboration systems have a stronger relationship because they must overcome the friction introduced by the structure itself.
  • Incentive systems and people systems strongly impact everything else except strategy.
  • People tend to focus first on org structure and work systems because they are the most visible, tangible, and even “fun” to work with.
  • Each organization design decision made will impact the other dimensions so as the design is created, the entire system must be reevaluated.
  • Organizations are typically good at people systems when it comes to tactical training and development, but more powerful levers are hiring, firing, and strategic training needs.
  • The most common constraint on change involves incentive systems.

What observations and experiences do you have using a systems perspective to view organizational challenges? Has the use of a systems perspective helped overcome these challenges? Leave your comment below so that we can get the conversation started.

The post Operationalizing Strategy with a Systems Perspective appeared first on LeadingAgile.

Categories: Blogs

Top 10 Tips for Measuring Agile Success

Agile Management Blog - VersionOne - Thu, 03/26/2015 - 14:02

State_of_Agile_Report_2014

Choosing the right agile metric to measure agile success is really simple, right? I wish that were the case, but in reality choosing the correct agile metric can be a little tricky.

So, how do you get the most out of your agile metrics? I reviewed the 9th annual State of Agile survey, which compiles insights from nearly 4,000 respondents, to find out how agile practitioners are measuring the success of their agile initiatives.

 

#1 On-Time Delivery

According to the State of Agile survey, 58% of the respondents* said they measured the success of their agile initiatives by on-time delivery.

With agile, our schedule is fixed and our scope is flexed. What does that mean for on-time? Well, time just happens, so theoretically, we are always on time. But, on-time is generally measured in context with the expectations about what will be delivered. To measure and have visibility of what is being delivered, we may look to the out-of-the box metrics of the burndown or the burnup.

For instance, in this VersionOne burndown chart you can see progress as the team heads toward an expected end date.

metrics1

 

 

 

 

 

This burnup chart, on the other hand, allows you to see the trend of getting stuff done, as well as the impact of scope changes.

metrics2

 

 

 

 

 

 

 

#2 Product Quality

A total of 48% of the respondents to the survey said they measured the success of their agile initiatives through product quality.

Quality is often measured in multiple ways, including looking at the customer satisfaction, revenue growth, and the technical aspects of testing conducted throughout the development life cycle. With agile software development teams, we’ll look at our velocity of completing working software with quality built in. We tightly couple continuous testing and inspection throughout the lifecycle of the development, so we’ll constantly be monitoring testing trends as well as constantly inspecting build and code health.

For instance, in this testing trend chart you can see the cumulative progress around testing activities. Ultimately you want to see all green, but a large amount of red along the line might reflect some issues in the code base or process.

metrics3

 

 

 

 


#3 Customer/User Satisfaction

The survey found that 44% of respondents measured the success of their agile initiatives by customer or user satisfaction.

As with all these benefits, there are multiple ways to measure the outcomes. In the case of customer/user satisfaction, these include looking at the Net Promoter score, sales figures, number of support calls vs. number of features delivered in a time period, or usage statistics of product or site capabilities.

#4 Business Value

Approximately 44% of the respondents to the State of Agile survey stated that they measured the success of their agile initiatives by business value.

And several of the principles of the Agile Manifesto recognize the importance of delivering business value. Measuring business value is very explicit when we know that there’s a contract for work to complete or a compliance need and fines if we don’t finish the work. On the other hand, sometimes measuring value is prospective or speculative in the sense that the market inputs drive decisions and the value is often a best guess. Having a business value score applied to the features to be delivered can measure value.

Here’s a sample epic cumulative flow chart based on value. This helps you see the delivery of anticipated business value as features and other large stories are completed. 

metrics4

 

 

 

 

 

 

 

 

#5 Product Scope (Features, Requirements)

Another 39% of the respondents answered that they measured the success of their agile initiatives with product scope.

Setting a goal around what to get done over the next three months, then tracking status, and getting it completed is hugely rewarding. Actually having real-time feedback as to the progress of work is valuable to everyone on the team, from the engineers to the program managers. With agile software development projects, you can always rely on the burndown charts, or just visualize the progress of the cards moving from left-to-right on the project kanban board.

Here’s an epicboard in VersionOne that helps the team track and visualize the progress of features at a program level. Or if you’re using Scaled Agile Framework® (SAFe®), you can see progress at the release train level.

metrics5

 

 

 

 

 

#6 Project Visibility

Project visibility was the measure of choice for 30% of respondents to the survey.

One of the best ways to build trust is transparency. That means having the plans out in the open and making progress visible to all. Sharing progress at multiple dimensions provides the different stakeholders with information that makes sense from their point of view. Metrics that show feature or overall progress against a targeted plan can provide great insights.

In this chart you can visualize progress on a feature and known work. The red diamond represents what was actually anticipated, so it’s easy to gauge whether you are above or under the anticipated scope.

metrics6

 

 

 

 

 

 

The other reason visibility is important is because we need to have alignment among internal teams so they can best manage their work in relation to component or service dependencies.

Understanding the impact of one team’s work on another team is critical. By looking at the dependency chart below, it’s easy to identify the stories at risk.

metrics7

 

 

 

 

 

 

 

#7 Productivity

According to the State of Agile survey, 29% of the respondents said they measured the success of their agile initiatives through productivity.

The concept of productivity in an agile world is a measure of outcomes, not output. So looking at burnup for a product or based on value is hugely impactful. Simply looking at a burnup of count of stories or features over time is a great way to understand how much the team is actually delivering.

#8 Predictability

Approximately 25% of the respondents from the survey said they measured the success of their agile initiatives by predictability.

A predominant metric used to assess predictability is velocity trend. For a three- to four-month period, this shows how much work has been completed at a sustainable pace on average. A velocity that wildly fluctuates might reflect a team that is changing, work that is unpredictable, or simply a team that is still getting used to defining work small enough to complete in an iteration.

A velocity trend chart like the one below not only helps you see performance, but also gives you visibility into whether or not the team’s output is at a predictable state – as this one shows.

metrics8

 

 

 

 

 

 

 

You can always try to assess velocity based simply on the count of story cards completed every week. This is usually the best indicator of predictability.

#9 Process Improvement

Another 23% of the respondents said they measured the success of their agile initiatives by process improvement.

A core tenet of all lean and agile mindsets is continuous improvement – constantly getting better. But how do you know you are getting better unless you are measuring the outcomes? There are all the metrics above that help, but there’s also the extremely helpful cumulative flow chart which shows how well work is flowing through the lifecycle.

With this team level cumulative flow chart, you can see where bottlenecks or slowdowns may exist.

metrics9

 

 

 

 

 

Also, there’s cycle time – which helps us with planning and predictability. Cycle time is a great metric to view over time to see if process tweaks and adjustments are having an impact on productivity.

For instance, in this cycle time report, you can see the level of variability and performance across the various estimated pieces of work.

metrics10

 

 

 

 

 

 

 

#10 Don’t Know

Just 11% of the State of Agile survey respondents said they didn’t know! Well, if you don’t know the benefits, try to start looking at the metrics above. You’ll see improvements in delivered value, better quality around what is produced, a more predictable cadence, and ultimately happier customers.

Conclusion

These results show that there isn’t just a single metric that everyone uses. Different organizations, types of management, and teams need different metrics.

Not sure which metric is right for you? Check out the 9th annual State of Agile survey to learn more about what nearly 4,000 of your peers are doing.

What metric do you use to measure your agile initiatives’ success?

*Respondents were able to make multiple selections.

State of Agile is a trademark of VersionOne, Inc.

Categories: Companies

Why Managers Ask for Estimates and What They Need to Know

Johanna Rothman - Thu, 03/26/2015 - 13:26

In many of my transitioning to agile clients, the managers want to know when the project will be done. Or, they want to know how much the project will cost. (I have a new book about this, Predicting the Unpredictable: Pragmatic Approaches to Estimating Cost or Schedule.)

Managers ask for estimates because they want to know something about their ability to recognize revenue this year. How many projects can they release? What is the projected effect on revenue; customer acquisition and retention; and on service revenue (training, support, all that kind of service). We pay managers big bucks so they can project out for “a while” and plan for the business.

You need to know this in your life, too. If you are an employee, you know approximately how much money you will make in a year. You might make more if you get a bonus. You might make less if you get laid off. But, you have an idea, which allows you to budget for mortgages, vacations, and kid’s braces.

Remember, in waterfall, there was no benefit until the end of the project. You couldn’t realize any benefit from a project until it was complete: not revenue, not capitalization, not any effect on what customers saw. Nothing.

When you use agile, you have options if you can release early. Remember the potential for release frequency?

If you can do continuous deployment or even release something more often, you can realize the benefits of the project before the end.

If you are agile, you don’t need to estimate a lot to tell them when they can first receive value from your work. You can capitalize software early. Your customers can see the benefits early. You might be able to acquire more customers early.

Agile changes the benefits equation for projects.

Agile is about the ability to change. We see this at the team level clearly. When the team finishes a feature, the team is ready for the next feature. It doesn’t matter if you work in flow or timeboxes, you can change the features either for the next feature (flow) or at the next timebox. You can change what the team does.

Agile is most successful when teams finish features every day (or more often). The faster you finish a feature, the faster the team gets feedback on the feature. The more flexibility the product owners has to update/change the backlog for the team (either for flow or the next timebox). The teams do have to complete their work on a feature in a reasonable amount of time. If your cycle time gets too high, no one sees the flow of features. If you don’t get to done at the end of the iteration, you don’t get the benefit of agile. Teams need to learn how to get to done quickly on small features, so they can demo and get feedback on their progress.

What does this fast delivery/fast feedback cycle do for senior managers?

It allows senior managers to change their questions. Instead of “When will this be done?” or “How much will it cost?” senior managers can ask, “When will I see the first bit of value? Can we turn that value into revenue? When can we capitalize the work?”

Those questions change the way teams and senior management work together.

When teams do agile/lean, and they have a constant flow of features, managers don’t need “assurances” or “commitments to estimates” from the teams. Instead, the team estimates a much smaller chunk of work–time to first delivery value.

You might not know precisely when you can deliver that first value. But, as soon as the team works together if they understand agile/lean, they can create a reasonable estimate. They can update that estimate if necessary.

What else can teams do?

  • Work to a target. If the teams and the product owners know that management has a desired release date, they can work to it. Teams can track their feature flow through their systems, understanding their cycle time. They can use timeboxes for focus. They can measure how close to done they are with a product backlog burnup chart.
  • Demo as you proceed. Always demo to the product owners. Depending on the pressure for revenue/whatever, ask the senior managers to participate in the demo. That way, they can see the product’s progress as you add more features.
  • Keep the backlog item size small. It doesn’t matter how much is in the backlog if the size of every item is small. The smaller the backlog items, the easier it is for teams to estimate. It’s also easier for teams to maintain a flow of features into the ever-evolving system. Who knows? You might be done earlier than you expect.

With agile, you don’t have to set the strategy for a year, fund the projects, and expect that the projects will complete within that year. A year is a long time in almost every market. Managers might want the ability to change their strategy, and still get to a first “delivery of value” date.

Our metrics need to change. Cost to release or time to release is inadequate. They are inadequate because we can change the backlog at any time.

Instead, consider these metrics:

  • Time to release value: How long will it take us to release something for revenue? (The smaller the number, the better.)
  • Frequency of release: How often can we release? (The higher the frequency, the better.)
  • Run rate (What the team costs per unit time)
  • When you capitalize software. I will admit too much ignorance here to provide you guidance.

I have other measurement suggestions for programs in Organizing An Agile Program, Part 5: Measurements That Might Mean Something to a Program.

It’s not about #noestimates. It’s about which estimates your managers need. Managers have a fiduciary responsibility to the organization. You have the responsibility to release often, at least internally. The more often you release, the fewer time/cost estimates your managers need. The more your managers can take advantage of capitalizing software and what the software can do for the organization and the customers.

Your managers need estimates. And, they need to change the estimates they request. It’s all about your organization’s transition to agile.

Categories: Blogs

Pulse Roadmap Update

A little madness - Thu, 03/26/2015 - 05:30

Long time users of our Pulse Continuous Integration Server would know that we don’t believe in posting long-term roadmaps. They just never reflect a changing reality! But we have always been happy to discuss features with customers, including keeping our issue tracker (creaky old version of Jira that it is) completely open for all to see and contribute. In that spirit I’d like to talk a little about where we’re heading with Pulse in the near term, the bit that can be predicted, in a format more digestible than disparate issues.

The next version of Pulse (as yet unnamed), will have updates focused on a few areas:

  1. Upgrades of underlying libraries including Equinox, Spring, Spring Security, Hibernate, Jetty, Quartz, EhCache and more. If you haven’t seen a lot of visible changes reported recently this is why: these upgrades have occupied the first part of this development cycle. These are truly the most boring of all changes, which we hope you won’t notice directly at all! What you will notice, though, is a payoff of this strong foundation over time.
  2. Major updates to the administration interface. The interface works well enough at the moment but could be improved in a couple of key areas: discoverability and efficiency. Key goals for these updates include:

    • Improving the visibility of the most commonly-used configuration via overview pages.
    • Making it easier to discover what is overridden (via templating) and where.
    • More efficient navigation, especially through the template hierarchy.
    • Modernisation to take advantage of HTML 5 (which the current interface predates).

    These changes are big enough to warrant a dedicated blog post at a future point.

  3. Improved visibility of the build environment. When builds fail in curious ways the culprit is often a small difference in the environment. Pulse currently publishes environment information via implicit env.txt artifacts, but these haven’t kept up to date with the variety of options Pulse now gives for specifying build properties.
  4. Improvements to the Windows experience. In 2.7 work was done to improve Windows service support, but more could be done to streamline the setup process in particular.

As always we will also be working on dozens of smaller improvements and suggestions from our user base, most of which fall under one of:

  • UI polish, especially in the reporting interface.
  • Increased flexibility of project and build configuration.
  • Updated support for modern versions of build tooling.

Customers are more than welcome to connect with us via our support email, support forum, or issue tracker to discuss these and other changes you’d like to see in Pulse!

Categories: Companies

Python: matplotlib hangs and shows nothing (Mac OS X)

Mark Needham - Thu, 03/26/2015 - 02:02

I’ve been playing around with some of the matplotlib demos recently and discovered that simply copying one of the examples didn’t actually work for me.

I was following the bar chart example and had the following code:

import numpy as np
import matplotlib.pyplot as plt
 
N = 5
ind = np.arange(N)
fig, ax = plt.subplots()
menMeans = (20, 35, 30, 35, 27)
menStd =   (2, 3, 4, 1, 2)
width = 0.35       # the width of the bars
rects1 = ax.bar(ind, menMeans, width, color='r', yerr=menStd)
 
plt.show()

When I execute this script from the command line it just hangs and I don’t see anything at all.

Via a combination of different blog posts (which all suggested different things!) I ended up with the following variation of imports which seems to do the job:

import numpy as np
import matplotlib
matplotlib.use('TkAgg')
import matplotlib.pyplot as plt
 
N = 5
ind = np.arange(N)
fig, ax = plt.subplots()
menMeans = (20, 35, 30, 35, 27)
menStd =   (2, 3, 4, 1, 2)
width = 0.35       # the width of the bars
rects1 = ax.bar(ind, menMeans, width, color='r', yerr=menStd)
 
plt.show()

If I run this script a Python window pops up and contains the following image which is what I expected to happen in the first place!

2015 03 25 23 56 08

The thing to notice is that we’ve had to change the backend in order to use matplotlib from the shell:

With the TkAgg backend, which uses the Tkinter user interface toolkit, you can use matplotlib from an arbitrary non-gui python shell.

Current state: Wishing for ggplot!

Categories: Blogs

Unleash What’s Next

Rally Agile Blog - Wed, 03/25/2015 - 23:00

The world’s moving faster than ever, and as a partner to some of the most innovative companies in the world, Rally is at the forefront of change. We bring our world-class SaaS platform and the most experienced coaches and consultants in the industry to help customers navigate today’s challenges — including nimble competitors, changing markets, increasing regulation and faster cycles of innovation.  And like you, we too must adapt to change.

Rally has been a pioneer in Agile approaches, with Agile development software that revolutionizes the way companies across the globe accelerate software delivery. We have delivered countless scaled Agile solutions and led large-scale transformations across thousands of people and hundreds of teams, helping our customers to align software development with strategic business objectives and leverage agility across their organizations. Building agility is mission-critical in organizations today. It’s improving the way we work, learn, respond to change, innovate and win in the market.

Just as Rally has evolved, our brand must evolve to better reflect and communicate our expertise in helping organizations worldwide succeed on their Agile journeys.  As a result, you may notice that Rally looks a little bit different. We’re introducing a new logo that modernizes our look while staying connected to our Agile roots.

We have a new tagline, Unleash What’s Next, designed to better communicate what Rally software and services help customers achieve.

You’ll also see our name as Rally instead of Rally Software, because we are more than a software company: we’re a partner to our customers, helping them succeed on their path to agility.

Learn more about our refreshed brand, and how we work with our customers to help make them more successful, efficient, and productive, in this short video.

Our customers, partners, and employees have played a key role in shaping who Rally is today, and for that I thank all of you. Our employees continue to be the heart behind everything Rally does — I’m grateful to you, the Rally team, for taking this journey.

We’re excited about the future and look forward to continuing to innovate with you to step beyond the possibilities of today.

Tim Miller
Categories: Companies

JSHint: Confusing Use of ! (not)

Derick Bailey - new ThoughtStream - Wed, 03/25/2015 - 21:15

I ran in to this error a moment ago, produced by JSHint:

NewImage

The error says: Confusing use of ‘!’

That was certainly a new one to me… but after a moment of thought, it made sense. 

The Potential Confusion

Here’s the original code that I wrote, which produced this problem:

In this code, the potential confusion is not from the JavaScript runtime. Rather, it is potentially confusing from the developer’s perspective.

Does this code say “(not id) in ticket”, or is it saying “not (id in ticket)”?

If you know the order of precedence in JavaScript, this code says … well… I don’t know the order of precedence between the ! and “in” operators. I’m assuming it would evaluate to “not (id in ticket)” but I honestly don’t know.

A Less Confusing Version

Let’s clean this up so it’s less confusing.

In this version of the code, I’m explicitly grouping the “in” statement before running the “!” (not) statement. The code is significantly more clear, already. I also avoided the JSHint error, which is what my ultimate goal was in this case.

If I want to take this one more step, however, I can make the code even more clear.

In this version, I explicitly make the “in” check and assign it to a variable. Now my if statement is even easier to understand because I have given a name to the operation being performed. 

Naming A Concept

Reading “!hasId” is easier for our mind to parse and understand as “not has id”, than “not id in ticket”. We’ve given a name to the concept that is expressed in the code.

This form of abstraction (named variable representing an operation result) is the basis by which we understand everything around us. You don’t look at a bottle of water and think about chains of polycarbons, hydrogen atoms, etc. You think “bottle of water”.

Named abstractions are an important part of the way we think, and should be reflected in our code.

Of course this can go too far. Sometimes there isn’t a proper name for a line of code, and many times that line of code is already wrapped in a named function, which covers the concept.

Taking this idea too far is just as bad as not taking it far enough. The key is to find the balance where names are meaningful and representative of what’s going on, not just names for the sake of naming things.

 

 

 

P.S. If you’re interested in seeing how I set up and use JSHint, check out my WatchMeCode episode on using JSHint from Grunt.

 

 

Categories: Blogs

Knowledge Sharing


SpiraTeam is a agile application lifecycle management (ALM) system designed specifically for methodologies such as scrum, XP and Kanban.