The Pioneers of DevOps Software

The software development industry has no shortage of “DevOps” tools that position themselves as the end-all solution for application lifecycle management. Everything from release management tools to automated testing software is being coined a “DevOps necessity for the forward looking enterprise.” With so many product categories competing for a slice of the pie, what constitutes a breakthrough DevOps product? This article sets out highlight pioneer products on the market, while bucketing them under the three ways of DevOps, as defined by Gene Kim in The Phoenix Project and The DevOps Handbook.

The first way is concerned with performance and flow of the entire system. It involves creating efficient value streams within the business through synergy between development and operations. The ultimate goal is to create faster delivery through automation, earlier collaboration between operations and development, and building quality in through testing and quality control measures.

First Way Pioneers:

Docker is a breakthrough container application that allows for deployment automation. It packages software with all code, tools, libraries, etc. that are needed to properly install on a server.

Chef and Puppet are configuration management tools that aid in the configuration and maintenance of enterprise servers.


Cucumber allows for custom automated tests built in a BDD style. Selenium is a record/playback tool for creating custom tests without learning a test scripting language.

The second way is the completion of the DevOps loop through feedback from operations to development. The goal is to not only create, but shorten and amplify the feedback loop so that the process is swift and seamless. The feedback loop should inevitably lead to an increase in efficiency with the first way.

Second Way Pioneers:

Clarive is an application release automation platform that provides a combination of automated modeling, workflow management, and deployment. All of this is achieved with incredible visibility that helps manage and regulate the way that deployments and releases are performed.

Jira is an issue tracker that provides bug tracking, issue tracking, and general project management.

Splunk is a searchable database of real-time big data. It was originally developed to provide executives outside of the IT department, actionable reporting.

The third way is to foster a culture of experimentation and learning within your company. This is the stage that you must push the capabilities of your system to the max through rigorous testing and experimentation. A company must foster a culture that accepts failure, as long as a lesson can be learned. As Henry Ford put it, “The only real mistake is the one from which we learn nothing.”

Third Way Pioneers:

CollabNet DevOps Lifecycle Manager
CollabNet DLM is a product that integrates with every industry-leading tool to create a rule based execution system between applications. It facilitates the cross platform integration, while providing a unified reporting dashboard on customizable KPI’s.

Jenkins is an open-source continuous integration software that allows for trigger based automation of testing and builds.

Keep in mind that these tools, individual or combined, will not elevate your company to the status of DevOps elite. It takes a paradigm shift to properly adopt DevOps within your business operations. These tools are a means to enhancement, once you outgrow your SMB solutions. However, when considering the market and the software available within it, these tools lead the pack.

Posted under Uncategorized

This post was written by admin on January 18, 2017

Want To Be Agile? Stop Doing “Projects.”

On Feb 9, 2013, at 9:57 PM, someone wrote:

Now….did you agree that there is ‘some stuff’ that needs to be done before sprinting?

No, I didn’t agree with that. Give me a product vision, a small cross-functional self-organizing team, a team room, some Post It notes, and a MacBook and we’ll get you some kind of working, tested product in two weeks. Actually we can borrow the Post Its and MacBook from somewhere. The other stuff (a fully-refined Product Backlog, complete environment set up, release plan, budget projections, market analysis, etc.) is nice to have, but not essential to start learning through empirical feedback. This is true even for “big” products — we’ll learn more about how many teams we might eventually need by starting with one team. Start small does not equal end small, though it’s also possible we’ll learn our one good team in one room gets more done than 20 mediocre geographically dispersed teams would have anyway.

This is unconventional, probably offends PMBOK* enthusiasts. The organizations that learn it sooner will be the quicker ones to discover their users’ real needs.

The organization may say it needs all kinds of project initiation activities, to accommodate people’s comfort, just as my daughter may need me to check under her bed for monsters.** So as a practical matter we may need to appease those people. This doesn’t mean there really were monsters under the bed.

“Project” and “project execution” are 20th Century concepts, perhaps useful for building skyscrapers and stuff with huge startup costs and exponential cost of change curves. But an impediment when it comes to Agile product development.


