Credit: http://500motivators.com/motivate/me/motivation-its-not-that-im-lazy-i-just-dont-care/

AMP = Autonomy, Mastery, Purpose.

Now this is a power-packed acronym! These three words power the engine within us that takes us to greater heights, and help us achieve self-actualization in the personal and professional environment.

Located at the peak of Abraham Maslow’s hierarchy, self-actualization is described in the following way:
“What a man can be, he must be. This need we may call self-actualization…It refers to the desire for self-fulfillment, namely, to the tendency for him to become actualized in what he is potentially. This tendency might be phrased as the desire to become more and more what one is, to become everything that one is capable of becoming.”

 
Why is this stuff important?

• Supporting innovation and experimentation without punishment is crucial to personal and professional success. An environment that supports ‘test-drives’ allows people to close in on what seems an impossible task.
• A ‘purpose-driven’ (not solely money-driven) approach makes what we do meaningful. An overload of seemingly monotonous work that isn’t engaging anymore is a productivity killer. Opportunities that allow one to explore and master new areas puts a spring back in a one’s step.
• The journey is, quite often, more significant than the destination. Experience and personal achievement are, without a doubt, the more distinguishing and memorable aspects of our lives.

During a class I was in earlier this year, the instructor played an RSAnimate video adapted from Dan Pink’s talk at the RSA to drive home a point. The video reinforces what really motivates us. If you haven’t come across this video yet, I recommend you watch it here. If you’ve watched it before, well, watch it again to remind yourself what it’s all about.

This week, my blogs are going to dissect AMP and take a look at why so many of us do things, not for money, but for the sheer joy of fulfillment and learning. AMP is a powerful influence over human lives that often goes unrecognized and under-appreciated.
 

As you can probably tell from the title, this blog post is very specific - and also a very valid thing to consider when working in short iterations. Your team have committed to deliver a specified number of story points in the current sprint and part-way through a team member announces that they need to take a few days annual leave. How does the team deal with this?

For me, the first stop is a management assessment of the request. If someone needs to attend to a family emergency, for example, then it may be that you can't (and shouldn't) even consider denying the request for leave. Regardless of what you decide (or whether the request for annual leave is a true emergency) there are a number of other things you may wish to consider doing:

• Have a conversation. Agile ways of working promote conversations as part of the 'process', so get the entire team around the whiteboard to discuss the annual leave request. If the request is granted, can the team still deliver on their commitments? If the answer is 'yes' then maybe you don't have a problem (provided the remaining team members are still fully bought-in to delivery). If the answer is 'no' and the request for annual leave is not related to an emergency situation then team pressure can be an incredibly useful device in persuading the individual that they, along with everyone else, made a commitment that they need to deliver on, i.e. that taking the leave is not appropriate.
• Ask the individual to put in additional effort between now and the date of the leave to ensure that the team can still deliver.
• Consider de-scoping features. If the request for annual leave is urgent and simply cannot be denied, then you may have no other choice. It's as simple as that. 
  • Even where the leave is not critical, you may choose to grant the request anyway. In doing this, you need to be very careful of the message that this sends to both the other team members and the business. Is it really worth it? Personally, I would shy away from this option in a non-emergency situation.
• Agree to play it by ear. Do you need to make the decision right now, or can you see how much progress the team is making in 1 to 2 weeks time and then make the call?

Thoughts?

Yes, we have snow. Like almost everybody else. The neighbors created an ice-skating track by flooding a small field. The ice is not perfect. But … it’s just perfect. People get together. The field of frozen water is just a good excuse to get out and have some fun.

It’s not that if there isn’t an ice-skating track you don’t meet. But this is just such a great opportunity. And a natural one. You don’t have to plan. You just go there. Show up. That’s it. The track is a catalyst for conversations.

Communities have more places like that. Libraries for example:

“For some, the building remains essential: engagement with the library is a ticket to – and a membership card for – a local community. Some say the building needs to be there, but not as “a warehouse of dead books”, but as a place to invent yourself, individually and socially.”

In some weird and twisted way, back in the days when I still smoked cigarettes, the smoking area in my company had a similar function for me: I was the most informed Project Manager around. I knew a lot of people that weren’t in the direct surroundings of my project. It’s not that the individuals weren’t approachable. It’s just that I am not the kind of guy that is randomly stopping people in the hallway to ask what they do.

Organizations have these natural places where people bump into each other.

Coffee corner. Lunch room. Places where you experience that you are part of a certain group, just by having the same rhythm. “Hey, we drink coffee in the same pace!”

Architects can actually design these places.

The best we can do is recognize the opportunities. Or make use of social objects:

“For a while I  had  a bowling bag to carry my papers and other work related stuff. I bought it, because everybody else was carrying the same black Samsonite briefcase. The bag was blue with white letters and oddly shaped. Colleagues and clients would say something about it. Complementing me on my fine exquisite taste. Making fun of my stupid bag.

The bowling bag created engagement. A conversation starter. Something to trigger a spontaneous moment of interaction. And never in a negative mood. The plastic bag from the supermarket I carried around for months after that triggered some different comments though.”

Image by Frau Shrink.

Bas de Baar helps people find ways to enjoy the diversity of human interaction in their organizations so that they can get out of their own way and achieve their goals. - An Ice Skating Track And Opportunities To Start Conversations. is a post from: Project Shrink.

