What is Agile?

The parable

Ever heard the story about the blind men and an elephant?  In various versions of the tale, a group of blind men touch an elephant. Each man feels a different part, but only one part, such as the leg, the tail, or the trunk.  They then compare notes and learn that they are in complete disagreement. Agile, my friends, is an elephant.

The first blind man

I just completed an initial engagement with a client.  Some of the people I interacted with were newly minted Certified ScrumMasters, some experienced developers, and some executive management.  In the mix, I met UX designers, architects, and more functional roles than this blog post should list.  The catalyst of this post happened on the first day of the engagement.  To set the stage, the organization was very clear the team is to "do" Scrum.  Due to user stories not being quite ready, the team pushed back at Sprint Planning and refused to estimate or commit to the work to be done.  I recommended the group visualize the workflow and maturation of user stories by way of a Kanban. I've made this recommendation before and it worked out quite well.  The response from one of the newly minted ScrumMasters was, "That sounds like waterfall!"  When I corrected him, confirming that it was not a waterfall approach,  he came back with an even better response.  "Well, it's not Scrum.  If it's not Scrum, it's not Agile".

If it's not Scrum, it's not Agile

A few days ago, I read a really great post by Joel Bancroft-Connors titled A Gorilla Primer: What the heck is Agile? Maybe this question is more common than I initially thought!  What I liked about Joel's post was it exposed the fact that Agile is different for so many people.  When asked what Agile is, I tend answer the question with a question.  Are you being Agile or doing Agile?  If you are being Agile, then how?  If you are doing Agile, then how?  Before I even attempt to answer the question, I want to know your perspective.  Why?  Because as with the parable and also reality, it's going to depend on your touch points. Go read Joel's post.  I think you'll enjoy it.  When you're done, I'm sure you'll agree that if it's not Scrum, it can still be Agile. Image Source: Pictofigo (Go get one. They're free)

Software Capitalization and Agile Development

Image: digitalart

Many of our clients are either publicly traded firms or firms that would like to be publicly traded someday. And something anyone working with these firms will be likely to tell you is that the way they account for software development costs can be tricky.

Let's start with the following fill-in-the-blank question:

The way accounting treats software development from a financial reporting perspective can be ______.

a) Financially significant to the firm in terms of profits, losses, taxes, etc.
b) A potential source of financial fraud
c) Mind-numbingly confusing
d) All of the above

The correct answer, of course, is (d). But despite the potential financial impact, capitalization is a topic that rarely comes up within the agile community. My goal for this post is to shed some light on the problem for the non-accountants out there, so please excuse any definitions and categorizations that aren't totally correct. I'm not an accounting expert.

What is Capitalization?

Capitalization is the act of categorizing an expenditure as an asset rather than an expense. Imagine that a company has one million dollars in cash but no real estate or other assets. In this case, the company's total amount of assets is one million. Now imagine that they construct an office building for $500,000. They still have one million in assets: $500,000 in the building and $500,000 in remaining cash. Because the building has long-term economic value, it's been classified as an "asset" to the firm. In other words, it's been classified as "capital" or has been "capitalized". Compare this to a firm taking everyone out for a big $500,000 party. This would definitely be categorized as an expense rather than an asset, because it has no long-term economic value to the firm. In both cases, they spent $500,000 but accounted for the $500,000 expediter differently on the books based on what it was spent on.

The Kinds of Software

There are basically two kinds of software recognized by financial types: software for internal use and software for sale to outside parties. You'll need to figure out which one applies in your situation, and in some cases, it may be both: You sell software and also build software for internal use. The same software could also fit into both categories in the case where you build the software for internal use but plan to sell it eventually.

The way we capture expenses, assets, etc., will depend to some extent on the kind of software it is, even though the basic premise is similar for both.  Expenditures with long-term economic value are treated as assets ("capitalized"). Otherwise, expenditures are treated as expenses.

Who Cares?

Many people, as it turns out. How you categorize your software costs can have a huge impact on profits, losses, assets, depreciation, taxes, etc. And many an accounting fraud has been perpetrated by willfully mis-categorizing assets versus expenses in order to cook the books. Remember Worldcom? By the end of the investigation, it was estimated that the company's total assets had been inflated by about $11 billion.  How? You guessed it: by capitalizing what should have been expensed.

Financial Accounting for Software

