LitheSpeed

Three Keys to Successful Product Ownership

2012-01-25T15:50:00.002-05:00

The Product Owner is both one of the most important roles in Scrum and often the most difficult to fill. In this post, I will explore a few aspects of successful product ownership that are often done poorly or not at all.

Manage Both the Big Vision and the Small Batches

Keeping a balance between the development of product qualities that will fulfill the business case and the tactical execution of low-level features is perhaps the most important skill possessed by a Product Owner. The difficulty in simultaneously doing both of these things well often leads to an actual split in the role, where a “Strategic” or “Chief” Product Owner focuses on the big picture, and the “Tactical” or “Proxy” Product Owner works with individual teams attending to the details of execution. Tools like story mapping, product trees and personas are commonly applied at the big picture level by Strategic POs, while sketches, wireframes, process flows and various collaborative modeling techniques are generally employed by Tactical POs to help teams better understand and execute the details.

Strategic product ownership is focused on garnering feedback and testing the project's assumptions at the vision and business case level, while tactical product ownership should align the whole team against small batches of work within sprints to ensure the best execution possible at the detailed level.

Test the Project’s Assumptions

Business cases are often presented as foregone conclusions: Build the features, and they will come. However, there is no shortage of failed and unloved products to prove that this is nonsense. Projects are built upon more or less educated guesses of what the market and stakeholders need and desire, and it is the Product Owner’s job to test and refine these assumptions, thereby guiding change through objective data.

Techniques such as customer development in the "Lean Startup" approach focus on stating your assumptions in such a way that they can be tested, and then using feedback from these tests to adjust the project’s focus. The simple process of coming up with metrics that represent the product’s desired qualities and impact areas also can be of tremendous help when attempting to balance diverse needs across disharmonious stakeholders, as it forces a focus on overall project needs rather than individual features. In essence, the why must precede the how.

Use the Whole Team

When Scrum was first formulated, a joke cast the “team” as committed “pigs” while the Product Owner (along with general stakeholders) was dubbed a merely involved “chicken.” This is an unfortunate place to draw the line, because these two roles work best as a tight-knit partnership. Scrum teams already play an active role in design and feature elaboration, and the best products come from fully engaged teams, not ones that simply wait for their orders or ones design in a vacuum.

Collaborative modeling techniques, where designs are created and refined by small groups rather than individuals, are common in such environments. Finding the right balance between giving the team a “final, approved” design to develop vs. involving them deeply in the design process itself isn’t automatic or consistent across teams, but it is the only way to maximize both the efficiencies so often touted in Agile methods with product innovation, effectiveness and quality.

I hope you've found this post useful. If you have any other questions about how to be an effective Scrum Product Owner, share them in the comments and I'll do my best to answer all of them in future posts.

What will it take to transform management? Look to the Polio Eradication Model.

2012-01-02T01:47:00.010-05:00

In a few days, I'll be leaving behind the balmy weather in Chennai and heading to #Stoos in Switzerland. Our Stoos Gathering attendees will be deliberating on the issue of accelerating the transformation of management. We'll likely be asking questions like, "How can we accelerate the transformation of management away from creaky, dysfunctional models of the past and towards modern, dynamic in the present?"

Or "How can we catalyze widespread change in management to better meet the challenges of our turbulent times?"

Some days ago, I blogged about some of the models under consideration, and indicated that all of the approaches are essentially humanistic and systemic. So, whether we consider slightly older models like Jim Highsmith's Agile Project Management model or the Declaration of Inter-dependence; or more recent ones like Jurgen Appelo's Management 3.0 and Steve Denning's Radical Management, I believe the required transformation from current management state to future state is less about the mechanics, and more about the fundamentals.

How can we transform from older industrial-style management with its mechanistic command-and-control to newer "light-touch" humanistic management with decentralized or distributed control? In the agile world, we have certainly seen many companies initiate and sustain agile management and agile development transformations. The Forrester Group reports more and more organizations have initiated agile transformations world-wide. In my last blog post, I referred to this as creating a playground of productivity. In response, @stevedenning points out that the bigger question is, "How can we sustain the transformation?" I've spent the last few days in preparation for #Stoos: reviewing available models, reviewing the comments surrounding the Stoos gathering and perhaps most important, doing some personal reflection and retrospection on that very question.

While mulling the question, and perhaps enabled by my current surroundings, I recalled a very successful worldwide movement: the Polio Global Eradication Initiative. I first learned about this initiative when, on a flight to India some months ago, I sat next to a gentleman from Boston who was leading a U.S based team of volunteers from Rotary International. The goal of the initiative is to completely eradicate this often fatal and always debilitating disease from the earth.

Rotary International is one of the four spearheading partners in the initiative, and it is heart-warming to see volunteers from all over the world fund their own way, and team with local organizations and volunteers to help vaccinate children in the remaining hotspots.

The key partners: the World Health Organization (WHO), Rotary International, the US Center for Disease Control and Prevention (CDC), and the United Nations Children's Fund (UNICEF) have mobilized thousands of volunteers, and managed and coordinated and managed their efforts in alignment with clear strategy with four pillars:

Routine immunization
Supplementary immunization
Surveillance
Targeted "mop-up" campaigns

The results are impressive. Per UNICEF, over the past 20 years, there has been a 99% reduction in polio cases.

I think we have a lot to learn from this model that brings public and private organizations; and governments and individuals together to work towards a common goal.

My thoughts on using the polio eradication initiative as a model for a global movement to transform management coming up in the next blog post.

Large-Scale Management Transformation: How Can We Create a "Playground of Productivity?"

2011-12-22T08:05:00.007-05:00

Something that has come up in discussions around the Stoos Gathering is the pivotal question, how does one create and sustain large-scale management transformation? The #Stoos participants have been engaging in lively discussions, and I thought it would be good to mull the topic as well.

So, I began looking back at some of the most successful transformations I've witnessed, two key factors emerged: a true business need and a willingness to experiment. From our archives, I found this post with my answers to 5Qs on Agile. Don't miss Bud Phillips' amazingly prescient conversation with our own Bob Payne on sparking and sustaining management change. I really like Bud's rhetorical question, how can we create a "playground of productivity?"

Want to Transform Management? Help Me Prepare for the #Stoos Gathering

2011-12-22T02:42:00.017-05:00

On January 6-7, 2012, I will be in Stoos, Switzerland as part of a gathering of management enthusiasts. Organized by the core team of Jurgen Appelo, Steve Denning, Peter Stevens and Franz Roosli, we have a lofty goal: we are seeking to accelerate the transformation of management. As Steve Denning and Jurgen Appelo posit, the pace of change in the world of management has been – glacial. So now, there is much interest in catalyzing that process to accelerate change in this area.

In preparation for the gathering, Jurgen has prepared a short list of models, and others are adding their thoughts. Before we can begin looking forward, I want look back in Agile tradition to make sure we are taking the past into due consideration, and that we can build on and synthesize different models.

In my own book, Managing Agile Projects, I shared my three guiding management principles for agile teams and projects:

Foster alignment and cooperation
Encourage emergence and self-organization
Institute learning and adaptation

Most everyone familiar with agile methods is likely able to trace things back to the seminal Manifesto for Agile Software Development. However, lesser known, but perhaps a "nearer neighbor" to the world of management is the Declaration of Inter-Dependence. In 2005, several of us within the agile movement were convened by visionary leader Jim Highsmith and hosted by David Anderson in Redmond, WA and emerged from that gathering with these six management guidelines that constitute the DOI:

We increase return on investment by making continuous flow of value our focus.
We deliver reliable results by engaging customers in frequent interactions and shared ownership
We expect uncertainty and manage for it through iterations, anticipation and adaptation.
We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.
We boost performance through group accountability for results and shared responsibility for team effectiveness.
We improve effectiveness and reliability through situationally specific strategies, processes and practices.

©2005 David Anderson, Sanjiv Augustine, Christopher Avery, Alistair Cockburn, Mike Cohn, Doug DeCarlo, Donna Fitzgerald, Jim Highsmith, Ole Jepsen, Lowell Lindstrom, Todd Little, Kent MacDonald, Polyanna Pixton, Preston Smith and Robert Wysocki

Alistair Cockburn's later commentary and explanation capture the thoughts of that group best, in my opinion. The DOI has certainly been my touch stone as I've applied Lean Thinking along with agile values and practices since then. I've found it especially useful when applying agile methods at the enterprise level, because of its lean-infused thinking and language. For example, phrases like flow of value, situation-specific strategies, and environment to make a difference help ensure that we simultaneously take both a humanistic and systemic approach to management.

That humanistic and systemic approach underlies the approaches postulated by both W. Edwards Deming and Peter Drucker, upon which we have built the foundations of modern agile management. Tellingly, at the core of Lean Thinking are these two fundamental principles: respect for people (humanistic) and continuous improvement (systemic).

Even if these principles are not yet manifested in a widespread fashion globally, there are certainly brilliant pockets of adoption world-wide. In North America and Europe, I've witnessed the power of agile methods to drive tremendous results, including some monumental agile adoptions. I'm now on vacation in India, and one model that has caught my interest here is the one practiced by Vineet Nayar at HCL Technologies, "Employees First, Customer Second." Definitely sounds like a humanistic and systemic model, doesn't it?

Finally, over the past year, since I was introduced to the concept by Jeff Sutherland, I've been captivated by the notion of wise leadership, as proposed by Takeuchi and Nonaka. Takeuchi and Nonaka recommend the quality of phronesis as the quintessential quality of wise leaders, and pinpoint these six abilities of a wise leader:

Wise leaders can judge goodness
Wise leaders can grasp the essence
Wise leaders create shared contexts
Wise leaders communicate the essence
Wise leaders exercise political power
Wise leaders foster practical wisdom in others

Earlier this month, as 2011 drew to a close, I was privileged to attend a remarkable event in Milan, Italy hosted by the PMI's Northern Italy Chapter (PMI NIC). Organized by Tiziano Villa and Walter Ginevri from PMI NIC and bringing in Victor Carter-Bey and others from the PMI Global, Tiziano later remarked that we were able to create a "ba," or place where relationships are forged and interactions occur as participants try to create new meaning.

As we usher in the New Year, I am now looking forward with eager anticipation to the trip to Stoos, and I'm hoping we can create a similar "ba" that helps accelerate the pace of management warming.

To reiterate the #Stoos gathering organizers' call to help transform management, please help us by sharing your thoughts in less than 100 words, either via the comments box below or by email at sanjiv DOT augustine AT LitheSpeed DOT com.

Thank you, and Happy New Year!

Collaboration in Agile Development: Should Agile Teams Work in a Bubble?

2011-12-08T08:48:00.000-05:00

When a developer posed a question to his Twitter followers a couple of weeks ago about collaboration between agile teams and the business side of the organization, a coworker passed the question my way. Despite the fact that I wasn't able to respond on Twitter right then (ah, travel), the question came at a great time. I had just finished an agile assessment for a client, and left with a fresh perspective on the topic of collaboration and agile team management in general.

The specific question was, "Is it healthy for Scrum teams to work in a bubble protected from the business around them? Should collaboration go beyond the team?"

There are two common threads that I see time and time again: What is the goal, and how is that goal communicated? Until these two threads are tied together, true collaboration won't happen. I don't see this as being unique to the world of Scrum. To help illustrate my point, I'll try to use terms from outside of the Scrum community.

Strategic Mission (Goals)

Executive leadership, in order to truly lead, must communicate the strategic vision of the organization. A strategic vision translates into a strategic mission or long-term goals. A strategic mission should be understood by the entire organization. If a team member doesn't know the mission, how will she be able to help the organization reach its goals? From there, the leadership needs to empower the people tasked to do the work to figure out how they will accomplish the goals.

Tactical Mission (Goals)

This is where you keep lines of communication open but insert a protective buffer. If you're leveraging Scrum, the Product Owner serves as the first buffer. The Product Owner (agile product manager) understands the strategic mission of the organization and translates it into a tactical mission. You could also refer to this person as an organizational liaison: someone who doesn't need to know all of the answers, but does need to be readily available to answer questions from the team and reach out to the appropriate subject matter expert(s) when necessary. The second buffer is the ScrumMaster (if leveraging Scrum) or could be referred to as a process manager. This person understands organizational process on a team level and is there to ensure the team consistently follows that process. Process managers such as ScrumMasters also work to keep those who do not aid in tactical execution from derailing the team from getting work done.

Collaborative Team

Okay, so now it's time for me to answer the first direct question about collaboration: "Is it healthy for Scrum teams to work in a bubble protected from the business around them?" Though I do believe the team should be protected from the people trying to change their tactical priorities, an agile team should never operate in a vacuum. If people from within the organization do try to change team short-term priorities, the process manager (ScrumMaster) should be right there to impress upon them the need to respect the agreed upon processes.

Collaborative Organization

The second question was, "Should collaboration go beyond the team?" My short answer is "yes," with the understanding that collaboration is different than communication, which needs to flow up and down the organization. Collaboration by definition points to working together, whereas communication can be limited to unidirectional imparting or transmitting. Effective agile product development and project management requires bi-directional communications (the flow of information back and forth).

Once the appropriate information is presented to the appropriate people, real collaboration can take place. The entire organization, which includes all cost and profit centers, needs to collaborate to discover the best solutions and work toward common goals.

Be the Minority: Increase Engagement and Have Fun Doing It

2011-11-15T15:37:00.002-05:00

“Seventy-one percent of American workers are ‘not engaged’ or ‘actively disengaged’ in their work,” according to a recent Gallup poll. This is certainly a dismal message for those interested in an Agile revolution, since the heart of agility is based around intelligent adaptation, and those who don’t care are unlikely to expend energy adapting.

Methods like Scrum and Kanban focus on creating environments where team members can get into flow, but they by no means assure that workers will be imbued with the drive necessary to be truly outstanding. Much of the coaching work we’ve done over the years at LitheSpeed has shown that simply getting people interested in improving can be quite the challenge.

While there are no pat solutions for this complex issue, we’ve been working hard to discern effective approaches. From fun exercises that engage the mind in learning to facilitation tricks that make work seem a bit more like play to team building exercises that leverage emotional connections, the “engagement tools” in coaches’ toolboxes are often even more useful than the process and technical expertise that are so often focal points.

One somewhat unusual tack that we’ve lately adopted is approaching things from the tooling angle; while this might seem strange as a solution to something so arcane as engagement, it turns out that many people turn to pursuits like games for this very reason. The fields of game design, psychology and marketing offer myriad insights into ways to excite people, and it is to these that we’ve turned in the development of Sensei, our first tool. In a nutshell, it focuses on continuous improvement, sidestepping the usual focus on backlogs and burndowns and attacking the problem of focusing, tracking and visualizing individual, team and organizational improvement activities.

Velocity, the most commonly touted metric used to measure agility, is unfortunately a poor indicator for engagement and team satisfaction, product quality, customer satisfaction, and even process quality. What Sensei does is gather observations about these elements, and show where they’re improving.

Our initial incarnation, focused on running retrospectives for local and remote teams, should be out within a month or so, and you can then see what the fuss is about. Until then, sign up to be notified of our first release, and let us know what you’d like to see in a continuous improvement tool, or ways you’ve found to drive engagement in your own teams.

Thanks for Agile DC: A Mountaintop Experience

2011-11-12T22:00:00.000-05:00

After Agile DC 2011 ended, we quickly turned our attention to the Agile Development Practices East conference in Orlando, where we launched a skeleton of our new product, Sensei.

But before the moment passes into history, I'd like to share a few reflections with our community. For me, Agile DC turned out to be what is termed in some religious circles as a mountaintop experience. I'd put some very special effort into the keynote talk, and it all seemed to come together effortlessly in the end. It was definitely Csikszentmihalyi's flow at work. (For those who weren't there, you can learn more by downloading my presentation here.) But the real strength of the experience lay in being able to connect with so many from the agile community here and leave with a deep sense of appreciation and gratitude.

In that compressed period of time, so many folks were part of the experience, that the names are almost too many to list:

The organizers and volunteers, lead by George Dinwiddie, Manoj Vadakkan, Jolly Rajan and our very own Bob Payne;
The generous sponsors, including our partners VersionOne and LeanKit Kanban;
The amazing speakers including Ken Schwaber, Jon Terry, Siraj Sirajuddin, David Bland, Sudhir Frederick and Montra Ellis, Paul Boos, Ahmed Sidky, Jay Flowers, Peter Saddington and our own David Bulkin and Derek Huether;
The fantastic Twitter conversation on #agiledc, with my new friends @Sprezzatura, @donmullens, @livlab and @daverooneyca;
Our old friend and colleague Roland Cuellar who happened to be at the conference; and
Our faithful LitheSpeed team, including Karen Falk, Colin Agnew, CJ Huether and Lindsay Hicks who got a thousand things together to set up our table and man it for the duration of the conference.

The special sense of auspiciousness was captured by a lady who won both an iPad 2 and a book in the raffle. She said, and though I paraphrase from a leaky memory, it truly captured the moment for me, "It's diwali, and today is certainly my lucky day."

In parting, all of us here at LitheSpeed would like to leave you with a big thank you for Agile DC, and share some gifts of our own with you. You can download all the presentations below here.

Derek Huether's, When PMI Introduced the Elephant in the Room
David Bulkin's, Agile Teams - From Good to Great
Sanjiv Augustine's, The Promise of Agile Methods

If you're interested in hearing more about our new PMI Agile Certified Professional (ACP) class, check it out here. Also, if you're interested in learning more about our new continuous improvement tool, Sensei, check it out here: http://www.senseitool.com.

Happy weekend to everyone!

My PMI-ACP Exam Experience

2011-11-09T09:05:00.008-05:00

Because I wanted to ensure people taking my class were learning things that are actually on the PMI-ACP exam, I thought it necessary to actually take the test. Sure, I was an independent reviewer of the PMI-ACP content but I was not part of the team who wrote the exam. Let me just say, I think those who wrote the exam did us all proud. I know it sounds sick but I really enjoyed taking this exam. It wasn't too hard or easy. For a v1.0 exam, it's pretty darn good. If you've been leveraging Agile for several years, I think you could pass it (in its current form). Let me caveat that by saying you'd have to be properly leveraging Lean, XP, and Scrum for several years. In all seriousness, there are people who still think cowboy coding or having no formal process or documentation makes them "agile". This exam pays its respects to the values and principles of agile practices and to those who wrote the Agile Manifesto just 10 years ago.

Now, considering every exam will be different, you can't take my testing experience as gospel to prepare. But, you can focus your attention in certain areas. I'm pretty certain I won't upset anyone with this blog post. I'm not exposing any super-secret strategy to game the exam. I remember taking the PMP and getting frustrated because I felt like their goal was to trick me, not test me. Thankfully, the PMI-ACP is not crafted like the PMP. It's written in a tone an everyday Agilist will understand.

Here is my bullet list for public consumption. The rest I will reserve for my PMI-ACP classes. (shameless plug)

Know the Agile Manifesto Values and Principles. Understand them. Don't just memorize them.

Have an end-to-end understanding of Scrum.

Know and understand the key roles of Scrum.

Know and understand the artifacts of Scrum.

Understand what are and why we use big visible charts or information radiators.

Be able to read a burndown chart and offer a few scenarios that would explain its appearance.

Understand all of the Scrum meetings. Who is there? Why? What happens and when?

Understand Scrum from a ScrumMaster perspective.

Understand Scrum from a Product Owner perspective.

Understand Scrum from an empowered Team perspective.

Know and understand the XP (eXtreme Programming) roles and who does what.

Understand Test Driven Development. Know how it works and why it's valuable.

Understand Continuous Integration. Know how it works and why it's valuable.

Understand the Lean Software Development Principles

Know what Lean Portfolio Management is and how your organization could benefit from it.

Understand what Value Stream Mapping is and how to do it

Understand the basics of Kanban

Understand what WIP is and why it works.

Know what Osmotic Communications is.

Understand what makes a Servant-Leader and what they do.

Understand Velocity and it's usefulness.

Understand Risk Burn Down Charts

Know about Risk Audit Meetings

Know Agile Estimation techniques

Understand the Definition of "Done"

Know how to write and identify good User Stories.

Know what Personas are and how to use them.

