Loading...

Follow VersionOne Agile & DevOps Blog on Feedspot

Continue with Google
Continue with Facebook
or

Valid

I’ve just returned from Agile 2018 in sunny San Diego and wow, what a fantastic week it was! CollabNet VersionOne made a number of big announcements, hosted THE party of the week — a luau at Roy’s on the water — in appreciation of our customers and partners, and set up a Q&A lunch panel with some of our executives and Dean Leffingwell from Scaled Agile.

CollabNet VersionOne was one of Agile 2018’s Title Sponsors and we really took the spotlight in the exhibit hall with our value stream adventure camp where we gave away camp gear like warm socks, trucker hats and the chance to win a Yeti Cooler.

The booth was a fantastic hit, but more importantly, the conversations that took place at the booth were thought provoking and insightful. We met conference attendees from all over the globe, representing a number of enterprise challenges — tool integration challenges post merger, lack of measurement capabilities for product development lifecycle improvements and cultures resistant to change.

Here are the announcements we made in case you missed them:

  1. CollabNet VersionOne Announces New Release of its VS Solution, an Innovative Offering that Enables Organizations to Achieve Enterprise Value Stream Management.

This release is significant because we are seeing more clearly that organizations need to connect business value to their software development initiatives. This solution provides, above all, the confidence that business leaders need to innovate and transform digitally, with software leading the way.

  1. CollabNet VersionOne Announces Opening of the 13th Annual State of Agile Survey.

Heading into its 13th year, the State of Agile Report has been a valuable resource for the software development community since its debut. This research is cited worldwide in discussions on the evolution of software development, Agile and DevOps. The survey is now open and collecting responses through December. We invite agile professionals to contribute at www.stateofagile.com.

  1. CollabNet VersionOne Named a Strong Performer in Value Stream Management Tools Report by Independent Research Firm.

See for yourself! We’ve made the report available for download at no cost, take a look at our excellent placement in this Forrester Wave and find out why CollabNet VersionOne is differentiated for the strongest current offering.

CollabNet VersionOne is lucky to have the support of some of one of the industry’s greatest leaders in scaling agile, Dean Leffingwell, who is practically a celebrity at Agile 2018.

As I mentioned briefly at the beginning, Dean joined myself and CollabNet VersionOne CTO, Ian Culling, for a panel luncheon on Wednesday Aug. 8. Our audience spent time networking and asked many good questions about the CollabNet VersionOne product roadmap, scaling agile across the enterprise and what’s next for the Scaled Agile Framework (SAFe).  Dean offered some sage advice on decisiveness when it comes to getting your team on board with the tools you’ve selected, the proper utilization of stories in agile, the investment required for an agile transformation and how DevOps is changing the movement. Thanks Dean for joining us as a guest host!

If you attended Agile 2018, I’d love to hear your feedback, what were your favorite sessions and what did you learn? Please leave your thoughts in the comments below.

If you missed the conference, no worries, maybe we’ll catch you next year or at the Global SAFe Summit in Washington DC, October 1-5 where we are headed next.

The post What You Missed at #Agile2018 appeared first on VersionOne Blog.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

We have been spending some time on the blog these past few weeks interviewing some of the “greats” of agile — people who have shaped the agile movement with their ideas and leadership. Hearing from these agile coaches, teachers, speakers and authors helps reveal where the industry is headed next, and has shed light on the value of the findings of the State of Agile Report, put on by VersionOne annually.

Today CollabNet VersionOne shares Q&A with Scott Ambler, agile coach and one of the developers of the Disciplined Agile Delivery (DAD or DA) framework. Scott shares some of the reasons DA has caught on (the State of Agile Report saw an increase in DA users from 1 to 5 percent in the last year). He also discusses misperceptions about agile and makes a prediction for next year’s report.

Here’s the full interview:

Question: The 12th Annual State of Agile report cites the ability to manage changing priorities as the top benefit of agile. In your experience, what is the greatest benefit?

Scott: I would agree with that. Being able to safely react to change is key into today’s marketplace. Traditional strategies just don’t get the job done any more.

