Skip to content

Feed aggregator

The Agile Journey Begins – or Ends – Depending on your Culture

Danube - Mon, 04/14/2014 - 23:56

 After the Webinar – More Insights from the DevOps Experts, part 1Ask the Expert icon1 300x71 The Agile Journey Begins – or Ends – Depending on your Culture

We recently conducted a webinar called Dev Ops in the Enterprise with Forrester Principal Analyst Kurt Bittner, Gene Kim, co-author of “The Phoenix Project and CollabNet’s own Laurence Sweeny.

The audience engagement was fantastic and we received many insightful questions from our listeners. Here are a few I hand-picked from the audience for Kurt Bittner around: The Agile Journey Begins – or Ends – Depending on your Culture.

Doug: What are some best practices in measuring/surveying the current culture?

Kurt:  Agile practices require cross-functional teams. An organization that has very strong role silos and strong role sub-cultures will struggle with Agile.

Agile works best with flat organizations with a servant-leader management culture.  Organizations with a strongly hierarchical, top-down culture will also struggle with Agile.

Agile also works best when there is transparency and cooperation between the business and the application delivery organization.  Organizations with an adversarial or contractual relationship between business and IT will struggle with agile. Contractual relationships are characterized by the need for contracts and signoffs to record commitments, especially where those contracts are used to transfer risk or to establish an audit trail for denial of responsibility.

Agile requires a learning culture, one able to learn from missteps or mistakes. A culture of blame that punishes failure and largely deals with it by searching for the responsible party and then punishing them will create a culture of fear that is extremely risk averse and unwilling to do anything with an uncertain outcome.  Since most outcomes are uncertain these organizations get very little done beyond the status quo.

Doug: How does one obtain the proper buy-in on necessary changes?

Kurt: There must be a recognition at the top of the organization that the traditional approach is not working, and an imperative need to change.  Leadership must create an environment in which innovation and learning are valued and rewarded. The focus must shift from protecting and rewarding the status quo to seeking out opportunities to improve, and rewarding results. The organization must be willing to break down existing silos and to dismantle the siloed fiefdoms that often permeate traditional organizations.

In addition, obstacles must be removed from Agile teams.  Operations should be streamlined so that appropriate development and test environments are available whenever they are needed.  Teams need appropriate tools right from the start as well – IDEs, SCM, continuous integration, and test automation. They need to be able to develop and test from the first day.

There is also a natural shift in focus from projects, temporary entities that have a defined start and end, to products that are funded and staffed as long-term initiatives. This also means that resources tend to be dedicated and not shared between initiatives.

Finally, the business needs to be fully engaged. They need to stop thinking of their involvement in developing applications as a part-time side project but a full-time commitment. The initiative needs to be important enough to the business for them to fully commit to being involved.

Doug: What are some lessons learned from implementing changes?

Kurt: Having environments available early in the project is really important. Standardizing environment configurations and being able to provision them on demand (sometimes called infrastructure as code) is very important for having those environments available quickly and eliminating hard to diagnose defects that emerge from mismatches in configurations between dev, test and prod (the classic “it works fine on my machine” bugs). Continuous integration is also a key enabler. Reducing batch size and branch duration is also key.

Engaging with the business is key; they need to be active participants, not engaged at “arms length” as they have been in the past. In some organizations the relationship between business and IT is so bad that this is going to be a challenge.  The only real answer to this is evidence of improved delivery.

Lots of organizations fall into the “training trap”. They announce that “agile is the way” with great fanfare and even, in some cases, beautiful posters and “Agile newsletters”. They then send everyone to a training class, perhaps one resulting in becoming a certified Scrum master. They track how many people have taken the training and passed the test, and that’s about it.  Training can establish a baseline understanding but it doesn’t usually achieve anything.  People have to learn by doing.  They have to be allowed to try and fail and learn. They need to be shown new ways of working by people who have already been through it.

Governance models reinforce behavior. If you measure projects using a schedule-driven set of milestones, the project will revert to a waterfall approach. You have to measure progress in terms of business value delivered in order to change behavior.

Architecture matters.  If the application is a traditional legacy system “mud ball of code”, with tight coupling and poor modularity, it will be very hard to deliver in small increments.  Not impossible, but very hard.  Agile works better with mobile and cloud applications because the architectures of those applications tend to be loosely coupled.  Loose coupling allows different parts of the application to change independently, allowing for faster delivery.

Doug: How does one get past the mentality of “There isn’t time to change how we do things, since we are already behind and the customers want us to move forward”?