Understand why and when you would use AgileEVM (don't worry about how!)

Remember, you have 3 hours to answer 120 questions.

Good luck!

PMI-ACP Learning is Fun

2011-10-21T23:44:00.004-04:00

This week I debuted my PMI-ACP class to the Washington DC/Baltimore area. Because this was my first time offering the class, I had a little trepidation. Would my students take to my teaching methods?

As I walked into the training center, I passed another classroom. It was a five-day PMP exam boot camp. Knowing how these types of classes are presented, I knew I didn't want the same for my class.

I want to do more than teach people how to pass a test. I want them to walk away with an understanding of concepts like self-organization, adaptive planning, continuous improvement, and value delivery. For this first class, I planned to spend a lot less time lecturing and a lot more time engaging my students with discussions, simulations, and games.

Over the course of the next three days, we held lengthy discussions on real-world topics. I would introduce a concept and ask questions like, "Now that I've talked about Concept A, how can you apply it at your organization?" The class would then compare and contrast different scenarios from each of their perspectives. But, I have to admit, some of the best moments of the class came when we played games. Activities ranged from building paper airplanes, to playing the "ball point" game and building a town out of Legos. I can't express the satisfaction I felt while witnessing each student's "lightbulb" moment.

One of the attendees just wrote me an email, saying,

The class was excellent! This has been the most valuable class I have had relative to understanding Agile and applying it to my organization.

We had six early-adopters at the first class, all of whom offered up some excellent feedback. I know the next class will be even better. Anyone have some Legos for sale?

5 Steps to Make Your Project Portfolio Flow

2011-10-21T18:50:00.010-04:00

In most organizations adopting Agile methods, the techniques used for program and portfolio management are still predictive and "waterfall": yearly budgeting cycles, capacity planning, and heavily matrixed resource management. It’s no surprise then that despite adopting Agile methods for their projects, many organizations have yet to exploit their full benefits at the portfolio level.

Put another way, Agile projects are constrained because their portfolios are clogged with the debris of failing projects, with slow moving projects that delay more critical initiatives, and with the inability to properly staff projects to get them moving at a rate that their business customers would appreciate. How can the project portfolio be fixed so that business value can flow and projects can be completed faster?

Program and portfolio managers have the charter to apply systematic management techniques to collections of projects and deliver business value in line with organizational strategy. In my previous posts on the subject, I laid out principles and practices for a Lean-Agile PMO that use lean principles to accelerate Agile project delivery.

To help you get started, here are 5 steps that you can use to make your project portfolio flow:

1. Terminate Sick Projects. In every organization, there are sick projects. These are projects that fail to deliver value: missing deadlines, not meeting business expectations, and undergoing long and painful “illnesses.” It is reasonable to assume that the majority of investment sunk into sick projects ends up wasted—returning very little value to the business. Consider the time spent by team members on those projects. If the portfolio was purged before these projects, and the project inventory thereby reduced, the team members' effort could be redirected to more productive projects that in turn would finish faster. To begin clearing the debris in your portfolio, don’t avoid the challenge—terminate sick projects as soon as you can.

2. Break Large Projects in Smaller Projects/Increments. In Agile parlance, a minimum marketable feature (MMF) represents a component of intrinsic marketable value. By categorizing and aggregating product features into MMFs, you can recognize and exploit the fact that sets of product features can have value to end users, even if the product is incomplete. Instead of carrying massive project inventory to deliver product functionality in one big bang, deliver products in increments of MMFs and improve lead time as a direct result. To reduce the undesirable large Work in Process (WIP) created by large projects, break them into smaller projects (or at least deliver smaller product increments) organized around MMFs.

3. Manage the On-Ramp. Is your organization is starting more projects than it's completing? This might a sign of improper project kickoff discipline that could lead to future project delays. Obviously, not all projects are alike and it is possible to end one large project and correspondingly start up several new smaller ones in its place, but this metric can still serve as a potential warning device and leading indicator of delays to come. To manage the project “on-ramp,” create a lightweight but disciplined project prioritization process to kickoff projects, and follow it stringently.

4. Create Stable Teams. To maximize project throughput, an organization should only start as many projects as available teams. Instead of sinking costs into forming teams for projects only to break them up on completion, smart organizations create stable teams as high-performance units focused on one project at a time. Each team is as fully cross-functional as practical, containing business analysts, development leads/designers, developers, testers, and perhaps a tools support person. An organization may also have separate dedicated support teams. You can then pull projects from a prioritized project backlog of selected projects and allocated to the appropriate team. The team focuses on this project alone to the extent possible and in working closely with the business sponsor, should be able to finish it way faster than in traditional environments. When the team completes the project, puts the system into production, and hands the maintenance over to the maintenance team, the team will then be available to start the next project. Create stable teams by dedicating core team members at least 80% to the project at hand.

5. Track and Control the Flow of In-Flight Projects. Projects are typically measured along the triple constraints: scope, schedule and resources. Using these as sole measures of progress is problematic: Because scope is often variable, schedules are usually assessed through unreliable artifact-based milestones.

The flow of business value in your project portfolio from Initiation, where ideas originate, through Deployment, when value is realized, should be smooth and steady. Variability – so desirable in Agile product exploration – is not a good thing in the project portfolio.

Defining metrics based upon the value propositions of product MMFs can provide much better indicators of progress. Rather than focusing on project constraints, milestones can measure the realization of product goals. When projects fail to live up to their business cases, as assessed by frequent and thorough evaluations (preferably with real target users), they can be retargeted or cleared from the portfolio. Institute a portfolio prioritization and control process that is based on the delivery of business value, and use it to relentlessly reevaluate projects in-flight and keep WIP in the form of in-flight projects to a minimum.

Get your portfolio flowing, and get started on the journey to low variability, high throughput and high value by applying the five steps above.

When PMI Introduced the Elephant - Part 1

2011-10-19T00:04:00.002-04:00

Last October I entered the Gaylord National with a little trepidation. The PMI North American Congress was taking place and I found out that several people I admire in the Agile space were going to be attending and speaking. Leading up to the major PMI event, I was hearing a lot of chatter about these "heretics" who were going to be presenting. In Washington DC, the PMP was king and few in the Federal space wanted to hear anything about adaptive planning, continuous elaboration, or focusing on delivering value to the customer. Project Managers were expected to predict the future, define process and then make damn sure you followed it, regardless if anything ever got delivered. So, I was very much surprised as I walked through the Gaylord and noticed poster after poster, display after display. "Are you Agile?"

Every Agile session I attended, PMI Vice President of Information Technology, Frank Schettini introduced the speaker and told the audience that he leads the team that is responsible for delivering value to PMI’s members, volunteer leaders, certification holders and staff through innovative and reliable technology solutions. He said that he was a strong supporter of the Agile Community and so was PMI.

Though the audience at one of the first Agile sessions was almost hostile towards the presenters, by the time Michele Sliger gave the final session on the final day, there was buzz in the halls of the Gaylord about how "this Agile thing" had taken the conference by storm.

While I was there at the conference, I was privately asked if I would be willing to assist PMI with the creation of an Agile certification. I was very apprehensive, at first. I didn’t want PMI "hijacking" Agile. I was assured that was not the case. I discovered those I respected most in the industry were already hard at work, making sure it was done right.

Agile was about to cross the chasm and PMI was going to make sure we made it to the other side.

But first, introductions were in order.

Four Steps to More Effective Agile Retrospectives

2011-10-17T14:33:00.001-04:00

It’s no secret among agile practitioners that retrospectives, as commonly practiced, tend to suffer from a fatal flaw: inaction. Teams discuss all that irritates, perhaps cheer each other on a bit, and then leave the retrospective with faint hopes that things will improve, eventually losing faith in the activity due to its obvious ineffectuality.

The simple solution is to choose a single high-value issue each sprint, and allocate the time necessary to solve it. Some practical ways to make this happen are:

1. Set expectations properly: Ensure that your stakeholders expect a bit of effort toward process improvement and understand the value this brings, both generally and in each case.

2. Keep things small: Improvement actions should go in your backlog. As with other item, they work best when they're able to be complete in about one to three days. If the action is too big or too broad, break it down into smaller, more manageable items.

3. Gather observations continuously: Much time in retrospectives can be spent just raising issues, which reduces the time available to craft and refine solutions. Keep an ongoing backlog of observations (and any suggested actions) that team members contribute to in real time, and this will help jumpstart meetings.

There are many great models for retrospectives available, and we've found that while there's no one perfect structure for all situations, there are some consistently effective patterns. Perhaps we'll explore these in a future post.

- Arlen

Slides from Agile Palooza DC

2011-10-04T13:47:00.004-04:00

Every now and then, one of my presentations seems to be more of a hit than others. The past keynote at Agile Palooza DC is one such occasion. I've had many requests for a copy of the slides, so here they are.

Please do share your thoughts and comments below.

Sanjiv

Building Quality In

2011-10-02T13:55:00.011-04:00

Building Quality In

In waterfall development, there is little opportunity for early testing. Most if not all of the delivery happens near the end of the project and this is a really bad time to find out that we have requirements issues, quality issues, performance issues, deployment issues, etc. One of the great advantages of Agile is in its ability to delivery early and often. This early delivery capability leads to an ability to start testing much sooner than usual. Early and frequent testing is critical to quality and agile's ability to support this early delivery model is one reason why agile projects often have lower production defect counts that systems built using traditional methods. However, what happens when you test early and you start to find a lot of defects? How should you handle that situation? Or should you even try to handle it? Perhaps this is to be expected given the fast delivery pace that agile demands. We think not. We are of the opinion that ...

A. Defects are very costly and are to be avoided where possible

B. Lean Thinking teaches us to build quality in

B. Many defects are actually the result of miscommunications and misunderstandings

C. There are simple techniques that can help

A. Defects Are Expensive.

Let's walk through the sequence of events when a typical software defect is found.

1. The developer writes code that it isn't going to pass through test and delivers it to testing

2. A tester finds the defect

3. The tester logs the defect in the ticket system

4. The developer tries to re-create the defect

5. Once found, the developer further investigates it

6. The developer, tester, and business analyst now have detailed discussions about how the feature should work

7. The developer re-codes, re-unit-tests, re-builds, and re-delivers the fix to the test environment

8. The tester verifies that the bug has been resolved and closes the ticket.

Wow! That's a lot of activity that would take up a lot of time for even the most trivial bugs. If teams are producing a lot of defects then this represents a huge 'quality debt' (kind of like technical debt) that will need to be paid back out of the velocity of future sprints. Either the team will need to hold back some amount of time from future sprints to work on defects or they will need to add additional sprints to deal with the quality backlog. So what can we do with our teams to better this situation?

B. Lean Thinking and Quality

There are a couple of different approaches to Quality in general. One way to deal with quality is to simply let defects happen and then rely upon quality control and testing to find the defects. This tends to be the standard approach. We don't think too much about quality until we enter the testing cycle and then we rely upon our testers to find the issues. The problem with this approach is that it is very expensive in terms of time as we have already discussed. Each defect will need to go through all of the steps that we outlined above. And who knows whether or not we will actually find all of the defects.

The Lean world has a different approach; build quality in and create continuous flow. In this model, we do everything that we can to keep defects from entering the system in the first place. By putting some additional controls in the up-stream process steps, and by giving the team members the ability to "stop the line", we can keep many of the defects from ever entering the product in the first place. This tends to greatly improve quality and also improve schedule performance since defects are so costly in terms of time. It also aids in continuous flow since you cannot get reliable forward flow when you are always having to go backwards to fix things. This is the approach that we will further explore. In order to keep defects out, we will need to think a bit about where defects come from.

C. Many defects are the result of miscommunications and misunderstandings

The US Constitution is only about 4000 words long. But to interpret it, we need 9 of the brightest and most educated legal scholars in the land who, at the end of the day, still cannot generally agree on what it means. These 9 people can read exactly the same document and come away with N number of interpretations, none of which exactly match each other. The same thing happens on software development projects. We can write the most beautiful, detailed, and highly elaborated requirements documents the world has ever seen and yet I am sure that if we gave the same document to 4 different software developers, 3 different testers, an architect, and a handful of end-users, we would come up with wide array of interpretations. So while the document may be of some importance in and of itself, it is in the end, insufficient. This is one of the reasons why we value people and interactions over documents!

Many of what we end up calling software defects are really just misunderstandings about requirements. The BA writes the requirement with one meaning in mind, the developer interprets it slightly differently, the tester interprets it in yet another way, and who knows whether or not any of them understand it in the way that the end-users want to see it work. And the funny thing is that the developer's unit tests will always pass because the tests are written against the developer's own assumptions!

The User Interface is another source of a myriad of little 'defects'. It is notoriously difficult if not impossible to write a UI requirements specification that completely and accurately captures every nuance of the user experience. I don't know that we yet have the tools and taxonomy to adequately communicate the user experience. So it is not uncommon to see a plethora of UI related defects for any system involving new UI development.

Another area of concern is that developers actually have at least 3 sets of requirements but they are typically only given 1 of them up front!

1. The Requirements Document or User Story: Yep, the developer usually has something to work with here.

2. The Tester's Test Plan / Approach: It is rare for the developer to see this in advance yet the code has to pass test in order to be released

3. The Customer's Acceptance Plan: It is rare the developer to see this in advance too yet we usually ask our product owners to 'accept' the solution before it goes into production

It is interesting that there are at least 3 sets of "requirements" that must be met and yet we tend to only have one of them defined in advance of development. The agile community is certainly getting better in terms of trying to define "acceptance criteria" up front but we still have a long way to go.

So how do we deal with all of this requirements uncertainty?

D. There are simple techniques that can help

I had the great pleasure of working with Jeff "Cheesy" Morgan a while back on a consulting engagement and we worked together to put some defect prevention steps in place that I will outline here. This is just a sampling of what is possible and there are certainly other techniques out there. The goal behind all of these tools is to either keep defects from entering the sprint in the first place or to at least keep defects from escaping the sprint once they are found.

1. Requirements Maturity Definition

If you've been in the agile community for any length of time, then you have certainly seen your fair share of inadequate requirements. And while even though we know that the requirements themselves will be insufficient, some level of requirements maturity is desirable. Some teams will create a "definition of done" for requirements that can help to make sure that poorly thought out requirements do not enter the sprint and end up being the source of a bunch of defects. For example, a story might need to pass the following basic criteria before being allowed into the sprint.

It is testable and estimable
The story has been decomposed to the point where it is less than N points in size
The basic UI elements have been defined and are available
The basic business rules have been defined and are available
The customer's acceptance tests are defined

By defining a basic level of maturity for the requirements themselves, we can help to ensure that enough details are known that the team has a reasonable likelihood of success in delivering the feature.

2. The Three Amigos

As we have discussed, even the best of requirements are open to interpretation. A practice that I like and that is growing is the use of what we call "The 3 Amigos Meeting". The 3 Amigos is an informal discussion between the person who wrote the requirement, the person who is going to be doing the coding, and the person who is going to be testing the feature. These 3 roles get together and discuss the story in some detail to make sure that they are all on the same page about what the requirement means, what the special cases are, how we will test the feature, how it should behave under special circumstances, how error conditions should be handled, etc, etc. At the end of the discussion, we will should have a much richer understanding of how the feature is going to work and most importantly, the 3 Amigos will all be of the same mind with regards to how this feature is going to work. The result should be greater understanding, less confusion, fewer misunderstandings, and fewer defects. We have this discussion for each feature/story in the sprint prior to development.

3. TDD

Test Driven Development is a powerful technique that turns the whole quality issue upside down; quality comes first. When we define in some detail how we are going to test a piece of functionality, what the test cases will be, what the data inputs will be, what the expected outputs will be, etc, we are actually specifying the true requirements in great detail. When we then code to the test plan, we are really coding to the detailed requirements. Not only do we typically get better quality, we also get automated test procedures and detailed testing plans. TDD is a powerful practice that, while difficult for many teams to implement, typically pays off in many ways.

4. In Flight UI Review

How often do you perform a demo to your stakeholders at the end of an iteration only to get a hundred little comments/change requests related to the user interface? This can be maddening for team members and clients alike as they try to identify, manage, and resolve all of the little things that often come up as a part of UI reviews. The UI is notoriously difficult to get right on the first pass; it is an inherently iterative activity that begs for a more collaborative process. We used to have a saying that I still like very much: "The demo should not be the first time that the customer has seen the feature!". While Scrum does demand that we perform product demos after each sprint, that doesn't mean that we have to wait until the end of the sprint to get feedback. For UI work especially, we should be collaborating with our product owners frequently throughout the sprint to catch all of those little subtle issues/changes that could be addressed right on the spot. Waiting until the end of the sprint to catch these can result in a truckload of annoying little change requests that could have been avoided.

5. Pair Programming

Like TDD, pairing is a powerful technique that pays back benefits in a variety of ways. And like TDD, it can be difficult to implement. There is a lot of existing bias against pairing, but if you can get it going, you will likely see improvements in product quality, improvements in code quality, expanded understanding of the product and the technologies by the team, cross training, elimination of single team-member dependencies, shared code ownership, etc.

Closing

The traditional approach to quality is to let bad things happen and then use various QA activities to find those defects and tease them back out again. We let bad design happen and then use design reviews to find the problems; these will need to be fixed resulting in rework. We let bad code happen and then use code reviews to find the bad coding practices; these will need to be fixed resulting in rework. We let defects enter the system and then we use testing to find the defects which will need to be fixed resulting in rework. You get the idea. The Lean model is to find where defects are entering the system and to put what are often simple steps in place to help to keep defects from ever entering the system in the first place.

Roland Cuellar

Announcing Agile India 2012: Call for Submissions

2011-09-26T10:37:00.005-04:00

Last month I blogged on Agile in Washington, DC, my hometown. Now, I'm pleased to announce another exciting conference, this one halfway around the world in distance, but very close in spirit: Agile India 2012.

I've been delivering training in India for the past two years and have presented at regional conferences and groups like Agile NCR and Agile Chennai. Now, it is quite exciting for me to be involved in a national conference in India next year. From the conference website, there are quite a few landmarks:

This is the first Agile Alliance conference held outside of North America.
This is slated to be the largest agile conference in Asia (okay, we'll make sure there are small teams/groups/sessions/meetings).
It represents a true collaboration between the Agile Software Community in India and the Agile Alliance.

Linda Cook from the Agile Alliance Board of Directors and I are co-producers of the Enterprise Agile stage at the conference.

Other cool things from a personal point of view:

The conference location is the global hotspot Bengaluru (formerly known as Bangalore), where I grew up.
I'm looking forward to working again with Naresh Jain, a Gordon Pask award winner and true pioneer in the agile world.
The co-producer of the Agile Product Development stage shares my last name. Her name is Annu Augustine, and she's doing a bang up job of organizing her stage, so please flood it with your submissions!
The conference stages incorporate key areas of personal interest, including Lean Startup, Leadership and Organizational Transformation.

From your perpective, I think this conference is a great opportunity:

If you live in India or other Asian countries, it will be an excellent opportunity to meet with other agile enthusiasts and spend quality time with them without long travel.
If you live further away, you have enough time between now and February to plan your travel to India and double up with some tourism as well. You can choose to head north to visit the Taj Mahal, or stay in the South visiting Mysore, Kerala and other closer destinations.
The agile movement in India is on the cusp of growth, and you can play a part in launching and growing it.

If you're interested in presenting, please note that October 3rd is the early bird deadline.

See you in Begaluru in February? Any questions or comments, do share!

ScrumMaster Standup for ExcellenceBy David Bulkin

2011-09-20T16:26:00.001-04:00

New ScrumMasters often try to direct the daily standup until someone explains that they are a servant leader, and it is the team, not the ScrumMaster who owns the daily standup.

The confused ScrumMaster then retreats into the background, not providing much value at all, other than recording blockers and updating burndowns.

Can a ScrumMaster play an active role while being a servant leader?

Active Role for ScrumMaster in Standup

I think a ScrumMaster can provide context to start the standup in a way that helps the team self manage.

Prior to the standup the ScrumMaster should collect relevant data about scheduling, progress (burndowns), work in process (e.g. how much), release progress, etc. Then, using 60 seconds or less, they can kickoff the standup, providing the context that helps the team understand how their efforts fit into the big picture, allowing them to make more effective decisions.

Example of ScrumMaster Providing Context

Here is example of one ScrumMaster providing context…

We have one more sprint prior to our release on October 28th and only five days left in this sprint.

Looking at our list of blockers, there are no open impediments, but looking at our stacked bar burndown and calendar, it appears that we have some trade-offs to make.

We have lots of work in progress, and, as we have noted (since Sprint Planning) both Bob and Carly are on vacation next week. Bob is out all week, and Carly is out Wednesday, Thursday and Friday.

I spoke to our PO Sue, who is offsite today, and she is fine with deferring either Story D or F, leaving it up to you, the team to decide. Story D has two tasks for which Bob volunteered, so that may help us make a decision (note that the ScrumMaster is pointing out an important fact, not explicitly telling the team what to do).

As always, thank you for letting me kick off our standup, and remember to focus on tasks on the board when answering the three questions.

In Closing

As a servant leader, a ScrumMaster should provide an environment for the team to succeed. One practical way to do this is to provide context that starts the standup.

Can you see a ScrumMaster providing value like this using 30 to 90 seconds of the teams time at the start of each standup?

The Gemba Walk

2011-09-16T10:53:00.003-04:00

As part of a recent engagement, Bob Payne and I went to assess and coach a group of Agile teams out in Iowa. Each morning, we would arrive before the daily stand-ups. Each morning we walked around, listened in on conversations and got updates from the teams. We quietly studied their large team boards and then how they interacted with the boards and one another. I would describe this daily stroll as our Gemba Walk. Gemba is a Japanese term meaning "the real place." In business, it refers to the place where value is created; in our case the gemba was the west side of the building on the 5th floor where the teams were located.

In lean manufacturing, the idea of gemba is that the problems are visible, and the best improvement ideas will come from going to the gemba. The gemba walk, much like Management By Walking Around (MBWA), is an activity that takes management to those doing the actual value delivery, to look for waste and opportunities to practice gemba kaizen, or practical shopfloor improvement. If you are in management and you want to make a real difference, get out of your office and go on a gemba walk.

If you are on a project team, do your managers go on a daily gemba walk?

HT: Wikipedia

Monumental Agile Adoption - Part 2

2011-09-04T06:43:00.005-04:00

Some weeks ago, I blogged about Monumental Agile Adoption. That is, large scale adoptions involving several 1000s of people. Even though they don't represent the majority of agile adoptions, we are still excited and inspired to hear about them.

The adoptions I mentioned then were large scale rollouts of agile software development methods. I've also been on the watch for "monumental" efforts where the agile principles and practices with which we are so familiar can be applied in other domains or novel ways. Here's an interesting example from the airline industry.

How does one manage the complex merger of airline systems when one major airline is acquired by another? When Delta acquired Northwest, Delta's CIO chose a version of the beloved agile tracking wall with the humble but ever increasingly popular Post It note. From the New York Times:

Delta’s chief information officer, Theresa Wise, said the airline had to merge 1,199 computer systems down to about 600, including one — a component within the airline’s reservation system — dating from 1966.
The challenge, she said, was to switch the systems progressively so that passengers would not notice. Ms. Wise, who has a doctorate in applied mathematics, devised a low-tech solution: she set up a timeline of the steps that had to be performed by pinning colored Post-it notes on the wall of a conference room.

Now that looks like the mother of all tracking boards, doesn't it? One would think that a successful approach like this would be imitated quickly. Well, it's too bad the folks at United Airlines didn't take note. United's systems have failed as they attempt to merge with Continental Airlines.

Do you have examples of applying agile techniques at a monumental scale? Do share.

Agile in Washington - A Decade in the Making?

2011-08-31T08:13:00.008-04:00

Around the time the Agile Manifesto was created in 2001, there were some of us in the DC Metro area who very quickly became passionate agilists. Flavio Diomede, my boss at that time introduced many of us, including Bob Payne, Kuryan Obi Thomas and others to Agile. We met "Uncle" Bob Martin, Ron Jeffries, Chet Hendrickson, Michael Feathers and other eXtreme Programing luminaries, and absorbed the beauty of technical discipline from them. Some years later I met Ken Schwaber when both of us were presenting at Software Education's Agile conference in New Zealand and Australia.

Over the next several years, as the agile movement continued to expand and grow all around the world, the DC region with its heavy bureaucracy remained an unexplored agile hinterland. There were many who despaired that agile would ever come to Washington in a big way. However one person with a positive counter vision was Fred Sencindiver, a fellow agile enthusiast and co-collaborator with Bob Payne and myself. A professor at George Washington University, Fred adamantly maintained it was simply a matter of time until Washington, DC ended up adopting agile methods in a big way.

Now, as we gear up for the 2011 Agile DC Conference, it seems that Washington's time has come. At this year's Agile DC conference, Ken Schwaber and I will keynote, and I'm sure we will meet with agile enthusiasts of all stripes and persuasions. Many local companies like The Motley Fool, The Chronicle of Higher Education, CarFax and AgileX have become strong practitioners of agile methods. Momentum has also built on initiatives such as the Federal CIO's 25-point program to reform federal IT management and Agile in the DoD, and federal agencies like the US Patent and Trademark Office and FFRDC's like MITRE have gotten into the agile act.

So, it turns out that Fred Sencindiver was quite right. It's clear that agile methods did indeed come to Washington. Fred was indeed a visionary, and continued to believe in an agile future even as he passed away in July, 2004. Thank you, Fred for your friendship, partnership and vision. We are now living in the future you imagined.

Visit us at AgileDC 2011 - Discount Below!

2011-08-29T13:02:00.008-04:00

Come visit us at AgileDC!

We are excited here at LitheSpeed to be involved in the AgileDC 2011 conference. We are a platinum sponsor of the event and three of us will be at the podium at one point or another throughout the day. Sanjiv Augustine is one of the keynote speakers along with Ken Schwaber. Derek Huether will be speaking on the new PMI ACP certification and the process that brought it to the Agile community. I (Bob Payne) work with a great group of volunteer organizers as chair of the AgileDC 2011 conference.

The conference is organized into 6 tracks and offers something for everyone, including our friends and clients in the government sector. These tracks include:

Introduction to Agile
Agile Engineering Practices
Agile in Government
Enterprise Agile
Agile & Business
Open Track for advanced and self organized sessions

The conference is happening on Wednesday October 26th, 2011, at the Kellogg Conference Hotel, Washington DC. Visit http://agiledc.org for information and registration.

LitheSpeed is happy to be able to offer a discount code to get you in for 15% off the regular ticket price; just use this code: AgileDCSponsorLSpeedGuest

I look forward to seeing you there and don't forget to say Hi!

Bob Payne

Vice President

LitheSpeed

Organizer AgileDC 2011

Theory X and Theory Y

2011-08-23T09:14:00.010-04:00

Do you lead or do you manage? Do you believe in command-and-control or do you believe in team empowerment? Recently, while presenting an Agile Enterprise Workshop, we discussed Theory X and Theory Y with our workshop attendees.

Theory X and Theory Y are two extremes introduced by Harvard Professor Douglas McGregor in his book “The Human Side of Enterprise”, over 50 years ago. Still, you can find both theories in practice today.

Though the theory of x and y are not absolute in how human nature plays out in our places of work, there will always be those among us who are polarizing and think of life as a side of a coin.

So, which do you believe?

Attitude: Do you believe we all dislike work, find it boring, and will avoid it if we can? Or, do you believe we need to work and want to take an interest in it? Under the right conditions, do you believe we can enjoy it?

Direction: Do you believe we must be forced or coerced to make the right effort? Or, do you believe we will direct ourselves towards a target that we accept?

Responsibility: Do you believe we would rather be directed than take responsibility for our own actions? Or, do you believe we seek and accept responsibility under the right circumstances?

Motivation: Do you believe we are intrinsically motivated by money and fears about our job security? Or, do you believe, under the right conditions, we are extrinsically motivated by the desire to realize our own potential?

Creativity: Do you believe most of us have little creativity? Or, do you believe we are actually highly creative, waiting for the opportunity to express it?

Again I ask, which do you believe?

HT: Dan Pink

HT: Sanjiv Augutine

HT: Wikipedia

LeanKit Kanban

2011-08-17T20:50:00.006-04:00

When the Agile Manifesto for Agile Software Development was written 10 years ago, it stated "We are uncovering better ways of developing software by doing it and helping others do it."

The very first of four values listed within the Manifesto was "Individuals and interactions over processes and tools"

The Manifesto goes on to state "...while there is value in the items on the right, we value the items on the left more."

Well, I am compelled to write about one of the items on the right. I still believe the tool should be good enough that it helps you reach your goals. But after that, it should not become a big process onto itself. What I want to do is finish tasks and get some actual closure on them.

I recently read in the book Personal Kanban by Jim Benson and Tonianne DeMaria Barry, a phenomenon known as the "Zeigarnik Effect". It states that 90% of people remember uncompleted or interrupted tasks better than completed tasks. Soviet psychologist Bluma Zeigarnic found that the human brain becomes preoccupied with things that are not closed.

Though I have leveraged Kanban with teams, it took me a while to realize that Visual Control Systems could be used to visualize and manage both personal and professional work. I then found myself using a physical board at the office and an electronic version (web-based tool) at home.

What is visual control, exactly?

A visual control is a technique employed in many places where information is communicated by using visual signals instead of texts or other written instructions. The design is deliberate in allowing quick recognition of the information being communicated, in order to increase efficiency and clarity.

The real question is, can a process tool take the place of individuals and interactions? Perhaps we need to stop and think about the reality of our world. Is everyone in your company physically located in the same office space or are you geographically dispersed? If you're not all sitting there together in an open workspace, you need to find a tool that will bridge that physical gap and then stay out of the way. Bandit Software's LeanKit Kanban does that. Let me tell you what puts LeanKit in the lead of the Kanban tool race. It's called mobile computing.

I seem to carry my iPad with me everywhere. (I'll be getting an iPhone as soon as my contract is up). Though the LeanKit iPhone/iPod interface could use a little work, the iPad interface is completely awesome. The image above is actually a screen print from my iPad. The design is simple; it's lightweight; it's functional. It helps me visualize my work and it helps control my work in process. Merge LeanKit Kanban and an iPad and you will have an amazing user experience, as it allows individuals to interact wherever they see fit. I'm happy because I can access half a dozen different boards with tap of my finger and my wife is happy because I didn't cover the walls of my home office with whiteboards and sticky notes.

If you're thinking about using a web-based Kanban tool for yourself, your team, or your organization, all of the vendors out there have relatively similar features. See which one fits your budget. If you or your teams are using mobile devices like iPhones, iPods, or iPads (in addition to desktops or laptops), you need to go to iTunes and download this app. Though you need to have an existing LeanKit account to make the Apple App versions work, you can get a personal account for free!

After you see how well it works for your personal life, I don't doubt you'll be using it in the office in the not-too-distant future.

HT: Wikipedia
HT: LeanKit
HT: Personal Kanban

The Joy of Agile Work - See you at Agile 2011?

2011-08-02T21:16:00.028-04:00

So, this is the 10th anniversary year of the Manifesto for Agile Software Development, and the registration for next week's Agile 2011 conference is the highest ever. This year, like others, we at LitheSpeed will be active and enthusiastic participants in the conference. Since this is an anniversary year, I thought some reminiscing would be appropriate.

My initial encounter with the agile community was in 2002, when my boss at that time took us to XP Universe. To someone new to the community, it was quite awe inspiring to meet luminaries like "Uncle Bob" Martin and Michael Feathers. I remain impressed by Uncle Bob and Michael to this day. Then, the next year's Agile conference brought a chance to meet none other than Alistair Cockburn in Salt Lake City. I have to say that that year's conference changed my professional life. I made so many friends, many of who have remained in close community. Alistair Cockburn, Sid Pinney from Thoughtworks, our own Bob Payne, Michael Hamman -- I met them all that year. Bob, Michael and I hung out at a taco truck and spoke excitedly about our shared interest in an Open Space session on Complex Adaptive Systems. We were excited because we felt in our bones that we were on the cusp of something new and big. We didn't quite know where the whole movement was headed; but when we met magnetic personalities like Diana Larsen and Ellen Gottesdiener, we knew that we had mentors and friends on that journey.

Over the years, every agile conference has grown, but I know others are having that first-time experience of discovering something new and wonderful (or maybe just exotic: few can forget the belly dancers at Agile 2004). Things have grown busier, the conference tracks are more packed, the speakers more advanced, but there remains an air of something new and different with every conference. Also nowadays, the conference certainly carries itself with a well heeled air. The taco stands have been replaced with vendor receptions and other generous spreads. Agile has both grown up and is bringing in the bacon/tofu. So, what keeps us coming back together?

Some years ago, I had a wonderful vacation in Sedona, Arizona and learned about its energy vortexes. Okay, so maybe I'm just not that into the vortexes (vortices?), but I think that the Agile Alliance has created a sort of energy vortex around the conference.

I think, every year, this wonderful vortex draws us all in – experienced and novices alike – and gives a uniquely uplifting experience. In this year's vortex, I don't doubt that I will meet old friends and make new ones, and learn tons more. But what draws me back this year, is exactly what has drawn me back in past years: the opportunity to learn and share more about what is ostensibly a development and/or project management process, but what has become for me and many others, a joyful way of work.

This year, we're excited that LitheSpeed's presence at the conference will include:

The Live Aid Lab/Agile Philanthropy led by Bob Payne, Tuesday 8/9 through Friday 8/12
10 Minutes to Testable Specifications led by David Bulkin and Bob Payne, Tuesday 8/9
10 Minutes to a Better Standup led by David Bulkin and Bob Payne, Tuesday 8/9
The Joy of Work: Managing Performance, Innovation and Organizational Maturity, led by Arlen Bankston and Sanjiv Augustine, Wednesday 8/10 at 1:30 PM
Three Months for Idea to Implementation: Jumpstarting Agile in Nuclear Power, led by Srini Gopalan and Eric Pitschke from Westinghouse Nuclear, and Sanjiv Augustine
Visual Portfolio Management - Putting the 'Big' in Big Visible Tracking led by Bob Payne and MIchael Kaiser
Interviews of Agile Thought Leaders for InfoQ, led by David Bulkin

To our many friends and associates with whom we've consulted and trained, I hope that this event will give us a few moments to catch up, and to connect yet again.

Hope to see you there in less than a week!

Becoming a PMI Registered Education Provider

2011-07-20T16:45:00.000-04:00

As you may know by now, I left my gig advising a Federal PMO to join LitheSpeed as a senior manager. LitheSpeed, as you likely know if you're on this site, offers premium Agile software development training, coaching and management consulting services. My relationship with the organization actually started several years ago, when I attended a ScrumMaster training to earn my certification. (You can't be a Certified ScrumMaster through the Scrum Alliance unless you get your training from a Certified Scrum Trainer®.) Well, the world is evolving and so is LitheSpeed.

See, Certified Scrum Trainers (CSTs) play a vital role within the Scrum Alliance. They are the only ones licensed to teach CSM and CSPO courses. Stringent certification requirements are imposed on CSTs to make certain that only those who are qualified to meet the commitment are entrusted to engage in this role on behalf of the Scrum Alliance.

Well, what about those out there who are members of the Project Management Institute? What about those seeking the upcoming PMI® Agile Certified Practitioner (PMI-ACP)^SM certification? If you want to qualify to sit for the PMI-ACP, you'll need 21 training hours in an Agile-specific curriculum. To ensure members of the PMI know LitheSpeed offers quality training that will help satisfy that requirement, we applied to and were approved to be a PMI Registered Education Provider (R.E.P.).

What does it take to become a PMI R.E.P.? Applicants must complete a 33-page application, which includes a strict quality review of both the trainers and the curriculum. The first class we submitted and got approved was our Certified ScrumMaster course; next will be our Certified Product Owner and PMI-ACP Prep courses. As an R.E.P., LitheSpeed has been approved by PMI to issue Professional Development Units (PDUs) through the PMI website. Our goal is to equip our trainees with tools they can apply to current and future projects, not just help them qualify to take an exam.

PMI recognizing Agile publicly (at the PMI North American Congress last October) was a huge step. Establishing a separate certification for Agile practitioners was also huge. Because there is a clear market need, it's critical for us to evolve along with PMI, expanding our offerings to ensure PMI members have the proper introduction to Agile approaches.

PMI® and the PMI® Registered Education Provider logos are registered trademarks of the Project Management Institute, Inc.
PMI-ACP^SMis a service mark of the Project Management Institute, Inc.

What to Consider When Hiring User Experience Specialists

2011-07-11T15:36:00.000-04:00

One of the questions I often get from our clients is, "What kind of designers or user experience specialists have the appropriate experience or skill set for working in an agile environment?"

In general, there are a number of different but related specialties in this field, the broadest definition of which has tended to be "user experience." Some of these include user experience (UX) research (understanding what users do and want and translating that into appropriate feature sets and designs), information architecture (IA) (organizing information, search and navigation theory, site structure, etc.), graphic design (visual representation of information or ideas), interaction/user interface (UI) design (visual design of interactive systems), and web design (front-end coding and scripting expertise in HTML/CSS/Javascript along with some UI design chops). Those who call themselves User Experience (UX) Designers often blend information architecture and UI design skills, and occasionally possess some coding ability.

There are two basic models that you most often see for these folks in an agile environment:

1. One widely experienced person in each team that blends a bit of all of the above, who would likely be called a UX/UI Designer or something of that nature. Some teams just have developers with skills in interface design, so the particular title differs widely, but it will likely have "designer" in the title.
2. A central UX group that helps multiple teams with user research, common style guides and UI design, often lending their members part-time (roughly 30-50% in many cases) to help execute designs within certain sprints.

More info on UX basics (and hiring) can be found here:

· An overview of what UX looks like in Agile teams: http://www.uxmatters.com/mt/archives/2011/04/integrating-ux-into-agile-development.php
· An old ad which captures some of the basic skills: http://blog.apps.chicagotribune.com/2009/12/24/were-hiring-a-uxia-expert-and-a-web-designerdeveloper/

- Arlen

Definitive versus Empirical

2011-06-29T22:56:00.008-04:00

Ever heard of the cone of uncertainty? The cone shows the historical error at certain time periods in a tropical cyclone forecast. What happens today and what has happened in the past is pretty much all we know. We can certainly use all kinds of scientifically proven processes or models to try to predict the future. But, in the end, we won't know what tomorrow will bring until tomorrow. If you are dealing with machines, you should be able to predict upcoming events with relative certainty. If you are dealing with people or something like mother nature, the odds of predicting events with certainty are slim to none.

We need to assume that baselines may change significantly during a project or in life. In unpredictable environments, empirical methods should be used to monitor progress and direct change, rather than using definitive methods to try and predict progress and stop change.

Definitive

You work and work and work, trying to lock in your scope, your schedule, and your budget before the project even begins. You do everything you can to lay it all out, attempting to account for every possible variable. Unfortunately, you don’t know what tomorrow will bring. So, the further out the schedule goes, the greater the risk something is going to change. What’s it going to be? Is scope going to change or maybe the schedule will slip? With the cone of uncertainty, whatever foreseen changes are ahead, there are going to be exponentially more unforeseen the further out the schedule goes.

Empirical

In reality, you begin with the greatest unknown. Even some of the unknowns aren't even known. Just accept it! You can’t predict the future. The only thing that is guaranteed is something is going to change. So, plan for that change. Know the goal you’re trying to reach. Keep your eye on that goal. Now, do what you do. Develop, lead, manage…it doesn’t matter. What does matter is you see where you are right now, know where you want to go, and then at a measured time, see where you are again. Make some adjustments and repeat. You will find if you just accept the change, you can use it to your advantage to get closer and closer to your goal.

Summary

You can not predict the future, only plan for it. You can not steer a hurricane, only plan for it. You can not prevent change. Can you guess what comes next? That’s right, you plan for it.

Organize Around Teams

2011-06-20T07:13:00.026-04:00

Several years ago, I was working with a client who was obsessed with keeping resources (in this case, people) 100-percent utilized. The client boasted that he had a strong matrixed organizational structure and everyone was a member of multiple teams working on multiple projects. When I came on board, I noticed that people were spread extremely thin between the projects. There was a lot of work being performed but very little was getting done. How can you make real progress if you have multiple managers asking you to deliver that high priority something for them? How can you make real progress if you have to constantly shift gears and go in different directions?

In theory, having a matrixed organization sounds really great. Resources can potentially be utilized up to 100 percent. In reality, the goal is not utilization of a resource. The goal is throughput and delivering something of value. In the end, having a matrixed organization made people busy but it did not make them more productive. Perhaps managers felt more productive because they essentially had more people they had to manage. But again let me stress, the goal is not to manage people. The goal is to deliver something of value. When I did my original assessment, there were two common complaints. First, team members didn't know who to take direction from. Second, team members never seemed to have time to just focus on one thing and get it completely done.

Status quo organizes teams around projects

Projects are initiated

We beg, borrow and steal, looking for the right people to work the project

We pull a few hours from here and a few hours from there

Everyone is "fully utilized" by working on several projects at the same time

When the project is complete, we release some portion of each person’s hours back into the pool and start again

Endless resource-management frustration

Bring the right projects to the right teams

Teams focus on one or two projects at a time and get them done quickly

Management prioritizes projects and queues them up for the appropriate teams

May need to move a few people around but hopefully not many and not constantly

Much of the resource management problem goes away

We also get fewer simultaneous projects, more focus, and more speed of delivery

Once we got people grouped into several (cross-functional) teams and then collocated in team areas, we actually started making deliveries on projects. The PMI would define this reorganization as being projectized. But, let us not forget that this is about the teams and creating an environment in which they can deliver value.

In our Enterprise Agile Workshop, we explain how organizing around teams allows you to estimate, plan, and deliver at a more accurate level of granularity.

HT: LitheSpeed Enterprise Agile Workshop

A Conversation on Using Agile at the Program Level

2011-06-15T08:31:00.001-04:00

As organizations scale to more agile teams, a shift to agile program management is inevitable. In this podcast, Bob Payne sits down to discuss agile program management with Johanna Rothman, management consultant, author, and enterprise program management expert.

The goal in program management is to effectively manage several projects run by multiple teams to get the product out the door. We’re talking about big deliverables here. Johanna talks about the challenge of moving the usage of agile up to the program level. She lays out the steps a program manager can take in order to help facilitate this kind of development, including the use of a program architect, program storyboards, and cross-team collaboration.

During the conversation, Johanna also addresses the importance of a product or program team's ability to make decisions when there are competing interests.

And finally, Bob and Johanna discuss the meaning of "done.” According to Johanna, a product isn't done until the team can answer in the affirmative to the following three questions:

1) Does it meet the acceptance criteria, including the norms for the team?
2) Has the product been reviewed and tested?
3) Is the product deployable and installable?

