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:
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: