Introducing Innovation Story Walls

An excellent and inexpensive tool for developing innovations where you work is using Innovation Story Walls. The scope of this blog topic is to offer some ideas on how you could and should implement these story walls. Many of us already know innovation makes a difference. It’s the:


• Key to survival and growth for all companies around the world,

• One of the highest sources of value creation,

• Diversity of ideas and sources of ideas that makes this so valuable, and it’s

• Typically a bottom-up phenomenon.

This has been proven over and over again in published research journals over the years, and this is our opportunity to expand on the innovations already identified via the Eureka portal.



No one, just because their role or has the market cornered on innovative ideas. The reality is that innovative ideas can come from anywhere and a lot of companies are recognizing that. It’s all about collaboration to crate new ideas because:

• Sometimes somebody has a great concept idea but no idea how to get from ‘here’ to ‘there’,

• Sometimes somebody has an idea to contribute that will help take a good idea and make it a better one but isn’t necessarily certain how to offer or contribute that idea,

• Sometimes somebody is shy about the concept idea they have or adding their 2¢, and

• Sometimes somebody has an idea how to get from ‘here’ to ‘there’ and just wants to open it up to others to make it more complete by offering any ideas they haven’t though of yet.


Now to the meat of this post ---

1) The objective of this tool is to (at a concept overview level):

• Publicizing what you’ve done , and

• Publicizing what you’d like to get done

It’s the latter of these two we’re interested in this post.

~ AND ~

2) Determine:

• What prerequisites people believe need to exist to implement the above and make it successful . . . .

• From and for managers and the leadership team(s) and

• From and for everyone else too

• What governing rules or constraints do you want in place? – i.e.

• Are anonymous story cards acceptable?

• Can people move or remove story cards that already exist?

• Do people want to use thread or strings to tie strong cards together or how will you string story cards together into a complete story?

• etc

• Where should innovation idea themes come from or should we have any at all?

• Should there be a maximum number of innovation ideas on the board at any one time?

• How do innovation opportunities can be added? – i.e.

• Should there be a spot on the wall for ideas in queue?

• What is the maximum time an innovation opportunity will remain up on the board and active . . . .

• Before it’s nullified / rejected,

• Before it’s formalized, or

• Before it’s removed due to inactivity

• Do you want to score ideas based on interest factor or some other criteria?

• Where the physical placement of the story boards should be in the workplace

• Which group(s) should govern this activity – i.e. who do people go to if they have questions?

• Who transposes the story cards into some on-line form or whatever before they are removed from the wall?

• Etc.


Need more convincing?

Two good, on-line articles on this topic are available at:

• http://www.forbes.com/sites/work-in-progress/2011/04/01/how-to-tear-down-the-walls-to-business-innovation/

• http://www.cognizant.com/business-consulting/Site%20Documents/fourwalls%20exec-sum.pdf

Classes or Categories of User Stories

Please see below. I couldn't easily find a site that has all of these definitions together in one spot. 

Epics 

Epics are large user stories, typically ones which are too big to implement in a single iteration and therefore need to be chunked into smaller user stories at some point before the effort required to complete them can be reasonably estimated. 

Themes 

A theme is a collection of related user stories.  For example, for a university registration system there might be themes around students, course management, transcript generation, grade administration, financial processing. 

Themes are often used to organize stories into releases or to organize them so that various subteams can work on them.   

Spikes 

The purpose of a spike is “to figure out answers to tough technical or design problems”. Spikes are considered useful when a more accurate time (and cost) estimate is required for an upcoming piece of work. 

Foundation development, investigation work and the set-up of a lab environment so it's ready for use when a software build becomes available for testing are all good examples of spikes. 

User Stories 

A user story is a high-level definition of a requirement, containing just enough information so that the developers and testers can produce a reasonable estimate of the effort, potential risks, key complexities, etc that need to be considered and are required to implement it. 

Tasks 

Tasks are single units of work such as checking out a code branch or installing a build in a test lab. 


Would you like this elaborated upon further? Just let me know. 

Us & Them ... Really

My kids and I were going through boxes of clutter this weekend to see what we could donate to the Sally Ann or just purge, and free up some space in the process. We did some sorting though too; to make sure we were not inadvertently disposing of something we wanted to or should keep -- like income tax receipts from 2009. :-)