Listen to Bob's conversation with Johanna now: http://agiletoolkit.libsyn.com/agile-2010-johanna-rothman-agile-program-management.

Failure: The Road to Success?

2011-05-23T17:12:00.012-04:00

Anyone who's been around in the agile space for a while knows the standard agile mantras: inspect and adapt, people over processes, and my own personal favorite: fail fast and learn fast.

Since my personal predilection tends toward trying to ensure success come what may, it's been fairly tough for me to develop a personal discipline of learning from failure. I remember the turning point - it was a keynote session delivered by Henry Petroski at the 2001 OOPSLA conference on Success and Failure in Design. From James Cooper's summary,

"The thrust of Petroski’s lecture was that the design of large architectural elements such as bridges went through a number of evolutionary steps, starting with limited understanding of the physical forces and material strengths and weights and moving towards much more sophisticated design. The key to success in building these structures is a thorough understanding how failure can occur, and design that includes allowing for that failure."

Closer to the agile homestead, and nearer in time, the Lean Startup model has rocketed in popularity. The Lean Startup model contains, I believe, an eminently viable model for agilists to learn from failure, or to experiment in conditions of high uncertainty. Actually, it's called pivoting, and the focus is completely on learning, and not on the failing because of the high speed and low cost with which it is accomplished. Our friend @DavidJBland, with whom I sometimes think I have a Wi-Fi mind meld, tweeted today about success and failure. He reiterates the Lean Startup essentials:

Customer Development
Business Model Generation
Agile Software Development

As David points out: survival without any of the above is pretty tough.

If you're more of a general management than a product management type, you might appreciate this: India's famed Tata group employs an interesting technique in its quest for increased innovation and global growth. Chairman Ratan Tata has instituted a prize for the best failed idea.

Columbia Business School professor Rita McGrath also identifies Google's myriad failed ideas: Google Wave, Google Search Wiki, Google Audio Ads, Dodgeball, Google Print Ads, and Google Answers to name a few, and reminds us that a few blockbuster successes are built on many failures (pivots?).

Your thoughts on the role of failure and learning in success?

Is Your CEO an Agilist?

2011-05-18T07:10:00.008-04:00

A few days ago, I blogged about "monumental" agile adoption, and discussed about how large-scale adoption (not just large projects), with 1000s of people involved in an agile transformation needs not just bottom-up, grass roots momentum and buy-in, but top-down executive support. I also was involved in a Twitter conversation about agile companies. The conversation led to how, while the numbers and the scale of agile adoptions are growing, we still need to see more companies leveraging agile methods to deliver business agility.

Jim Highsmith has described agility as, "the ability to create and respond to change." So, by this definition, an agile business must be able to both create and respond to change. It stands to reason that such a company needs executive leadership that understand, appreciates and is able to institutionalize agility. There is direct financial benefit to this sort of Enterprise Agility. As Jim points out, Enterprise Agility generates 30% higher profit.

The theme of this year's Agile Executive Forum, organized by the Agile Alliance in collaboration with the Agile Leadership Network at the Agile Alliance's annual conference is "Now is the Time to move to Enterprise Agility." As my Twitter friend asked me, is their CEO an agilist?

I'll be blogging more on this topic shortly, but in the meantime, let us know: is your CEO an agilist?

"Monumental" Agile Adoption

2011-05-13T23:30:00.006-04:00

Some years ago, I had the privilege of being involved in a massive agile adoption at Capital One. That adoption succeeded, I believe, because of the powerful combination of top-down executive support and bottom-up grass-roots momentum.

I've found that, though these large-scale adoptions do not represent the vast majority of adoptions, we still love hearing about them. What is it about these large adoptions that captivate us? I think it is their large, visible, monumental nature that strikes us with awe and respect. [Incidentally, I think this is why we hear (see?) much more about Egypt than the larger and equally accomplished Indus Valley civilization. For history buffs, the Indus Valley civilization is believed to have been democratic, and not authoritarian.]

Anyway, over the past few years, I've been looking forward to hearing more about other, newer monumental adoptions. There are large-scale adoptions underway with several 1000s of people at Siemens and Huawei. Reportedly, 70% of all projects at Huawei use agile methods.

Now, ERP giant SAP reports "all well" with its own monumental agile adoption. Working toward building a "culture of innovation," co-CEO Jim Hagemann Snabe reports that delivery cycles have been cut from 15 months down to 6-9 months. Some of SAP's agile-in-a-large-company specifics, across 14,000+ developers:

Forming smaller teams that are empowered to make decisions on their own
Customers are in the room from the beginning, not at the very end
Switching to Scrum for iterative development, with 4-week Sprints

Hopefully, these changes will help SAP turn its bureaucratic culture around and achieve desired business results.

Meanwhile, Capital One has moved on and is doing well. If you're interested in the larger business focus of how Capital One "loves to change," check out this paper, Building a Change Capability at Capital One Financial: http://ceo.usc.edu/pdf/g08_09.pdf.

Do you know of any monumental adoptions? Do tell...we all love them, don't we?

The PMI's "Agile Certified Practitioner" Certification

2011-05-13T23:03:00.002-04:00

After a few years of inexorable movement, we are very close to seeing the Project Management Institute (PMI) launching its agile certification. After some early involvement in 2008 with the PMI Agile Community of Practice, and 2009 at the Agile Conference in Chicago, I had to drop out of the organizing group. So, I am glad to see this movement coalesce and move toward certification. Kudos to Mike Griffiths, Jesse Fewell, Derek Huether (now with LitheSpeed!) and others in the PMI leadership for pulling off this difficult task.

In looking for details about the certification and what it entails, I've found Mike Griffiths' site to be most illuminating. So, here are links to 3 pages that I found most useful:

More details about PMI's Agile Certification
Inside PMI's Agile Certification Exam Content Outline
PMI Cert to be called "Agile Certified Practitioner"

Then of course, we should be diligent enough to review the information coming from the source, so here is the PMI's page on the subject: http://www.pmi.org/Agile.aspx.

I'd like to congratulate Mike Griffiths and Jesse Fewell -- two bridge builders who worked tirelessly for the past few years to make this a reality. Thanks also to Rory McCorkle and his team at the PMI for doing the long hard work within the PMI.

In closing, for those in the LitheSpeed CSM community -- have no fear -- your 16 PDUs earned doing the CSM qualify towards the required 21 PDUs needed to take the exam.

Free Agile Tool!

2011-05-10T13:20:00.002-04:00

Did that get your attention? We all love a freebie now and then, but I think our friend David Bland has outdone himself with this one.

Check out David's incredible Blog post on creating a Burndown Chart with Google Docs: http://www.scrumology.net/2011/05/03/how-to-create-a-burndown-chart-in-google-docs/.

Okay so, it's not Version One, but I haven't seen something as simple, light and quick as this in many years.

Thank you David for your yeoman service to the agile community, and for this incredibly detailed, useful and bound to be popular advice!

Stop versus Done, Part 2 of 2 David Bulkin

2011-05-09T14:40:00.003-04:00

This is part two of a two part post, so if you didn't read part one yet, you can read it now.

Per part one, it is easy stop work on fine grained tasks without ever getting anything to the point where it is truly done.

Good agile teams have just a few stories in play at a time, and use the story acceptance criteria as the most basic definition of done. They also include additional generic criteria at the story level that must be met, such as the code is checked in.

At the feature level, we rely on the product owner to define done, as they decide if the stories already completed address the feature sufficiently enough, perhaps to the point where no further work is required for that feature.

In this post we will look beyond the story and feature level to the sprint level and beyond.

Sprint Level Criteria

Sprint level done criteria covers items that are addressed in aggregate, instead of at the user story level. Some samples that may apply are listed below.

Installation documentation has been updated
Security scans and tests performed and all problems addressed
Installation scripts have been updated and tested
Release notes have been updated

Why not at the Story Level?

Getting to done earlier rather than later is a good thing so you could specify the above criteria at the story level. One way of deciding if criteria should be applied at the sprint level is to ask if it will be best for one person (not necessarily the same person each sprint) to be responsible for this criteria for all stories in a sprint.

As an example, you want one consolidated set of release notes that is coherent across the team. It is easy to have one person be responsible for updating the notes getting input from the rest of the team.

Why not at the Release Level?

The criteria that we listed as sprint level, could be story level criteria, but most teams, especially those new to agile, do the reverse and keep them as release level criteria.

For example, security testing is frequently deferred until just before a release, generally because it is painful to deal with the large number of exceptions found.

Does waiting make it less painful, or does it just push increased pain off until the future?

The simplest way to make the pain go away is to perform the security test more often, perhaps daily (maybe even with each story, thus making this story level done criteria). The fast feedback simplifies the remediation work.

Across Multiple Sprints

We prefer not to defer, but there are some things that may best occur outside the context of a single Sprint. One common example is performance and load testing.

Perhaps the test environment we need costs several million dollars and is shared across several teams. In this case, maybe we only get a testing window every other month for a week. Assuming two weeks Sprints, this means that our done criteria must span four Sprints.

What happens if we find serious performance issues after four sprints of work?

Do we have to unwind many hours of work?
Do we have to create multiple branches of code?

Ok, you already got that point, delaying the feedback cycle is a bad thing. But let’s assume, that in our example, we simply can’t get to the performance environment more than once every other month.

Would it be possible to do performance and load testing on a scaled down environment that would shorten our feedback cycle and allow us to address most issues early?

In many cases the answer is yes, if so, you can include “Passes load and performance test on scaled down environment” as part of your sprint level done criteria.
Your release level done criteria can then include “Passes load and performance test on environment that models production”.

Release Level

There should be little deferred to the release level. Items that are truly release level should generally be at the periphery of the teams work, like training for the impacted staff, assisting with verbiage for the sales campaign, etc.

Closing

Create your done criteria to ensure rapid feedback and recognize that deferring the point at which you reach done likely increases pain and complexity, while balancing this with the need for your done criteria to be practical.

As always, feedback is welcome.

Stop versus Done - Part 1 of 2 By David Bulkin

2011-05-09T14:24:00.002-04:00

Project manager often rely on detailed task lists to monitor progress. The thought is that having lots of fine grained tasks provides visibility.

Unfortunately it is easy to get lost in the details and we often end up being lax in determining if a task is truly complete. As such, we simply consider a task done when the assigned individual stops work on it.

Just because work is stopped, doesn’t mean that anything valuable has really been done.

Good agile projects track just a few user stories (instead of many tasks) at a time and apply strict criteria, specified in advance, to determine when a deliverable is truly complete, e.g. done.

This post, and the follow up, help your team define done criteria at various levels, from story to release, in a way that will engender fast feedback and increase effectiveness to define done criteria in a way that encourages early feedback and ensures that when we stop, we are truly done.

In this first post we will look at the basics, user story and feature level definitions of done.

Story Done

A user story is not done until it meets all story acceptance criteria and has been accepted by the product owner. In addition to the user story specific acceptance criteria, teams should have generic story level specifications similar to the following.

Code has been checked in
The agile lifecycle management tool and task board have been updated
Testing has been performed and the code passed
Code has peer reviewed and approved (e.g. code is clean)
Automated testing is in place for the code
Help system has been updated to reflect changes to the story

Don’t Defer Testing

In all cases we want to define done criteria in a way that encourages early feedback and ensures that when we stop, we are truly done.

A primary example is testing which we have included as story level done criteria. All too many teams defer writing test cases for a story until after the coding is stopped. This means that in most cases the code is not tested until the subsequent sprint.

Testing a sprint behind defers feedback and results in a cascade of complexity as we eventually have to resume coding that we had previously stopped (e.g. we weren’t really done).

For example, assume we are in Sprint 12. What happens when find a large number of bugs in the stories that we stopped coding in Sprint 11?

Do we stop work on the user stories planned for Sprint 12?

Do we continue some work on our planned stories and spend some time fixing bugs?

Or do we just defer the bug fixing to Sprint 13?

When when we stop coding and then do testing, we are really not done coding because testing will find bugs. As such testing should occur roughly in parallel with coding and be completed in a single sprint, meaning our story level done criteria should include that all tests have been executed and passed.

Help System Updated, Another Example

The update of a help system is interesting as, with testing, it is often deferred. In the case of help systems, they are often specified as release level done criteria. The logic is that the technical writer is a part time team member and teams want to have everything in place for them.

Our goal is to make the team and organization more effective, not to optimize the performance of the technical writer.

Documenting a user interface is a great way to help with quality. If a UI is hard to document, it is generally also hard to use, so if we work on end user documentation in parallel with the development work, the feedback informs and improves our design.

So include the help system update as a story level done criteria (or perhaps you can include as sprint level criteria if your sprints are generally focused on related changes) and modify your teams approach, by sharing the writing load or by getting more writing resources.

Feature Level Done

The done criteria for a feature (e.g. something to big for a sprint, a.k.a. an epic) can be viewed as getting to done on enough of the high priority child stories (e.g. the sub stories) to the point where the product owner believes that no more stories should be worked on.

As most good agile teams have learned, this means that we often decide not to work on many of the original user stories we created. Sometimes the best decision we make is what not to work on!

Closing

In summary remember not to confuse stopping work with being done, don't defer to later what you can do now, and also remember that you don't need to do everything you originally specified (e.g. less can be more especially at the feature level).

In part two, we will look at definitions of done for the sprint level and across sprints.

Motivation for Today's Knowledge Worker - Listen to Payne & Augustine By David Bulkin

2011-03-27T13:53:00.000-04:00

Thanks to Despair.Com for image

We recognize that year-end performance reviews seldom improve performance as they generally focus on what’s wrong, not amplifying what right.

We also recognize that pretty posters do little to help motivation.

To make it even more confusing research indicates that money by itself is not a great motivator for most knowledge workers!

So what motivates today's knowledge worker?

Money, Title?

According to Dan Pink, more money and a better title are examples of extrinsic motivation that attempts to motivate from the outside. They work well for concrete well defined, repeatable tasks and jobs, but extrinsic motivation fails for the complex tasks performed by knowledge workers.

Autonomy, Mastery, Purpose?

On the other hand, intrinsic motivation, which is based on autonomy (control), mastery (improving over time), and purpose (makes a difference), is more appropriate way of thinking about motivation for knowledge workers.

Listen to Find out More

In this podcast you will hear Bob Payne interview Sanjiv Augustine; they talk about Dan Pinks work, and cover other aspects of motivation (with an eye on agile) with the goal of leveraging techniques for better performance by individuals, teams and organizations.

Click here to listen to the podcast and then write and tell us what you think.

Thanks,
David Bulkin

Estimation in the Large By David Bulkin

2011-03-05T14:13:00.003-05:00

This post is for those who believe that story point estimates are valuable (if you are not sure you can read the post linked here) and who have to estimate a large number of stories at one time (e.g. in Discovery / Sprint 0 or at Release Planning).

Most teams use Planning Poker all the time, but does Planning Poker work effectively when you have 150+ stories that you need to estimate at one time?

In practice, Planning Poker is too slow when estimating large backlogs. To be more formal, I created acceptance criteria to judge a story point estimation process that you would use for an approved effort (e.g. you may want to use a different approach if you just want a rough size prior to approval):

Leads to a shared, common understanding, of the user story.
Results in an ability to create a credible release schedule across the backlog.
Relatively quick to use.
Fun, or at least not painful to use.

I didn’t list accurate story estimates as acceptance criteria. This is because I care more about a common understanding and a credible schedule across the backlog (e.g. the aggregate of the estimates are what counts, so if there are two stories that should be a 5, and one is labeled an 8, and another a 3, I am ok with that).

Planning Poker Not So Great for Large Backlogs

In any case, Planning Poker meets the top two acceptance criteria when working with small backlogs. With larger backlogs your mileage may vary because of the stress created by failing to meet the third and fourth criteria.

Planning Poker is not very fast, and when it slows down it gets painful, resulting in tension, poor estimates and lack of clarity. It also results in a large loss of time. No wonder so many have given up on estimating!

Team Estimation Game

Assuming you do want to estimate, there are approaches better suited to large backlogs. The Team Estimation Game developed by Steve Bockman is summarized.

The Product Owner ranks the story cards and places the highest ranked card in the center.
The team arranges the story cards, left to right, in columns, by size, on a table, whiteboard, or in an electronic tool. The leftmost column is the smallest story, the rightmost the largest.

Team Members take turns.
In each turn the team member can take the top story card and place it into one of the existing columns or create a new column.
Or, the team member can take a previously placed card and move it.

After all stories have been estimated, each team member can move one card, and then the team assigns the relative scale, such as the modified Fibonacci sequence (1, 2, 3, 5, 8, 13, 20, 40, 100, 200, 400, 800), to each column.

How Good is the Team Estimation Game?

I think the Team Estimation Game is superior to Planning Poker for large backlogs, but does it meet the acceptance criteria?

There is a tension between obtaining a shared understanding (first criterion) and being quick (third criterion). As such, I believe there are variations on this theme that are even better for large backlogs. But, it wouldn’t be any fun if I included those variations in this post.

In Closing

So, next time, we will look at some alternatives. Until then, please write us with your thoughts and what has worked for you.

Jeff Sutherland at APLN DC

2011-01-29T08:08:00.002-05:00

On Monday, February 7th, Jeff Sutherland will be speaking at APLN DC on Using Scrum to Avoid Bad CMMi Implementations. Jeff's will also co-training a Certified ScrumMaster class with me on February 7-8 in Reston, VA.

Hope to see you at one or both events!

Widespread (Though Fragmented) Agile Adoption Continues

2010-12-28T18:23:00.015-05:00

