Sunday, December 18, 2011

Focus on the Customer


What does it take to have a first rate customer experience when there are more customers than sales representatives?  Yes, this means there is going to be some form of wait, a queue.  Here is my comparison of experience at the Apple Store to that of the restaurant, CheeseCake Factory which we went to right afterwards.

At the Apple store we were put on a wait list to see a representative (the greeter used a text description and my wife's name to put her on the list explaining that the next available person would find us, as we browsed).  I asked what the description was, and this is how my wife was described: "tall, with long hair, in a jean jacket with multi-colored scarf".  I suggested that they had the technology to just snap a picture and attached it.  She said there might be privacy concerns with that.


We browsed and found the item we needed (a Mini Display Port - HDMI adapter).  About the time we had found it an Apple person (wearing a red shirt for the holidays) walked up and asked for Tracy.  We handed her the item we found and she checked us out immediately.

At the restaurant we got on the wait list and received a pager.  We went to the bar to wait and have drinks for the 15 minute wait (got a separate bill for the drinks). When the pager beeped we went to the greeter desk and then had to wait there again for the line of people being seated (4 parties ahead of us).  After seating and a lovely lunch, we paid again (a separate bill for the meal).

Now which business has a smooth process that is customer focused?


Wednesday, December 14, 2011

Visualize Your Problem Domain

Do you innovate new ways to visualize your problem domain?

The health care field is constantly using technology to visualize their problem domain.  They teach with color coded pictures, pink muscles, red arteries, blue veins, yellow nerves, etc. Yet the actual patient doesn't arrive on the surgens table with this color coding - YET.  They can do quite miraculous tricks with imaging (x-Ray, CT Scans, MRI, etc) and some imaging techniques are in real time.  Here is a video of the latest technique I've seen.  To visualize the problem.



I love the history and context Ms Nguyen gives us in this video.  The reason for surgery theaters to be where their were in old buildings.  Now with electric lights they can be in the basements, many times they are because of the heavy equipment they contain.

Apply this to the domain of software development.  Yes, we also use color coding to visualize the field, we have IDEs that give unique color to constants for example.  Yet we can not yet tag a bug with a florescent and shine a light across 10,000 lines of code to see how many times it has been replicated.  Or can we - have you created a florescent bug tracker?

Tuesday, December 13, 2011

Yes - You Need a Full Time Scrum Master


Many organizations adopting Scrum ask these questions.

  • Do we need a full time Scrum master for each team?
  • Why do we need a full time Scrum master, can't they do other roles also?

Now allow me to give you the answers: 
  • Yes, you need a full time Scrum Master.
  • Why - watch the video.
Let me explain:

Yes, you need a full time Scrum master, because they will be constantly watching for the actions of the team.  Making sure that the team member are working in flow as often as possible.  This is a full time job.

Why can the scrum master not do other roles on the team? Because of the human ability of selective attention.  First let me show you a video - a little test of your superior ability to follow instructions.  Perhaps you've seen this video - if so, just play along, maybe you will be surprised at how well you do on the test.

The Monkey Business Illusion

Now do you understand why we need a Scrum master watchhttp://www.infoq.com/articles/case-dedicated-scrum-mastering out for impediments all the time.  If they are tasked with doing something else, I'm sure they will miss the obvious impediments the subtle changes in the team members and the environment.

Here is Jeff Sutherland's reasoning (from Scrum Development Yahoo group):
"One of the leading Agile teams in software development asked me how to go hyperproductive. I was their coach as my venture group had invested in them. They had a fuzzy ScrumMaster definition and it was not clear who owned this role. I told them to get a ScrumMaster. The experienced team thought they were better than that and could never go hyperproductive. A new team was formed with a ScrumMaster which immediately went hyperproductive."

"So a lot of teams that think they don't need a ScrumMaster are a long way from 10 times the performance of a waterfall team. This was the design goal for Scrum and every team should be getting a 10% velocity increase sprint to sprint until they hit that number."

"Teams without ScrumMaster's don't do this. Usually they are flatlined and will never reach their full potential."

  --  Jeff Sutherland
Have you heard of the Fleas in the Jar Experiment - watch the video:

Where should Scrum Masters report? - Ryan Dorrell
An analytical approach to the same question:  Scrum Master Allocation: The Case for a Dedicated Scrum Master  by  Melinda Stelzer Jacobson on InfoQ
Can you use a Scrum Master by Bob Marshall the FlowchainSensei



Sunday, December 4, 2011

Is Time-to-Market really a Key Differentiator?

Why do some product win in the market place and some lose?  Is being first to market the key distinction between winning and losing?

The Agile software development movement has this one aspect (time-to-market) as key differentiator.  Many surveys note this aspect as a reason to adopt Agile methods.  Business people resonate with this value proposition.  The Lean Startup movement has this within its core.  It appears just common sense.  But is it good practice - is it a true cause and effect relationship?  If one is first in the market place with a new product, will it capture market share and become the de-facto standard product in the market segment?

Take the case of the cookie - the Oreo Cookie (introduced in 1912) - have you heard the back story?  It was the perhaps a knock-off of the Hydrox cookie (introduced in 1908), the first in the market segment, yet always labeled "imitator" and never a strong competitor (Oreos to Hydrox: Resistance is Futile).

It certainly did not work for Apple Computer in 1985 when they introduced the world to a computer for the rest of us.  Their graphical user interface was new and created a key differentiator, perhaps the key innovation since they had created a new market segment with the introduction of the personal computer in 1977 (see Apple History Timeline).  Yet Apple consistently a first to market innovator, appears to always run in second place to Microsoft.  That is until very recently (the post PC era).

Why It Feels Like We're Falling Behind It can take years to notice a life-changing invention. - Motley Fool

The typical path of how people respond to life-changing inventions is something like this:
  • I've never heard of it.
  • I've heard of it but don't understand it.
  • I understand it, but I don't see how it's useful.
  • I see how it could be fun for rich people, but not me.
  • I use it, but it's just a toy.
  • It's becoming more useful for me.
  • I use it all the time.
  • I could not imagine life without it.
  • Seriously, people lived without it?
This process can take years, or decades. It always looks like we haven't innovated in 10 or 20 years because it takes 10 or 20 years to notice an innovation.

  One aspect of the difference between first movers and the rest of the pack is not the timing of the introduction (being "first") but in having a better and more compelling story.  Much of the product story has to do with marketing, distribution, partnerships, and customer satisfaction and adoptions of the product story as their own personal story.  A case in point the Teddy Bear.

Steiff Billy Possum
A great story, the origin story of the Teddy Bear is in pod-cast audio on 99% Invisible.  It is told from the perspective of the second mover - the air-apparent to the thrown of the assumed temporary Teddy Bear toy - Billy Possum - the next big thing.  This toy was designed to succeed the outgoing president's (Roosevelt) plush toy with the incoming president's (Taft) product designed and marketing flop toy - a plush possum.

Which would you purchase for your child to play with - a teddy bear or a billy possum?

How's this for marketing - and the rest of the story is not for youngins.  While he would not shoot the bear - doesn't mean he wouldn't eat the bear.


See Also:  
51 Most Popular Tech Gadgets through the Years - Popular Mechanics

Saturday, December 3, 2011

Info-radiator; Better than Google Analytics

What is better than Google Analytics (web analytics made smarter, friendlier and free)?  How about web analytics made into an INFO-RADIATOR?

Better than Google Analytics
Info-radiator of desire.
What is an info-radiator?
“An Information radiator is a display posted in a place where people can see it as they work or walk by. It shows readers information they care about without having to ask anyone a question. This means more communication with fewer interruptions."
  -- Alistair Cockburn
See also:  Big Visible Chart, Informative Workspaces, Information Radiators.

Day 2
This concept is a mash-up of publishing information with information graphics and personal interactive engagement.


So here is my latest attempt to create one of these mash-ups.  It is an attempt to disseminate information about some Scrum videos and a survey on basic training evaluation (did the learner like and value the training).  One problem with this poster is that it may spark interest in the topic - yet there was a poor actionable behavior associated this reading the poster.  One could watch people stop in the hallway and read the poster, yet one couldn't measure any transfer of knowledge.  Did the learner actually go to the web site to watch the video advertised by the poster?  Sure we could put in some fancy web tracking analytics (if our back-end systems supported this feature - who knows what SharePoint can do - but I know it cannot be helpful in me acquiring knowledge of its capabilities - it doesn't like to share).

Day 3
So solving one problem - the issue of people need to remember the ridiculously long and complex URL (again SharePoint lack of capability) lead me to a great solution.  I shortened the SharePoint URL using Bit.ly then printed the shortened URL multiple times and created a tear-off and take-one sheet.  By posting this beside the poster I created the info-radiator.  Each day, I walk by and see the growing torn-off shortened URL tabs on the sheet.  This is an indication that the poster is working.  I think it may also create a virtuous cycle.  As others see the obvious interest, they see value in stopping to read the poster.  This may drive people to the Scrum videos and they may actually watch the video - then take the survey.


See Also:

Real-time Dashboards considered harmful
"Next time you think about making a real-time dashboard, ask a deeper question about the underlying problem instead. I guarantee you’ll find more value from that."
Related posts:


Another Info-Cooler bites the dust.
Why I use Flip Charts not PPT Slides
A Burndown chart that radiates progress




Monday, November 28, 2011

Play != Games


I'm excited to see Game Storming the iPhone app.




Dave Gray notes that "games and play are not the same thing."  He will teach you to bring games into the work place to get work done.  I think one of the side effects is that you may start to have fun.  For many people work will never be the same as play.  Yet if you want to change the world (thank you Steve Jobs); if you wish to have a purpose aligned life, then you will need to find a way to make play equal to work.  For me, this involves bring games into the work place.

Related posts:
Games and the Human
Agile tools for your iPhone - a list


Thursday, November 24, 2011

Every object should have multiple uses.


Book used as a saw guide.
Working on a honey-do item from the task board today.  It was to cut the dinning room table into, shorten it by about 12- 20 inches.  I was working with a limited selection of tools.  I needed a short straight edge, skill-saw guide.  I had a 6 foot straight edge for the table top - but needed a small one for the table skirt. Looking around I couldn't find one until I looked at the book shelf.  So I grabbed "Agile Estimating and Planning" by Mike Cohn.  I though it was quite appropriate.

Table with two cutoff pieces. 

Help me Circle you up on G+

Do you want to help me circle you on G+ - if so edit your profile and place a sentence or two in the field "Employment". Then when I mouse over your name I get a richer understanding of who you are. It helps me decide which of my circles I'd like to put you in - keep in mine the empty circle is also a choice. So help me out.

G+ > Profile > Employment (describe yourself)



Saturday, November 19, 2011

What have we LEARNED?

Scrum is a stepping stone toward the organization becoming learning organization, and much of being Agile is about the opportunity to learn. In the modern world of knowledge workers, if the people are not learning on the job, then they are not creating new knowledge. We create new knowledge by understanding the context of new problems, deconstructing the problem, understanding the forces acting within the system, creating solutions to solve them, and then remembering the decisions that resolved the forces and applying them to new challenges. Experience comes from numerous encounters with similar problems. When we reflect on new problems, we generalize and abstract guidelines and rules – this synthesis is learning. Reflection requires time and distance from the immediate problem.