During that effort, I came across the following hand written note; don't recall where it came from or what the original context was, and for all I know its a note for a speech given by the Dalai Lama. Regardless, I've seen a lot of "us & them" conflict, me-me-me, not my problem types of behavior and discussions as of late on-line, in the news, and elsewhere in multiple contexts. And the more I thought about it, the more this note seemed to apply to all of them whether it was a topic about implementing Agile strategies, coding versus testing work, leadership practices, or even some so-and-so on the news that didn't have enough forethought in his head to think "gee, I'm having un-diagnosed seizures (as reported by family members). Maybe I shouldn't drive!" The last example resulted in the death of an 11-yo girl. I agree; this is an extreme example. It's also a very good example of how serious the following applies. Thus, at the risk of being perceived as all philosophical and such hopefully this 'awakening' and 'it' noted below comes as some measure of serendipity the next time(s) any of us directly or indirectly experience those divisive rather than teaming behaviors.

Who are they? It's you, me, your family, friends; all of us. That is until we've experienced the awakening because its already happened, its about to happen to us, or some one we truly care about. For a lot of us, we awaken after it's happened and we struggle harder than we ever could have imagined. For some of us, we awaken while its happening and maybe there's a chance to stop it right there and then. For a few of us, we awaken before it happens and can stop it before it begins. The only question left is what are you doing to help awaken those who are still asleep, to help those who still have a chance to avoid or overcome the chaos.

Happy thoughts.

P.S.

For me, 'awakening' in the above refers to the known awareness, the epiphanies we all have at one time or another that help shape who we are as people and members of a society. Things that stay with us for the rest of our lives even if we don't recall exactly why. 'It' can be anything we encounter or endure.

Scrum Master, Project Manager ... Po-tay-to, Pot-at-o

The Ignite! Newsletter recaptured earlier work in a December'08 article entitled "The Stabilizing Effect of Good Leadership" where they noted companies that best deal with adversities and workforce anxieties caused by financial uncertainty cycles and layoffs are those that have:

• A clear and compelling vision 
• Passionate and engaged employees 
• Strong servant leaders 

I'd like to extend that to the decade long and ongoing debate over the differences between the Scrum Master and Project Manager roles (or titles); if there even are any differences to be quite frank. Many others in addition to myself agree there is too much debate and wasted energy on this topic. A topic I would suggest is now a rather distasteful topic simply driven with a desire to validate their personal definitions of "success" rather than focusing on how they can add ever greater value over time. When people behaving in that prior way finally realize they should embrace instead of fear the grey-scale reality that life is the pigeon-hole B&W role definitions will finally cease. Then we can all get on with adding value.

A tangible example I'd offer is from the Disney corporation. People are cast members; plain and simple. Of course they have roles like managers, Scrum Master, Project Manager, Developer, Tester, etc. And I suspect there is also a good deal of focus applied to ensure each cast member has a mutual respect for other cast members and their roles. Based on my experience in the business world and that of various mentors over the years the more a company touts having mutual respect in the workplace the less likely this is actually to exist. I suspect this is a carry over from school days behavior (and maturity); the guys who garishly announced they got 'it' on their date the night before very typically didn't get anything of the sort.

That said and getting back to my Disney example; one of my favorite quotes is from Walt Disney himself. He was once quoted from his berating of an executive who was behaving poorly to a gardener working outside his office. Walt called that exec into his office and expressively told him "There's only one tyrant in this place; and that's me!" ... meaning that we all do our part and the parts working collaboratively together doing what they each do best are what create the greatest value. Walt was not a tyrant; that I've ever heard of from any reputable source.

I'd like to offer a personal example too. My current income source is for a position (role) labeled 'Project Manager'. My job, however, is to enable, motivate and empower groups of people so together they are as effective and productive as they can be to create, enhance and innovate new software, business practices and release initiatives to meet customer needs and expectations as efficiently as possible. I prefer to do this using whichever Agile methodology or framework best suits (aligns to) the initiative. Whether I'm called 'Project Manager', 'Scrum Master', 'Joe Schmoe' or any other label is really inconsequential to doing my job.

Kudos to Robert K. Greenleaf (1904–1990) and Ken Blanchard for all their inspirational work and Steven Starke for his article which inspired this post.


References:

Appelo, Juergen. "Management 3.0": Chapter 7

http://www.greenleaf.org/

http://www.blanchardinternational.com.au/Ignite/Ignite_Article.php?Doc=17&Seln=4

http://www.projecttimes.com/articles/lets-end-the-debate-over-scrum-master-versus-project-manager.html 

Can Agile methodology work in very small Dev teams?

This is a great question and topic and one so few ask!

 

The question is from a LinkedIn thread where the person posing the question works in a small dev group of 1 project lead, 1 developer and 1 tester; all who need to multitask on concurrent projects.

Scaling larger seems to be the most common theme, but what about scaling smaller? I’ve worked in companies where the total workforce was no more than a few dozen and the entire R&D team included maybe ten people. I’m certain there are a lot of these environments with the number of start ups that exist in just the region I live alone.

The first gut reaction to this question may be Sure! Of course! If you want to strive for …

• Constant communication to collaborate with your customers and users,
• Improved code quality, unit tests, and disciplined development,
• Constantly improving and working to get better,
• Delivering actual value rather than meaningless overhead for your customers and business,
• Delivering working software that meets your customer's needs and not just their wants (and sometimes worse; what they actually asked for!),
• etc …

but I suspect the question goes a lot deeper than that. If people in these types of work environments didn’t already know that they wouldn’t even be thinking about Agile let alone asking about it.

I also suspect that in most of these environments there are a lot of Hem and Haw type of people that debate the problem but ultimately take way too long to make a decision to move in a new direction ultimately they already knew deep down would benefit them. And ultimately, in too many of these cases, they become an ‘also ran’ company to their competition as a result. I’ve witnessed far too many small, medium and large companies do just that. And the one thing they all have in common? They’re all shadows of their former selves; if they actually still exist that is.

Now, that ground work laid, say you work in an environment where out of some necessity you have PMs, analysts, developers, testers, etc all multitasking across multiple projects even after study after study has shown the ‘productivity of multitasking’ to be no more than a mere fallacy at best and fooling ourselves at worst.

The problem actually comes from how the situation is being looked at rather than the situation itself; remembering the old adage “when you’re a hammer; everything looks like a nail.”

The reality is you can actually have everything you’re doing today and still achieve the above. And now some of you reading this are getting a bit incredulous, but I am in earnest here. Just bear with me a little further.

The first step is to get back to basics and look at the objectives of the Agile Manifesto, and stop looking for a tool or a process that your people are supposed to then subscribe to . Imagine, if you will, a small R&D group where everyone there has:

•  A specific and unique set of technical skills with minimal overlap between people.
• Multiple projects going on all at once mainly out of necessity rather than a lack of strategic planning. Example: Ever try to tell your spouse that you decided you were only going to do the dishes for the next month and they could do everything else around the house? Yeah, I bet that didn’t go so well for you either. Same thing here.
• A team of 2 or 3 people they work with at any one time.
• A strong desire to have some semblance of order in the chaos – including all the developers, testers, etc. Thus, user stories and their priorities are hardened each month with multiple sprints (2+) within that month; effectively making the plan for that month a scrum of scrums.
• A need to be fully utilized because that’s what keeps them motivated and what the business needs to stay profitable.

The second step is the phrase ‘Scrum is Agile; but Agile is not Scrum” – i.e. there is no singular "Agile Methodology"; there are actually 18 Agile methodologies and frameworks and counting at my last check, but I digress. That said, nothing but kudos to Jeff Sutherland, Ken Schwaber, Mike Cohn and all their predecessors. 

 

The third step is to look at kanban, lean, and probably one of the xDD methodologies to determine which best fits with your work environment’s existing culture. The latter part of this last sentence being very important as noted described in the picture below.

Here is a very brief example to show you what I mean.

 

Choose TDD, BDD or FDD to execute on that – Google them (just don’t go overboard and over-think this part) and choose one that looks like it currently approximates your current workplace culture.

1. Create a backlog of user stories, prioritize them, and post them in columns by the projects they belong to.
2. Figure out what ‘potentially shippable’ new feature—functionality or new block of code module(s) you want to exist at the end of the month.
3. Post the relevant story cards on a story wall or kanban board so what you’re doing has visibility.
4. Let everyone know that they alone own and are accountable for the story cards they selected to work on, they need to share progress on that card with everyone else, and they need to provide more granularity between ‘started’ and ‘done/complete’. AND you are there to support them in your leadership role to enable them to do just that.
5. Go!

