Skip to content

Feed aggregator

Minimal Action Energy Principle in User Interface Design

TargetProcess - Edge of Chaos Blog - Thu, 07/16/2015 - 17:07

In physics there is an interesting fundamental principle: a system moves from one state to another using the minimal path, i.e. a path that demands the minimum energy.

Three_paths_from_A_to_B

When I read this, I immediately think about user interface design. Can we apply this principle to UI? It seems yes, since it is quite fundamental. I have never heard of attempts to use energy to evaluate efficiency of UI. This is the first try.

Let’s say, we have several interfaces that can transfer a user from state A to state B. Which one is the best? The Minimal Action Energy Principle in User Interface states:

From all available interfaces that transfer a user from state A to state B we should select the one with the minimum action energy.

So what is energy? That is a very tricky question, even in physics. But humans are more simple, so we can define all processes where we loose energy: clicking, taping, scrolling, looking/thinking, moving the mouse cursor, waiting, typing, asking for help, screaming, etc. A more complex thing is to unify these actions and have the same units for them to come up with a single energy number. After that we can compare energy of user interfaces and find the one with the minimal energy required to complete some action.

We can start with a simple model that will be good enough for the tests. We should introduce a unit to measure User Interface Action Energy. It can be yellow frogs, but let’s call it Action Units (au). All actions can be expressed via this unit:

1 click / tap = 1 au
1 scroll movement / wheel rotation = 2 au
1 second of thinking / looking = 3 au (thinking is hard)
1 second of cursor movement = 1 au
1 second of waiting = 0.5 au
1 second of typing = 2 au
1 second of asking for help = we fucked up

If I missed some interaction patterns let me know. Now we have a model to measure User Interface Action Energy. Note that energy is not equal to time. It means the user can actually spend more time with a system, but apply less energy to complete the tasks.

Let’s calculate User Interface Action Energy for a simple login action:

login_energy Looking at the form: 1
Click the email input field: 1
Recall your email: 1
Type the email: 3
Press Tab: 0.5
Recall the password: 2
Type the password: 3
Press Tab: 0.5
Realize it doesn’t highlight the login button: 6
Click the login button: 1
Wait 20 seconds to log in: 10
Total: 29 au

This decomposition makes it clear where we have energy leaks! Let’t fix it to spend less energy:

Looking at the form: 1
Click the email input field: 1 (This field should have the focus by default).
Recall your email: 1
Type the email: 3 (autocompletion can save some au)
Press Tab: 0.5
Recall the password: 2
Type the password: 3
Press Tab: 0.5
Realize it doesn’t highlight the login button: 6 (Tab navigation should work and highlight the button. Note that confusion causes a significant increase in the energy required to complete the scenario).
Push Enter to log in: 0.5
Wait 20 seconds to actually log in: 10 (Warm-up the application to reduce this time to 6 seconds that equals to 3 au)
Total: 13.5 au

This design is two times more efficient since it takes two times less energy to complete the task. Can we do even better? Yes, implement the Login scenario using the Facebook auto-fill button. This solution eliminates thinking completely.

1_login_500px_mini Looking at the form: 1
Click the Facebook button: 1
Wait: 3
Total 5 au

The absolute nirvana of UI is zero energy. You do nothing and authenticate. Is it possible? Yes, but it will compromise security. Is it possible to do that securely? For example, you navigate to an application, the device takes your picture, recognizes your live face (the photo should not work) and logs you in. You do nothing, but still wait for some seconds most likely. So total the Action Energy will be around 2 au.

Time != Energy

Usability testing is not new and clicks counting is not new. Usually we just measure the time to complete a task, observe bottlenecks and try to fix them. However, time should not be the ultimate measure of a user interface. Most likely, thinking is the most energy-heavy activity, so the best thing a designer can do is to remove thinking from the user interface as much as possible. Steve Krug was right. Some extra clicks might be OK if they reduce thinking about UI.

Moreover, a usability test doesn’t give you a breakthrough. You can find some leaks, confusions, etc., but to radically improve a solution you should think hard. When testing a basic login form you will not find a solution with the Facebook button. This solution evolves from other activities, like brainstorming, taking a shower, walking, etc.

The designer’s job is to think. The user’s job is to use the tool with ease.

Ideally, the designer should create several solutions, select the ones with a lower action energy and test them with real users to find the solution with the minimum action energy.

Automation

I think we can automate action energy measurements. Now we have quite advanced equipment to measure the eye movement, the heart rate, clicks, cursor movements, etc. In theory it is possible to create a software that will calculate User Interface Action Energy for every scenario automatically during live usability tests.

For remote usability tests where we have a limited access to a real person’s data we can measure action energy with a good approximation. Still it will be a more objective metric than just empirical observation.

TL; DR
  1. Estimate UI efficiency with User Interface Action Energy, not time or some empirical observations.
  2. Action energy includes all processes where the user looses energy like clicking, taping, scrolling, looking/thinking, moving the mouse cursor, waiting, typing, asking for help, screaming, etc.
  3. Create several solutions and test the most promising ones to calculate Action Energy. Find the solution with the minimal UIAE and it will be the most efficient one.
  4. Confusion, thinking and dead end routes are the main causes of energy leaks in UI.
Categories: Companies

New Video: Myths of Scrum – A Public Retrospective

Learn more about our Scrum and Agile training sessions on WorldMindware.com

Although subtle, having a public retrospective can do terrible damage to a Scrum team.  In this video I explain what I mean by “public”, why it is so bad, and what you should do instead.  This is part of a video series on the Myths of Scrum that is meant to respond to some of the most common mis-information (myths) about Scrum and Scrum practices.  I will follow-up this video in several weeks with a written article complimentary to this video.  Feel free to let me know in the comments if you have any topics that you would like me to cover in my video series!

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
facebooktwittergoogle_plusredditpinterestlinkedinmail

The post New Video: Myths of Scrum – A Public Retrospective appeared first on Agile Advice.

Categories: Blogs

Early Bird Ends 31 July for Agile on the Beach Conference

Scrum Expert - Thu, 07/16/2015 - 16:12
Early Bird ticket will end 31st July for the for Agile on the Beach conference that will take place in Falmouth, UK, September 3-4 2015. Early Bird Tickets are on sale for the conference and can be secured via eventbrite, capacity is currently at 90%. This year we are moving to a bigger venue. The Performance Centre is still based on Tremough Campus at the Penryn. This venue allows us to comfortably host all 350 attending. We will be having our pre-conference pasty and a drink gathering at the Performance ...
Categories: Communities

The One Thing You Must Do this Morning to Achieve Your Goals

Agile Management Blog - VersionOne - Thu, 07/16/2015 - 14:30

Goals

 

 

 

 

 

 

 

We all have goals, yet many of us don’t meet them. Sometimes this is disappointing, but more often than not the bar just kind of moves down, time passes, and we become complacent.

Why?

Because it is pretty tough to stay focused for long periods of time on “Big Hairy Audacious Goals”.

So what can you do to meet your goals?

Just like it doesn’t work to wait till the end of a release to power through the requirements in a traditional waterfall, it doesn’t work to wait till the end of the day to power through your tasks. Instead of powering out of the day, focus on powering into your morning.

I once heard a CEO tell his company a story to motivate them. It was January and the year was just kicking off. He said “If we want to meet our annual goals, we have to meet our quarterly goals. If we want to meet our quarterly goals, then we have to meet our monthly goals. In order to meet our monthly goals we have to meet our weekly goals, and to meet our weekly goals we have to win each day.” He said to forget everything else and just win the day. He then went on to explain the origin of the mantra.

If you follow college football, you may be familiar with the Oregon Duck’s mantra “Win the Day.” Most football coaches at whatever level preach about just focusing on the next game and not looking past it. When Chip Kelly began coaching at Oregon, he began preaching for players to just “win the day” because he believed the team needed to strive to win at every sprint, study session and scrimmage in order to win the next game.

This story and mantra resonated with my agile roots. Agile is rooted in focusing on the day to achieve the end goal. Agile’s foundation is built around not over planning to meet the final goal, but taking each day as it comes and responding accordingly. Stand-ups are all about teams winning the day.

Truthfully, as inspiring as this story was, I had come to forget about it till the other day when I was working out at the gym and listening to a podcast in which an author was discussing their book The Miracle Morning. The book is about six practices people can do every morning to be more productive, successful and happy. During the interview, the author started talking about the “how to win the day” mantra and how, if you want to win the day, you have to win the morning.

