How We Can Inspire a Million Children to Become Engineers

CoderDojo

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.

event_258537462

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.

Impact

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 | Leave a 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.

Figure1

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

Table1

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

shutterstock_97093796

 

 

 

 

 

 

 

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.

Blink_image1

 

 

 

 

 

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?

Blink_image2

 

 

 

 

 

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

8 Reasons Why Agile Projects Fail

Print

 

 

 

 

 

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.

Conclusion

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?

This is the second article in a series of blog posts on the 9th Annual State of Agile survey. You can read the first article on “Top 10 Tips for Measuring Agile Success” here.

Posted in Agile Adoption, Agile Development, Agile Management, Agile Methodologies, Agile Project Management, Agile Software, Agile Teams, Agile Training, Enterprise Agile | Leave a comment

Top 10 Tips for Measuring Agile Success

State_of_Agile_Report_2014

Choosing the right agile metric to measure agile success is really simple, right? I wish that were the case, but in reality choosing the correct agile metric can be a little tricky.

So, how do you get the most out of your agile metrics? I reviewed the 9th annual State of Agile survey, which compiles insights from nearly 4,000 respondents, to find out how agile practitioners are measuring the success of their agile initiatives.

 

#1 On-Time Delivery

According to the State of Agile survey, 58% of the respondents* said they measured the success of their agile initiatives by on-time delivery.

With agile, our schedule is fixed and our scope is flexed. What does that mean for on-time? Well, time just happens, so theoretically, we are always on time. But, on-time is generally measured in context with the expectations about what will be delivered. To measure and have visibility of what is being delivered, we may look to the out-of-the box metrics of the burndown or the burnup.

For instance, in this VersionOne burndown chart you can see progress as the team heads toward an expected end date.

metrics1

 

 

 

 

 

This burnup chart, on the other hand, allows you to see the trend of getting stuff done, as well as the impact of scope changes.

metrics2

 

 

 

 

 

 

 

#2 Product Quality

A total of 48% of the respondents to the survey said they measured the success of their agile initiatives through product quality.

Quality is often measured in multiple ways, including looking at the customer satisfaction, revenue growth, and the technical aspects of testing conducted throughout the development life cycle. With agile software development teams, we’ll look at our velocity of completing working software with quality built in. We tightly couple continuous testing and inspection throughout the lifecycle of the development, so we’ll constantly be monitoring testing trends as well as constantly inspecting build and code health.

For instance, in this testing trend chart you can see the cumulative progress around testing activities. Ultimately you want to see all green, but a large amount of red along the line might reflect some issues in the code base or process.

metrics3

 

 

 

 


#3 Customer/User Satisfaction

The survey found that 44% of respondents measured the success of their agile initiatives by customer or user satisfaction.

As with all these benefits, there are multiple ways to measure the outcomes. In the case of customer/user satisfaction, these include looking at the Net Promoter score, sales figures, number of support calls vs. number of features delivered in a time period, or usage statistics of product or site capabilities.

#4 Business Value

Approximately 44% of the respondents to the State of Agile survey stated that they measured the success of their agile initiatives by business value.

And several of the principles of the Agile Manifesto recognize the importance of delivering business value. Measuring business value is very explicit when we know that there’s a contract for work to complete or a compliance need and fines if we don’t finish the work. On the other hand, sometimes measuring value is prospective or speculative in the sense that the market inputs drive decisions and the value is often a best guess. Having a business value score applied to the features to be delivered can measure value.

Here’s a sample epic cumulative flow chart based on value. This helps you see the delivery of anticipated business value as features and other large stories are completed. 

metrics4

 

 

 

 

 

 

 

 

#5 Product Scope (Features, Requirements)

Another 39% of the respondents answered that they measured the success of their agile initiatives with product scope.

Setting a goal around what to get done over the next three months, then tracking status, and getting it completed is hugely rewarding. Actually having real-time feedback as to the progress of work is valuable to everyone on the team, from the engineers to the program managers. With agile software development projects, you can always rely on the burndown charts, or just visualize the progress of the cards moving from left-to-right on the project kanban board.

Here’s an epicboard in VersionOne that helps the team track and visualize the progress of features at a program level. Or if you’re using Scaled Agile Framework® (SAFe®), you can see progress at the release train level.

