Skip to content

Feed aggregator

Take an Agile Road Trip With Us!

Rally Agile Blog - Thu, 05/21/2015 - 21:30

Change is happening fast and furious in the business world. With so much pressure to keep up, it can be hard to take your foot off the gas pedal, even for a few days. Occasionally, though, it’s important to pull over and check the map to make sure you’re still on the right road.

If you’ll excuse the extended metaphor, we’d like to humbly offer RallyON!™ 2015 as a rest stop on your way to business agility.

Register today for the RallyON 2015 Agile conference — and get ready to drive at the new pace of change. Join us as we condense the industry’s most dynamic ideas, strategies, and practices into three days of learning, inspiration, and fun.

When: June 15–17, 2015

Where: JW Marriott Phoenix Desert Ridge Resort & Spa in Phoenix, Arizona

Don’t miss this chance to connect with experts and peers. It’s a rare opportunity to gather fresh insights that will remove your most challenging roadblocks and push your projects forward!

  • See how organizations like yours are achieving outstanding business results using Lean, Agile, and DevOps practices.

  • Learn how to create an unstoppable delivery engine, with coordinated teams using the coolest new collaboration tools.

  • Find out how to amplify the success of your Agile release planning and quarterly business steering to deliver value at scale.

Special Discount

There’s something for everyone, so bring your colleagues! In fact, when you register as a team, you can save up to 30% off the registration cost. See Pricing for more details.

Who’s Coming to RallyON?

C-level executives who need business agility to stay ahead of rapid change — whether it’s competition, disruptive technologies, rising consumer demands, or changing regulations

VPs and managers in development and product management who need to improve planning and coordination across teams, so they can connect strategy with execution and ultimately deliver business value

Development team members who are tired of fighting fires and want to gain visibility into work, balance priorities, and respond effectively to the needs of the business

Check out the agenda and search by track (we’ve got seven) to find the sessions that interest you most.

Don’t wait any longer. Register your team today!


Morgan Campbell
Categories: Companies

Acceptance Criteria: or How I Learned to Stop Worrying and Love Conditions of Satisfaction

Agile Game Development - Thu, 05/21/2015 - 19:29
"Of course, the whole point of a 
Doomsday Machine is lost, if you 
*keep* it a *secret*!"  
- Missing acceptance criteria?A definition of done applies to all product backlog items, but sometimes you need to define a set of important requirements that are unique for individual stories before they are worked on.  These are considered “conditions of satisfaction” for the product owner, or acceptance criteria.

Example: As a player, I want to see a Message-of-the-Day (MOTD) from the developer so that I learn useful things about the game.

Some acceptance criteria for this story might be:
  • The MOTD window may only take half the screen.
  • It’s only shown the first time someone starts the game during a calendar day.
Keep in mind that acceptance criteria shouldn’t be a huge list of design specifications.  These are a limited set of specific “must do” criteria that the team needs to know up front.

Types of acceptance criteria:
  • Specific functionality known up front (above).
  • Special, non-functional requirements (e.g. memory or CPU performance limits), for example “The game should have ten of these effects running with less than 2 milliseconds per frame cost on the target platform”.
  • A set of expected behaviors for a subset of features, such as needing persistence in saved games or needing specific tests for online gameplay.   
  • Known areas that will be incomplete.  For example, if you’re implementing a jump feature, but don’t have enough animation support (and have failed to get more), an acceptance criteria might say “some animation transitions will pop”.
Good acceptance criteria will:
  • Have a clean pass/fail, testable state.
  • Won’t dictate implementation details.
Who and When?
Acceptance criteria can be added to a story any time before, and during, sprint planning.  Usually they’ll be added in release planning, grooming and sprint planning with greater detail added as the sprint work approaches.  The product owner doesn’t have to be the one to identify them all, but should be present when they are captured.  I prefer to have the team there as well asking questions and suggesting acceptance criteria along the way.  One useful approach is to have a member of QA or a developer capture any acceptance criteria during discussions of the story, especially in sprint planning.

The Point
Acceptance testing will focus the team on the outcome as much as the means of getting there.  It allows the business side to build trust with the team and to improve how they communicate their needs.  When trust exists, the business is less likely to worry about the sprint and interfere.
Categories: Blogs

Q2 2015 Product Update Webinar

Jon Terry, COO at LeanKit, shares the most recent product enhancements, discusses what’s currently in progress, and provides a look at what’s ahead in LeanKit. About This Webinar Topics discussed during this webinar include: Enhanced Lean reporting rollout UI and board template updates Project scheduling improvements Project system integrations Informational Links Enhanced Lean Metrics: More Speed and Insight LeanKit, Integrated […]

The post Q2 2015 Product Update Webinar appeared first on Blog | LeanKit.

Categories: Companies

Certified ScrumMaster Workshop in Toronto—November 2-3

Notes from a Tool User - Mark Levison - Thu, 05/21/2015 - 19:15
Agile Pain Relief presents a two-day Certified ScrumMaster Workshop in Toronto—November 2-3 taught by certified ScrumMaster Trainer Mark Levison.
Categories: Blogs

Pop Quiz: How’s Your Agile?

Rally Agile Blog - Thu, 05/21/2015 - 17:44

Humans typically crawl before we learn to walk, and walk before we learn to run. But sometimes what we call running is really more like a walk, and sometimes when we’re in a real hurry we’ve been known to skip a step.

Creative Commons photo via Flickr

How we learn to get started with Agile can take a lot of forms. Many people begin with baby steps: piloting a single team or experimenting with daily standups. Others are eager to get into a fast cadence right away and launch whole delivery groups — coordinated teams working on business strategy — all at once.

How we gauge our speed and progress varies, too.

  • Some organizations outgrowing stickies on a whiteboard don’t know how to take the next step.
  • Some go through the motions of Agile without noticing that their form is pain-inducing, or they’re moving so fast that they don’t have time to look around for competitors.
  • Some become so focused on the work in the moment that they lose sight of the finish line altogether.
  • Many who are “winning” at Agile forget to retrospect on their success or how to further improve.

Where are you in your Agile journey? Are you eager to take the next step, but don’t know where to start? Do you wonder how you stack up against others?

Now you can find out. Take five minutes to take our Agile Quiz. Get immediate answers, see how you compare to others who do what you do, and get recommendations for what to do next.



Categories: Companies

