10 Agile Quotes From The World’s Most Brilliant Minds

Truly embracing agile can be a very hard task; agile practices are mostly learned and experienced, not something that you can easily glean from a book or article. But if you’re in search for valuable agile quotes to inspire you and your teams, here are 10 from the world’s most brilliant minds.

Brilliant Agile Quotes










1) “Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning.”
– Albert Einstein

As agile organizations, teams and team members, we must constantly question what could be better in order to continually improve.










2) “Perfection is not attainable, but if we chase perfection we can catch excellence.”
-Vince Lombardi

Perfection is a fallacy that leads to over planning, procrastination and failure to ship; agile is about focusing on delivering the best thing possible in a set time period.









3) “Unless someone like you cares a whole awful lot, nothing is going to get better.
It’s not.”
– Dr. Seuss

Agile practices focus on giving teams and individuals ownership of their work and accountability to the team and organization, so that you can care to make things better.










4) “Service to others is the rent you pay for your room here on earth.”
– Muhammad Ali

Service leadership and selflessness are foundation principles of agile; these are the prices to be paid to be part of an agile team.










5) “You simply have to put one foot in front of the other and keep going. Put blinders on and plow right ahead.”
– George Lucas

Agile is about doing as opposed to being paralyzed by over-planning; in agile you get the minimal necessary requirements and start working.










6) “It does not matter how slowly you go as long as you do not stop.”
– Confucius

A core principle of agile is working at a constant pace, which in turn enables you to deliver at a constant pace, as opposed to working sporadically and delivering nothing.










7) “We may encounter many defeats but we must not be defeated.”
– Maya Angelou

You will inevitably run into challenges along your agile journey, the key is to learn from these challenges and overcome them through standups and retrospectives.










8) “Intelligence is the ability to adapt to change.”
– Stephen Hawking

Agile is all about adapting to change; it was built on the foundational principle that business drivers will change and the development teams must be ready to adapt.










9) “Our greatest weakness lies in giving up. The most certain way to succeed is always to try just one more time.”
– Thomas A. Edison

In agile as in life there will be hiccups, but the iterative nature of agile makes it easy to do a retrospective and learn from our mistakes then move on to the next sprint and do better.










10)”If you can dream it, you can do it.”
– Walt Disney

We should never forget that agile was formed to find a way to develop software better and to more easily conquer our dreams.

What is your favorite quote as it relates to agile?

Posted in Agile Adoption, Agile Benefits, Agile Project Management, Agile Teams, Continuous Delivery, continuous improvement, Uncategorized | Leave a comment

Why Agile Won’t Make You More Productive

PrintAccording to the 9th annual State of Agile™ survey, more organizations are adopting agile in order to improve productivity:

“Consistent with last year, most respondents adopted agile practices to accelerate product delivery (59%) or enhance their ability to manage changing priorities (56%). However, in 2014, productivity (53%) has moved into the top 3, outranking last year’s #3 response – improved IT and business alignment.”

This made me wonder why there is a perception that if companies transition to agile, teams will be more productive. I put my waterfall hat on and read the twelve principles that support the Agile Manifesto from a traditional stance. I could see where delivering working software frequently and at a sustainable pace speaks to teams being more productive in agile.

For example, a project that is managed with a traditional waterfall process has big upfront design and is transitioned over to a team that knows they have six to nine months to produce the software. At the beginning of project, the teams are more relaxed and moving slower. The intensity level and sense of urgency is a lot lower. Then as time goes on – three months, six months – the teams and management start to miscommunicate and stop being as diligent about status meetings. Near the end of the project suddenly the pressure and a bit of panic set in. Teams and management are panicking because now they have to scramble to get the software finished. Maybe this is what creates the perception with waterfall that your teams are not constantly producing software; there’s an ebb and flow.

Waterfall projects start out with very low intensity. By the end of the project the intensity is extremely high and teams are burned out because they’re working crazy hours. The teams are producing low-quality code because they have to rush and the code isn’t being tested. The low quality work damages the team’s pride, which decreases morale and can lead to turnover.

The benefit of going to agile is that the team maintains a constant level of intensity and consistent working hours, which in turn empowers the team to produce beautifully working software at a constant pace.

So when people are saying “productivity,” what I think they really mean is “intensity.” If we’re maintaining a constant level of working hours, a constant level of quality and a constant level of delivery, teams are happier, they’re proud of their work and they enjoy going to work. This is super important because keeping good developers is really difficult. If good developers aren’t happy they can easily leave and go somewhere else. That’s why 26% of respondents to the 9th annual State of Agile survey said improving team morale was the reason they adopted agile.

That’s my take on why there is a perception that agile is more productive than waterfall. When I saw the 9th annual State of Agile survey, I was curious about why people felt that if they moved to agile their teams were going to be more productive.

Why do you think there’s a perception that if companies go agile, teams will be more productive?

State of Agile is a trademark of VersionOne Inc.

versionone-coaches-susan-evansAbout the Author
Susan Evans

Susan has more than eight years of agile project management experience in software development. Prior to joining the company, she was an internal coach who optimized the usage of the VersionOne platform to help many non-collocated teams thrive in their agile processes. Susan focuses on enhancing team relationships, communication skills, conflict resolution, and processes to help create happy teams that deliver high quality.


Posted in Agile Adoption, Agile Benefits, Agile Management, Agile Project Management, Agile Teams, Uncategorized | 5 Comments

Improving Agile Portfolio Management Coordination










Simply producing status reports in an enterprise with hundreds of software development teams isn’t enough to ensure that your products will be delivered on time. You have to ensure that the plans, dependencies, progress and schedules of those teams are all coordinated.

So, how can you coordinate the software delivery across multiple large-scaled systems across hundreds of enterprise software development teams?

Enterprise Software Development Coordination

Whether you’re coordinating several teams or hundreds of enterprise software development teams, you need clear visibility of plans, dependencies, progress and schedules across your portfolios, programs and projects. While it’s simple and easy to look at just a single feature and understand the dependencies and progress of various teams, it’s much more complex when you’re working with a portfolio or program that includes many features that can raise questions about what should be prioritized first in the various backlogs. As a portfolio or program manager you have to do some juggling, planning and coordination to make sure that the portfolio and program level features are moving and progressing as they should, and that all of the work that is needed to support and deliver your programs is really happening down at the team levels.

Let’s take a relatively simple example of an organization with multiple products in a suite. Each product has a team dedicated to its development. Some features are product specific and left to the product owners to drive per product. Some organizational level initiatives, however, may cross all of the products to drive forward company-wide strategies. If this is, say a U.S. company with a corporate initiative to expand into foreign markets, there can be many product and organization ramifications. Sales and services capabilities must exist in Europe. Products must support Value Added Taxes and multiple currencies, perhaps even multiple languages. Support teams must be able to handle extended hours and languages. Clearly, there is a great deal of coordination required to deliver on such an initiative and the better a businesses can handle such a challenge, the better its chances of thriving in a global marketplace.

Coordinating Plans