This snapped me out of my workout. On the surface, it would seem that the author just took something successful and took it one level down, but to me it was brilliant and once again aligned to my agile roots.

At work we are so often bombarded by firefighting that we fail to focus on our original goals or tasks. Agile, of course, employs story cards and stand-ups to combat these and other distractions. Most teams hold their stand-ups in the morning to kick the day off right.

Despite all of this, I had never thought about these practices being designed to help us win the morning so that we would win the day and ultimately win the end goal, but that is what they do. So, now I want to think about other things our teams can do first thing in the morning to ensure that we win the day – because to win the day, you have to win the morning.

Categories: Companies

Failure Modes of an Agile Transformation: Congruency

Rally Agile Blog - Thu, 07/16/2015 - 14:00

To this point, I’ve covered topics around failure in leadership and failure in workflow. It’s now time to dig a bit deeper into the question, “How does your organization “show up?” That is, “What’s the overall sense of how people take ownership for their behavior in the transformation?” What healthy alignments emerge among the teams? When a leader chooses to ignore the importance of behaviors and relationships, I refer to this as a failure in congruency.

What do I mean by congruency? To take a geometric perspective, envision polygons that have similarities in the number of sides; their angles also align with one another. In this, they are congruent. They can turn or flip or rotate and remain congruent. In fact, they need not be in the same location to have this attribute of congruency.

 (photo: Flickr CC)

In our human world, congruency evidences itself through changes in behaviors across the team. Congruent team members move away from a “yes/no” “black/white” “us/them” mentality. Congruent teams abide by norms in which pathological (yes I said pathological) behaviors are not acceptable, because relationships matter. The pathologies of blaming or placating are replaced with an emphasis on equal stature and equal voice. In environments of congruency, each member is heard, understood, and valued.  

Of the 12 failure modes in Agile transformation, consider failures 7, 8, and 9 as failures in congruency.

7. Lack of a Transformation Product Manager

Imagine your transformation as a product. The product you create is not one that is “in” your business; that is, it is not software or a service you would sell. Rather, this product is one that works “on” your business. As such, it requires the discipline we’d ascribe to product development. You need to identify a “Transformation Product Manager” to be your scout leader in delivering a high-quality transformation. Have this person work in a tight relationship with the executive owner of the transformation. Together, they define the disciplined exploration and execution to deliver a world-class transformation. And, together, they are the models of congruency among all players in the transformation. They define the value of our various team polygons: different but equal.

Using language from Virginia Satir, think of congruent teams as “family” systems in which the whole matters. As you move through the bumps of your Agile transformation, your Transformation Product Owner helps the teams be attentive to the incongruent behaviors that can eat away at the sense of “us” and “among”. What behaviors are creating distrust or lack of safety in your transformation? If you walk around your teams and notice tendencies toward blaming, placating, distracting, or being overly focused on process and structure , you are smack in the middle of incongruency. Ignore these harmful behaviors at your own risk.

All the process in the world is not going to move your Agile transformation into a healthy, sustainable state.

In a healthy world of Agile transformation, an intention around congruency emphasizes, “How can we better behave as a whole system to bring about the best results?” Here’s a start: ensure your Transformation Product Manager has the vision and empathy to recognize the destructive, incongruent behaviors. Next, ensure there is a non-negotiable value of trust — not just within a team, but across teams. Incongruency will evidence itself through “us/them” behaviors. Remove confusion about what we mean by product ownership. Incongruent Product Owners focus on “what’s in it for me” (WIIFM). There is a protectionist attitude about their particular backlog and the teams that work on them. Blaming becomes their primary communication mode.

 (photo: Flickr CC)

Congruent transformations breed new types of Product Owners, who let go of this pathology around defending their product and product teams. Instead, they engage in conversations like, “Given the value that this product brings and its projected cost and value, what’s best for the overall portfolio?”

Investing in a congruent transformation opens critical dialogue around:

  • How the transformation impacts behaviors as well as processes and structures
  • Clarity of transformation goals in teams and across teams
  • The health of teams where behaviors such as blaming and placating, or a focus primarily on process and hierarchy are recognized as detrimental to the transformation
  • Intentional decisions about consistency of behavior not just standards and practices around process and metrics
  • Supporting the benefits of congruency over enforced enforced behaviors
8. Failure to Create Fast Feedback

 (photo: Flickr CC)

Did you know that Sir Isaac Newton never had an apple fall on his head? He was, however, the father of the fundamental law of cause and effect. Little did he know the impact his physics would have on software development in the 21st century. Through the Industrial Age into the Age of Information, we’ve been clinging to cause and effect in how we build our organizations and how we expect them to work. {Link: Frederick Taylor} and [Link: Henry Ford] took advantage of this principle too. At its core, the assembly line uses cause and effect to create sequential, predictable, repeatable processes. Feedback loops on quality were less important or non-existent compared to how many items came off the line at any given point.

But where are we now? The nature of our knowledge work is inconsistent with the predictable, sequential work Newton helped foster. Yes, gravity still exists in a congruent world (well, at least in mine it does) but there’s much more going on. This is particularly true in an Agile transformation.

The forms we take, the behaviors we bring, the knowledge we carry all impact how we can stay in congruency. And that means we need to embrace regular learning as a core practice in our work.

How would you know that your Agile transformation remains largely informed by Newtonian physics? Think about these behaviors:

  • Clinging to a strict sense of predictability for when feature work will be completed
  • One centralized organization deciding all standards and rules for every team at the start of the transformation
  • Large-batch delivery of feature sets
  • Holding onto the belief that precision in analysis can resolve all risks in product delivery
  • Lack of experiments to test cause-and-effect assumptions about time, effort, and value
  • Blaming between business and development about delivery predictions and actual dates to support projected value
  • Blaming between development and testing about defects long after the features have been built

And finally, my favorite indicator of incongruent behavior:

  • Failure to get feedback through retrospectives, or the retrospectives that do occur perpetuate cause-and-effect fallacies and pathological behaviors (blaming, placating, etc.)

Fast feedback is the unspoken hero of congruency. We seek feedback on:

  • Guesses
  • Value
  • Behavior
  • Risk
  • Culture
  • Agile practices

In sum, healthy Agile transformations crave fast feedback on every aspect of how our the transformation is progressing. For this to occur, ensure you deliver feedback both ad-hoc and on a cadence, the latter being more formal and facilitated. The ad-hoc feedback reduces the waste of waiting for direction on very transactional decisions; the cadenced retrospectives ensure regular inspect-and-adapt sessions across the organization.

9. Short-changing Collaboration and Facilitation

We humans forming teams are constantly playing with the balance of how to be a team member and now to remain an individual. How can I speak up, be valued, and not have fear of recrimination while at the same time working toward the good of everyone? This is where some sense of congruency can help.

Recall that our congruent polygons are not identical. Rather, they hold similar characteristics such that you could recognize them as belonging to the same “polygon tribe.”

Can you say this about your teams? A few things occur when we inadequately support team interactions through facilitation and collaboration: we lose a sense of trust. Our teams end up fighting the gravitational pull of artificial harmony, low standards, and inattention to results, all due to a fundamental absence of trust. (See Patrick Lencioni’s The Five Dysfunctions of a Team to dig more into this pyramid of incongruent behaviors.)

Think about this: using Virginia Satir’s language, if we invite behaviors that gnaw away at the core fiber of a team, people move into modes of behaving that do not bring out their greatest insights. When this occurs, our dynamic is self-destructive. Why? Because we are only as smart as the least vocal person in a team.

How do we hold our insights dear and precious and necessary? We must seek a core team belief that collaboration makes us greater. And to collaborate, we recognize the value of objective facilitation. The work of the facilitator guides a team of individuals to decisions that integrate diverse perspectives in order to converge on actionable decisions. Good facilitators devote themselves to bringing out the best in the team. They do so by addressing incongruent behaviors and creating divergence and convergence processes, to safely buoy the team to sustainable decisions.

 (photo: Flickr CC)

Be clear with yourself and your teams. Collaboration does not mean groupthink, despite what people may infer. Rather, we are explicit and intentional about when to bring voices together for the greater good of the team. These voices can disagree. And we need them all so that we uncover risks, opportunities, puzzles, and surprises. Armed with this knowledge, teams can bring this caution into their commitment and move forward with their work.

Jean Tabaka
Categories: Companies

Helping others deal with conflict

Growing Agile - Thu, 07/16/2015 - 13:56
One of the sessions I attended at Agile 2014 by Tricia […]
Categories: Companies

5 Tips for Accelerated Learning

thekua.com@work - Thu, 07/16/2015 - 10:19