Kurt: The Japanese poet Ryokan said “If you want to find meaning, stop chasing so many things.” The first thing you need to do is to reduce WIP.  Most of that WIP is probably waste right now anyway.  If you reduce the batch size, limiting the amount you are doing in parallel, you can then focus on trying to improve.  The reduction in waste caused by too much WIP will give you the time and resources  you need to get better.  The challenge is recognizing, and getting the business to recognize, that a lot of what you are doing now is just waste.  As once manager with whom I used to work wisely said, sometimes you need to go slow (at first) to go faster.

What type of Agile culture does your organization have?  

Follow me on Twitter @dribback, @collabnet


The post The Agile Journey Begins – or Ends – Depending on your Culture appeared first on

Categories: Companies

Feature Board and Cards

Scrum Expert - Mon, 04/14/2014 - 20:46
Most of the Scrum teams use a task board to visualize their activity and progress with task cards. In these two blog posts, Keith Clinton, the author of Agile Game Development with Scrum, discusses the concept of feature boards and feature cards. Task cards contain information about individual tasks that will be needed to complete a set of features. Keith Clinton says that the problem of task boards is the lack of visibility of cross-discipline dependencies. In a feature board, cards move around the board depending on the work that is ...
Categories: Communities

Measuring Benefits of Software Development: Traditional vs. Agile

Scott W. Ambler - Agility@Scale - Mon, 04/14/2014 - 20:09

I was recently involved in an online discussion about how to calculate the benefits realized by software development teams.   As with most online discussions it quickly devolved into camps and the conversation didn’t progress much after that.  In this case there was what I would characterize as a traditional project camp and a much smaller agile/lean product camp.  Although each camp had interesting points, the important thing for me in the conversation was the wide cultural and experience gap between the people involved in the conversation.

The following diagram summarizes the main viewpoints and the differences between them.  The traditional project camp promoted a strategy where the potential return on investment (ROI) for a project would be calculated, a decision would be made to finance the project based (partly) on that ROI, the project would run, the solution delivered into production, and then at some point in the future the actual ROI would be calculated.  Everyone was a bit vague on how the actual ROI would be calculated, but they agreed that it could be done although would be driven by the context of the situation.  Of course several people pointed out that it rarely works that way.  Even if the potential ROI was initially calculated it would likely be based on wishful thinking and it would be incredibly unlikely that the actual ROI would be calculated once the solution was in production.  This is because few organizations are actually interested in investing the time to do so and some would even be afraid to do so.  Hence the planned and actual versions of the traditional strategy in the diagram.


The agile/lean camp had a very different vision.  Instead of investing in upfront ROI calculation, which would have required a fair bit of upfront requirements modelling and architectural modelling to get the information, the idea was that we should instead focus on a single feature or small change.  If this change made sense to the stakeholders then it would be implemented, typically on the order of days or weeks instead of months, and put quickly into production.  If your application is properly instrumented, which is becoming more and more common given the growing adoption of DevOps strategies, you can easily determine whether the addition of the new feature/change adds real value.

Cultural differences get in your way  

The traditional project camp certainly believed in their process.  In theory it sounded good, and I’m sure you could make it work, but in practice it was very fragile.  The long feedback cycle, potentially months if not years, pretty much doomed the traditional approach to measuring benefits of software development to failure. The initial ROI guesstimate was often a work of fiction and rarely would it be compared to actuals.  The cultural belief in bureaucracy motivated the traditional project camp to ignore the obvious challenges with their chosen approach.

The agile/lean camp also believed in their strategy.  In theory it works very well, and more and more organizations are clearly pulling this off in practice, but it does require great discipline and investment in your environment.  In particular, you need investment in modern development practices such as continuous integration (CI), continuous deployment (CD), and instrumented solutions (all important aspects of a disciplined agile DevOps strategy).  These are very good things to do anyway, it just so happens that they have an interesting side effect of making it easy (and inexpensive) to measure the actual benefits of changes to your software-based solutions.  The cultural belief in short feedback cycles, in taking a series of smaller steps instead of one large one, and in their ability to automate some potentially complex processes motivated the agile/lean camp to see the traditional camp as hopeless and part of the problem.  

Several people in the traditional project camp struggled to understand the agile/lean approach, which is certainly understandable given how different that vision is compared with traditional software development environments.  Sadly a few of the traditionalists chose to malign the agile/lean strategy instead of respectfully considering it.  They missed an excellent opportunity to learn and potentially improve their game.  Similarly the agilists started to tune out, dropping out of the conversation and forgoing the opportunity to help others see their point of view.  In short, each camp suffered from cultural challenges that prevented them from coherently discussing how to measure the benefits of software development efforts.

How Should You Measure the Effectiveness of Software Development?