It’s really that simple. Now go try it for yourself, or post a comment and let me know what you think.

 

Tracking and Monitoring

Always trust but verify too. That light at the end of the tunnel could actually be an oncoming train.

If ... (Good Advice)

Good advice even 100 years later; for any project or program management professional; male or female.

http://www.goodreads.com/work/quotes/34072-if-a-father-s-advice-to-his-son

1 Minute Intro to Programs & Projects – Their Definitions and Descriptions

"History is lived forward but is written in retrospect. We know the end before we consider the 

 beginning, and we can never recapture what it is to know the beginning only."

~C.V. Wedgwood

The quote above got me thinking that as unlikely as it may seem to those of us already in the profession there are still a lot of people who are just beginning to learn about it for any of a number of reasons. Thus, following the theme of this site, the following information is a one minute introduction into programs and projects. The source is from the PMI (Project Management Institute) standards and that is an excellent source for many publications of these topics.

A project:

• is a temporary endeavor undertaken to create a unique product, service, or result (temporary does not necessarily mean short in duration)
• has a definite beginning and end
• ends when the projects objectives have been achieved or when the project is terminated because its objectives will not or cannot be met, or when the need for the project no longer exists
  

A program:

• is a group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually
• may include elements of related work outside of the scope of the discrete projects in the program
• also includes components for managing effort and the needed program infrastructure
  

A portfolio:

• refers to a collection of projects or programs and other work that are grouped together to facilitate effective management of that work to meet strategic business objectives
  

Thus, as shown in the drawing above:

• Portfolios encapsulate Programs
• Programs encapsulate related Projects
• Projects encapsulate deliverables
• Deliverables are comprised of tasks that need to be efficiently and effectively accomplished in order to realize all of the successively larger views and management towards realizing the required business objectives
  

Projects and programs are carried out using project management and project leadership techniques.
Project management:

• is the application of knowledge, skills, tools, and techniques to project activities to meet the project requirements
• is accomplished through the appropriate application and integration of the 42 logically grouped project management processes comprising the 5 Process Groups
  

Project leadership:

• focuses the efforts of a group of people toward a common goal and enable them to work as a team
• establishes and maintains the vision, strategy, and communications
• motivated and inspires project participants to achieve high performance
• fosters trust and team building
• influences, mentors, and monitors
• evaluates the performance of the team and the project
  

Thanks to all my family and friends who have offered suggestions to improve the launch of my blog! Updates are in progress and please keep those ideas coming!

But let us all also take some advice from www.dilbert.com and December  3, 1999:









:-)

~Leyton

What Went Wrong? - Humour

Okay -- enough of the long posts -- at least for one day. ;-)

Here's a bit of project management humour about the importance of planning and communication in any project. It's an oldie but a goodie. :-)

This is the story of four people: 

Eyerybody, Somebody, Anybody and Nobody. 

There was an important job to be done 

and Everybody was sure that Somebody would do it. 

Anybody could have done it but Nobody did it. 

Somebody got angry because it was Everybody's job. 

Everybody thought that Somebody would do it. 

But Nobody asked Anybody. 

It ended up that the job wasn't done 

and Everybody blamed Somebody, 

when actually Nobody asked Anybody.

~Joan Esch

Good User Stories … continued

I was thinking about this and thinking “Well that's not very nice to leave people hanging like that about the 'S' in INVEST and what defines “small”. Especially when I realized I forgot about a psuedo-acronym.

Good User Stories enable the team members and project's stakeholders to INVEST in what is being set as an objective.  Put another way, they communicate functionality that is of value to the end user that promotes further communication when the story is being worked on. And like I said in my last post, 'small' is subjective and because of that the definitive answer is 'well that depends.' Seriously though, in preparation for this post I Googled 'agile INVEST acronym' and it returned 'About 203,000 results'. I Googled 'user stories' and it returned 'About 1,310,000,000 results'. That's how subjective this is. No worries though, it really is a lot simpler than all that. 

If you really wanted to you could probably scan through some of those results and quickly find definitions like 

