So…when does the healing begin?

so-when-does-the-healing-begin-800x328Many people have commented on the statement that Kent Beck made in Snowbird around agile-manifestohis purpose for the meeting.  I wasn’t there of course, so I am most likely paraphrasing, but the generally accepted representation was that he wanted to “heal the rift between development and the business”.  As I was attending the first of the conference season
events, Mile High Agile, I started to wonder how well that has worked.  I’m not thrilled with what my conclusions currently are.  I’m hoping someone can show me where I’m wrong.

First, some history.  This might seem a little self-indulgent, but I promise that I do have a point, if only to set some context.  I discovered eXtreme Programming back around 1999. I read the book and rejected it, until I met people who were doing it.  It was truly revelatory. People were happy.  The business oriented folks were working together collaboratively with the rest of the team.  Not at a daily meeting, but throughout the day.   I started digging deeper and realized that someone had finally found a way to make software that managed the balancing act between good engineering and good project management. With that in mind, I went to the first XP Universe.  I left even more energized and ready to take on the world.

The next few years were fun and challenging.  Most of my time was spent practicing and Missing-Pieceevangelizing XP, and then agile came along.  I continued to be part of development, and attended many, many conferences and discussion groups.  And that is where it gets weird.  At the early conferences, the mix between developer and manager/project manager was a little lopsided toward the programmers.

Then there was a shift and all of a sudden it was hard to find someone at the conference who wasn’t a Scrum Master, the head of a PMO, a senior portfolio project manager, CSM, CSPO, SA, or EIEIO.  Several keynote speakers who I really admire started asking, “where are the programmers?”  This has led me to wonder, what now?  The rift was starting to heal, but it seems to be growing wider again.  Far too much attention is being spent on “what processes and tools do we need” and not enough on “how can we deliver working software?”  What can we do to reverse this trend?

So, now that I’ve indulged in reminiscences, it’s time to do something about it.  I’m not a big fan of just sitting around arguing over a course of action without actually doing something about it.  So let’s get the software development back into agile software development.

We can begin by refusing to accept a separation of “management practices” and “technical practices”.  There are just agile practices. The next time we’re going to spend training money on agile stuff, let’s skip the story writing and framework training, and let’s spend it on test driven development (TDD) or refactoring.  Better yet, let’s spend that time and energy on DevOps.  And don’t just send “Dev” to these classes. Wouldn’t it be cool if the technical folks had the same understanding of what agile means?  And the next time you’re inclined to ask for or write another report about “progress”, ask yourself “can I express this in terms of working software?”

So this is  my call to action: The time for the  healing to start again is now.  What will you do to make it happen?

Posted in agile, agile 2016, Agile Adoption, Agile Benefits, Agile Coaching, Agile Development, Agile Executive, Agile Leadership, Agile Management, Agile Methodologies, Agile programming, Agile Software, Agile Software Development, Agile Software Quality, Agile Teams, Agile Testing, Agile Training, agile trends, Continuous Delivery, continuous improvement, Continuous Integration, DevOps, Extreme Programming, Scrum Development, Scrum Methodology, Scrum Software, Software Craftsmanship, Test Driven Development, Uncategorized | Leave a comment

How We Celebrated Our CTO’s Birthday and How You Can, Too

ians-birthday-800x328

This week at VersionOne we had the opportunity to celebrate our CTO Ian Culling for having a birthday.  He won’t tell us how old he is, so I guess that means he’s over 20?  If you get the chance to meet him you might think he’s in his 20’s!

The man is a big part of the culture here at VersionOne.  He makes things fun in addition to being smart as hell and doing a bang up job as the CTO.  Walk into the development area and you are sure to find traces of Ian’s shenanigans, Dumb & Dumber orange suit, a plethora of nerf guns, Oculus rift, OneWheel, and more recently a Razor drift cart.

He’s also known for showing up at events in “special” attire.  It’s a thing we that we’ve come to expect from him, but there’s always an element of surprise to it.  So in honor of his birthday, we thought we would egg him on for an upcoming golf event that we have going on.