Each product that an initiative touches must be delivered in a coordinated fashion to provide the most business value possible. So you must plan out an initiative that spans multiple systems as a whole unit. That starts with prioritizing the work at the initiative level, then prioritizing and scheduling the various features that need to be delivered across teams in order to realize the business value of that initiative. By planning first at the initiative and then feature level, we can minimize Work–In-Progress (WIP) and get more value delivered quicker.

From a coordination standpoint it’s important to be able to see what the teams are planning as they’re doing the work, and to see whether or not they look like they’re on track to be able to deliver at the level where the business value can actually be realized. If we have three systems that are all working together to support a given initiative and only two of the systems deliver their parts within the scheduled release, we’ve wasted the effort of the two teams that did deliver. Take for example a feature that essentially is a transaction that goes from system A to system B to system C. If systems A and C plan their features for Release 1, but B plans its feature for Release 2, we don’t get to realize the value of that initiative until Release 2. A and C would be better off planning capabilities for Release 1 that could be used by the customer when Release 1 is delivered.

Coordinating Dependencies

An important consideration in coordinating your software teams is to understand which stories and teams are dependent on each other to produce a working release of software. It’s important to be able to quickly understand where those specific dependencies exist and how they fit into your greater program. On related features across products, not every story will have a dependency. It is important to understand, identify and track those stories and features that have dependencies across teams. For example, system A may require an update to a central security component that is managed by a specialized team. Both system A’s team and the security component team need to understand that linkage, coordinate the timing and track the plans of the other team as they evolve.

Building a dependency diagram at the epic level of your program will help you understand what features and initiatives are dependent on each other. Mapping your program’s dependencies provides visibility into the teams that require extra coordination and communication to remain in lock-step so they can deliver your product on time.

Agile Portfolio Management Dependency Diagram Screenshot from VersionOne

Agile Portfolio Management Dependency Diagram Screenshot from VersionOne


Coordinating Progress

In addition to tracking progress at the team level, it is important to track at the feature and initiative level as well. Business value resides at these higher levels, so it is imperative that organizations work to track progress and throughput at that level to keep the focus where the business value lives. This is best accomplished by having Kanban boards to view and understand the progress at the various levels of your program. Depending on the size of your organization you may have multiple levels of planning and monitoring. Large enterprises typically have an overarching portfolio level, followed by a program level and finally a team or project level. At the portfolio and program level there are high-level initiatives that are being developed which will typically be decomposed into multiple features that may spread across several different systems. Those features then get broken down into stories the teams are going to deliver. To effectively monitor these multiple levels, you’ll want the flexibility of tracking each level independently and understanding the context of features and how they relate to the higher level initiatives being driven.
Agile Portfolio Management Kanban Board Screenshot from VersionOne

Agile Portfolio Management Dependency Diagram Screenshot from VersionOne

Agile Portfolio Management Dependency Diagram Screenshot from VersionOne









At the team or project level, create storyboards and make sure the individual stories are part of epics that represent a program or feature on your program board. Storyboards enable you to see all the low level details of stories and how those details roll up into a feature. This allows you to drill down into the next level of detail needed. By mapping your programs with epic boards and storyboards you have the visibility to see your programs’ high level flow, medium level flow and low level flow. The dependency diagram lets you easily understand which initiatives, programs, epics, projects and stories are dependent on one another so that you can coordinate their progress.

Coordinating Time

Easily viewing progress and dependencies across an entire portfolio helps overcome many of the challenges associated with scaling agile across large enterprises, but it will not cure all ills. In order to fully coordinate your portfolio and programs you must be able to view progress and dependencies in relation to your delivery schedule. This is where it is good to have a timeline view. Your timeline should be connected to your dependency diagrams, epic boards and storyboards, enabling you to drill down into initiatives, programs, epics, projects and stories.

Agile Portfolio Management Timeline from VersionOne

Agile Portfolio Management Timeline from VersionOne









With a timeline view you can take an initiative and drill down into the features. This allows executives and PMOs to have visibility into when all the features are scheduled within a single view. Within a single view you can get an understanding of whether or not the delivery dates for programs, features and stories are coordinated across various levels of the portfolio and programs. For example if you have an initiative that you’re thinking you’re going to deliver in June, but then when you drill down into it you see that you have features for that initiative spreading out into July and August, that could be a problem. Being able to see views like that enables you to understand what may be at risk and what changes may need to be made.

Coordinating the Portfolio

By tracking progress, dependencies and release dates you can easily coordinate the progress of your portfolio from the very highest level, that of the initiative, to the very lowest level, that of the stories. Coordinating the portfolio will help increase the throughput of business value. These three views enable you to drill down and be able to see the progress of all your features from a delivery standpoint. Are they completed? Are they in progress right now? Do we have some that we haven’t even started yet? What is the status? What are the plans for this? Epic boards, dependency diagrams and timelines provide you with visibility into the progress of all of your initiatives. They allow you to see all of the features that a given organization might be working on. Or, they can show you all of the features that roll up into a certain initiative, providing that next level of detail to see what’s where from a delivery standpoint.

Whether you are an executive, line of business person, or a program manager, you can take a look at whether your teams are coordinated up and down the portfolio, program and team delivery levels. Being able to track across the various levels is extremely important. That’s the ideal way to manage the course of delivery. We’re tracking, monitoring, watching and having conversations between those various levels of delivery.


Coordinating software delivery across an enterprise of software development teams isn’t easy. However, if you organize, plan and track your portfolio as laid out above, you will not only deliver software on-time but you’ll help your organization maximize the throughput of business value.

So, how are you coordinating software delivery? VersionOne can help. 

Posted in agile dashboard, agile portfolio, Agile Portfolio Management, agile program, agile program management, scaled agile, Scaling Agile, Uncategorized | Leave a comment

What DONE Looks Like in DevOps

shutterstock_107535005Have you ever wondered about the meaning of DONE in DevOps? If you’re including DevOps in the definition of DONE, what are the agile changes that need to occur? Tweet This.

Fortunately, after working with many organizations exploring these questions, I’ve figured out that the answer isn’t that difficult.

So, what’s the meaning of DONE in a DevOps world?

Definition of Done in a DevOps World

DevOps creates the need for a lot of changes in the development process, not just from the technical aspect of continuous delivery, etc., but also with regards to agile. One of the aspects of agile that’s most interesting is the definition of DONE in a DevOps environment.

This isn’t a new problem by any means; people have been arguing about what the definition of DONE should be since Scrum became popular, and maybe even prior. As development teams begin to infuse DevOps practices, they need to rethink the definition of DONE. In the DevOps world, DONE doesn’t just mean it is coded and tested; it means it will work in production.

A few years back, at one of VersionOne’s AgilePalooza events, a tester asked a question that saddened me. She asked, “So what do you do when the story is done, but it hasn’t been tested?” I think a tear rolled down the cheek of each of the panelists as we had to explain, “it’s not done, if it hasn’t been tested.”

Fast forward a few years, and now we are in a world where most people recognize if code hasn’t been tested or the story is not done and stories are still missing the hooks for monitoring tools. There may be no way of saying, “It is not done until we know that it can be deployed safely and we can monitor its health while it is in deployment.”

In advocating change, I am suggesting the addition of DevOps requirements to your definition of DONE. I’m asking for you to agree that no story is done until the code has been written. And if you aren’t pair programming, then the peer review has happened, the tests are all passing, and the hooks for monitoring, performance evaluation and health checks are in as well. This is vital if you want to be successful with DevOps.

DevOps is all about moving quickly and deploying continuously. If you’re going to deploy continuously, you need to know that what you’re putting out is ready to go out. That means you have to be prepared for when the code meets the real world. You need to know right away if something bad happens when the code is deployed. You can’t wait until somebody calls and asks, “Why can’t I get onto your website anymore?” That is not good enough. If you deploy something, you have to find out before the customer does if something is not working right.

You have to make a few additions to stories to incorporate DevOps into the definition of DONE. The first step is adding the requirements to enable you to understand how the code is doing after deployment. Second, when you are planning a story, you’re going to need to estimate based on what it means to have the code in a state that will be successful post-deployment. Third, every single member of the team is a developer, and every single member of the team is a tester. Every single member of the team is now on the operations staff as well. That is where true success will happen in the DevOps world.


If you’re not fusing DevOps into your agile stories, you should start doing so right away. If you already are, make sure you’re including the hooks for monitoring, performance evaluation, and health checks as well.

What do you think about including DevOps into the definition of DONE? Are you going to start including post-deployment requirements in your definition of DONE?


versionone-coaches-steve-ropaSteve Ropa
SAFe Agilist, CSM, CSPO, Innovation Games Facilitator
Agile Coach and Product Consultant, VersionOne

Steve has more than 21 years of experience in software development and 12 years of experience working with agile methods. Steve is passionate about bridging the gap between the business and technology and nurturing the change in the nature of development. As an agile coach and VersionOne product trainer, Steve has supported clients across multiple industry verticals including: telecommunications, network security, entertainment and education. A frequent presenter at agile events, he is also a member of Agile Alliance and Scrum Alliance.

Posted in Agile Adoption, Agile Development, Agile Management, Agile Project Management, Agile Testing, DevOps, Uncategorized | 5 Comments

Empathy Driven Development: Rescuing Value from the Bermuda Triangle

Slide02Embarrassing Discovery

True story from when I was an agile coach for a multi-billion dollar, Fortune 15 giant…

It was a large agile program and we had new team members joining the program in waves. Not everyone was familiar with agile and we did not have money for in-person training. So we had to do the next best thing – remote agile training. Ugh!

Anyway, so I designed five 90-minute modules and as I was introducing the concept of optimizing value and minimizing waste, I asked the attendees who our customers and end users were and how our program helped them be more successful.

Nothing. Crickets.

I made an embarrassing discovery – most of the attendees were unaware of the “who our end customers and end users were.” Application architects, ScrumMasters, developers. This made it hard to talk about value and waste.

Course Correction

I was disappointed in myself. I had let my team down. So we worked with our product owner to shoot a series of videos that answered key questions about our business, our customers, our end users, their pain, what made them successful, and where our program fit in. We made these videos available on our team Sharepoint and made it mandatory viewing as part of onboarding.

A few months later, as I was walking around the office, chatting with some new team members, I asked the same questions – who were our customers and users, what were their pain points, where did our program fit in? I got great answers. No more crickets.


This got me thinking about how frequently we get sucked into the mechanics of Scrum – the events and artifacts, without reflecting on the business value we were chartered to create. I call this TRAM-SCRUM where TRAM stands for:

  • T-actical
  • R-itualistic
  • Am-ateur

This was not why Jeff Sutherland and Ken Schwaber created Scrum. They wanted us to use Scrum strategically and professionally. I learned more about professional Scrum in the Scrum.org Scaled Professional Scrum course in Boston last year, but that is another topic for another blog.

I began wondering about some of the most common obstacles that prevented teams from making the shift from TRAM-SCRUM to PROFESSIONAL SCRUM. One common pattern kept niggling away at me – the lack of stakeholder empathy.

The Bermuda Triangle 

Our industry still suffers from the curse of the Bermuda Triangle – the place where all stakeholder value goes to die. This triangle is a crafty chameleon and seems to have changed forms over the years, but you know what Shakespeare said –

“A stinky diaper-genie by any other name would smell just as stinky.”
– William Shakespeare

Or something to that effect, anyway. English literature never was my strong point.
But I digress. Even though we have migrated to the rituals of Scrum, in many cases, we still labor under the tyranny of the Iron Triangle of staff, schedule and scope, we just rename the sides to be more “agile”…









Cost Thinking vs. Value Thinking

So how do we stop getting more efficient at delivering waste and get more efficient at delivering value? This is another lesson I learned in the Scrum.org Scaled Professional Scrum Course









STEP 1: Let go off cost thinking – How can I relentlessly cut costs, without factoring in the unintended destruction of value.

STEP 2: Take baby steps towards value thinking – how can I increase delivery of stakeholder value at the lowest cost, to generate sustainable stakeholder value?
I think one of the barriers to making this shift is lack of stakeholder empathy. Which brings us to the question what is empathy…?


Empathy can be defined as…

“The action of understanding, being aware of and being sensitive to the feelings, thoughts, and experiences of another.”









It requires us to walk in another’s shoes…

Current State

So this might open up an avenue of exploration for you – what is the current state of empathy in your teams, when it comes to your stakeholders?

We must begin by creating a shared understanding of who your stakeholders are. They might fall into different buckets…

  1. SPONSORS: Fund the Scrum team
  2. END USERS: Use the increments
  3. END CUSTOMERS: Served by end users via the increment
  4. COLLEAGUES: Impacted by the Scrum team
  5. EMPLOYERS: Writing the paycheck
  6. COMMUNITY: In which the team works
  7. OTHER: …?

What indicators might you use to assess this state? Are you satisfied by the current state, or would you like to make any adaptations? And if you would like to make some adaptations, what might you do…?

A Fresh Approach

I humbly offer to you an idea that has been evolving in my mind for about a year or so – drum-roll please….









Empathy Driven Development

An approach to developing software that relies on team members making decisions based on empathy towards impacted stakeholders.

This approach requires development teams to creatively self-organize within the constraints of their organizations, to work around the barriers that isolate them from their stakeholders.

Empathy Driven Development (EDD) is complementary to agile software delivery with Scrum and is key to Scrum activities and events like backlog management and refining, sprint planning, daily Scrum and sprint review.

Common Barriers to EDD

As you think about using this approach, chances are that you will encounter some common obstacles…

  • Stakeholders inaccessible to development team
  • Un-validated assumptions about stakeholder needs
  • Layers of proxies between stakeholders and development team
  • Distrust between stakeholder proxies and development team
  • Cynicism / apathy towards stakeholders
  • No time / money to connect with stakeholders

If you are not ready to give up, here is a place to start…

Stakeholder Empathy Map