* The “Guide to the Project Manager’s Body of Knowledge” is a compendium of obsolete management techniques, updated every year by the Project Management Institute with more obsolete techniques.  Agilists know there are really only two misconceptions in “Project Management”: projects, and management.

** Hypothetical analogy. She doesn’t actually have me do this.

Posted under Agile Methodology, Uncategorized

This post was written by admin on February 10, 2013

Effort Estimation and Story Points Demystified

I recently worked with some teams in India that were obsessed with effort estimation.  It turned out their real problem wasn’t estimation, it was keeping the product in a properly tested, shippable state all the time — the basic requirement of Scrum.  If the product is always shippable, and the user stories are always small, and the Product Owner is always prioritizing, we can always ship a product with the important stuff in it.  If we get some estimates wrong, it just means we’ll omit the less important features.  This isn’t a perfect situation, but it’s much better than what most companies do: ship late, or ship untested.

Agile teams generally use relative estimation approaches such as story points, sometimes a Fibonacci scale, sometimes an exponential scale.  To learn how, watch this example of a Backlog Grooming Meeting.  Note that the Scrum team does not pay much attention to the points during the example Sprint Planning Meeting.  They are mostly to help the Product Owner make forecasts.


Posted under Agile Methodology, Scrum, Uncategorized

This post was written by admin on January 9, 2013

Scrum Reference Card now available in English and Spanish

The English version of CollabNet’s famous Scrum Reference Card has been downloaded over 20,000 times.  A Spanish Scrum Reference Card is now also available, thanks to Martin Alaimo.  Reference Card de Scrum ahora también en español!


Spanish Scrum Reference CardFlag of Spain

Posted under Uncategorized

This post was written by admin on January 8, 2013

Playing it SAFe, Can a Large Organization Become Agile Without Changing Anything?

We’ve noticed someone selling a prescriptive approach to large scale Agile that actually appears to be 80% waterfall.  An 80/20 waterfall/agile hybrid approach may be a positive step, but we’re concerned that this scaled agile framework confuses people about what a truly Agile approach to large scale development would be.
Let’s examine some principles from the Agile Manifesto:
  • Business people and developers must work together daily throughout the project.
  • Simplicity–the art of maximizing the amount of work not done–is essential.
  • The best architectures, requirements, and designs emerge from self-organizing teams.
On the other hand, the easy, safe prescription for scaling seems to deliberately institutionalize some bad ideas we usually call impediments:
  • A three layer stack with proxy Product Owners in the bottom layer, enmeshed in coding teams.  Somewhere above the pseudo-Product Owners, other silos contain the stuff we usually consider Product Owner work: vision, product management, release management, portfolio management.  In our experience it’s better for self-organizing teams to work directly with the *real* decision makers responsible for the vision as it emerges.  The Scrum Product Owner was never supposed to be an artificially elevated middle manager.  According to Kent Beck, the first known XP project failed because the “Goal Donor” was not the “Gold Owner.” We want regular face to face contact between business decision makers and development teams so all learn from each other.
  • Teams contain “Developers & Testers” but UX, architecture, integration (by the “System Team”), and “release train engineering” occur elsewhere.  In Scrum, these are team responsibilities, so we want truly cross-functional teams, usually with business requirements experts, UI/UX designers, etc. right on the teams.  Scrum encourages a rigorous definition of done.  Teams will be more Agile if they learn to integrate their work with other teams. This will be difficult at scale, but coordination roles only make this worse.
  • Somewhere up in the whipped cream layer of this cake we find czars such as the “Enterprise Architect” working on “Architectural Epics” guaranteed to lead to architectural bloat.  I assume this was created to appease senior technical guys who have grown rusty at everything but PowerPoint.  One place I worked with found their (waterfall era) Architecture Center Of Excellence ivory tower to be such a huge impediment they disbanded it and put the architects right on Scrum development teams, right in the team rooms.  An assigned “architect” role is utterly incompatible with the Agile principle “The best architectures, requirements, and designs emerge from self-organizing teams.”  Scrum teams are responsible for the design of the software they build.  If we must use multiple teams on one product/portfolio and we believe in team self organization, ScrumMasters must create environments that encourage teams to coordinate with each other through communities of practice, not implementation czars.