Many (but not all!) of the costs associated with building software can be capitalized, or in other words, considered an asset like the construction of a building I mentioned earlier. But not all of the costs can be capitalized. This is where accounting rules come into play. The way you treat software from a financial reporting standpoint depends on its kind. If it's software for sale, then I believe that more costs can be treated as expense. If the software is for internal use, then it's treated slightly differently. I think that fewer costs are treated as an expense and more are treated as assets. But we'll leave the minutiae to the accountants.

In general, it's fairly safe to say that actual software development and test time is capitalized or treated as an asset, whereas up-front R&D, feasibility, prototypes, etc., may be considered expenses. I'm pretty sure that time spent on operational support and defect fixes count as expenses, and therefore cannot be capitalized. The time spent on architecture and design, however, can be capitalized. I'm not sure whether requirements analysis time counts as an asset or expense.  So, for example, if you spend:

• $250,000 on design
• $500,000 on development and test
• $100,000 on operational maintenance

Then you might have $250 + $500 = $750,000 in new assets, and you might have $100,000 in profit-sucking (or tax-lowering) costs.   

Agile Complicates Things (Again)

All of this was easier in waterfall because you entire phases could be treated as assets or expenses. You could just say that all of the money spent during the development phase and test phase could be capitalized. In the agile world, we don't have these phases, so it becomes a little trickier to track the numbers. My advice would be to track the time spent on each activity so that the accountants have what they need to figure it all out. In agile product development, you'd need to do this on a per-user story basis, which can be a pain.

I don't generally break user stories down into tasks anymore, but this is a case where it would definitely help. Create a requirements task, design task, dev task, test task, etc., for each user story. Keep track of which stories are new features and which are support/operational-bug-fixes. You'll need to track the time spent on each task and then roll it all up for the bean-counters so that they can get a total amount of time spent on requirements, dev, test, etc.

Finally, talk to your corporate accountants. One of the reasons that you may not hear much about this topic is that your accountants have come up with reasonable ways to estimate the breakdowns using historical averages, etc.  Still, every now and then, we run into firms where this topic requires a more accurate treatment. I'm sure that you can come up with ways to get the information the accountants require, such as by doing it on a per user-story basis.    - Roland Cuellar

---

Roland Cuellar is a software and product development process consultant specializing in program management leadership and agile software development, and lean business process improvement.

Stoos: Is Great Management Timeless? (Continued)

In discussing the Stoos movement, I posed the question, "Is great management timeless?" That is, do we really keep reinventing management or do we just uncover different ways to manifest principles of great management?

After further discussion about the goal of the Stoos movement, I believe continued dialogue will lead us to uncover the underlying truth. It's dialectical.

Certainly, as Peter Stevens, the originator of Stoos, commented,

This [industrial] model worked extremely well in the first half of the 20th century, stumbled through the 70s, but is creaking and shuddering today. 

More recently, the advances at Xerox, PARC and elsewhere (Smalltalk, IDEs, rapid feedback, not to mention the whole internet) enabled new management approaches, e.g. Scrum, XP, Kanban. The same advancements also put pressure on companies to do better, not just developing software, but at innovating for their customers. This requires more enabling management than was necessary 100 years ago.

Clearly, older industrial management is creaking and shuddering today.

But, simultaneous with the creaky industrial management that Peter identifies, we've had wonders from Walter Shewart, W. Edwards Deming, Taiichi Ohno, and, of course, Peter Drucker. We know that the Lean management model has grown and thrived through Toyota and others during the same period that industrial management has declined. Indeed, very little we propose in #Stoos and agile management cannot be found in the works of Drucker, Deming and others.  In fact, Scrum draws on the work of Ikujiro Nonaka and Hirotaka Takeuchi, through their landmark paper, The New, New Product Development Game.

Because management is dependent on the nature of the work we're doing, Drucker coined the term "knowledge workers," and maintained that knowledge workers needed to be managed differently. This view is also supported by Nonaka, one of the grand doyens of Scrum.

So, it seems like our inflection point is the difference between industrial/scientific management and lean/agile management. Perhaps great management is not timeless, and we need to adapt management to suit the challenges and work of our time.

Thanks, Peter and others associated with #Stoos for moving that process along.

The Community Guide of the PMI-ACP: Get Involved!

The Community Guide of the PMI-ACP (login required) is an initiative of the PMI Agile Community of Practice to provide ongoing support for the PMI-ACP agile certification. Community volunteers played a crucial role in the creation of the certification (as recently highlighted in PMI Today), so it only follows that they should also be the ones to mature it into the future.