I spent all of last year in Berlin, where I focused on learning the German language. After years learning different programming languages like Java, C#, Javascript and Ruby (not to mention all the tools, frameworks and libraries) and several years training and teaching I figured I could “eat my own dog food” and apply what I learnt about learning to a real language.

Enter to Learn stone signStone sign: Enter to Learn. Image take from flikr under the Creative Commons licence.

Since that year, I talked to numerous people impressed that I can speak fluent German after living in Berlin. They often ask me, how did I found my experience. This post is a good summary of what I found myself repeating. Firstly, if you really, really want to learn German, Berlin is probably not the best place since there are so many foreigners living there and the level of spoken English is ridiculously high. You can easily fall into hanging out with the English-speaking crowd, enjoy the city, and fail to pick up more than rudimentary German.

Although I have very specific tips for learning the German language, this is more focused on what helped me learn the most that I think applies to any subject.

1. Find different teachers

At the start of the year, I spent the first three months doing an immersive language course at the Goethe Institute. Over the two classes, I experienced four different teachers, each with their own style and emphasis on what is important to learn. Although I wished that I had spent less time with one of the teachers, I found their point of view was sometimes useful. Each teacher focused on different aspects and it made my learning all that richer.

Over the rest of the year, I found other avenues to teach me, guide me and give the feedback I needed to grow. If I had stuck with a single teacher, I would have missed out on a number of other valuable perspectives.

2. Have a goal, and keep focused on it

Unlike many European people, I was never bilingual as a child. Moving to England from Australia, I came to appreciate how useful a second language was by meeting many other bilingual people. Although I learned Japanese in school, I believe it is more important to have the ability to use it.As they say:

Use it, or lose it.

A whole year to learn a language was a once in a lifetime opportunity and my goal was to be fluent by the end of the year. I had a whole bunch of other personal reasons to learn German, but figured many things came into alignment and I would make the most of this opportunity.

I reminded myself throughout the year about my goal, and why it was important to me, and it helped me keep focus on the learning. It helped me in particular when the going got tough, and it will get tough!

3. Celebrate progress

After a year passed by, I met with some of my colleagues again who were impressed that I could now speak with them fluently in their native tongue. Although it’s easy to celebrate that final result, there were many times along the way that I wanted to give up because it was hard, and I felt frustrated that I felt like I wasn’t learning as fast I wanted to.

I was sharing a flat with a German, who knew that I was wanting to speak fluent German. Although he could speak English very well, he spoke only to me in German even if it would have been easier for him to communicate in English. I remember coming home one day, exasperatedly asking, “Can we just speak in English?!” His answer, “Nein!” (No, in German).

Although there were bad days, there were also good days and I made sure to sit back and acknowledge these small milestones, such as watching my first film in German with subtitles (and understanding most of it), completing my first German novel, and going to the Town Hall to register myself without speaking a word of English!

Each small step moves you towards your final goal, and celebrating progress will help you overcome the learning hurdles you experience along the way.

4. Vary your learning activities

One problem with a long-term learning goal, is that you will get bored and distracted. At the start of my year, I was naturally doing a lot of grammatical textbook exercises which was useful for the classroom. However I couldn’t see myself continuing to do just these exercises for the rest of the year. I wanted other ways to learn but would help me keep engaged. Therefore I combined learning German with other activities that I enjoyed, such as meeting with people (the German Stammtisch the language school organised was a good one), watching movies and reading books I liked in German (thanks library!), meeting with a tandem partner, and listening to the radio.

A friend gave me the book, “111 Orte in Berlin, die man gesehen haben muss” which roughly translates to, “111 must see places in Berlin.” The book has two pages for each place, one with a short description and the other with a picture and was perfect for dipping in and out. I could read about a place I wanted to visit, and because I lived in Berlin, could go and see what it was talking about. At the same time, it helped me deepen my vocabulary and help me experience the unique experiences Berlin had of offer.

Later in the year, I spent some time traveling around in Germany, where I did a number of tours in German. Each of these experiences kept the learning alive for me and I never grew bored about “learning German” because I was doing it at the same time as I was doing other activities I was enjoying.

5. Accept you’ll never be perfect

Early on in my career, I discovered the idea of the Beginner’s Mind (Shoshin). For me, part of this accepts that I do not, and cannot know everything and that means there are new things to learn. In learning German, I found that my vocabulary will never be as rich as it is in English because there are situations I have never found myself in.

A good example of this was talking to a friend of mine when we first worked in a German-speaking office. She told me this story:

Although I studied German at school and was very fluent, I was shocked the first time that I was running a project kickoff for a German-speaking client. Not only was I learning new German words for the domain (transportation) but I was also learning new German words for technology terms I had taken for granted.

Our experiences shape who we are, and we cannot possibly be experts at everything, and that’s perfectly fine. I found it was more productive to focus on getting better than worrying about how close to mastery I was.

Conclusion

After years of coaching, teaching and training technology, I have many techniques that I consider useful as learning strategies. I found last year was a great opportunity to try applying some of them to a completely different skill and see how far I could go. Happily, it seemed to have worked.

I hope you found this article useful and that you will find these tips above useful. In summary, try to:

  1. Find different teachers
  2. Have a goal, and keep focused on it
  3. Celebrate progress
  4. Vary your learning activities
  5. Accept you’ll never be perfect

What other learning strategies do you find work for you?

Categories: Blogs

Neo4j: The football transfers graph

Mark Needham - Thu, 07/16/2015 - 08:40

Given we’re still in pre season transfer madness as far as European football is concerned I thought it’d be interesting to put together a football transfers graph to see whether there are any interesting insights to be had.

It took me a while to find an appropriate source but I eventually came across transfermarkt.co.uk which contains transfers going back at least as far as the start of the Premier League in 1992.

I wrote a quick Python script to create a CSV file of all the transfers. This is what the file looks like:

$ head -n 10 data/transfers.csv
player,from_team,from_team_id,to_team,to_team_id,fee,season
Martin Keown,Everton,29,Arsenal FC,11,"2,10 Mill. £",1992-1993
John Jensen,Bröndby IF,206,Arsenal FC,11,"1,12 Mill. £",1992-1993
Alan Miller,Birmingham,337,Arsenal FC,11,,1992-1993
Jim Will,Sheffield Utd.,350,Arsenal FC,11,,1992-1993
David Rocastle,Arsenal FC,11,Leeds,399,"1,68 Mill. £",1992-1993
Perry Groves,Arsenal FC,11,Southampton FC,180,595 Th. £,1992-1993
Ty Gooden,Arsenal FC,11,Wycombe Wand.,2805,?,1992-1993
Geraint Williams,Derby,22,Ipswich Town,677,525 Th. £,1992-1993
Jason Winters,Chelsea U21,9250,Ipswich Town,677,?,1992-1993

I’m going to create the following graph and then we’ll write some queries which explore chains of transfers involving players and clubs.

2015 07 15 07 28 11

I wrote a few import scripts using Neo4j’s LOAD CSV command, having set up the appropriate indexes first:

create index on :Team(id);
create index on :Season(name);
create index on :Transfer(description);
create index on :Player(name);
// teams
load csv with headers from "file:///Users/markneedham/projects/football-transfers/data/teams.csv" as row
merge (team:Team {id: toint(row.team_id)})
on create set team.name = row.team;
 
// seasons
load csv with headers from "file:///Users/markneedham/projects/football-transfers/data/transfers.csv" as row
merge (season:Season {name: row.season})
ON CREATE SET season.starts =  toint(split(season.name, "-")[0]);
 
// players
load csv with headers from "file:///Users/markneedham/projects/football-transfers/data/transfers.csv" as row
merge (player:Player {name: row.player});
 
// transfers
load csv with headers from "file:///Users/markneedham/projects/football-transfers/data/transfers.csv" as row
match (from:Team {id: toint(row.from_team_id)})
match (to:Team {id: toint(row.to_team_id)})
match (season:Season {name: row.season})
match (player:Player {name: row.player})
 
merge (transfer:Transfer {description: row.player + " from " + from.name + " to " + to.name})
merge (transfer)-[:FROM_TEAM]->(from)
merge (transfer)-[:TO_TEAM]->(to)
merge (transfer)-[:IN_SEASON]->(season)
merge (transfer)-[:PLAYER]->(player);
 
// connect transfers
match (season)<-[:IN_SEASON]-(transfer:Transfer)-[:PLAYER]->(player)
WITH player, season, transfer
ORDER BY player.name, season.starts
WITH player, COLLECT({s: season, t: transfer}) AS transfers
UNWIND range(0, length(transfers)-2) AS idx
WITH player, transfers[idx] AS t1, transfers[idx +1] AS t2
WITH player, t1.t AS t1, t2.t AS t2
MERGE (t1)-[:NEXT]->(t2);

All the files and scripts are on this gist if you want to play around with the data. The only thing you’ll need to change is the file path on each of the ‘LOAD CSV’ lines.

The ‘connect transfers’ query is a bit more complicated than the others – in that one we’re first ordering the transfers in ascending order grouped by player and then creating a linked list of a player’s transfers.

Now that we’ve got the data loaded let’s find out which player was transferred the most:

match path = (:Transfer)-[:NEXT*0..]->(transfer:Transfer)
where NOT (transfer)-[:NEXT]->()
RETURN path 
ORDER BY LENGTH(path) DESC
LIMIT 1
Graph  22

Which other players have moved teams frequently?

match path = (first:Transfer)-[:NEXT*0..]->(transfer:Transfer),
             (player)<-[:PLAYER]-(transfer)
where NOT ((transfer)-[:NEXT]->()) AND NOT ((first)<-[:NEXT]-())
RETURN player.name, LENGTH(path) AS numberOfTransfers 
ORDER BY numberOfTransfers DESC
LIMIT 10
 
==> +--------------------------------------+
==> | player.name      | numberOfTransfers |
==> +--------------------------------------+
==> | "Craig Bellamy"  | 7                 |
==> | "David Unsworth" | 6                 |
==> | "Andrew Cole"    | 6                 |
==> | "Peter Crouch"   | 6                 |
==> | "Les Ferdinand"  | 5                 |
==> | "Kevin Phillips" | 5                 |
==> | "Mark Hughes"    | 5                 |
==> | "Tommy Wright"   | 4                 |
==> | "Carl Tiler"     | 4                 |
==> | "Don Hutchison"  | 4                 |
==> +--------------------------------------+
==> 10 rows

What are the most frequent combinations of clubs involved in transfers?

match (from)<-[:FROM_TEAM]-(t:Transfer)-[:TO_TEAM]->(to), (t)-[:PLAYER]->(p)
RETURN from.name, to.name, COUNT(*) AS times, COLLECT(p.name) AS players
ORDER BY times DESC
LIMIT 10
 
==> +------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
==> | from.name           | to.name               | times | players                                                                                                                                                                                                    |
==> +------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
==> | "West Ham United"   | "Queens Park Rangers" | 13    | ["Keith Rowland","Iain Dowie","Tim Breacker","Ludek Miklosko","Bertie Brayley","Terrell Forbes","Steve Lomas","Hogan Ephraim","Nigel Quashie","Danny Gabbidon","Kieron Dyer","Robert Green","Gary O'Neil"] |
==> | "Tottenham Hotspur" | "Portsmouth FC"       | 12    | ["Paul Walsh","Andy Turner","Rory Allen","Justin Edinburgh","Tim Sherwood","Teddy Sheringham","Noé Pamarot","Pedro Mendes","Sean Davis","Jermain Defoe","Younès Kaboul","Kevin-Prince Boateng"]            |
==> | "Liverpool FC"      | "West Ham United"     | 12    | ["Julian Dicks","David Burrows","Mike Marsh","Don Hutchison","Neil Ruddock","Titi Camara","Rob Jones","Rigobert Song","Craig Bellamy","Joe Cole","Andy Carroll","Stewart Downing"]                         |
==> | "Manchester United" | "Everton FC"          | 9     | ["Andrey Kanchelskis","John O'Kane","Jesper Blomqvist","Phil Neville","Tim Howard","Louis Saha","Darron Gibson","Sam Byrne","Tom Cleverley"]                                                               |
==> | "Newcastle United"  | "West Ham United"     | 9     | ["Paul Kitson","Shaka Hislop","Stuart Pearce","Wayne Quinn","Lee Bowyer","Kieron Dyer","Scott Parker","Nolberto Solano","Kevin Nolan"]                                                                     |
==> | "Blackburn Rovers"  | "Leicester City"      | 9     | ["Steve Agnew","Tim Flowers","Callum Davidson","John Curtis","Keith Gillespie","Craig Hignett","Nils-Eric Johansson","Bruno Berner","Paul Gallagher"]                                                      |
==> | "Chelsea FC"        | "Southampton FC"      | 8     | ["Ken Monkou","Kerry Dixon","Neil Shipperley","Mark Hughes","Paul Hughes","Graeme Le Saux","Jack Cork","Ryan Bertrand"]                                                                                    |
==> | "Birmingham City"   | "Coventry City"       | 8     | ["David Rennie","John Gayle","Liam Daish","Gary Breen","Stern John","Julian Gray","Lee Carsley","Gary McSheffrey"]                                                                                         |
==> | "Southampton FC"    | "Fulham FC"           | 8     | ["Micky Adams","Kevin Moore","Terry Hurlock","Maik Taylor","Alan Neilson","Luís Boa Morte","Antti Niemi","Chris Baird"]                                                                                    |
==> | "Portsmouth FC"     | "Stoke City"          | 8     | ["Kevin Harper","Lewis Buxton","Anthony Pulis","Vincent Péricard","Asmir Begovic","Marc Wilson","Elliot Wheeler","Alex Grant"]                                                                             |
==> +------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
==> 10 rows

Are there ever situations where players get transferred in both directions?

match (from)<-[:FROM_TEAM]-(t:Transfer)-[:TO_TEAM]->(to), (t)-[:PLAYER]->(player)
where id(from) < id(to)
WITH from, to, COUNT(*) AS times, COLLECT(player.name) AS players
match (to)<-[:FROM_TEAM]-(t:Transfer)-[:TO_TEAM]->(from), (t)-[:PLAYER]->(player)
RETURN from.name, to.name, times, COUNT(*) as otherWayTimes, players, COLLECT(player.name) AS otherWayPlayers
ORDER BY times + otherWayTimes DESC
LIMIT 10
 
==> +-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
==> | from.name           | to.name               | times | otherWayTimes | players                                                                                                                                                                                                    | otherWayPlayers                                                                                                                                                                    |
==> +-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
==> | "Tottenham Hotspur" | "Portsmouth FC"       | 12    | 5             | ["Paul Walsh","Andy Turner","Rory Allen","Justin Edinburgh","Tim Sherwood","Teddy Sheringham","Noé Pamarot","Pedro Mendes","Sean Davis","Jermain Defoe","Younès Kaboul","Kevin-Prince Boateng"]            | ["Jermain Defoe","Niko Kranjcar","Younès Kaboul","Peter Crouch","Darren Anderton"]                                                                                                 |
==> | "West Ham United"   | "Liverpool FC"        | 4     | 12            | ["Julian Dicks","Daniel Sjölund","Yossi Benayoun","Javier Mascherano"]                                                                                                                                     | ["Stewart Downing","Andy Carroll","Joe Cole","Craig Bellamy","Rigobert Song","Titi Camara","Rob Jones","Neil Ruddock","Don Hutchison","Julian Dicks","Mike Marsh","David Burrows"] |
==> | "West Ham United"   | "Queens Park Rangers" | 13    | 2             | ["Keith Rowland","Iain Dowie","Tim Breacker","Ludek Miklosko","Bertie Brayley","Terrell Forbes","Steve Lomas","Hogan Ephraim","Nigel Quashie","Danny Gabbidon","Kieron Dyer","Robert Green","Gary O'Neil"] | ["Andy Impey","Trevor Sinclair"]                                                                                                                                                   |
==> | "West Ham United"   | "Tottenham Hotspur"   | 5     | 8             | ["Jermain Defoe","Frédéric Kanouté","Michael Carrick","Jimmy Walker","Scott Parker"]                                                                                                                       | ["Sergiy Rebrov","Mauricio Taricco","Calum Davenport","Les Ferdinand","Matthew Etherington","Bobby Zamora","Ilie Dumitrescu","Mark Robson"]                                        |
==> | "West Ham United"   | "Portsmouth FC"       | 8     | 5             | ["Martin Allen","Adrian Whitbread","Marc Keller","Svetoslav Todorov","Hayden Foxe","Shaka Hislop","Sébastien Schemmel","Hayden Mullins"]                                                                   | ["Stephen Henderson","Teddy Sheringham","Shaka Hislop","Marc Keller","Lee Chapman"]                                                                                                |
==> | "Newcastle United"  | "West Ham United"     | 9     | 3             | ["Paul Kitson","Shaka Hislop","Stuart Pearce","Wayne Quinn","Lee Bowyer","Kieron Dyer","Scott Parker","Nolberto Solano","Kevin Nolan"]                                                                     | ["Demba Ba","Lee Bowyer","David Terrier"]                                                                                                                                          |
==> | "Birmingham City"   | "Coventry City"       | 8     | 4             | ["David Rennie","John Gayle","Liam Daish","Gary Breen","Stern John","Julian Gray","Lee Carsley","Gary McSheffrey"]                                                                                         | ["Scott Dann","David Burrows","Peter Ndlovu","David Smith"]                                                                                                                        |
==> | "Manchester City"   | "Portsmouth FC"       | 8     | 4             | ["Paul Walsh","Carl Griffiths","Fitzroy Simpson","Eyal Berkovic","David James","Andrew Cole","Sylvain Distin","Tal Ben Haim"]                                                                              | ["Benjani","Gerry Creaney","Kit Symons","Paul Walsh"]                                                                                                                              |
==> | "Blackburn Rovers"  | "Southampton FC"      | 5     | 6             | ["David Speedie","Stuart Ripley","James Beattie","Kevin Davies","Zak Jones"]                                                                                                                               | ["Zak Jones","Egil Östenstad","Kevin Davies","Alan Shearer","Jeff Kenna","Tim Flowers"]                                                                                            |
==> | "AFC Bournemouth"   | "West Ham United"     | 3     | 8             | ["Keith Rowland","Paul Mitchell","Scott Mean"]                                                                                                                                                             | ["Steve Jones","Matt Holland","Mohammed Berthé","Scott Mean","Paul Mitchell","Jamie Victory","Mark Watson","Stephen Purches"]                                                      |
==> +-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

Any players who go back to the same club they were at previously?

match (player:Player)<-[:PLAYER]-(t1:Transfer)-[:FROM_TEAM]->(from)<-[:TO_TEAM]-(t2:Transfer)-[:FROM_TEAM]->(to),
      (t2)-[:PLAYER]->(player), (t1)-[:TO_TEAM]->(to)
WHERE ID(to) < ID(from)
WITH player, COLLECT([ from.name, " ⥄ ", to.name]) AS teams
RETURN player.name, 
       REDUCE(acc = [], item in teams | acc  + REDUCE(acc2 = "", i in item | acc2 + i)) AS thereAndBack
ORDER BY LENGTH(thereAndBack) DESC
LIMIT 10
 
==> +-------------------------------------------------------------------------------------+
==> | player.name       | thereAndBack                                                    |
==> +-------------------------------------------------------------------------------------+
==> | "Mark Stein"      | ["Stoke City ⥄ Chelsea FC","Ipswich Town ⥄ Chelsea FC"]         |
==> | "Peter Beagrie"   | ["Bradford City ⥄ Everton FC","Bradford City ⥄ Wigan Athletic"] |
==> | "Richard Dryden"  | ["Southampton FC ⥄ Stoke City","Southampton FC ⥄ Swindon Town"] |
==> | "Robbie Elliott"  | ["Bolton Wanderers ⥄ Newcastle United"]                         |
==> | "Elliot Grandin"  | ["Blackpool FC ⥄ Crystal Palace"]                               |
==> | "Robert Fleck"    | ["Chelsea FC ⥄ Norwich City"]                                   |
==> | "Paul Walsh"      | ["Portsmouth FC ⥄ Manchester City"]                             |
==> | "Rick Holden"     | ["Manchester City ⥄ Oldham Athletic"]                           |
==> | "Gary McAllister" | ["Liverpool FC ⥄ Coventry City"]                                |
==> | "Lee Bowyer"      | ["West Ham United ⥄ Newcastle United"]                          |
==> +-------------------------------------------------------------------------------------+

That’s all I’ve got for now – if you can think of any other interesting avenues to explore let me know and I’ll take a look.

Categories: Blogs

Enterprise Services Planning Management Summit

A new conference! A new format! A new movement! London 28 September

The Enterprise Services Planning Management Summit is designed for managers in all types of professional services to come together and share their challenges managing modern 21st Century business in a complex world of disruptive change and ever shifting customer demands and expectations.

read more

Categories: Companies

Team Kanban Practitioner

Lean Kanban University is introducing a new entry level Kanban class for Team Kanban together with a certification and professional credential, TKP, Team Kanban Practitioner. This new class becomes the entry level on the "alternative path to agility" and reflects the market reality that most Kanban starts shallow and at the team level.

read more

Categories: Companies

Kanban - the alternative path to agility

The Kanban Method was conceived as an alternative path to agility - as a means to improve responsiveness and adaptability without any significant revolution or reorganization in your way or working or political structure of your business. Lean Kanban University has recently introduced a series of training classes developed and evolved from older, tried and tested curriculum to ease adoption of Kanban and communicate the full scope and scale of what is possible when you fully embrace Kanban as a way to manage your modern professional services business.

read more

Categories: Companies

Pitfall of Scrum: Problem-Solving in the Daily Scrum

Learn more about our Scrum and Agile training sessions on WorldMindware.com

The Daily Scrum should not be used to find solutions to problems (obstacles, impediments) raised. Instead, keep the meeting very short and have those problem-solving conversations afterwards with only those who are interested. The ScrumMaster facilitates this meeting to keep it on track. The Daily Scrum is timeboxed to a maximum of 15 minutes, but often should be even less. With a good physical task board, a Daily Scrum can often be done in less than a minute simply by each team member pointing at the pieces of work they are working on.

From the Scrum Guide:

The Development Team or team members often meet immediately after the Daily Scrum for detailed discussions, or to adapt, or replan, the rest of the Sprint’s work.

In other words, don’t have those discussions during the Daily Scrum! The Daily Scrum is essential to creating transparency and implementing the Scrum value of Openness. The three questions of the Daily Scrum are effectively:

  1. What did I do since the last time we checked in as a team?
  2. What am I planning to do before the next check in time?
  3. What impediments, if any, are preventing us from getting our work done?

Each member of the team takes a turn and answers those three questions. This doesn’t have to be completely stilted, but it should be Focused (another value of Scrum) and efficient so that the need for other meetings is minimized. Accomplishing this takes some practice. The ScrumMaster helps the team to keep the timebox, but at first, a team might have challenges with this.

Struggling with the Daily Scrum

There are a some common reasons that a team might struggle with wanting to problem solve in the Daily Scrum:

  • One team member doesn’t know what to do next and it devolves into re-planning right there and then. A quick suggestion or two is probably fine, but it is a very steep slippery slope. A team can easily get into the habit of always doing this! The ScrumMaster needs to be vigilant about recommending that the discussion be taken up after the Daily Scrum is concluded in order to avoid this pitfall. This suggestion will be common when a team is first starting out.
  • One person mentions an impediment that someone else knows how to solve… and a third person has a different idea of solving it. In this situation it is much better for interested team members to just simply indicate “I have an idea for that,” and let the Daily Scrum continue. Then after the Daily Scrum those people have a quick discussion. This avoids wasting the time of everyone on the team with something that is only interesting to a few.
  • An individual doesn’t seem to have anything to report and other team members try to elicit more information. This should really be something that the ScrumMaster or the team’s coach should take up with the individual. It may be that there is an impediment that the person is uncomfortable sharing openly with the whole team. There is a subtle pitfall that may be revealed here: that the team does not have the safety to self-organize.
  • Disagreement about what to do next. This type of problem is the hardest to deal with because many people will feel that disagreements need to be resolved before any action can be taken. A good ScrumMaster will actually encourage competing ideas to be attempted. Learn by doing instead of by argument and analysis. This is the fundamental shift in culture that Scrum is attempting to put in place: an empirical approach to work rather than a defined approach.

Just beware: yet another pitfall (although not common) is to decide that the Daily Scrum shouldn’t be daily because it is taking so long. Unfortunately, making this change will often just make the meetings even longer until they devolve back into weekly status meetings reporting to the team lead!!! Remember that it’s not Scrum anymore if your team doesn’t meet together daily.

Ultimately, if a team is struggling with the Daily Scrum in any way, this is a valid topic for discussion in the Sprint Retrospective.

This article is a follow-up article to the 24 Common Scrum Pitfalls written back in 2011.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
facebooktwittergoogle_plusredditpinterestlinkedinmail

The post Pitfall of Scrum: Problem-Solving in the Daily Scrum appeared first on Agile Advice.

Categories: Blogs

You Asked, the Agile Aficionados Answered

