It didn't take long for Stacia Viscardi to realize that as effective as agile can be, a plan-driven mindset may not be the best approach for every project or every team. Breaking the rules and embracing whatever it takes to motivate the team to get a project to doneness—and delighting the customer along the way—is a much better approach, even if it means breaking away from fixed iterations.
The #NoEstimates movement isn't really about no estimates. It’s about working in a sufficiently agile way that you don’t need estimates. When you break down your work into smaller chunks, you provide more value by delivering working product than you do by estimating. What would it take for you to work that way?
Last month, Forrester released a wave of portfolio management industry reports. In the Portfolio Management for Tech Management wave, Rally was named among the ten most significant portfolio management software providers, and was the only Agile vendor featured in the report. The inclusion of a pure Agile vendor reflects the growing importance of executing portfolio plans faster to hit critical market windows.
In midsize to large organizations, delivering business value faster requires scaling Agile practices to coordinate a large number of teams to deliver on an entire portfolio scope. But a good strategy is irrelevant if you can’t deliver on it in the timeframe required to stay competitive. As companies realize this, faster portfolio execution becomes an imperative.
At the same time, many of these companies still have traditional financial controls that impede their ability to respond to market changes: project funding that locks in requirements for long periods of time and mandates that developers leave their environments to fill out timesheets — a process that often results in inaccurate cost reporting.
Changing those financial practices takes time — and you can’t afford to wait. If you work in one of those organizations, you can still scale your Agile practices to deliver faster by integrating the Rally platform with PPM vendors.
Planview — one of the leading PPM vendors — has been honing its integration with the Rally platform for several years to create a realtime connection between traditional portfolio planning and Agile portfolio execution. The latest Rally-Planview integration provides added granularity into the visibility of Agile projects from PPM dashboards. When adopting Agile, the more visibility you can give to business leaders, the faster they can adapt their plans to respond to changes.
The year? 2015. The setting? An Agile transformation near you. The problem? You’ve hit a wall. Despite all your best intentions, you’re still not getting those promised benefits of Agile: speed, quality, value, sustainable growth across your organization. And your problems don’t stop there. You aren’t responding to market threats; you can’t even see market threats; you’re unable to retain great employees; you’re not an industry showcase. In the end, your Agile transformation has brought cynicism and distrust.
You may have heard me talk about “12 Agile Adoption Failure Modes” that concentrated on agile failure in the context of IT teams. Given the expanded adoption of Agile practices in organizations beyond the IT group, the threat of failure is now farther-reaching, with bigger impact.
Now it’s imperative that we look not just at Agile adoption, but at Agile transformation — where organizations move beyond Agile principles within their IT groups to business agility. To accomplish this, we transform from just doing Agile to being Agile.
Over the next few weeks I’ll share with you the top 12 failure modes of an Agile transformation that I’m witnessing in my work with organizations around the globe. Following are the first three.1. Lack of Executive Sponsorship
This failure mode evidences itself in several different ways and ultimately, it warrants its spot as the number one failure mode and drives all the other failure modes. Also known as “buzzword buy-in,” a lack of executive sponsorship can come at you from two directions
Imagine a small group of techies eager to adopt Agile in their team. With no executive sponsorship, they perform in a stealth environment — sort of a “skunkworks” adoption — under the radar of the existing organizational structure. Why? Because they’re hiding from the hierarchy of management (see the second failure mode, below) which could shut down their effort, and evading the current gate-driven approach to product delivery. While the project may gain some momentum, deliver value faster, and stir the souls of those involved, its sustainability is improbable. Lack of executive sponsorship will limit visibility into the team’s success and provide insufficient support for adoption across subsequent teams. Agile adopted this way will likely die.
In our second scenario, an executive decrees a switch to Agile delivery across the entire IT organization, but there’s no real follow-through: it’s simply a “checkbook commitment.” The executive demands immediate results, yet doesn’t change the metrics by which success is measured. Unengaged, the executive proclamation for an Agile adoption will never move to a true business transformation. At best, without the executive’s continued engagement, the organization will only have pockets of Agile success, typically limited to the team level. The organization will probably grow to blame Agile (and each other) for decreased quality and productivity. And the executive’s resignation letter will conveniently not include the word “Agile” in its summary of successes.
How do we prevent this failure? Leaders must accept that a successful transformation is a journey. Along this journey, leaders seek guidance for a transformation with a broad, sustainable impact. As part of the transformation they make a personal commitment to their teams, and in turn they recognize the personal commitment they are asking of their employees. Executives commit to measuring success differently from before, because the work is different from before. Success now favors value delivery, and time for learning is built into the transformation. Ultimately, success is celebrated across the organization and setbacks are seen not as failures or cause for blame, but as opportunities for learning and growth.2. Failure to Transform Leader Behaviors
Isn’t it great to have managers who just get things done? They know the right actions to achieve success; they direct their teams to perform these actions; and they have the power to control all aspects of the work and do whatever it takes to get it done.
Let’s pull this apart a little. When a manager tells the team what to do, there’s a false sense of success via control. When a manager powers through difficult circumstances regardless of the impact on the team, they leave the wisdom and the morale of the team behind.
Such a management style is a classic Agile transformation failure mode. All the team-level Agile practices in the world mean nothing if the manager doesn’t embrace a behavior that is more in service to the team than control of the team. Robert Greenleaf’s work identifies the characteristics of what he calls a “servant leader”: one who serves by leading, and leads by serving. An Agile transformation success story hinges on the ability of the leaders in the organization to take on these characteristics:
Systematic neglect: knows the limits of how much focus can be allocated to issues; learns what to focus on and what to let go of in order to support the team and achieve goals effectively
Acceptance: knows when to let go and trust the instincts of the team; accepts the wisdom of the team and is prepared to support it
Listening: facilitates useful and necessary communication, pays attention to what remains unspoken, and is motivated to actively hear what others are saying
Language: speaks effectively and non-destructively; clearly and consistently articulates the vision and goals for the team
Values: is responsible for building a personal sense of values that are clearly exhibited through consistent actions; supports team behaviors that build their sense of values
Tolerance of imperfection: modulates his or her own sense of perfection and offers to each team member an understanding of their strengths and challenges; cares more about “How can I help the team grow?”
Goal setting: owns the vision; doesn’t advocate for a personal belief in what is right but rather maintains the goal for a higher purpose, inviting others to align with the vision for the overall good
Personal growth: recognizes the value of continually finding diverse disciplines that invite new ways of acting in service to the team, and models this growth behavior to inspire others
Withdrawal: knows when to step back and allow the team to figure out its course, versus inflicting a personal sense of what is right for the team; carefully decides what to bring forward and when
What is your current organizational structure? How many layers of management exist around each Agile team? How is governance perceived, and who is ready to break down walls to make sure that value flows through your organization?
Failed Agile transformations suffer from an inability to change the existing organizational structure. What do I mean by this? Typical organizations have been set up for sub-optimization: that is, they measure success by departmental performance, versus overall value delivery. Here’s what that looks like: In the book This Is Lean, authors Niklas Modig and Par Ahlstrom depict a soccer field scattered with teams, each one in its own tent. Success is defined as any one team getting the ball out of its tent. But is that really success overall? In this scenario, as in our traditional organizations, we create accidental adversaries. We limit visibility of the organization’s overall effectiveness, and focus on our team’s success at the expense of success for the organization.
True Agile transformations push the boundaries of these existing organizational hierarchies. In the soccer field metaphor, we remove the tents. Now everyone can see where the ball is, where everyone else is, where the goal is positioned, what the referee is indicating, what the coach is saying, and what the scoreboard says. In your effective Agile transformation, you know what the true value is, you know who needs to be involved in order for the value to be delivered, and everyone associated with the value delivery has visibility into the current state of the value stream, including its blocks. They see the goal as successful delivery of value to the customer, and they coordinate as a whole to deliver that value.
Here’s another symptom that your organizational infrastructure is crippling your Agile transformation: Does your organization cling to a notion of efficiency based on resource usage — believing that loading people to 100% capacity is the best way to get work done, and then measuring people annually by how well they deliver in this fully-loaded mode?
To incent greater collaboration and communication, you need to revisit how you appraise work. Instead of annually, by individual, 100% utilized, with MBOs set 12 months earlier, you should invite frequent feedback; focus more on team effectiveness; and bias performance appraisal toward efficiency of value flow versus efficiency of workers.
If you’re not feeling the discomfort change brings, you aren’t truly transforming. If your transformation isn’t requiring you to invest in the technology and culture to support a new mode of visibility and collaboration, you aren’t truly transforming. If you’re adopting some Agile practices at the project level without looking at the bigger picture, your Agile transformation is poised for failure. And Agile, not the failure to transform the organization, will get the blame.
Stay tuned to the blog for Jean’s next three Agile transformation failure modes.
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.
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.
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.
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.
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 email@example.com.
So what do you have to say, will you help us inspire the next generation of software programmers?
If you are agile, you might spend some time estimating. If you’re using Scrum, you estimate what you can do in an iteration so you can meet your “commitment.” But estimation is a problem for many agile projects. The larger the effort, the more difficult it is to estimate. You can’t depend on ideal days. Do your estimates provide value? To whom?
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.
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.
Chicago, April 7, 2015, thanks to the Chicago Ruby meet up for making this possible:
- the story at 10:30 about moving pieces of paper across the cork board
- 15:30+ the estimation story (after the prologue about Wideband Delphi estimating)
- Kanban meets Disneyland at 17:00
Like any great process methodology, agile (and Scrum specifically) can lose sight of the best way to facilitate a development lifecycle from concept to delivery. David Hussman frequently encounters teams that are going through the motions. If your sprint planning meetings have disintegrated into quick listmaking exercises, David will show you how to reinvigorate your team.
It’s no secret agile projects can fail, but do you know the reasons they fail and how to avoid them? I could tell you why I think they fail. Instead, let me share what nearly 4,000 of your colleagues said were the eight reasons why agile projects fail and what you can do about it.
#1 Lack of Experience with Agile Methods
According to the 9th annual State of Agile™ survey, 44% of the respondents to the survey said they blamed the failure of agile projects on a lack of experience with agile methods.
Indeed, agile is first about how you think, but it also impacts what you do and how you do it. Teams that are deficient in the ability to apply basic agile practices tend to run into trouble. Investing in solid foundational training in agile techniques, and competent coaching as to their proper application, is money well spent.
#2 Company Philosophy or Culture at Odds with Core Agile Values
A total of 42% of the respondents said company philosophy or culture at odds with core agile values was the leading cause of failed agile projects. In fact, it was interesting to note that two of the top five reasons that caused agile failures revolve around the organization’s culture – company philosophy or culture at odds with core values and a lack of support for cultural transition (#5).
We know that agile is first about “how you think,” and then about “what you do.” If your organization’s culture is either ignorant of or outright hostile to agile principles and values, the prospect of success beyond isolated pockets of agile teams are slim. Understanding that agile impacts organizational values and facilitating that transformation is the first step to having a broader adoption of agile, and more success with agile as a means to successful delivery.
#3 Lack of Management Support
Some 38% of the respondents to the survey pointed to a lack of management support as the cause of failed agile projects.
This most typically pertains to “middle management.” In a poorly planned agile transformation, it’s not unusual for there to be great enthusiasm for agile at the team level and general support of agile at the executive level, leaving the project and program managers, functional “resource” managers, etc., in the middle of a messy “change sandwich.” Without strong executive guidance, this management layer can feel isolated and then simply dig in to survive. During an agile transformation, executive leaders need to model the behavior they want their management team to display, live the values they want them to adopt, and help them understand how they fit into the changing organization.
#4 External Pressure to Follow Traditional Waterfall Processes
Another 37% of respondents answered that they found external pressure to follow traditional waterfall processes impeding their projects’ success.
This is especially common in large enterprises, where there are agile teams and traditional waterfall teams working under the umbrella of the same portfolio. In such cases, the agile endeavors are usually being grafted into the existing traditional portfolio and project management (PPM) methodology, as opposed to the PPM methodology transforming to an agile approach. This doesn’t mean that agile can’t succeed, but it does mean that agile will need to coexist with (and to some extent, within) the traditional methodology. As I point out in the Get What you Want From Your Enterprise Agile Transformation white paper, two ways to facilitate that coexistence are to involve people from outside of the agile part of the organization in your planning, reviews, and retrospectives, and also to agree on mutual organizational interfaces for the exchange of information.
#5 Lack of Support for Cultural Transition
The survey found that 36% of the respondents saw a lack of support for cultural transition as the reason agile projects fail.
This is closely related to #2 and #3 above, Organizational values and norms evolve over time, and as they become established, they stubbornly resist change. Senior leadership holds the most leverage in facilitating the transformation of an organization’s culture to one that embraces agile. Tangible, active involvement at the executive level is critical to cultural transformation.
#6 A Broader Organizational or Communications Problem
According to the 9th annual State of Agile survey, 33% of the respondents said they found a broader organizational or communications problem causing agile projects to fail.
To reiterate what we’ve looked at in several of the preceding points, agile’s effectiveness beyond one-off teams here and there is dependent upon broader and deeper organizational buy-in to agile values and principles.
#7 Unwillingness of Team to Follow Agile
Unwillingness of the team to follow agile was the cause of failure for 33% of the respondents to the survey.
This tends to happen when the members of a team continue to identify themselves by function (Dev, QA, etc.). Team-level resistance can also happen when there is a team member with a “strong personality” who insists on retaining his/her position at the top of the pecking order. In both cases, it comes down to a perceived loss of identity or control. Executive leadership’s effective influence on the culture and the management team, thorough training, and capable team-level coaching are necessary to overcome these impediments.
#8 Insufficient training
Some 30% of the respondents to the survey said they blamed insufficient training for failed agile projects.
“Insufficient training” comes in three flavors:
1. Nobody received training;
2. Not everybody who needed training received it; or
3. Some/all received training, but the training wasn’t very good.
Skimping on training isn’t a good idea, and never leads to a successful agile organization. Make sure that everyone involved in your agile efforts receives rock-solid training. Do it early. “Everyone,” by the way, includes your executive leadership.
If you’re struggling with any of these barriers to agile success, this survey proves that you aren’t alone. The theme that underlies these impediments is that they can be traced back to cultural issues in the organization. In order to have significant and lasting agile success, there’s no getting around the need for strong executive leadership, solid training, and capable coaching.
Approximately 6% of respondents said “not applicable/don’t know.”
And 7.5% of the respondents told us that none of their agile projects could be considered “unsuccessful.” Which is great news.
So how are your agile projects doing? Are they succeeding or failing?
I have just been re-reading your closing remarks in this paper, that economic-cooperative gaming “does not capture the thought processes of the designer-programmer while creating and manipulating the design and expression of the program. An adjunct model, picking up aspects of a mental craft, needs to be added.”
Do you have any more ideas or examples or references in this area, I wonder?
And do you see the need any further “adjunct models”, or any need to modify the gaming model?
-by Bob Corrick on 7/12/2010 at 11:12 AM
Hi, Bob – Yes there are adjunct models needed. Since 2004 I’ve added Craft, Lean processes, Design as knowledge acquisition, and most recently, the Crystal 3-step model (discussion: Re: The three steps of Crystal) that includes practices, theory and self-awareness. You can read about all but the last in Foundations for Software Engineering (discussion: Re: Foundations for Software Engineering).
I just uploaded Talk not given at TEDxUoU 018.ppt which contains all five – you can look at that.
The point is that the Cooperative Game picks up social and team strategies, but not individual ones.
- I like best Peter Naur’s “Programming as Theory Building” (reprinted in the appendix of my ASD book) for both 1-person and N-person design assignments.
- The Craft aspect of the full model simply says, “Get good at what you do”, which doesn’t give any real guidance.
- The Lean aspect of the full model says to the 1-person designer, “Don’t collect inventory.”
- The Knowledge acquisition aspect of the full model says to the 1-person designer, “Spend time on where you need knowledge”.
- The Crystal 3-step model says to the 1-person designer, “Know thyself, and keep up with the theory in the field.”
So aside from not having specific craft guidance anywhere, the other parts of the model do offer advice to the 1-person designer.
cheers – Alistair
-by Alistair on 7/13/2010 at 11:05 AM
It´s a nice model, but it should complement software engineering, not substitute it. Management
nowadays is largely based on process, and quality thought as adherence to process(not only achieved/didn´t achieve goal). Any economic activity can be thought as goal-directed or process oriented, depending on how you view it.
Virtually all activities can be thought as games, process, or both.
-by Rafael on 11/12/2010 at 10:24 PM
Your blog is very nice and informative.
-by seo services delhi on 2/16/2012 at 12:28 AM