Get your team together in a room and…

  1. Create a grid with flip charts and tape.
  2. In the first column, ask your team to put post-it’s for all your stakeholders. Review and refine as a group.
  3. Now, ask your team to put up post-it’s to capture in 140 characters or less, each stakeholder’s…
  • ACCOUNTABILITY: What outcome are they responsible for?
  • MOST VALUABLE: What do they consider to be most valuable in the software they use, to help them deliver on their accountability?
  • MOST PAINFUL: What do they find most painful and frustrating in the software they use to deliver on their accountability

Review and refine as a group.

For instance, if we were doing this exercise in a group that develops patient care software used in a hospital, the outcome might look a little bit like this…









Desired Outcomes

Whenever I have facilitated this exercise, it has generated tremendous conversation among the team members, which is the desired outcome. We want this exercise to result in…

  • Good conversations
  • Identifying Un-validated assumptions
  • Head scratching
  • Curiosity
  • Action items to connect with stakeholders
  • Many follow-up actions and conversations

But most importantly… an increase in stakeholder empathy!

Head vs. Heart

As you explore this further, an approach that might help you facilitate the enquiry is a pattern described by Dr. John Kotter, international change leadership guru, Harvard Business School professor, and founder of Kotter International. In his book – The Heart of Change -Dr. Kotter illustrates one of his Six Key Principles

Head and Heart. Dr. Kotter’s research demonstrates that successful large-scale change requires engaging not just the minds of those we lead, but, more importantly, their hearts. Creating a vivid picture of opportunities ahead is vital. A heartfelt passion and commitment enables companies to overcome the inevitable barriers and obstacles encountered along the way to success.









Try to apply Dr. Kotter’s principle to establish an emotional connection between your team members and your stakeholders.


Challenge your teams to self-organize within the constraints of your organization to increase stakeholder empathy. Here are some initial ideas to get the ball rolling…

  • Try to get your developers to customer site…? (Make sure your most influential / cynical team members participate.)
  • Try to get customers to developer sites.
  • If you don’t have money, video customers using product and share it on your team site.
  • Maybe you can Skype / GotoMeeting with Webcam and watch your customers use your product and get frustrated or delighted with it.
  • Maybe you can include all these videos in new hire training / onboarding.

No matter what your team does, it must capture the smiles and frowns of your customers and stakeholders so it tugs at the hearts of your teams.

Call to Action

So here is my call to action – begin using EDD right now….

  1. Apply empiricism
  2. Create an empathy map
  3. Interact with stakeholders face to face or webcam. Make sure to talk to them and they are talking to each other.

Walk in their shoes. Self-organize and figure it out…!

  • TRANSPARENCY: Current state of stakeholder empathy
  • INSPECTION: Is it where you would like it to be?
  • ADAPTATION: Self-organize to make it better!

Rescue value from the Bermuda Triangle of cost thinking and value destruction!

And don’t forget to let me know how it goes.

Keep calm and scrum on!


Posted in Agile Development, Agile Leadership, Agile Management, Agile Project Management, Agile Teams, Scrum Development, Scrum Methodology, Uncategorized | 2 Comments

10 Benefits of Agile You Definitely Don’t Want to Miss Out On

PrintAre you sure you’re receiving the most benefits of agile possible? Do you know the top ten benefits of agile?

Read this article to learn what nearly 4,000 of your agile peers said were the benefits of agile that their organizations are receiving.


#1 Ability to Manage Changing Priorities

According to the 9th annual State of Agile™ survey, 87% of the respondents said agile improved their ability to manage changing priorities. If you’re familiar with the Agile Manifesto, this likely resonates with one of the values: Responding to change over following a plan. This value was, in fact, probably the foundational reason for the agile movement, and its top ranking in the State of Agile survey reinforces the value of agile.

There’s no question about whether adopting agile practices will enable you to better manage changing priorities. The fact that you have product backlogs that are being ranked by product owners as information becomes known improves your ability to manage changing priorities. Planning is continuous and each sprint is an opportunity to revisit priorities based on feedback and insight gained.

#2 Increased Team Productivity

Approximately 84% of the survey respondents stated that agile increased team productivity. Increasing team productivity has a lot to do with getting employees engaged and focused. Employee engagement comes from having a sense of purpose. Fostering employee engagement and team productivity are a natural byproduct of adopting agile.

When practicing agile the product owner works from a set of overarching initiatives and a vision for the product. The product owner communicates the vision and value-based decisions to the team on a regular cadence as they plan each sprint cycle. This makes it very clear to a team practicing agile that what they’re producing in every sprint cycle is always of the highest value. The team is protected from outside interference to minimize context switching and multi-tasking, so they can remain focused on completing the sprint plan. Agile retrospectives and continuous improvement initiatives further improve team performance.

#3 Improved Project Visibility

Another 82% of the respondents answered that agile improved project visibility. Personally, as a former manager, improving project visibility would be a top agile benefit for me. Agile provides all stakeholders, team members, the product owners, and management real-time access to the health and status of all of projects. There is no need to wait on formal weekly, monthly, or quarterly status updates. It’s simple to instead check the project or sprint level burndown and burnup charts and you can apply velocity for project forecasting analysis.

As agile teams are updating the work they’re doing on a daily basis, the entire enterprise is aware of the accurate, current status of all the work across all of their projects. It’s simple and easy, with the added benefit that the story and task boards provide the teams with a visible information radiator that promotes team collaboration.

#4 Increased Team Morale/Motivation

The survey found that 79% of respondents to the 9th annual State of Agile survey increased team morale/motivation through agile. I think that increased team morale is tied to many of the same factors that help with improving productivity. Team members feel more pride and satisfaction in knowing that they’re delivering valuable quality work that somebody wants and appreciates.

Increased transparency in agile reduces a lot of stress and pressure. Agile allows organizations to break some of the political dysfunctions. As self-managing teams, members have a direct voice in planning and can take ownership of their commitments, thus making team members feel more connected. As an added benefit, working with a happy team is fun and promotes growth and skill development.

#5 Better Delivery Predictability

In the survey, 79% of the respondents stated that agile provided better delivery predictability. This emerges as organizations become more experienced at practicing agile. It’s important to realize that you don’t achieve better delivery predictability from day one. You have to be practicing agile for a few sprint cycles, and there has to be a certain maturity that’s established across the project teams. Over time, as your teams continue to practice agile and begin to stabilize, their velocity metrics are going to emerge and stabilize.

Velocity is what enables agile organizations to better deliver predictability. In the past, project managers tried to forecast and lay out plans in an attempt to predict the future. As hard as we might try, we can’t control the future, so often those results were less than effective. An agile organization is going to use an actual proven measure, such as velocity, and they’re going to apply that to relative size estimates of their backlogs.

#6 Enhanced Software Quality

Another 78% of the respondents answered that agile enhanced software quality. We coach agile teams not to compromise quality in order to make up for time or scope. An organization can never really achieve the optimum benefits of agility if they’re not addressing the underlying quality of their product or service, as well as actively managing technical debt. It’s instilled into the agile principles and values that teams estimate and plan accordingly to build a quality product.