At what point in the Scrum framework do we focus on learning? Well, for a truly mature Scrum team it is constantly, at varying levels. That's what makes working on an Agile team fun for me. We’re constantly learning something – whether it’s through planning to do something new or different and it actually working or by failing to achieve an objective and then realizing a better path to that objective. Learning to learn is like riding a bicycle; once you know how, it gives your inner child freedom to explore.

But if you have never experienced this type of fun on an Agile team, then perhaps you need training wheels for your shiny new Agile vehicle. These training wheels come in the form of the basic framework of Scrum. For example, the product review meeting (demo) is a great place for learning. If the team can create an opportunity for the stakeholders to learn the current state of the product, then they are doing the core of their task. However, the team also needs to present what they have learned during this iteration. Sometimes this is too technical for many of the stakeholders, but this doesn't mean it should be squelched. One of those stakeholders may be a high-level technical architect. If the team learns something about the suggested architecture, isn't this demo a great place for that feedback (positive or negative)?

A great story from Richard Cheng that describes an Agile team in the learning process was covered on the  ScrumDevelopment YahooGroup discussion list.
"Let me tell you a true story. I was working with a Scrum team at a financial website. About once a month, there was a company meeting where they presented what they did to the other departments and executives. Their initial presentation contained information such story points completed, hours spent on stories/spikes/firefighting, and what they implemented. As the team really started to understand the goals of the company and the project and their place in achieving these goals, the team presented the following:

1. What have we done this month to help make our company profitable?

2. How have we excited our customers

3. What we have learned

"This is a fundamental shift from thinking about task based, to do list work to actually achieving goals and providing value. Helping your organization shift from getting value from the first set of presentations to the second set of presentations is a big part of what the Agile transformation is about."

-- Richard K Cheng, PMP, CSP


Teams of developers (programmers, testers, business analysis, etc.) typically adapt to change with ease. For these knowledge workers, learning and doing Scrum is relatively easy. In Richard’s story, he’s telling us of a fundamental change that happened within his organization. It is at the company meeting that teams are describing the new knowledge that they have created and describing the impact to their customers.
How would this fundamental change occur in an organization?  My answer is via a shift from management operating in outdated fashion (i.e., control and reduce risk) to thinking in a leadership style (i.e., release control and accept risk). It is often the management – working within the traditional organizational structure – that that have difficulty embracing the Agile change. Scrum teams may create many more learning opportunities than management desires, and they may expose many more impediments than the existing structure can bare. This will cause friction in the management layers above the teams. 

Do not forget that the management layer has become successful within the old structure, and they may need to embrace new theories of motivation and practices of management. These new theories, ones that were not taught in MBA school in the 1980s, are well described in popular leadership literature. The Industrial revolution lead to a style of management largely based in Fredric Taylor’s work on Scientific Management also called Taylorism. This theory of management worked very well for assembly line workers. It does not function well for knowledge workers. New theories for creating the environment required for creative knowledge work are described in:

Drive: The Surprising Truth about what Motivates Us by Dan Pink
Switch: How to Change Things When Change is Hard by Chip and Dan Heath
Management 3.0: Leading Agile Developers, Developing Agile Leaders by Jurgen Appelo, author of the popular NOOP.NL site.

Leaders are you managing your knowledge workers as if they are industrial workers? Have you upgraded your wetware – your mental model of the way in which you manage and lead people? What are you studying to increase you ability and knowledge? What are you learning? To become the Agile learning organization, the whole body of the organization must learn new things – create knowledge – this is especially true for the leadership.

In her article The Rise of Emergent Organizations, Beth Comstock describes a possible alternative dynamic in the way to organize people to achieve a common purpose.  She appears to be experimenting with some of these techniques at GE.  I'd like to learn more about what she refers to as "Opening up New Feedback Loops."

"GE last year did away with annual performance reviews, opting instead for systems that allow individuals to give and receive feedback to anybody they interact with."

See Also:
Why we cannot learn a damn thing from Toyota or Semco by Niels Pflaeging

Esko Kilpi's article on Productivity Revolutions - Medium. An interesting view of Taylor the socialist and troublemaker. And a prediction that "technological augmentation" is going be the next revolution in productivity for the knowledge worker.

How to build the next Trello and sell it for $425 million or more
Atlassian bought Trello for $425 million. Because Trello was on trajectory to kill Jira.
by Mitt Tarasowski Executive at Libertex. Co-Founder of Clever.do.

Saturday, November 12, 2011

It is not about Sprint Zero; Think Sprint-N

There is a good dialogue on the topic of Scrum's Sprint Zero going on at Scrumdevelopment@yahoogroups.com.  If you follow the group you will surely learn something about Agility.  It will just seep into your pores.  Go right ahead - click the link and join up... I'll wait here.