metrics5

 

 

 

 

 

#6 Project Visibility

Project visibility was the measure of choice for 30% of respondents to the survey.

One of the best ways to build trust is transparency. That means having the plans out in the open and making progress visible to all. Sharing progress at multiple dimensions provides the different stakeholders with information that makes sense from their point of view. Metrics that show feature or overall progress against a targeted plan can provide great insights.

In this chart you can visualize progress on a feature and known work. The red diamond represents what was actually anticipated, so it’s easy to gauge whether you are above or under the anticipated scope.

metrics6

 

 

 

 

 

 

The other reason visibility is important is because we need to have alignment among internal teams so they can best manage their work in relation to component or service dependencies.

Understanding the impact of one team’s work on another team is critical. By looking at the dependency chart below, it’s easy to identify the stories at risk.

metrics7

 

 

 

 

 

 

 

#7 Productivity

According to the State of Agile survey, 29% of the respondents said they measured the success of their agile initiatives through productivity.

The concept of productivity in an agile world is a measure of outcomes, not output. So looking at burnup for a product or based on value is hugely impactful. Simply looking at a burnup of count of stories or features over time is a great way to understand how much the team is actually delivering.

#8 Predictability

Approximately 25% of the respondents from the survey said they measured the success of their agile initiatives by predictability.

A predominant metric used to assess predictability is velocity trend. For a three- to four-month period, this shows how much work has been completed at a sustainable pace on average. A velocity that wildly fluctuates might reflect a team that is changing, work that is unpredictable, or simply a team that is still getting used to defining work small enough to complete in an iteration.

A velocity trend chart like the one below not only helps you see performance, but also gives you visibility into whether or not the team’s output is at a predictable state – as this one shows.

metrics8

 

 

 

 

 

 

 

You can always try to assess velocity based simply on the count of story cards completed every week. This is usually the best indicator of predictability.

#9 Process Improvement

Another 23% of the respondents said they measured the success of their agile initiatives by process improvement.

A core tenet of all lean and agile mindsets is continuous improvement – constantly getting better. But how do you know you are getting better unless you are measuring the outcomes? There are all the metrics above that help, but there’s also the extremely helpful cumulative flow chart which shows how well work is flowing through the lifecycle.

With this team level cumulative flow chart, you can see where bottlenecks or slowdowns may exist.

metrics9

 

 

 

 

 

Also, there’s cycle time – which helps us with planning and predictability. Cycle time is a great metric to view over time to see if process tweaks and adjustments are having an impact on productivity.

For instance, in this cycle time report, you can see the level of variability and performance across the various estimated pieces of work.

metrics10

 

 

 

 

 

 

 

#10 Don’t Know

Just 11% of the State of Agile survey respondents said they didn’t know! Well, if you don’t know the benefits, try to start looking at the metrics above. You’ll see improvements in delivered value, better quality around what is produced, a more predictable cadence, and ultimately happier customers.

Conclusion

These results show that there isn’t just a single metric that everyone uses. Different organizations, types of management, and teams need different metrics.

Not sure which metric is right for you? Check out the 9th annual State of Agile survey to learn more about what nearly 4,000 of your peers are doing.

What metric do you use to measure your agile initiatives’ success?

*Respondents were able to make multiple selections.

State of Agile is a trademark of VersionOne, Inc.

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

Walk Before You Run: Understanding CI in CD

With the buzz around Continuous Delivery (CD) these days it might seem like an antiquated notion to even speak of, let alone write about Continuous Integration (CI). However, in the many conversations we’ve had with organizations looking to implement CD or in the midst of an implementation (and stumbling), it has become rather clear to us that there exists a wide chasm that needs to be bridged on the foundational aspects that support an organization’s desire to adopt CD. CI is a key supporting construct whose principles are still not understood/implemented with sufficient clarity, and hence worth a revisit.

Continuous…

Integration is the process of eliciting fast, automated feedback on the correctness of your application every time there is a change to the code.

Delivery builds upon the earlier concept by providing fast, automated feedback on the correctness and production readiness of your application every time there is a change to code, infrastructure, or configuration.