Your measurement strategy should meet the following criteria:

  1. Measurements should be actioned.  Both the traditional and agile/lean strategies described above meet this criteria in theory.  However, because few organizations appear willing to calculate ROI after deployment as the traditional approach recommends, in practice the traditional strategy rarely meets this criteria.  It is important to note that I used the word actioned, not actionable.  Key difference.
  2. There must be positive value.  The total cost of taking a measure must be less than the total value of the improvement in decision making you gain.  I think that the traditional strategy falls down dramatically here, which is likely why most organizations don’t actually follow it in practice.  The agile/lean strategy can also fall down WRT this criterion but is much less likely to because the feedback cycle between creating the feature and measuring it is so short (and thus it is easier to identify the change in results to the actual change itself).
  3. The measures must reflect the situation you face.  There are many things you can measure that can give you insight into the ROI of your software development efforts.  Changes in sales levels, how often given screen or function is invoked, savings incurred from a new way of working, improved timeliness of information (and thereby potentially better decision making), customer retention, customer return rate, and many others.  What questions are important to you right now?  What measures can help provide insight into those questions?  It depends on the situation that you face, there are no hard and fast rules.  For a better understanding of complexity factors faced by teams, see The Software Development Context Framework.
  4. The measures should be difficult to game.  Once again, traditional falls down here.  ROI estimates are notoriously flakey because they require people to make guesses about costs, revenues, time frames, and other issues.  The measurements coming out of your instrumented applications are very difficult to game because they’re being generated as the result of doing your day-to-day business.  
  5. The strategy must be compatible with your organization.  Once again, this is a “it depends” type of situation.  Can you imagine trying to convince an agile team to adopt the traditional strategy, or vice versa?  Yes, you can choose to improve over time.  

Not surprisingly, I put a lot more faith in the agile/lean approach to measuring value.  Having said that, I do respect the traditional strategy as there are some situations where it may in fact work. Just not as many as traditional protagonists may believe.

Categories: Blogs, Companies

Validation and Uncertainty

George Dinwiddie’s blog - Mon, 04/14/2014 - 16:54

What an extraordinary conversation I had recently on Twitter. It started with Neil Killick’s statement that we should not consider our stories truly done until validated by actual use. This is a lovely thing, if we can manage it. While I’ve not set such a bold declaration of “done,” I’ve certainly advocated for testing the benefit of what we build in actual use. Deriving user stories from hypothesis of what the users will do, and then measuring actual use against that hypothesis is a very powerful means of producing the right thing—more powerful than any Product Owner or Marketing Manager could otherwise dream up. 

While I often recommend such an approach as part of “Lean Startup in the Enterprise,” when I hear someone else say it, it’s easier to think of potential problems. Paul Boos says it’s “balanced insight.” I fear it’s me being contrary, but I do like to examine multiple sides of a question when I can. In any event, such conversations help me to think deeper about an issue.

The first situation I considered was the solar calibrator for Landsat VII. When you only get one launch date, it’s a bit hard to work incrementally, validating the value with each increment. Instead, we must validate as best we can prior to our single irrevocable commitment. This involves quite a bit of inference from previous satellites, and from phenomena we can measure on earth. We must also predict future conditions as best we can, so that we can plan for both expected conditions and anomalies that we can envision. This is an extreme situation, and it’s quite possible we’ll utterly fail.

So, the conversation turned to ecommerce systems. Surely we can measure user behavior and know what effect a change makes. We can measure the behavior, all right, but even without making any change, we may notice a lot of variance in that behavior. If a variance of 5% to 10% can be expected week-over-week in some measured behavior, then a change that might produce a 1% to 2% change is very hard to detect.

The obvious answer is to maintain a control group. If we present some users with an unchanged system and others with the change, then we can measure the normal variation in the control group and the normal variation plus the variation specific to the change in the experimental group. Given a sufficient number of users, the normal variation should be equal between the two groups.

Is, however, the specific variation a lasting phenomena in response to the essence of the change, or is it transient behavior triggered by the fact that there was a change? In spite of the Hawthorne Effect being a legend based on poor experimental design, novelty does attract interest.

Another difficulty is that the people whose behavior we are measuring are individuals, and vary considerably from one another. When we measure in aggregate, we are averaging across those individuals, and smoothing the rough bumps off of our data. Unfortunately, much of the data is in those rough bumps. What motivates one person to purchase our product may drive another one off. Can’t we segregate our customers into different segments so that we can at least average over smaller, more-targeted groups? If we’re measuring behavior of customers who are logged into our site and whose background and behavioral history we know, then we certainly can. If they are anonymous users, then no, we can’t. Not unless we can spy on them by tracking them around the web through widespread cookies, surreptitious javascript, or other means.

When we gain in one respect, we lose in another. With either of these methods, there may be errors in what we think we know about them. And any time we segment, we’re reducing the quantity in a study group, increasing the chance that our measurements may be due to random chance rather than the change we are studying.