The "raging" debate in the Scrum world for years is - should a Scrum team have a Sprint Zero?  A sprint in which they get setup for doing real work.  A sprint for installing all that infrastructure (DB, Version Control System, App Server, build a few [sarcasm] frameworks). [Hint: when a developer says they just need to build a framework - it is geek-code for I don't have any idea how to use The Google to find a tool to do that job - so I will have to forge my own special handmade tool - check back with me after I reinvent the wheel.]

I think perhaps the wise and wonderful man behind the curtain - Ron Jeffries - captures the best thinking on the topic:

"I do, however, object to calling those activities Sprint Zero. Here is my reason:"

"It is a core principle of Scrum that every Sprint must produce an increment of potentially shippable software.

"Therefore, an interval of time which does not produce an increment of potentially shippable software is not a Sprint.

"Therefore such a time interval should not be called a Sprint. It doesn't do what a Sprint does."
   -- Ron Jeffries
So the debate - and I think it is much more a debate - than a productive dialogue, is over something at the very beginning of a long learning process. The transition from predictive to emergent behaviors of development.  Is the debate over - what to call an increment of time?  Or is it over our starting point: Zero vs One?  Or is it over the principle of - do we really have to deliver something this first iteration - what could we possibly do AND do all this setup work?  Do we have to do ALL this setup work?  Now we are going down the right path.

And the abstraction of that path is that we learn to count with the infinite goal in mind - not the beginning.  We learn to count:  Zero, One, Many.

If you have only ONE sprint called Zero - I'm fine with that - it is a failure if it delivers no potentially shippable software.  But hey, I'm OK with failure.  And if you fail once and learn something - like how to get back up, dust yourself off and start delivering working software in one sprint, well then HEY I'm good with whatever you call it.

You see, I'm focusing on the goal - getting to reliably delivering software in Sprint-N, each and every Sprint-N.  And if you need training wheels on your first bicycle - then I'm all for getting training wheels - it is a very reliable learning technique.  Just don't put them on your Harley.


See Also:
InfoQ:  What is Sprint Zero? Why was it Introduced?
An alternative view:  Why do you need Sprint 0
Scrum Alliance article:  What is Sprint Zero
Mountain Goat SW:  Sprint Zero: A Good Idea or Not?

Friday, November 11, 2011

The Ultimate Wallboard Innovation

Some years ago Atlassian ran a contest to find the Ultimate Wallboard.  The winner Vodafone's board was awesome.  There are other nice boards there - if you are in need of inspiration to improve your task board.

vodafone_wallboard.gif
The Ultimate Wallboard - 2010
Ole Højriis Kristensen from the Vodafone Web Team in Denmark was voted the Ultimate Wallboard winner in Dec. 2010. An interview with Ole on the creation of their wallboard.

It uses RFID to track the task on the board and projects on the board real time graphs of work in process and burn up rates.  This allows them to integrate with team members in remote locations.  Yet they do not lose the tactile sense, nor the spatial processing that the vision center of the brain do so effortlessly for us.

While I'm expecting nice online version of wall boards to keep improving, I don't believe there is a better way to learn Scrum than with a physical low-fidelity wallboard.

We don't learn to do arithmetic using a calculator.  No, one starts with simple addition and by the time your ready to learn division it is done using pencil and paper (long division old school).  Requiring the student to do the hard work of the long division process may help them to understand the conceptual division problem and the solution technique.  Just image how hard it was to do in Euclid's time (300 BC) without the zero and using Roman numerals.  Thank you Fibonacci for introducing us to the Arabic Zero.

The invention of the tablet device (post PC era - thank you Steve Jobs) may be an additional minor improvement to our eWallboards.  They will get better when I can touch a task and move it from one area to another and that action syncs to everyones device, including the Big Visible Chart on the team room wall.  While my iPad may represent an abstraction of the BVC via a zoomed-window to allow me to work on a tiny portion it will not replace the ability to stand back and see the big picture.  To recognize the patterns that emerge when I see the whole.  This ability is just the tip of the iceberg of Systems Thinking.

One advantage the eWallboards have over my favorite brand of stickies (Post-it pastels) is rarely seen used.  It is touched on in the timelapse above.  The ability to see patterns that emerge over time.  The temporal dimension of patterns.  These events could be recorded and played back at super-fast-mo to show patterns over a 4 - 6 month release.  How would we create a temporal-burn chart?

I'm a big fan of info-graphics - wish I was better at creating them, maybe that's my next career.

What would we see if we timelapsed each project form cradle to grave?  Then compared the patterns the emerged to derive health stats for projects in the aggregate   Something like the human body-mass index.  At six months your baby project should be weighing in at 10-15 developers and delivering health product increments each iteration Ms. Manager.  Now compare that to the young adult project out in the lobby - it appears to have caught a virus, perhaps mono I expect it is running hot and productivity has dropped through the floor.

Now imagine that info graphic help you to determine if the project you have is healthy, and suggesting forms of treatment with projections of what might happen - the what if - scenario.  Then imagine it playing those on an 8 foot wall.

My advice to everyone - bring in the creativity, the fanciful, the silly, and the fun.

Related post:
Interactive Whiteboard using the iPad
8 reasons to buy an iPad for your team room
Agile apps for your iPad/iPhone

Thursday, November 3, 2011

Have you written a Manifesto lately?

What is it lately - everyone wants to get into the Manifesto authorship racket.  When I was growing up - only commies and the unibomber wrote manifestos.

Well after taking a stroll through the internet, there are quite a few nice manifestos out there.  Here are a few that I subscribe to...

The Agile Manifesto - four comparative value statements and 12 principles for how to build better software.  With an industry failure rate of 72% boy do we need a manifesto!

The ScrumMaster Manifesto - because this is a group of people that are downtrodden every day.  Sitting in a seat for 2 days straight without nodding off is no bais for a system of government - to paraphrase Dennis - come see the violence inherent in the system.


The Manifesto for Software Craftsmanship - because we need the bar raised.

The Mother [bleep] ing Manifesto for Programming Mother [bleep] ers - because sometime a four letter word says more than a well crafted phrase.

The MoreAgile Manifesto... because incremental improvement beats the alternative.

The Holstee Manifesto - because it is my life - and I will do what I love.


The Gangplank Manifesto, creating community changing culture, walk the plank.

The Cult of Done Manifesto - enough said.

Having a motivation problem?  The BootStart Manifesto might help you - but you must fall in love with your problem (not the solutions).

The After the Agile Manifesto, Stop Writing Any More. Please. A really long list of manifesto, and a plea to stop it already.  Oh!  Maybe I should end it here.

And now the PMO has a Manifesto (don't you just hear the resonance).

What would happen if a Manifesto were written as a scientific experiment - starting with a null hypothesis? Bob Marshall's Agile H0.


--------------

Well I haven't updated this Manifesto page in a number of months... haven't found anything worth the trouble until today (Feb 1, 2017) a day that may change my carrer journey... Agile Transition Guide may get a rev. version number soon. Thanks to the Manifesto for Agile Company Development by Agile 102: (reprinted below). Credit for this wonderful work goes to: Matt the Agile Coach on twitter @MattAgileCoach.

Manifesto for Agile Company Development

We are discovering new ways of transforming corporate processes, activities and structures by helping companies take better advantage of Agile software development techniques. Throughout this journey we have recognised it is better to:


  • Create streams of business value rather than end-to-end projects.
  • Structure organisations for pace rather than for complexity.
  • Model and experiment rather than describe and document.
  • Create processes to empower people rather than to constrain them.
  • Promote cross-functional collaboration rather than singular accountability.
  • Discover and prioritise customer needs rather than deliver internal vision.

We recognise that all of these may not be entirely achievable within the constraints of some industries; however promoting the positive values from within each one will enable more agility in any organisation.



I just saw this today and it instantly resonates with me as that thing that many people have desired - What comes next after Agile? I've decide that a journey is the prize, not some destination. However this manifesto might set the goal for many of us that are not working on our "own" companies... but trying to help with another's company.

Now had I been invited to the chalet to collaborate on the manifesto - I'd like to polish the word "company" into a broader term "organization". To include groups that are not-for-profit and weirdos that might find they fit within the realm of "The People's Scrum" by Tobias Mayer.




A trick for motivating people

If you're task is to motivate people - you may be surprised that you will fail very often. Invert your thinking.  Figure out, how do you not demotivate people?  It is easier to not demotivate people than to motivate them.  Here are a few ideas from Jim Collins, author of Good to Great.


  • Don't first sell people on a vision.  Confront the reality (the facts).
  • Don't decide first and then appear to discuss.  Have a true dialogue, then decide.
  • Don't make progress toward the goal invisible.  Show progress, make it obvious.


Related posts:
my notes on Dan Pink's book Drive!
see Sinek TED Talk video in Be or Be Not; there is no Do in Agile


Tuesday, November 1, 2011

A Timeline of Digital Storage Media



It is a well know fact that humans are relatives of the packrat. We love to store stuff - useless stuff away for a later time. Therefore we need bigger storage lockers, and more storage lockers. We need 30,000 sq-ft homes with basements the size of a high school gym. We need climate controlled storage lockers - off site, but still within 5 miles of home.

The same is true for our digital lives. Who still has the code for the first program they wrote for the x86 chip set? Now we have more storage on our key ring than was in the corporate data center of 1984 (I am Big Brother).


The History of Digital Storage [INFOGRAPHIC]

My how time flys! The rate at which data storage capability increases is exponential. But is it limited?

See Also:



Sunday, October 30, 2011

Why I use Flip Charts not PPT Slides


Want to retain something you just heard - draw a doodle.

Want to engage learners - get them active.

Want to teach someone a skill - have them teach you.

Want to change some behavior - make it fun.

In all of these techniques the trick is to invert the traditional training paradigm.  The classroom was created to process children with unique talents into factory workers willing to follow directions of an authority.

Doodlers, unite! Sunni Brown on TED.com

Read Sharon Bowman's 'Training from the BACK of the Room!'.

Don't think you can doodle - come out of the closet with these techniques from Dan Roam 'Back of the Napkin'.

Maybe it all comes down to improvement, and the need to iterate - to recreate to improve.

One can not doodle on the power-point slide one the screen. One can not quickly annotate a burndown chart in that spreadsheet (a learning moment). One can not give the marker to a participant and have them draw a diagram on your slide deck. You do not get their mental model of the problem domain when you show them your perfect architectural layer model. While sitting in perfect rows and columns the students are not allowed to engage with each other - only by signaling the authority (raising a hand) may the student (receiver of info) become active in the dialogue. Is that fun?

I encourage people to mark on the charts and diagrams on the flip charts - they really are not works of art. They do not have to be treated like paintings hanging in a museum. I've gotten in "trouble" for annotating (with sticky notes) a poster hanging in the work place. Oh-my, it started a conversation about the topic, what is wrong with that?  I didn't draw a mustache on the Mona Lisa.

If the traditional paradigm is not working - try an inversion principle.


This RSAnimate video was adapted from a talk given at the RSA by Sir Ken Robinson, world-renowned education and creativity expert.

Maybe the reason this technique works has something to do with the concept of texture in architecture - why some over-designed spaces don't attract people to congregate, contrary to the designer's intent.  See "Why Glass Towers are Bad for City Life - and What We Need Instead" by Justin Davidson's TED Talk.




See Also:
Recreate to Improve
Why I Use a Paper Kanban Board - by johanna
Why Paper is the Real Killer App - BBC


Saturday, October 29, 2011

How Happy Are You?

The (USA) founding fathers declared that the pursuit of happiness was a right of the people.  So do you have a right to be happy at work?  No.  But you may pursue happiness there as well as anywhere.  And you may wonder if happiness at work will be more productive.  There is not yet enough study in this regard, and the studies of 19th C. work methods like the Hawthorne Studies might not be generalizable to the modern knowledge workers.

The Surprising Myths About Happiness at Work (Inc.com)  A body of research has found that a happy workforce doesn't necessarily equate to a productive one.
The Research We’ve Ignored About Happiness at Work (HBR.com)

The Science of Happiness in depth report by Scientific American.

The Harvard Life study of Happiness 75 years of it.


Learn the latest psychology behind why it's hard to be happy, and take the quiz to learn how your contentment compares to that in other cultures.

Scientific American

"Happiness varies not only from one person to the next but also from one country to another. (For more discussion of happiness around the world, see The Many Faces of Happiness.) Psychologists measure happiness in several ways. One approach involves the extent to which you experience positive versus negative emotions. Another assesses life satisfaction, or how pleased you are with your life as a whole."

Quiz: How Happy Are You?: Scientific American:

So maybe happiness at work is not a smart goal for a leader of an organization.  Perhaps it is an externality of some other aspect; think correlation not causation.  So what could be the savvy leaders smart goal?  I believe that Richard Sheridan has arrived at a viable solution and sees the externality of happiness in his employees.   Please don't mistake the cinnamon of Joy with Happiness... that is not his root purpose as a leader.  It is his desire... but he achieves the desire via other methods.  One is to create a safe to fail environment for his work force.  As a leader his main task is to drive fear from the room/office/environment and the organization.




See Also:

Warning: Your Workplace Can Improve By Adding Joy. Yes, I said Joy by Guy Kawasaki 

You'll Never Work Alone (Inc.com) At Menlo Innovations, all work (seriously, all work) is done by pairs.

Friday, October 28, 2011

Change is easier with FUN!

OK - I've got to remember to bring the FUN. That's what empowers changing behaviors. Not Power-Points, not mission statements, not a list of 10 things you don't know, not a study done at Stanford. It's pure Fun!

100 Things You Should Know About People: #13 — Want To Change a Habit? Use Fun, Surprise, and a Crowd | What Makes Them Click:



The Dancing Traffic Light


What belongs on the Task Board?

I wonder about these questions a lot - what types of task belong on the task board?  Does every task have to belong to a Story?  Are some tasks just too small?  Are some tasks too obvious?  Obviously some task are too larger, but when should it be decomposed?  How will we know a task is too large?

I answer these questions with a question.  What about a task board motivates us to get work done?  The answer is: T.A.S.K.S. to DONE!



Inherent in the acronym TASKS is the point of all tasks, to get to done.  That is the measure of if the task is the right size.  Does it motivate us to get the work done?  (see notes on Dan Pink's book: Drive - The surprising Truth about what motivates us) If we are forgetting to do some class of task then putting it on the board will help us remember.  If we think some small task is being done by someone else, then putting it on the board will validate that someone else is actually doing it.  If a task is obvious, then putting it on the board will take virtually no time and promote the well being of getting things done.  If a task is too large it will never move to done.

Sisyphean - adjective (of a task) such
that it can never be completed.
I walked up to a task board just this week and saw a set of Sisyphean Tasks.  It was a signal that the board would not be helpful.  No flow would happen.  The task would get to In-Process and stay there for life.  What information would radiate from this board?  A static task board sends the one signal - we don't know what we are working on, and we can't tell you.

The solution for this group was to realize that those epic tasks were a story or a class of work and after reforming the task board a bit, we made a minor improvement.  Hey, that's what it's all about.


Oh... no, maybe that's the Hokey-Pokey.


See Also:
Why Visual Management Techniques are so Powerful
Elements of an Effective Scrum Task Board
7 Aspects of a GREAT Impediment Sticky

Monday, October 10, 2011

Thinking about company culture




What does a company culture (wikipedia's definition) tell you about their Agility?


When I think of culture and models to describe these very complex human dynamics I think of the song "Hair Styles and Attitudes" by Timbuk 3.  In this song they sing of how scientist have categorized our attitudes into 3 basic types (a model of attitudes).  This is the Three Stooges model of attitude.  I liked this model so much that I created a slide show of my company's people as a prelude to a project retrospective.  This project had a clash with the client culture.  The project ended, but I'd have to say it didn't end pretty.  It did not end in a win-win situation.



Slide show of Hair Styles and Attitudes



Would some coaching from Lysaa Adkins on team conflict have save the contract?  Boy, I wish we would have know about it and tried.

Navigating Conflict on Agile Teams: Why Resolving it Won't Work


One of the best blogs on the topic is Michael Sahota's Agile Culture Series Reading Guide.
Michael uses the Schneider Culture Model to describe efforts to transition a culture.
This is a reading guide to the series that explores corporate culture and how that has a direct impact (sometimes very negative) on efforts towards Agile adoption. It is a must-read for anyone that is considering taking their company agile or for coaches and consultants whose trade is based on Agile. The role of Kanban is quite distinct and is discussed throughout.


I just did a refresher course on Crucial Conversations by VitalSmarts.com it was an awesome course. In the course material was this question:  "Does your organization have a written cultural rule to be 'candid and transparent,' yet the unwritten rule tends to be 'disclose selectively?'"  I'd have to answer that question in the affermitive. VitalSmarts goes on to state:  "The question is not whether you have a cultural operating system - it's whether yours is one that advances or impedes continuous improvement."

References:

“That’s the Way We Do Things Around Here”: An Overview of Organizational Culture by M. Jason Martin

The Reengineering Alternative: A plan for making your current culture work by William Schneider.

How we do things around here in order to succeed.  Agile 2010 conference session by Israel Gat.

How to Find Out If the Company's Culture Is Right for You by Whelan Stone


End of nations: Is there an alternative to countries?  Nation states cause some of our biggest problems, from civil war to climate inaction. Science suggests there are better ways to run a planet.

Saturday, October 8, 2011

The 25 Smartest Things Steve Jobs Ever Said



Steve Jobs and I quote:

25. "Being the richest man in the cemetery doesn't matter to me. Going to bed saying we've done something wonderful ... that matters to me."

24. "I read a study that measured the efficiency of locomotion for various species on the planet. The condor used the least energy to move a kilometer. Humans came in with a rather unimpressive showing about a third of the way down the list ... That didn't look so good, but then someone at Scientific American had the insight to test the efficiency of locomotion for a man on a bicycle. And a man on a bicycle blew the condor away. That's what a computer is to me: the computer is the most remarkable tool that we've ever come up with. It's the equivalent of a bicycle for our minds."

23. "In most people's vocabularies, design means veneer. It's interior decorating. It's the fabric of the curtains of the sofa. But to me, nothing could be further from the meaning of design. Design is the fundamental soul of a human-made creation that ends up expressing itself in successive outer layers of the product or service."

22. "I'm as proud of what we don't do as I am of what we do."

21. "We don't get a chance to do that many things, and every one should be really excellent. Because this is our life. Life is brief, and then you die, you know? And we've all chosen to do this with our lives. So it better be damn good. It better be worth it."

20. "My model for business is The Beatles: They were four guys that kept each other's negative tendencies in check; they balanced each other. And the total was greater than the sum of the parts. Great things in business are never done by one person; they are done by a team of people."

19. "The system is that there is no system. That doesn't mean we don't have process. Apple is a very disciplined company, and we have great processes. But that's not what it's about. Process makes you more efficient. But innovation comes from people meeting up in the hallways or calling each other at 10:30 at night with a new idea, or because they realized something that shoots holes in how we've been thinking about a problem. It's ad hoc meetings of six people called by someone who thinks he has figured out the coolest new thing ever and who wants to know what other people think of his idea. And it comes from saying no to 1,000 things to make sure we don't get on the wrong track or try to do too much. We're always thinking about new markets we could enter, but it's only by saying no that you can concentrate on the things that are really important."

18. "I wish [Bill Gates] the best, I really do. I just think he and Microsoft are a bit narrow. He'd be a broader guy if he had dropped acid once or gone off to an ashram when he was younger.''

17. "My self-identity does not revolve around being a businessman, though I recognize that is what I do. I think of myself more as a person who builds neat things. I like building neat things. I like making tools that are useful to people. I like working with very bright people. I like interacting in the world of ideas, though somehow those ideas have to be tied to some physical reality. One of the things I like the most is dropping a new idea on a bunch of incredibly smart and talented people and then letting them work it out themselves. I like all of that very, very much."

16. "Innovation has nothing to do with how many R&D dollars you have. When Apple came up with the Mac, IBM was spending at least 100 times more on R&D. It's not about money. It's about the people you have, how you're led, and how much you get it."

15. "Your time is limited, so don't waste it living someone else's life. Don't be trapped by dogma -- which is living with the results of other people's thinking. Don't let the noise of others' opinions drown out your own inner voice. And most important, have the courage to follow your heart and intuition. They somehow already know what you truly want to become. Everything else is secondary."

14. "You can't just ask customers what they want and then try to give that to them. By the time you get it built, they'll want something new."

13. "A lot of times, people don't know what they want until you show it to them."

12. "We're gambling on our vision, and we would rather do that than make 'me, too' products. Let some other companies do that. For us, it's always the next dream."

11. "The cure for Apple is not cost-cutting. The cure for Apple is to innovate its way out of its current predicament."

10. "A lot of companies have chosen to downsize, and maybe that was the right thing for them. We chose a different path. Our belief was that if we kept putting great products in front of customers, they would continue to open their wallets."

9. "When you first start off trying to solve a problem, the first solutions you come up with are very complex, and most people stop there. But if you keep going, and live with the problem and peel more layers of the onion off, you can often times arrive at some very elegant and simple solutions. Most people just don't put in the time or energy to get there."

8. "That's been one of my mantras -- focus and simplicity. Simple can be harder than complex."

7. "We didn't build the Mac for anybody else. We built it for ourselves. We were the group of people who were going to judge whether it was great or not. We weren't going to go out and do market research. We just wanted to build the best thing we could build."

6. "Be a yardstick of quality. Some people aren't used to an environment where excellence is expected."

5. "We've never worried about numbers. In the marketplace, Apple is trying to focus the spotlight on
products, because products really make a difference. ... You can't con people in this business. The products speak for themselves."

4. "You can't connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future. You have to trust in something -- your gut, destiny, life, karma, whatever. This approach has never let me down, and it has made all the difference in my life."

3. "Creativity is just connecting things. When you ask creative people how they did something, they feel a little guilty because they didn't really do it, they just saw something. It seemed obvious to them after a while. That's because they were able to connect experiences they've had and synthesize new things. And the reason they were able to do that was that they've had more experiences or they have thought more about their experiences than other people."

2. "Sometimes life hits you in the head with a brick. Don't lose faith. I'm convinced that the only thing that kept me going was that I loved what I did. You've got to find what you love. And that is as true for your work as it is for your lovers. Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work. And the only way to do great work is to love what you do. If you haven't found it yet, keep looking. Don't settle. As with all matters of the heart, you'll know when you find it. And, like any great relationship, it just gets better and better as the years roll on. So keep looking until you find it. Don't settle."

1. "Stay Hungry. Stay Foolish." * not originally by Jobs.
    *  Stewart Brand - The Last Whole Earth Catalog. Jobs noted Stewart Brand in his Stanford speech.


See Also:

In Reinterpreting Steve Jobs Folklore, an Opera Disrupts Its Form
Silicon Valley’s favorite iconoclast is getting his own, appropriately high-tech musical

What are the Principles?

The agile reboot is underway... the company says it is using "Agile" yet there is no methodology/process/framework that defines "Agile" is there.  So it is not a very valid statement to say we do Agile.  Agile is a philosophy - defined by 4 comparative value statements and 12 principles.  So the top-dog rightly focuses the company on one well defined Agile process - Scrum.  Great move for a change initiative.  Focus is going to be important.  Now we need to discriminate the change - what is it that we want to quit doing and what do we wish to start doing?  We must label these things.

Three of the 12 principles of Agile with engineering
practices mapped to them (TDD, Pair Programming, etc).
When we tried to map our existing practices - we found
we didn't have very many disciplined practices, so this
is a mapping of a desired future state.

Typically it is easy - one applies the Waterfall label to the old and the Agile or Lean label or more specifically Scrum/XP or Kanban to the new.  That has worked for me in the past very well.  But what to do when it doesn't work?  What to do, if the company has brainwashed itself into thinking it is practicing Agile.

I must resist the Stockholm syndrome. That culture of just get it done - is not a process - and by any definition of the word - it is not Agile.

But then perhaps in a moment of desperation they look around and ask - "what are the principles"?  What is the foundational philosophy of this Scrum process?  We want to know these so that we will know where we can customize this process.  We want to know what we can bend, what we can circle around - how can we keep doing what our culture dictates and just install the scrum.

Agile Culture Series Reading Guide Written by: Michael Sahota

How many times does a process get broken before it is tried - before it is adopted - before any experience what-so-ever with the designed process, we say "we can't do that - we must change it" - not our selves - we change the process.  We all know that it is easier to change something else than it is to change ourselves.  So we search for the exceptions that will prove the case that process step 23-C will not work here - we have decided that we are so special that the Sun actually revolves around us.

Scrum designers have done a wonderful job of defining a very small list of things that must be done - if you do them - then you are doing Scrum.  If you break the rules, bend the framework to suit you special case - well then do you think you will get the desired outcome?

So that first question of what are the principles may be more subversive than it appears.  Because if you slip up and define a gap in the principle fabric then there will be a hole for the monsters to slip back through.   Given that I'm not going to be able to articulate each principle and you will not quite understand my meaning just perfectly.  Is this not a slippery slope.

So if you want to customize your process - one that has been built/designed/tested/refactored over years by experts - and you think you are qualified to state when we can just re-jigger this piece, skipping that piece, it is just a waste, never understood it anyway, so we'll just do it our way.  Well I don't want any part of your bastardization.

If you want the principles - they were stated - as best we have found in the Manifesto.  Don't re-invent the principles - just re-use them.


Exercise :: Mapping Engineering Principles to Agile Practices (PDF) by David Koontz

Lovely space at Microsoft NERD center.
Mapping Engineering Practices to Agile Principles at
Agile Games 2011 in Cambridge.
Note circular whiteboard - awesome!

 
Trusted & Motivated People - a label for
one of 12 Agile principles is well supported
by 5 practices.
Jay summing up 'User Stories' supports 7 principles

David Koontz
Pointing at the root of our principles
Agile Manifesto


Another Exercise: The Definition of Done & Ready!

See Also:
Exercise:: Mapping Engineering Practices to Agile Principles article by David Koontz - includes PDF downloadable exercise.
The 12 Principles Ice Breaker by Gerard Chiva on Oikosofy
The Big List of Agile Practices - NOOP, Jurgen Appelo an alternative list of engineering practices to map to the Agile Principles



Thursday, October 6, 2011

Another Info-Cooler bites the dust.

Built another Scrum task board today for a team.  I first described it on the whiteboard, and a bit about how it worked, how we could choose vertical story and status columns or horizontal - gave them the choice.  We could start with the simplest thing that might work - 3 states (ToDo, In process, Done) and add states if needed (another choice). 
The simplest thing that could possible work.
A Scrum task board (ToDo, In Process, Done).
Tasks flow down the page.

I gave my standard disclaimer - the first version was going to be designed to be thrown away - so bad that they would have to re-do it to make it better.  That's a trick I've learned to sell them ownership of their board.  After a few mock examples on the whiteboard they were getting restless and wanted action.  They bought it.  Sold!

After 6 flip charts got pasted to the wall (3 h. x 2 v.) and a bit of labels and lines - we ran some examples of what it might look like with Story stickies and Task stickies.  Then we played a simulation standup for a few simulated days.  The simulation worked wonderfully.  They got into the make-believe and started adding to the Improv.  I was switching hats - Coach... ScrumMaster... Team Member with a really bad performance record on a task.  They improv-ed some situations and  one or two really great question later we had a team that was going to learn Scrum the old fassion way - by doing it.  No powerpoints, no death by bullet points, just good old Polish hard work and positive attitude.

I did pull out one acronym and we talked about homonyms (I'm from the south so my dialect allows me to pronounce 'pen' == 'pin' - but they are Polish and it all sounds English to them).

T - those
A - awesome
S - stickies
K - keep
S - Sliding to DONE!

That's as close to a slide as we got.

Sorry Rally/VersionOne/etc. - that's a three person team that is not going to use your Information Cooler.

Video at 11.

Queen - Another One Bites the Dust. 

Scrum Task board loaded and in action.
A Polish Impediments list on the right wall.