Question: What is the greatest misperception about the agile methodology?

Scott: That would be a very long list. I think that the biggest misperception is that Scrum is sufficient for agility. Anyone who says that they’re doing Scrum doesn’t really know what they’re talking about, because to make Scrum work they would also have to have adopted strategies from XP, Agile Modeling, RUP, and many other sources. They’re very likely doing something much closer to Discipline Agile Delivery (DAD) than Scrum, but sadly don’t realize it due to all the marketing rhetoric around Scrum.

Question: The 12th Annual State of Agile report highlights that the use of Disciplined Agile (DA) has grown from 1% last year to 5% this year, why the increase?

Scott: As organizations continue to adopt agile across a wider range of situations, particularly in the enterprise space, they’re starting to discover that they need something a bit more robust than the agile strategies that are geared for simpler situations. DA has done a lot of the heavy lifting when it comes to figuring out how to apply agile in the enterprise, and as people start to realize that they’ve hit the limits of Scrum, they start looking around for something a bit more comprehensive.

Question: If you had to make one prediction for next year’s State of Agile report, what do you guess the new findings will reveal about where agile is going?

Scott: I think you’ll see that DA adoption continues to rise. DA already addresses a lot of the issues that organizations are struggling with, such as, how does architecture fit in? how do you govern agile teams effectively? how do you address regulatory compliance? and many other issues. You can figure out all these things on your own or you can adopt DA and get a very big leg up.

Question: Have you seen the greatest agile success when teams take a grassroots approach or when management leads a top-down approach?

Scott: You need both. Grassroots adoption on its own hits a glass ceiling pretty quickly. Similarly, a top-down approach on its own is pretty much guaranteed to be ignored by the people in the trenches. You need a combined approach where the team-level issues are addressed as well as the organization-level issues.

Question: Are there instances where software teams should not employ agile practices and other methodologies such as waterfall are fitting?

Waterfall works well in very straightforward, well-defined spaces. For example, if you were to do an infrastructure upgrade (say moving from Windows 7 to Windows 10) then traditional works fine.

Thank you Scott for providing these insights!

Please check out the previous two posts in this series:

“Q&A with Scaled Agile Expert Dean Leffingwell” and “Sanji Augustine Discusses Business Agility, High-Performing Teams and Opportunities in China and Africa”

The post Q&A with Creator of Disciplined Agile Delivery (DA), Scott Ambler appeared first on VersionOne Blog.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

CollabNet VersionOne has been interviewing some of the agile movement’s greatest leaders. The publication of the State of Agile Report each year gets us thinking about the adoption of agile, which organizations are using it and how they are applying the methodology. The survey looks into why folks are using agile and how it is helping teams develop better software at speed.

Last time we spoke with Dean Leffingwell from Scaled Agile.

This week, we’ve posed many of the same questions to Sanjiv Augustine, president of LitheSpeed and author of Managing Agile Projects and Scaling Agile: a Lean Jumpstart.  Sanjiv shares anecdotes from his experience as a global consultant and provides a fresh perspective on some agile clichés such as the Scrum standup meeting.

Let’s see what he has to say:

Question: How did you first learn about agile and what about the practice appealed to you initially?

Sanjiv: I learned about agile methods in the year 2000. My then boss needed someone to manage eXtreme Programming (XP) teams, and hired me to align management with XP. The practice that made immediate sense was timeboxed iterations (Sprints in Scrum). I saw the power of timeboxing to drive throughput and delivery, and still believe short timeboxes are one of the best practices in agile methods.

Question: The 12th Annual State of Agile report cites the ability to manage changing priorities as the top benefit of agile. In your experience, what is the greatest benefit?

Sanjiv: One of the greatest benefits is to break up the log jam caused by waterfall and siloed organizations. When you break that log jam, value is delivered faster, and organizational silos will no longer stand in the way of bringing value to customers. Certainly managing the changing priorities is a benefit, but more of a secondary benefit and an outcomes of this structural change. Establishing this end-to-end value stream with our customers drives true business agility.