Rally Agile Blog - Wed, 07/15/2015 - 14:00

Getting onboard with Agile methods across your organization is no small task. To do it well requires knowledge, culture change, and practice — lots of practice — at all levels.

Rally is fortunate to have some of the most experienced practitioners in the industry. Their broad experience working onsite with customers and their deep knowledge of Agile practices, organizational culture, and human behavior only excites in them a deeper curiosity and eagerness to learn. As you can imagine, this makes them great advice-givers and storytellers!

Recently we assembled a few of these Agile aficionados (Agile Coach Tamara Nation, Transformation Consultant Eric Willeke, and Services Product Manager Ronica Roth) to respond to some of your toughest Agile questions with their advice and stories. You can listen to the whole terrific webcast of their conversation here, but below we share a few things we learned from their chat.

You Can’t Innovate Until You Can Execute

ERIC: A lot of the language I'm hearing with executives and business partners around the IT industry is all about, “We need to innovate more. We need to do more of this, more of that.” I fear that people are losing sight of the need to actually be able to implement those ideas and operate the businesses effectively once those innovations are brought to market. A lot of the focus I help organizations drive early in their transformation is to stabilize your implementation capability. Stabilize that execution organization that's able to build those new ideas, able to bring them to market. Then use that as the base from which to start to launch innovation and start to disrupt the markets you're in, and move the business in the places you want to go.

TAMARA: I see a similar trend, especially when I'm working with really large organizations that have organizationally institutionalized impediments. You know those silos that we're always talking about? I feel like I've been in a lot of conversations recently where IT and development folks are pointing the fingers at “the business” … when, really, we need to be able to deliver predictably. We need to be able to deliver quality products.

Agile Ops: Upfront Architecture or Emergent Design?

ERIC: At least in my mind, the real purpose of architecture is to ensure that an organization is in a position to take care of future opportunities, be ready to seize those and have the technical infrastructure, the technical platforms to put the company where it needs to be in the future.

One of the things that architects need to be good at is the capability to see around the corners, to anticipate that beyond the current need, beyond what we're building now, what are we going to be faced with on this platform, and in this environment, and in this market in the future?

Sometimes that means overinvesting in flexibility early in a platform. Sometimes that means closing a platform so that you can milk every last penny out of it at the lowest operational cost. But first and foremost, it's to help take those needs and convey them into the organization in a form that allows you to articulate the trade-offs and steer the decisions that need to be made by the teams moment to moment.

The flipside of that, and this is where the emergent architecture aspect and emergent design aspect comes from, is most architecture groups can't move at the speed of development.

Once you achieve that execution engine, once you have a development organization that can push out high quality software week after week, quarter after quarter, nobody can predictably say, "Here's what design you need." We want to ensure that the development organization always has a direction that they can go that they know they can implement at full speed and not cause things to break, not go off the rails and cause huge operational costs or poor flexibility or challenges down the line. That is the tension and the balance that we're looking at when we talk about the intersection of intentional architecture and emergent design.

A lot of the ideas around service-oriented architecture and now the DevOps microservices mindset are really taking balance and pushing it to the extreme where it's in smaller and smaller groups that have both skill sets and both mindsets and decentralizing that decision-making around architecture. It's a continuum, but it's also a very careful balancing of those two forces of predicting the future and moving at full speed today.

TAMARA: I think the other thing I look for, Eric, is, can we start to build a group of people who can make good architectural decisions? I 100 percent agree with that paradigm. It's really systems thinking. How can we set up an environment where our teams can be successful? What are the guardrails? What are the performance ‘ilities’? What are the things that this system needs to be able to do and how can I create architects of the future, for instance? How do we have that architectural skill set in each of our Agile teams?

ERIC: I like what you said there, Tamara, because it really indicates that we all think that we're past the day of fire-and-forget architectures. It's no longer at a point where you can define "the architecture" and then move on with life. The people need to be embedded. They need to be engaged throughout the development process and probably into the operations stage of any major platform. It's not an up-front activity by any means anymore.

How Big Room Planning Pays for Itself

RONICA: I know you guys have seen the release planning or big room planning where we bring everyone in a delivery group or release train together to plan a quarter's worth of work. What are some experiences you guys have had recently where that event has had a radical impact on a group's ability to execute, or what resistance have you seen?

TAMARA: I think the number one piece of resistance I see is about, "Well, I can't afford it, we're too busy. People need to keep working, so I can't possibly get everyone together to do this big planning exercise." This first time is scary because the upfront investment looks big. The downstream benefit's harder to see until you've actually executed the event.

ERIC: The same thing for me. Cost, cost, and cost are always the first, second, and third complaints. Generally it's travel costs, followed by the cost of the time of the people, and then the cost of distraction and planning are the three types of costs that I hear people concerned about.

TAMARA: Have I ever seen a time where bringing everyone together and talking about our work and our priorities didn't yield a significant either cost savings or we were able to see a risk and mitigate it earlier in the process? I can think of one example with a particular Salesforce implementation. That's a lot of configuration, those types of implementations. They realized, "Oh, we're configuring the exact wrong module. [laughs] We'll never use that one, so why waste our time doing that?" That was $100K savings from a real quick conversation. I saw it happen in front of me. I don't think you could even monetize the value from bringing those people together.

ERIC: I don't think I've ever seen one where there wasn't at least one directly attributable learning or discovery that didn't pay for the cost of the event in terms of travel and logistics and everything else. That doesn't even include the real outcome of the big-room planning, which is to create an organization and a group that's ready to deliver that plan. Like the classic saying that "planning is invaluable, the plan itself useless." These groups come together and the people that are excluded, in my experience, you can noticeably see over the next 10 to 12 weeks that they're at a distinct disadvantage in their ability to contribute compared to the people that were in the room.

Planning and Continuous Delivery Are Not Mutually Exclusive

RONICA: Why a release train and a continuous delivery model? If we're doing continuous delivery, why do this by quarterly plan, that look-ahead?

TAMARA: The whole planning event is designed around, What should we be working on? What's the next right thing to do, and what do we need to know to get that done?

ERIC: Yeah. A lot of us, I think, recently, have been reading Patrick Lencioni's new book, The Advantage. In all of his language about organizational help, he really drives those four principles all back to clarity and providing intense clarity among the organization about, What are the goals and how are we going to accomplish them? Beyond what that book offers, the big room plan, to me, is such an amazing opportunity to get a much larger group than you normally would be able to enrolled into the same clarity of intent that at least we're all operating off the same view of reality. We believe we're all moving to the same direction. Sharing that clarity and sharing that alignment is so powerful for the day-to-day execution that needs to follow starting, generally, the day after planning, like the Monday after planning.

TAMARA: The continuous delivery is an important part of that. Things are moving quickly, the pace and people's expectations on our ability to deliver new things, respond to changes, and fix defects. I was listening to a story from one our colleagues in China about how he submitted a defect through Twitter — the Chinese equivalent of Twitter. He got a response within four hours that they'd received the defect, and he got a notification 10 hours later that it was fixed. I thought, "Wow." Once things are identified, we know that's a priority and respond quickly, that's what continuous delivery's all about.

ERIC: it's so critical for people to remember that, yes, there are still enterprises that are in an annual delivery cycle and maybe a twice-a-year delivery cycle. Something like SAFe and the midrange planning helps them get down to a 10-week cycle. But I think it's gotten to the point where we all assume, of course you're going to deliver faster than that if you can and it makes sense for your business. We forget to say, "No, there's nothing that limits you to deliver once a quarter. There's nothing in SAFe or any of the other larger scaling models that say you can only deliver in your planning boundaries." I know multiple companies that have gotten down to where they can essentially deliver on-demand whenever they have something worth delivering. They do that within the construct of SAFe. They do that as part of their normal sprint planning, is to say, "Yeah, I can create this feature, and this feature will be done. We'll get them through this cycle, and let's go and share those next Thursday, before the end of the sprint."

Agile Metrics: What to Measure, What to Ignore

RONICA: Of course, there are two sides to metrics. One is, How do we measure success of the Agile adoption? Then, of course, there is, What are the good Agile metrics that help us know whether our projects or programs or delivery groups are being successful? What metrics might you suggest avoiding? Talk to me about some of your favorite measures.

TAMARA: I think about cycle time and lead time as the most important metric, because it's going to touch all parts of your business. If you have a really good understanding of how long something takes from the time somebody has an idea or submits a defect, to when you can get that idea into production, that's going to help you uncover all of the different areas where you have bottlenecks, where there are transparency issues inside of your organization.