• anything longer than 2 or 3 or 4 weeks is when it becomes a them or an epic
• small enough to fit within a sprint or iteration and deliver value from it
• the right size is usually about a work week
• shorter than a week is too small 
• a day or two
• and so on and so forth

And you know what …. yup, you got it, they're all correct …. for them! The reality is that when user stories are being written and sized (size 'small'; please :-) ) there are still four more factors. Those factors are time, work effort, risk and overall complexity; I'll save “complex versus complicated” for another post. :-) 

Time is the easy one and because it's easy that's where a lot of people new to Agile stop … and then they have schedule overruns just like they did in the traditional (waterfall) way of doing things. 

Work effort is the first factor (of these four) that starts to ask people to think about who and which roles need to be involved to deliver something of value. After all, if your stories are specific to one person or role you've probably just created broad, high level tasks and labeled them user stories. 

Risk – well this could be a book all on it's own; well what do you know … it is! ;-)   For now, let's just say big risks should equal smaller sizes unless there is a high tolerance for delayed feedback.

Overall complexity as I eluded to above is at least another post and are books all to themselves when you start thinking about complex adaptive systems and other systems theories. For now, let's just say the harder it is to describe the story on a 3x5 card so your intended audience understands what is being asked for the more complex it is.

Oh, that missing pseudo acronym? It's the 3C's – Card, Conversation, Confirmation. Just click on the link for the details in the Agile Alliance Guide.  :-) 

GOOD USER STORIES

Projects start with customer requirements; or hopefully they do and out of the Agile training available via consultants and on-line we usually learn a new acronym or are reminded of one we previously heard. Have you heard of any or all of those below? What about others? Can you share?


Good User Stories enable the team members and project's stakeholders to INVEST in what is being set as an objective. The acronym and a question you can ask of yourself and others to determine if it really is can be found below.

• Independent -- Does this user story overlap with other user stories in your backlog?
• Negotiable -- Does it cover the essence of the objective or is it an explicitly defined contractual obligation?
• Valuable -- Does it actually add value, or is it something somebody wants done because that's the way it's always been done?
• Estimated / Estimat-able -- Is it clear and concise enough so the team members who need to be directly involved know what the expectations are? Do they agree, and can they paraphrase back what's been asked for?
• Small -- Yes, this is very subjective. We'll cover this in a near future post.
• Testable -- Is it vague or can unit, feature-function, and system tests (as applicable) be defined and the test results be objectively validated?

There is an acronym "SMART" for creating effective goals; and user stories.

• S – Specific -- this relates to the 'INV' parts of INVEST
• M – Measurable --  this relates to the 'EST' parts of INVEST
• A – Achievable -- this asks something INVEST doesn't ask. Do the people with the required skills, processes to follow, and tools (i.e. resources) exist to realize what's being asked for?
• R – Relevant / Realistic -- this asks whether the user story actually even fits into the scope of the larger backlog and project objectives.
• T – Timely / Time-boxed -- this relates to whether or not the story is appropriately estimated and prioritized.

ADAPT

• Awareness of room for improvement -- Do people want whatever this is going to produce?
• Desire to change -- Do they care or are they resistant to what this will produce?
• Ability to work in an Agile way -- i.e.: This is going to be a challenge if the people involved are used to a command and control style of management.
• Promote successes along the way to build momentum and get others to follow -- Does it?
• Transfer -- the knowledge of the impact of this so it sticks in people's minds and they want to keep doing this.

DEEP (for Product Backlogs) by Roman Pichler and Mike Cohn

• Detailed -- appropriately 
• Estimated -- see above 
• Emergent -- new items emerge based on customer and user feedback, and they are added to the product backlog. Existing items are modified, reprioritized, refined, or removed on an ongoing basis. 
• Prioritized -- are most important and highest-priority items are implemented first 

To ensure that the product backlog is DEEP, we have to regularly groom it. Grooming the product backlog is an ongoing, collaborative process that involves the product owner, ScrumMaster, and team as well as stakeholders.

All these factors (and aconyms) are important for the best user stories because ....

• As a customer, I have certain expectations on the functionality and usability of your product, and if you want me to buy your product over somebody else's ...

• As a stakeholder, I have needs to be met so what the project team produces I can inform, communicate and/or sell about on my own, and not inappropriately commit the product to doing something it doesn't actually do.

• As employees at different locations in different time zones the way this project is managed better work for me too.