The premise behind CD is that software is always deployable. Hmm. Sounds familiar. Anyone glance at the principles behind the Agile Manifesto lately? The very first principle states:

“Our highest priority is to satisfy the customer – through early and continuous delivery – of valuable software.”

It seems CD is less a newfangled notion and more about realizing a long-standing promise. And, the key prerequisites toward realizing this ideal are:

  • Continuous Integration
  • Comprehensive Configuration Management
  • Multi-level Automated Testing

The rest of the post delves a little deeper into the CI aspect of CD.

Continuous Integration

CI is the process of executing the software Build-Deploy-Test (BDT) cycle frequently with minimal manual intervention with the underlying principle as one of constant communication and feedback among team members. Martin Fowler, a well-known author and speaker on software development topics, describes it as:

“…a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily – leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.”

CI_image1

 

 

 

 

 

If It Hurts, Bring the Pain Forward

CI provides a framework for detecting software integration errors quickly, allowing teams to develop unified software more rapidly while ameliorating the dreaded “big bang” integrations and associated code merge misery that plague many software teams. CI aims to eliminate integration uncertainty by encouraging developers to make frequent integration of their work part of the daily development activity. It does not eliminate the challenging activity of code merge and conflict resolution – it sharply reduces the pain associated with infrequent merges by demanding small, incremental merges daily. It trades debilitating pain later for some pain today.

How does it change what the developer does daily?

CI is a mindset, and while the process can be executed in manual fashion, most teams use a tool to enforce the discipline. The figure below depicts the typical integration cycle within the context of using such a tool – a CI server – to help implement the practice.

CI_image2

 

 

 

 

 

 

 

 

 

 

 

  • The day begins with the developer pulling the latest codebase from the source control repository
  • Then there is the typical development activity (guided by automated unit tests preferably)
  • Developer is ready to commit code into the repository and might need to communicate the intent to the team
  • Updates local working copy with code from the repository (since others may have updated the code stream)
  • Merges code and resolves any conflicts locally
  • Builds and ensures tests pass locally
  • Commits code into the repository
  • The CI server “listens” for changes in the code repository. Any change triggers the build and test cycle automatically, and the results communicated to the team members in an automated fashion. A broken or “red” build (either due to compilation or test failures) is indicative of an integration failure and should be tended to immediately. Bringing the CI environment to “green” should become the top priority of the developer/team.

Where do we begin?

As is evident from the description of the integration cycle, the adoption of CI mandates certain practices that are necessary to make CI possible and effective.

Single Source Repository

All source code files, database scripts, dependent libraries, property files needed to build the deployable software artifacts need to be version controlled in some sort of a source control system since the CI server monitors changes to the code repository to trigger the BDT cycle. As rudimentary as this constraint might seem, there remain some organizations that haven’t yet reached that stage of maturity where centralized source control and version management is a given.

Build Automation

Even with centralized source control in place, many organizations still rely upon manual processes to creating deployable software artifacts that involve coordination across organizational silos and team members. Since the premise of CI is to kick off a build without human intervention, it necessitates the creation of a single-click build capability in order to automate the BDT cycle. The rule of thumb prescribed for build automation is to be able to stand-up a running system from scratch.

Test Automation

While not a precondition, test automation plays a key role in providing reliable feedback to the team that the software components are not only integrated but also working correctly. Don’t let test automation get in the way of moving towards CI, but its best not to wait too long to introduce automated tests into the mix to truly harness the benefits of the practice.

What are some of the “best practices”?

  •  Frequent commits to a common code stream
  • Disallow commits into a “broken” build
  • A “broken” build on CI should be attended to immediately and its resolution should be of utmost priority
  • Address long-running builds. 10-15 minutes is ideal; more than 20-30 min is the outside limit for meaningful frequent integration. The shorter the cycle the better. The most likely culprit could be integration tests masquerading as unit tests. Stage the builds if necessary.
  • Rebuild the database (build from zero)
  • Build/deploy/test in production-like platform
  • Provide capability to QA to deploy targeted builds to higher-level environments

What are some of the misconceptions?

CI is the Same as the Nightly Build

