News
Analyzed 8 days
ago based on code collected 8 days ago.
|
Posted
2 days
ago
by
dave.sh...@agile42.com (davesharrock)
One of the principles of agility is transparency - making the flow of work visible. It is common for the development team to use task boards and burndown charts, and we've found that extending this practice to the product management team is just as
... [More]
valuable. No surprise there.
We have found this to be especially valuable, as the PO Team tends to be less agile due to their background. Most accept that the dev team is doing something weird and that they are required to provide different “specifications” but if you manage to set up a board and make their work more transparent, it is a vital step towards true agility for the POs and therefore for the whole organization. However, the PO Board itself has some subtleties that reflect the needs of the product management team. The PO Board provides the context for working on a specific product. In particular, by combining the product vision and the emerging requirements and features the PO Board allows incoming work to be simply and easily cross-checked with the product strategy, keeping a focus on the long-term aims of the product, rather than near-term distractions. Starting with a clear description of the product vision, including the requirements identified to deliver on that vision, the PO Board always includes the contextual information required to decide whether a feature or work request should be included in the backlog and worked on by the product management team, let alone the development team. Beneath the product vision and requirements, we capture all feature requests associated with the product. At this stage, no prioritization is used. This is simply our someday-maybe pile for consideration in the future. As we begin release planning, the features in the someday-maybe pool are moved to the beginning of the task board in order of priority. Depending on the agreed process for integrating new ideas, the board will have a number of columns describing the stages a new idea goes through: investigation and sharing with the architects and technical leads, or the customers and stakeholders during the elicitation and definition process. The result is a feature board that exposes the progress made on defining, grooming, developing and deploying product features (see diagram). Starting from the top left, the highest priority feature is defined, split into stories, discussed and groomed with the team, and eventually enters the team's backlog. As we move down the board, we can see when the next release will be complete and what it, and the one or two releases after that, will contain. As we move across the board, we can see where each feature is in the definition process. Several things become clear when the PO Board is used. - First, the team no longer considers the grooming and backlog definition process something that happens right before the team starts work. The depth of research, requirements definition and preparatory work becomes much more clear. In fact, in one client we worked with, the PO Board allowed the organization to see how poorly staffed the product management team was (queues forming long before stories hit the development team's backlog). - Second, queues can be allowed where there are quality gates, traditionally defined by a form of Definition of Done, which helps clarify hand-off between columns (and in particular, between different teams/individuals): For stories ready to be groomed and sized, we use a Definition of Ready; For stories that are complete, but not fully integrated or acceptance tested, we use a Story Definition of Done; For stories accepted by the customer and ready for deployment, we use a Release Definition of Done. In conclusion, the transparency brought about by the PO Board brings to the PO team many of the benefits we see with development teams. It quickly exposes dysfunction, bottlenecks and inaccurate assumptions. It acts as a brake on starting urgent tasks over important tasks. It reinforces the need to focus on a small number of items at any one time. It encompasses the entire value chain, focussing on delivery to the customer rather than the development team. And of course, it introduces agile principles to teams outside core development. [Less] |
||||||
|
Posted
8 days
ago
by
kruse...@googlemail.com (ralfkruse81)
I am looking forward to have my talk tomorrow at the Scrum-day!
The idea behind my talk arose from the last Scrumday. There was already the focus on scaling, but the most of the attention was direct to "how it looks like" and ... [More] "how you should do it", but not so much on WHY doing it. For me finding the best solution for your organization, your team is highly depending on where you are and where you want to be. This is the reason why I tried to focus my talk on "Is your organization reaping the possible benefits of scaling agile? " I will share my slides with nice hand made drawing on slideshare, but I hope to see you there in person :-) For more information about the Conference agenda please have a look here: http://www.scrum-day.de/index.php http://www.scrum-day.de/agenda/index.php http://www.scrum-day.de/vortraege/isyourorganisationreapingthepossiblebenefits.html [Less] |
||||||
|
Posted
12 days
ago
by
marion.e...@agilosoftware.com (marion)
Hello All,
we are happy to announce the next Berlin Scrumtisch scheduled for April 26th: Date: 26th of June, 2013 Time: 18:30 Place: Cafe Restaurant Deseo, Boxhagener Str. ... [More] 108, http://www.deseo-restaurant.de/ For this Scrumtisch I invited Bent Myllerup from Denmark. Bent is a Systemic Coach, CSC and CST and will give us some insides in personal Coaching. I am still waiting for his confirmation, if he can make it on th 26th but since I cross fingers. If you would like to attend, please send an email to scrumtisch@agile42.com, or register at the Scrum User Group on Xing :-) We are looking forward to seeing you all again and sharing a nice evening with good learnings! :) Marion [Less] |
||||||
|
Posted
13 days
ago
by
brad.s...@agile42.com (bswanson)
Agile Transformation Failure Modes
Lack of Executive Commitment An enterprise agile transformation requires sustained commitment, effort and a focused sense of urgency from the leadership team. Lukewarm commitment or incongruent messages ... [More] from leaders are quickly detected, legitimizing apathy and delay, and stalling the transformation before it gains the momentum needed to create lasting organizational change. Overburdened Teams When teams and managers face a daunting array of volatile, short-term priorities, they have no capacity to learn a new system for working. Failing to pursue clarity of purpose or to allow teams the time to learn sends the message that we are not serious enough to prioritize our current workload. And, because people revert to old habits and behaviors under pressure, it reduces the window of opportunity for change. Failure to Build Consensus Even when leaders have a clear vision for change, a critical mass of people in each team, and across the organization, must believe in and support that vision in order to reach the tipping point where sustainable change is driven from the inside. Many organizations forget to build consensus as they move from highly localized pilots with early adopters to broader adoption impacting a wider cross-section of the company. Weak Strategy Many agile adoption strategies are too narrowly focussed or light-weight, not recognizing the magnitude of the organizational change problem. Common weaknesses include an over-reliance on training alone without coaching and failure to build an internal coaching capability for scaling and sustaining changes. A weak strategy can leave the agile transformation isolated and under-resourced just as the scale of the change emerges. Underestimating the Importance of Culture In the 2011 VersionOne ‘State of Agile’ survey, the #1 barrier to agile adoption cited by 52% of respondents was the ‘inability to change organizational culture.’ A strong culture is what allows a company to scale and grow without rigid rules. But when a change in culture is needed, the very strength of the culture works against you. Culture will eat your strategy for breakfast. You’d better plan for it. Silo’d Agile Adoption Reaping the full benefits of agile practices requires alignment across the entire value stream. When agile adoption is limited to a single silo or department (e.g. IT or R&D), a dissonance begins to emerge with the departments in the rest of the organization, where Sales, Marketing, Operations, Finance and even HR practices find themselves at odds with - and unable to keep up with - agile practices. Practices Without Principles Agile development is first and foremost a set of values and principles for managing uncertainty and complexity while showing great respect for people. These values and principles guide the process improvement, strengthening the learning process. Knowing how to implement practices is necessary but not sufficient for an organization to continually improve and achieve organizational agility. Neglecting the Need for Technical Excellence Although Agile will improve most processes immediately, sustained improvement when building high quality software and systems in short cycles requires disciplined and rigorous technical practices like continuous integration and deployment, refactoring, test automation and test-driven development. This requires a culture of technical craftsmanship. And Success Modes to make it work… While there is no recipe for successful enterprise agile transformation that works in all contexts there are some critical ingredients and principles common to any successful agile adoption strategy: Urgency and Commitment Change is painful, and anyone will avoid the pain if there isn’t a good reason to go through it. A shared sense of urgency, a belief that change right now is critical to an organization’s success, and that the pain is shared across the organization -- this brings people together, removing obstacles allowing tough decisions to be made. Following an organizational change adoption framework, such as John Kotter’s 8-steps to Leading Change, can help align people and build momentum and support for the change. Develop a sense of urgency, create a guiding coalition, and begin communicating the strategy. Transparency Radical transparency has to be one of the most underrated tools for changing behavior. Ford Motor Co. started turning around when Alan Mulally recognized the need for transparency into what was really happening in the company - red and amber dashboards started emerging in a culture dominated by green-light reporting. Leaders can set the example by making the change process open and transparent, and the vision and strategy highly visible to everyone in order to gain buy-in. Leaders must put themselves in a vulnerable position of making bold decisions with high visibility; this leadership by example demonstrates the commitment to change and empowers others to act on their own. Focus Making a commitment to an enterprise agile transition means clearly and visibly saying ‘No’ to other organizational initiatives. Most organizations are stretched thin today, working on too many projects in too many domains. Steve Jobs, on returning to Apple, refocused the company on just 4 products, stopping development on many potential product lines to bring about the shift needed to make Apple great once more. Leaders must communicate unambiguous delivery priorities at the organization and portfolio levels so development and operational teams can align around common goals, and this invariably means stopping many activities in progress in order to focus on a few critical priorities. “Stop starting, start finishing.” Investment in Continuous Learning Eric Ries wrote, “the only way to win is to learn faster than anyone else.” As technologies and trends such as social media speed up the pace of feedback, companies that are able to utilize this information will prosper. The capability to both analyze data, respond to new information and execute on it becomes more and more valuable. But mistakes must be tolerated, even celebrated, and rigorous validated learning encouraged in order for innovation to occur -- often at the perceived price of the status of the resident experts. If lean thinking teaches us to pursue perfection, which is approachable but never attainable, then agile thinking allows us to incrementally move towards that perfection through its core practices that promote continual learning and improvement. [Less] |
||||||
|
Posted
13 days
ago
by
kruse...@googlemail.com (ralfkruse81)
I am looking forward to play the Kanban Pizza Game™ at Limited WIP Society Hamburg.
It’s difficult to teach the principles of Lean and Agile simply by lecturing. People have to experience the principles by ... [More] themselves to get a feeling for how it all works. By playing the Kanban Pizza Game™, you will enter the Kanban world in an playful way. The game looks simple, but the facilitation has it's pitfalls. :-) Since we invented the Kanban Pizza Game™ two years ago we played it with various customers and Agile User Groups.Through these experiences we improved the game and added new ideas. Today the Kanban Pizza Game™ is famous and known as one of the best tools to introduce Kanban to a team. The Kanban Pizza Game™ is pubished under the Creative Commens Licenses and you can find a comprehensive description on our website. I am looking forward to play the Kanban Pizza Game™ at Limited WIP Society Hamburg. And I like to invite you to be friend with the Game on Facebook. Let's Play Ralf Kruse [Less] |
||||||
|
Posted
21 days
ago
by
kruse...@googlemail.com (ralfkruse81)
Get the chance to play with us!
I am happy to announce that Saturday, June 15th I will be at the Lean & Kanban conference DARE 2013 in Antwerp with the Kanban Pizza Game. Nick Oostvogels, one of the organizers of the conference ... [More] , describes DARE 2013 as “a conference for those brave souls who want to change the ordinary and take changes. A place to get fresh ideas how to turn your business into a success.” So I am sure that this is the right place where play to our Kanban Pizza Game ;-) We invented the Kanban Pizza Game a year ago with the purpose to teach the principles of Lean and Agile in an effective and fun way. In the Kanban Pizza Game, you will experience firsthand the benefits of a Kanban System, by simulating the frantic pace of ordering pizza. While other Kanban Games usually focus only on the flow of an existing Kanban System, the Kanban Pizza Game demonstrates the path from an existing process to a Kanban System and starts right where you are. Kanban helps you to: Put a focus on delivering value quickly and effectively; Address problems with queues and bottlenecks; Facilitate interactions between people; Keep focusing on the system as a whole. You will learn to use the five basic practices of Kanban (Visualize the workflow, Limit WIP, Manage Flow, Make Process Policies Explicit & Improve Collaboratively) and at the end understand how Kanban and its evolutionary approach to change can be applied to software development. The game is fun, the activity level stays high and it offers a complex simulation that includes changes in flow, while the difficulty progresses. I believe that playing is an integral and very effective part of learning, as it opens people's minds and hearts and creates the emotional connections that makes experiences stick. And we have experienced that the right games help people to discover, experience, and greatly accelerate learning. For more information about the Conference agenda please have a look here http://www.dare2013.be/program/ http://www.dare2013.be/speaker/ralf-kruse/ A Detailed description of the Kanban Pizza Game can be found at: Join also the Kanban Fanpage on Facebook [Less] |
||||||
|
Posted
26 days
ago
by
manny.s...@agile42.com (mannysegarra)
The role of agile coach encompasses the responsibilities of Change, replacing the old inefficient ways with value adding tasks, in process, bureaucracy or otherwise. Here lies the danger and inherent resistance from the implicit company culture
... [More]
to agile and its transparent ways. In the dark corners of bureaucracy and inert processes, will you find a Dark Champion, someone for whom the status quo is king and will fight, indirectly and in the shadows, to keep things the way they are… As an Agile Champion, you bring Courage and Knowledge to the arena…
Resistant to change The Dark Champion, the Dark for short, will find a wedge to come between those whom seek change and those whom wish to change but lack the motivation to rise up. The Dark uses fear of change to highlight the loss of power to some and prestige to others. The comfort of the old way will be the wedge for the rest. All fear, regardless of source, must be brought out in the open, only then can empathy and knowledge be applied through acceptance and closure. Unlike agile, which espouses self-empowered teams to manage change, there is no comfort in change you cannot control. I remind teams of an old business axiom “Change or Die”, a saying from well before my time, proven effective by nature through evolution. Instill Courage in teams to shape their change, so prestige is gained by through predictability, power is gained through reliability by delivering on your sprint commits. Some feel change will remove them from being the ‘go to guy’, a legitimate fear for people whom have become accustom to being the center of attention. This can be overcome by helping people evolve into the ‘go to team’. Hides in plain sight, Politics as a cloak of invisibility The Dark uses politics to hide in plain sight…the Cloak of Invisibility is used to hide mediocrity, redundancy and increased opacity, the opposite of Transparency, one of the five Scrum values. Political tactics are beyond the scope of this blog post, but knowing who your enemy is, helps out. This Dark Champion, The Baron, reports to the boss, has the power of process, HR or otherwise, and uses the power of redundancy to slow down your agile initiatives. When and how change is implemented, the Baron will proclaim “we must adhere to regulations”. Mercy for you if the Baron is supported by legal regulations such as HIPPA or Sar-Ox! The Baron is brought into the open with a reassignment of power. Although the SM is usually in charge of scheduling the scrum rituals, the Baron is minimized by delegating these duties to him. The perspective here is for the rituals of Scrum not to interfere, but enhance process improvement. Inclusion, empowerment and participation are tools the agile coach or ScrumMaster (SM) can use against the Baron, perhaps by going so far as to let the Baron facilitate the rituals as well? The Dark Champion of Mediocrity takes the forms of the middle manager. The Dark is responsible for inefficient forms and procedures and resists agile and the call for improvement; a prime example is the TPS report (see the movie, Office Space!) is threatened by agile’s focus on performance and teamwork. The Dark will use fear of change especially towards those whom are used to less than stellar work efforts. Fear is presented as resistance and takes root as apathy. Once apathy has taken hold then, the Dark will team with the Baron to stymie and outlast you with inertia! The Agile Champion could propose a strategy to improve team performance, with a modification to HR processes which focus on promotion and bonuses. Insert a ‘team score’ along with individual performance, so that team wins and losses have an effect on each team member’s overall performance metrics. This defeats mediocrity and compels those who work less, to work harder, now that everyone’s bonus is dependent on their efforts as well. For example, use two scores for performance, an individual scale from 1 – 10 and a team score which uses the same scale. These two numbers are multiplied together (individual score is 8 – great programmer, team score is 5 – needs to pitch in more: 8 x 5 = 40 overall score). The implicit peer pressure to perform removes part of the motivational burden from the coach and correctly focuses it on the team members to motivate one another. Part two of this blog, ‘Gathering Allies for Change’ will discuss who can help you in the struggle for Scrum and how they can are empowered to overcome the resistance to Change. [Less] |
||||||
|
Posted
27 days
ago
by
marion.e...@agilosoftware.com (marion)
Topic Backlog
Transition from technical role to PO role (2) When to do estimations (2) Agile vs. management culture (6/7) Intrinsic motivation in an agile environment (5) How to tell management to relax (4) How to handle ... [More] weak POs (3) Why Scrum does not work (2) Agile vs. Management Culture The host of this topic had the example that new, unknown stakeholders join Sprint Reviews and come with new requirements without knowing anything about agile and the team's new development approach. The question now was how to handle management and stakeholders who has no knowledge about agile. Following ideas were discussed: welcome new attendees at the Review meeting and explain the meeting/format enable the PO to do proper stakeholder management explain to stakeholders before and during the project how Scrum works stakeholders need to share the vision PO role and person needs legitimisation by management Intrinsic Motivation in an Agile Environment We had a more general discussion about motivators, intrinsic and extrinsic motivation. Following points have been mentioned: people on the project need to share the vision team decides how to split rewards (if there are any, as rewards are extrinsic motivators) people involved in decision making are more motivated to act upon it (so Scrum is a good way to realise such involvement in every meeting) everybody has different motivators = handle people individually enable appreciation between team members know exactly what drives yourself There were some book recommendations as well: Julius Kuhl - Die Kunst der Selbstmotivation Daniel Pink - Drive Chip Conley - Peak How to Tell Management to Relax The example observations of the topic host were: story points / velocity are taken too seriously retrospectives contain 80% negative topics management does not see things that go right Discussed suggestions: make every Review meeting awesome and useful for management explain how Scrum/Agile works to management keep management busy with other things build up trust with stakeholders Schnitzel and ongoing talks Finally we ordered some food and had ongoing discussions on the topics. It was a great evening and we're looking forward to see you at the next Scrumtisch here in Berlin. [Less] |
||||||
|
Posted
28 days
ago
by
ales...@sevenseas.org (abragad)
Organized by the Scrum Alliance, the Scrum Gathering in Las Vegas in early May has been a great success and the first sold out Gathering with over 500 attendees! For members of Scrum Alliance all presentations are now posted online on the
... [More]
organization's site under the Presentations tab.
Coaches from agile42 were present as always and you can also find their presentations here. Dave Sharrock presented Giving Teams the Roots to Grow and Wings to Fly, an interactive session introducing useful and proven practices that increase the sticking power of new agile teams, allowing them to stay agile long into the future. In fact, to create sustainable change, agile teams have to overcome organizational gravity that pulls them back into the old, comfortable ways of working. You can check the slides and note of Giving Teams the Roots to Grow and Wings to Fly on SlideShare. Brad Swanson presented From Doing Scrum to Being Agile: Lessons Learned Transforming a Culture, a case study of the agile transformation at Ericsson Mobile Core from 2009-2012 and using John Kotter's 8-step change model for leading the change. Slides for Transforming a culture using Kotter’s change model: a case study are available on SlideShare as well. Dave has also presented the talk The Challenge for the next Decade… because Andrea Tomasini could not be in Las Vegas. The next Scrum Gathering will be in Paris, September 23-25. [Less] |
||||||
|
Posted
about 1 month
ago
by
dave.sh...@agile42.com (davesharrock)
Companies typically have a large number of active or valuable work to be done at any one time, all at various stages of development. Performance improvement often focuses on how to do more, not how to do less. Therefore, limiting the volume of
... [More]
requests being done seems to go counter to the overall goal. In fact, many systems speed up when the volume of work being worked on decreases.
The Traffic Flow Problem A reasonable metaphor for this is the speed-density-flow relationship seen in traffic studies. Figure 1 shows the classic relationship, where flow = speed x density. In the case of traffic, the speed of the traffic increases (from a standstill) as the number of cars on the road falls. The flow of traffic on the road, on the other hand, increases to a point, but then falls off as the number of cars on the road falls below a certain number, however fast they are going. In other words, there is excess capacity in the system as the number of cars on the road falls. Figure 1: The graph shows the relationship between speed, density and flow for traffic on a highway. The higher the volume of traffic, the slower the speed of the cars, and the lower the flow of cars along the highway. However, as the number of cars on the highway falls, the flow will also drop off even as the cars go as fast as they can (hopefully at the speed limit). In the case of work requests entering development, the flow of work through the system changes in the same way, increasing to a point, but then decreasing rapidly as the volume of work requests increases. Unfortunately most systems operate at or above capacity, at which point there is a negatively reinforcing feedback loop driving the performance down (Figure 2). Once a system has passed its optimal flow regime, additional work requests quickly decrease the performance of the system, causing longer wait times as more work requests pile up, which can lead to more requests being worked on, decreasing the performance (throughput) of the system even more. Figure 2: Above the maximum capacity of the system (when the flow through the system is at its highest), we see a negatively reinforcing loop. That is, as the density of cars increases, the flow through the system falls, increasing the number of cars in the system, leading to a further drop in the flow through the system, and so on. Something we’ve all encountered around 5 o’clock in most cities. This can be seen in any system by measuring the cycle time, the total time it takes to start and complete a single feature or piece of work, and lead time, the total time it takes to complete a piece of work (cycle time) plus the time the work spends in the queue, and plotting these as a function of the number of work items open at any given time. Limiting WIP in a Scrum Team So how can we apply this principle to an existing backlog of work consisting of the many valuable and less valuable tasks a product gathers over time? In Scrum, the team limits the number of items they are working on by pulling in only the number of work items (or stories) they can complete in a sprint. This automatically limits the team to a fixed number of stories, hopefully between 6-10 stories. More mature agile teams will also limit the number of stories they are actively working on during the sprint, only working on 2-3 stories at any one time; The purpose of this is to speed up throughput by limiting work-in-progress (WIP). Many teams have other kinds of work they have to handle. Perhaps emergency items (such as production support tickets) that cannot wait until the next sprint planning to be addressed, or small enhancements, maintenance items or report extracts, that are part of the everyday maintenance and support of a product or service. These types of work requests can be handled through a contingency stream, captured on the team’s task board, and tracked visibly for all to see. There are a few guidelines for handling these tickets: Set a capacity limit for the team to spend on these additional items, and help the team manage to this capacity. Have clear policies around what to do with larger items (e.g. work requests larger than 1 day go into the backlog, work requests smaller than a day are handled in priority order). Hide the bulk of the tickets from the team (but not the business stakeholders) to avoid distracting the team. Allow the business to prioritize the tickets the team works on – hopefully through the Product Owner – and if this is not possible set clear rules (e.g. date order) and keep to that. Make the work backlogs visible to all so that everyone can see where their ticket is and what is in front of their ticket. Prioritizing Work across Multiple Projects In situations where there is a portfolio of projects for a single team to work on, it can be hard for the team to complete one project before the pressure to turn their attention to the next project in the pipeline becomes unbearable. This leads to large amount of unfinished work (inventory with a very real cost to maintain and support or build around) as well as the frustration of abnormally long lead times or time-to-market, incomplete work waiting on small changes, and never-ending projects. In this case, we clearly want to allow the team to work on each project a little at a time. But doing this story by story (work request by work request) doesn`t solve the problem of partially complete work unless the work on each project delivers something shippable, something that adds value even if the project in its entirety is not delivered. Grouping a minimal set of stories together to deliver a slice of functionality – a Minimum Viable Product (MVP) the customer can interact with and use – allows the team to work on one project after the other, delivering something of value for the owner of each project (this could be feedback, rather than working functionality, but that’s a discussion for another post) as quickly as possible (Figure 3), while moving each project forward. Figure 3: Managing multiple projects is hard. Many times, the priority of a project is determined by urgency or whether or not a project is ‘front-of-mind’. In this case, projects can be continually open, never quite ready for release, but not moving forwards either. In order to facilitate effective delivery of projects, we want to break them down into small, releasable slices of functionality. Minimum Viable Products (MVPs) that we can release, perhaps to a limited audience for feedback, before committing to build the next slice of functionality. This allows multiple projects to be developed in parallel, while ensuring each project moves forwards in viable steps. This does not remove the need for prioritization of the projects. However, this can be done at the portfolio level, even better at the MVP level (rather than the project level). Its easy to say that a performance project has priority over a site re-design project. However, some performance improvements are more valuable than others, and some site re-design changes can be more valuable than other performance enhancements. Prioritizing between MVPs allows the line of business to optimize on what is most important to the business at any one time, while allowing all projects and priorities to move forward. Working on Fewer of the Right Things In conclusion, limiting the number of projects a team is working on (making the team do less) does not have to reduce productivity (can actually deliver more). While the development team takes responsibility for delivering an increased flow of work through the team - making sure the capacity is predictable and continually improving, the business team and product owners ensure a transparent backlog of MVPs from which to work from - making sure that how the capacity is used maximizes value delivery. The increase in throughput as a result of focusing on fewer work requests, coupled with an ordered backlog of small features or Minimum Viable Products (MVPs), allows a development group to deliver the most important and valuable work more frequently. [Less] |
||||||
Code Data
SCM Data
Community Data
Copyright
©
2013
Black Duck Software, Inc.
and its contributors, Some Rights Reserved. Unless otherwise marked, this work is licensed under a
Creative Commons Attribution 3.0 Unported License
. Ohloh
®
and the Ohloh logo are trademarks of
Black Duck Software, Inc.
in the United States and/or other jurisdictions. All other trademarks are the property of their respective holders.