For the past couple of years, our friends at Cutter Consortium have requested me to contribute to their set of predictions for the upcoming New Year. Here are my predictions from last year. Looking forward, here (on Cutter's excellent site) are my predictions for 2011. I've also reproduced them below for your reading convenience.

In 2011, I see continued widespread adoption of agile methods, though with growing fragmentation and dissipation. Many different blends of Agile will evolve to serve the interest of different communities and protagonists:

Growing PMI-Agile Nexus. The philosophies of the leaders of and project managers in the PMI and Agile communities will continue to converge, with the PMI Agile Community of Practice growing at the nexus. This will happen despite chagrin and opposition from the extreme quarters of both communities. PMI managers will now feel they have their own version of agile.
"Cargo Cult" Agile. With many companies having practiced some version of Scrum or other agile method for many years now, many agile practices such as collocation, big visible charts, daily stand-up meetings and collaborative workspaces will simply become the de facto way that software development projects are run. These agile practices will be employed without any knowledge of the principles behind them, and therefore, will be of limited effectiveness, though perhaps still better than the waterfall alternative. Nominal adopters will feel they have arrived with agile.
Growing Internationalization. With the rapid growth of agile adoption in India, China and Latin America; agile methods will expand internationally in a big way. U.S and European companies will feel that their international partners and/or subsidiaries are now drinking the same agile Kool-Aid.
Yes They Kanban. With the establishment of the Lean Systems and Software Conference, a new landmark book by David Anderson, and many other industry bigwigs behind it, Kanban will develop significant momentum. Scrum doubters will now have their own version of Agile.
Lean-Scrum-XP for the Enterprise. Agile Enterprise enthusiasts like myself will continue to insist on the Lean-Scrum-XP prescription as the best way to scale Agile to the enterprise. Scrum, for getting teams up and running quickly and evolving high performance teams; XP, for deep technical discipline; and Lean, to scale beyond individual teams with effective program and portfolio governance. Senior managers will feel they have a robust Agile variant.
Scrum Uber Alles. Despite the momentum of Kanban, PMI Agile growth, some Lean in the enterprise, and diehard XP adoption, Scrum will continue to rule the roost. Certification will continue to be the wedge that introduces Scrum into more and more organizations. Also, despite continued lamentation in some quarters, certification will continue to be the market draw for individuals genuinely seeking to burnish their credentials or to simply jump onto the Agile bandwagon. Scrum enthusiasts can feel vindicated that they have the largest mindshare.

What do you think? Do you agree/disagree with any of the predictions above? They're just guesses after all!

2010 Predictions - How Did We Do?

2010-11-18T23:05:00.004-05:00

Late last year, I participated in Cutter Consortium's predictions for the year ahead. I'm getting ready to go out on a limb again and make another set of predictions for 2011. But in the meantime, I thought it would be good to reflect on the predictions I made for 2010:

XP 2.0. Agile engineering practices will gain traction as teams and organizations that have implemented Scrum work on increasing code quality. Practices like Test Driven Development, Automated Build and Test, and Continuous Integration will see wider acceptance. Several years after its initial surfacing, software craftsmanship (seehttp://manifesto.softwarecraftsmanship.org/) will gain in momentum.
Agile 2.0. Teams and organizations that have been practicing Scrum for 3 years or more will extend to hybrids like ScrumBan, Scrum/XP and even ScrumFall (if they lose executive sponsorship and are forced to backslide towards Waterfall). Kanban will continue to gain in momentum and mindshare.
Business 2.0. More small to medium-sized companies will initiate enterprise-wide transformations, using Agile development principles in concert with Lean business process improvement in an attempt to transform their businesses in today’s harsh economic climate.
Agile Failure 1.0. There will be more failures in agile adoption, as organizations attempt to drive the agile practices without fully understanding the agile principles; or simply jump onto the agile bandwagon and continue to practice waterfall (or whatever) while calling it agile.

I think I was reasonably accurate with my Agile 2.0, Business 2.0 and Agile Failure 1.0 predictions. Kanban continues to gain significant momentum and many organizations are easily applying both methodologies. One interesting application is Kanban for service/help desk. See Roland's excellent blog post for an example of this. We have personally assisted with enterprise-wide transformations this year, interestingly with medium-sized companies. Finally, I saw a Forrester Research statistic recently that puts the percentage of "ad hoc" agile adoptions at a whopping 50%, meaning that half of the companies adopting agile (or at least the ones Forrester surveyed) are not approaching agile adoption in a structured and disciplined way.

Okay, last but not the least, my XP 2.0 prediction fell way short, at least to my knowledge. Companies continue to struggle to adopt the high level of discipline that XP demands. While some of XP's tool-assisted techniques like continuous integration and automated testing are gaining traction, I do not see too many teams with a complete set of practices (see diagram from Don Wells' classic site: http://www.extremeprogramming.org).

In fact, I'm wondering how the Software Craftsmanship movement is doing. I hope it is gaining momentum -- anyone know?

So, all in all, I suppose 3 out of 4 ain't bad? As Neils Bohr said, "predictions are difficult to make, especially when they are about the future."

Happy Thanksgiving to our friends in the U.S.A.

Can Scrum and Kanban Coexist?

2010-11-18T22:39:00.005-05:00

Our LitheSpeed team just returned from the excellent Agile Development Practices East conference. It was nice to be able to connect with fellow agilistas while there. Along with Certified Product Owner training, we conducted several other sessions, including one on the Lean Principles behind Agile Methods.

In that that session, someone asked the question, "can we apply Scrum and Kanban on the same project?"

Before I provide my opinion, I wanted to check with folks out there -- what do you think? Do chime in with your comments.

Agile Alliance Board Reception in Falls Church, VA

2010-09-23T18:26:00.005-04:00

The new Board of Directors of the Agile Alliance invites Agilistas in the Washington, D.C. area to a reception to be held at the Westin Tyson's Corner Hotel in Falls Church, Virginia on Thursday September 30th from 6:30 PM to 9:00 PM.

Agile Alliance members and others are welcome to mingle with the new board, share h'ors' d'oeuvres, a glass of wine, and ideas!

Web: http://www.agilealliance.org/index.php/events/agile_alliance_board_reception/

Please RSVP: Contact: Gale Nies

Location:

The Westin Tysons Corner
7801 Leesburg Pike
Falls Church, VA 22043

Join us for the first annual Agile Tour DC conference

2010-09-19T15:03:00.002-04:00

Join us for the first Agile Tour DC on October 22, 2010. This one-day conference aims to serve agile practitioners in the Washington, DC area through the following 3 tracks:

Agile Essentials – Get the skills you need to get started.
Enterprise and Government Agility – See how it works in the large and hear from a Panel of practitioners working in government.
Open Talks – Create the conference you want in this Open Space (like) track. Don’t see a talk on one of the other two tracks? Propose one or attend one of the 4 concurrent Open Talks.

Learn more at http://agiledc.org/.

Speaking at Agile Development Practices East Conference

2010-09-10T20:28:00.004-04:00

I'm excited to announce that Roland Cuellar, Arlen Bankston and I will be speaking at the upcoming Better Software and Agile Development Practices East Conference, November 14-19, 2010 at the Rosen Centre in Orlando, FL.

To check out the program, visit http://www.sqe.com/AgileDevPracticesEast/

Register using special promo code SPAV and save up to $600 if you register by Super Early Bird September 17^thor up to $400 by Early Bird October 15^th.

Hope to see you there!

Decoupled Requirements Pipeline - Getting to ReadyBy David Bulkin

2010-08-20T19:22:00.005-04:00

I had the distinct pleasure of presenting at Agile2010 with Kevin Fisher of Nationwide Insurance. Our talk was about a sustainable process for discovery that makes it possible for a small "ready" team to mature requirements on a continual basis so that the requirements and specifications are appropriately ready for estimating and building.

Our belief is that you would never let anything out of an iteration that is not done, so you should never let anything into an iteration that is not ready.

At LitheSpeed we have helped teams implement this type of sustainable discovery for some time, and my colleague Arlen gave a similar presentation at Agile 2009, also with Kevin Fisher of Nationwide. This talk gets increasing levels of attention indicating that many teams are struggling with getting requirements and specifications mature enough prior to estimating and building.

Click here to download a copy of the Agile 2010 Presentation and help your team get to ready!

User Story versus Requirement and SpecificationBy David Bulkin

2010-08-20T18:32:00.015-04:00

In the agile community we focus heavily on user stories as a way of organizing our needs, but many make the false assumption that a user story, in itself, is sufficient as both a requirement and a specification.

The reality is that a user story is not a requirement, it is what helps you remember, organize and talk about a requirement. Taking this further, a requirement is not a specification, and you often need a specification prior to building.

What Constitutes an Agile Requirement?

A requirement is a user story, plus acceptance criteria, plus a conversation.

Generally speaking a requirement is enough information to make a point based estimate. This is often true even when the requirement is large grained (think epic or feature). But, a requirement is not sufficient information for most teams to start building. So prior to Sprint Planning there is a good chance you will need a specification.

What Constitutes an Agile Specification?

A specification is a requirement, plus additional supporting material as necessary, plus a conversation.

The determination of what supporting material is appropriate is highly dependent upon the team and the requirement. For example, a UI intensive application will often require one or two of:

concrete example (e.g. testable example)
wire frame
pixel perfect rendering
dependency list
interaction diagram (flow)
etc.

As you are thinking about the supporting material, try to create the minimal amount of supporting material in the lightest weight way, to provide the information the team needs. Remember, if a short conversation and a drawing on the back of a napkin is enough, don't create anything more (e.g. we don't want mini waterfalls with heavyweight documents).

How Does This Impact the Way We Work?

Generally speaking we find that far too many teams make estimates on user stories (without acceptance criteria) and then start building against requirements (without specifications). The result is poorly executed Sprints.

In most cases, you should have requirements ready prior to Release Planning (.e.g. prior to estimating) and have your specifications available prior to Sprint Planning (e.g. prior to building). If the requirement is simple enough, or the team is experienced / jelled enough, you can create the specification itself in the Sprint.

As always, I appreciate your feedback and input.

CSM Class in Gurgaon, India Next Week

2010-08-11T22:46:00.000-04:00

I'm looking forward to my CSM class in Gurgaon, India next week. Thanks to partners Xebia India for making it happen.

Hope to learn from participants about newer trends in management there like Vineet Nayar's Employees First, Customers Second. To quote Vineet,

"The time has come for chief executive officers to transform themselves into chief enabling officers who enable, encourage, and enthuse employees that are toiling in the value zone."

Sounds quite like agile management to me!

Agile Teams - Serving Many Masters?

2010-08-11T22:36:00.006-04:00

One Team with Many Projects

In many of the organizations where we consult, teams have a plethora of stakeholders to serve, each of whom has their own set of project requests, features, defect fixes, etc. The nice, simple model of “one team with one project” often does not apply.

Or to put it another way, agile teams must often serve many masters. Balancing out the needs of all of the stakeholders, getting good requirements from a variety of customers, and determining priorities across stakeholders are typically challenging. Even determining the one single voice who will speak on behalf of the stakeholder community can be difficult.

We get a lot of questions regarding the scope and timing of these and other product owner activities. Working with several clients on these topics recently, I thought that I would put out a few notes on the kind of structure and rhythm that seems to be working for us.

The Uber Product Owner or Chief Chaos Officer

Imagine a corporate website, either internal or external. Perhaps a single development team performs updates and maintenance to this website. But there may be many potential ‘product owners’ and it is not clear who is in charge. Marketing has stuff that it wants on the website, sales has entirely different stuff that it wants, various business units want their own stuff out there, HR has yet more stuff, and IT has its own stuff that it wants to do from a technical standpoint. Add to this that there may be a production support and operations team that has set maintenance windows for production update. Let’s say that the web team is allowed to make production drops once a month.

Each of these potential customers like marketing, sales, HR, etc may have their own projects and their own budgets and they would each engage the single team that is responsible for maintaining the website. And the team has fixed delivery windows when they can make updates so they may need to batch up several small projects into a single release.

In this environment, there may not be one clear product owner who really owns the corporate website. The website may be a shared communications resource that everyone uses and as such, there are many potential customers/stakeholders. Each of these stakeholders is also potentially a product owner for their own individual web projects. Yet someone needs to coordinate, prioritize, and trade off across all of these efforts and coordinate with the development team. Also, ideally, the team would want to engage with each of these potential product owners in a common way.

Enter the uber-product-owner or chief chaos officer. We often suggest that one person, and I pity that person, coordinate across all of the various customer product owners so that the team can coordinate, communicate, prioritize, and schedule across the entire portfolio of web project requests. This is basically a portfolio management function. And while many organizations have portfolio management systems, most are not aligned very well with the agile delivery cycle. (See our Cutter paper ‘The Agile PMO’)

No doubt some of you will say that the whole structure around the ownership of the website is wrong and I might agree. But the problem that I have laid out above is a very common one.

Regular Portfolio Review
We usually suggest that clients start with a monthly review of the overall demand portfolio. We suggest that the uber-product-owner herd all of the stakeholder cats together and lay out a timeline on a large whiteboard. We then write up each project request or major enhancement request on a card and start to put them on the timeline. Doing this, we can quickly lay out the major projects/features/efforts over the next N months. If we have some team velocity numbers and if we have early rough estimates of the projects/features from the teams, we can start to have discussions across the stakeholders regarding how much work can fit within a sprint. For example, if each sprint can hold 50 points of work, then this gives us a fixed capacity per sprint. This fixed capacity forces the various stakeholders/product owners to ‘negotiate’ amongst themselves about whose features are going to get done now and whose features are going to have to wait. THIS SHOULD NOT BE IT’s DECISION!

The business really should own the clear development and communication of project priorities and sequence. Having a bunch of business owners come in and dump a bunch of project requests on IT and then just telling IT to ‘figure it out’ is a major abdication of business leadership and responsibility in my opinion. I usually take this sort of behavior as an indication that the business owners themselves do not agree on the priorities and are just passing the buck.

Anyway, out of these lively portfolio discussions, we hopefully have clear objectives, clear priorities, and approximate timelines across the stakeholder community for the next several releases. We should now have a sequence of projects that makes sense to the business but is still in keeping with the team’s capacity. These priorities and timings should then be communicated broadly. And hopefully there should be no need to continuously revisit the priorities for at least for another month or so!! I would suggest setting these portfolio reviews up as regular recurring meetings and that you find a wall where this information can be permanently displayed to all.

Requirements Maturity
Now that we have the request priorities established across the portfolio of projects we can now delve into the details of each individual project or request. I would see our business analysts then getting in one-on-one sessions with each individual product owner that has any work coming up in the next several sprints. They would work together to nail down the requirements in good user-story format, work out user interface issues, develop acceptance criteria, discuss workflows, etc. In some cases, you might want to get a developer involved early to make sure that they are capturing the right info and addressing the right issues. For larger efforts, our BA and the product owners will need to be working several sprints in advance, getting requirements ready and to a decent state of maturity so that the requirements are ‘sprint-ready’.

As consultants, we have been seeing a lot of mediocre requirements lately. You really can’t give vague requirements to a team and expect good working software that meets your needs to come out in the first pass. Now you certainly can use agile’s iterative nature to discover the requirements but it may take several passes to get a feature just right. And of course our development team and our customers can work together in real time cycles of iterative requirements discussion within the sprint. We have no problem with any of these approaches. But it is problematic when a product owner gives vague requirements as inputs and yet expects perfect output every time. We can either spend the time up front developing better requirements or we can spend the team’s time discovering requirements. Unfortunately, there is still no free lunch. Our uber-product owners need to set appropriate expectations with the various stakeholders on how the process works and make sure that the project-specific product owners are aware of their responsibilities.

Sometime before the actual release planning, I would then have the uber-product-owner and the project-specific product owner engage with senior development team members to get their feedback on the requirements, scope, expectations, feasibility, etc so that we can make sure that there are no major issues before we go into release planning. If the developer identifies major gaps, we still have some time to do some additional research before release planning.

Release Planning
At release planning, we already have the priorities established and we already have at least some detailed requirements for each of the projects or enhancements in the release. Each product owner that has work slated for the release then presents the goals and the user stories to the team. The team estimates the stories and engages in Q&A with the product owner. We continue with this activity until we have filled the release up to capacity. Note that we may need to do estimation twice for each project/enhancement. We’ll need one rough estimate up-front for portfolio planning purposes and then here again prior to the release for a final and probably more accurate sanity check.

Execution
Now the release is underway. The uber-product-owner and the true product owners for the projects that are in this release need to continue to be available for Q&A and for interim review, testing, and feedback.

Repeat
With this release underway, the cycle then goes back up to the start again, reviewing the portfolio of projects again, adding in any new requests, re-prioritizing and re-scheduling with the stakeholders as necessary to prepare for the next release and the cycle starts again.

Most of the literature out there assumes “one project and one team” but we are finding that it is often the case that our teams need to support multiple projects from multiple stakeholders simultaneously. We can still manage to capacity and we can still have clear priorities across projects but we will need to take our planning and estimation and prioritization up a level in order to support these kinds of shared services teams.

Thanks,
Roland Cuellar

Mindmap: Challenges in implementing agile

2010-08-09T22:30:00.003-04:00

I don't have as much time as I'd like to (or had before) to browse the web and discover all the great stuff that's out there. However, now and then I do come across some real gems. Today, I came across an awesome mindmap that Siddhartha Govindraj from Silver Stripe Software put together at the Agile NCR conference in India.

Check out his Blog post here and mindmap here.

Thanks, Siddhartha for some great stuff like this!

CSM Training in sunny South Florida

2010-06-30T13:03:00.010-04:00

So, it's summer and all roads this summer seem to be leading to Florida. We'll be partnering with SoftKey to deliver a Certified ScrumMaster (CSM) class on July 20-21, 2010 in Pembroke Pines in sunny South Florida.

Hope you can join us for the class! You can register here.

Special Discounts for LitheSpeed CSM Training and BizConf Conference

2010-06-22T14:28:00.007-04:00

This August, LitheSpeed will be partnering with BizConf to deliver a Certified ScrumMaster course (CSM) on August 3-4, 2010 right before the conference. The conference is to be held on August 4-6, 2010. Both events will be held at the Ritz-Carlton, Amelia Island, North Florida.

If you'd like more information, including how to get a conference AND training discount, please contact Karen Falk at info@lithespeed.com. You can check out more details on the class here.

Here are the Top 5 reasons to join us for both the CSM class and the conference:

Develop your skill in hands-on workshops led by experts
Fewer attendees means you get more face time with speakers
Build relationships with industry leaders
Amazing Ritz-Carlton beachfront venue
Make it a long weekend and enjoy all that Florida has to offer

Looking forward to AgilePalooza DC

2010-06-09T10:51:00.005-04:00

Given the road warrior life of a consultant, presenting at home is always a distinct pleasure for me. Next week, Bob Payne and I will be presenting at Agile Palooza in the Washington, DC metro area. This is my first time at an Agile Palooza event, and I'm interested in seeing how the dual tracks work out: learning agility for newbies, and advancing agility for seasoned agilists. For the advanced folks, I'll be covering scaling agile up to the enterprise with agile portfolio management.

Version One is also offering a discount. From their announcement:

AgilePalooza is coming to the Washington, DC area June 18th!
Learn more and register at www.AgilePalooza.com/Washington2010.

Space is limited. Register now and save $20 with promo code VOne - that's only $69 for a full day agile conference including lunch!

What is it?
AgilePalooza is an agile community event taking place at the Tysons Corner Marriott. There are 2 tracks: Learning Agility and Advancing Agility. You get a full day of agile education from internationally recognized Agile coaches, trainers and industry leaders.

This event is about serious learning in a fun atmosphere.

Kanban for Service Desks

2010-06-06T22:21:00.006-04:00

We worked recently with a client who wanted to apply agile principles and practices to their help desk and networking operations teams. Below is a brief case study of the situation, the methods that we employed, and some of the results.

The Situation
There are two small teams, the help desk team and the network operations team, that work primarily in support functions. Each team has two kinds of work: some planned projects and a lot of unplanned support calls.

The help desk takes support calls for a huge variety of internal issues, everything from printers that need new toner cartridges, to email outages, to software upgrades and pc problems. The networking team supports the LAN, back-office hardware infrastructure, and software infrastructure. Planning and managing in these environments is extremely challenging due to the constantly changing issues, help requests, ever changing priorities, and lots of simultaneous efforts. No traditional plan would survive even a few hours in this environment.

In addition to the constant requests for support, these two teams have some traditional project work to deliver. Project examples might be email system upgrades, network upgrades, new hardware installs, etc. The project work needs to be estimated, budgeted, planned, and delivered like any project. Trying to deliver on project plans for the planned project work is highly difficult in this environment due to the interruptions coming from the constant support calls.

We had already helped the software development teams in this company move to agile/scrum processes and the management desired a similar approach for these two support teams.

Approaches
In a typical software development environment there is often a lot of planned development work combined with some unplanned support work. But here, the situation was reversed: a lot of unplannable support work with some planned project work. The idea of scrum with its time-boxed iterations didn’t seem like a natural fit. Help desk calls, network outages, etc don’t lend themselves naturally to well delineated, fixed-scope scrum iterations and a two-week delivery cycle on a network outage is nonsensical. While we probably could have made scrum work, we decided instead to take a kanban approach for these 2 teams.

What is Kanban?

Kanban transfers in even smaller buckets than scrum

In a traditional waterfall process, we use large batches and huge amounts of work-in-progress as the planning paradigm. We do all of the requirements elaboration, then all of the design, then all of the coding, then all of the testing. These huge batches typically take months to deliver.

Scrum uses much smaller sized buckets. In scrum, we break the transfer-batch size down to two-week chunks. We do a little bit of requirements analysis, a little bit of design, a little bit of development, and a little bit of testing in order to deliver a handful of features every few weeks. By reducing work-in-process (WIP) to these small 2-week sized buckets, we can greatly accelerate delivery of high priority features.

Kanban is yet a further step towards even smaller batch sizes and a move towards a more continuous flow. Kanban eliminates the whole idea of iterations or sprints. In kanban, like scrum, we work on highest priority items but when an item is done, we can deliver it immediately, sometimes within a day or even within hours! … very small buckets indeed! This seems like a perfect fit for help-desk and support work. Requests come in, we actively prioritize them, we focus on the highest priority items, and deliver fixes often within hours. Though continuous reprioritization and continuous delivery, we can create a highly responsive organization.

In scrum, we achieve fast delivery through short 2-week deadlines of fixed scope. So how do we ensure fast delivery in kanban? We use WIP limits instead. We leverage Little’s Law which says that cycle time is a function WIP. The more work-in-progress we have, the longer it takes to deliver any particular piece of work. If we want very fast delivery, we could have a WIP limit of 1 and ask that the whole team focus on only one help-desk ticket at a time. The result would probably be very fast delivery for this one item but a lot of help-desk tickets would go untouched. If we wanted to touch more help-desk tickets simultaneously, we could have a WIP limit of 20. This would mean that the team could focus on the highest priority 20 items at a time. In this scenario, 20 items would get some attention but overall delivery time would suffer since we are juggling so many simultaneous tasks. The trick in kanban, is to find a WIP limit that finds a balance between these two extremes.

Kanban doesn’t get into things like daily standups, retrospectives, etc so it is even less prescriptive than scrum. If you want some additional structure, you could borrow from both as we did.

Our Kanban Implementation
In the end, we decided upon a mixture of both scrum and kanban. We wanted the iteration-less, continuous flow nature of kanban but we needed some additional support mechanisms to facilitate communications and continuous improvement. Our resulting process utilized:
• Kanban with WIP limits of 8 (more of this later)
• Daily Standups (from scrum)
• Retrospectives (from scrum)
• Point estimates and Burndown charts for the planned project work (from scrum)
Or to put it another way, scrum without iterations.

Each team had 4 people on it and so we decided to try an initial WIP limit of 8 and this turned out to work pretty well. This means that each person could be working at most 2 items at a time. If one item was blocked for some reason, there was another item that each person could work on. The job of team leadership was to take all of the support requests each day and prioritize them into the top 8 items.

We enforced the WIP limit through our planning board. Our planning board has a column called EXECUTING that has a limit of 8. So no more than 8 cards can be present in this column at any one time.

Only a few items in EXECUTING but a lot in DONE!

Team members would meet each morning for a daily standup, review the priorities, and determine who is going to work on what. Periodically, we have retrospectives to see how the team is doing and where we can make improvements.

Realizations
First we set up a simple tracking board that had columns for backlog, WIP, and Done. We then asked the team to put all of the current work up on the wall. What we noticed was that there was a huge amount of work in WIP and only a few items in Done. Our goal was to turn that around. We instituted the WIP limit of 8 and within a few days, we had our WIP down to our target of 8 and we had many more items in Done! By limiting our WIP and focusing on the highest priority items, we were able to get much more work to an actual done state. And since these were the highest priority support items, we knew that we were delivering the most impactful work.

Working this way, we noticed that our team leadership needed to be more proactive about reviewing the work and assigning clear priorities. This became one of their primary functions. Daily standups have resulted in better visibility and cross-team communication, which the team has found valuable.

Finally, with this visual system in place, we noticed that our project work was falling behind. For actual planned projects such as email upgrades or hardware installs, we did typical scrum point estimates and release burndown charts. Tasks related to these projects were intermingled with the support tasks so that if there were no high-priority support-tasks, the team could focus on project work. After a few weeks, it was apparent that our project work was getting short-changed. So much time was going into support calls that there was little time left for the more strategic project work. While we had a lot of unplanned work in the Done column, and we were delivering outstanding support to our user community, our project burndowns showed that we were behind schedule for our planned projects. In other words, support work velocity was outstanding but project work velocity was falling short. Clearly, user support work was taking priority over more strategic projects. While we knew that this was probably the case, the board combined with the burndowns highlighted this problem clearly and showed quantitatively, how far we were behind on project work.

Next Steps
The obvious next step was to institute swim-lanes for the 2 kinds of work; planned project work and unplanned support work. We can keep the WIP limit of 8 since that is working well but divide it up into 2 parts. We can have a WIP limit of 6 for unplanned support work and a WIP limit of 2 for the planned project work. This means that we should always have 2 planned project tasks being executed at any particular time and this should allow us to start to make headway on the planned project work. Through experimentation with these 2 WIP limits, we can find a balance between delivering outstanding service and and delivering on the longer term strategic projects.

Team Feedback
Feedack from the team and management has been positive. The team reports having an improved system for managing support work, better visibility, and better clarity on priorities and WIP. Kanban is a deceptively simple but powerful system for visualizing and managing work. WIP limits force prioritization, focus, and delivery with minimal process overhead and high degrees of responsiveness. The kanban system has been a very natural way for these support teams to work that doesn't impose too much process overhead while still giving sufficient structure and visibility to managing the ever-changing priorities that are the nature of support work.

APLN Board Update

2010-05-15T15:32:00.004-04:00

It's been a pleasure for me to get involved with the Agile Project Leadership Network (APLN) after a hiatus of a few years. Several APLN chapters are doing well, and growing quite bit. The Houston and Bay APLN Chapters in particular seem to have the "secret sauce" in this area.

Some years ago, the APLN was setup as a network of chapters where agile leaders could connect, engage and learn from each other, and from experts in various agile disciplines. This year the APLN Board is emphasizing enterprise agility with a focus on agile leadership; the new vision statement is: Accelerate Agility: Connect and Engage to Transform your Enterprise.

Here's a Board update from co-presidents Jim Highsmith and Julie Chickering: http://www.apln.org/profiles/blogs/apln-board-update. Make sure you check it out at the APLN's spanking new Ning site: http://www.apln.org. Of course, no discussion about the APLN is complete without mentioning the Declaration of Interdependence.

Innovation Games® comes to Houston, TX

2010-05-10T10:32:00.004-04:00

The Innovation Games® technique is growing in popularity in the agile community as a way to improve business performance through collaborative and cooperative play. Pioneered by Luke Hohmann over the years, other experts are now offering Innovation Games training in various venues.

If you're in the Houston, TX area, or can make it there easily, don't miss Derek Wade's upcoming Innovation Games for Agile Teams workshop on May 18, 2010. Derek is a fellow APLN board member, and an accomplished team coach and trainer.

Gantt Charts for Agile?By David Bulkin

2010-04-24T13:29:00.009-04:00

Gantt Charts are commonly used to visually represent dependencies and progress against milestones and activities. They are often viewed as symptomatic of a top down, plan driven, control environment, and as such, they are looked at despairingly in the agile community. Although being called a GanttHead is an insult to an agile practitioner, I propose that agile initiatives can often benefit from traditional Gantt Charts.

Top Down Plan Etched in Stone

The use of Gantt Charts on software projects is a sorry history of creating a schedule, etching it in stone and then trying to bend reality to match an outdated schedule. No wonder the agile community hates Gantt Charts. But, there are times where a larger project, that includes agile software development as one component, can benefit from the use of Gantt Charts.

Example A: Developing and Delivering Training for a Large Call Center

Let’s assume your team is developing software for use by a large contact center (historically known as call centers). The call center uses your software to respond to prospect and customer questions on IRA’s and other personally funded retirement accounts. The contact center is incredibly busy from late January to late April (e.g. during the US Tax Season). During this time the staff works 60+ hour weeks.

Your team is doing the software development, but you are also going to be training the call center staff. There are a 150 of them, and you need to plan the training, several months in advance, to coincide with off-peak season, when most of the staff is working part time. The manuals need to be printed and delivered, the training rooms must be arranged, and the staff must be available during the heavy vacation period of the summer.

Common sense tells us that a traditional Gantt Chart, with clearly defined dependencies and dates, works well as a way to communicate among the various parties involved, track progress, and address changes in plan.

Example B: Rolling out new Laptops to a Distributed Sales Force on Your CRM Initiative

As another example, perhaps you are on a team delivering a new CRM Platform to your sales force. This sales force is distributed, but members of the sales team generally come into one of 12 regional offices once every couple of weeks. As part of the rollout you are upgrading the laptops for all 325 members of the sales force. There are some complexities, so you need to first choose a hardware / software platform that supports a handful of legacy applications that are in use, while meeting security standards, and then roll them out to the sales team.

Once again a traditional Gantt Chart, with clearly defined dependencies and dates, works well as a way to communicate among the various parties involved to track progress, and address changes in plan for this example.

In Closing: GanttCharts can be Beautiful

Gantt Charts make sense when you have to schedule date driven events, with true finish to start relationships (such as finishing training material before printing it).

I don’t propose that you use Gantt Charts to replace your card wall or your agile lifecycle management tool, I do propose that some of your work can benefit from a traditional approach of laying out dependencies and time lines visually to support planning, communication and making adjustments to schedules.

So, in closing, perhaps GanttHeads can be beautiful, and right!

Free Report: The Lean-Agile PMO

2010-04-11T21:44:00.001-04:00

Cutter is offering the report that Roland Cuellar and I wrote for free. Check it out here: http://www.cutter.com/offers/leanagile.html.

PODCAST: Agile PMO

2010-04-10T21:46:00.005-04:00

Some time ago, I was approached by Joseph Flahiff, who was interested in hearing details about how agile and waterfall combine on projects.

Our conversations led to the area of agile program and portfolio management. In particular, Joseph was very interested in the work we've done in setting up Agile PMOs to help with the light touch governance of agile projects. Joseph interviewed me for a podcast that I enjoyed quite a bit.

Here is the podcast: http://gallery.josephflahiff.com/podcast/sanjiv_augustine.mp3. Hope you find it useful. Do let me know what you think of it via the comments below.

COHAA Presents The Path to a·gil·i·ty

2010-04-05T17:58:00.002-04:00

The Central Ohio Agile Association (COHAA) is holding an exciting conference: The Path to a.gil.i.ty. Keynote speakers are Ken Schwaber and Michael Mah. Seems like a "must attend" for folks in Columbus and nearby cities.

"Steve the Contractor" - Applying Agile and Lean in the Construction Industry

2010-03-13T13:04:00.005-05:00

Over the past few years, we've been working in scaling agile to the enterprise with the help of Lean, and in particular the Agile PMO. We're seeing growing interest and adoption of these concept among companies that have being practicing agile for several years.

I personally have presented regularly on the subject at various fora, including PMI and APLN Chapter events and the Scrum Gathering.

Briefly, we believe that the work of senior managers on agile teams should involve:

Project identification and selection of new projects, and termination or re-purposing of existing projects;
Portfolio tracking of in-flight projects;
Resource management via the creation, care and feeding of stable, business platform teams; and
ROI and quality assurance of agile adoption.

These are admittedly tough practices to implement in any organization. So, it was a delightful surprise when I recently contracted with Steve D, the owner of a small contracting business based in the DC-Baltimore region. Steve started and finished on time, delivered high quality work and interestingly to me, worked with a very small team. In conversations, it became quite clear that Steve had both agile project management and some elements of agile portfolio management down pat.

Check out this interview with Steve to see what I'm talking about. I assure you you will find it delightful: http://www.youtube.com/watch?v=1_qWOHdi5aM.

The Role of the Manager on Agile Projects

2010-03-13T12:53:00.003-05:00

Okay, this might be another Ground Hog day type of post, but I wanted to pull together a few of my previous thoughts on the subject, and also indicate another one from the Scrum Alliance's site:

From an earlier posting, I believe the role of an agile manager is to lead project teams in creating and responding to change.
From my post on leadership versus management: leadership and management are both equally important. Without management, leadership falls victim to complexity. Without leadership, management loses its soul.
From an excellent article by Lyssa Adkins and Michael Spayd, the manager's role in Agile involves managing teams, managing investments and managing the organization's environment.

Agilists Don't Get the Enterprise View?

2010-03-13T12:39:00.005-05:00

Every now and then, a viewpoint arises that the agile community just doesn't understand the reality in large companies. From my post to the PMI Agile CoP discussion list:

I can empathize with your frustration, having faced such challenges and myopia in certain circles. For example, there’s been an ongoing dialog about the role of management on self-organizing teams. See my Blog post http://lithespeed.blogspot.com/2009/11/self-organization-self-discipline-light.html for my own perspective. Wayne — I would echo Brad’s sentiment that you are not alone. There are several of us who have spent the last decade helping bring agility to large, mainstream companies. I would think that is why (at least in part) large, mainstream companies are going agile in an increasing way.

I also think it’s good to vent, so that we can hear what folks are really thinking out there and engage each other in productive discussion. However, I would caution against sweeping negative generalizations of any community: APLN, Scrum or the PMI. As someone engaged fairly closely with all three (Co-founder and current VP of the APLN, active CST, and Member, PMI CoP), I think folks in all the named organizations are making sincere and effective moves to take agile mainstream. I also believe that they are all sincerely working towards a pragmatic view of agility, albeit from their own frames of reference. Here are some anecdotes that should support my contention:

The CEO of the PMI was the keynote speaker at last year’s U.S Scrum Gathering. Close to half the attendees at that Scrum Gathering (as judged by a show of hands requested by Mr. Balestrero) were PMPs.
Personally, I have never seen or experienced the naïveté allude to at the APLN — either on the Board or at any of the chapters at which I regularly present. My present and past colleagues at the APLN: Jim Highsmith, Pollyanna Pixton, Bob Wysocki, Susan Fotajek, Kent McDonald and Todd Little to name a few, are all grappling with the same challenges you raise and take a very similar enterprise view as I do.
I have presented the same Agile PMO session that addresses governance and program management at the APLN (see http://www.aplnhouston.org/), the PMI (see http://www.pmiwdc.org/careerday2009-education#Sanjiv_Augustine) and the Scrum Gathering ( http://www.scrumalliance.org/events/105-orlando-scrum-gathering). Interestingly, I received very similar positive feedback from all 3 audiences.

While there are some voices in the agile community whose opinions might not hold sway in today’s corporate circles, I would respectfully request that we be careful not to paint everyone with the same brush. At the same time, I would also point out that these views are what move us to improve and get better as a whole even if we find them controversial today. For instance, we might question a Scrum industry leader’s belief that a self-empowered team should be allowed to select its own membership. Yet, in fact, that is exactly the norm at Whole Foods Corporation (From http://money.cnn.com/2007/09/26/news/companies/management_hamel.fortune/index.htm, “the underlying logic is powerful if unconventional: Whole Foods believes that critical decisions, such as whom to hire, should be made by those who will be most directly impacted by the consequences of those decisions”).

Thanks again for some thought provoking comments, and I think it is through this sort of exchange that the next advances in agile management will arise.

Outcomes = Testable Goals By David Bulkin

2010-02-06T20:50:00.004-05:00

This post fleshes out one aspect of my recent post on a requirements breakdown structure, giving examples of how to define goals as testable outcomes.

In my next post on this subject I will cover the context of why we want to use outcomes like this, when they are created, and by whom.

Goals Cascade Down from the Vision

At the top the requirements breakdown structure, defined in my previous post, and repeated here for clarity, is a vision, which is a strategic direction in which the organization wants to move. Meeting the vision could take the successful execution of many projects, executed on over many years. Each of these projects needs one or more defined goals, and that is where outcomes help.

Outcomes are Testable Goals

So, if our vision was…
Be the eBanking Provider of choice for small business customers

Then, we could have the following for an outcome.
Increase retention of small business eBanking customers by 20%.

Providing the Test

As you get closer to point where the rubber meets the road, you will want to get more specific about the outcome, ideally piggybacking off of an already existing reporting mechanism, and using something like the following.

Increase retention of small business eBanking customers by 20% as measured by the Customer Retention by Segment and Time Report from the business intelligence dashboard.

A similar outcome based on acquisition could be as follows.

Increase the acquisition of new small business eBanking customers, so that we gain 80,000 new small business eBanking customers in a one year period as measured by the Customer Acquisition by Segment and Time Report from the business intelligence dashboard.

More Examples

Here are a few more examples of goals expressed as outcomes with measures.

In 18 months, decrease Total Cost of Ownership of our web systems by 25% as measured by …

In six months, decrease the error rate on data provided to our top client, XYZ Corp, by 35%, ensuring rate is never > 1.25%, as measured by the error report file summary statistics they send weekly.

In three months, decrease the time it takes to perform a release to three hours (3 months to 3 hours) as measured by the time ops starts the process to when the site is live to the customer.

Closing

This post covered “how” to create testable goals. In my next post on this subject I will cover the context of why we want to use outcomes like this, when they are created, and by whom.

Until then, please send along your comments and questions, and, of course, your samples.

Self Organization Rules! By David Bulkin

2010-01-31T13:41:00.012-05:00

The concept of self organization for agile teams is frequently discussed, with one excellent take being this from my colleague Sanjiv Augustine (which focuses on the question of whether agile teams need traditional management and how to apply light touch leadership).

This post focuses on simple practical rules (you may call them practices) for self organization. Every team is different, so these are just samples but I believe they provide a practical perspective that I have not seen enough of (please comment if there are other posts that provide practical guidance on self organization).

Sample Rules (or Practices)

As a team member, I will contact the ScrumMaster if we can tweak a user story, to maintain its business value, while reducing time, cost or risk associated with implementing that user story.
As a team member, when I complete my work, on a task, I will either help another team member, or start a new task, depending on what will most likely allow us to deliver the maximum value in a Sprint.
As a team member, I will provide honest and open feedback to my peers, to the ScrumMaster, to the Product Owner, and all team members, whenever that feedback will help the performance of the team, even when I feel uncomfortable doing so.
As an agile team, we will define and continually refine rules and practices and use them to guide us in our work.

In Closing

Hopefully this short post was of value to you and your team. As a reminder, other than number four, these rules are just samples, so have fun creating your own and write back to tell us what they are and how they are working. Also comment if you have seen other blog posts that cover practical rules for self organization on an agile team.

Agile Requirements Breakdown Structure by David Bulkin

2010-01-31T13:13:00.019-05:00

In agile when we talk about requirements, we often talk about epics, features and user stories.

But, do we really know how these different levels of requirements fit together, and how they relate to vision, goals and outcomes?

This post provides a simple example of what a requirements breakdown can look like. This is nothing new and is similar to a functional breakdown structure, or product oriented work breakdown structure that has been used since I started my career over 25 years ago.

An Example

It Starts with a Vision

At the top of the hierarchy is a vision. The vision is broad in scope and addressing it can take many years and many projects. In this example, our vision is:

Be the eBanking Provider of choice for small business customers

Goals, or if you like, Outcomes

To address our vision we have goals, or if you like outcomes (more below). In this example, the goal / outcome is:

Increase retention on eBanking Website

You could make this more concrete, and thus turn it into an outcome, by including a measurement, stating something like:

Increase retention of small business eBanking customers by 20% as measured by…

Epics, Cohesive, Large Chunks of Business Value

Below the goals we have epics, which are large grained chunks of business value, that, by definition, will take more than on iteration to complete. In fact, epics can be so large that they may take several releases to complete. In this example, the epic is:

Add a Customer Center for self service for common needs

Note that even though this is an epic, you could still write it in user story format, perhaps like this:

As a customer
I want to handle my self service needs online
So that I can address them 24 by 7 by 365 without leaving the house or making a call

Features, Cohesive, but Smaller Chunks of Business Value

At the next level down are features, which in this model, are cohesive chunks that address a particular need. In this model, features are smaller than epics and it often possible to complete a feature in a single release or even in one iteration. In this case our feature is..

As a customer find a branch location

The Stories

At the lowest level of the hierarchy are the actual stories. In this example the stories were split from the “find a branch” feature. Here is one.

As a customer
find a branch that is close to a specific address
so that I can minimize travel

In real life there would likely be similar stories, such as finding a branch by hours of operation, or by zip code.

In Closing

There are number of variations on decomposition for requirements, and although this example is not comprehensive, I think a picture is worth a 1,000 words.

You can also check out other blogs that cover similar topics. Dean Leffingwell covered this in a comprehensive white paper you can get from his site.

Drew Jemilo’s blog specifies a very similar take. I would have never have found it if I hadn’t talked to him a couple of months back, so check it out at his blog.

Enjoy.

Agile in the DOD By Roland Cuellar

2009-11-23T11:25:00.008-05:00

I recently went to a presentation by Don Johnson, Advisor to the Defense Sciences Task Force on Acquisition of Information Technology within the DOD. This group has been investigating how to speed up and lean out the acquisition process within the DOD for some time now and they have a new report out with their recommendations. The task force is recommending that the DOD take an Agile approach and furthermore, they have asked for and have received congressional approval to begin piloting the use of Agile in the procurement of large DOD systems! Some of the reasons for this move towards agile are:

The current technology acquisition process was designed decades ago and is no longer suitable for the rapid pace of change that is required to design, develop, and deploy latest technology solutions to the field.
The current process is designed for and better suited towards large platforms such as ships and planes than for software intensive systems.
The USA has a declining software development pipeline. The number of American citizen college graduates in the technology fields is shrinking. Finding clearable employees is getting more and more difficult. Therefore, we need processes that make us significantly more productive. It is likely that we will need to produce far more software with fewer resources.
In 1970, IT accounted for only about 20% of weapon system functionality. Today, it sometimes accounts for as much as 90% of weapon system functionality.
The current acquisition and development process has an average delivery time of 91 months!

For these and other reasons, congress has granted the DOD the authority to modify the current acquisition and development process for up to 10 large systems annually to utilize an Agile approach and the DOD will update congress annually on the results of the new process. The new process will feature Scrum-like iterations, early and frequent delivery of working software,and some degree of requirements flexibility.

This is an exciting time for us in the Agile community as the DOD recognizes the success that Agile has had in the commercial marketplace. But the DOD's adoption of Agile will also bring extraordinary challenges. The scale and complexity of modern defense systems will certainly tax our existing methods. However, I am sure that working together, we can improve significantly on the current process.

Write to us here at LitheSpeed using the 'comments' link below if you would like to get a copy of the DOD slides on this topic.

Don't Forget the Storming

2009-11-23T11:10:00.003-05:00

Our good friend and agile champion, Sean Buck, recently wrote an outstanding article on the 'storming' phase of team maturation. He has kindly allowed us to share it with you.

Building Teams - Don't skip the "Storming"

By Sean Buck, 2009

A lot of you may be familiar with the Forming - Storming - Norming -Performing stages of a team. It has been around quite awhile, almost 45 years actually. It's also referred to as Tuckman's Stages, since it was first brought to us by a psychologist named Bruce Tuckman. Something I have observed and found interesting is that there are a lot of people that don't embrace the Storming so much. Maybe because there are many personalities that would rather avoid conflict. I have even observed instances within the organization where some members would rather take things "off-line" or may possibly exhibit a passive aggresive behavior by agreeing with something in a meeting, yet disagreeing and not supporting it outside of that meeting. In my humble opinion the Storming stage of building a team is one of the most important steps that does need to happen to becoming a Performing team, and needs to be properly facilitated and supported by leaders. It's needed to build trust and comraderie, which are crucial traits of a high performing team. I would like to share a brief story on how the United States Marine Corps embraces storming, and some tips on supporting a positive environment for Storming within the organization and just the corporate environment in general.

Storming in the USMC - What I learned in 3 days that will last me a lifetime

As a Sergeant in the USMC, I understood the importance of teamwork. The teamwork concept is so crucial to how we operate and execute. So much so, that teamwork is a focus from day 1. When you arrive at bootcamp the first thing they do is shave your head, and throw you into a camoflauge uniform. This is symbolic of stripping away your individuality. Not that individuality is not valued in the USMC, but it's overvalued in the civilian world. You even don't have a name and can no longer say "I" or "me" You are required to refer to your self in the third person. When addressing a Drill Instructor, you can't say "I have a question" It's "Sir, this recruit has a question, sir" From day one everything we do is done as a team. And throughout training storming will occur. The USMC forces Storming in a final event leading up to graduation called the crucible.

The Crucible

Back in the 90's I had the luxury of being in one of the first platoons through a newly created event called the crucible. Although it has probably changed over the years, for me it was 3 days and nights of one of the most challenging experiences I have faced. Throughout the course of the 3 days, our platoon had marched over 60 miles in full combat gear (about 75 lbs on your back), we had about an hour of sleep per night, and less than one meal per day. In the middle of all that, there were obstacle courses of over 60 different missions that required our 6 person team to be working as a team to complete. Things like scaling a 15 foot high wall as a team with no rope, trying to get to the other side of a bridge damaged by an explosion, getting down from a series of platforms simulating a four story building blown in half (there are no stairs on your half.) All things we could possibly experience in combat. The crucible was our last event, or challenge if you will. It was the pinnacle of our training that ended in our transormation into Marines. After this event we were called Marines instead of recruits.

The Storming Part

Anyone ever been cranky after skipping breakfast, or getting an hour less sleep at night? Imagine what we were going through from a stress perspective with basically no sleep and no food, physically exhausted from marching, and then being asked to complete these missions as a team. When we first started on day 1, we were accomplishing missions ok. We were divided into newly formed teams of people we probably hadn't worked with before. After all the exhaustion, crankiness, and stress started to settle in, things got ugly. We were yelling, arguing, fighting (physically), and pretty much hated each others guts, and obviously failing at all of our missions. The Drill Instructor assigned to our team just watched, sometimes laughing at us, but let us carry on. After awhile he then explained to us that what we were going through is absolutely normal. That teams normally go through a period of storming, however due to our lack of sleep, lack of food, and exhaustion that everything was amplified.

Now The Norming and Performing

It didn't take long after he put things in perspective for us, that we started to see what was going on. We even started joking about some of the stupid things we were doing and started to bond. Funny thing happened is that as time went on, we had less food, less sleep, and more exhaustion but yet were accomplishing our missions with greater ease and we were seeing the difference. Our productivity and performance was night and day after experiencing our storming. That's not to say that we didn't have our arguments throughout the rest of the crucible. But they were more constructive and actually lead to greater results. Because we learned how to properly storm, when not to cross the line, and how to control our emotions by recognizing stress was changing our rational thought. I still remember that event to this day. Not from all the blisters and pain. Not from the ceremony in front of an Iwo Jima monument - where our platoon of beaten down recruits were handed an Eagle, Globe, an Anchor (USMC logo) and called Marines by our Drill Instructors. But I remember that event because I think I finally learned and figured out what a team was. That it was more than a group of people. In 3 days I saw with my own eyes and was part of a transormation that lead me to believe that the saying that "the whole of a team is greater than the sum of it's parts" was not just a bunch of BS. And I truly believe and see how the storming was necessary step for us to understand how to work with each other to perform.

I wanted to share that story as an extreme example of Storming, but to drive the point that it is necessary. It can't be skipped over. Well, it can, but your team will not reach it's full potential, and in my eyes won't be a team unless they go through that stage. Passive aggresive behavior is detrimental to a healthy team.

How I Embrace Storming Today - Tips:

It doesn't always happen, but the first thing I try to do when forming a team is talk about storming and "constructive arguments" with my team. And that I feel it is a necessary component and completely normal thing for us to go through. I also let my team know that I expect them to challenge me and my thoughts and ideas. That they should feel comfortable engaging in a "lively discussion" with me and not just always agree with what I say. I do outline rules of maintaining professionalism but encourage lively discussion. No insulting anyones thoughts or ideas. Challenging is ok. Absolutely no personal attacks or insults are tolerated. Another rule is that the storming phase of a team does stay within a team, and people should feel comfortable to solve their problems and talk them through with team members. As a leader you are a facilitator, but when it comes to 2 people not getting along, they are the only ones that can resolve that. In the USMC we used to make 2 people having difficulties with each other go dig ditches together for hours. They might be upset at first, but eventually figure out they need to work together, find some common ground and start talking. I've experienced this myself, and even observed some people becoming best of friends after such an event. When a lively discussion is taking place sometimes I joke about us storming to ease tension but also recognize that we are exhibiting healthy team behavior. When I see someone biting their tongue, I encourage them to talk and voice their opinion. Otherwise, they will go voice their opinion to someone outside of the team and start anti-team behavior. Always keep an eye on things, when you get passionate people together with strong convictions, chances are sometimes lines will be crossed. Call timeout on such events and follow up with the individuals to address problems and concerns. Never reprimand someone in front of the team. Know your own limits. It's innevitiable if you are a strong, passionate leader that you will sometimes not just facilitate but will get involved. In many cases, I have found myself needing to take a step back from a discussion. Others thoughts or feedback? Feel free to storm with me if you disagree.

Sean Buck

Is it Groundhog Day? Thoughts on Self Organization, Self-Discipline & Light Touch LeadershipBy Sanjiv Augustine

2009-11-13T15:23:00.031-05:00

In the movie, Groundhog Day, the central theme revolves around the protagonist reliving February 2 over and over again. In doing so, he uses the knowledge to improve himself, and of course, to move the film towards a happy Hollywood ending.

A couple of years ago, Jim Highsmith's Cutter Advisory on self organization, No More Self Organizing Teams, resulted in a passionate response from Tobias Mayer (and others). I responded via this Blog post.

In the time since, I've encountered this debate regularly on various user groups. Do agile teams need project managers or ScrumMasters; or can they simply self-organize? I've come to realize that it is one of those groundhog day type questions that keeps getting asked over and over again. I think the question is repeated because someone in one camp or the other doesn't really like the answer they've been given. And so they ask the question again in hopes of getting and an answer closer to one they like.

In the hopes of improving myself, and moving towards a happy ending to this story, I'm reposting my response below. I've taken the liberty to update it slightly for readability:

This is a discussion that gets to the essence of Agile methods. Both Jim’s and Tobias’ posts are impassioned and display remarkable shared concern for preserving the hard-won value wrought by Agile methods in tough environments. But there’s also a difference, that though barely perceptible, reveals a divide to those familiar with the territory. The dividing line becomes clearer when one reads the follow up messages — the line faults along manager and non-manager.

To managers, this is about something very, very fundamental. Managers are interested in understanding how to add value on Agile teams and discover the best value-adding role for them on Agile projects. So, to my mind this is really about the role of the manager on the Agile team. See my Blog post on this topic here:http://lithespeed.blogspot.com/2007/09/agile-project-management-role-of.html

Agile methods have been great about defining how developers can add value. With the product owner role becoming more solidly defined in Scrum, business analysts can jump on board as well as product owners or product owner proxies. But what about managers, and testers (anyone remember those guys who used to show up with reams full of defect listings?). And how about user interface designers (users do like those cool interfaces and design is an increasingly sought-after specialization), production specialists (maintaining production environments that are reliable and secure is an expert skill), etc.

The truth is that, as Agile methods are successfully making the transition into the mainstream, they are being quietly adapted to fit into large, complex organizations. Very few adoptions of Agile in these organization go exactly "by the book." Work in large, complex organizations tends to flow across organizational silos. Significant strides have been made in creating integrated teams that collapse some organizational silos. On these teams, costly hand-offs have been eliminated or at least reduced. But, the prevailing reality is that, in most organizations organizational silos with division of labor exist in some shape or form. And in most large organizations, those silos are also represented on Agile projects. Therein, I think, lies the core issue. Can division of labor be completely eliminated from Agile projects and teams?

Most managers, I believe, will take the pragmatic view, press for an integrated team, and then manage work across said silos. Others will hold that the organizational structure itself is flawed, and therefore needs to be completely replaced. Rid organizations of the scourge of division of labor, move to completely integrated teams, adopt a craft model, and everything will be solved, they hold. Managers — at least those not appointed by the team — will then not be necessary, they believe. Perhaps. But, as long as organizational silos exist, some division of labor is necessary for effective functioning, and these discussions will continue.

As for leadership, it’s like mom-and-apple-pie. Everyone seems to agree that leadership is a good thing, don’t they? Though how that leadership is appointed, sanctioned or manifested is the subject of debate, I think we all agree that leadership is a good thing on Agile teams.

My own position is that, if we can find ways to reduce non-value added management work caused by the reality of organizational silos (via Lean Kanban systems, etc), we can then all — managers and non-managers alike — get down to the important business of figuring how to lead our Agile teams. Until then, having a role that addresses the management work is simply a necessity.

To that end, Light Touch Leadership, as Jim articulates, is a great way for managers to lead Agile teams in a way that is completely congruent with the Agile value system, but that also acknowledges the reality of organizational silos and division of labor in most organizations.

I think there is definitely a place for a value-adding Light Touch role on agile teams. Light Touch is about managing agile teams with a style that allows team autonomy and flexibility, and a customer value focus without sacrificing control.To learn more about what I deem Light Touch management, go here: http://www.informit.com/articles/article.aspx?p=390811.

What do you think? Do we need project managers and/or ScrumMasters on agile teams? Please chime in!

The Agile Word Association GameBy David Bulkin

2009-10-30T13:58:00.060-04:00

#	Term	Possible Association
1	ATDD	Bad
2	Backlog	Coordinate
3	Daily Standup / Daily Scrum	Design
4	Product Owner	Facilitate Collaboration
5	ScrumMaster	Iteration
6	Sprint	Specify
7	TDD	To Do List
8	WIP	Tradeoff

We are about to play word association game. This is a game, not a test, so the purpose is to provoke thought, not define the exact meaning of each term.

Given the list of the words on the left, find the most appropriate match on the right. Remember that this is a game, so, even though both “ATDD” and “TDD” are listed on the left, you won’t find “Testing” anywhere on the right. If it were that easy, it wouldn’t be fun or informative!

The Associations

ATDD = Specify

Oh, you thought ATDD / Acceptance Test Driven Development was about testing.

In fact, ATDD is at least as much about specification as it is about testing. With ATDD, Product Owners, Business Analysts, Testers, Developers and other stakeholders use a common language to concretely define examples that specify the expected behavior of a system.

The concrete examples are created before the code, and when specified in a format compatible with one or more testing frameworks, like Fit or Cucumber, they can serve as executable specifications (once the supporting fixtures are coded).

With ATDD, external dependencies are often mocked or stubbed, making it possible to verify that functionality meets the specifications, but not necessarily proving that the system works in an end to end fashion. As such, despite its’ name, ATDD does not replace integration testing, but it sure does make it a whole lot easier to specify expected behavior in a way that can truly be understood by all, hence, ATDD = Specify.

Backlog = To Do List

At its’ simplest, your Product Backlog is a prioritized To-Do List with estimates. Your Iteration Backlog is your short term to do list. Doesn’t sound very technical, but that’s what they are.

Daily Standup / Daily Scrum = Coordinate

Traditional project teams focus their status meetings on providing information to the manager, who then makes all of the decisions. Agile teams answers three questions so that team members can commit to each other and self manage. The questions are:

What did I do since the last stand-up?
What will I do before the next standup?
What blockers do I have?

You should answer these questions succinctly, deferring details until the post meetings (which I call the “Daily Sit-Downs”) so that just the information necessary for the team to coordinate, and hence, self manage, is covered.

Product Owner = Trade-offs

We all know that the key responsibility of the Product Owner is maximizing the business value of the system that is developed. But, how much fun would it be if "business value" was on the list?

More importantly, when I think about how the Product Owner maximizes values, I think of at least two key things, conveying the information that the team needs, and making trade-offs decisions. I emphasize the trade-off decisions in this post, as in my experience, this aspect of the Product Owner role is sometimes not given enough emphasis, so, at least for this post, Product Owner = Trade-offs.

ScrumMaster = Facilitate Collaboration

There are many attributes of the ScrumMaster role. At the core, the ScrumMaster ensures that the process is being followed. So, I guess I could have said, ScrumMaster = Ensure Process is Followed, but, remember this is a game, not a test, so I want you to think.

In thinking about the ScrumMaster role, my experience has shown that it is easier for novice ScrumMaster's to grasp the process, but far more difficult to understand how to facilitate the self managing aspects of the team.

As such, in this post, ScrumMaster = Facilitate Collaboration.

Sprint = Iteration

A textbook definition of sprint (outside the world of agile), as given by Wikipedia is a type of short race in athletics.

When I co-train with Sanjiv Augustine he likes to point out that racing is not an appropriate metaphor for executing with a sustainable pace. I agree, and I prefer Iteration to Sprint.

TDD = Design

TDD, or Test Driven Development, is an approach where a developer, or pair, write a test prior to writing just enough code to pass the test. The tests are automated, and they are constantly run, to ensure that code changes work and that they don't have unintended consequences.

OK, you may ask, then why do I equate TDD with design? As with ATDD, TDD much more than testing.

Most hard core devotees of TDD will tell you that the act of writing the test prior to writing the code is an easy and cost effective way to create simple, clean, loosely coupled, highly cohesive, i.e., well designed, code.

Hence, TDD = Design!

WIP = Bad

Work in Process, a.k.a. WIP, is the partially completed deliverables. There will also be some unfinished work in a system, but complexity quickly expands as the amount of WIP increases, so, WIP = Bad.

Answer Key Summary

#	Term	Association
1	ATDD	Specify
2	Backlog	To Do List
3	Daily Standup / Daily Scrum	Co-ordinate
4	Product Owner	Tradeoffs
5	ScrumMaster	Facilitate Collaboration
6	Sprint	Iteration
7	TDD	Design
8	WIP	Bad

Closing

There are many equally valid, and in fact more valid associations than the ones I listed, but this was a game, not a test, with the intent of provoking us to think. Please feel free to provoke me, and all readers of this blog by providing your feedback.

Death by Team Room, or Teamroom-A-CideDavid Bulkin

2009-10-29T15:06:00.028-04:00

Agile teams are often co-located with all team members sitting in one physical room. The rooms are often spacious, with ample natural light, an effective layout, nearby private space, etc., and, as a result, productivity is high.

But, there is an anti-pattern; productivity-robbing team rooms that please no one (OK, maybe the cost accountants are happy).

A Good Team Room

Let’s start with a quick look at some attributes of good team rooms.

Ample storage for personal possessions in cabinets and cubbies.
Ample space for team members to comfortably stretch out.
Nearby private space, often called caves, for private calls, deep thinking or collaborative work between two or three people.
White boards, tack boards and other mechanisms that support big visible charts.
Natural light / windows.
Ample ventilation.
Large screen monitors to support collaboration.
Full size keyboards to support ergonomics.

Team Room Anti-Patterns

Sometimes agile team rooms are designed from inception into new floor plans, or as a well thought out redesign to an existing floor plan. In other cases, team rooms are put together with little focus on productivity.

Perhaps a cost conscious company is focusing on square foot per person (an example of metrics misuse).
Maybe a manager just has no place to put a new team.
Or worse yet, perhaps a manager mistakenly believes that packing everyone together will result in increases in productivity, irrespective of the conditions (a belief in agile magic).

The instantaneous conference room conversion, a.k.a., ICRC

Let’s look at one near worst-case scenario, the instantaneous conference room conversion, a.k.a., ICRC. With an ICRC, existing employees re-locate from their cubes or offices to a conference room, often joined by new staff members (consultants or new employees).

Let's look at a theoretical, but all too common, example of an ICRC Anti-Pattern:

In our example a team of 18, eight existing employees, two new hires, and eight consultants, are packed into the conference room (hey, why not, 20 people can sit there for a meeting).

This conference room, like many, has good ventilation and natural light. Additionally there is ample white board space upfront.

On the other hand, there is no tack board or magnetic boards for cards, so one on wheels is brought in, which takes up just enough space to make it difficult for those sitting in front of the board to get in and out of their chairs. When people come by during the day to look at cards, it is a tight fit, which sometimes results in a few spilled cups of coffee.

Power and network connectivity is available only at the two ends of the room so long wires are dangerously snaked throughout the room.

There is no place for private stuff so team members place their personal possessions under the table and in the desks of friends who are located elsewhere.

Many of the team members used to use separate full size keyboards and an external monitor, but with the reduced space, ergonomics is a luxury that can’t be afforded.

Taking personal calls now requires a hike to the lobby area or outside, the most private spaces still available for the team. Conference calls are conducted several times a week in the room, and although collaboration is important, it is rare that all 18 team members are required for a call, but they really have no option other than listening.

The Productivity-Robbing Result

As a result, our team experiences a significant increase in stress. They also experience minor injuries like tweaked backs from leaning at odd angles, carpal tunnel syndrome from typing on a poor laptop keyboard and eyestrain. No surprise, illness is also passed around quite rapidly.

Productivity is low to non-existent, and 18 team members produce output that a team of four could easily create.

Management eventually notices, and mercifully, the team is disbanded. Unfortunately, this was the first agile project, and the entire transition to agile is canceled based on the poor results of this one effort. Apparently no one in management seems to understand just how detrimental the poorly designed team room was.

Conclusion

Despite what the above scenario may lead you to believe, I am an advocate for team rooms, assuming they fit the needs of the team, are designed by the team, and provide basics like ample space, ventilation, light, windows, ergonomics, storage, nearby private areas, etc.

But, as extreme as the above scenario seems, truth is often, stranger, and worse, than fiction. I had to make the scenario sound plausible so I couldn't use the real examples I have seen (you wouldn't have believed them)! As agile usage continues to grow, and as companies continue to face tough economic realities, anti-patterns like the Instantaneous Conference Room Conversion will likely occur more and more frequently.

As agilists, we have to dispel the notion co-location equals agility. We also need to accept the fact that if the space isn’t available, perhaps it may be better to:

Delay the project start until space becomes available for an appropriate team room.
Form a smaller team. Perhaps a productive team of five is better than 18 non-productive members.
Not execute the project at all.
Execute the project without co-locating the whole team in one room! Yes, old fashion cubes and offices can be better than a poorly designed team room.

Please respond with your thoughts and experiences.

Chickens, Chigs, Pigs and PigletsBy David Bulkin

2009-10-04T19:57:00.019-04:00

Although many don’t like it, all agilists are familiar with the chicken and pig joke that explains that pigs are committed to success, while chickens are at best involved. As we continue to move to larger scale enterprise agile, we can benefit from understanding varying levels of participation and commitment. As such, I use terms like piglets and chigs to describe patterns and anti-patterns of team participation and commitment.

Piglets are part time participants that view their role as making a project successful, and act accordingly, despite their part time participation.

Chigs on the other hand, are individuals who look and act like chickens, but whom should really be pigs or piglets. Chigs are often worse then chickens as they frequently focus on finding problems and derailing the project instead of helping the project succeed.

Looking more Closely at Piglets

Long before Scrum became popular, there were concepts like being a member of a Core Team (think pig) or an Extended Team (think chicken). Over the years, many organizations have benefited from another concept; an Extended Core Team (think piglet).

Extended Core Team Members work part time on a project, but they are committed to success. They focus on finding solutions, not poking holes. They are only successful when the projects they are on are successful. To make this delineation clear in the agile community, I have often used the term piglets to describe Extended Core Team Members.

A Typical Anti-Pattern, Security Engineer as Chig

The evil inverse of a piglet is a chig. For example, let’s assume you are developing a new application in a high security environment. Your team works hard to understand the complex security infrastructure, but the custom services for authentication, authorization, and file transfer, along with multiple dependencies on other teams, makes it difficult to get clarity on how to proceed.

Unfortunately, Chuck, let’s call him Chuck the Chig, is the Security Engineer assigned, part time, to your team. The part time nature of his assignment is a problem, but even worse, he is simply not concerned about your project’s success.

Chuck the Chig views his role as telling you why your system can’t go live, without giving you solutions. Here’s a sample conversation that you may have with Chuck the Chig or other chigs like him.

You: How does our app look from a security perspective?

Chuck the Chig: Not good, I don’t like the authorization mechanism. I will have time in two months to review this again after you fix it.

You: But, as you know, we are due to go live in six weeks, and you have had access to everything since day one. Can you give me a specific recommendation and work with us to fix the problem?

Chuck the Chig: You don’t seem to understand my role. As a Security Engineer, I can tell you what is wrong, but I can’t tell you what to do. You have the detailed, 218 page, document that describes valid protocols and how to leverage our security infrastructure. Read it, fix the app, and when I have time in six weeks, I will check to see if you have done it correctly.

Even worse, Chuck the Chig goes back to his peers, and explains just well, how dumb your team is. In short, Chuck the Chig views his role as an auditor, someone who finds problems, not as someone who helps with solutions. In fact, he gets more accolades from his boss for pointing out problems than he does for helping your team succeed.

Pulling off the Feathers

The pattern described above is far too common, and it often occurs with individuals from compliance, architecture, privacy or similar groups in larger companies. It would be nice to have full time participation from the aforementioned groups, but this is often not possible. The real leverage point is a commitment to success by those who may potentially view themselves as chigs. They, their bosses, and the organization, must view them as piglets, or Extended Core Team Members if you prefer, and use whatever limited time they have on the project to maximize the chance for success.

Saying this another way, you need to pull the feathers off of the chigs and make them piglets, where pulling off the feathers is a metaphor for removing the false assumption that there job is to find problems (e.g. their job is provide solutions).

Closing and Credits

The example above makes the case for the piglet and chigs delineation, highlighting the importance of being fully committed to project success even when participating only part time.

I coined the term piglets quite some time ago, but special thanks go to Teresa Tierney, a creative individual indeed, for coming up with the “pulling off the feathers” analogy. Hopefully this vivid metaphor will help your team (including those on the Extended Core Team) achieve success.

Follow Up - What, I Have to Pass a Test to become a Certified ScrumMaster!By David Bulkin

2009-09-27T12:00:00.007-04:00

On August 31st I blogged about the new CSM Exam. The test created considerable controversy and confusion. As such, this blog summarizes the two current posts on the Scrum Alliance News Section as they relates to the new CSM Exam.

You Will Need to Take the Test, But For Now, It Looks Like Everyone Passes!

According to the Scrum Alliance Website News Post from September 21st and September 24th, beginning October 1 there will be an online exam for those that take a CSM Class. The cost of the exam will be included in your course fee. According the September 21st post, initially, all CSM students who take the test will receive a passing grade.

At some point in the future, passing and failing grades will be given. So if you become a CSM in the near future, the good news is that you take a test for free that you can’t fail! If you do not read or speak English you won't have to take the exam for now.

Good News for Current CSMs Also

All current CSM’s have had their membership automatically renewed for 2 years and will not have to take the exam until 2011; at that point you will have to pay $150 and pass the online exam.

Variations on Exams and the Future

Three variations of the exam will launch on October 1 with a total pool of 90 questions, 60 of which will be posed, and the Scrum Alliance will use initial results to determine the best 60 questions.

Over time, the exam will be converted into multiple languages.

Closing

The new CSM Exam is currently in a state of change and we will keep you up to date on the practical implications as we learn more.

Cash for Clunkers and what it Means for Government IT

2009-09-07T15:35:00.008-04:00

This article is about the Cash for Clunkers Program (officially the Cars Allowance Rebate System). It won’t discuss how disappointed I am that I couldn’t purchase that Ford Escape Hybrid (a SUV that gets 30 MPG, no surprise they were hard to get) I wanted, nor will it discuss the merits of the program for stimulating the economy or helping the environment. Instead, it looks at how this program exemplifies a future where the Federal Government has to become increasingly agile to rapidly deliver software in the face of changing needs.

The Historical Government IT Landscape

By and large, most Government IT has been waterfall based but there is a growing adoption of agile for development of software on classified projects in the DoD and intelligence communities. Reasons why agile has penetrated these pockets include:

These projects are often on the leading edge, targeting the rapid creation of new technology, often in the face of shifting requirements.
These projects are not beholden to the typical regulations that govern other projects.

The Need for Agility in Government IT

Some assume that Government IT time-lines can be defined in years (i.e. no speed required) and that flexibility is not only not required, but in fact not desirable, as the goal is to build to a predefined baseline (i.e. making it easy to gauge the performance of contractors).

Cash for Clunkers was a federal program that gave buyers $3,500 to $4,500 towards a new, more environmentally friendly, vehicle when they traded in an old, gas guzzling vehicle. In the end (see http://www.cars.gov/files/official-information/August26PR.pdf), close to 3 billion dollars in rebates were given for the purchase of almost 700,000 new fuel-efficient vehicles.

Cash for Clunkers Program was not a classified project, and it was for the civilian sector, not the DoD, but, from an IT perspective, there was both a short time-line and shifting requirements.

The house and senate had different criteria for what vehicles would qualify for the rebate, and what vehicles could be purchased. In short requirements were changing. The requirements were eventually agreed to, and President Obama signed the Cash for Clunker Program into law on June 24, 2009.

As Wikipedia documents, changes continued after this:

“Although the program officially started on July 1, 2009, the processing of claims did not begin until July 24, and the program ended on August 24, as the appropriated resources were exhausted. The deadline for dealers to submit applications was August 25. According to estimates of the Department of Transportation, the initial $1 billion appropriated for the system was exhausted by July 30, 2009, well before the anticipated end date of November 1, 2009, due to very high demand. In response, Congress approved an additional $2 billion.”

In short, the development staff faced continuing changes in requirements and had to deliver in a short time frame, thus dispelling assumptions about the acceptability of long time lines and static requirements.

Conclusion

We know that agile approaches are quite appropriate for a growing number of government projects that face shorter deadlines, increased risk and dynamic requirements. Unfortunately, the agile community can't point to the successful agile efforts on black projects due to their classified nature.

As such, please comment on your experience with, and thoughts about, the use of agile for IT Projects in the federal, state and local governments, especially for projects that are not classified.

What, I Have to Pass a Test to become a Certified ScrumMaster??!By David Bulkin

2009-08-31T22:55:00.011-04:00

The Past, The October 1st Future, of ScrumMaster Certification

Those who are certified as ScrumMasters are known as CertifiedScrum Masters (CSMs). The CSM has continually grown in popularity as the acceptance of agile has grown, perhaps synergistically. In the past, to become a CSM, you simply attended, participated in, and completed a 2 or more day CSM course taught by a Certified Scrum Trainer (CST). Starting on October 1st, this changes.

In Short, Take a September Class, or Take the Test

In short, if you take a CSM class, and this course completes before October 1st, you won’t need to take the exam to become a Certified ScrumMaster. If, you take a class after this, you will need to pass the new exam in order to become certified.

Information from Scrum Alliance Website:

Effective 1 October 2009, all CSMs will be required to complete a Certified ScrumMaster course and pass a Certified ScrumMaster (CSM) online certification exam to maintain certification.

Certification Duration:
Effective 1 October 2009, certifications will be valid for two years from the date when the CSM passes his or her certification exam. If an individual takes a CSM course after 30 September 2009, he or she will have ninety days after the course date to pass the certification exam.

If an individual earned his or her certification prior to 1 April 2009, the individual must take the initial online certification exam by 1 April 2011 to maintain certification.

If an individual earned his or her certification between 1 April 2009 and 1 October 2009, the individual will have two years from the course date to pass the CSM exam and maintain certification.

Recertification Process:
To recertify, CSMs who have not previously passed the CSM exam will required to do so. CSMs who have previously passed the CSM exam will not be required to retake it. The recertification fee is $150.

In Closing

Anyone interested in becoming a CSM should seriously think about taking a class this September to avoid the extra effort and expense of taking the exam.

The Almost Daily Sit Downs

2009-08-31T21:22:00.020-04:00

You can find literally hundreds of blog posts and articles on the Daily Standup, a.k.a. Daily Scrum. But there is little written about what often comes, or at least should come, after, the Daily Standup.

What, you may ask should come after the Daily Standup? Well, the Almost Daily Sit-Downs of course! By the way, if you haven't heard the term before, I just coined it.

The Daily Standup

Before we go into the Almost Daily Sit-Downs, let’s look briefly at the Daily Standup. The Daily Standup is held each working day (with few exceptions) and is attended by the core team (the Pigs in Scrum parlance) and potentially others. The goal is to finish the meeting in 15 minutes, so only the core team members are allowed to speak, and each person has approximately 1 to 2 minutes (assuming < 10 people) to answer:

What I did yesterday (since the last Daily Standup)?
What I will do today (before the next Daily Standup)?
What blockers are in the way?

Focus on Coordination

These questions are deceptively simple, but many are confused about how much detail to give in
response. As a result, Daily Standups often end up taking much more than the allotted 15 minutes. When this happens, I recommend one word to guide individuals and teams as they answer the three questions; “coordination”.

If you focus on giving just the information required to coordinate effectively, the meeting will be more effective. The information passed along will help the team make commitments to each other, and self manage, but you will invariably have to leave some things out. For example, perhaps you would like to talk about something you learned.

You could say this...
“Yesterday I found out something incredibly interesting and valuable about transforming the new XML file that we receive, if you want to, blah, blah, blah.”

But, it would be better to say...
“Yesterday I found some valuable information about how to transform the new XML file that we receive. I believe that Venkat, Ellie and Carly will benefit, so we can have a sit down after this meeting to discuss, and anyone else who wants to learn more can also come.”

Or maybe when you are talking about what you are going to do today, you want to go into detail, so that the team can give you input.

You could say this...
“Today I am going to work on the new database cache approach to speed up data access. I am going to create a set of new tables on the application server. As each new request comes in, blah, blah, blah."

But it would be better to say...
“Today I will work on the new database cache approach to speed up data access. This will rely on storing frequently accessed data on the application server, and I can use help on the design. Can anyone sit down with me after this meeting to help me think this through?”

Defer the Details and Problem Solving to the Almost Daily Sit-Downs

Depending on the particular day, it is possible that the team will need several sit down meetings, and on other days, none will be required. The key is that you hold a sit down meeting only when required (hence the "Almost Daily" part of the name).

Using the Almost Daily Sit-Downs for the detailed discussion and problem solving allows a team to focus the Daily Standup on coordination, so that team members can answer the three-questions in a rapid fashion, making the Daily Standup a concise and effective coordination mechanism.

Your Experience

We are always interested in your experience, so please respond with your thoughts about how your team operates today?

Does your team have Almost Daily Sit-Downs?
Does your team focus their discussion at the Daily Standup on coordination?
If your team doesn’t have effective Daily Standups, can they improve by focusing on coordination and deferring the details until the Almost Daily Sit-Downs?

VersionOne 2009 State of Agile Survey

2009-08-27T14:54:00.001-04:00

VersionOne is seeking input for their 2009 State of Agile survey. Take the survey here: http://surveys.versionone.com/akira/TakeSurvey?id=1299357&ext_ref=400.

PMI Agile Launch Event @ Agile 2009

2009-08-18T22:48:00.003-04:00

The PMI Agile Community of Practice will be launching at Agile 2009. Join Martin Fowler, Mike Griffiths, Alistair Cockburn, Jesse Fewell, Michele Sliger, Pat Reed, Dan Mezick, Brian Bozzuto, George Sclitz and me for an exciting event.

More details are here: http://agile-pm.pbworks.com/Launch-Activities.

Or, you can register directly for the event here: http://connect.thoughtworks.com/agileoffice/.

Hope to see you there!

Agile 2009: 1-on-1 Consulting - Get free Assistance from an Agile Expert

2009-08-18T22:45:00.002-04:00

New to agile, want to fine tune your process, or want to share your expertise? The LiveAid Lab will be facilitating 1-on-1 sessions between people with questions and experts in the field who know how to put agile theory into practice. You can:

1. Become a 1-on-1 Mentor:

Sign up at the Live Aid Stage to provide consulting during the conference or email: sanjiv DOT scrum AT gmail DOT com, prior to the conference. We need all disciplines from agile teams as mentors. Now is the time to share your expertise and meet new people in the process.

2. Consult with a One on One Mentor:

Sign up at the Live Aid Stage to request consulting during the conference or email sanjiv DOT scrum AT gmail DOT com prior to the conference. No question is too easy or difficult for these 1-on-1 sessions. Each mentor will work with you on the topic of your choice and may show you live examples from the Mano a Mano project being developed during the conference.
During the conference, simply stop by the LiveAid area to sign up to give or receive consulting.

Potential Topics: Estimation and Planning, Managing Agile Teams, Story Card Writing, Project Walls, Test Driven Development, Kicking off Agile Projects, Agile Portfolio Management, Setting up Team Rooms, Running an Iteration, Agile Usability and Architecture, Agile Team Roles, Paired Programming, Continuous Integration, Testing and QA on Agile Teams, Automated Acceptance Testing, and Organizational Transformation.

Gearing up for Agile 2009 -- See you There?

2009-08-13T14:13:00.008-04:00

This time of year, while we're counting down the dog days of summer, we are also looking forward to another successful agile conference.

This year, Agile 2009 will be held in Chicago, and is likely to draw old hands, newbies, and the generally curious. Agile methods are mainstream in the IT space these days, and I expect that many companies large and small will be sending their emissaries.

Agile guru Alistair Cockburn will be a keynote speaker, so I would expect that we will be hearing about some of the foundational principles of Agile. I believe the conference was the brain child of Alistair's, and know that he organized the first (combined XP and Agile) conference in Salt Lake City (with belly dancers and all).

LitheSpeed involvement in the conference will be in these areas:

Arlen Bankston will be co-presenting with Kevin Fisher of Nationwide Insurance. Expect to hear a story of the tremendous original work done by a crack Agile team at Nationwide in the area of the kanban-style progressive elaboration of product requirements across 21 teams.
I will be co-producing the LiveAid stage with Bob Payne. Live Aid is gaining momentum and we are excited about teaming with the User Experience stage. The LiveAid lab allows attendees to participate in a real agile project that directly benefits a not-for-profit organization.
I will be coordination a consulting one-on-one exchange for people connecting people who need consulting help with consultants who will be offering it pro bono.
The PMI Agile Community of Practice will be launching at party hosted by ThoughtWorks. Register for the event here.
Several PMI Agile Committee members (Brian Bozzuto, Jesse Fewell, Mike Griffiths, Dan Mezick, Ainsley Nies, Pat Reed, Michele Sliger and Sanjiv Augustine) will be at the conference -- make sure you connect with one of us to learn more and to get involved.

As always, I expect that the conference will be simultaneously busy, hectic, fun, invigorating, and an all-round tremendous experience.

Personally, it's always been a great time to connect with old friends, meet new ones and learn one heck of a lot.

Hope to see many of you there! You can find me at the LiveAid stage area Monday through Thursday, and it'll be good to connect in person.

Agile Project Time Management

2009-08-11T23:20:00.003-04:00

Jurgen Appelo has a nice, concise post on agile project time management on his Blog: http://www.noop.nl/2008/06/10-principles-of-agile-project-time-management.html.

Agile 2009 Presentation - From Cradle to Sprint: Creating a Full-Lifecycle Request Pipeline at Nationwide

2009-08-11T09:30:00.003-04:00

I will be co-presenting a session entitled From Cradle to Sprint: Creating a Full-Lifecycle Request Pipeline at Nationwide Insurance alongside Nationwide’s Kevin Fisher at the upcoming Agile 2009 conference in Chicago, IL. We will discuss how LitheSpeed helped them to adapt Scrum for a monumental, 18-team project that spanned much of the company .

The presentation focuses on how Corporate Internet Solution's RedFishBlueFish team addressed key issues such as aligning multiple powerful stakeholders, integrating robust user experience design and testing into a Scrum model, and addressing dependencies across all of the teams with powerful, lightweight techniques.

We hope to see you there!

Speaking at PMI DC Career Day

2009-07-28T21:17:00.002-04:00

I'll be speaking at the PMI Washington DC's Career Day on October 16, 2009. Topic is the Agile PMO: Scaling Agile through Adaptive Governance. Hope those interested in the subject will be able to make it to the session.

Israel Gat on Agile Adoption

2009-07-24T22:43:00.006-04:00

Via the HereTech, Israel Gat on agile adoption. Israel Gat, best known for pioneering agile methods at BMC Software speaks with Forrester Analyst Tom Grant in this podcast.

Among other nuggets of real life experience, Israel shares how he expected the agile adoption to be equally drive 50:50 top-down and bottom-up. Instead, he found that he only needed to provide about 20% of top-down leadership, and the groundswell of grass roots momentum carried the adoption forward quickly. He also warns of the danger of agile being considered a silver bullet, and recommends demanding specificity of the problem at hand before adopting agile.

Some great insights from an executive who has been through the crucible of real life agile adoption.

Flexibility and Rhythm - Top 10 Characteristics of an Agile Organization

2009-07-24T22:34:00.002-04:00

Excellent video from Ryan Martens of Rally Development on maintaining a rhythm in organizations. See also the comment from a reader on "Battle Rhythm, a mechanism for both maintaining and managing synchronized activity."

The post is part of a 10 part series on the characteristics of an agile organization.