Work expands so as to fill the time available for its completion. ~ Parkinson’s Law, Cyril Northcote Parkinson

On Risk Reduction

Teams talk some good game when they sell Agile to their organizational leaders: real software in a few weeks, higher quality, and, if they’re really good, risk reduction.  “See, if we build these features early,” they say, “and people don’t like it, we’ve saved you 13 months of wasted effort and costs.  How can you not love this stuff?”  Sign me up Johnny!

It’s true, if you build done software in 30 days or less, you do get the opportunity to inspect the output determining whether to stay the course or correct.  You can even begin taking on more creative, innovative, industry shaking adventures knowing they are limited to a few weeks or months.

Looking to become strategic and not just tactical with technology… this is your ticket.

But it’s not all roses. You must expect that some adventures will not end with a pot of real gold. Instead, our gold is measured in learning; new information which can be taken back and used to concoct the next ground shaking advance.  If you allow the fear of failure to drive your decisions you will grind to a halt.  Instead, create a system based on learning and encourage the free communication of that information as a value neutral asset.

On Focus

Tell me you didn’t see this coming.

Every team feels the pressure of a time box.  It’s natural and it can be used wisely.  It can also be abused.  Terribly, terribly abused.  I have good news though!  Corporate evolution is on the side of the wise.

Those who follow the Pomodoro Technique create short, focused 30 minute durations to accomplish activities.  25 minutes exist for actually working the task at hand and 5 are meant to provide the necessary, human break needed to maintain focus over extended periods.

Our Sprints must consciously reflect this same human capacity for focus in a creative environment like software development.  As outlined in our previous part of this series we can easily turn a space for focus and creativity into a pressure box of panic, frustration, and corner cutting.

Sausage stuffing is the two steps back to your previous step forward.

On Decision Making

To support a team in delivering functioning, ship-quality software in 30 days or less, organizations must provide them with timely, informed decisions to questions and alternatives.  Authoritative and informed decisions which take into account the political and user environment are necessary within minutes and hours, not days or weeks.

Would you ever consider the impact of removing 10% of an existing project’s schedule?  In delaying a decision for steering committee or general approval by 1 day, a two week iteration is similarly delayed.  In the absence of responsive decision making and an open social environment for voicing questions and concerns, teams will make decisions and assumptions on their own.

In many of these cases, we may have the best people on the team to make those decisions!  Time boxes demand that our teams be composed of or have direct access to those skills necessary to make decisions quickly.  This includes domain experts such as lawyers, accountants, marketing, design, etc.  With “done” software in 30 days we cannot hide the impact of delayed decisions.

To help me keep track of them and to help others I’m going to catalog them here.

• Methods no more than 3 lines
• No mouse
• No moving cursor more than 2 lines with the arrow keys
• Test Method names at least 40
• All methods/properties names at least 30 characters
• No Classes
• No Mutable State
• No Exposed State
• 3 Refactorings after each passing test
• No If, Else, Switch Statements
• TDD as if you mean it
• No Frameworks
• No IDE

* Replace any number with your preference

If you have ideas for others, put them in the comments and I’ll update the list.

TL;DR

I have an insatiable thirst for new information.  It can be quite frustrating and, at times, debilitating.  The neat thing about new information, is it changes what you consider normal.  Common sense is a bunch of crap.  Using a fork is common sense… until you move to India.  We should all move to India (or vice versa) for a while.

Not to long ago someone described an art course in which many of the lessons included drawing 50 different types of circles or straight lines.  I imagine around 10 or 20 you start struggling a wee bit.  I was reminded of this while reading Zach Holman’s Slide Design for Developers.  He writes:

I took one design class in college. One of the most fascinating assignments they gave us was a study of shape: you get one letter, in one typeface… do something with it. The idea was that the severe limitation forced you to be creative with duplication, rotation, scale, alignment, and whitespace.

Katas give us a silly background story like Triangle Classification, Roman Numerals, or Harry Potter, but those aren’t the point.  The point is not making the next test pass.  In fact, don’t write any tests next time.  They’re getting in your way.  Pick some other area that you feel comfortable in and come up with a constraint outside your Normal so that when you’re done you’ve moved normal a little bit.

Without freedom, one’s creativity cannot bloom. ~ Dalai Lama

On Creativity

In his 2005 A Survey of Organizational Creativity, Wayne Morris of New Zealand found that 2 of the top 3 Factors that facilitate or enhance organizational creativity are Time and Space/resources to pursue ideas.  Google stands as a preeminent topic brought up by software teams with it’s 20% time for engineers to follow passions.

Creativity, a necessary ingredient to innovation, demands space.  Space to experiment, learn, fail, and refine.  Space in time, environment, and pressure.

On Cleanliness

The mythic Rewrite.  It also comes in the form of a Refactoring Sprint.

Software Developers would hand over their first born in exchange for a Rewrite.  Customers hear: So we have to complete two more sprints before I can deliver new value that I can sell to pay these clowns’ salaries?

Keeping our code and our designs clean and in good state requires time and effort.  This isn’t in question.  Not even to your customers.  It most definitely needs to happen more often than once a year or however often it’s happening today.  Let’s face it, that big ball of mud didn’t happen last sprint.  It’s been simmering for some time now.

We must be delivering clean, refactored software in the midst of delivering new value.  We need to do this for many reasons, but here’s one you really need to accept or go learn the hard way: cash flow is a big deal.

On Sausage

I must credit Ken Schwaber for this analogy (and vision!).

There is a great unrest growing against the velocity metric.  In the minds and realities of many, velocity has been corrupt.  We are using this tool for calibration to fill a sprint to capacity and beyond.  To take a team to it’s limit.  To optimize!

We are stuffing the sausage.

I say ‘we’ and you’re reading ‘they’.  Admit it, I don’t blame you.  I do it to.  But we as team members are as much to blame.  When asked what we can accomplish we take that word ‘can’ to its limit in the hopes that we are pleasing others.  It’s pretty natural I’d say.

Unfortunately, in stuffing our sprints like sausages we squeeze (sorry) out the space for creativity and cleanliness that should otherwise be built into our ongoing process.  We must make space for the continuous improvement and balance our sense of urgency with our sense of exploration.

On Reality

Industries are not changed on Innovation Day or in Executive Offsite Meetings.  They are changed through discipline and a framework for learning applied to frequent delivery.

So choose a period of time which provides you an appropriate opportunity to inspect and react.  Build creative, clean, done features in that time.  Now use that experience to forecast which new parts of that product you can complete should you repeat that cycle in the future.

Continue reading this Time box series here

In reading many of the Iteration abandonment stories and views on why iterations are outdated I believe there is a rather one sided understanding of Iterations.  I believe this is a remnant of the software development industry’s state of being from which we came; the way referred to in the opening line of the Agile Manifesto.

We are uncovering better ways of developing
software…

            ~ opening line of the Agile Manifesto

I have a confession to make: I think iterations are really, really useful.  I also think they are often bastardized.  I’d like to help fix that problem and, in so doing, bring some of you back to the iteration so you can be more creative and strategic and less, well, cogs in a wheel.

In a three part series of posts I will redefine the meek, abused iteration for you as a:

• Safety Zone for creativity and complex problem solving
• Get S^&* Done tool for decision making and focus
• Yardstick for objectively evaluating the impact of choices and change over time

If you really, really want to love going to work, experiment with cool new technologies and techniques even in the most conservative organization, and want the best argument for ‘going Agile’ then stick with me.  By the time we’re done you will have a better understand of what a time box really is, where the time box applies, where it corrupts and, how to make a balanced decision for the duration of your next time box.

Having a clear, well understood and explicit Definition of Done that everyone, including your product owner and surrounding teams accept is very important to growing quality and capabilities consciously.  Underlying any Definition of Done is the expectation that the useful (for another day) software is ready for consumption by those who asked for it.

As a new team, discovering your initial definition of done can be surprisingly challenging.  Certainly we can come up with things that we want to do and I say go for it!  Only inspection at regular intervals can tell us for sure where we are and what the impact has been.  But there are some things we can do to help make this decision more effectively.  And it doesn’t take long.  30 minutes… maybe.

Circles and Soup

Innovations Games has a fantastic activity with many applications called Circles and Soup (sometimes called The Soup).  I’ve used this to help a pissed off team focus their energy, but it’s also very helpful in creating an initial Definition of Done that is truly attainable.

You should read the full instructions, but suffice it to say the team will categorize those activities both historically done (i.e. architecture review) and potential (i.e. TDD) that must or should be accomplished to deliver into: Things They Control, Things They Influence, or The Soup (things they have no control or influence over).  This is immediately actionable information, but also a roadmap to move items into the teams control.  Share this with your organization and advocates.

A Definition of Done, something that they agree will always be completed before calling a feature or story or product backlog item done, which includes activities outside of the team’s control is risky or foolish.  You should control your own destiny as best as possible.  How can a team ever feel at all confident in their own forecasts otherwise.

-ilities