Hansoft 8.4 Released

Scrum Expert - Thu, 05/21/2015 - 17:41
Hansoft has announced the release of Hansoft. 8.4, which includes a complete reboot of the quality assurance features in the tool. This represents a huge step forward for quality assurance teams using Hansoft to manage defects or tickets and cross functional teams looking to further integrate quality assurance with their development processes. Bugs Visible within Sprints in the Planning View Hansoft 8.4 allows for bugs to be viewed in the sprint backlog and on boards. Bugs can also be given a sprint priority, meaning they can easily be prioritised against regular ...
Categories: Communities

Agile Roots, Salt Lake City, USA, June 18-20 2015

Scrum Expert - Thu, 05/21/2015 - 15:45
The Agile Roots conference is a two-days event taking place in Salt Lake City that provides sessions and workshops about learning, improving effectiveness, measuring and predicting customers, as well as more general Agile, Scrum, Lean and Kanban topics. In the agenda of Agile Roots you can find topics like “How doing the little things well makes the big things possible”, “Do testers need to code to be useful?”, “Practical Team Diversity Tactics”, “Shoestring Agility in a Velcro Organization”, “Team Mind — What Can Agile Teams Learn From Science Teams?”, “Build Quality ...
Categories: Communities

Have A Point Of View And A Plan

Leading Agile - Mike Cottmeyer - Thu, 05/21/2015 - 15:29

If you get a few minutes to talk to your executives about agile… you’ve got to be really crisp about what you are asking for and why.

Far too often people get that few minutes and totally fail to explain why agile is important and why their executives should care.

If you have an opportunity to speak to your leadership team about agile, here are the four things you need to be able to communicate.

1. Show deep understanding of the problems that your executives are trying to solve. Not the problem YOU want to solve, but the problems that THEY are trying to solve.

2. Explain specifically what about the current organization is contributing to these problems and how doing more of the same isn’t likely to lead to a different outcome.

3. Explain the specific changes you’d like to make in the organization. You have to be VERY specific. You can’t tell people to think differently. You have a shot at asking them to behave differently.

4. Make a specific ask for permission… to do a specific action… to prove that your approach to solving the problem could work. Let the executive know specifically what kind of support you need.

You need to be able to do this in about 10 minutes. Here is an example.

1. I deeply understand that we are struggling as an organization to make and meet commitments and get product to market in a timely manner. Our competition is moving faster and taking market share.

2. Our problem is that people are spread too thin across too many initiatives. People are unable to estimate accurately, and when they do, the constant context switching is slowing them down.

3. I’d like to try an experiment where we form a complete cross functional team. Help the team prepare a really clear backlog and we’ll help them produce a working tested increment every couple of weeks.

4. Could I get your support to form a team around our new product. We’d like to use a method called Scrum to manage the team’s work and in three months we’ll be able to get a prototype ready for market.

Obviously, this is an oversimplified example, but I think you get the idea.

Walking into the C-Suite and telling them they don’t get it… that they need to change… that they need to empower people…that they need to let folks self-organize… IMO, doesn’t really cut it.

Just a quick comment as we close… if you don’t understand your executives problems, you don’t have a clear point of view about what is specifically broken, you don’t have a clear plan for how to fix it, and you don’t know how to ask your executive to take action…

Don’t bother.

The post Have A Point Of View And A Plan appeared first on LeadingAgile.

Categories: Blogs

Use Metrics to Tell a Story

Leading Agile - Mike Cottmeyer - Thu, 05/21/2015 - 15:26

Agile delivery practices use metrics as a foundation to quantify the unpredictable nature of understanding what someone has in mind. Stories are a set of words that convey an idea and translate one person’s imagination into an imaginary format called software. Given that we can debate what the definition of “is” is, estimating when some body of work will be done and how far we are in that body of work approaches impossible. However, all Delivery Managers are asked to do exactly that. End of Sprint reports are used to convey to the rest of the business where we are on an imaginary journey and when we will get there.

The Release burn up helps to describe how well the teams are able to complete the work planned for this release. In this team we can see that although the team is tracking to complete the scope originally planned in the release. Scope was added to the plan either by better understanding or changes in definition and the team is not able to complete the growth in scope. Also in this chart we see that the Product Owner is not accepting the scope. This could increase the risk of an on time delivery.

Use Metrics 1

The bug chart helps to give some understanding of the quality of the work. It is important to report all of the defects in the code base. Deciding what to do about the defects is a subject for another blog.

Use Metrics 2

Finally we want to report something about what is happening with the scope. The scope chart below just gives a snapshot in time of how things are going and what areas need focus. The chart shows that the scope is actively being managed but investment decisions may be affected by the discovered scope in one or more features.

Use Metrics 3

The most important part of any report is not the numbers gathered but the narrative that goes along with the numbers. The story of this release so far is that scope has been found or added that the team cannot achieve but they are tracking to make plan. The defects are being well managed and do not appear to cause alarm. Scope is being managed but higher-level decisions need to be made. The View Report feature is not anywhere close to the high level estimate and will impact the team’s ability to take on other work. The team needs help to prioritize whether they should continue with this feature or look for other solutions.

What story is your status report telling?

The post Use Metrics to Tell a Story appeared first on LeadingAgile.

Categories: Blogs

Failing to Plan is Planning to Fail: Succeed with Agile Planning Framework and Its Four Planning Objectives

Agile Management Blog - VersionOne - Thu, 05/21/2015 - 14:30

In the first blog post of this series of six, I explained the need for Agile Planning Framework with its four planning levels.

In this second blog post, I explain four objectives at each planning level, and how to use the proposed Agile Planning Framework to implement and operationalize your customized agile planning playbook.

Agile Planning Framework: 4 planning levels x 4 planning objectives covering 16 practices.

Table 1 presents the recommended Agile Planning Framework, with four agile planning levels represented by its four columns, and four key objectives represented by its four rows.  The wording of each objective is the same for all four levels, offering a unified treatment of each objective at all four levels, and also making the objectives easy to understand and manage.  However, the implementation of each objective with specific practices depends on the level.  For each of the four objectives, there are four practices corresponding to four levels of planning.  Altogether there are 4 x 4 = 16 practices covering all four levels of planning and four objectives. These 16 practices are numbered as 1.1 through 1.4, 2.1 through 2.4, 3.1 through 3.4, and 4.4 through 4.4.