Below is the email that went out from Holly Reynolds, an interaction designer on the product development team.

——

In case you didn’t know…. it’s Ian’s birthday today…

We all know how much Ian loves to dress up and as much as he probably would like to come to work in his actual birthday suit, clothing is not optional here at VersionOne.

Stars pass and we honor them by celebrating their life after they are gone, but that seems like such a waste.  Ian’s not dead, but he is getting older.  Each of these remind me of him in a special way.  I’m pretty sure if you pick your favorite, we just might get to see this guy show up at the upcoming golf outing on May 16th  (don’t forget to sign up…you’re welcome Michelle).

Reply to me with your vote by 5 pm today or add your own suggestion for the birthday guy if you please.

The results will be compiled and shared later.

Ian Stardust
Creator, eccentric, minus the weird hair.

stardust

 

 

 

 

 


The Artist Formerly Known as Ian
Calm, cool and….collected;
Purple pants are not above this man

purple

 

 

 

 

Rowdy Roddy Culling
“I came here to chew bubble gum and kick ass.
And I’m all out of bubble gum.”

roddy

 

 

 

 

 

 

 

Comment on this post and vote for your favorite or make a suggestion of your own.  We’ll share the results in a couple weeks!

Posted in Agile Powered By People | Leave a comment

State of Agile: Are Distributed Teams Here to Stay?

are-distributed-teams-here-to-stay-800x328The 10th annual State of Agile Report is out.  I love reading the results of these surveys, as I learn so much about what other businesses are thinking and doing in the agile software development arena. Each year the results show the growth of acceptance and adoption of agile around the world. Gone are the days when recruiters would tell me to “get that agile stuff (or some word like that) off of your resume, or I can’t even get you an interview”. That is the good news!

But the survey also brings to light some uncomfortable facts about how agile is being attempted or practiced in the real world. This is just as important as all of the happy news. Identifying what is not going well is more important than just feeling good about the fact that all of this “agile stuff” is starting to take hold. Just as inspecting and adapting is built into our psyche as agilists, we need to apply it to our own movement.

One item that really stood out for me was the fact that more than 80% of responding organizations are distributed at some level. This is an incredibly high number, and more than twice the level it was last year. All of the research and experiential learning shows that one of the best things you can do for productivity and communications is to co-locate your teams. So is this a problem? I think it is. Teams need to be able to talk to each other, and should be able to do it without having to schedule a conference call, not to mention dealing with time zone issues.

Distributed Agile Teams

One of the 12 principles of Agile Software Development is “The most efficient and effective method of conveying information to and within a development team is face to face conversation”.  So distributed teams mean that we can at best be 11 and 1 in our agile world.  And the odds are not in our favor that this is the only thing we are “setting aside”.

So is this all bad? I don’t think so. But it is something we need to address and work on. First, let’s ask ourselves if we absolutely must have these teams distributed.  Just because they always were distributed, doesn’t mean they still need to be. If we absolutely must have distributed teams, we need to find the best way to facilitate conversation. What are some options we can consider to help that happen?

Form Teams Around Location

If you can, make the team at each location a fully functioning team. Rather than having QA in Denver and Development in Dublin, have a team in Denver that handles some features, and a team in Dublin that handles others. Or, if you can, just have each team pull from a common backlog. Emphasize the need to eliminate any perceived dependencies rather than just identifying them with yarn.

Anything But Email

Email continues to maintain its status as the world’s worst form of communication we’ve ever invented. There are many good online chat tools, as well as using Conversations in VersionOne that can help remove the formality that gets in the way of real conversation.

Respect

One of the most important, and least recognized, challenges to a distributed team is the “senior partner/junior partner” attitude that pervades most distributed arrangements. No team should be called “the offshore team” or “the remote team”.  Make sure to alter times for meetings so that the same team isn’t inconvenienced every time. It is better for each team to share the inconvenience of time zone disparities.