Oftentimes, with traditional waterfall approaches, there are schedule pressures that can lead teams to feeling that they have to compromise quality. If the team has a fixed scope and is pressured to deliver by an unrealistic fixed date, the team doesn’t have a choice but to compromise quality.

An agile team, however, isn’t pressured to make those choices. Quality is a recognized commitment by these teams. While the results may not be visible immediately, over time, as the culture changes, inevitably teams will produce higher quality product leading to customer satisfaction and more sustainable scalable products.

#7 Faster Time to Market

The survey results reflect that 77% of the respondents said that agile provided faster time to market. A desire to get to market faster is a very common reason that businesses initially decide to adopt agile. Organizations are feeling competitive pressures and the need to improve their product faster to stay relevant. If another company gets to market with something better, they can lose significant customer share.

I’m a little surprised that faster time to market isn’t higher up on the list. I suspect that maybe this is because it’s something that is not necessarily inherent in agile planning practices alone and may not be fully realized initially. Yes, our teams are going to focus on delivering working software on a short cadence and getting feedback early and often, but there may some additional factors that come into play before software can be deployed into the marketplace.

#8 Reduced Project Risk

According to the 9th annual State of Agile survey, 76% of the respondents said that agile reduced project risk. Practicing agile reduces project risk by the very fact that agile organizations are conducting very short feedback loops, typically every two weeks or less. Agile teams are presenting results and getting feedback from the stakeholders in short sprints. That in itself reduces risk because unforeseen issues are discovered early when they can be addressed with less impact.

Additionally, in some cases teams are encouraged to rank known high-risk items so that they can work these items sooner rather than later, to address what they learn earlier in the project. This helps teams evaluate the risks earlier and discover whether or not the project is going be viable and deliver the expected value. If needed, you can redeploy these teams to work on something else that will deliver better value.

#9 Improved Business/IT Alignment

Among survey respondents, 75% of the respondents said that agile improved business/IT alignment. I often hear improve business and IT alignment cited as a main reason to adopt agile. This is realized through the closer collaboration that is inherent in the agile principles and values, primarily through the transparency and the feedback from short inspect and adapt cycles. I think this is a clear benefit that’s easily realized as teams are aligned to have more open and transparent collaboration between their product owner, who serves as proxy for the customer, and business stakeholders. Defining and communicating clear project vision drives this alignment.

#10 Improved Engineering Discipline

Another 72% of the respondents said agile improved engineering discipline. Improved engineering discipline is, again, not something that’s inherently obtained just by the fact that you adopt agile planning practices. When the expectations and the cultural underlying principles of agile are taken to heart, team members are empowered to address the delivery of quality work as opposed to just getting work done. The ultimate foundation of a good solid product is going to be inherent with a good scalable design and architecture.

Once agile organizations come to embrace the agile principles with a goal of delivering high product quality, they must also embrace sound engineering discipline. Effective design, configuration management and testing strategies are essential to maximize agility.


These results show that there isn’t just a single benefit of agile. Different organizations and teams are gaining different agile benefits.

Would you like to find out even more information about the benefits your peers are receiving? Check out the 9th annual State of Agile survey.

State of Agile is a trademark of VersionOne, Inc.

versionone-coaches-jo-hollenAbout the Author
Jo Hollen
SAFe Agilist, CSM, CSP
Agile Coach and Product Consultant, VersionOne

Jo Hollen has more than 30 years of experience in the aerospace industry. Her career began with training Space Shuttle astronauts. Jo later moved into software engineering management where she introduced agile practices for Mission Control Center applications, including software currently onboard the International Space Station. With a passion for continuous improvement and challenging the status quo, Jo believes that servant leadership and agile principles and values just make sense and welcomes the opportunity to help organizations optimize their effectiveness.

Posted in Agile Adoption, Agile Benefits, Agile Development, Agile Management, Agile Metrics, Agile Project Management, Agile Teams, Enterprise Agile, Scaling Agile, Uncategorized | 1 Comment

The Critical Aspect of DevOps You’re Overlooking

shutterstock_95440231DevOps tends to be viewed through a technical lens, but the people aspect is what will dictate your success or failure.

So, how are the people challenges of DevOps more important than the technical challenges?

Recently I was reading Puppet Labs’ State of DevOps Report. Similar to VersionOne’s 9th annual State of Agile™ survey, this report has an interesting set of conclusions about the current state of DevOps. One of the things that I’ve been considering for some time is the strange proximity of DevOps people to technical problems.

There are a lot of technical aspects to doing DevOps. One example is continuous integration. When releasing, everything needs to be integrated and checked, no matter how small. DevOps takes it one step further with continuous deployment since you need to set up acceptance tests and unit tests, and all tests have to be automated.

One of the aspects of DevOps that reading this survey reinforced for me is that the folks who do DevOps the most successfully focus on the people aspect as much as, or sometimes even more than, the technical aspect. This brings the Gerry Weinberg conundrum to mind. Gerry Weinberg, considered by some to be the grandfather of agile, said that there’s always a people problem. The technical focus of DevOps may lead you to think that there isn’t a people aspect to focus on. In reality, while the technical piece is a focus, the people problem is huge and even more important.

DevOps is about bringing the functions of operations and development together, which means you have to break some stereotypes. You have to think outside the box. Those on the DevOps team must have the will to think about each one of the development stories through the post-deployment lens. Do you have monitoring as part of what you’re doing? Do you have performance constantly tested? Do you have all aspects of your tests automated? If not, then you’re probably not going to be as successful with DevOps.

This sounds technical, but it’s actually more of a people problem. It’s employing DevOps engineers who remember to do that. It’s not asking the question of should you automate, but how will you automate this specific story? That’s huge and it’s vital. It needs to be addressed and it needs to be addressed successfully. If you don’t, then you’re not tall enough to ride the ride. It’s not worth your time and energy to claim to be DevOps if you can’t do those things. DevOps takes time, energy and nurturing. It takes the willingness for individuals to step up. And it takes the willingness for management to step back and give your people the opportunity.

There were a couple of other fascinating people issues that that survey brought to light. The number one key to success in an IT organization, according to this survey, was employee happiness. This is an aspect people need to listen to this and build on. Employee happiness is number one. It proves that even geeky programmers like me don’t derive our employee happiness only from the really cool tools we get to use and work on. It’s nice, but it’s not enough.

The other fascinating people issue was getting the whole team together to work on the issues, thus becoming a cross-functional team. Everybody is responsible for everything, and that makes a huge difference in the DevOps world, even more so than in the traditionally agile world. Teamwork is where you’re really going to see the difference between just checking things in all the time and continuous deployment.

DevOps lends itself to being viewed through a technical lens, but the people aspect is what differentiates you from success or failure. I hope I have inspired you to take a closer look at how you are balancing the people aspect of DevOps with the technical.

So, what are some other people aspects of DevOps that should be focused on?

Need assistance with a Continuous Delivery/DevOps Assessment? Click here for info.