Not true. A nightly build produces software artifacts for external consumption i.e., QA functional testing, product review, etc. XP took the notion of a nightly build and pushed it to an extreme by suggesting frequent intra-day code synchronization check points as a means for a developer to converse with the system to ensure that he/she has done his/her part, at least for the time being. It is not to say that there isn’t value in the nightly build, and in fact CI could be used to generate it in a staged manner.

We Are Not Agile, So We Don’t Do CI

While the term “Continuous Integration” was introduced by Extreme Programming (XP) the underlying concept of more frequent integration predates XP. In fact, CI is one of the least controversial of the practices espoused in XP and its guiding principles are relevant whether an organization has embraced agile or not.

Frequent Deployment Disruptive

Adoption of CI doesn’t necessarily mean an automatic deployment of each every “green” build to higher-level environments whether requested or not. A good CI implementation should provide the capability such that QA or other team members can deploy targeted builds on the CI server into other environments as needed.

In the Automation for the people series, Paul Duvall lists some common CI anti-patterns and misconceptions and how to avoid them.

Conclusion

The greatest benefit of CI is that of reduced risk. Too often the issues with delayed and infrequent integration manifest during the latter part of the project, when the stakes are high and pressure to deliver is greatest. Further, it paves the way for automation at many levels, starting with build automation, test automation and more recently continuous delivery/continuous deployment, all of which aim to foster the creation of higher quality software, faster.

References

Posted in Agile Adoption, Agile Benefits, Agile Development, Agile Management, Agile Methodologies, Agile Project Management, Continuous Delivery, Continuous Integration, Uncategorized | Leave a comment

How to Reduce Agile Risk with Monte Carlo Simulation

Man with dice

 

 

 

 

 

 

 

I love to gamble, but I prefer to gamble with dice, not software delivery.

Precisely predicting what can be completed in a release, and accurately accounting for risk, is one of the most important responsibilities of a program manager, IT leader, project manager or executive; yet the majority of our predictions have the same odds as winning the lottery.

Given those odds, can you improve the accuracy of predicting when software will be delivered?

Why Linear Forecasting Isn’t Optimal for Reducing Agile Risk

For decades the people managing software projects have attempted to predict software delivery dates with mixed results. In most cases, these predictions relied on linear forecasting techniques. While these can be useful, they fail to consider the risk associated with human involvement. Linear techniques assume a fixed future velocity based on an average historical velocity. As any investment broker or financial advisor will tell you “past results do not guarantee future performance.”

Consider a simple scenario where two teams both have an average velocity of 7.5. Using this average, either team could deliver the next 45 points in 6 iterations. However, suppose Team A’s historical velocities values were 10, 4, 5, and 11, and Team B’s historical velocities values were 7, 8, 8, and 7. The average is the same, but because the velocity values for Team A have a higher variance, there is greater risk when predicting future results. Furthermore, as stated above, the historical velocity values are not indicators of future performance. Either team could encounter a scenario that significantly improves or degrades velocity.

Another problem with linear forecasting is the fact that it yields a single date; nothing more. Yes, you can forecast a cone of uncertainty using the best and worst historical values, but in the end you only have dates; the best case date, the worst case date and the average date. There is no information to help you determine why any given date is better or worse than another.

Therefore, when asked to commit to a delivery date, you’re left with “trusting your gut” based on your knowledge of the team and other perceived trends. Unfortunately, many people would look at the upward trend of Team A and conclude “velocity is going up; that’s a good thing; they must be getting better.” The significant drop from 10 to 4 in the second iteration would be considered an anomaly “because the team was just getting started.” These factors result in a false confidence that leads to a more optimistic date commitment.

Given nothing more than a forecasted delivery date, and limited insight into the probability of hitting any date, you are left negotiating a contract, the delivery date, with limited information. Therefore, it is not a surprise that we consistently pick the wrong date and scramble at the end to “deliver something”.

There are better techniques for forecasting delivery dates that account for risk and give us the information necessary to effectively collaborate on a delivery date.

Reducing Agile Risk using a Monte Carlo Simulation