Interestingly enough, I don't know if Eric's at this place, in terms of Agile adoption metrics, I talk about that a lot less, because I feel like Agile's really crossed...it's crossed the chasm. I'm a little less concerned about their adoption and more on whether there's real, tangible business impacts we're having.

ERIC: Yeah, I've actually taken, maybe, even a step further beyond that and I'm at the point of saying, "I actively discourage centers of excellence and transformation coalitions from having percent-of-adoption type metrics." I find if you start to look at something like the percent of teams that have adopted Scrum or something like that, you actually drive worse behaviors in the organization once you hit a certain tipping point. Because the push is to get people to where you can give them the stamp of Scrum approval or the stamp of, "This team is Agile," rather than focusing on the improvement journey or the business impact that's so much more valuable.

The first-order metric I'm usually looking at is lead time, from an execution perspective: what's the impact? Is it reflected in the share prices? Is it reflected in the large business programs that are using Agile techniques to show more capability and more market presence than the ones who aren't? Then work back to, "What are the factors that drive it?" I think sustainable shortest lead time is a huge, almost number-one goal to get that feature delivery and then cycle from idea identification, opportunity identification, all the way through to business implementation and revenue recognition and can you shrink that time.

That gives you the ability to respond to the market faster. That gives you the ability to learn faster. Then once you get inside of that, almost every metric I use is situational. Is it indicative of a specific impediment or bottleneck that we're trying to resolve in an organization? If so, let's wrap some evidence around it and find the right metric that illustrates what we're trying to do and brings the impact of the problems to some sort of visibility, work to resolve it. Then keep capturing the data.

TAMARA: I feel that there is an addiction to metrics inside of organizations, particularly technologies companies where they feel like, "We're sitting on all this data. We should be able to have really great metrics." I feel like I see so many executives really locked into their red, yellow, green dashboards and that's what they're using to sense and understand where their business is...it's such a temptation to fall back into, "I want the cold, hard facts. I want the numbers," when we all know that metrics can be shaded in either direction.

ERIC: I had a senior leader who has, roughly, 35 teams under his purview. A month or two ago he actually came out to Rally and visited our steering. But while he was in town he actually hung out with two of his development teams that were located in another office. He just took the teams to lunch. None of the management in the middle was present. There was probably a two- or three-layer power gap. He just went to lunch and he came away with a very different understanding and perspective over what some of the relationship challenges were among different parts of the organization. None of that ever finds its way up through the reports or the PowerPoint decks or the executive status boards or anything else that you're going to run into.

Listen to the whole conversation, and sign up for our August webinar, “Next Level Agile,” with Rally VP of Products Ryan Polk.

Rally
Categories: Companies

Python: UnicodeDecodeError: ‘ascii’ codec can’t decode byte 0xe2 in position 0: ordinal not in range(128)

Mark Needham - Wed, 07/15/2015 - 08:20

I was recently doing some text scrubbing and had difficulty working out how to remove the ‘†’ character from strings.

e.g. I had a string like this:

>>> u'foo †'
u'foo \u2020'

I wanted to get rid of the ‘†’ character and then strip any trailing spaces so I’d end up with the string ‘foo’. I tried to do this in one call to ‘replace':

>>> u'foo †'.replace(" †", "")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 1: ordinal not in range(128)

It took me a while to work out that “† ” was being treated as ASCII rather than UTF-8. Let’s fix that:

>>> u'foo †'.replace(u' †', "")
u'foo'

I think the following call to unicode, which I’ve written about before, is equivalent:

>>> u'foo †'.replace(unicode(' †', "utf-8"), "")
u'foo'

Now back to the scrubbing!

Categories: Blogs

Does This Fizz Good?

FSGD (pronounced Fizz Good) is a thinking tool that LeanKit created to shape how we plan our work to get things done and provide value to our customers faster. FSGD is an acronym comprised of four equal parts: Frequent, Small, Good, and Decoupled. We think of it as simply a concise restatement of Lean principles, […]

The post Does This Fizz Good? appeared first on Blog | LeanKit.

Categories: Companies

VersionOne Partners With Blue Agility on SAFe

Scrum Expert - Tue, 07/14/2015 - 18:56
Blue Agility and VersionOne have partnered to help companies drive business agility and transformation at scale. This partnership will help address a growing market need: empowering organizations to reap the benefits of agility at the enterprise level using proven techniques and methodologies, including the Scaled Agile Framework® (SAFe®). Blue Agility has a wealth of experience and successful track record leveraging SAFe to better align IT with business and significantly improve product development lead times for their client base. VersionOne solutions provide seamless technology support for SAFe, with a particular focus on ...
Categories: Communities

New Webinar: DevOps, SAFe and the Path to Better Agile Development

Agile Product Owner - Tue, 07/14/2015 - 18:53

A Perspective on DevOps from SAFe, IBM and Telstra

Hi everyone,

Alex just participated in a webinar hosted by IBM that provides SAFe, IBM and customer implementation perspectives on DevOps. Other participants include:

  • Tony Christensen, GM/Agile Competency Lead, Telstra
  • Amy Silberbauer, Executive IT & Solution Specialist, SAFe and DevOps

The session was facilitated by IBM’s Kelli Houston. The customer is Telstra, Australia’s largest telecommunications provider, who has recently implemented SAFe, with a rollout that includes over a thousand software development practitioners. That’s agile at scale!

It’s an interesting construct—a distributed panel discussion combining these unique perspectives. While the focus is on DevOps, there are some interesting findings around some “more obvious” constructs like the value of the common taxonomy that SAFe provides, the role of leadership in facilitating flow at the program and portfolio levels, the value and necessity of training to the new way of working, the cultural transformation that DevOps really entails, and more. This 30+ minute webinar provides a lot of value in understanding how to prevent agile from simply creating more un-deployed code laid on the doorsteps of the IT Ops team.

You can watch it here:

https://www.youtube.com/watch?v=OTS3v0b3m_c

Stay SAFe!

–Dean

 

 

Categories: Blogs

PlanningPoker.com Updated

Scrum Expert - Tue, 07/14/2015 - 18:40
PlanningPoker.com is an on-line web site for planning poker produced in cooperation with Mountain Goat, Mike Cohn’s company. It has launched several new free features over the past two weeks. Major design enhancements throughout the game, including a smaller footer and header to increase the game board space. New features for PlanningPoker.com Dealers: * view and print game results in a helpful summary screen * edit game details in an all-new Settings tab within the game board * choose whether cards automatically flip when the last card is played * choose whether players can change ...
Categories: Communities

A Simple Approach to Get Stronger Agile Executive Support

Agile Management Blog - VersionOne - Tue, 07/14/2015 - 14:30

Exec Support

 

 

 

 

 

 

 

If the leading business literature from the past couple of years is to be believed, leanness and agility have become must-have characteristics of any company that expects to thrive. Yet, lack of executive support is consistently reported to be a primary reason that enterprise agile transformations are unsuccessful.

How can this be? If agility is essential to an organization’s business success, how can executive-level support of the adoption of agility throughout the enterprise not be a top priority?

As perplexing as that is, here are some things we do know:

Just the Facts

  • Executives have limited time to take on more.
    More than 60% of the executives surveyed by the Standish Group reported that they spend less than 5% of their time on executive sponsor responsibilities related to the projects that they already own.
  • Executives aren’t focused on the same things that most agile practitioners talk about.
    When is the last time you heard your CEO talk about ATDD, story point normalization, or team empowerment?
  • Executives are accountable for business outcomes.
    Growth, profitability, cost containment, and business strategy development rank high on the list of things that keep CxOs awake at night.

Missed Opportunities

The struggle these days usually isn’t in convincing executives of the general benefits of agile. By now, they’ve at least heard about it or read about it. The challenge lies in connecting agile values, principles, and practices to their needs in a compelling-enough way to convince them that leading fundamental change in the way their organization thinks about and goes about its business will be worth the effort.

Most agile champions and practitioners have limited opportunities to influence executive leadership. And when the right circumstances have presented themselves, we typically haven’t done a very good job of advocating agile as a means of achieving business outcomes. In order to gain enthusiastic executive support, we’re going to have to maximize our opportunities by effectively talking about agile in the context of their needs and responsibilities. They won’t be into agile unless there’s something in agile for them.

Reframing the Discussion

You can use the three-component approach below to help you talk about agility more effectively at the executive level. This can close the perceived gaps between agile’s capabilities and the challenges that executives are focused on. The three components are:

  • Message (a relevant statement of the challenge): says “I understand your needs”
  • Methods (what we can do to meet the challenge): says “I can help you”
  • Measures (how we’ll know that what we’re doing is working): says “I can prove it”