Question: Have you seen the greatest agile success when teams take a grassroots approach or when management leads a top-down approach?

Sanjiv: It’s really not an either/or, the best success comes when you have both grassroots and top-down movement. The top down approach implies ‘thou shalt do xyz …,” and that’s not the best way. The best transformations happen when management can say, we want to help you, provide what you need to make this happen. Management and executives must commit to the process of course, but team members also need to have it in their hearts and minds to adopt agile methods. Thus, there must be team momentum as well.

So, the best-case scenario happens when you combine team momentum with top executive buy in, that way all pieces are working together – the commitment and air cover as well as the enablement.

Question: Are there instances where software teams should not employ agile practices and other methodologies such as waterfall are fitting?

Sanjiv: I don’t think of agile methods as a single thing. The truth is, any agile method can be teased apart into a number of different practices and it is possible to apply certain agile practices without others.

For example, agile teams are cross-functional and high performing. You can create this with physical meetings where team members share a location or you can use tools like Slack, video conferencing or IM. This team aspect is important for Scrum. Applying this high-performance team discipline is possible even if you have a waterfall process. For example, we’ve worked with Capital One in the past, and their waterfall teams apply many Scrum practices. You can walk into a waterfall team space and find they are doing similar practices as agile teams — whiteboards and all. It’s just that the delivery process and timeline is different.

That said, agile processes are not a good fit when you don’t have good buy in from the business. For instance, to practice Scrum, SAFe, or Scrum at Scale requires business involvement with an involved sponsor. So, in those instances waterfall might make more sense.

Question: The 12th Annual State of Agile report revealed that in organizations with some teams practicing agile, those teams represent less than half of the organization’s teams in total. What does this say about the spread of Agile across the enterprise?

Sanjiv: That says we’ve got a long way to go. Waterfall has been around since 1974, and agile has really only taken off in the last 10 years, so there’s something DevOps identifies as “Conway’s law,” which means our process and organizations mirror each other.

As we’ve been using waterfall for 50 years, we’ve built up governance, portfolio management, funding, etc. These are ancillary functions that are waterfall in nature.

Until we start aligning those to agile teams, it’s no surprise the organization itself is not all agile. When those start to be agile the enterprise can be agile, until then we have a long way to go.

Question: In the 12th State of Agile Report, 90 percent of respondents indicated they participate in a daily stand-up meeting at their organization. Why are standup meetings valuable for software teams?

Sanjiv: Let me give a comparison from agile history.

Before Scrum became popular, 18 years ago, eXtreme Programming (XP) was all the rage. However, the first thing people thought of when XP came to mind was folks sitting together and pair programming.  This was the most visible and tactical part of the XP methodology, so it was easily recognizable. A lot of XP magic happens behind the scenes and isn’t immediately obvious, but what is obvious is two people sitting together, so if you don’t know anything else that is your first assumption. For many, XP was simply, “pair programming.”

With Scrum you have a product backlog as well as specific roles for the Product Owner, ScrumMaster and Development Team. The Scaled Agile Framework (SAFe) add the Release Train Engineer (RTE) role, and Scrum at Scale has sophisticated structures like the Meta Scrum. However to the casual observer, they look at Scrum and see a team standing in a circle – it’s simply the most visible practice.  Therefore, Scrum has largely become associated with a standup meeting. They associate the mechanics of standing in a circle with better process for software development.

So, I absolutely encourage it as a practice though because it’s so simple and straightforward. In 15 minutes or less, you can break down barriers to communication, face to face. However, I also strongly encourage everyone to go well beyond the Daily Standup “cult of practice” and truly implement other agile practices with true agile values in mind.

Question: Any additional comments you’d like to make on the findings of the 12th Annual State of Agile Report?

Sanjiv: I find it interesting that most of these responses were taken in North America. As you look at the places in the world with under 10 percent responses provided on this survey, I believe those are opportunities for growth. I know there’s a strong level of agile adoption right now in Australia and Brazil. And there’s a huge opportunity in South America. We also see strong growing adoption in India and China.