A Monte Carlo Simulation is a forecasting technique that can be used for predicting software delivery dates and accounting for risk. A Monte Carlo Simulation is “a problem solving technique used to approximate the probability of certain outcomes by running multiple trial runs, called simulations, using random variables.” The technique gets its name from the city of Monaco, a place renowned for its casinos long before the likes of Las Vegas or Atlantic City. Monte Carlo methods have been effectively used for years in the physics, engineering, financial application and even predicting election results. Douglas Hubbard, author of “How to Measure Anything”, states, “running Monte Carlo is the only way to analyze big uncertain decisions.“

A Monte Carlo Simulation considers the historical values of control variables, in our case velocity, as opposed to relying on a single value. It then simulates the completion of remaining work and produces a histogram showing the distribution of possible delivery dates. From those results, you can calculate various percentiles, or confidence levels, on each possible delivery date.

You’re probably thinking, “Whoa! That sounds really complicated!” Well, maybe if you were building the simulation yourself, but there are solutions that make it very simple. VersionOne is the first agile lifecycle management solution to offer predictive project modeling through Monte Carlo Simulation. The solution leverages quantitative information and risk factors to help forecast project completion dates at various confidence levels so that project managers understand when all of the planned work is most likely to be completed.

Sample Monte Carlo Simulation

Going back to the example presented earlier. When asked to determine when Feature X is going to be available, you can use a Monte Carlo Simulation to have an informed conversation about various dates and the confidence level of delivering on those dates. And now you are collaborating with the business on a delivery date rather than negotiating.

Even if you made customer commitments that Feature X will be included in a given release, you can use the Monte Carlo Simulation to determine, much earlier in the delivery cycle, the likelihood of the feature being delivered on time. By having this information earlier, you can make better business decisions, rather than waiting until the end of a delivery cycle.

Start Accurately Accounting for Agile Risk

In closing a word of caution: the Monte Carlo Simulation is not a panacea nor is it a crystal ball that lets you see into the future. Rather, the results of a Monte Carlo Simulation provide a more informed forecast that accounts for risk. And with the Monte Carlo Simulation capabilities in VersionOne, these simulations are faster and easier than you might imagine. In fact, it probably takes more time to deal with dissatisfied stakeholders after a missing a date because of a poor prediction.

I hope this article has inspired you to more precisely predict what can be completed in a release and more accurately account for risk using a Monte Carlo Simulation.

In addition to Monte Carlo Simulation, find out how VersionOne provides better insights for making better decisions.

 

Posted in Agile Adoption, Agile Benefits, Agile Development, Agile Management, Agile Metrics, Agile Project Management, Agile Software, Agile Tools, Enterprise Agile, Scaling Agile | Leave a comment

Is DevOps a People Problem AND a Technical Problem?

weinberg secrets of consultingOver the past few years, I’ve become more familiar with the works of Jerry Weinberg.  One of his best is a book called Secrets of Consulting, which I highly recommend to all those who give advice for a living.  Among the many rules and secrets that he shares, there are two that stand out time and again:

  1. There’s always a problem.  If they’re bringing a consultant in, there’s a problem to solve, even if they don’t really know what that problem is.
  2. It’s always a people problem.  Even in the most highly technical of scenarios, at the end of the day there’s a people issue at the root of it.

Now I don’t want to be one to quibble, but I believe that DevOps is that unusual scenario where getting good at it is both a technical and people problem.  Let’s take a look at what that really means.

nasa-control-roomThe Technical Problem

When we look at the practices that are so important for DevOps, we see a lot of technical solutions.  These practices enable DevOps to run smoothly and efficiently and make a huge difference in the success of an IT organization.  Many of them require a high level of technical sophistication as well as discipline, to achieve.

What are they?   Most of these practices are well understood as the foundation of DevOps. Items like Continuous integration have been around a very long time, and require a CI server as well as the concurrent automated Unit and Acceptance Tests to make Continuous Integration worthwhile.  This also requires a tight integration with the version control system, so that everything can be under version control.  All artifacts of delivery need versioning to truly be successful and, dare I say it, safe in a Continuous Delivery environment, which is of course the logical conclusion of a DevOps approach.

But wait, there’s more

So yes, there are technical practices that are required to truly “do” DevOps.  But in order to do those practices, we need people.  Bringing operations into the Team Room requires a new_shimmermindset and a willingness to change that can be very difficult to engender.  I’m not just referring to the difficult things like learning to automate and *choosing* to automate all Acceptance Tests, but also simple things like remembering to include monitoring items in all of your stories.