The use of statistics can help us estimate whether or not a variation is specific or random. It can tell us whether the change is statistically significant, and what is our confidence level that it’s not random. It cannot, however, assure us of our conclusions.

Statistics also can only alert us to correlation, not to causation. The behavior change we notice may be due to an overlooked difference that accompanies the difference we’re attempting to measure. If we’re not very careful, then there may be systemic bias that we don’t notice, and we make the wrong presumption from the evidence.

In the world of commerce, we rarely have the opportunity to repeat our experiments to see if they’re repeatable. We want to keep progressing, and so we lose the baseline conditions that would allow us to repeat. Also, our system is just a small part of the daily life of a potential customer. It’s just a small part of the larger system made up of all the other small systems they use. Those other systems also have the capability to change the user’s behavior with our system. Perhaps they change how the user perceives our system can be operated, or sets a different standard for what is considered acceptable.

The world is a bit unpredictable. In the end, we seem to be measuring what happened against what we estimate would have happened, otherwise. Sometimes it may seem very clear to us; sometimes murky. Always we have the possibility of fooling ourselves.

Categories: Blogs

Task Boards: Track the Details

LeanKit Task Boards help you break down and manage the finer details of your work. Seeing each granular task as a part of your visual flow of work promotes visibility for the whole team.   Group and Ungroup Work On the Fly For those, “Oops, those should’ve been grouped together…” moments, cards include a ‘Move to Taskboard’ […]

The post Task Boards: Track the Details appeared first on Blog | LeanKit.

Categories: Companies

How To Solve Problems So They Stay Solved

Why is it that as we approach our goals they seem to be more difficult to achieve? Why is it that things progressing so well seem sooner or later to turn sour? And when things turn sour, how is it that they seem to do so in such a rapid fashion? Why is it that […]

The post How To Solve Problems So They Stay Solved appeared first on Blog | LeanKit.

Categories: Companies

Leveraging the Team for Good PDPs (if you need them)

Learn more about our Scrum and Agile training sessions on

I am currently working with a relatively new Scrum team (5 Sprints/weeks young) that needs to rewrite their Personal Development Plans (PDPs) in order to better support Scrum and the team.  PDPs are still the deliverables of individuals required by the organization and likely will be for some time.  The organization is still in the early days of Agile adoption (pilots) and they are large.  So, instead of giving them a sermon on why metrics for managed individuals are bad, I am going to help them take the step towards Agility that they are ready to take.

The Plan:

  • Facilitate a team workshop to create an initial Skills Matrix;
  • work as a team to develop a PDP for each individual team member that directly supports the team’s high-performance Goal (already established)—
    • in other words, when considering an appropriate PDP per individual, the team will start with the team’s performance Goal and build the individual PDP from there;
  • develop a plan as a team for how the team will support each team member to fulfill his/her individual PDP—
    • in other words, all individual PDPs will be part of the team’s plan for team improvement;
  • Internally publish the plan (share with management).

I’ll follow up with another post to let everyone know how it goes.

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!
Categories: Blogs

Testautomatisierung – die Versicherung für Ihre Software!

Scrum 4 You - Mon, 04/14/2014 - 07:25

Der Ausgangspunkt dieses Beitrags war eine Diskussion zum Thema Testautomatisierung und die Frage, wie deren Vorteile und Nutzen einfach kommuniziert werden können. Mit welchem Beispiel aus der alltäglichen Praxis lässt sich die Testautomatisierung für Software am besten vergleichen? Mir fiel folgender Vergleich ein: Ist denn die Testautomatisierung nicht eigentlich eine Versicherung für die entwickelte Software?

Aber der Reihe nach. Per Definition sind Versicherungen dazu da, ein mögliches Risiko für einen Schadenseintritt abzusichern [1]. Da Software heute in vielen Unternehmen essentiell für deren Wertschöpfungsprozesse ist oder sogar die Wertschöpfung darstellt, ist deren Berücksichtigung für das Risikomanagement des Unternehmens nicht nur sinnvoll, sondern notwendig. Im Rahmen des Risikomanagements müssen mögliche Schadensfälle definiert und bezüglich ihrer Eintrittswahrscheinlichkeit und -schwere klassifiziert und priorisiert werden.

Stellt euch vor, dass das betrachtete Unternehmen 50% seines Umsatzes mit Hilfe eines Online-Shops erwirtschaftet und in diesem wegen eines Softwarefehlers mehrere Stunden keine Bestellungen getätigt werden können. Im realen Leben ein Worst-Case-Szenario, das immer wieder auch renommierte Shop-Betreiber trifft.

In der Lehre des Risikomanagements gibt es verschiedene Varianten, mit einem Risiko umzugehen. Das Risiko kann in Kauf genommen, minimiert, an Dritte übertragen oder gar vermieden werden. [2]