VersionOne and State of Agile are registered trademarks of VersionOne Inc.

Posted in Agile Project Management, Agile Teams, Continuous Delivery, Continuous Integration, DevOps | 1 Comment

How We Can Inspire a Million Children to Become Engineers


We can all agree that inspiring children to become engineers and scientists is of utter importance. However making a difference on a local level seems intimidating. But it doesn’t have to be so difficult.

Learn how you can help us inspire a million children to become engineers by providing just a few hours a month and a safe, collaborative meeting space.

The Challenge

A few years ago Robert Holler, the president and CEO of VersionOne, challenged VersionOne employees to come up with an idea that would help children in our local community learn about programming and technology. This seemed like an exciting, though daunting, community service project.

At VersionOne we feel it is an important responsibility to help the community. That doesn’t mean just the agile community, but also the local community. In fact, Gartner recently recognized our strong community presence in the Magic Quadrant for Application Development Lifecycle Management report.

Typically when we do local community projects they are hosted by charities that manage projects. This project, on the other hand, would be completely managed by VersionOne employees. At first, this seemed like it might take a lot more time and effort than any of us really had. Nonetheless, we were very excited to try to make it work.event_258537472

There were a lot of ideas that would need varying degrees of resources, but after a little research we discovered the global CoderDojo movement. It was a movement started in Ireland in 2011 by an eighteen-year-old student and a serial entrepreneur. They developed a vision for creating a safe and collaborative environment in which experienced adult mentors help students who want to learn about technology and programming. Their model was fairly lean, making it easy to launch. Parents bring their kids and their own laptops, so we just needed space and mentors to get started.

Since VersionOne is an agile lifecycle management company, we were attracted to the lean nature of this program. Soon after, CoderDojo Ponce Springs was born!

How It Works

The way it works is that parents bring their kids, ages 7 through 17, with laptops in hand to a meeting place. (In our case, we also have a limited number of laptops that have been donated by VersionOne for kids who don’t have a laptop). Volunteers help the students learn a programming language or other creative tools.


There are tons of great free resources like TeachingKidsProgramming.com, Khan Academy, Codecademy, CODE.org, Scratch, Blockly Games, and more. This makes it less burdensome for new volunteers to help because they don’t need to spend hours and hours creating their own resources.

However, a number of our volunteers have devoted additional time to creating step-by-step tutorials and interactive tools tailored to the needs of students who have been through the beginner materials online and want to more challenging things like building plugins for Minecraft or learning about building HTML5 JavaScript games.

Student-Driven Learning

We should stress, however, that the bulk of the work is on the students themselves! Mentors are there to assist and inspire, but not to provide long, drawn-out lectures. Students rapidly get hands on with the technologies and help each other learn. It’s a theme that’s woven throughout the CoderDojo movement. One of its own mentors is Sugata Mitra, who has conducted some amazing experiments in child-driven learning. Check out his TED talks to see what he discovered about the innate curiosity and capacity for learning and teaching that children possess.

Want to Start Your Own CoderDojo?

We share code and resources in GitHub in this open source and forkable CoderDojoPonceSprings repository. Feel free to create a copy of it and start one in your own community! Our Dojos take place in downtown Atlanta and in Alpharetta, Georgia, but one of our volunteers cloned our content and started a brand new CoderDojo in Henry County, about 30 minutes south of Atlanta.


It has been exciting to see the program still going strong for more than two years. The majority of the students are returning students, a good indication of the value they are getting from the program. In fact, many of the students have been participating for the entire program, and are becoming quite advanced. These are the students who have encouraging parents and peers outside of the Dojo as well, because it takes more just attending a Dojo to become really advanced.

What a CoderDojo is best at is providing the safe, collaborative environment for students who are ready and willing to learn to meet other enthusiastic peers with whom they can collaborate and increase their knowledge. Research has shown that when someone is learning something new, they often learn best from peers who are just slightly ahead. A CoderDojo also provides students who want to help others an opportunity to start giving back immediately. In one particular case, we had a student serve as a mentor to much younger students. He is thirteen and participated in a special event with students from an Atlanta elementary school.

A Million Children

Making a difference in the world can seem like a daunting feat, but the greatest lesson that I think has come out of our CoderDojo project is that by simply providing some space and time, we can inspire the next generation to get excited about programming and technology.

We probably have 300 different children come to our program each year. Over the next five years we hope to inspire 1,500 children in our program. If each of the three chapters that launched after ours has the same results, together we will inspire 4,500 children. And if 223 companies are willing to join us, we all can inspire 1,000,000 children over the next five years.

Volunteers in our Dojo are currently collaborating on tools and content to make starting a new CoderDojo even easier, if you’re interested to learn more or start your own CoderDojo, email us at coderdojo@versionone.com.

So what do you have to say, will you help us inspire the next generation of software programmers?

Posted in Agile Adoption, Agile Benefits, Agile Coaching, Agile Development, Agile Leadership, Agile Management, Agile Methodologies, Agile programming, Agile Training | 1 Comment

Product Backlog is DEEP; INVEST Wisely and DIVE Carefully

A product backlog stores, organizes and manages all work items that you plan to work on in the future. While providing agile training, consulting and coaching engagements at VersionOne, our clients often ask how to logically structure, organize and manage their product backlog. Clients also want to know how to prioritize or rank work items.

Here is a simple and easy-to-remember phrase that captures the key characteristics of a well-managed product backlog: Product backlog is DEEP; INVEST wisely and DIVE carefully … otherwise, by implication, you may sink (just kidding, but only slightly).

The key characteristics of a well-organized and managed product backlog are summarized in the image below. DEEP, INVEST and DIVE are meaningful words. They can be used as very useful acronyms to help us remember the key characteristics. In this blog, I will explain how to manage a DEEP product backlog well by INVESTing wisely and DIV[E]ing carefully.


Figure 1: Logical Structure and Key Characteristics of a
Well-Managed Product Backlog

The granularity or size of work items should be determined based on how far into the future you are planning a product, i.e., the planning horizon. The longer or shorter the planning horizon, the larger or smaller the work items. This makes sense as it takes a lot more effort to develop, specify and maintain a large number of small-grain work items compared to developing, specifying and maintaining a small number of large-grain work items. Smaller work items, stories, are typically developed by breaking down larger work items, epics. Stories are the unit of software design, development and value delivery.

DEEP product backlog

A product backlog may have several hundred or more work items, hence the acronym DEEP. Work items can be comprised of stories, defects and test sets. DEEP is also an interesting acronym capturing the essence of the logical structure of a product backlog.

  • Detailed appropriately: Workitems in the backlog are specified at an appropriate level of detail as summarized in Figure 1 and explained below.
  • Estimated appropriately: workitems in the product backlog are estimated appropriately as explained below.
  • Emergent: Product backlog is not frozen or static; it evolves or emerges on an on-going basis in response to product feedback, and changes in competitive, market and business. New backlog items are added, existing items are groomed (revised, refined, elaborated) or deleted or re-prioritized.
  • Prioritized as needed: Workitems in the backlog are linearly rank-ordered as needed, as explained below.