In the Professional Scrum Developer course we talk about and spend a few minutes brainstorming attributes that define quality.  We call these ‘ilities’.  Things like maintainability, supportability, reliability, performance-ability.  Ok I made that last one up, but you get the idea.  It’s a big list too. 

Very few people will argue that missing an -ility negatively influences the quality of an application. Which –ilities are most important, though, depends on many factors.  Type of application, type of user, industry, etc.

What I like to do as a facilitator for this activity:

1. Ask the team to break up in pairs or individuals for 5 minutes.  Write every attribute that affects your impression of any application you’ve ever used on a sticky. 
2. Then come together, remove duplicates and put them on the wall for another 5 minutes (usually less).  This creates discussion about what people intended or experiences.  Often another -ility or two will be discovered.
3. Use dot voting or some other form of ranking to figure out which –ilities are most important to this application.

Putting it together

You should now have a good idea of what the team has true ownership of and what is most important to build a great application for the intended customer.

With the results on either side of a whiteboard or giant sticky, choose a few activities which correlate the important –ilities and the activities in the team’s control to determine an actionable, checkbox-able list of things you feel will assure each feature and sprint produces Done software.

Each iteration you have the opportunity to review these artifacts or recreate them to evolve your Definition of Done from good to great.

Most people try to avoid hard things or at least delay them until they have a good reason, but some things, important things… we should do those more often.  We need to practice the hard things.  They in turn become less risky and less scary bookends to our prideful efforts.

Testing is one of those things.

A few months back there was a thread going on the Scrum.org Professional Scrum Developer Trainers list about topics to include in the future.  Specifically this was in regards to the .Net flavor of the course, because we were getting updates about what was coming down the pipe in the tooling.  My excitement in that course has always focused on testing and with Jason Zander announcing continuous testing for all the major test runners in Visual Studio vNext that was my suggestion.

Adam Cogan, a smart dude in his own right, followed up asking me to describe why I thought that was such a big deal.  I sent a rather long reply that I found useful today while describing the testing pyramid to coworker Steve Gentile.  I thought I’d provide that reply here and get everyone’s thoughts:

We give passing credence to the idea of fast tests that run often versus slow tests that we expand to include before checkin/commit or during automated build (gated).  Unfortunately, the later becomes a catch all for the oops, just got lazy scenario. 

I remember when I first got the automated testing bug.  I wrote some tests (calling them unit tests) that integrated with a 3^rd party tool, gave great coverage and awesome feedback.  We knew within 5-10 minutes if a new 3^rd party version could be released.  Giant leap.  The next step, though, was hidden.  I would code for 20, 30, 90 minutes or more and then run my tests while I grabbed a cappuccino.

My current passer-by, rock your world tip/tool is NCrunch for .Net or Guard for everyone else (we need this).  Autotest.Net was the first try from James Avery, but it didn’t have any traction and was unstable at best.  Most teams have tests, but they aren’t using them effectively.   (Ok, Nuget and the no-commit pattern is a very close second!)

I run a group call Cincy Clean Coders.  We do katas, often as a whole group.  The first Randori kata we did was eye opening for the audience.  Someone started refactoring to solve a red test and another person threw a fit.  “What are you doing?!  You’re red!  You can’t refactor when your red.”  The driver didn’t intend to be refactoring, they were just solving the current red test in their mind.  They didn’t realize they were mixing many steps into one.  There is a mental burden to doing the simplest thing, running the tests, and only then refactoring.

Teams make a great jump when they automate their important tests.  Nightly feedback from QTP, Test Pro, or Coded UI is a big step.  Consciously mixing unit, integration and acceptance tests is amazing.  Our current tools mandate the start of the feedback loop be a conscious decision.  “So all those changes, wonder if things are still working?  Let’s find out.”  We don’t say it, but that’s how we act.

When your tests run every time you pause (NCrunch) or save a file (Guard) you come to expect feedback NOW.  You skip even CTRL+R,Y until your “finished”, only to find you just did 3,5, 10 refactorings.  Which one caused the problem?  Or you write a test that calls a web service, taking .65 seconds.  Pretty soon “fast” tests take 30-60 seconds (or more!) and your CI build takes 20 minutes.

Continuous testing is (IMO) the next step in shortening the feedback loop.  You start organizing your tests more effectively (or at all).  In good environments, I even use this as a chance to commit.  I now have the luxury of completely ignoring the path I took to my current source situation.  Get into a tizzy, reset/undo checkout.  Committing 10-20 times in an hour isn’t uncommon here.  Neither is branching half a dozen times.

In the PSD I can demo and talk to the importance of running tests often and having confidence, but a blaring red failure on the screen for that last edit really hits home.