Table 1: Customizable Agile Planning Framework with 4 Levels,
4 Objectives and 16 Practices


Table1BObjective 1 – Choose and include appropriate method for planning in your Agile Planning Playbook:  At each level of planning, Row 1 of Table 1 shows which specific planning method to choose from a set of choices, what specific things to pay attention to, and things to avoid as they cause waste.

Objective 2 – Obtain required inputs for planning and do necessary preparation ahead of the planning sessions:  Agile planners must obtain the inputs required for planning and do the necessary planning preparation ahead of each planning session (meeting or workshop).  Organizational old habits and inertia might mean multiple reminders and follow-up with at least some people, which some planners may find distasteful (pulling the teeth experience), and may be tempted to skip this diligence.  Without required inputs needed for planning and preparatory steps completed, the planning work to be done during a planning session will not be effective. Row 2 of Table 1 lists the input information needed for planning at each level.

Objective 3 – Develop your agile plan:  At each level of planning, several outputs must be produced to develop the Agile Plan at that level.  Row 3 of Table 1 lists many of these key outputs of the agile plan at each level of planning.  Note that the agile plan also needs to specify how workflow against the plan will be monitored.

Objective 4 – Re-plan as required, and improve the agile planning process and agile planning playbook on an on-going basis:  An agile plan is not an end-all in itself.  As an agile plan gets implemented at each level, lessons are learned through experience, and new inputs are received from the environment (market changes, competitive changes, and business condition changes), the plan itself will need revisions (agile re-planning).  The nature and method of re-planning change with the planning level.   The need for re-planning must be understood by the highest level of management – an area where agile champions and coaches may need to put some effort to overcome old mindsets.

Lessons learned from developing and executing agile plans at all levels, lessons discussed at reviews and retrospectives at all levels, and inputs received from the environment should become the basis for on-going improvements of the agile planning process and the agile planning playbook at your organization.

Relationship among Agile Planning Framework, Agile Planning Playbook, Agile Plans and their Implementations

Figure 3 shows this relationship along with an explanatory legend.  I encourage agile champions to use the Agile Planning Framework presented in this blog series (Blog 1 and 2) to guide the development of your customized Agile Planning Playbook.  Customization is done in the way you choose planning levels and planning objectives, and implement 16 practices of Table 1.  Agile Planning Playbook is part of the more comprehensive Agile Lifecycle Playbook.  Four planning level-specific playbooks are part of the Agile Planning Playbook.  Each level of planning provides the context for the next lower level of planning.  Implementation at each level provides feedback to the agile plan at that level, and based on the nature of the feedback the agile plan may be revised.

Moreover, implementation at each level provides a second order – what I call “derivative” – feedback to the Agile Planning Playbook; for example, if there is a systemic trend based on several days of daily feedback, it may alter the Agile Daily Planning and Daily Scrum Playbook.  As an example, if a team finds it difficult to hold to the scheduled start and end time of their daily Scrum meetings based on daily feedback from several days of work, then the team tries to find the root cause, fixes it, and revises its own Agile Daily Planning and Daily Scrum Playbook.

If a team finds that the same problems have recurred few sprints later even after “fixing” them as a result of an earlier sprint retrospective, the sprint planners and agile champions must explore deeper over the feedback data from a series of sprint retrospectives (hence it is called derivative feedback), address the root cause, and revise their Agile Sprint Planning Playbook.  Feedback from few samples in agile implementation is usually enough to drive a change in the agile plan at that level, but it requires sustained or systemic feedback over several samples (derivative feedback) to warrant a change in agile planning playbook at that level.  Sometimes, a feedback at one level of agile implementation may be so strong that it could alter the agile plan at a higher level.  An agile implementation or a plan or sometimes even a playbook may be altered due to inputs from the environment (market changes, competitive changes, technology issues, business changes).  This is not shown in Figure 3 to avoid clutter and to stay focused on the relationship among Framework, Playbooks, Plans and Implementation effort.


Fig4_Legendfor_Fig3Figure 3: Relationship among Agile Planning Framework, Agile Planning Playbooks, Agile Plans and Implementation

Guidelines for customizing the Agile Planning Framework:  For a client-specific project of a relatively modest duration (say, six months), you may be able to skip Level 1 planning (Product Vision and Strategy) and start with Level 2: Release Planning, consisting of two release cycles of three months each.

Teams that are new to agile development may start with Level 3: Sprint planning and Level 4: Daily Planning and Daily Scrums.  As they gain experience of few sprints under their belt, they may then start doing Level 2: Release planning, and with further experience start with Level 1: Product Vision and Strategy planning.

For entrepreneurial start-ups with high degree of uncertainty about their real customers and their real problems, and about technical feasibility of their solution, staring with a two-year long vision and strategy exercise may not be very productive.  A start-up may spend the first several months on Level 3 (Sprints) and Level 4 (Daily) planning and execution to validate their assumptions, demonstrate prototypes to potential customers, and make small changes in the (implicit) strategy or even “pivot” (significantly change) the strategy based on feedback from short sprints.  Only when they have a good understanding about real customers and their real problems, and have some confidence in technical feasibility of their solution, they may advance to Level 2 (Release) and finally to Level 1 (Product Vision and Strategy) planning.

For a very large organization with many portfolios, programs and projects, you may have five levels of planning: Portfolio vision and strategy, Product vision and strategy, Release planning, Sprint planning, and Daily Planning and Daily Scrums.   Alternatively, you may choose to have multiple Agile Planning Books targeted for different lines of businesses or product lines.

For well-jelled, highly experienced and stable teams that have demonstrated a stable velocity pattern (velocity changes within a narrow range across successive sprints), Planning Level 4 can be substantially simplified.  Such teams should still conduct Daily Scrum meetings and may break stories into SMART tasks, but may track the effort for an entire story, and not at the task level.