Sprint planning horizon, workitem granularity, estimation and rank order

If the planning horizon is the next, i.e., upcoming sprint or iteration (typically 2 to 4 weeks), each workitem is small enough to fit in a single sprint, and is 100% ready (“ready-ready”) to be worked on, as indicated in Figure 1 – see the top red-color region.  A ready-ready story has already been analyzed with clear definition (User Role, Functionality, and Business Value) and associated Acceptance Criteria.    Workitems planned for the next sprint are stories, defects and test sets.  The workitems in the next sprint have the highest rank order compared to workitems in later sprints or later release cycles.  I will soon explain how this rank ordering is done.   The rank order information is used to decide the order in which the team will undertake work on workitems in a sprint backlog, and also decide which incomplete workitems to push out to the release or product backlog at the end of a sprint time-box.

Workitems in the next sprint collectively satisfy the well-known INVEST criteria; it is a meaningful English word, as well as an interesting acronym coined by Bill Wake (see his blog Invest in Stories and Smart Tasks).  Its letters represent important characteristics of workitems in the next sprint backlog.   I will now elaborate on the letters in INVEST acronym.  Stories in the next sprint backlog should be:

  • Independent of each other: At the specification level stories are independent; they offer distinctly different functionality and don’t overlap. Moreover, at the implementation level these stories should also be as independent of each other as possible.  However, sometimes certain implementation-level dependencies may be unavoidable.
  • Negotiable: Stories in the next sprint are always subject to negotiations and clarifications among product owner (business proxy) and the members of agile development team.
  • Valuable: Each story for the next sprint offers clear value or benefit to either external users or customers (outside the development team), or to the team itself, or to a stakeholder. For most products and projects, most stories offer value to external users or customers.
  • Estimable: From the specification of story itself, an agile team should be able to estimate the effort needed to implement the story; this estimate is in relative size terms (story points), and optionally, it can also be in time units (such as ideal staff-hours or staff-days for the whole team). Thus, stories are estimated in story points, and also often in ideal time units.
  • Sized Appropriately: A simpler interpretation of this criterion is that each story is Small enough to be completed and delivered in a single sprint. The letter “S” can be taken to mean Sized Appropriately; specifically, each story should take no more than N/4 staff-weeks of team effort for an N-week long sprint (see “Scaling Lean and Agile Development” by Larman & Vodde, 2009, page 120.).  Thus, for a 2-week sprint, each story should take no more than 2/4 staff-week = 0.5 staff-week = 20 staff-hours of effort.  A story substantially larger than 20 staff-hours of total effort should be treated as an epic and be broken down into smaller stories.  For a 4-week sprint, each story should take no more than 4/4 staff-week = 1 staff-week = 40 staff-hours of effort.   If a sprint backlog has a mix of stories that are small, medium or large size stories (their average far exceeds N/4 staff-weeks), the average cycle time across all stories will increase dramatically reducing the team velocity.
  • Testable: Each story specification is very clear to be able to develop all test cases from its acceptance criteria (which is part of the specification).

Stories may be broken down into implementation tasks, such as Analysis, Design, Code Development, Unit Testing, Test Case Development, On-line Help, etc.  These tasks need to be SMART:

  • S: Specific
  • M: Measurable
  • A: Achievable
  • R: Relevant
  • T: Time-boxed (typically small enough to complete in a single day)

If a story needs to take no more than N/4 staff-week of team effort (ex. 20 staff-hours for 2-week sprints), all SMART tasks in a story should add up to no more than N/4 staff-week of team effort.  If you have 5 tasks, each task on an average should take 4 hours of ideal time effort or less.  Stories and its SMART tasks for the next sprint are worth INVESTing in, as the return on that INVESTment is high because they are scheduled to be worked on and delivered as working software in the next sprint itself.

Release planning horizon, workitem granularity, estimation and rank order

If the planning horizon is an upcoming release cycle (typically 8 to 26 weeks, or 2 to 6 months long – consisting of several sprints), workitems are “medium-grain” as shown in the middle yellow color region of Figure 1.  Typically, many of these workitems are epics; however, they should be still small enough to fit in a release cycle and can be completed over two or more sprints in a release cycle.  These epics are typically called features or feature-epics.  These feature-epics should still be specified with User Role, Action, Value and Acceptance Criteria formalism that is often used for specifying stories, but now you are capturing a larger functionality represented by a feature-epic.   Feature-epics are divided into stories – small enough to fit in a sprint – before the sprint in which a story will be implemented.

Over the time horizon of an entire release cycle, INVESTing in stories for an entire release cycle has poor returns, because it takes a lot of effort to ensure that the INVEST criteria is being satisfied correctly for a large number of stories covering an entire release cycle, and those stories are much more likely to change over the release cycle spanning several sprints; so this kind of INVESTment may not yield expected results as stories will very likely change during an entire release cycle after they have been specified.

Feature-epics in a release cycle can and should be estimated in relative size terms, but without expending the effort needed to break down all feature-epics in a release cycle into individual stories.   This epic-level estimation can be done by comparing relative sizes of epics.  I have presented a detailed approach for doing so in Part 5 of my 5-part blog series on Scalable Agile Estimation: Normalization of Story Points.  This method ensures that all epics and stories are estimated in a common currency of “normalized story point” which represents the same scale for an entire organization across all projects, sprints, release cycles, and teams.  There is no need to estimate epics in “swags” or “bigness numbers” which are entirely unrelated to story points.

It still makes sense to rank order feature-epics in a release cycle to decide which ones will be scheduled in Sprint 1, 2, 3, and so on.  However, this assignment may change as each sprint is completed and more information and learning emerge.

Product planning horizon, workitem granularity, estimation and rank order

If the product planning horizon is over multiple release cycles (typically 6 to 24 months) going beyond the current release cycle, workitems are “coarse-grain” as shown in the bottom gray color region of Figure 1.  These large epics or super epics require two or more release cycles to complete.  These super epics may be described in plain English (bulleted text) or with screen mock-up or video or prototype or with any form of expression suitable to express the intent and value of super epics.  These super epics are divided into feature-epics – small enough to fit in a single release cycle – before the release cycle in which that feature-epic will be implemented.

Over the time horizon of multiple release cycles, INVESTing in stories has even poorer returns compared to INVESTing in stories for a single release cycle.  This kind of INVESTment will not yield expected results as stories are very likely to change over much longer duration of multiple release cycles.

Large epics or super epics that need multiple release cycles to be implemented can and should be estimated in relative size terms, but without expending the effort needed to break down large epics into feature-epics, and breaking those, in turn, into stories.   This estimation can be done by comparing relative sizes of large epics.  I have presented a detailed approach for doing so in the same Part 5 of my 5-part blog series on Scalable Agile Estimation: Normalization of Story Points, as mentioned above.

It may not make much sense to rank order large epics over a multiple release cycle product planning horizon, as this assignment very likely will change over a larger time horizon; besides it does not matter if a large epic which is six to 24 months out in the future is rank-ordered 125th or 126th.  That level of rank order precision is not required.