So yes, while I would love for all teams to be able to engage in face-to-face conversation, the world is clearly moving to multiple distributed environments. We could rail against this, or we can learn to work with this reality and find ways to make it as effective as possible.

Find out more by downloading the 10th annual State of Agile Report.

State of Agile is a trademark of VersionOne Inc.

Posted in agile 2016, agile survey, agile trends | Leave a comment

State of Agile: Culture Matters

culture-matters-800x328So you want to adopt agile within your organization or perhaps your transformation is already underway. You are not alone as the number of organizations of all sizes adopting agile continues to grow. The increasing popularity of agile persists because organizations are realizing benefits including the top three cited benefits from the 10th annual State of Agile Report:

  • Ability to manage changing priorities
  • Increased team productivity
  • Improved project visibility

But there are barriers to adoption and success with agile. Be forewarned, depending on the current culture of your organization, the path to agility could be long and challenging.

In the 10th annual State of Agile Report, the top barriers to agile adoption center on matters of culture including 1) the ability to change organizational culture, and 2) general organizational resistance to change. And the most often cited causes of agile project failure include 1) the company culture at odds with agile core values followed by, and 2) lack of experience. Culture can profoundly impact agile transformation and can also cause existing agile projects to struggle.

Barriers to Further Agile Adoption

Culture is defined as a way of thinking, behaving, or working that exists in an organization.

So does the culture drive the behaviors, or do behaviors drive the culture? I say yes to both in this chicken and egg debate. We own our behavior and can change as individuals. While we each have a personal value and belief system that governs our thinking and behavior, we also are driven by the need for self-preservation, a survival instinct. Placed within an organization value system, people most readily adapt their behaviors to align with the perceived organization values, expectations, and observed behaviors. To change the thinking and behavior of a group requires a recognized shift in the core values and expectations.

So why is culture so challenging? First the new set of values and expectations must be clearly communicated and understood by the group. Then the group must trust that it is safe to actually shift their thinking and behavior. Without a strong foundation of trust, this may take a long time. Any inconsistent application of new values and expectations from authority figures will signal that it is not yet safe to behave differently further delaying change. Some will be confused about how to adapt or to fit into the new expectations and will need guidance. Some may not accept the new values. While others may hesitate to move outside their familiar comfort zone or fear losing position or influence. Human psychology is complex and the factors are situational making it difficult to prescribe a canned solution.

But, there are some common ingredients in successful agile transformations. Start by instilling the agile valves. Communicate, explain, and model them. Leadership needs to believe in these values as others will quickly see through empty words. Learn from others. Provide coaching and mentoring, whether from internal or external sources, to help people understand their new role and how to be successful.  People fear and thus resist what they do not understand or feel they will not be good at. It is easier to just do what you already know.

Too often organizations focus agile adoption efforts on instilling the mechanics of a process framework while failing to understand the underlying values and principles of agile. To successfully establish an agile culture, you must set the values, expectations, and beliefs to fundamentally change the underlying thinking and behaviors around the agile set of core values. Agile involves a different way of thinking about the work and the people.

The agile core values are expressed by the Agile Manifesto.

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

Agile values are rooted deeply in a sense of mutual trust and respect for one another, a belief that people matter and that empowered teams are the keys to excellence. Effective collaboration is essential, and continuous improvement around the delivery of value is the goal. Frequent feedback loops provide opportunity to inspect and adapt and to adjust priorities.

An agile culture requires a foundation of trust and transparency. It challenges the status quo, listens respectively to dissecting opinions, and views failure as an opportunity to learn. It empowers teams and promotes team performance investing in team building and growth of team members. It embraces a spirit of service and excellence. Servant leadership replaces controlling and directing.

Some organizations announce “Yes, we are doing agile” now. Then they quickly become disillusioned when they are not experiencing the expected benefits cited by agile organizations.

When you look a bit deeper, the reality is that they continued to think and behave as before. What they valued and believed did not change. They just adopted some new terminology and some process activity. They were going through the motions, but with no fundamental change in thinking. Sadly they failed to understand the philosophy behind agile values and principles. The culture did not change.