What about the AgileBOK?

There will be no Agile Body of Knowledge (AgileBOK) supported by PMI.  PMI does not own, maintain, or support ANY web presence that lives outside of PMI.org. There is not, and never should be an authoritative standard for Agile. Having an AgileBOK would invite all PMI project managers to rigorously follow a standard and never adapt, tailor, or innovate their processes. This counters what we as Agilists stand and strive for.

How can you contribute? Team members will work as individual contributors within the Community Guide project. Their involvement may vary based on the nature of the work and their availability. If you are interested in creating or maintaining articles for the Community Guide, contact the current co-leaders of the ACP Support Team: Joeseph Flahiff and Derek Huether.

Who is the Community Guide for?

The Community Guide is intended to be the authoritative source for all the stakeholders in the PMI-ACP ecosphere, including:

• A study reference for those pursuing the PMI-ACP credential
• A training reference for REPs and trainers
• A technical reference for exam writers

What does the Community Guide cover?

The Community Guide is a unique community resource, offering:

• Links to relevant PMI documents regarding the certification
• The original intent of the PMI-ACP creators for each topic on the exam
• The current community consensus on how each topic works on "most agile projects, most of the time"

Image Source: Pictofigo

An Agile Game - Management by Walking Around

Image: Stuart Miles

It’s time for another Agile game that you coaches, trainers and ScrumMasters out there can use to educate your teams. This is a fast, easy and physically engaging one that illustrates how simple rules and time boxes can create a self-organizing environment that mitigates risk and increases engagement, speed and flexibility.

Timing: 10-15 minutes with debriefs
Group Size: 10-50 students
Setup: A room with a fair amount of potential obstacles (e.g. tables and chairs) and masking tape defining a boundary around the room just wide enough to allow for movement by participants. You'll also need a timer.

Round One Instructions: 
1.  Ask students to pair up and decide who will be the Manager. The other person will be a Worker.
2.  Describe a silly scenario that justifies the boundary, such as, "We’re tracing possible paths through a space station, and the tape defines the walls," or "We’re simulating traffic within a small section of Manhattan."
3.  Tell students that their goal is to take 60 steps.
4.  Tell the Manager to direct the Worker’s movement, using one of these commands:

• Go forward (full strides, no walking in place) 
• Stop 
• Turn right (90 degrees) 
• Turn left (90 degrees) 

Any deviation from these commands will be regarded as insubordination and duly punished. 

5.  The Manager must track the number of steps taken.
6.  Set the timer for one minute and begin the exercise.
7.  While the exercise is underway, walk around and act as a general blocker (moving things in people’s way, standing in inconvenient spots with a vacant look, etc.).

Round One Debrief: 
Ask a few Managers how many steps were taken. They will often be unsure, given the general chaos of the exercise.
Ask a few Managers how they felt. They will likely feel stressed and ineffective. Micromanagement at this level takes a lot of time and energy, but rarely pays off in efficient processes.
Ask a few Workers how they felt. They will generally turn their brains off, demonstrating that when people are given orders, they will simply follow them rather than think for themselves. This is a key point: True engagement requires empowerment and autonomy.
Note that the room was very noisy and chaotic. 

Round Two Instructions: 
1.  Dissolve the pairs; everyone is now a Self-Managing Worker.
2.  The goal is the same: to take 60 steps.
3.  Ask everyone to count their own steps.
4.  Set the timer for one minute and begin the exercise.
5.  Act as a roving blocker, just as in the last round.

Round Two Debrief: 
Note that more steps were taken, and more than likely, most participants achieved their goal. Empowerment at lower levels provides more bandwidth to get work done.
Note that this round was probably largely silent, and ask why. Clear goals and simple rules allow everyone to easily make their own decisions without undue intervention or discussion.
Ask whether anyone noticed patterns forming. The group probably quickly fell into a series of loops, illustrating how complex and effective patterns can emerge in the absence of centralized planning when goals and boundaries are clear.

You might also choose to point out that checking in on such a process at stable intervals (e.g. every minute, in this exercise, or every Sprint in Scrum) would create ample opportunities to inspect and adapt the team’s approach, while limiting the investment of time and budget during any given interval. The major takeaway from this exercise is that risk management and efficiency are better achieved through a system with highly visible goals and clear rules for participation as opposed to direct management intervention in lower-level tasks.

I hope this has been helpful! Please let me know if you’re looking for a specific topic or point to illustrate with an exercise, and I'll try to address your requests in future posts.