I use the strategy of INVESTing in stories and SMART tasks only for the next sprint backlog, but not doing so at the release or product backlog levels. INVEST just-in-time in the next sprint as you plan it. INVESTing in stories and tasks over a longer time horizon will yield poor returns.

DIVE the product backlog carefully

There is rarely enough time or resources to do everything.  Therefore, agile teams must prioritize (rank-order, to be more precise) which stories to focus on and which lowest rank-order stories could be pushed out of scope when close to the end of a sprint.  For agile development projects, you should linearly rank-order the backlog, rather than do coarse-grain prioritization where stories and epics are lumped into a small number of priority buckets, such as Low, Medium, High, Critical priorities.  Linear rank ordering (i.e., 1, 2, 3, 4 ….n) avoids inflation of priority, keeps everyone honest, and forces decisions on what is really important.  It discourages the “kid-in-a-candy-shop” behavior when the business side clamors that everything is of high-priority or of equal importance.

Note that epics and stories are conceptually different, and should not be mixed or aggregated while developing a rank order.  An epic rank order is separate from a story rank order.

The responsibility of agile rank ordering is shared among all members of a team; however, the rank ordering effort is led by the product owner.   Similar to DEEP, INVEST and SMART,  DIVE is a meaningful English word, and also an acronym.    Product backlog items should be linearly ordered based on the DIVE criteria, which requires careful consideration of all four factors captured in the DIVE acronym:

  • Dependencies: Even after minimizing the dependencies among stories or epics (which is always a good thing to do), there may still be few unavoidable dependencies and they will have an impact on rank ordering.  If workitem A depends on B, B needs to be rank-ordered higher than A.
  • Insure against Risks: Business as well as technical risks
  • Business Value
  • Estimated Effort

In my blog post on Agile Prioritization: A Comprehensive and Customizable, Yet Simple and Practical Method, I have presented a simple but fairly comprehensive method for linearly rank ordering a product backlog (both stories as well as epics).  The blog explains how to model and quantify value, risk and effort for the purpose of rank ordering workitems in a backlog.   I will not repeat those details here. The method is extensible, customizable and very practical.   The Agile Prioritizer template makes the rank ordering effort easy.

Table 1 summarized how to manage DEEP product backlog with wise INVESTing and careful DIV(E)ing.

Table 1: Summary for managing a DEEP Product Backlogs with
wise INVESTing and careful DIV[E]Ing


I hope you find the statement “Product backlog is DEEP; INVEST wisely and DIVE carefully” a useful mnemonic to remember key characteristics of a well-managed product backlog.  I would love to hear feedback from you on this blog here, or by email (Satish.Thatte@VersionOne.com), or on Twitter@smthatte.

Posted in Agile Adoption, Agile Coaching, Agile Development, Agile Management, Agile Methodologies, Agile Project Management, Scrum Methodology | Leave a comment

Blink: Teams









In his book, Blink, Malcolm Gladwell tells the story of marriage counselors who can tell whether a couple will stay married or get divorced after watching a very short video of the couple talking. The researchers have been able to spot subtle signs of contempt that would eventually lead to divorce.

When it comes to scaling enterprise agile, organizations have their own subtle signs of contempt, things I (and any other person, really) can observe that would lead to the conclusion that any attempt at agile will not have long-term success in that organization. With issues that cut so deep, trying to scale them will fail.

What is that sign? What do companies do that sabotages their attempts to improve?

The answer is simple: teams.

More specifically, it’s how organizations treat their teams.

If you have truly cross-functional teams that stay together, empowering them and allowing them to learn from each other and proceed through the stages of team development, then your chances of success will be very high. True teams, with trust, a sense of commitment to each other, and the ability to develop a sustainable pace of delivery, will lead your organization to bigger and better things.

Conversely, if you treat teams as mere boxes into and out of which people are shuffled, if teams are built up and torn down when the priority of projects change with the direction of the wind, and people are not allowed to stay together long enough to form bonds, you will never succeed.

I know, I know; that seems like a pretty dramatic statement, but it is true.

You will not succeed.

You may have some short bursts of “success” that come from heroic project work and a few rock stars, but that is not sustainable. Do not let this “success” fool you. You are not creating sustainable teams that will be able to constantly deliver valuable software.

It is not just keeping teams together; they must be truly cross-functional. Many companies are still holding onto the old vestiges of shared services models or “component and feature” team models. These will work, but will dramatically cut into your ability to scale.

Simply put, your ability to scale will be limited by the shared team with the lowest capacity. It does not matter what that shared team provides; I have seen it in many different flavors: security, EDI, data warehouse, and other internal specific applications. Whenever you lead yourself into believing these teams are “special” and need to be separate from the others, it will be difficult to scale.

Let’s look at a couple of examples.

First, we have a shared team that is supplying work to the feature teams. Notice how all of their velocities are similar (velocity scores are in the circles). The primary reason is that the shared team is holding them back. The teams are fighting for the scarce resource (the shared team) and waiting for deliverables from that team is artificially throttling their velocity. In other words, they could go faster, but cannot because of the bottleneck.

More troubling, if you have to focus all of the teams on one important goal, you would not be able to achieve your goal as fast, and their velocity would most likely drop due to their reliance on that shared team.







Now let’s look at a development group with truly cross-functional teams. First, you will notice that the overall velocities are higher, mainly because there is no shared team throttling their work. Second, if you had to focus all of the teams on one goal, all of the teams would be able to drive in that direction. No one team would become a bottleneck, and all are contributing to the goal.

So… how do we create cross-functional, sustainable teams?







First, know that it is not easy. It takes dedication, empowerment, and a top-down willingness to make it through the transition. We know from Dr. Bruce Tuckman, a researcher into the theory of group dynamics, that teams will struggle in the beginning. As they are going through “forming and storming,” productivity will crater. However, your patience will be rewarded once they normalize and then reach performing level.

Second, don’t be afraid to take risks with teams. Blend your “A” players with some junior people. Teams of all “A” players tend to linger in the storming phase as everyone is trying to be the alpha dog. Maybe let the teams choose themselves (just beware of the playground last-to-be-picked problem).

Finally, break up any cliques. Especially if you’re moving from a shared service model, those folks will most likely want to stay together. Why? They have been a team! But you need to spread their skills around (remember, we want CROSS functionality), so they need to find new teams.

The lynchpin to being able to consistently deliver great software is the empowered cross-functional team. They are the foundation of predictability within an organization. Without sustainable teams, executives tend to fall back into the “just get it done by X date” model. This model only serves to burn out the people and does not help the organization to achieve its goals. Building a solid foundation of teams takes time, effort, and patience, but the rewards greatly exceed the cost to get there.

Find out how VersionOne empowers successful teams with TeamRoom.

Posted in Agile Adoption, Agile Benefits, Agile Development, Agile Management, Agile Project Management, Agile Teams, Scaling Agile, Uncategorized | Leave a comment