Viele Firmen entscheiden sich bei Software unbewusst für die erste Variante, da sie diese Schadensfälle gar nicht berücksichtigt, geschweige denn berechnet haben. Erst wenn der Schaden eintritt, wird sich ein Unternehmen seines ausgesetzten Risikos bewusst. Dabei wäre es doch so einfach, das Risiko mit Hilfe einer Versicherung auf ein akzeptables Maß zu minimieren. Diese Versicherung ist die Testautomatisierung. Mit Hilfe unzähliger automatisierter Tests werden regelmäßig alle wichtigen Funktionalitäten der Software auf ihre Funktionstüchtigkeit getestet. Diese Tests liefern somit regelmäßig Feedback über das aktuelle Risiko, das von der Software ausgeht. Mit Hilfe von Statistiken und Auswertungen können diese Daten dann in eine unternehmensweite Risikoüberwachung integriert werden.

Testautomatisierung sichert so nicht nur nachhaltig die Qualität und Wartbarkeit der Software, sondern verschafft auch ein Gefühl der Sicherheit, die eigene Software „im Griff“ zu haben. So let us start coding test driven!

[1]  Wiktionary:
[2]  Ahrendts, F.; Martin, A.: IT-Risikomanagement leben! Wirkungsvolle Umsetzung für Projekte in der Softwareentwicklung. Berlin: Springer Verlag, 2008.

Related posts:

  1. Test Driven Development (TDD) und Scrum | Teil 1
  2. Der ScrumMaster ist eine Versicherung (Mike Beedle)
  3. Prioritäten | Product Owners Tools

Categories: Blogs

Why Have a Strategy?

J.D. Meier's Blog - Mon, 04/14/2014 - 06:50

To be able to change it.

Brilliant pithy advice from Professor Jason Davis’ class,Technology Strategy (MIT’s OpenCourseWare.)

Categories: Blogs

Agile Lagging to Leading Metric Path

Even in an Agile environment there is a benefit to applying measures to understand progress.  It can be tempting to apply the same iron triangle metrics (based on cost, schedule, and scope) that may have been used in a more traditional mindset to Agile projects and initiatives.  Instead, I suggest removing all of those metrics and start with a clean slate.  On the clean slate, consider your outcomes.

An Agile mindset asks that you consider outcome instead of output as a measure of success.  This means we should first start with understanding our desired outcomes for an initiative or project.  Within a business context of building products, one measure of success an increase in revenue. Having a customer revenue metric helps you understand whether the products being built are increasing revenue upon release. While capturing revenue is a good starting point, it is a “lagging” indicator meaning you don’t recognize the evidence of revenue movement until after the release is in production and has been in the marketplace for a period of time.
To supplement lagging measures, you need corresponding leading measures and indicators that provide you with visibility during development to gauge if you are moving the product into a position of increased revenue. I call this framework the Lagging to Leading Metric Path.  This visibility is important because it provides input for making decisions as you move forward. Making the right decision leads to improved results. As you consider measures, think about how they help you gain visibility and information for decisions in building a product that helps you lead toward an increase in revenue.
For a hopeful increase in customer revenue, what leading metrics can we put in place to ensure we are moving in the right direction?  Let’s say in this case that increased revenue is the hopeful lagging metric based on expected customer sales.  Examples of leading measures or indicators to achieve an outcome of this lagging metric for increased customer revenue include:
  • Customers attending Sprint Review: a leading metric where you capture how many customers are actually attending the sprint review and how much feedback they give. This indicates engagement and interest. 
  • Customer satisfaction from Sprint Review: a leading metric is capturing customer satisfaction from the functionality they viewed within the sprint review.  This indicates levels of satisfaction with the functionality as the product is being built. 
  • Customer satisfaction of product usage: an indicator of the most recent release highlighting a level of satisfaction on the usage of the current product including commentary.   

When applying Agile to product development, the outcome that matters most are often represented by lagging metrics.  Therefore you will need leading indicators to ensure you are moving in the right direction, to provide visibility, and to help you with decision-making.   Within your own context, consider constructing a lagging to leading metric path so that you know you are moving in the right direction during your Agile journey.

Note: the lagging to leading metric path really isn't specific to Agile and I would suggest applying this to an initiative or project aligning with any mindset, process, method, or practice of delivering value.

To read more about establishing an Agile Lagging to Leading Metric Path and Agile Measures of Success, consider reading Chapter 14 of Being Agile
Categories: Blogs

Neo4j 2.0.0: Query not prepared correctly / Type mismatch: expected Map

Mark Needham - Sun, 04/13/2014 - 19:40

I was playing around with Neo4j’s Cypher last weekend and found myself accidentally running some queries against an earlier version of the Neo4j 2.0 series (2.0.0).