This is a big shift in thinking.  Development teams are used to finishing something, handing off to operations, and moving on to the next thing.  They don’t want to be bothered with something in production unless there is a bug, which they will often see as an inconvenience.  Building a culture that goes beyond deployment, but treats development and operations as a single, holistic entity takes a lot of support and willingness on the part of everyone.

Sometimes it’s just about language.  We need to start asking different, or more, questions during our analysis of stories.  Instead of asking if a particular test should be automated, familyTherapyask instead “how will we automate this one?” Including automated deployment and monitoring in our definition of done, or at least in the tasks we identify, will take us very far in the culture of DevOps.  This brings the whole cross-functional team into a world where the success or failure of a story doesn’t stop at the Sprint end.  Getting our team members to all take that to heart, and looking for the operational aspects of a story is hard, and requires patience and nurturing.  For that matter, so is getting the team into the mindset that automating tests is not optional, but required to ride this ride.   This also takes patience and nurturing.

Darn it, Jerry Weinberg is right again!  It really is a People Problem!

Posted in Agile Adoption, Agile Benefits, Agile Coaching, Agile Leadership, Agile Management, Agile Methodologies, Agile programming, Agile Software, Agile Teams, Agile Testing, Agile Tools, Continuous Integration, DevOps, Distributed Agile, Enterprise Agile, Extreme Programming, Software Craftsmanship, Test Driven Development, Uncategorized | Leave a comment

The Trojan Retrospective – From Crickets to Conversations

rear view

This blog is part of a series on “Agile Trojan Horses – Covert Appetizers for Agile Discovery.” This series is intended to help spark conversations that restore focus on agile fundamentals, whet the appetite to discover more about agile, and help apply agile in day-to-day decision-making.

One of the elements that I love about Agile and Scrum is the focus on humility, reflection and continuous inspection and adaptation. One of my favorite Agile Principles is #12…

At regular intervals,
the team reflects on how to become more effective,
then tunes and adjusts its behavior accordingly.

One of my favorite Scrum events is the retrospective. As the Scrum Guide says…
The sprint retrospective is an opportunity for the Scrum team to inspect itself and create a plan for improvements to be enacted during the next sprint…

…The purpose of the sprint retrospective is to:
– Inspect how the last sprint went with regards to people, relationships, rocess, and tools;
– Identify and order the major items that went well and potential improvements; and,
– Create a plan for implementing improvements to the way the Scrum team does its work.

Some common impediments prevent teams from applying the agile principle of regular reflection and from having effective Scrum tetrospectives.

LACK OF ATTENDANCE – Team members not showing up to the retrospective.

- LACK OF PARTICIPATION – Not hearing anything at the event besides the sound of crickets – team members showing up, but not sharing anything.

- LACK OF TRANSPARENCY & INSPECTION – Meaningless conversations – no transparency and no inspection. Nothing other than whining, finger-pointing and complaints.

LACK OF ADAPTATION – Meaningful conversations – healthy transparency and inspection but no meaningful adaptation. No follow-up actions to make things better.

Besides creating safety, one of the most important elements needed for a team to have meaningful inspection and adaptation is an ice-breaker. For many team members new to agile, the act of reflecting on the team in a safe setting, is awkward and unfamiliar.

I usually begin by putting up some flip charts with the questions…

1.    What worked well?
2.    What could have worked better?
3.    What actions will we take in the coming sprint to make it more effective?

I add a couple of additional questions…

4.    What was the most valuable knowledge we gained in this sprint?
5.    What contributions would we like to acknowledge in this sprint?

In most cases, with a few nudges here or there, the team starts opening up and we have a meaningful conversation. However if the team is still not talking, you could try this approach…

In this approach, we put up a bunch of assertions in front of the team and ask them to share their responses to the statement. These approaches fall into five major categories that also help raise the team’s awareness of key elements relevant to agility…
ResponseCategories

 

 

 

 

 

For each assertion, ask the team to respond by choosing one of four categories…