You may add one or a small number of new objectives (beyond four objectives in Table 1) to your Agile Planning Framework, if required for your specific situation.  Ability to add new planning levels and new objectives makes the Agile Planning Framework extensible.  If you decide to add new levels or new objectives, I will be very interested in knowing the reasons (you may send me an email at  If you delete or modify or relax any of these four objectives, your agile plan will be incomplete or inadequate or of poorer quality compared to a plan developed by rigorously and diligently following all four objectives.

From Agile Planning Framework to your customizable agile planning playbook:  Agile champions owning the agile planning playbook have many important responsibilities:

  • Take the Agile Planning Framework from this blog series and customize it to create your agile planning playbook, instead of developing the playbook from scratch. This will save you substantial effort and result into a better and higher-quality playbook.
  • Choose your own method for implementing each of 16 practices of Table 1. Furthermore, you should explore how to integrate your agile planning playbook with your Agile Lifecycle Management platform (see below) as that will make its actual use by agile champions, agile planners and agile team members much more likely and natural.
  • After getting the buy-in and commitment for agile planning from your senior executives, educate agile planners and stakeholders in your organization on the agile planning playbook to be used in your company, and also get their inputs in developing your agile planning playbook.
  • Make sure that your agile planning playbook is followed by agile planners at all four levels of agile planning, and even more importantly agile team members do their work driven by those plans.
  • Improve the agile planning process and the playbook on an on-going basis.

The resulting agile planning playbook can be a brief document or a set of wiki pages.  However, this solution will be disconnected from and will be poorly integrated with your ALM platform, and may not get used much as it is an “out-of-band” solution; and for that reason, it’s not my favorite.  I strongly recommend that you implement and operationalize your agile planning playbook as an “in-band” solution that is well-integrated with your ALM platform.

If you are using or planning to use VersionOne as your ALM platform, I encourage you to implement your agile planning playbook using VersionOne Communities, Templates, Reporting and Customization capabilities, pilot your playbook with few agile projects, and then roll it out at a larger scale.  If you have questions on how to implement and operationalize your customized agile planning playbook or to implement a more comprehensive agile lifecycle playbook covering the entire agile project lifecycle, please let us know at

Though last but not the least, the agile planning playbook is necessary but not sufficient for agile success.  Excellence in agile project execution is also essential, in addition to be good at agile planning.  However excellence in execution will not be effective in delivering business results without proper agile planning.

The next five blogs of this blog series: In the next blog (Blog 2 of this series), I will explain four objectives at each planning level of the Agile Planning Framework.   In the following four blogs (Blog 3 to 6), I will explain the implementation and customization details for four practices needed to realize the four objectives at each planning level.

  • Blog 3: Plan and Succeed Strategically using Your Agile Product Vision and Strategy Planning Playbook
  • Blog 4: Plan and Succeed in each Release using Your Agile Release Planning Playbook
  • Blog 5: Plan and Succeed in each Sprint using Your Agile Sprint Planning Playbook
  • Blog 6: Plan and Succeed every Day using Your Agile Daily Planning and Daily Scrum Playbook

In Blog 6, I will also present a complete example of an Agile Planning Playbook based on the Agile Planning Framework.

If you have questions on how to implement and operationalize your customized Agile Planning Playbook or to implement a more comprehensive Agile Lifecycle Playbook covering the entire agile project lifecycle, please let us know at

Your feedback: I would love to hear from the readers of this blog either here or by e-mail ( or on Twitter (@smthatte).

versionone-coaches-satish-thatteAbout the Author
Dr. Satish Thatte

Dr. Satish Thatte is Agile/Lean Coach & Product Consultant at VersionOne.  He has over 30 years of industry experience, covering 15 years of software development and management at Texas Instruments, Bellcore and LG Electronics, 7 years as VP of Engineering at several companies practicing agile methods, and 6 years of agile coaching and consulting engagements for over 50 clients with impact at the executive level.  He obtained his MS and PhD degrees in Electrical and Computer Engineering from the University of Illinois at Urbana-Champaign.

His expertise is in application of agile-lean methods and getting business results, agile transformation, and scaling up agile methods. He has been a speaker at a number of organizations and events: NYC Scrum, NY SPIN, NJ SPIN, Philly SPIN and AgilePalooza. He is a member of the Scrum Alliance, Agile Alliance, and a Senior member of the IEEE, and has served as Director of Modeling and Simulation at the Conscious Capitalism Institute.  Learn more about Satish and his blogs at LinkedIn and blogs.

Categories: Companies

The SonarQube COBOL Plugin Tracks Sneaky Bugs in Conditions

Sonar - Thu, 05/21/2015 - 13:28

Not long ago, I wrote that COBOL is not a dead language and there are still billions lines of COBOL code in production today. At COBOL’s inception back in 1959, the goal was to provide something close to natural language so that even business analysts could read the code. As a side effect, the language is really, really verbose. Each time a ruby, python or scala developer complains about the verbosity of Java, C# or C++, he should have a look at a COBOL program to see how much worse it could be :). Moreover, since there is no concept of a local variable in COBOL, the ability to factorize common pieces of code in PARAGRAPHS or SECTIONS is limited. In the end, the temptation to duplicate logic is strong. When you combine those two flaws: verbosity and duplicated logic, guess what the consequence is: it’s pretty easy in COBOL to inject bugs in conditions.

Let’s take some examples we’ve found in production code:

Inconsistencies between nesting and nested IF statements

In the following piece of code the condition of the second nested IF statement is always TRUE. Indeed, when starting evaluation of the nested condition, we already know that the value of ZS-LPWN-IDC-WTR-EMP is ‘X’ so by definition this is TRUE: ZS-LPWN-IDC-WTR-EMP NOT EQUAL 'N' AND 'O'. What was the intent of the developer here? Who knows?

And what about the next one? The second condition in this example is by definition always TRUE since the nesting ELSE block is executed if and only if KST-RETCODE is not equal to ’02′ and ’13′:

Inconsistencies in the same condition

In the following piece of code and in the same condition we’re asking ZS-RPACCNT-NB-TRX to be both equal to 1 and 0. Obviously Quantum Theory is not relevant in COBOL, and a data item can’t have two values at the same time.

The next example is pretty similar, except that here it is “just” a sub part of the condition which is always TRUE: (ZS-BLTRS-KY-GRP NOT = 'IH' OR ZS-BLTRS-KY-GRP NOT = 'IN'). We can probably assume that this was not what the developer wanted to code.

Inconsistencies due to the format of data items

What’s the issue with the next very basic condition?

ZS-RB-TCM-WD-PDN cannot be greater than 9 since it’s declared as a single-digit number:

With version 2.6 of the COBOL plugin, you can track all these kinds of bugs in your COBOL source code. So let’s start hunting them to make your COBOL application even more reliable!

Categories: Open Source

Python: UnicodeEncodeError: ‘ascii’ codec can’t encode character u’\xfc’ in position 11: ordinal not in range(128)

Mark Needham - Thu, 05/21/2015 - 08:14

I’ve been trying to write some Python code to extract the players and the team they represented in the Bayern Munich/Barcelona match into a CSV file and had much more difficulty than I expected.

I have some scraping code (which is beyond the scope of this article) which gives me a list of (player, team) pairs that I want to write to disk. The contents of the list is as follows:

$ python
(u'Sergio Busquets', u'Barcelona')
(u'Javier Mascherano', u'Barcelona')
(u'Jordi Alba', u'Barcelona')
(u'Bastian Schweinsteiger', u'FC Bayern M\xfcnchen')
(u'Dani Alves', u'Barcelona')

I started with the following script:

with open("data/players.csv", "w") as file:
    writer = csv.writer(file, delimiter=",")
    writer.writerow(["player", "team"])
    for player, team in players:
        print player, team, type(player), type(team)
        writer.writerow([player, team])

And if I run that I’ll see this error:

$ python
Bastian Schweinsteiger FC Bayern München <type 'unicode'> <type 'unicode'>
Traceback (most recent call last):
  File "", line 67, in <module>
    writer.writerow([player, team])
UnicodeEncodeError: 'ascii' codec can't encode character u'\xfc' in position 11: ordinal not in range(128)

So it looks like the ‘ü’ in ‘FC Bayern München’ is causing us issues. Let’s try and encode the teams to avoid this:

with open("data/players.csv", "w") as file:
    writer = csv.writer(file, delimiter=",")
    writer.writerow(["player", "team"])
    for player, team in players:
        print player, team, type(player), type(team)
        writer.writerow([player, team.encode("utf-8")])
$ python
Thomas Müller FC Bayern München <type 'unicode'> <type 'unicode'>
Traceback (most recent call last):
  File "", line 70, in <module>
    writer.writerow([player, team.encode("utf-8")])
UnicodeEncodeError: 'ascii' codec can't encode character u'\xfc' in position 8: ordinal not in range(128)

Now we’ve got the same issue with the ‘ü’ in Müller so let’s encode the players too:

with open("data/players.csv", "w") as file:
    writer = csv.writer(file, delimiter=",")
    writer.writerow(["player", "team"])
    for player, team in players:
        print player, team, type(player), type(team)
        writer.writerow([player.encode("utf-8"), team.encode("utf-8")])
$ python
Gerard Piqué Barcelona <type 'str'> <type 'unicode'>
Traceback (most recent call last):
  File "", line 70, in <module>
    writer.writerow([player.encode("utf-8"), team.encode("utf-8")])
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 11: ordinal not in range(128)

Now we’ve got a problem with Gerard Piqué because that value has type string rather than unicode. Let’s fix that:

with open("data/players.csv", "w") as file:
    writer = csv.writer(file, delimiter=",")
    writer.writerow(["player", "team"])
    for player, team in players:
        if isinstance(player, str):
            player = unicode(player, "utf-8")
        print player, team, type(player), type(team)
        writer.writerow([player.encode("utf-8"), team.encode("utf-8")])

Et voila! All the players are now successfully written to the file.

An alternative approach is to change the default encoding of the whole script to be ‘UTF-8′, like so:

# encoding=utf8
import sys
with open("data/players.csv", "w") as file:
    writer = csv.writer(file, delimiter=",")
    writer.writerow(["player", "team"])
    for player, team in players:
        print player, team, type(player), type(team)
        writer.writerow([player, team])

It took me a while to figure it out but finally the players are ready to go!

Categories: Blogs

How to Use Empathy to Build Software Products

Pivotal Tracker Blog - Thu, 05/21/2015 - 00:16

There’s one skill that every wildly successful product manager, UX designer, businessperson, and leader has in common. It helps them unite teams and ship products that customers love time and time again.

What could possibly unite all these technologists?

It’s conscious and deliberate empathy.

Most people believe empathy is just about being compassionate, like lending your friend a shoulder to cry on when they’re going through a breakup. Others dismiss it altogether as a distraction, because they believe it’s more important to be efficient, focus, and get stuff done!

Well, it just so happens that when a company is plagued by lack of motivation, missed deadlines, and high employee turnover, often it’s because employees feel that their teammates, bosses, and management don’t “get them.” They might feel like coworkers jump to conclusions or assume their intentions and motivations. In other words, they don’t feel that anyone has empathy for them as an individual.

Lack of empathy is terrible for team building, but it also impacts another crucial part of your business . . .

It actually seeps into how products are created, so customers feel like your company doesn’t “get” them either! Why would a customer who feels misunderstood stay loyal to you or recommend you to your friends?

Empathy isn’t just about being compassionate. There are actually several different types of empathy. And there’s one that’s most helpful for success in business and technology.

We’ll tell you how to start using it right away in today’s episode of Femgineer TV. For expert guidance, I’ve invited Indi Young, a founder of Adaptive Path, user experience consultant, and author of two books: Mental Models and, most recently, Practical Empathy.

Indi will help us clarify several misconceptions and avoid some misuses of empathy . . . and of course to learn how to actually practice it in the right way.

Watch the episode and learn:

  • Why Tom Gruber, the designer and cofounder of Siri, believes empathy is crucial to getting things done in tech companies.
  • Why empathy isn’t limited to just building products but extends to processes and building teams.
  • Why we’ve fallen in love with quantitative data, but it isn’t enough to develop a deep understanding of our teammates and customers—we need qualitative data, too.
  • Why empathy is a skill that can be learned and practiced.
  • How to translate our learnings from practicing empathy into actionable insights for our business.

If you’re struggling to understand your customers and find alignment with your teammates, then you’ll want to watch this episode!

Viewer’s Challenge

After you’ve watched the episode, take our challenge. Let us know in the blog comments below: What do you currently do to understand your customers and teammates?

The three best responses will receive a special giveaway from our sponsor, Pivotal Tracker, and will be showcased in Femgineer’s weekly newsletter!

Submit your responses in the blog comments below by May 20th at 11:59pm PST.

Join our Twitter chat

Poornima Vijayashanker and Indi Young will be hosting a Twitter chat on Wednesday, May 20th at 7:15pm PST. Join the conversation using the hashtag #femgineertv.

The next episode of Femgineer TV airs in June!

I’ll be hosting Edmond Lau, the author of The Effective Engineer. Subscribe to our YouTube channel to know when it’s out!


The post How to Use Empathy to Build Software Products appeared first on Pivotal Tracker.

Categories: Companies

SAFe Lean-Agile Principles Have Arrived!

Agile Product Owner - Wed, 05/20/2015 - 20:18

The impression that “our problems are different” is a common disease that afflicts management the world over. They are different, to be sure, but the principles that will help to improve the quality of product and service are universal in nature.                             —W. Edwards Deming

Why the Focus on Principles?

SAFe provides an integrated set of proven practices that enterprises rely on to improve their solution development capability. Implementation of these practices however, often requires tailoring to address the needs of a specific organization.  Should an enterprise use eight, ten or twelve week PIs? Should they have a System Team at the program or at the value stream level? Should DevOps functions be supported via a hybrid ART team or fully incorporated in each Agile team? What if you can’t integrate every day, or even every iteration? Should the trains be organized around capabilities or subsystems?

As a framework, SAFe can only take things so far, after that it’s up to the judgment of those doing the implementation. But how can SAFe provide guidance with this kind of decision-making? Answer: By clearly articulating the underlying principles that make SAFe safe.

To that end, we’ve developed nine principles that summarize the key tenets of Agile, Lean process and product development, Systems thinking and product development flow, as applied in the context of building large systems and solutions. These are the fundamental tenets, the basic truths and economic underpinnings that drive the roles and practices that make SAFe effective. Of course, you can’t possibly capture this complexity in only nine principles, but that doesn’t mean you shouldn’t try. To that end, we offer the following.

Screen Shot 2015-05-19 at 4.39.03 PM

SAFe Lean-Agile Principles

These new principles can be accessed from the new Principles tab. Each is hyperlinked to a short article that describes the principle in further detail.

The Sources

These principles incorporate lessons learned from applying Agile, Lean and SAFe practices in the field for over a decade, in a hundred different contexts. We’ve observed, recorded, drafted, revised, incorporated feedback and tried again. It’s from this field experience that we’ve observed patterns that are effective in Screen Shot 2015-05-19 at 4.46.22 PMenterprise after enterprise. Underlying these successful patterns are the principles that cause those patterns to be effective. In order to find them, you just have to dig a little further into the theory, abstract a bit, write them down, read them, and then listen to what they tell you.

Screen Shot 2015-05-19 at 4.43.42 PM

They are also derived from the Agile body of knowledge—from the Agile Manifesto to the many books and methods, Scrum, XP, Kanban—and dozens of books by the Agile thought leaders we all know so well. And in order to scale, we take our inspiration from Lean Thinking, and writings on human potential and knowledge creation from seminal and ground breaking authors Deming, Drucker, Pink, Oosterwal, Ohno, Nonaka and Takeuchi, Ries, Kim, Reinertsen, Liker, Ward, Kennedy, and many more.  Some of these books represent a lifetime of learning condensed into a few hundred pages.

We are standing on the shoulders of giants. Let’s make sure we apply all that we have learned.

Categories: Blogs

Help! My Scrum Master is Running the Sprint!

Agile Game Development - Wed, 05/20/2015 - 19:15

“Hi, I had a question.  Our Scrum Master is acting like a manager, running all the meetings and assigning work.  This is what they did before Scrum.  I thought Scrum meant the team did this stuff?” - A developer

The values of Scrum apply here.
Scrum! Scrum! Scrum! Scrum!
The sprint is the team’s commitment to a goal.  True commitment to the game and continuous improvement requires a level of ownership, otherwise it’s an environment of compliance and people don’t engage as well with that.

The barrier to allowing ownership is fear.  I often hear the micro-managing Scrum Master’s fear of what will happen if the team doesn’t follow their leadership.  "They might fail!", they cry.   There is often an underlying suspicion that others on the team are not competent because they'll make mistakes.   The news is that competence doesn't mean you don't make mistakes!

Allowing teams to make mistakes and safely fail from time-to-time requires trust and courage.  Trust requires respect.  A lack of trust and respect is a cultural root of evil.  When I see locked supply cabinets, dictated core hours or time-sheets, web filters, people referred to as “resources” etc. I know that the true adoption of Scrum will be a bit harder.

How can this be done?
Courage is requiredShifting from a mindset of individual compliance to team commitment requires courage all around.  The Scrum Master and the team must summon the courage to take chances and fail every once in awhile.  Emboldening the team to find this courage is more challenging than micromanaging via a task spreadsheet, but it’s also more fulfilling.  It doesn’t happen overnight, but trust and respect can be grown.

Scrum Masters can start with some simple things:
  1. Silence yourself! Stop doing all the talking.  Learn to allow awkward silences.  The team will fill the silence with their own ideas and solutions.
  2. Ask questions, even when you know the answer.  Teach them to catch fish rather than giving them fish to eat.
  3. Be courageous.  Demonstrate respect and protect the team.
The development team assumes a part of this challenge as well.  It’s often hard for them to shift from being assigned tasks to accepting responsibly for planning and executing their own work.  Respect and openness among each other is critical.

For example: if an artist is having problems getting code to work with a model, the entire sprint goal is threatened, but the team's focus on their shared goal should guide them to solve this problem on their own.   There is no need to blame the artist for not solving their own problem.  There is no need for someone wearing a manager’s hat to assign an engineer to fix the problem.

Does this mean managers/producers should be fired?
Don't expect leadership to
be overthrown, but leveragedAn underlying fear from managers or producers jumping into the Scrum Master role is that they should continue doing what they've been good at in the past or they'll be let go.

In the ten years that I have been training teams to use Scrum, I haven’t seen this happen.  I’m not saying it never will, but most stories I hear reflect my own as a manager in a studio that adopted Scrum.

I found that as teams became more self-organizing, there was a growing part of my time that needed to be filled with other things.  Eventually, about half my day was freed up by not micro-managing.  This wasn’t bad because the work that teams took from me was never the work I enjoyed doing.  So, I joined a team as their product owner and ended up enjoying the work far more as I was closer to the game and the people making it.

This might not be the path for every manager.  Agile should lead a studio to ask what practices and roles are benefitting their games and the people making them and what parts are not.  Again, this can threaten the status quo, which is why a lot of larger, established studios have a harder time adopting agile.

"Now I can make cool movies about
monkeys taking over the world!"The bottom line is that these values have to win out for you to have full success with agile.
Categories: Blogs

Product Owner Camp Switzerland, Sursee, Switzerland, June 11-13 2015

Scrum Expert - Wed, 05/20/2015 - 17:06
Product Owner Camp Switzerland is a three-day event for Scrum product owners and Agile product managers, coaches and ScrumMaster. The first day will be dedicated to a Product Owner Master Class. The two other days will have an open space format with discussions on how to solve problems, sharing ideas and networking with people passionately engaged in all facets of Agile product creation. Product Owner Camp Switzerland follows the open space format for conferences. Open space is a simple methodology for self-organizing conference tracks. It relies on participation by people who ...
Categories: Communities

What Happened to the Idea of Inspect and Adapt?

Scrum Expert - Wed, 05/20/2015 - 17:03
It’s all too common these days to see arguments on Twitter or mailing lists with these rules-bound zealots arguing that ”you’re not agile” because you aren’t following the rules to their satisfaction. What happened to the idea of inspect and adapt? What happened to the idea of introducing new practices, of evolving our practices to suit the challenges at hand? The canonical agile practices of popular methods have remained essentially unchanged for over a decade. We are stuck in a rut. And as I’m fond of saying, the only difference between a ...
Categories: Communities

Agile in a Bag, London, UK, June 12 2015

Scrum Expert - Wed, 05/20/2015 - 10:57
Agile in a Bag is a one-day conference that takes place in London. It proposes workshops to help you understand how Agile works and interesting presentations explaining Scrum ideas. It is also a great place to network with fellow Agile practitioners in London. In the agenda of Agile in a Bag, you can find topics like “Coaching Tools for Agile Leaders”, ” Quantifying Cost of Delay – Why is it the ‘one thing’ to quantify, How do I do it?”, “Influence techniques of Scrum Master: how to build a team without ...
Categories: Communities

Gibt es ein Leben nach dem Jobtitel?

Scrum 4 You - Wed, 05/20/2015 - 08:00

So wie bei vielen anderen Unternehmen auch gibt es auf unserem Portal mehrere Stellenanzeigen. Wir suchen wie verrückt: Senior Consultants, Senior Entwickler, ScrumMaster, Scrum Coaches etc. Vor ein paar Tagen stieß ich in diesem Zusammenhang auf einen spannenden Blogbeitrag von Johann-Peter Hartmann von Mayflower, in Deutschland bekannt für die agile Softwareentwicklung u.a. in PHP. Sein Artikel „Warum wir keine Titel und Positionen mehr haben“ hat mich sehr nachdenklich gemacht. Er schreibt: „Scrum macht jeden Sprint eine Retrospektive, um die Prozesse und Organisationsform kontinuierlich zu adaptieren. Kanban schleppt ein ganzes Sammelsurium von Messinstrumenten mit, um überhaupt feststellen zu können, wie es im Projekt aussieht und was gerade gebraucht wird. Agil fordert cross-funktionale Teams, bei DevOps wird die Brücke in den Betrieb geschlagen. Das Team ist eigenverantwortlich. Es trägt die Verantwortung selbst. Nicht der Projektleiter, nicht der Teamleiter, nicht der Senior Architect und nicht der Technical Lead. Und wenn alles angepasst werden kann, und alle Entscheidungen vom Team ausgehen, bilden Positionen und Titel da eine Ausnahme? Alles darf angepasst werden, nur die Titel und Positionen nicht? Das Team darf entscheiden und ist verantwortlich, ausser da ist ein Technical Lead, ein Architect oder ein Team Lead?”

Johann-Peter hat damit natürlich vollkommen recht und diese Frage ist genial. Sie zeigt, dass man am Ende auch die eigene Organisation hinterfragen muss. Doch wie wirkt das nach außen? Findet man Entwickler oder Consultants, wenn man nicht explizit nach z.B. „Senior Consultants“ sucht? Ich denke, das ist schwer und das schreibt er auch: „Und dann kommt die Irritation. Denn sie (die Bewerber) wollen Teamleiter, C*O, irgendwas mit Personalverantwortung, Head of *, * Lead oder Senior Architect werden. Auf gar keinen Fall einfach nur Developer. Nein, ein Titel muss her, man will ja die eigene Leistungsfähigkeit in der Karriere abgebildet sehen. Tja, und damit können wir – und viel wichtiger wollen wir – gar nicht dienen. Weder die HR-Abteilung noch die Geschäftsführung kann Leute auf Positionen einstellen oder einen Titel vergeben. Denn die existieren bei uns nicht mehr.”

Diese Idee, dass es keinerlei Positionen mehr gibt und dass es sich natürlich auch auf die Stellenanzeigen auswirkt, ergibt Sinn. Aber Moment … jemand vergibt die Jobs und wählt aus. Der Gesetzgeber verlangt zum Beispiel bei einer GmbH einen Geschäftsführer, der im Interesse der Gesellschaft handelt und möglicherweise sogar die Interessen der Gesellschaft gegen die Interessen der Gesellschafter abwiegt. Er ist also mit Leib und Seele gesetzlich in der Position der Gesamtverantwortung gebunden, ob er das nun persönlich will oder nicht.

Real existieren mehrere Konflikte, die diesem Gedanken auf den ersten Blick widersprechen:

  1. Die Bilder im Kopf der Mitarbeiter
  2. Die gesetzlichen Rahmenbedingungen
  3. Die gelernten Reflexe von Mitarbeitern und Management
  4. Das Umfeld, in dem diese Firmen arbeiten – denn die Kunden wollen oftmals mit dem Senior XY arbeiten.
  5. Die Gesellschafter/das Board – wollen die auch agil?

Nun kann man solche Überlegungen natürlich als Fatamorgana abtun und entgegenhalten: “Das ist altes Denken, traditioneller Quatsch!“ Doch Phänomene weisen uns immer auf etwas hin: Dass da etwas ist – ein zugrunde liegendes Bedürfnis, ein tief sitzender Faktor, der immer mitschwingt und vielleicht erst überwunden werden muss.

Ich kann nur von meinem eigenen kleinen Unternehmen erzählen, denn auch bei uns sind Aufstieg und Verantwortung, Gehaltserhöhungen, Selbst- und Fremdwahrnehmung immer wieder ein Thema. Warum eigentlich? Wir sind “leading edge“ im agilen Umfeld. Wir wissen, was agile Führung bedeutet und wohin der Zug fahren sollte. Wieso straucheln auch wir immer wieder? Ist es, wie ich dem Gespräch mit einem Professor der Psychologie entnommen habe, die Sozialisation? Haben uns die Gesellschaft, Schule, Familie (soziologisch gesprochen: die Institutionen) so geprägt?

Wenn die Graugans in uns schnattert

Ich vermute, die tieferliegende Ursache hinter alledem ist das Thema Rang = Status. Soziale Wesen wollen wissen, in welchem Verhältnis sie zu den anderen stehen – also auf welcher Rangstufe. Das mag jetzt zu simpel sein: Konrad Lorenz war der erste, der das am Verhalten von Graugänsen gezeigt hat. Sofern mich die Erinnerung an meine Biologie-Schulstunden nicht täuscht, arbeitete er heraus, wie wichtig die Hackordnung in sozialen Verbänden ist. Schaut man sich die neueren Erkenntnisse der Neurologie an, so ist genau der Status für uns alle immer ein Thema. Status ist wichtig, weil wir uns in sozialen Verbänden nur dann sicher fühlen, wenn wir wissen, wo wir stehen. Die bereits von Lorenz beschriebenen Phänomene sind u.a. Ausdruck dessen, dass etwas in uns nach Status (Rang, Titel usw.) strebt. Wir alle wollen Auszeichnungen, wir wollen Preise gewinnen und uns von der Masse abheben, Rangkämpfe sind „normal“ und gehören dazu. Sie sind nicht etwa Ausdruck von Machtgier, sondern entstehen aus dem Bedürfnis nach Sicherheit in der Gruppe. Alle, nicht nur „agile“ Teams, erleben diese Suche nach dem Platz in der Gruppe als Verunsicherung in der Storming Phase. Als Wissenschaft ist die Soziologie entstanden, um den Menschen aus der Unmündigkeit der nicht verstandenen Herrschaftsbeziehungen zu befreien. Soziobiologisch sind wir aber in diese Statuskämpfe hineingezwungen und vieles in unserem menschlichen Verhalten lässt sich tatsächlich auf diese Instinkte zurückführen. Aber sind wir ihnen ausgeliefert? Nur dann, wenn wir sie nicht erkennen und uns nicht von ihnen befreien.



Agilität ist eine bewusste Entscheidung

Agiles Arbeiten ist u.a. der Versuch, sich dieser Instinkte bewusst zu werden und immer und immer wieder dagegen anzugehen, um die menschliche Natur zu kultivieren.
Die Beispiele, die in „Reinventing Organizations“, in meinem Buch „Selbstorganisation braucht Führung“ und auch im Blogbeitrag von Johann-Peter Hartmann zu lesen sind, schüren die Hoffnung, dass Menschen in Teams und Organisationen beginnen, diese Zusammenhänge zu verstehen und sich immer wieder bewusst gegen das Eingefahrene entscheiden. Das ist extrem anstrengend für alle Beteiligte. Aber Verhalten lässt sich ändern, auf unterschiedliche Weise. Es beginnt mit dem Glauben daran, dass dieses andere Verhalten für alle befreiender ist und uns glücklicher, gesünder und erfolgreicher macht. Diese bewusste Entscheidung ist es, die uns in die Richtung des agilen Managements führen wird.

Ich finde es toll, dass es Mayflower gelungen ist, die Titel intern abzuschaffen. Ich würde mich sehr freuen, wenn wir in den kommenden Jahren noch öfter solche Artikel von verschiedenen Unternehmen lesen könnten. Ein Beispiel habe ich noch: Seht euch mal die Firma an. Gerhard Andrey hat bei der BWI Fachtagung in Zürich wunderbar erklärt, wie sie es in ihrem Unternehmen umgesetzt haben. Er erzählte über Open Source, über Teams und die Guilds (für die man sich u.a. bewerben muss). Toller Vortrag.

Übrigens: Beim nächsten Treffen des Software Forums Leipzig im November werden wir das Thema Führung und Selbstorganisation beleuchten und miteinander diskutieren. Vielleicht macht ihr mit?

Categories: Blogs

Neo4j: Finding all shortest paths

Mark Needham - Wed, 05/20/2015 - 00:45

One of the Cypher language features we show in Neo4j training courses is the shortest path function which allows you to find the shortest path in terms of number of relationships between two nodes.

Using the movie graph, which you can import via the ‘:play movies’ command in the browser, we’ll first create a ‘KNOWS’ relationship between any people that have appeared in the same movie:

MATCH (p1:Person)-[:ACTED_IN]->()<-[:ACTED_IN]-(p2:Person)
MERGE (p1)-[:KNOWS]-(p2)

Now that we’ve got that relationship we can easily find the shortest path between two people, say Tom Cruise and Tom Hanks:

MATCH (p1:Person {name: "Tom Hanks"}), (p2:Person {name: "Tom Cruise"}),
      path = shortestpath((p1)-[:KNOWS*]-(p2))
Graph  18

That works pretty well but what if we want to find the longest shortest path between any two people in the graph? We can calculate it like this:

MATCH (p1:Person), (p2:Person),
      path = shortestpath((p1)-[:KNOWS*]-(p2))
Graph  19

So that’s 6 hops which is actually the Bacon number – I expect we’d probably see a smaller maximum value if we imported all the movies.

And to round off the post what if we want to find the longest shortest path between the 10 people who acted in the most movies? We might start out with the following query which seems like it should do the job:

MATCH (p1:Person)-[:ACTED_IN]->()
WITH p1, COUNT(*) AS appearances
ORDER BY appearances DESC
WITH p1 AS p1, p1 AS p2
MATCH path = shortestpath((p1)-[:KNOWS*]-(p2))

Unfortunately if we run that query we get no rows returned because ‘p1′ and ‘p2′ always refer to the same node.

Instead we can calculate the shortest path between our hardest working people by creating a cross product using COLLECT and UNWIND:

MATCH (p1:Person)-[:ACTED_IN]->()
WITH p1, COUNT(*) AS appearances
ORDER BY appearances DESC
MATCH path = shortestpath((p1)-[:KNOWS*]-(p2))

Graph  20

That’s all for now!

Categories: Blogs

Knowledge Sharing

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