The primary opportunities, however, in my estimation, exist in China and Africa. For instance, there are approximately 250 Scrum trainers worldwide, and the majority are based in North America and Europe. I think there are only 3 based in China, and only one based in Africa.

Thank you Sanjiv for taking the time to answer these questions and provide our readers with some food for thought. Cheers!

The post Sanjiv Augustine Discusses Business Agility, High-Performing Teams and Opportunities in China and Africa appeared first on VersionOne Blog.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

For years VersionOne has taken its role seriously in furthering agile research for the betterment of the software development industry. The State of Agile Report is one great example. For 12 years straight we’ve surveyed practitioners, IT leaders, executives and everyone in between to find out who is using agile, how they are using it and why. This is just one way the company has historically contributed to the software development community.

In order to deliver products or services that will truly benefit our customers, we have to do a lot of listening. We listen to customers and non-customers alike. We want to know, what are the challenges of software teams? Where is agile bringing benefit and where is it falling short?

One of the best ways to learn, however, is to talk to the experts. Talking to leaders within the agile community who have changed the industry landscape through inspiring thoughts, helpful innovations or challenging the status quo is incredibly worthwhile.

CollabNet VersionOne recently had a conversation with Dean Leffingwell, SAFe (Scaled Agile Framework) creator and chief methodologist, at Scaled Agile Inc. CollabNet VersionOne platforms are designed with SAFe in mind because we have seen how many enterprises achieve success using this methodology.

Let’s hear Dean’s thoughts on some of the State of Agile Report findings, learn more about his experience joining the agile movement and ask some questions about what’s important for our industry.

Question: How did you first learn about agile and what about the practice appealed to you initially?

Dean: “I first learned of Scrum and XP in the late nineties. But I was working with large enterprises, those with 200-500 or even thousands of developers. I saw how XP and Scrum worked well for small teams, but it didn’t seem like something for me because I was dealing with really big teams building really big systems. So it didn’t influence my thinking much at that time.

Later, from 2001 and on, I began advising startups and spent time learning Agile staring with XP. Frankly, I was blown away by the discipline and code quality that resulted from XP practices. I was tipped. I also attended a ScrumMaster class and was impressed by the simple Scrum paradigm and the roles of Product owner and Scrum Master. At that time there was a quite a method war between the two, but I saw them as being optimized for different things, the yin and yang, if you will, of team agility. So I adopted both methods and built a hybrid process that I used to coach a number of software startups. The results were truly amazing. It was the biggest improvement in the software development I’d ever seen. I was convinced there was only one way to develop software from them on, and I have been an Agile champion ever since.

Looking back now, there was a time when Agile seemed so new. But by now, I’ve been using it for almost half of a 40-year career. We use SAFe here at Scaled Agile, Inc., and of course the framework team operates as an Agile Team. Now my personal mission is to allow people in larger enterprises to reap the benefits of these Agile methods, so the power of the methods is not relegated solely to just small companies and small teams.”

Q: The 12th Annual State of Agile report reveals that 29 percent of respondents use the Scaled Agile Framework (SAFe) and it is the most popular scaling method used. Why is this method continuing to grow in popularity?

Dean: “The simple answer is, it produces outstanding business benefits. We have more than 40 published case studies on the Scaled Agile Framework website and another 40 or so public references to what companies have achieved with SAFe. The results these companies achieved are unbelievable.

There are records of significant productivity gains, quality improving by 3 or 4 times, time-to-market increased by 70 or 80 percent, and most importantly, people enjoying their jobs more. They report much higher levels of employee engagement. SAFe is basically Agile on steroids with a lean substrate, but as applied to large enterprises. Business get outstanding benefits from SAFe.

Also, Scaled Agile Inc, which owns SAFe, is a rock solid company. We have an outstanding entrepreneurial team, experienced executives, the leading framework, professionals in learning development, and certification, very effective sales and marketing, over 175 worldwide service and tooling partners, etc. We have a community platform that supports hundreds of thousands of users, a customer success team with a less than 24 hr. response time to questions. And we have the development and support infrastructure necessary to implement and share the framework globally. We are in a strong cultural, thought leadership, distribution and financial position.