While agile transformation may not always be easy, it does provide benefits for those willing to stay the course. Find out more by downloading the 10th annual State of Agile Report.

State of Agile is a trademark of VersionOne Inc.

Posted in agile 2016, agile survey, agile trends | Leave a comment

Improved Project Visibility: A Top 3 Benefit of Agile

improved-project-visibility-a-top-3-benefit-of-agile-800x328-2Visibility, the ability to see what is in front of you, is critically important for companies in order to remain profitable and relevant in their industry. Imagine how difficult it would be for you to drive a car without being able to see the road.  Adding in weather impediment elements can hamper your ability to reach your destination on-time even further. Even the sunniest days can blind your vision causing you to be distracted from where you are going.

Just like with driving a car, it’s a leader’s ability to chart the course with a clear vision for what the customer needs, along with what the teams can deliver, that is key to business success. So it comes as no surprise that 87% of the 10th annual State of Agile survey respondents said that the “ability to manage changing priorities” remains as the top improvement result of implementing agile practices. The ability to change helps foster the #2 item on that list, “increased team productivity” at 85%, and both of those are a result of “improved project visibility” at 84%.* In fact, managing change, increased productivity, and improved project visibility have been at the top of this list for the past five years.

Benefits of Agile

While change and productivity are so very important, visibility is the key that paves the road to agile success. Without visibility, how hard would it be to change course quickly? Without visibility how do you track and measure productivity improvements? And just like in driving, visibility is a two-way street. Teams need to know where they are going as much as the leaders of your organization need to know what the current map looks like, how fast the cars are driving, and how close we are to various destinations.

Whether you are a senior leader, or a member of an agile team, here a few key areas to help your company reap the benefits through better visibility practices:

Team Visibility

  • Know the important team indicators that drive the company’s success (e.g., velocity, throughput, productivity)
  • Align your work items correctly to help influence the success factors and be open to discussing this in your daily and weekly planning sessions
  • Be transparent with leadership and encourage them to be more involved in reviews
  • Share impediments and bad news as quickly and efficiently as possible
  • Practice extreme visibility with all your indicators, make them visible and known far and wide

Leadership Visibility

  • Become a trust agent for your teams and remember to always be building trust
  • Share company news and the key indicators that drive the company, have the teams help create these key numbers in partnership (e.g. share ownership on scorecards and dashboards)
  • Know how the teams operate and understand the value of their processes and ceremonies (act and think more like a team member)
  • Celebrate every win and encourage good behavior (vs discouraging bad behavior)
  • Ruthlessly remove impediments for the team to help them be successful

Improving the visibility in your organization can produce amazing results. Agile companies strive to provide customer value early and often. The State of Agile Report once again highlights how agile companies are seeing productivity improvements that boost company profits and increase the number happy customers.

Do you have the visibility your organization needs to succeed?

State of Agile is a trademark of VersionOne Inc.

 

Posted in agile 2016, agile survey, agile trends | Leave a comment

The Results Are In! Read the 10th Annual State of Agile Report

SOA-1024x512 (2)

VersionOne is excited to release the 10th annual State of Agile Report – one of the key ways that the company proactively gives back to the software development community.  For more than 10 years, this annual survey has collected unbiased feedback to give software professionals insight into agile trends, best practices, and lessons learned to help them succeed with their agile transformations. In fact this year there were a total of 3,880 completed responses, of which only 28% were VersionOne customers, further adding to the range and diversity of respondents. While many of the trends remained constant, we were surprised by some of the results.

Here’s a sneak peek:

  • Larger enterprises are embracing agile – 24% of respondents work for organizations with 20,000+ employees.
  • Agile is scaling – Scrum still dominates, but the Scaled Agile Framework® (SAFe®) made a big jump this year.
  • Agile talent and experience is growing – 63% said they were ‘very’ to ‘extremely’ knowledgeable about agile.
  • Agile is going global – 26% of the respondents work in Europe, and more than 18% work in Asia, South America, Oceania, and Africa.
  • You’re succeeding with agile – 95% reported that their organizations practice agile, and only 1% had experienced agile failure.