Here’s a familiar example from the bottom-up perspective (you can probably already do this one in your sleep):Lee's post

Message: “I understand that you’re frustrated at how we consistently plan more than we can do, which leads to unrealistic expectations and missed deliverable dates.”

Methods: “Why don’t we limit our commitment to how much we’re really getting done? That way, we can set realistic expectations as to how much we can deliver within a given time frame, at a given level of quality.”

Measures: “We can use the observed velocity trend to determine how much we can commit to. We’ll continuously update that trend, and investigate the causes of any negative trending.”

That’s just an introduction to velocity-based planning, and applicable to somebody directly involved with planning and delivering software. But in order to get the attention of executive leaders, we have to communicate in terms that really impact their world.

The skeleton of that discussion looks like this:

Message: “I understand that we are facing [higher-level business challenge]…”

Methods: “[these agile practices] can help. Here’s how it typically works [no agile jargon – use their language]. Here’s an example: [quick example of what ‘xyz company’ did]”

Measures: “These are the simple metrics we can track to know that it’s working…”

Here’s a fleshed out example:

Message: “I understand that we are facing increasing costs of developing our software, and that this is impacting our overall profitability. A significant factor in this is the amount of test and re-work churn we have during the development cycle.”

Methods: “Test-driven development and continuous integration can help reduce that expensive churn. The development teams continuously build and test small changes in a version of the finished product, allowing them to immediately catch and correct anything that isn’t working the way it should. That eliminates long, expensive integration and test phases. XYZ Company adopted these practices and reduced their overall cost of developing software, while gaining higher quality, and increased sales. And they achieved that without having to hire additional people.”

Measures: “In order to verify that our efforts are working, we can measure the trend in feature cycle time – how long is it taking us to get features completed and delivered to our customers? We can also track the trend of how many defects we are releasing to our customers. Both trends should go down.”

Recap

Now I realize that some might see this as a myopic approach, too focused on a particular set of practices and not focused enough on the values and principles behind them. Remember, though, that if questions are asked, there’s nothing preventing me from, say, further explaining the impact of these practices on throughput and how that affects both the revenue and cost components of the ROI equation. What I’m trying to accomplish here is simply flip the light switch on. We can talk about voltage, current, resistance, and luminosity later.

Of course, the flawless execution of this technique won’t guarantee that the executives in your organization will become agile fanatics. But they certainly won’t embrace agile if they don’t perceive it as a means of meeting their business challenges.
The point here is to be prepared with the right message, and with the methods and measures to back it up, when the opportunity to influence your executive leadership presents itself. Give it a try, and let me know how it goes!

Categories: Companies

Estimating Placeholder Stories is a Bad Practice

Leading Agile - Mike Cottmeyer - Tue, 07/14/2015 - 13:59

Placeholder stories, in general, are a bad idea. Estimating placeholder stories to reserve capacity or to get credit is a very bad idea.

Define “Placeholder Stories”

Of course, all stories are “placeholders for a conversation”, but that’s not what I’m talking about here.

I am also not talking about things like “Refactor the such-n-such class as we start work on the something-or-another Epic”. I’m not talking about having a known customer problem but not yet knowing what to do about it, if anything. Those are specifically identifiable work. Those should be in the backlog (for the sprint or the release), and I don’t call them placeholders.

I’m not wild about having time-tracking stories in the sprint or release backlog because they need to be backed out of certain metrics such as number of stories completed (throughput). But I understand why organizations have them. Let’s call those time-tracking stories instead of placeholders.

By “placeholder stories” what I mean are stories for known-unknowns (or even unknown-unknowns) such as:

– we know we’ll have some production support work to do… 2 points

– we might have to do some sales support… 1 point

– we know we’ll have to do deal with some high priority defects that come up during the sprint… 3 points

– we could get interrupted for some high priority expedite work… reserve 8 points

– the build server is flakey and it might break again… 2 points

– “placeholder story for other unknown work that we might have to do”… 3 points

– end of release regression testing… 60 points

My main complaint is estimating them.

Visibility is Good

I’ve seen teams put a placeholder story in each sprint just as a place to keep record of their customer calls (mainly to get credit). They’ll add a line in the description or a (sub-)task for each new support call. I’m not completely opposed to the placeholder story itself in this case because it’s really just another type of time-tracking story. Also, making the work visible with sub-tasks is a fine idea. But estimating it is wonky.

Negatively Impacts Release Planning

Velocity is a useful input to sprint planing, but it is far more important and useful for release planning. If velocity includes defects and other placeholders, release planning actually becomes more difficult.

Keeping up with how much of the velocity the PO could bank on and how much will go to defects and other placeholders gets tiresome and is error prone.

When the Product Owner is considering the cost or duration of a batch of stories (for example, a new feature or an epic), that PO can’t just do simple math (backlog size / velocity). They have to ask someone to put placeholder stories for support work into the epic or they have to ask someone to tell them what’s the velocity of just the real user stories.

Placeholders make it harder to do what-if scenarios for the release: “What if we trimmed some scope and brought the release date in 2 months? What if we do this expedite and extend the release 1 month?” We have to consider where the placeholders fall in the backlog and scale them up or down. Or if there is a placeholder slotted in advance for every future sprint, then we have lots of placeholders polluting our backlog.

Estimating placeholders causes your velocity to be inflated relative to the backlog of known work for the release. Not estimating placeholders for known-unknowns will simplify release planning.

Therefore, don’t put placeholder junk in your velocity. If you use velocity or throughput for release planning purposes, and you probably should if you are making any release commitments at all, then your velocity metric should only count value stories — items in the backlog that the Product Owner or Customer wants, items from your story map and your Epic/Feature/Story decomposition.

Not Needed for Contingency

Some people use estimated placeholders for buffering in a release plan. They have to do this because they put points on everything, on all the unplanned stuff too. Don’t estimate that stuff. The unplanned and unknown stuff should serve to lower your velocity.

Track the historical rate of production support separately from your velocity. Track defect rates too. Understand the trend and distribution pattern across a release. Then take that into consideration when putting the release plan together. For example, that information helps me decide what to use for my planning velocity, how many or which sprints to include in the average and whether to adjust it further. It also helps me decide how many sprints of active development to plan for. If you take a week or a couple sprints at the end of your release to do regression testing, just plan for that in your schedule. You don’t need to put points on it.

Moving placeholders around as release dates change and adjusting them as the buffer is consumed gets tiresome. Worse, it’s a complication that creates unnecessary opportunities for error.

Plan releases conservatively: don’t include known-unknowns in your velocity; but do include known-unknowns in your release plan.

Not Needed for Sprint Planning

Usually when teams use placeholders it’s because they want to estimate story points for that work in order to reserve some capacity in the sprint. Putting a placeholder in every sprint and calling it 2 points to reserve capacity is unnecessary.

Plan sprints based on the amount of planned points of stuff the Product Owner wanted that you got done in the last sprint. If you use (sub-)tasks with hours estimates and an hours-based burndown, then reduce your capacity for these unknown things, but base it on how many planned hours for known-knowns you were able to do in prior sprints.

If your build server is flakey or if you need to do some maintenance on your VM server, either decide to fix it or don’t. Don’t put a placeholder in your sprint just in case. That’s poor planning.

Isn’t Relative Estimation

Relative estimation works when comparing like kinds of work — known-knowns and actual user stories. You don’t know how many production support issues you are going to have or how long it’s going to take to resolve them. Estimating that stuff is much less accurate than estimating known-knowns. General production support and other overhead shouldn’t show up as estimated items in your sprint or release backlog. Just let support activity be a drag on your velocity.

What About Defects and Expedites?

Defects should show up in your backlog once there is a specific issue that needs fixing — a known-known. Same for high priority expedite work. Add it to your sprint once it becomes a known-known.

But don’t estimate defects. Just let them be a drag on your velocity. Track the historical rate of defects separately. You can reserve capacity in your sprint and release plan without putting points on a placeholder for defects that haven’t been discovered yet.

Getting Credit for Work Done

If your team is using and estimating placeholders to get credit, Stop that. It’s a dysfunction in the organization if people feel the need to inflate their velocity or get credit.

Conclusion

There is no good reason to put points on placeholder stories. Keep unplanned stuff out of your velocity number. This leads to simpler and more conservative release planning.

The post Estimating Placeholder Stories is a Bad Practice appeared first on LeadingAgile.

Categories: Blogs

Knowledge Sharing


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