Success scales. SAFe is generally not an approach that managers ‘need to be talked into’, they see the benefits and decide for themselves if the efforts is worthwhile. Usually the answer is yes.”

Q: The 12th Annual State of Agile report cites the ability to manage changing priorities as the top benefit of agile. In your experience, what is the greatest benefit?

Dean: “I think that managing changing priorities is certainly one, but the collected benefits of creating a persistent way of working, lean thinking and relentless improvement, are important too. Agile isn’t a state of being, it’s a journey that can always be improved.”

Q: If you had to make one prediction for next year’s State of Agile report, what do you guess the new findings will reveal about where agile is going?

Dean: “The trends will likely continue. That’s why they are trends. But one of the things that the State of Agile report doesn’t cover extensively enough is DevOps. DevOps is different from agile, as it’s focused more on code to cash than concept to code. But it’s part of the continuum.

Agile is mostly about the front end of the product lifecycle and DevOps takes the industry further down the lifecycle. These two communities — agile and DevOps — see things very similarly. These movements need each other. You’ll see that folks scaling agile need DevOps to support rapid release of new value. And those heading down a DevOps path will say, ‘We can’t do it without agile development delivering smaller batches just-in-time.’

I’d anticipate that these trends will continue to show that these worlds are converging. Agile has always been mostly about ‘development’ which helps on the front end. But we haven’t yet optimized the full continuous flow of value. To get releases out quicker, agile and DevOps must be married in the middle. And as SAFe integrates DevOps and agile, I’m also confident that SAFe will maintain its leadership position. ”

Q: Have you seen the greatest agile success when teams take a grassroots approach or when management leads a top-down approach?

Dean: “I think that misses the larger piece of the puzzle. In an enterprise, what C-level executive doesn’t want faster time-to-market or the ability to respond faster to market needs? Will the CEO believe Lean and agile are good? ‘Yes and can I get ice cream with that?’ So I’d say it’s relatively easy for a CEO to get on board. Executives get it.

Then, at the ground level where the work is done, what developer doesn’t want to be on an agile team? Most do because this means getting their voice heard and getting the psychic reward for doing the right work in the right way, with a minimum of nonproductive overhead. And seeing their work solve real problems for real users quickly and expeditiously. So there’s usually very little resistance in the executive suite or at the practitioner level.

The challenge can be in the middle. Only these managers and leaders can change the systems which control the way the work is performed. It turns out that they, not the executive or the developer, hold the keys to the kingdom. And in the larger enterprise, there are a lot of them and they are talented and largely responsible for the success that’s been achieved to date. It’s hard to argue with what they have achieved with the existing way of working.

But there is a new, and better way of working available. At Scaled Agile, we always start by getting in front of these people, to show them a new way of working and to directly address the pockets of resistance that can be there. We teach these leaders first so they can teach others. These are the champions we really need to effect change.“

Q: Are there instances where software teams should not employ agile practices and other methodologies such as waterfall are fitting?

Dean: “I haven’t found them. I just don’t know of any material initiative where, we’d really like to wait until the very end to find out how I’m doing. The scientific method says, ‘I don’t know the answer, I need to find out with a series of small experiments.’ Perhaps it’s the thrill of leaving all the risk to the end of the program that still drives waterfall: ‘I can hardly wait for that surprise!

But there’s just no way you can begin knowing everything 100 percent up front. Considering the business case up front is important, but Waterfall, for example, starts with the assumption that the requirements can be known fully up front. But if that were truly the case, then the system’s already been built.

It just doesn’t make sense when we build systems of complexity. Waterfall got us where we are, so it is not by any means a stupid process. But we’ve learned better ways.”

Q: In the 12th State of Agile Report, 90 percent of respondents indicated they participate in a daily stand-up meeting at their organization. Why are standup meetings valuable for software teams?