Read the report and get access to the archives of the previous nine State of Agile reports.

VersionOne is a registered trademark and State of Agile is a trademark of VersionOne Inc.
Scaled Agile Framework and SAFe are registered trademarks of Scaled Agile, Inc.

Posted in agile 2016, agile survey, agile trends | Leave a comment

Honk If You Love Hackweek

honk-if-you-love-hackweek-800x328

Alexa, honk Ian’s horn.”

Uncomfortable silence. You know the kind when you are in a demo and shit doesn’t work and the audience just stares at you. The air gets thick, you sweat a little and you shake your mouse really fast as if somehow applying intensity will change the outcome.

“Let me try that again….Alexa, honk Ian’s horn.”

More uncomfortable silence only to be broken by the sound of our CTO Ian Culling’s Tesla honking outside.

Success!honk-if-you-love-hackweek-photos

The audience erupts, cheering and laughing, while Denise Architetto and Shannon Cruey, smile having overcome the demo demons. They successfully demonstrated that you could use Amazon Echo’s Alexa voice commands to trigger a VersionOne Continuum™ automation pipeline to call the Tesla API to honk Ian’s car horn.

Inspired by Denise’s Echo project, Shannon paired up with Denise and extended the idea, just to see if he could do it. It was a spectacular display of what the spirit of hackweek is like at VersionOne. It’s all about: collaborating and developing ideas that we are passionate about.

It’s a coveted time in our organization where we get to set aside our daily responsibilities and work on our curiosities. The bi-annual event tends to stir up the kid in all of us. The creative pause gives us time to remember why we love what we do. And we get to build fun, useful, innovative stuff.

You might be thinking: what value does honking a car horn actually provide to the business? Or why would I give my team the time to work on such silliness when I have customers who are knocking at the door cash in hand for new features?

Hackweek is about infusing innovation into our organization and opening up the creative energy in our team by giving them the freedom to explore. Exploration opens the door to new ideas and new ways of looking at things.

It’s not about the end result of the hackweek projects. It’s about the thought process, the experience, the learning, and of course the fun. Great ideas come when the mind is relaxed and this is a time when the team gets to expand their thinking beyond our quarterly objectives.

Innovation is a core value at VersionOne and this is just one way that we get to express that.  The company gets the benefit of seeing new product ideas, improved processes, and solutions to problems that have been around for too long.

In some cases, hackweek projects turn into features that our customers come to love. This past hackweek produced more than 15 different projects, some of which have become feature candidates on our product roadmap. Estimably, an estimation game that allows teams to collaboratively estimate their backlog is a great example.  Estimably started as a hackweek project in 2013. It was inspired as a mashup between the planning poker method as popularized by Mike Cohn in his book, Agile Estimating and Planning, and the game Spaceteam, a collaborative game that encourages shouting and pushing buttons. The product was ultimately released in our Summer ‘14 release and has quickly become a customer favorite.

The benefits go beyond what’s delivered to the organization and our customers. Our people benefit too. Employees get the opportunity to work with people they might not normally get to work with. They get to learn and to explore new topics and technologies, as was the case with Alexa and the Tesla.

Honking Ian’s car horn will likely never make it into our product, but who knows, maybe asking Alexa to add a new story to your backlog during stand-up could be.

Posted in Agile Software Development, VersionOne | Leave a comment

Scaling Agility Without Killing Agility

Scaling Agility Arlen Blog

Frameworks for scaling agile methods have exploded in variety and popularity over the past few years: Scaled Agile Framework® (SAFe®), LeSS, and DAD are a few prominent examples. A common facet of these methods is the delineation of Portfolio, Program, and Team layers, with the idea of allowing goals at the executive level to be effectively communicated and driven through groups of teams.