HUH…? - We are unaware of or unclear about what this means.
HEALTHY – Our team is healthy in this area. No adaptation needed.
NEEDS SOME ADAPTATION – Our team could use some adaptation here.
BLOCKED! NEEDS URGENT ADAPTATION- Our team needs urgent adaptation here.

If the team is co-located, you could create a grid on flip charts and the team could put up colored posts.

Encourage each team member to also jot down why they chose a particular post-it, maybe with an example, if they can. If not, it is completely OK, they can just put up a blank post-it.

If the team has specific ideas on how they might adapt the next sprint to be more effective, they can jot them down on a post-it and put it up in the last column.

The grid might look something like this…ResponseOptions
If the team is distributed, you could send them an online survey and have them respond either before the retrospective event or during the initial portion of the event.

Either way, once the team has finished responding, you can sum-up the responses in a table like this…ResponseScores

You might try jotting down your responses as you read this blog as well, before you take this idea to the team. Now that we have set the stage, let’s start reviewing the assertions…

SECTION A – AGILE MANIFESTO

We begin with a section adapted from the Agile Manifesto. Reflect on how aware your team is about the Manifesto and how effective you all feel you were in applying it to your work. time-box this section, and review feedback as a group.Manifesto

SECTION B – AGILE PRINCIPLES

The next section encourages reflection on the Agile Principles. Ask the team to consider each principle and share their thoughts on how effectively you all applied them. Discuss as a group.Principles 1-6

Principles 7-12
SECTION C – SCRUM OBJECTIVES

Let’s start reflecting on one of the frameworks under the agile umbrella – Scrum. At a high level, the Scrum framework has three core objectives. As a team, reflect on whether the processes you used helped accomplish these objectives.
ScrumObjectives

SECTION D – SCRUM VALUES

Scrum is not just about rituals or “what” we do as a team. The heart of scrum are the core Scrum Values that define “how” we work together as a team. Pull up the Five Scrum Values and allow the team to share their thoughts on the team culture and how close it was to being true to the Scrum Values. Discuss as a group.
ScrumValues


SECTION E.1 – SCRUM GUIDE: SCRUM THEORY

As described in the Scrum Guide, Scrum is based on the three pillars of empirical process control. Ask the team to share their thoughts on how effectively the team applied empiricism in their work. Discuss as a group.
ScrumGuide-1

SECTION E.2 – SCRUM GUIDE: SCRUM TEAM

The Scrum Guide clearly lays out the accountability for each role in the framework. Ask the team to reflect on how effectively each role or group delivered their accountability. Discuss as a group…ScrumGuide-2

SECTION E.3 – SCRUM GUIDE: SCRUM EVENTS

The Scrum Guide clearly lays out the purpose and desired outcomes for each of the five events in the framework. Ask the team to reflect on how effective they thought each event was. Discuss as a group…ScrumGuide-3

SECTION E.4 – SCRUM GUIDE: SCRUM ARTIFACTS

The Scrum Guide clearly lays out the purpose of each of the three artifacts. Ask the team to reflect on how closely each artifact accomplished the purpose defined in the Guide. Discuss as a group…
ScrumGuide-4

SECTION E.5 – SCRUM GUIDE: TRANSPARENCY

Scrum can only be as effective as the level of transparency in the organization. Reflect as a team on how transparent you feel the organization is. Discuss as a group…
ScrumGuide-5

SECTION F – LEAN SOFTWARE PRINCIPLES
(MARY & TOM POPPENDIECK)

Mary and Tom Poppendiek have done some amazing work how the lean principles from manufacturing offer a better approach to software development. These principles are available on their website – http://www.poppendieck.com/ and I have taken the liberty to adapt them for our approach.
Lean-1

Lean-2

Lean-3

Reflect as a team on how effective you were in applying the lean mindset and discuss as a group.
Lean-4

By now, hopefully, the silence and crickets at the beginning of the retrospective have been replaced by meaningful conversations about how the team can inspect and adapt its work.

Hopefully, these conversations have dispelled some common myths about what agile is and is not and acted as an appetizer for the team to explore some more about agile software delivery.

When you sum up the responses, the graph might look something like this…
SampleGraph