Dean: “Simply, programmatic communication and collaboration. And it’s not just for software teams. At Scaled Agile, our teams are spread out throughout a 27,000 square foot building — plus we have folks on the road, and we have people around the globe. But if you walk around our building between 8:30 and about 11 AM, you’ll see most every team doing a daily standup.

Now honestly however, if your teams are distributed you’ve got to have some work-arounds. For the framework team, because of our distribution, travel, and classroom training and consulting schedules, we do not have a daily stand up. But we try to make up for that by running one week iterations inside our two week company sprint cycle. But we are thinking about starting one. In any case, the point is you have to have steady, routine communication.”

Thanks so much Dean for taking the time to chat!

If you’d like to learn more about SAFe from Dean, check out this webinar, “Driving Innovation in the Enterprise with Lean Thinking and SAFe.” In this webinar, Dean Leffingwell illustrates how seemingly disparate practices — like Agile, Scaled Agile, Lean Startup, Lean UX, DevOps and Continuously Delivery — need not be separate initiatives, but rather a continuum that helps enterprises deliver more innovative solutions at a velocity they could only imagine before.

The post Agile Q&A with Scaled Agile Expert Dean Leffingwell appeared first on VersionOne Blog.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Another amazing installment of DevOps Enterprise Summit London (DOES18) is in the books! As a proud sponsor of the event for the past three years, we feel confident in saying that this was the best year yet. It was our first time at DOES London as a combined company – CollabNet VersionOne – and we were excited to announce our newest solution, CollabNet Enterprise Value Stream Management (EVSM). CollabNet EVSM combines our Agile, Enterprise Version Control and DevOps Continuous Delivery platforms to help visualize, measure and optimize delivery pipelines and value streams across the entire application lifecycle, giving customers the ability to make their Agile-plus-DevOps environments into realized digital business drivers. We could not have thought of a better venue to announce CollabNet EVSM and were very pleased with the activity and interest we saw at our booth.

Of course, this is not to overshadow the incredible programming put on by Gene Kim and IT Revolution. Almost 1,000 attendees, including ourselves, enjoyed listening to dozens of speakers representing global companies like Disney, Barclays, Adidas, Capital One, Verizon and others, share their DevOps and digital transformation journeys. We certainly learned a lot and were excited to hear several stories about value stream management and business-centric talks that aligned with our own vision. There were a few themes and sessions that stuck with us and we wanted to share those highlights with you:

  • The Intersection of Business and Technology: It’s no secret that every business is becoming a technology business. From banks to government to retail it’s important that every company have a digital presence, as consumers become more reliant on accessing what they need on a website, app or other digital platform. Plus, with consumers becoming increasingly demanding and the landscape becoming more competitive, being able to deliver quality at speed is mission critical. For many years, tech teams within organizations functioned as a silo from business teams. This created bottlenecks, general misunderstandings to outright disasters, and ultimately poor customer experiences that affected the bottom line. Organizations are finally realizing that technology and business teams need to come together to work toward a common goal and have a mutual understanding to encourage a blameless culture. These themes were especially apparent in talks like this one from Aimee Bechtle and John Schmidt from Capital One. Bechtle, senior manager, next generation infrastructure business strategy, and Schmidt, software product innovator, shared how they created cross-disciplinary teams by starting a DevOps dojo. The Nike talk, from Randy Lyons, senior director of Nike digital, and Michele Power, CFO of Nike Direct EMEA, emphasized the importance of business leaders understanding technology, and technology leaders understanding business. We could not agree more that having business and technology leaders sit at the same table is a critical step in realizing digital transformation.
  • Don’t Leave Out Ops: A phrase we often heard at the conference was “The DevOps equation has been favorable to the Dev side.” Well, not anymore! Damon Edwards, co-founder and Chief Product Officer at RunDeck, gave an insightful and engaging talk on how developers have frankly had it easy in this whole DevOps movement. He walked through a ticketing system that many in the audience were all too unfortunately familiar with, ending with the conclusion that the adoption of Agile, DevOps and Continuous Delivery methods has by and large left operations out of the picture, leading to failing transformations. Other sessions like this one from Cornelia Davis, senior director of technology at Pivotal, also talked about ways to revolutionize and engage the operations side of the DevOps journey. While Davis, Edwards and others brought to light the current state of operations, it’s clear that much more needs to be done to bring operations into the transformation fold. Hopefully as we head to DevOps Enterprise Summit Las Vegas later this year, and the London event in 2019, we will begin to see some success stories of bringing ops into the mix.