The growth of scaling patterns has had significant effects, notably driving adoption and interest in areas where agile methods have historically encountered skepticism, such as government agencies and some large organizations. But not all is peaches and cream, as companies like mine which have helped organizations employ these methods have seen time and again. Based on these experiences, I offer the following guidelines for those considering the adoption of agile scaling frameworks.

  1. Get the team right first. Fundamental to all agile methods is the idea of autonomy at lower levels, such as a team in Scrum/XP, or a group of aligned individuals in Kanban. The ownership that this drives keeps teams more engaged and interested, while also speeding the process of evaluating and executing decisions. Our coaches have often noticed that introducing hierarchies early on can dramatically impede the ability of teams to decide, flex, and adapt to local circumstances, hence limiting the organization’s overall agility. Ensure that teams are able to make decisions and deliver locally before linking them in large hierarchies.
  2. Keep hierarchies as flat as possible. Layers of approvals slow decisionmaking, which hampers organizational agility. They also tend to slow delivery, and limit local innovation.  However, it is often the case that scaling methods are introduced largely with the idea of limiting organizational disruption, and hence they can provide an excuse for avoiding deeper (and often needed) organizational redesign. Consider how you might break an organization into smaller autonomous units before introducing multi-layered hierarchical planning processes.
  3. Pay attention to infrastructure and tooling. While perhaps the majority of agility focuses on the human element, the technology that underlies the process is just as critical when dealing with software delivery. The recent DevOps movement echoes the early agile method Extreme Programming by emphasizing the critical need to automate basic delivery capabilities through techniques like continuous integration, test driven development, and build automation, to the greater end of dissolving dependent silos. Absent this sophistication, teams find themselves still dependent on one another and external testing/release groups, once again defeating the local speed and flexibility that define agility. Scaling before addressing tooling can hurt organizations by allowing them to retain lengthy release cycles and dependent specialized teams, whereas short time boxes force better delivery capabilities.
  4. Release often to learn. Patterns like SAFe’s Agile Release Train can have some great effects by aligning historically separatist business-oriented silos such as Sales, Marketing, and Finance with their technology partners in Development and Operations. However, release cycles often end up settling on one-three month cycles. While there is nothing inherently wrong with this, it is of course possible (and often desirable) in many environments to deliver much more rapidly than that.There are two core purposes for releasing software in agile methods: to learn and to profit.  These must be considered separately. Constrained availability releases are generally meant to drive feedback at scale, like giving software to a field testing group or doing gradual rollout of new functionality through live A/B testing. This helps us understand what features are used most often, where glitches occur and so forth, and hence drive subsequent planning cycles. These should happen very frequently, on the order of days and weeks, and should not be constrained by higher-level planning cycles.Typically we have a higher bar for full-scale production release, which can also be driven or constrained by customer demand cycles. This can happen less often, as seems appropriate based upon market and customer cycles, but should not hamstring the ability to do small, quick releases for the purpose of learning.
  5. Ensure that information flows up, not just down. Building on the point above, much of the reason why agile methods encourage rapid releases is to ensure smarter, more empirical data-based planning, as opposed to the typical “guess what the customer wants then build it for months” approach we’ve seen historically. However, this requires that information garnered from user testing is rapidly received, understood and acted upon. In general, hierarchies dampen or eliminate the ability for such granular information to travel back up the chain and influence decision-makers.Some of my best agile business stories came from projects that were canceled or dramatically altered based upon information that was unavailable during initial planning, but that rapidly became available as ground truth became apparent from user and system behavior in the wild. If this information had been suppressed in the interest of avoiding disruption of some higher order, millions would have been lost in building the wrong thing. This isn’t an impossible problem to solve, but it requires curiosity and flexibility at higher organizational levels, and a clear strategy for ensuring that team-level data is considered properly during planning cycles.

Agile scaling methods have clearly filled a demand void, and they have introduced many tools and patterns that have been observed to work in certain environments. However, not every company or situation is the same, and hence no one method is likely to work the same way for everyone. One must remember that such methods are essentially toolboxes, so understand your goals before picking your tools, and keep in mind that true agility will never be so simple as adopting a methodology.