Stoos: Is Great Management Timeless?

The Stoos movement is off to a great start. More than 850 people have joined the Stoos Network on LinkedIn since January and the Stoos Stampede in Amsterdam is scheduled for July 6-7, 2012. Still, as with any movement, the enthusiasm felt by many isn't shared by all. In fact, it appears that the work of Stoos enthusiasts might be ruffling some feathers.

In my opinion, this is undoubtedly unintentional, because every person I've met associated with this movement is passionate about fixing the dysfunctions in our organizations today. So what is it about the Stoos message that might not resonate with some people?

I've been mulling the message over in search of an answer. In my posts, as well as those written by Jurgen Appelo, Steve Denning and others, the message has been about transforming management. But are we talking about transforming the discipline of management or transforming organizations through better management?

Check out Peter Stevens' related blog post on this topic: Agile is the Vanguard of the Transformation of Management.

Perhaps, upon reflection and with introspection, we can say that great management is timeless. Isn't it that we uncover the immutable principles of great management slightly differently in each age? After all, there is nothing in the agile management movement not previously covered and espoused by Peter Drucker, W. Edwards Deming and Taiichi Ohno.

Should we be talking about transforming management, or should we be aiming to implement timeless best practices in our organizations using the best methods of our age? We can use videoconferencing to achieve real-time collaboration when not collocated. We can implement “commander’s intent” through self-organized teams.

Is great management timeless or not? Do we really keep reinventing management or do we just uncover different ways to manifest principles of great management? What do you think?

Agile Retrospectives: Why Bother?

Retrospectives in Scrum (called "reflections" in eXtreme Programming) are a key agile practice. The mechanics of a retrospective—a meeting through which the team assesses its performance and sets goals for improvement—are fairly straightforward. There are many ways to tailor and improve a retrospective, but this simple Plus/Delta-inspired format is a good start:

• Arrange for a neutral facilitator to run the retrospective. 
• All project team members sit in a large conference room, preferably in a circle. 
• All participants follow simple ground rules (cell phones off, no interrupting others, each person gets a time-limited turn, and no judgment on feedback). 
• Each team member provides feedback on these questions: What’s working well? What can we improve? What are some obstacles or issues facing the team? 
• A brainstorming period follows to address the major issues. 
• The meeting ends after the facilitator captures action items. 

Unlike the traditional “lessons learned,” reflections are conducted while the project is underway, usually after every sprint, to qualitatively inspect the team's agile process. Although the concept is simple, we've found that teams often struggle with establishing effective retrospectives. One of the reasons for this is that after the initial excitement of getting agile projects up and running, we let certain key practices lapse, and the retrospective is often one of the first to slip. Going through the retrospective over and over again can become tiresome if the team doesn't understand and value its purpose.

Some time ago, Arlen blogged about steps to achieving more efficient agile retrospectives. This post addresses the purpose behind the practice, instead, answering the question, "Why do retrospectives at all?" It's an important question, because knowing the answer helps us implement and sustain this critical practice.

From a systems perspective, learning and adaptation requires us to continually make slight adjustments in order to discover the best fit for the environment. An agile team needs continuous feedback to enable learning, just as the feedback we get when driving (the feel of the steering wheel, the road conditions, other traffic, etc.) allows us to make the adjustments necessary to steer the vehicle. Learning is enabled by continuous feedback from the environment, and is accomplished through adaptation of strategies and rules. In the field of organizational development, this is called "double-loop learning."

As illustrated, double-loop learning involves two learning "loops." The first loop represents adjustments based on fixed, non-changing goals and operating norms. The operation of a thermostat is a common example of single-loop learning.

When a thermostat at a particular setting learns it is either too hot or too cold, it turns itself off. It performs this corrective action on receiving information about the temperature of the room.

Double-loop learning involves an additional learning loop with steps to reflect and adapt the operating norms themselves. With double-loop learning, one questions the norm represented by the thermostat's temperature setting. Why is the thermostat at this particular setting? Is it the optimum temperature all day? Should it be changed to accommodate the number of people in the room, for example? This sort of self-reflection and learning results in intelligent, congruent action.

The retrospective represents a simple way to implement deeper double-loop learning beyond the day-to-day adjustments we make to keep things running on our projects. Retrospectives are thus fundamental to continuous improvement. Our teams and organizations cannot improve unless we're constantly assessing and improving our processes, and the retrospective is an excellent way to implement that continuous improvement.