There was so much more that was shared and learned over the course of two days, but the themes of integrating business and technology, and next-gen operations stuck with us the most. If you attended, or watched the live stream, we’d love to hear what your favorite talks or themes were! Comment below to leave your thoughts.

If you want more DevOps in your life, be sure to join us at DevOps Enterprise Summit Las Vegas October 22-24, 2018 at The Cosmopolitan. Early Bird tickets are still available until July 16 – register now.

The post DevOps Enterprise Summit London 2018 Recap and Highlights appeared first on VersionOne Blog.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

DevOps has grown significantly in recent years as an approach to better and faster software delivery through breaking down the Development and Operations silos. Author and speaker Gene Kim defines DevOps in The DevOps Handbook as, “The emerging professional movement that advocates a collaborative working relationship between Development and IT Operations, resulting in the fast flow of planned work (i.e., high deploy rates), while simultaneously increasing the reliability, stability, resilience and security of the production environment.”

What types of challenges prompt an enterprise to start looking to DevOps to improve process and flow? Issues such as:

  • Lack of management visibility;
  • Inconsistent processes;
  • Incompatible data and measurements;
  • Minimal collaboration and knowledge sharing;
  • Deployment delays, inefficiencies and errors;
  • Limited alignment with business strategy;
  • And unmanaged dependencies

All of the above can contribute to slow release times while the cost of regular inefficiencies take a toll on the organization. Team members experience frustration due to a lack of clear direction and changing priorities and company resources are depleted. These challenges are familiar at all levels of the enterprise — from portfolio to program, release and team.

These challenges are all reasons that organizations bring companies like CollabNet VersionOne into an Agile-plus-DevOps discussion. Any one of the challenges mentioned is enough for managers to seek a better way, however most of the time we see enterprises facing almost all of them at once.

When we meet with large enterprises that are dealing with the challenges above, these issues have repercussions throughout the entire business.  What about taking a more holistic approach and applying the principals of DevOps to the entire product delivery pipeline?

This is where Value Stream Management (VSM) comes in. What is VSM?  Forrester defines VSM as a mechanism for business users’ visibility into how much value is being delivered. It gives all stakeholders a view of the health of the product delivery pipeline. In essence, VSM is end-to-end visibility and perhaps value delivery is simply the last dark mile.

For example, there are a number of iteration periods that may be well known to an enterprise in capturing value such as portfolios, epics, features and backlog. However, to truly create value, other iteration periods, such as commit, artifacts, packages, releases and deployments, must also be known, measured visibility.

So how does an enterprise apply DevOps throughout the value stream? Is it possible using point tools alone? We see many organizations with an alphabet soup of tools from AWS to Puppet to Jenkins and dozens more, yet they still face the challenges that I first mentioned, such as incompatible data (no way to correlate data from various tools) or minimal collaboration and sharing.

On top of the hodgepodge of tools, the silo-ed teams and distributed nature of most enterprises today, we also find that there are a number of methodologies in use within an organization such as Agile, CMMI, Waterfall, etc. The struggle can be to blend work items across teams and the good news is that VSM can map multiple methodologies and still produce the needed traceability and visibility for business value evaluation.

Simply creating software faster does not solve the problem. In fact, it can create new problems, such as higher inventory, unchanged delivery processes and endless new surprises that will overwhelm teams.

Resources such as the State of DevOps Report give us a glimpse into how enterprises are doing and affirms the need for a more holistic view of DevOps that spans value streams throughout the organization and enables business value visibility.  We see in the 2017 State of DevOps report that though organizations are increasing deployment speed, quality is lacking and the result is bigger failures and more time needed to restore service. In other words as source code change accumulates, we lose track of what matters most:  the business value. “Going faster” with a primary focus on automation only increases risk and likelihood of Failure.