Before you end the session, ask the team to pair up and pick up at least one action item to make a thin slice or process improvement in the next sprint. Without adaptation, the transparency and inspection of a retrospective are meaningless. If there are too many options to choose from, use dot-voting to help rank the options and pick the ones that fit the capacity constraints of the team.

Try out this approach even if you begin with baby steps by reflecting as an individual.
Either way, please share your thoughts. If you like, you can use this Excel spreadsheet as a starting point.

Either way, please share your thoughts. Keep calm, and Scrum on!

Posted in Agile Adoption, Agile Benefits, Agile Development, Agile Methodologies, Agile Teams, Agile Training, Scrum Development, Scrum Methodology, Scrum Software, Scrum Tools, Uncategorized | Leave a comment

Psssst! I Can Get You Fixed Cost AND Fixed Dates!!

130614-110928-2486x1687

I have an offer you can’t refuse…

You don’t have to be afraid, just because I am Sicilian.

I am talking about Product Development here, not “garbage collection”.

I know it frustrates you that all this Agile stuff talks about uncertainty and fluffy stuff. I have a secret for you, however. It’s one of the most overlooked aspects of Agile. I will even let you in on this secret for absolutely FREE.

Here it goes…

In Scrum, there are fixed timeboxes or iterations we call Sprints. You probably knew that. However, what you probably didn’t realize is that if your Scrum Teams establish fanatical discipline and rigor around only releasing things that are in line with their strong and comprehensive Definition of Done every Sprint, you will have…

FIXED DELIVERY DATES!!!

What will undermine this is if they compromise on the various criteria in the DoD, effectively cutting corners and introducing risk into the product. Also, if they extend the Sprints, change the duration repeatedly, or have nonsensical practices like magical mystery Sprints where hardening, innovation, and planning suddenly take place then all bets are off in terms of having…

FIXED DELIVERY DATES!!!

So, let the Scrum Teams be responsible and empowered to make the critical decisions that no one else can truly and effectively make. They will make the product sound in accordance with changing customer needs and technological advancements by baking quality in, integrating along the way, practicing emergent design, improving by coming up with new ideas, and doing smaller increments of ongoing planning, as Scrum intended. The result will be…

FIXED DELIVERY DATES!!!

Now, we all know that a Development Team in Scrum is supposed to be 5-9 (7±2) people, right? If we use a blended rate of, say, $100k to represent the average salary for team members (including consultants), then we know for certain that a Development Team will cost $500-900k / year. Voila! We have…

FIXED COSTS!!

Now, we can figure out what a Sprint costs by doing simple division. Let’s say a Sprint is two weeks. That gives us ~$19,000-$35,000 / Sprint depending on the Development Team size. Further, let’s assume our releases are every 3 Sprints (6 weeks). Now we know that a release costs us ~$57,000-105,000. That’s a beautiful thing. That’s…

FIXED COSTS!!!

You can’t ask for more!!

No, I mean literally, you can NOT ask for more; like Fixed Scope, for instance. In order to get fixed costs and fixed delivery dates in Scrum, the trade-off here is that the Scope is flexible. This is good, don’t freak out.

Having flexible scope ensures that we are able to roll with the punches and change as customer needs change, technology changes, and most importantly, business priorities change. To help us with this, we want the Sprints to be as short as possible. If we have one week Sprints, then we can formulate smaller increments in planning and ultimately have very granular refinements in our strategy rather than very drastic course corrections which are costly.

We still have higher level elements of planning that map to overall strategy: Vision, Roadmap, Release level planning, and insisting upon a Sprint Goal for every Sprint. This helps to keep us on target and focused with our longer term strategy.

So, not having fixed scope is a good thing. We could still have releases that are structured around fixed scope instead of fixed delivery dates. But it’s simply not realistic or REAL WORLD to expect to have more than one element fixed, one element firm, and one element flexible from among Scope, Cost, and Time. Those who demand to have all three fixed (so-called “firm fixed price”) are best served in taking this up by seeking an audience with OZ in the Emerald City, since they are indeed in fantasy land…

So, there it is:
FIXED DELIVERY DATES and FIXED COSTS

Happy weekend!

Peace and blessings-

Daniel

Posted in Agile Adoption, Agile Benefits, Agile Development, Agile Methodologies, Agile Teams, Agile Training | 3 Comments