Lithespeed is a VersionOne premier partner. You can learn more about Arlen Bankston at www.lithespeed.com.

 

Posted in SAFe, scaled agile framewok, Scaling Agile | Leave a comment

2015 Spirit of VersionOne Award

2015-spirit-of-versionone-award-800x328

Mark Schultz in front of the Spirit of VersionOne award winners wall of fame.

Mark Schultz in front of the Spirit of VersionOne award winners wall of fame.

Each year the VersionOne team nominates employees for the annual Spirit of VersionOne award to recognize an individual who best represents the core values of VersionOne. This year we are sincerely honored to announce that Mark Schultz is the Spirit of VersionOne award winner.

Based on nominations from fellow employees, Mark exemplifies the culture and spirit of VersionOne. He is respectful, honest, authentic, and truly cares for the success of his team, colleagues, and customers. Many of the nominations also referenced Mark as the ultimate servant leader, who is constantly looking for ways to use his experience to help others succeed. The only attribute that exceeds his work ethic is his passion for the success of the company and its employees.

Since he first joined the company more than five years ago, he has consistently gone above and beyond to be available to others whenever needed. His positive attitude is extremely infectious. And while years of success have provided Mark with a wealth of experience to share, he remains incredibly humble and willing to learn from the experiences of others.

In a world of many managers, Mark is a true leader that inspires many on a daily basis. Trust, humility, and integrity are some of the qualities that great leaders possess and all of which you will find in Mark. It is rare to find one individual who has this combination of personal and professional integrity at such a high level. Thank you, Mark for your unselfish commitment to VersionOne!

Posted in agile, Agile Powered By People, Agile Software Development, VersionOne | Leave a comment

Shiny Objects and SAFe

shiny-objects-and-safe-800x328

R300x250-View-Nowecently, while I was teaching new teams on how Scrum fits in a larger Scaled Agile Framework® (SAFe®) structure, the question kept coming up from a product owner. “Yes, all this new Scrum stuff is great, BUT how do I juggle multiple requests from multiple stakeholders?” “My customers keep asking for more and more without taking anything off the plate.” I often refer to this as stakeholders chasing “the next shiny object.” Or, I want it all and I want it now.

Our business customers often fall into this mode due to the delivery nature of the waterfall projects we have been running for 40 years, where we deliver late, we do not deliver all they want, and it is not the best quality. As a result, I think they ask for everything they think they might need, which results in some of the difficulties of delivering what they REALLY need.

So the answer led me to explain how not only the Scrum teams deliver work, but how each of the teams is part of a larger ecosystem of project, program, and portfolio control that helps define work and priorities from original stakeholder requests to the work dispatched to the individual team members.

Walking the team through the SAFe Big Picture was exciting, and I’m not sure everyone took it all in a short time, but the questions kept coming: “Where do we fit in?” “What happens if I get buttonholed in the hallway and asked to do something by one of my customers, do I promise to deliver what they want?” and (well, you get the idea), new practices, new ways of acting and reacting to old situations. As team members they were afraid to tell a customer “No, we cannot do that”, or “I don’t know we have the staff to cover that request.”

In a recent engagement, the CIO never refused a request. We needed a way to corral her “Can’t say no” responses with SAFe. And we did. I’ll explain further a little later. The end result of these problems is a book of work that continues to expand, priorities that are not met, pet projects that take precedence and generally, queued work that gets out of balance with priority requests.

SAFe has some of the answers. We need to look at adding a strong helping of simple discipline and rigor following the SAFe principles and practices. But in my opinion, SAFe adoption alone is not enough – you need the Circle of Life in an IT shop: People, Practices, and Tools. All three combined are a recipe for success.

SAFe 4.0 Big Picture used with permission from © 2011-2016 Scaled Agile, Inc. All rights reserved. Original Big Picture graphic found at scaledagileframework.com.