The 20% of this that’s Agile is the stuff that’s relatively easy to change in an organization: putting testers on the teams (except not integration testers evidently), working in iterations, acknowledging that architecture will evolve, and co-opting (occasionally abusing) Agile jargon.  Maybe a couple steps forward for some orgs, but far from ideal.  I think it will appeal to companies that are concerned with keeping cozy spots for everyone, avoiding the uncomfortable ambiguity and uncertainty where real breakthroughs occur.

Posted under Agile Methodology, Scrum, Uncategorized

This post was written by admin on January 2, 2013

Community Development – A coding community

I work mostly with software teams in large organizations. One things I’ve noticed is that the vast majority (all?) tend to work in a very siloed manner. Whether by design or default, the good news is that this serves to insulate each of the teams from unwanted changes to the systems and infrastructure. But it also cause issues, because it is highly inefficient. Not only are the administrative overheads impacted, IP is not shared and expertise is not leveraged. Centralizing and consolidating IT software assets is the foundation upon which organizations can implement a robust coding community that promotes collaboration and sharing across enterprise teams.

A coding community relies upon the implementation of a community architecture to provide the facilities for data sharing, structured data, and enabling communities to work together in the development and delivery of software applications. Key aspects of the Community include the following:

• The Community must include social forums for ad-hoc collaboration between distributed team members. Such forums might include wiki-based knowledgebase containing a central and searchable repository of comments, code snippets, libraries and other valuable assets
• Team members from any part of the organization can benefit from enhanced visibility and search across the enterprise. Subject to the security constraints of the specific business, the more visibility given to developers, the more access to those valuable IT assets is provided, the more productive those developers can be. Sharing in a safe and controlled environment is a huge boost to productivity.
• Just like any other part of an enterprises’ IT environment, comprehensive governance is a necessity. The community architecture that is put in place to foster re-use must also reflect the governance and security mandates of the individual enterprise.
• To the degree possible, it is often useful to enhance third-party collaboration in the coding community. This extends re-use and cooperation beyond the firewall.

Done well, a development community can help a disparate, fractured and distributed staff in the development organization find common architectural foundations, share best practices, communicate more effectively. Outside of the development organization, a Community Architecture can break down the barriers and bridge the gaps between non-technical business people and the developer community.

Here’s an interesting White Paper on Social Coding.

Posted under Uncategorized

This post was written by admin on January 3, 2012

ScrumMaster Checklist and Scrum Reference Card

An adequate ScrumMaster can handle two or three teams at a time. If you’re content to limit your role to organizing meetings, enforcing timeboxes, and responding to the impediments people explicitly report, you can get by with part time attention to this role. The team will probably still exceed the baseline, pre-Scrum expectation at your organization, and probably nothing catastrophic will happen.

But if you can envision a team that has a great time accomplishing things you didn’t previously consider possible, within a transformed organization — consider being a great ScrumMaster.

Check out the ScrumMaster Checklist written by Michael James. It will help you gauge the progress of your agile teams and help you answer questions like:
• How is my Product Owner doing?
• How is my team doing?
• How are our engineering practices doing?
• How is the organization doing?

To learn about Scrum from entertaining cartoon characters, see the Scrum Training Series.

Michael has also written the Scrum Reference Card, a valuable reference document for anyone practicing Scrum or other Agile disciplines.

Posted under Uncategorized

This post was written by admin on November 19, 2010

Getting Down to Business with Games

Over at InfoQ, Deborah Hartmann Preuss reports on the values of games for teaching the principles of Scrum. If youÂ’ve ever attended a Certified ScrumMaster or Product Owner course, chances are your instructor led the group to a deeper understanding of Scrum and agile principles by playing a game or utilizing an interactive exercise. ItÂ’s an effective strategy for communicating difficult-to-grasp ideas in a fun and memorable way and itÂ’s becoming increasingly common for agile education.