I want your test suite to be an invaluable tool.  Continuous testing is one of those pit of success kind of things.  We need more of those.  But when signals pop up solve the real problem.  Don’t delay the pain.

Over that time, I’ve taken my experiences on awesome teams and tried to spread the love as a Professional Scrum Trainer both in the technical aspects (PSD), the fundamentals (PSF), and the organizational through coaching.  I tried my hand at organizing conferences like Cincy Day of Agile and Southwest Ohio GiveCamp with other awesome community members.  I started Cincy Clean Coders (soon to spread to Dayton, shhh) and organized a Code Retreat with the awesome Mark Haskamp.  Interwoven in all of that is about a presentation per month and normal client duties.

Not sure how my wife survived it

The clear theme in all of that is teaching or, at least, the distribution of shoddy advise.  It’s certainly something I feel confident in and have had some success doing.  I highly recommend everyone make it a focus for some period in their life.  It’s had a significant impact.

Some get into technical teaching as an end goal.  It’s a challenging, dynamic, and worthy objective.  It is not an end game for me.  It’s a skill.  Providing answers is easy, guiding and enabling is really hard.  So hard that the vast majority of leaders, those paid many hundreds of thousands & millions of dollars are terribly inept in the art.

Big News!

A few months ago my wife and I found out that our plans for a 3rd infliction on this world would instead be both 3 and 4.  Yes, twins.  Someone told me shortly after finding out “if you want to hear God laugh, tell him¹ your plans.” 

With this amazing and scary news, some lofty personal objectives for this year needed adjusting.  Certainly a big year, but different.

I fully anticipate making a dent in this universe.  I’ve experienced the power of self-organization on certain scales and I look forward to bringing to play industrial democracy in a powerful way in the not to distant future.  I hope this is a significant learning experience and step towards larger goals when it does finally happen.

2012

In the mean time, I expect and challenge myself each day to impart on my children the skills, experiences, attitudes, and dreams to make their own dent.  This is my most difficult challenge and it will take even more effort next year.

As part of this shifting focus, I will be leaving Cardinal Solutions.  While a pretty tumultuous experiment, I hope I was able to enhance the team on par with the experience I was looking for and partially found. 

So starting today I join crazy smart dudes Steve Gentile and Derek Hubbard at the new local office of Applied Information Sciences.  This gets me much closer to home much more often.  I’ll have a chance to ship some amazing things like their recent Vogue Archive and I can get back to teaching in the context of shipping a bit more frequently.  Anything else is simply not worth the effort.

I still expect to be involved with Scrum.org, but I will likely not be providing much formal, external training. I expect to bring this to AIS as time progresses and I get better footing.

I look forward to putting to the test and good use the empowerment and entrepreneurial spirit AIS offers and expects of their people.  I certainly feel that having a long debate with AIS President Tom O’Connell during my interview had a big impact on my decision to join AIS.

¹ While I have no proof, through observing the behavior of the men and women in my family on Sunday’s I’ve come to the conclusion that God most certainly is male.

It’s really nice to forget about all that cruft and just build the app while those things work automagically.  Unfortunately the magic doesn’t start until I say go.  And go.  And go.  And go.

There has to be a better way than starting half a dozen terminals or terminal tabs and  remembering to run guard, node-dev, vows, etc.  Turns out there is @rubyist and @pragma_tech had the cheese: terminitor.

Yeah – read it again: terminitor.  The govna isn’t much help.  It’s a different dude.  Even turns out people were so confused they changed the name to consular.

I’m not entirely sure how consular does it’s magic, but I did piece together the Ubuntu puzzle.  Here’s the deal:

1. Make sure to export TERM_EDITOR & EDITOR (vim for me) in your ~/.bashrc.  If you use a different shell, YMMV.

sudo apt-get install xdotool

This appears to be a keyboard & mouse abstraction layer.  This is required by a consular ‘core’.  Coming soon.

gem install consular

gem install consular-gnome-terminal

Initialize and configure consular with:

consular init

This should open ~/.consularch in your editor if you have TERM_EDITOR  configured.  Add

require ‘consular/gnome-terminal’

Head to a project directory in your terminal and

consular edit

This will create and open a Termfile in your editor of choice.  This file has some sample configurations using Now you can get rolling by running:

consular start

This will run the default, but you can learn the DSL and start everything from guard to your vim environment.  Get into your working mode faster.

]]> http://blog.cromwellhaus.com/2011/09/accus-saturday-schedule/feed/ 0 http://blog.cromwellhaus.com/2011/09/accus-saturday-schedule/