SAFe 4.0 Big Picture used with permission from © 2011-2016 Scaled Agile, Inc.
All rights reserved. Original Big Picture graphic found at scaledagileframework.com.

People – SAFe does give us governance structures, roles that staff needs to play, and definitions of how they interact. This is highly valuable as it gives substance to the various roles in SAFe, while being flexible enough to add or revise, as needed. After all, it is a framework.

Process – With the introduction of Scrum and Product Owners, all the Inspect and Adapt cycles, potential added capabilities with Portfolio management to direct traffic, the picture looks a lot better from the standpoint of someone driving and managing those priorities. Now we actually have a framework to customize and make “our own” to manage a book of work for a medium to large shop (say 500 – 10,000 staff). New versions of “Essential SAFe” are available for smaller shops as well.

Tools – They give us the necessary discipline and rigor to carry through with the often complex dance of delivering systems and features to production. We need a single global collection point as a repository of the work to be delivered, a means of dispatching the work to various teams, a collection of metrics to report our current state, past efforts, future capabilities, compliance with practices, and so on. Tools provide us with the ability to do this. Strengthening the back-end delivery through DevOps is also a great capability to deliver.

Still, Stakeholders of Systems Want LOTS of Features

So, our business customers are still going to come at us from many different directions with a ton of Features, which can often be identified as “the next shiny object.”

What work may already be in stream or in construction can get impacted as the “next shiny object” can now be added to the list.

Shiny objects occur with amazing regularity as a result of:

  • A competitor introduces a new function – keeping up with the Joneses.
  • A stakeholder gets impatient for the delivery of a feature and becomes focused on that current shiny object.
  • A simple request in an email, which you mistakenly agree to do, goes from being a small paper airplane to a B-2 stealth bomber-sized project or program.

The results of stakeholders repeatedly chasing shiny objects tends to distract teams from delivery. Stakeholders can change their minds about what is important based on what is happening in the business world – which is often disconnected from our IT delivery world.

Unless we have a strong commitment to the SAFe processes and practices, we are unlikely to actually combat the shiny object syndrome.

SAFe practices corral, organize, prioritize, and deliver whole categories of shiny objects based on the needs and priorities of the stakeholders. At the portfolio level:

  • We corral, organize and prioritize (and even set the value of) shiny objects.
  • We use Kanban capabilities to organize and prioritize objects.
  • We use Value Streams to align work and fund the work (unfunded work like those B-2 stealth projects die at this point).
  • We make strategic level decisions for the good of the enterprise.

Remember that errant CIO who promised everyone who asked whatever they asked for? We gave her a sheet that became an input form to the portfolio screening process.

So what happens when that commitment starts to backslide or fail? How can we make sure a complex system of systems like this keeps on working?

SAFe is based upon a set of key Lean and Agile principles:

List of 9

Also of critical importance are the core values of SAFe:

ImageFor organizations to effectively implement SAFe, we also need a significant amount of individual and team based capabilities of rigor and discipline. In addition, we need some mechanism to keep us on track, and monitor speed, delivery, quality, and compliance, plus deliveries in a priority cadence that is driven by the stakeholders. Rigor and discipline of this type can come in the form of using an enterprise agile lifecycle platform (such as VersionOne) as a key to providing:

  1. Planning capabilities at various levels for various roles
  2. Metrics gathering and reporting
  3. Quick methods of prioritizing
  4. Globally distributed capabilities of defining and managing work

In my own experience working with large and globally distributed organizations, performing SAFe planning and execution, and utilizing technology with enterprise-wide capabilities of the caliber of VersionOne, provides them with the rigor and discipline to successfully be SAFe.

You can contact Tom Weinberger at www.linkedin.com/in/tomweinberger

Graphics reproduced with permission from © 2011-2016 Scaled Agile, Inc.  All rights reserved.

Scaled Agile Framework and SAFe are registered trademarks of Scaled Agile, Inc.

Posted in SAFe, scaled agile, scaled agile framewok | Leave a comment