We must measure DevOps performance in order to drive business value.  A discussion on how collaborative Dev and Ops environments can work better together to create real digital business drivers is the next step. The best way to adopt DevOps is clearly understanding the business value that the new changes will deliver, the efficiencies and benefits gained, and any future possibilities to optimize each product and process in a delivery pipeline.

As a longtime leader in the software development space, CollabNet VersionOne has the leadership (recognized this year already by both Gartner and Forrester).  Our main mission, as we have shared this week at the DevOps Enterprise Summit London (DOES18) is to enable enterprises to — not only deliver better software faster — but gives organizations implementing Agile-plus-DevOps a better understanding of the value delivered through visibility and traceability across the product delivery pipeline.

To learn more about marrying DevOps and Value Stream Management, please visit: https://www.collab.net/solutions/value-stream-management or watch the recorded webinar, “Bringing Value Stream Management to the Enterprise.”

The post Expanding Agile-plus-DevOps Across the Enterprise Value Stream appeared first on VersionOne Blog.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

The ideal DevOps project starts with everything stored in source control. As a coach, I often find that too little thought is given to how a team will handle their source control branching strategy. Time and time again I have seen how this one decision determines much of the complexity of both product and process. The ease of the journey to continuous delivery is largely dependent on this decision. Teams see success when they take time to make this decision and don’t just buy into master-only development or a model such as GitFlow. Instead, they think about how they want to manage complexity, and it starts with source control and branching strategy.

As an industry, we don’t think about branching strategies in depth or enough. One of the key tenets of DevOps is systems thinking and people tend to forget about it, albeit unintentionally. If branching strategy is supposed to be the best thing since sliced bread, why does it feel or look like we’re trying to navigate through a train yard with no knowledge of how to navigate through the train yard? We’re not train engineers, at least not at the beginning of our efforts.

The current state of branching strategies is usually more like organized chaos. The less complex or the simpler your branching strategy is, the simpler your product is going to be, and the simpler it will be to maintain it. Feature branching and feature toggling are two ways to simplify:

  • Feature branching: Feature branching is when you take a feature, work on it by yourself in its own little space, and then merge it back in to the pipeline. Oftentimes I see people using a much more complex model called GitFlow. GitFlow can be abused as a branching model although it comes in handy for understanding that you still need to maintain all the code, but it’s infinitely more complex.
  • Feature toggling: Feature toggling can be helpful, especially if you work iteratively or with an agile process. Jez Humble and Dave Farley are very clear in their book Continuous Delivery and the follow up since writing this text book. Trunk “based” (not trunk only) development is key to the team understanding and integrating their changes together. When the team has to deal with integrating their changes on a trunk or master branch every day, they have to deal with the pain of integration immediately instead of somewhere down the line with a merge. When we introduce feature toggling, teams can provide toggles around their new features to make sure they have control of them in production. Feature toggling gives teams (Dev and Ops) the ability to make sure that when something doesn’t work as expected, it can quickly be turned off.

All of this means that we have to learn as an organization what works best for us. On the complexity curve, this isn’t a linear problem, it’s more exponential. Just think about the number of branches that you have to maintain and all of the work you have in progress at any given time – it’s naturally more exponential. What can also add to the complexity is if you’re using a model where you create a lot of branches, you might be doing work that’s not actually going to get out into your production environment, which is a problem, because then you’re spending time doing something that you might never get back to.

The more often we work together and on fewer things, the better off we are. Keeping it simple doesn’t mean that it can’t be complex. Keeping it simple just means that everybody knows what’s going on, everybody knows how to use their own internal process the right way, so that when it comes time for changes to come together for a release or a deployment, everything works together very, very smoothly. That’s how I hope you can be epic with your own branching strategies and reduce the complexity of your product.

The post Branching Strategy – The Forgotten Child of DevOps appeared first on VersionOne Blog.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Separate tags by commas
To access this feature, please upgrade your account.
Start your free month
Free Preview