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.

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.

Disclaimer: All events are provided as examples which can and may occur as you work toward solving a problem.  I’m not advising you to include these explicitly in your process.

I’m happy to announce that Cincy Clean Coders is really going to happen.  Details can be found at http://cincycleancoders.com, but suffice it to say the inaugural meeting will be held April 7th at 6pm in the Max Train facilities in Mason, Ohio.

Mark Haskamp was strong armed brave enough to offer to go first with me.  I’ll update the site with the topics for the first meeting soon.

Big Thanks to Ernie Stormann and Parag Joshi who helped push this through.  And a big kudos to the rest of Twitter for being excited about a topic like this.  It says a lot about where our industry wants to be.

Help! You might notice I’m not a designer.  If you want to help, we could use a site design that doesn’t compare to notepad in a browser.  Nothing special, just, you know, some other than black on white text.

We’ve made more tickets available this year, but don’t expect them to last too long.

Register here: http://cincydayofagile.org/

Topics you’ll find at Cincinnati Day of Agile:

^*Blog owner bias acknowledged

There will also be an awesome 3 hour, hands-on workshop by Mark Windholtz and open discussion round tables.

I recently had to work through a mountain of feedback data provided by a limited product release.  User Experience experts, random individuals, and customers known for their willingness to provide quality feedback gave us excellent information.  The question became how do we effectively process the information as a team. 

Here a redacted version of the meeting notice I sent out:

We have feedback from some users. We need to talk about it, but it’s a lot of info.

Here’s the tentative plan (tentative because someone might think of a better one).

Agenda

15min · Soapbox

30min · UX Feedback

30min · Customer Feedback

15min · Next Steps

We need a really, really good note taker.  Volunteers?

Rules of the Game

1. Each person receives 3 uninterrupted minutes for their soapbox.
2. Interrupt someone during their soapbox and you lose a minute from yours.
3. Maximum 5 minutes on any one feedback item.  Action item to dig in later.
4. Fist in the air by anyone immediately halts discussion on the topic and we move to the next. Action item to dig in later.
5. Add a sticky note to the wall if you want to discuss something relevant by off topic.
6. Try to have read as much of the feedback as possible before the meeting.

---

The key to any meeting is preparation and an effective recorder.  By having a timeboxed agenda, audible timer, rules, and an awesome recorder meetings can actually be fun! 

I love the Soapbox for two reasons.  First it gets everyone talking.  Even the quiet person has three minutes (or a really long, awkward silence).  If someone finishes before their allotted time, sit quietly (you kinda have to or you lose a minute yourself!).  They will probably come up with something else right before their alarm buzzes. The second reason I love the soapbox is that you can then get down to business without people interjecting something off topic.

We didn’t make it through everything, people were cut off by the alarm, and people didn’t get to say everything during their soapbox.  It’s ok.  Do it often and people will learn to be direct, to prioritize their thoughts, and to PREPARE.

Now, back to my code.

I’m happy to announce that our first Professional Scrum Developer course of 2011 is scheduled for February 21st.  This is a course which practices 5 days of craftsmanship, collaboration, and sustainable pace via the Scrum framework.  Practice is the key to success and there is no better way to build a successful Agile team than to work together, continuously with a coach available to guide you through unfamiliar terrain.

Every team has it’s own happy path to a successful, self-organizing, self-managing Scrum team and it is not an easy one to navigate.  During these 5 days we will experience brown-field product development using Modern Engineering Practices such as TDD, Continuous Integration, Refactoring, and more.  Our case study is an ASP.Net MVC application.

Register for the course with MaxTrain.com who graciously provides the facility and infrastructure. 

Scrum.org, founded by Ken Schwaber to improve the profession of software development so that developers love their work and our customers love working with developers, describes the Professional Scrum Developer course in detail.  You’ll also find the course syllabus here.

Look forward to seeing you there.

"Your team may be dysfunctional … but at least you can see the impediments. Now you have the ability to do something about it!"
- Kane Mar – Scrumology, Scrum Coach

This fantastic statement about Scrum highlights the most important aspect of Scrum that is invariably lost in most Scrum implementations in which an experienced member or coach is not present.  In the context of your Team’s skills and the quality of your product this is an incredibly powerful statement.  One which enables developers to produce high quality software they can be proud of at a sustainable pace.

What is often perceived as a failed transition to Scrum is, in actuality, an organizations first, all be it scary, encounter with the power of the Scrum framework.  By committing to a minimal portion of the Product Backlog to be delivered in a relatively short timebox and, finally, asking the Team to demonstrate this potentially shippable product we ask the Team to expose their weaknesses early and often to a large audience.

Some of the most common weaknesses include misunderstanding customer needs, poor estimation or over commitment, and skill gaps.  These issues existed all along, but Scrum makes them more apparent.  All are essential to the successful delivery of a product where success means a satisfied customer, but some are more recognizable than others.

Misunderstanding customer needs is immediately evident during the sprint review in which Working Software is demonstrated.  An effective Team will increase Customer Collaboration to avoid a future embarrassing sprint review.  This is also where an effective Scrum Coach makes their mark in guiding the Team into effective practices.

Poor Estimation is also one of those obvious problems, but it takes time for a team to become effective in estimating.  The more critical problem is habitual under estimation or over commitment.  By making available the Team’s actual velocity in the sprint review it becomes difficult for the team to continue over committing time and again, but an effective coach can highlight the importance of velocity when planning a sprint and projecting a Product Backlog.  Transparency has a wonderful way of solving many problems naturally.

Skill gaps, not surprisingly, are the most likely to be overlooked (and often ignored).  A Team which neglects its craft will eventually see decreased velocity as a result of rising bug rates and complexity.  The Team alone is responsible for the quality of the software delivered to clients and it is here that we see the convergence with Software Craftsmanship.

“Scrum’s purpose is not to be sufficient: it is to set the team into an improvement loop whereby they try to build software, observe what is wrong, and fix it.”

- Ron Jeffries – XProgramming, Co-founder Extreme Programming

Software Craftsmanship is an extension to the Principals behind the Agile Manifesto which compels developers to challenge their skills in the craft of software development.  Scrum provides two important tools which integrate this notion of Craftsmanship: the Definition of Done and the Sprint Retrospective.

Definition of Done is whatever the Team means when it commits to a Sprint.  It should be influenced by the environment in which a team operates and be made apparent to the Product Owner and other teams, though the Team is ultimately responsible.  The Definition of Done acts as a valuable tool to enable evolution of a Team’s skills and a product’s quality through expansion and refinement. 

An example of the evolution of “Done” might be seen as initially stating that all new features must include at minimum one automated test.  While rather abstract and vague, this allows the team to experiment and learn the techniques for testing while building an inventory of tests which can validate the existing functionality.  During a Sprint Retrospective a team may come to the conclusion that it has sufficiently exercised its skills and resolve to expand the Definition of Done to state Code Coverage will not decrease from Sprint to Sprint.  This improvement loop continues with each Sprint.

Software Craftsmanship relies on the initiative, abilities, and imagination of the Team.  Scrum provides the framework for a self-organized team of Craftsman to enact their skills.  The result? An engaged team producing ever higher quality software at a sustainable pace.