IÂ’ve played a number of games over the course of my agile and Scrum education. If youÂ’re responsible for teaching your team or others in your organization, here are a few helpful links thatÂ’ll give you some proof that games are, in fact, valuable and will provide a few ideas for games to try.

HereÂ’s CST Kane Mar on the Ball Point Game, which he learned from Boris Gloger:

And hereÂ’s Katie Playfair of Danube Technologies arguing for the relevance of game-playing:

Posted under Uncategorized

This post was written by admin on December 22, 2009

Agile Team Lead?

Mike Bria recently posted a story on InfoQ discussing how a group of agilistas are arguing for the creation of a new role within agile and Scrum teams called the “agile team lead,” designed to effectively replace the ScrumMaster and Project Manager positions. For purists, it’s hard not to be skeptical, especially considering the delicate balance of authority and responsibility that marks the composition of Scrum teams. But for the sake of entertaining the idea, the following criteria summarize the group’s ideas about the duties that agile team leadership entails:

  • “Continuous Leadership
    Understanding the team’s place in the organization’s goals, being a single point of leadership (for the team) and accountability (to stakeholders), building a “safe container” for the team to work within, growing trust and respect between team and stakeholders, and continuously improving team cohesion.
  • “Continuous Planning
    Ensuring the team become increasing capable of meeting their own established commitments, ensuring everything remain “big and visible”, manages metrics, making “the plan the bad guy” (as opposed to the people), and ensuring the “plan changes with demand/supply”.
  • “Continuous Execution
    “Monitoring/managing team velocity/throughput”, securing resources, removing and escalating blockages. Ultimately, “keeping flow, momentum and focus in the team”.
  • “Continuous Risk Reduction
    Identifying risks and making their “potential impacts big and visible to the right people”, ensuring risk reduction occurs, and quantifying risk management effectiveness.
  • “Continuous Improvement (Agile Coaching)
    Driving the “improvement of the overall Definition of Done“, sensing and drawing attention to performance breakdowns, facilitating team improvements in the right areas, and helping the team learn emerging practices from outside itself.”

Though several Scrum and agile practitioners have supported this idea, my favorite response belongs to CST Tobias Mayer, who states: “Creating a ‘role’ of team lead is the beginning of a slippery slope back to command and control, It is a cop-out, an excuse for not facing the real challenge of nurturing a leader-full team.”

I can’t help but agree. This role not only seems to disrupt the balance of power in Scrum and agile, but seems to be moving backwards—toward traditional management practices. I’m curious to know what you think. Would an agile team lead role solve problems at your organization or just create more? Let me know what you think in the comments.

Posted under Uncategorized

This post was written by admin on December 17, 2009

Lean Software

As IÂ’ve discussed here before, Lean manufacturing, typified by Toyota and HondaÂ’s production system of the 1980s, was one of the most influential precursors to agile development practices. Specifically, LeanÂ’s emphasis on ongoing evaluation of the teamÂ’s performance, constant pursuit of process improvement, and continued waste elimination can be directly observed in agileÂ’s tenets of incremental and iterative inspection and adaptation. Tony Baer, an analyst who covers agile, discussed how Lean has become a hot topic of discussion of late among the agile community. According to Baer’s post, this debate boils down to two arguments: “First is the contention that value stream analysis will add unnecessary bottlenecks, and second is that software development is a special case to which manufacturing metaphors do not apply.”

Baer’s take on these issues tends to align with my own thinking. Firstly, he acknowledges that it does seem a little contradictory for a development methodology that privileges a reactive approach to emerging conditions to place such an emphasis on value stream analysis. However, he still acknowledges the value of this kind of analysis. In the case of the latter argument, Baer cites a concern among developers that software development is categorically different from any other kind of construction or development process that occurs in the real world. Certainly, such criticisms are correct: Software development is not governed by a stable set of physical properties like, say, bridge building is. However, Lean’s values—as described above—are all applicable to project management, regardless of what is being produced. After all, Lean is essentially a philosophical approach, in which teams and organizations commit to continuous improvement—by reflecting on processes and taking whatever steps necessary to improve them.

Posted under Uncategorized

This post was written by admin on September 29, 2009

Tags: ,