- what would it take to differentiate yourself and your project from others? What would the value be?

To most project managers and professionals my guess is that the word ‘brand’ evokes a certain sense of ‘marketing non-sense’ and ‘showman-ship’. Why would a project or even worse a project leader need a ‘brand’?

As it turns out, the project management world has an opportunity to learn from our product and brand management colleagues. The value and equity we can derive from ‘marketing’ our project using a brand can help set it apart from others and help get our project prioritized and noticed.

MIT Sloan’s – Management Review recently put some focus on this in an article titled “Why Every Project Needs a Brand (and how to get one). In reference to the project brand they wrote, “Broadly speaking, a brand can be defined as a unique value proposition expressed in a relevant and differentiated way such that it creates preference and loyalty among key audiences. So why is project branding important? Because your project can suffer in the absence of a compelling brand.[i] “

(source: .http://theclosetentrepreneur.com)

So, what are those key pieces of information that project leaders can learn to leverage so your suffer in the absence of a compelling brand? Here are a few to start with, if you have others that you would like to share, feel free.

Project Naming: this is the brand management process of deciding what a product will be called. A project manager can think of her project as a product, considering the stakeholders and the project members. Naming a project or product is a critical part of the branding process, it will help everyone involved to identify with the vision of the project and to be consciously reminded of the future outcome and benefit of the project When naming a project you must take into account the many uses of your name in documents and dialogue and ensure that it is a name that helps people to ‘get it’ easily.

The process of naming your project should be done deliberately and by involving your team members, ensuring that it is something they will be energized and inspired by.

Some key steps include specifying the objectives of the branding, developing the project name itself, evaluating names submitted by the team, and choosing a final name.

When brainstorming about a project name, the following ideas might be useful:

• it strategically distinguishes the project from other projects by conveying its unique positioning
• it holds appeal for target audience
• it implies the project’s future benefits and outcome
• it helps to motivate team members to work on the project and helps executives to promote it.

Selling a vision: Just as brands help those who market products or companies convey the purpose and value to their target audience, so can a project manager help convey the vision of their project through a brand.  In most cases your project is competing for attention and funding with many other projects and you with many other project managers. Developing a brand for your project and maybe even for yourself can help you set yourself apart and help you convey your vision, benefits and value or your project. To help you get started, spend some time thinking about statements in the following four areas that help you convey the project:

1. Unique value proposition – what is the unique value your project is bringing to the table
2. Unique selling proposition – your elevator pitch
3. Slogan or Mantra – what is going to make it easy for people to know what you are working on
4. Positioning statements – targeted towards different people you may encounter

(Source: http://craigpearce.info)

Brand Equity: in essence the value you get from employing a brand for yourself and/or your project versus those who do not spend the time doing so.  Thinking about the brand equity you may be building through your efforts can help determine if the time and investment is worthwhile compared to your peers and competing projects.

According to Wikipedia, Brand Equity is “the marketing effects and outcomes that accrue to a product with its brand name compared with those that would accrue if the same product did not have the brand name. Fact of the well-known brand name is that, the company can sometimes charge premium prices from the consumer.”[ii]

How might this translate into a project management setting? If the process of branding is done correctly for your project, it might mean that when funding decisions are made by your executive team, you would see additional benefits by the “awareness” of your project and garner opportunities to showcase your project and its benefits/outcomes/value in forums not otherwise open to you.

[i] http://sloanreview.mit.edu/the-magazine/2011-summer/52416/why-every-project-needs-a-brand-and-how-to-create-one/

[ii] http://en.wikipedia.org/wiki/Brand_equity

- a set of familiar tools seen through the eyes of a product manager

- By Sridhar Karnam (www.linkedin.com/in/sridharkarnam)

Tools that product management use that might be interesting for project managers to use:

In continuation to our last week’s discussion about lessons that project management can learn from product management, let us examine some of the tools that product management uses that could assist in project management:

Weekly newsletter: The communication within the team and between team is critical for product management. At a simplest form product management uses email, wiki, idea management, and requirement management tools. Project management could use simple tools such as weekly newsletter to communicate the status update with the entire team, with the management, and also between other project teams to ensure that everyone is on the same page. Program manager is typically responsible to bring every project on the same page at high level. However, a weekly email update in the form of newsletter can give the details and granularity that everyone needs to know about the project. Smaller team could use a simple corporate email with consistent template or format to communicate with the ecosystem. A larger team could use free web 2.0 tools such as mailchimp.com to communicate.

Knowledge tools: The product management is responsible to build and manage the inventory of product knowledge. Typical tools used are MS Sharepoint, FTP servers, Dropbox.com, salesforce.com, or fancy knowledge base tools. At a simplest form use a Dropbox.com tool create a consistent folders. Every user gets an instant notification as soon as a new version/ doc is checked-in. Every member of the team has the same version of the document irrespective of the number of revisions that it has gone through. Collateral that Product Manager uses to communicate about the product to senior management and field during the initial stages are relevant for the product development team. The one-pager executive summary of the product is a great example apart from MRD, PRD, SRS, etc. to be shared in this folder.

(source: http://www.knowledgejump.com)

Empowering tools: Product management uses many webinars to discuss and debate the research and diligence reports. Project teams could make use of such tools to conduct a 30-min project team refresh meetings to discuss about case studies, coding best practices, efficiency improvements, re-usability of code, and so on. Product management uses simple tools such as Google Alerts to capture information about competition and market. Use corporate collaboration tools such as webex, go-to-meeting, or even Google+ to empower your team with the latest and greatest in the domain, technology, or process.

Decision tools: Product management usually run multiple what if scenarios for the features, functionalities, revenue, volume, or users. This helps them take quick decision in the meetings. With emphasis on making decisions in every meeting these days, it is important that the project management uses its existing tools and run what if scenarios by modifying activities, resources, bugs, or release dates. This makes the project management to respond quickly during the meetings and in hall-way discussions to speak about the impact of changes rather than calculating them after the decision has been made.

Change management tools: The project management gets input from many people through support escalations, business escalations, management requests, and of course market changes. Product management uses simple tools to modify product backlogs and directs changes to the project management. As we know that execution is more challenging than idea generation, proper use of tools are required for project management to manage changes in requirements, schedule, or resources. Capturing the information from above tools of different teams may help the project management team to re-use or learn about the changes quickly and be agile. The bulky ERP tools that we mostly use which goes through approval from who’s who in the group may not be very effective. Combination of knowledge base, current version of the documents, and decision tools will help through navigate the changes rather than avoiding it.

(Source: http://www.ideachampions.com)

Prioritization tools: The project management team has people management, resource management, code management, technology management, and many other challenges to manage. With constantly changing business requirements, it could get overwhelming to manage changes. Using some of the prioritization methods could be helpful to manage these changes. There are many tools that product management use based on the prioritization methods used. As a first step, the project management shall get away from a To-Do list format to prioritization way of thinking, and use any of the tools that is available in the system.

The tools are only tools, and it’s the skill and attitude that would drive the business. A tool is very critical to cut a huge log of wood. The tools has to be sharp and right. At the same time, a great club in Golf will not help you achieve great results. So a combination of right attitude and a tool will help project management move away from a tactical to-do list teams to strategic teams with vision.

(Source: http://www.realministry.org)

I have written here and elsewhere -- including in academic journals with Fabrizio Ferraro and Jeff Pfeffer -- about research and theory suggesting that, when people are exposed to economic theory and assumptions, they tend to become more selfish.  This research, as with much evidence in the behavioral science, shows that exposure to ideas or even little "primes" (such as one study that simply exposed students to backpack versus a briefcase) can have surprisingly big effects on whether people are selfish or generous.  In this vein, an article in the December 2011 edition of the Academy of Management Learning & Education journal by Long Wang, Deepak Malhotra, and Keith Murnighan reports three studies that add to this troubling pile of evidence:

In the first study, students played something called "The Dictator Game," where they are given complete control over how ten dollars were distributed between themselves and a counterpart in another room.   The researchers found that students who studied economics were significantly more greedy than those who studied education, with the average economics student taking about a $1.25 more for him or herself (($7.76 vs. $6.50). 

A second study compared the attitudes of students who had taken two or fewer economics courses to those who had taken three or more classes, and found that those students who had taken more economics classes had more positive views of their own greedy behavior and of morality of greed in general.

A third study compared students who were simply exposed to short statements from economists about the virtues of self-interested behavior versus statements from economists about the negative effects of self-interest.  Then they were given a questionnaire with five statements about the benefits of greed. The researchers found that simply being exposed to these short arguments packed a wallop:  People who read about the benefits of self-interest (although randomly assigned to the condition) were more likely portray greed as good, correct, and moral.

Taken together, these studies, along with a pile of research before them, suggests the assumptions we are exposed to in life -- and those we are attracted to as well -- can have a big impact on how we view and treat others.  They don't show that economics is inherently evil, but do suggest that embracing (or just being exposed to) one of the core assumptions in the field -- that people are inherently self-interested -- can create a self-fulfilling prophecy, which can make you think and act like a more greedy person.  

Looking out for yourself is necessary in life. We all need to money, we have others we need to take care of, and striving to do great individual work can benefit those around us in many ways.  But studies like this one  are instructive.  They remind us that being around others who are greedy and selfish can cause us to be infected with the same behaviors and beliefs, that just being around money and thinking about it can lead us to be less likely to help others (and less likely to ask for help), and that when we are feeling competitive and wanting more and more it is a good time to stop ask and ourselves: Do I have enough for myself? Do I really need more?

Strong SAP SDN post by Mark Chaffen on SAP RDS (Rapid Deployment Solutions) and the case of the missing Blueprint.   I’ve only started to dig in to the topic, so these are my (likely half-baked) first thoughts:

• On balance “no Blueprint” is good.  Its exclusion reinforces that a RDS implementation is of a fixed, limited scope.  There must always be some sort of scope statement, of course, and its there.  Unfortunately, “Blueprint” seems to equal “everything and the kitchen sink” in some SI’s SAP glossaries!  Wise to make a clean break in the lexicon.
• Avoid Death by Change Order.   RDS is designed to deliver only what one needs to execute — the wish list comes later.  Only fill in regulatory, statutory, or other compliance gaps during the initial implementation; otherwise make a conscious decision to remaining requirements into  backlogs that get burned down release-by-release. 
• RDS still too “new solution” oriented.  There are other ways to expand a SAP footprint… how about RDS for acquisitions, divestitures, or other growth/transformation scenarios?

Filed under: PMO Tagged: ASAP, Dennis Howlett, Mark Chaffen, RDS, SAP

The more I work within the Scrum project framework, the more I appreciate its practical and simple concepts. I am also interested in the expertise required to be a Scrum master. Like any skill you seek to master, the path may be harder than you want and take longer than you want. I am convinced [...]

Pro .NET Best Practices gets a great review from Tad Anderson in the .NET Developer’s Journal http://t.co/I0W5P4lL. 
I loved the reviewer’s lede:

I personally do not find software development an art form. It is not an unpredictable activity driven by crazy business users that come to work every day inventing a new way to operate their businesses just to savagely changing your requirements. Project teams that use changing requirements as an excuse for their dates constantly slipping and bugs being pushed to production are simply not good development teams and they are poorly managed.

Filed under: PMO Tagged: Development, Project Management

Example 3: Using a Project Manager with Iterations and Kanban and Silo’d Teams

Here, the developers were in Cambridge, MA, the product owners were in San Francisco, the testers were in Bangalore, and the project manager was always flying somewhere, because the project manager was shared among several projects. The developers knew about timeboxed iterations, so they used timeboxes. Senior management had made the decision to fire all the local testers and buy cheaper tester time over the developers’ objections and move the testing to Bangalore. The Indian testers were very smart, and unfamiliar with the product, so the developers suggested the testers test feature by feature inside the iteration.

The project manager suggested they use cumulative flow diagrams and cycle time measurements to make sure the developers were not developing “too fast” for the testers. The developers, still smarting over the loss of “their testers” were at first, peeved about this. They then realized the truth of this statement, and developed this kanban board.

You can see in this board, that four items are waiting to go into system test. Uh oh. The developers are out-producing what the testers can take. This is precisely what a kanban board can show you.

The testers aren’t stupid or slow. They are new. They cannot keep up with the developers. It’s a fact of life, not a mystery of life. The developers have to act in some way to help the testers or the entire project will fail. The reason they are working in timeboxes as well as using kanban is that they have several contractual deliverables, that management, bless their tiny little hearts, committed to. The timebox allows the team or the product owners to meet with their customers and show them their progress. (They were deciding who would meet when I last worked with the team.) The kanban board help make the progress even more transparent.

Iteration planning: The product owner and the project manager jointly work on the agile feature roadmap, and the product owner owns the roadmap responsibility for it. The product owner owns and generates the backlog. The product owner and the agile project manager present a strawman iteration backlog to the team at the start of the iteration. They have had difficulty finding iteration planning time that allows everyone to be awake and functioning, bless the senior managers’ little hearts.

Daily commitment: They do a handoff, asking each other what they completed that day and what the impediments are. If you have read Manage It!, you know I modified the three questions to “What did you complete, what are you planning to complete, what is in your way?”

Measurements: cumulative flow, average time to release a feature into the product. They are experimenting with burnup charts and impediment charts. They are still having trouble bringing the testers up to speed fast enough.

Yes, they do retrospectives at the end of each iteration. Yes, the product owners own the backlogs.

I’ll summarize in the final part, the next entry.

(Want to learn to work more effectively on your geographically distributed team? Join Shane Hastie and me in a workshop April 17-18, 2012.)

Do you think team dynamics make a difference in business results?

© derby for Insights You Can Use, 2012. | Permalink | No comment | Add to del.icio.us
Post tags: management, teams

Feed enhanced by Better Feed from Ozh

Flight of fancy...now boarding!

My first thought when I saw this post by Glen Alleman was ”cargo cult“. 

I’m wary of concepts from hard sciences that find their way into business jargon, largely because the concepts become incantations.  It feels like we’re appropriating the prestige of science, just like a cargo cult’s “focus on obtaining the material wealth (the “cargo”) of the advanced culture through magic and religious rituals and practices.”

In other words, I cringe when I hear incantations like — “complexity”, “emergent”, etc. — as if the words in and of themselves suffice.   It’s nothing but meaningless superstition without insight and actions that solve problems or exploit opportunities.

Filed under: PMO Tagged: cargo cult, Complexity, Emergence, Glen Alleman

Some people have tried to argue that source code is a liability, not an asset. Apparently this “is now widely accepted”
and
“this is a very strong idea that has a lot of impact across the IT industry and in the way developers view and perform their day-to-day work”.

Really?

The argument, as far as I can follow it, is that while engineers are paid to help design and build bridges and power plants, as developers we’re paid to “deliver business value”, and…
“Source code is merely the necessary evil that’s required to create value”

Source code, the software that we create, is only a means to and end. The software itself has no value, or worse it has negative value, because it creates a drag on your ability to innovate and move forward. The more code that you have, the higher your maintenance costs will be, therefore…
“… the best code of all is the code that's never written.”

Michael Feathers, who has a lot of smart things to say about source code, joined in on this discussion. In The Carrying-Cost of Code he says that
“code is inventory. It is stuff lying around and it has substantial cost of ownership. It might do us good to consider what we can do to minimize it.”
He goes so far as to suggest a goofy thought experiment where “every line of code written disappears exactly three months after it is written”. The point of this would be to get developers and the business to understand that the “costs of carrying code are real, but no one accounts for them”.

Feathers reinforces the valid points about the drag that unmaintained or poorly maintained legacy code has on companies. Writing less code to solve a problem is a good thing – it’s (usually) more efficient and (usually) costs less to maintain a smaller code base. And yes there is a necessary cost to maintaining software and working with existing software and changing it.

But none of this changes the fact that software is an asset
If you build and operate a power plant or a bridge, you have to maintain it – just like software. And like a bridge or a power plant, a newer, more modern, better-designed, more efficient and simpler asset is better than a big, old, complicated, expensive-to-maintain one.

The “software is a liability” argument seems to be that it’s not the software that’s the asset, it’s the “features and options” – the capabilities that the software provides. This is like saying that it’s not the power plant (which a company spent millions of dollars to design and engineer) that’s a valuable asset to a company, it’s the energy that it generates. It’s not the bridge – it’s the ability to drive over water. It’s not the airplane, it’s the ability to fly.

Pretending that software has no value in itself is silly. Try explaining this to accountants (don’t depreciate the airplane, depreciate the ability to fly!) and IP lawyers and to investors who buy software companies for their IP. They all understand that software and the ideas embodied in it are valuable and need to be treated as assets. The ideas themselves are only worth so much, even if they’re patented. But the ideas realized in software, actualized and proven and ready to be used or (better) already being used – that’s where the real value is. And this is the value that needs to be maintained and preserved.

Software is more valuable than other assets
The important difference between software and other assets is that software is much more plastic than other engineering work. Software is “soft” – it can be changed easily and inexpensively and quickly. This makes software more strategically valuable than “hard” assets like a building because software can be continuously adapted and renewed in response to changing situations, and transformed to create new business opportunities.

Software has to be changed to stay useful. The problem is NOT that we HAVE TO maintain software and change it to do things that it was never intended to do, to work in ways that it was never designed to, to do things that we couldn’t imagine a few years ago. This is the opportunity that software gives us – that we CAN do this. This is why Software is Eating the World.

I have been at Wikipedia again. This time at the User Story page.  I didn't like the contents as usual, and this time I drafted a variation on the Wikipedia page and published it in the Business Analysts Handbook. A copy is recreated below for your interest.  It also serves well as a first post in the Agile Thursdays series.


Introduction

A User Story is a marker indicating a request for work to be done.

User Stories are often conflated with software or business requirementsbecasue on first impressions they look like requirements. They are actually independent things.

User Stories were first introduced to the world by the XP community in the late 1990s, although the concept of stories and narratives being effective tools for communicating requirements daes back at least into the early 1980s.

Important things to consider about User Stories 

• They are a token for doing a piece of work and are not a software requirement in the traditional sense 
• They are a 'trigger for a conversation ' and build upon the Agile Manifesto principle that face to face conversations are the most effective form of communicating ideas 
• A User Story is likely to evolve over time as people's knowledge on the topics area matures 
• Generally, when a software team starts work on a User Story a clear 'definition of done ' should be available 
• User Stories are ideally written on index cards or similar because of the value of visualizing the workflow , keeping them simple and osmotic communication . 

Card Conversation, Confirmation
The three essential elements of a User Story are the card, conversation and confirmation.

These are described below under the following headings.

• Card = Physical v Electronic 
• Conversation = As a Product Owner I want a template 
• Confirmation = Start with the end in mind 

Physical v Electronic
User Stories are typically written on index cards or post it notes because of the value of osmotic communications, the lightweight nature of the tool and because face to face communication is optimal for project team communications.

Many teams also capture User Stories in electronic media such as requirements management or test tools.

There are many purpose build product backlog management tools on the market.


As a product owner I want a template so that it's easy
Since the mid 2000's a 'common form' of User Story has become dominant. It is presented in the following form;

• As a [user type] 
• I want [an interaction+outcome] 
• So that [I get some form of value] 

The benefits of this templated form are real and tangible. An important part of both requirements management and workflow management is effective partitioning or dividing of the model elements into smaller parts. Diving the stories by the user type is a useful technique. Occasionally a feature or service will be identical for multiple users but more often than not there are differences, subtle or obvious, that the division helps surface.

The "I want" element generally describes some tangible interaction or feature. Because of this element a User Story is often conflated with a Use Case, a scenario or a feature. And it may well describe any of these or other thing.

Again partitioning is relevant and important here. But the main driver in this space is to partition the work into a small, independent pieces of work. (See the INVEST mnemonic.)

Software developers usually have a lot to offer in relation to requirements and how they should best be fulfilled. Often they have been constrained by a lack of awareness of the motivation for the requirement. It's also a common client failing to jump to solutions to early. Asking for the motivation in terms of business value helps everyone focus on what's most important in the story. SO explain why in the "So that" clause.

But the template has it's detractors.
By proving a tamplate in the first place you provide a platform for people to communicate in written form with the idea that the communication is sufficient and complete.

Unlike requirements a User Story is not a complete brief. It is aimed at being a trigger for a conversation and is purposefully incomplete so that the conversations can be had to further elaborate understanding collaboratively.

Start with the end in mind
A clear definition of done is important for User Stories as they re work requests. By being clear about 'done' teams are better able to determine when they have not yet met the minimum quality and capability thresholds, and when they have gone too far.

Typically the definition of done is created via a test case or acceptance criteria prior to commencing work on the user story. Early User Story advoctes simply used the trigger "This will be done when..." to stimulate the discussion on 'done. More recently the idea has been elaborated. From the same vector as the "As A, I want, So that" template comes Behaviour Driven Development (BDD.)

BDD is more than just a form for acceptance criteria. It is also a framework for managing stories and requirements more broadly. But it has also been adopted as teh dominant form for acceptance criteria on User Stories with the template;

• Given 
• When 
• Then 

Where given describes a starting state, when describes a trigger or catalyst and then describes the new state of being. This template form suffers the same strengths and weaknesses as the "As a I want" template.
Further reading

• Mike Cohn's User Stories Explained 
• Wikipedia on User Stories 
• c2.com on User Stories 
• ExtremeProgramming.org on User Stories 
• Scott Ambler on User Stories 
• User Story Template 

Related topics

• INVEST - A quality checklist for User Stories 
• Kanban - another concept for work tokens 
• Story Maps - a way of managing large numbers of stories 
• Behaviour Driven Development - Test thinking applied to stories
• Stories as Inventory - understanding the cost of too many stories (or requirements)

A reader asked why the lifecycle in Agile Lifecycles for Geographically Distributed Teams, Part 1 is not Scrum. It’s not Scrum for these reasons:

1. The project manager and product owner start the release planning and ask the team if the release planning is ok. The team does not generate the initial draft of release planning itself. In Scrum, the team is supposed to generate all of the planning itself.
2. The checkin is different from the Scrum standup and the objectives of the checkin are different. I did suggest to the teams that if you want to create a cross-functional team where the functions are separated, if you ask people how they are working together, you might help them work together. Sometimes those questions work, and sometimes they don’t. It depends on the team and whether the people want to work together.

I didn’t mention retrospectives or backlogs in my examples so far, because I took them for granted. Yes, both examples of these teams do perform retrospectives and have product backlogs. They also have agile feature roadmaps, which are on my list to blog about.

The real difference is the difference between a Scrum Master and an Agile Project Manager. A Scrum Master is not a project manager. A scrum master does not manage risk by him or herself. A project manager will take on the risk management responsibility without asking the team.

A Scrum Master has only allegiance to the team. A project manager has responsibility to the team and to the organization. That means that the project manager might feel torn when the organization pressures the project manager to do something stupid. (Although, I just downloaded the Scrum Guide, and the Scrum Master’s responsibilities have grown considerably since I took my CSM with Jeff way back in 2006.)

But agile provides transparency when the organization asks the agile project manager to do something stupid, so it’s easier to retain your integrity as a project manager.

Want to move a feature higher in the backlog? Change the feature roadmap with the product owner and then change the backlog with the product owner. I expect the agile project manager to collaborate on the feature roadmap and the backlog with the product owner.

Want to change the velocity of the team to please some crazed manager? Both the Scrum Master or the agile project manager protects the team in these ways:

• Explain that velocity is not a productivity metric
• Say No and explain why
• Play the Double Your Velocity schedule game
• Or choose some other way to remove this management obstacle.

Agile makes it easy to protect the team. The question is this: does the Scrum Master have other responsibilities in addition to protecting the team or is the Scrum Master full time? An agile project manager tends to be full time on a geographically distributed team. Even on a geographically distributed team, a Scrum Master is not seen as a full time position. Bless their tiny little hearts, managers don’t seem to understand that transitioning to agile, especially for silo’d distributed teams with different cultural norms is non-trivial. They will make room for a project manager, but a Scrum Master? Oh no. Makes me nuts.

Cut corners on quality? I don’t see how. The team doesn’t meet the acceptance criteria on the stories and doesn’t meet their criteria of done for an iteration, and can’t show a demo. How does that serve anyone?

Help a team go faster? This is the one place where a project manager may have an edge over a Scrum Master, and that’s only because of education. An agile project manager is a project manager. That means he or she is actively studying project management, which means he or she is studying lean also, looking into work in progress. (I realize many project managers do not actively study project management.) I have high expectations of an agile project manager, and that is to limit WIP, work in progress, to measure cumulative flow. But, Johanna, that’s a lean project manager. Yes, that’s correct. Why not use all of the tools available to us at all times? This is not to help a team actually go faster, but to provide feedback to the team about their WIP. If everyone takes a story at the start of the iteration and everyone always works on their own story, it’s likely the team is at the slowest possible velocity. It’s worth knowing that, or at least retrospecting about the data. A project manager will gather the data. A Scrum Master, especially one who was not a trained project manager, may not know to gather the data.

I have nothing against Scrum Masters. Some of my good friends are CSTs (Certified Scrum Trainers). However, they are not all project managers, and have not been project managers, and have not studied the field of project management. Some have been. And, the real issue is this: In a two or three day workshop, they cannot convey to a person who may or may not have been a practicing project manager all of their project knowledge.

Organizations do not always pick project managers to be Scrum Masters. And, with good reason. Some project managers are command-and-control project managers. I suspect back in my long-ago past, I was. I gave it up long ago because it didn’t work. Some people never gave up command-and-control project management. Those people are not good project managers for agile projects. They are terrible project managers for geographically distributed projects, where you must work through influence.

You can have self-managing teams that are geographically distributed. You can have self-directed teams that are geographically distributed. But, they don’t start that way. They evolve into self-directed and self-managing teams. They start as management-led teams.

And, especially when they are silo’d teams, they need the coordination of a project manager, someone who will manage the risk between the silos, and someone who has the organizational backing, and yes, someone who has the allegiance to the organization to say, “We need to do this project” to write the project charter.

In a geographically distributed team, the agile project manager writes the project charter either with the team, or as a strawman for the people to edit and approve. Shane and I recommend that the people get together to write it together. We like it if people get together in person. We know how rarely that happens. (Penny wise, pound foolish.) So we teach people how to write a project charter when they are divided in space.

Because until there is a project charter, there is no organizing principle for the silo’d teams. Those developers in France, testers in Belarus, product managers and project manager in San Francisco, they all need something to coalesce around. The charter, which includes the project vision provides that. The iterations provide the project heartbeat.

So, that’s why I don’t think Agile Lifecycles for Geographically Distributed Teams, Part 1 is Scrum. It’s close, but no cigar. I respect Ken and Jeff’s work too much to call it Scrum when it’s not.

Now that I’m mostly recovered from my cold, I can continue the series about lifecycles.

(Want to learn to work more effectively on your geographically distributed team? Join Shane Hastie and me in a workshop April 17-18, 2012.)

Eminence based medicine — The more senior the colleague, the less importance he or she placed on the need for anything as mundane as evidence. Experience, it seems, is worth any amount of evidence. These colleagues have a touching faith in clinical experience, which has been defined as “making the same mistakes with increasing confidence over an impressive number of years.” The eminent physician's white hair and balding pate are called the “halo” effect. — from "Seven alternatives to evidence based medicine," British Medical Journal, 18 December 1999.

When I hear about new and innovative processes, technologies, or theories of how to cure the world's ills - from energy to new management techniques, I start my quest with the question...

Ya got any evidence your idea actually works in the domain I'm currently working in?

No? Well go get some and come back, I'd love to see it work here. Many times I never hear from them again.

For those of you who would prefer to read rather than watch the video, here’s the transcript:

Elizabeth Harrin: I’ve come to Victoria in London and I am looking for the Microsoft offices. I’m going to be chairing a round table discussion there today about project management in the collaborative age, and the things that are making our new ways of working, and the ways that we’re doing project management change, like globalization, virtual teams and things like that.

So I think that would be quite interesting to hear what the practitioners who are coming are saying about how their working life is changing, if indeed it is. And also we’ve got some software suppliers who are coming as well, so it will be interesting to see what they think the future of technology and the tools are. So I’m going to go and find where I’m supposed to be now.

This pointy building here is Microsoft office on Victoria Street. So I’m about to go in and meet the people from Project Magazine who are hosting the round table today.

At the round table:

Richard Gordon (Microsoft): …in a few days to a wider audience. And so it’s not necessarily about finding a common format for things. I guess coming back to the point earlier where there are lot of formats and we’re not necessarily sure whether it’s Facebook, Twitter, blogs, it’s this, that and the other, but allowing people to be able to bring whatever it is that they want to do, however this project is going to be managed whether it’s very rigorously or whether it’s much more open and fluid, to bring people together to share information and ideas.

Fredrik Kellerman (ProjectPlace): So I think very much our approach is that we believe in opening up, allowing people to see the overall progress of the whole project. And actually for their customers to invite their stakeholders, because if the stakeholder is involved in the project and they can see the progress then there are no surprises, then you can handle issues before they turn into massive proportions.

Anne (project manager): There is so much information out there. It’s getting the right bit of information with the right contact which is where I think it needs…

James (project manager): …And that’s where face to face can often help, I mean with the number of problems I’ve seen just in the last couple of months with misunderstood emails or any electronic message without that context is…I’ve been bitten too many times…

Elizabeth Harrin: If we’re seeing that the step change… This all comes back to communicating to stakeholders and yes, okay, that does mean they will have to have difficult conversations with sponsors and senior executives in organizations to try and bring these collaboration ideas to the forefront and maybe we’re not empowered enough to be able to make a decision to go out and buy new tools or design new ways of displaying information. But we can at least be aware that it’s happening and ask the right questions.

Benjamin Sarkka (Improlity): Oh we need to do this and it’s really slow as often this kind of integration projects are really expensive and time consuming, and there are so many IT projects that fail and they have bad reputations. So I think there is still lots of work to be done and meanwhile, there needs to be the right tools to enable project managers to go on. We can’t wait for the perfect tool to arrive.

Editor of Project Magazine: That’s a good point. On the question of the right tools I’m just interested in the views from the project managers around the table: What do you think of the tools that are available at the moment? Do you think they’re up to the job? Do you think they are the right tools? And also from the software providers: Are project managers really maximizing those tools? Do they really understand the capability and the potential that’s at their fingertips?

Matt (project manager): Personally, I know and understand technology and things, but listening to you guys, I’ve realized straight away that there are opportunities there that I don’t even know about in terms of collaborative tools. I’ve worked all my career in traditional engineering type organizations, and email now, that’s the de facto standard for written communication. You get the odd person who might want to go into instant messaging with you but virtually everyone wants to email. And the volume of email you have to deal with, that you’re sending and receiving is just ridiculous, we’re at saturation point now.  You need to find better ways to get those messages across.

Paul Major (Program Framework): Yeah! What I’m saying and picking up on the PMO conversation in that context I think is really interesting because PMO’s potentially have the challenge of being perceived as more of an administrative function. I think that is changing.

Two of the organizations I’m working with at the moment we’re designing what does a global or enterprise PMO look like? And it’s actually the antipathy of the admin piece. It’s moving it to something that’s much more value added in strategic space, kind of almost sits as an adjunct to the chief exec’s office and it’s kind of almost that space of the strategic director or the strategy director sat in in the old world way of looking at things. But one of the things that those organizations I see are doing is starting to look at actually what’s the role and career path of the project management professional.

Later…

Elizabeth Harrin: I’m back now from the Project round table that was hosted by Project Magazine and Microsoft. And it was really quite an interesting way to spend the morning. We had suppliers there, software vendors from Improlity, Microsoft and Projectplace and we had practitioners, real project managers who are using these tools, and we talked a lot about collaboration and the problems that project managers have. Some quite interesting topics came out. I’ve just got a few notes here to share with you.

One of the guys said that project management bleeds into a number of different tools which I thought was really quite an important point as we’re trying to match up different types of technology. Complexity then increases with everybody wanting to know what’s going on at the same time and again, technology can help with that.

As part of our collaboration challenge is to work out how we deal with the fact that we need to provide different information to different stakeholders at different moments in time, and that gives us a tension between control and collaboration. So we want to be able to share everything or share what we can, but we also need to apply project controls so there’s a requirement for security. There’s a requirement for audit trail. There’s a requirement to not share confidential information with people who shouldn’t see it. So we talked a lot actually about the tension between collaboration and control and where the project manager’s role was in improving transparency while still managing to keep control of what was going on in the organization.

I think we generally concluded that technology is not the answer to some of the problems that we are facing as a discipline. But that it is there to help us deliver to the challenges that we’ve got and are currently facing like globalization, the requirement to be more green, virtual teams, distributed working and the challenge of having five different generations working together in the workplace for the very first time.

So technology is there to help us but talking to the vendors, what we realized was that the tools are so far advanced and very few project managers are actually using the full functionality of the tool, partly because the tools have become very generic. Oh, that’s not really the right word, they’ve become feature rich. Project managers are perhaps picking and choosing what is relevant to their project and their environment. But from a vendor’s perspective, they have to make a tool that suits all projects and all environments and they’re constantly getting feedback from customers as to what they want to see included in those products. So that was quite an interesting point.

The conclusion we came to really is that technology is there to help us be the next generation of project leaders. We just have to get on and actually do it and step up and we are being pushed in the direction of being able to want to embrace this new technology by a number of different forces including the consumerization of technology, of IT and gadgets and so really, we’ve got a way to go before we are these inspiring project leaders full of innovative ideas really driving through change in our organization.

As a whole, I’m sure some people are already doing that now and the role of the PMO in that is to become a strategic centre of excellence to support project managers in achieving all of those goals. So really, quite a lot of stuff came out. We talked for 2 hours and that’s just the summary really of some of the key points. But yes, quite an interesting day.

No related posts.

I've been doing some research for a project at work on Critical Chain (a result of my articles <here and here> for Projects at Work being noticed within the company). I started by re-reading Goldratt's book Critical Chain. If you haven't read it, I recommend it. It's written as a novel and is an easy read, but still has some good content.

What I've been pondering is how to use Critical Chain in Program Management. I've come across some agilist talking about Critical Chain and Theory of Constraints (TOC-Goldratt's work in manufacturing). Dave Prior recently wrote an article for Projects at Work on transforming to agile where Drum-Buffer-Rope (part of TOC) was mentioned. There was also Mike Cottmeyer's mention of Theory of Constraints I mentioned in a previous post.

So is Critical Chain the answer to scaling agility? When Mike talked about scaling agility at the PMI North America Global Congress last year, he argued that Scrum isn't the answer to scaling agility. Some other tool that can address constraints needs to be used. I think many of us have experienced resources being the big constraint in a program. Critical Chain provides an answer to this.

When using Critical Chain, your first step is to identify the constraint. Let's say it's the number of U/I designers you have. You can't run four projects in parallel because your two designers will be constantly pulled back and forth, and we all know multi-tasking is bad! Critical Chain would say that you need to delay some of your projects to address this constraint, even if this means other resources are idle.

It sounds simple, but will it work? How else can you address constraints across a program? Do we also need to be concerned with buffers? Goldratt spends a lot of time talking about buffers on the project level, including resource buffers. But how does this scale to the program level? Do we need program schedules with resource buffers? I'm going to keep digging in. If you have any suggestions, let me know.

Glen Alleman posts here on the need to ensure that analogies fit the domain.  He notes a common problem with metaphors, especially those adapted from math or science.  They sound right to the layman, but are off-key to the expert.

This insight provoked a few thought on analogies in the ERP world.  We often use analogies to convey the complexity of ERP: changing the engines on an in-flight 747 is very popular.  It sure sounds tough, doesn’t it?  And the image is powerful and vivid, but does it have anything to do with how ERP really works with your business?  Also, who has ever done something like that?

I’ve found that it is much more effective to leverage metaphors that are a bit more concrete.  For example, I’ve found that a conversation about ERP as “a model of your business that operates in real time” gets me down a better path.  We can then move on to concrete visualizations that model — from Tinker Toys, to Lincoln Logs, to K-Nex, to Lego, to Erector Sets, to HeathKits — that come from the participants, not from me.

Filed under: PMO Tagged: analogy, Data Model, ERP, Glen Alleman, Process Model, SAP