My first query started with a map and I wanted to create a person from an identifier inside the map:

WITH {person: {id: 1}} AS params
MERGE (p:Person {id:})

When I ran the query I got this error:

==> SyntaxException: Type mismatch: expected Map but was Boolean, Number, String or Collection<Any> (line 1, column 62)
==> "WITH {person: {id: 1}} AS params MERGE (p:Person {id:}) RETURN p"

If we try the same query in 2.0.1 it works as we’d expect:

==> +---------------+
==> | p             |
==> +---------------+
==> | Node[1]{id:} |
==> +---------------+
==> 1 row
==> Nodes created: 1
==> Properties set: 1
==> Labels added: 1
==> 47 ms

My next query was the following which links topics of interest to a person:

WITH {topics: [{name: "Java"}, {name: "Neo4j"}]} AS params
MERGE (p:Person {id: 2})
FOREACH(t IN params.topics | 
  MERGE (topic:Topic {name:})
  MERGE (p)-[:INTERESTED_IN]->(topic)

In 2.0.0 that query fails like so:

==> InternalException: Query not prepared correctly!

but if we try it in 2.0.1 we’ll see that it works as well:

==> +---------------+
==> | p             |
==> +---------------+
==> | Node[4]{id:2} |
==> +---------------+
==> 1 row
==> Nodes created: 1
==> Relationships created: 2
==> Properties set: 1
==> Labels added: 1
==> 53 ms

So if you’re seeing either of those errors then get yourself upgraded to 2.0.1 as well!

Categories: Blogs

Quarterly Product Update Webinar

Join us for a roundup of LeanKit’s newest and upcoming features on Thursday, May 1 at 1pm ET.  Jon Terry, LeanKit’s COO, will give a live update and answer questions. During this webinar, you’ll learn how to:  Visualize your date-driven work with the new Calendar View Get the most out of recent UI enhancements Stay connected with […]

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

Categories: Companies

Effective Agile at Scale Webinar Series

Net Objectives gets straight to the point when it comes to describing Agile, reminding us that it’s not about iterations, teams, co-location or any of the ways it may be implemented. Instead, Agile is about the fast delivery of business value in a predictable, repeatable manner. With this perspective in mind, join Al Shalloway, CEO of […]

The post Effective Agile at Scale Webinar Series appeared first on Blog | LeanKit.

Categories: Companies

Social Intelligence and 95 Articles to Give You an Unfair Advantage

J.D. Meier's Blog - Sun, 04/13/2014 - 15:56

Social Intelligence is hot.

I added a new category at Sources of Insight to put the power of Social Intelligence at your fingertips:

Social Intelligence

(Note that you can get to Social Intelligence from the menu under “More Topics …”)

I wanted a simple category to capture and consolidate the wealth of insights around interpersonal communication, relationships, conflict, influence, negotiation, and more.   There are 95 articles in this category, and growing, and it includes everything from forging friendships to dealing with people you can’t stand, to building better relationships with your boss.

According to Wikipedia, “Social intelligence is the capacity to effectively negotiate complex social relationships and environments.”

There's a great book on Social Intelligence by Daniel Goleman:

Social Intelligence, The New Science of Human Relationships

According to Goleman, “We are constantly engaged in a ‘neural ballet’ that connects our brain to the brains with those around us.”

Goleman says:

“Our reactions to others, and theirs to us, have a far-reaching biological impact, sending out cascades of hormones that regulate everything from our hearts to our immune systems, making good relationships act like vitamins—and bad relationships like poisons. We can ‘catch’ other people’s emotions the way we catch a cold, and the consequences of isolation or relentless social stress can be life-shortening. Goleman explains the surprising accuracy of first impressions, the basis of charisma and emotional power, the complexity of sexual attraction, and how we detect lies. He describes the ‘dark side’ of social intelligence, from narcissism to Machiavellianism and psychopathy. He also reveals our astonishing capacity for ‘mindsight,’ as well as the tragedy of those, like autistic children, whose mindsight is impaired.”

According to the Leadership Lab for Corporate Social Innovation, by Dr. Claus Otto Scharmer  (MIT OpenCourseware), there is a relational shift:

The Rise of the Network Society

And, of course, Social is taking off as a hot technology in the Enterprise arena.  It’s changing the game, and changing how people innovate, communicate, and collaborate in a comprehensive collaboration sort of way.

Here is a sampling of some of my Social Intelligence articles to get you started:

5 Conversations to Have with Your Boss
6 Styles Under Stress
10 Types of Difficult People
Antiheckler Technique
Ask, Mirror, Paraphrase and Prime
Cooperative Controversy Over Competitive Controversy
Coping with Power-Clutchers, Paranoids and Perfectionists
Dealing with People You Can't Stand
Expectation Management
How To Consistently Build a Winning Team
How To Deal With Criticism
How Do You Choose a Friend?
How To Repair a Broken Work Relationship
Mutual Purpose
Superordinate Goals
The Lens of Human Understanding
The Politically Competent Leader, The Political Analyst, and the Consensus Builder
Work on Me First

If you really want to dive in here, you can brows the full collection at:

Social Intelligence

Enjoy, and may the power of Social Intelligence be with you.

Categories: Blogs

Scrum, XP, SAFe, Kanban: Which Method Is Suitable for My Organization?

Agile World - Venkatesh Krishnamurthy - Sun, 04/13/2014 - 14:12

image I have recently seen the SAFe framework criticized by the Scrum founder as well as the Kanban founder (see "unSAFEe at Any Speed" and "Kanban -- The Anti-SAFe for Almost a Decade Already"). Method wars are not new, however, and could go on forever. In the face of these discussions, it is important to remember the real intent behind Agile methods.

In this recently published Cutter article, I discuss the importance of understanding Agile as a tool rather than as a goal.  I am also proposing some ideas from complexity theory and Cynefin framework to substantiate the need for parallel/safe to fail experiments rather than  handcuffing organizations with single framework/method or a process.

Read the complete article on Cutter


Photo courtesy: Flickr

Categories: Blogs

Question: Advice to a beginning ScrumMaster

Agile & Business - Joseph Little - Sun, 04/13/2014 - 00:31

Virginia asks: “I am a beginning ScrumMaster in a tough situation.  I have some ideas, but I am unsure what to do.  And unsure what to do first.  What can you suggest?”

Answer:  I think this is a common problem.

But, in reality, there is no end of things that a ScrumMaster can do to help the team.

First, take what you already know about Scrum, and remind the Team what Scrum is.  And why….what the values and principles are.

This can be done in a thousand ways.  One example: Post the Agile Manifesto and the Agile Principles in the Team room.  After each Daily Scrum, ask each member of the Team to take two minutes to explain something about one line or one item from the list.

You will be impressed how well they explain the agile ideas to each other.  And then, you can add an additional insight. Maybe something you think they could improve on.

Read or re-read Agile Project Management with Scrum by Schwaber to get lots of stories and ideas about how Scrum should work.

Second, get a better list of impediments.  Ok, let’s be honest — START a list, a public list.  Yes, of course collect the ones they tell you in the Daily Scrum and in the Retrospective.  Add the ones that you see.  Read this blog, and steal some impediments that apply to you and your team.

You want a list of the top 20 things to improve, broken down into actionable things, where you could see, smell, notice improvement in 2 weeks or less.  Yes, you often start with some epic impediments…but just start there…

An impediment is anything, ANYTHING, that is slowing down the Team. Example: Anything that stops a story, slows down the Team. People issues, technical issues, organizational issues, the weather, I need coffee, I need a dentist, we need a different culture, whatever. Whatever.

Ok, we have to discuss two things that happen universally in the Daily Scrum, at least at first.  They don’t divide the tasks into small pieces, and they talk vaguely about what they worked on, and do not focus on what was DONE (completed).  The tasks must be mostly in the 2-4 hour range.  And they must say whether or not it was completed. If a 4 hour task is not completed in one day, clearly there is some kind of ‘impediment’ (eg, I cannot estimate very well).

Then, they must give their biggest impediment. (What slowed them down the most.)  Time itself is not an impediment.

It might be: “I don’t know this area that well.”  Or: “The servers were down.”  Or: “Well, if the tests were automated, then I could have found the bad code faster.”  Or lots of other things.  Saying: “None” is not an option.  Implying that ‘things are so good around here, that there is no way it could possibly get better’ is also not an option.  Things can always be better.

Also, you must give them a challenge.  Tell them: “We have to double the velocity, in a way that we believe, and not by working any harder.  So, what do we have to change to do that?  And imagine that anything could change. Anything. And that the managers will approve anything, if we can make a good case for it.”

For the Retrospective, see also Agile Retrospectives by Derby and Larsen for more ideas to uncover the real impediments. They have forgotten lots of impediments because they have become used to them, or they can’t imagine that it could be changed.

Third, aggressively attack the impediments.  Every day. Every hour.  Take the top one, and go after it. If you can’t fix it yourself, that is fine.  But get someone to.

I do not mean go crazy. Use some common sense. If the cost is greater than the benefit, than do solve it that way.  Sometimes you can only mitigate the impact. Etc, etc.  But still, every day and every hour, attack the top impediment.

Fourth, tell them.  Tell the right people what you will do, what you are doing, and what you have done.

Mostly, you tell the Team.

How?  In the Daily Scrum (you answer the questions, and tell them).  In the Retrospective.  And in other ways that make sense.

Why?  Well, not to brag as such.  But you need to know they care.  They want the ‘fix’ that you will give, are giving, did give them.  Also, once they know things are getting fixed, they will get more creative about talking about things you could fix.

Fifth, keep a list of ‘fixes installed.’  All the things you did, or got done, to make their lives better.

Why? So, when you are discouraged, you can look at the list and get some encouragement.  So, so when the wonder why you are not doing ‘real work’, you can remind them of your value.  So you can justify the managers why you deserve a raise.

Track the list, and make a reasonable guess as to how much of the improved velocity of the team is attributable to the fixed or mitigated impediments. Typically 100% is effectively attributable to you.  Yes, Scrum itself did some (but you still take credit). Yes, the Team did some things, but honestly probably would have done very little without you, or would have done it very much later.  It does not matter that you did not do it ‘with your own hands’.  You made it happen, you were the key.  It does not matter than some improvements cost ‘extra’ money. The benefits were huge, and mostly would never have happened without you.

Do not slack for even one day.

The Team and the customers deserve everything you have to give.  And you too will be rewarded in ways hard to explain but very clear…by all the good things you make happen.

Sixth, to help you become a better ScrumMaster faster, start a ScrumMasters club with other SMs in your area.

Learn from each other. Maybe have a brown bag once a week, and present ideas and experiences to each other once per week over lunch.

That’s a start. There are many places and ways to learn.  As you act, you will discover more ways to learn, and more things to learn about.

Does that help?


Categories: Blogs

Five links on Software Design

The real lessons in software development come from production. The more frequently you can deploy – more feedback you can generate






I don’t claim these articles to be the best on this subject, but I have enjoyed reading them and they have made my knowledge grow. I recommend you to have a look if you are interested in the subject. Happy reading!

Follow me on twitter @hlarsson for more links on a daily basis. You may also subscribe to weekly newsletter of my links. Thanks to writers of these articles and Kirill Klimov for collecting the agile quotes: Please follow @agilequote for more quotes.

Categories: Blogs

The Industry Life Cycle

J.D. Meier's Blog - Sat, 04/12/2014 - 21:27

I’m a fan of simple models that help you see things you might otherwise miss, or that help explain how things work, or that simply show you a good lens for looking at the world around you.

Here’s a simple Industry Life Cycle model that I found in Professor Jason Davis’ class, Technology Strategy (MIT’s OpenCourseWare.)


It’s a simple backdrop and that’s good.  It’s good because there is a lot of complexity in the transitions, and there are may big ideas that all build on top of this simple frame.

Sometimes the most important thing to do with a model is to use it as a map.

What stage is your industry in?

Categories: Blogs

Security Update on CVE-2014-0160 Heartbleed - scrum software - Sat, 04/12/2014 - 05:30

OpenSSL, the open source cryptographic library reported the Heartbleed vulnerability on April 7, 2014. The vulnerability allows stealing the information protected, under normal conditions, by SSL/TLS encryption.

We have had no evidence that this vulnerability was used against Sprintly but we have taken all necessary precautions to ensure the continued safety of your information. 

Actions We Have Taken 

  1. Within hours of the official report from OpenSSL, we patched and verified all our servers for CVE-2014-0160. 
  2. We use Amazon’s ELB product for load balancing. They patched our region a few hours before we patched our servers. 
  3. We have re-issued new SSL certificates to all our servers. 
  4. We have rotated all of our SSH, Chef, and AWS API keys throughout our infrastructure. 
  5. We have rotated all 3rd party API keys we use to provide services, such as Transloadit (file processing) and Postmark (email).
  6. We have set up our Chef nodes to re-key themselves every 24 hours. We suggest you do the same
  7. Friday night we flushed all active sessions. This means you will have to log into Sprintly again when you get back to work Monday. Apologies in advance for any inconveniences.

Additional Precautions 

You may consider taking these additional precautionary measures on your Sprintly account: 

  1. Change your Sprintly password 
  2. Reset your Sprintly API key 

Both settings may be found in the Profile menu under your Gravatar. 

Again, we have had no indication that this vulnerability was used against Sprintly but do feel that it is a good habit to keep your passwords and security keys regularly updated. 

If you have any questions or concerns, please feel free to contact us at

Categories: Companies

LeanKit Services Not Affected by Heartbleed

You may have heard recent reports of a vulnerability, commonly known as “Heartbleed,” that affects the popular open-source library OpenSSL. We have confirmed that the LeanKit application and our internal supporting services are not affected by this vulnerability. This bug, officially referenced as CVE-2014-0160, is not an issue with the design of SSL but is […]

The post LeanKit Services Not Affected by Heartbleed appeared first on Blog | LeanKit.

Categories: Companies

Knowledge Sharing

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