kevin donaldson

For the past few years I have been doing a personal year end retrospective.  Its a fun and relaxing exercise to do over the holidays as you sip on a warm drink, enjoy the Christmas season, and prepare to kick things back into gear in the new year.  Here are a sample list of questions that I have collected and use to carry out this exercise.  I like to write down my answers to some of these so I can then go back and look at them next year.  Some I just think through.   You can do it solo or go through some of them with a good friend.  (Lance - I will miss doing this with you this year!)

Looking Back...

• What is the greatest lesson you learned this year that you never want your kids to forget?
• How might you have behaved or acted differently in 2010 if you had to do it over again
• Looking back over the year what did you set out to do that you didn’t do and why?
• What key discipline did you live out this past year that had significant impact on your life?  What was the impact?
• What are you most proud of this year?
• What was the biggest triumph this year?
• What were the key surprises (good or bad) that happened this year?
• Which relationship in your life grew this year and which regressed?
• If you could go back to the beginning of this year what piece of advice would you give yourself? Why?
• Looking back, what was the overarching theme for this year? / What one word best sums up your 2010 experience?
• What was the greatest lesson you learned in 2010?
• What was the most loving service you performed in 2010?
• What is your biggest piece of unfinished business in 2010?
• What are you most happy about completing in 2010?
• Who were the 3 people that had the greatest impact on your life in 2010?
• What was the biggest risk you took in 2010?
• What was I worrying about at this time last year, and how have things changed?
• What are my current allergies (emotionally, mentally, spiritually, and physically)?
• What compliments would you have liked to receive in 2010?
• What compliments would you like to have given in 2010?
• What was the smartest decision you made in 2010?
• What else do you need to do or say to be complete with 2010?

Looking Ahead...

• What would you like to be your biggest triumph in 2011?
• What advice would you like to give yourself in 2011?
• What is the major effort you are planning to improve your financial results in 2011?
• What would you be most happy about completing in 2011?
• What major indulgence are you willing to experience in 2011?
• What would you most lie to change about yourself in 2011?
• What are you looking forward to learning in 2011?
• What do you think your biggest risk will be in 2011?
• What about your work, are you most committed to changing and improving in 2011?
• How should I control/adjust my rhythm/pace in 2011?
• What is one as yet undeveloped talent you are willing to explore in 2011?
• What brings you the most joy and how are you going to do or have more of that in 2011?
• Who or what, other than yourself, are you most committed to loving and serving in 2011?
• What one word would you like to have as your theme for 2011?

Agile has definitely reached buzzword status.   Have you heard any of the following?

• 'Agile is one of our initiatives for this year’
• ‘We plan to implement Agile next quarter’
• ‘Agile is in the budget for this year’
• ‘Yeah – we started Agile’

A large number of companies going in with this mentality will fail, and come out saying things like ‘Agile just doesn’t work in our organization’.  Here’s the thing: Agility is about people.  It’s a way of thinking; it’s a way of being and acting.  It’s not a process. It’s not something you buy and implement.  You would not say ‘we are going to implement company culture this year’, and organizational agility falls in the same camp.   Agility is an organizational value and philosophy guided by patterns and frameworks.

A lot of this misunderstanding stems from Agile software development.  Even within the software community there is confusion.  For instance, Agile is not a development methodology – it’s a set of guiding principles.  Even the methods that fall under the Agile umbrella such as Scrum can best be described as frameworks to help guide and implement Agile principals.

That being said, Agile software development should also be celebrated.  Software development is a realm of extreme uncertainty, which has allowed agile techniques to evolve at much faster rates than other aspects of business.   Now that extreme uncertainty has spread well beyond software and we can take advantage of these advances and adopt them more broadly to support organizational agility.  To use a software analogy on agility: Agile needs to be part of the organizational operating system – not a program that run within it.

In business, agility is most often described as  “the capability of rapidly and efficiently adapting to changes”, but this definition has a very mechanistic feel to me.  When I think about true agility I think about a Cheetah for instance.  With that frame of reference, I define organizational agility as the capability to react with speed, strength and grace.    This makes agility less machine-like and more focused on its true core – people. 

Over the past couple of days we have had Jeff Sutherland in helping us work through some of our scrum impediments and he brought up an interesting, yet simple measurement tool that I would like to expand upon here that can be useful for any organization using agile techniques for business management.

Think of it as a simple balanced scorecard for agile teams.  To create the score, you can use a combination of quantitative hard measures as well as qualitative metrics such as surveying your team.  Doing this, say on a monthly basis can give you a gut sense on where things are going well and where the team can improve.   It can be a valuable part of the retrospective process.  This can create discussions that can lead to the identification of team impediments and hence towards ways in which process’s can be adjusted and improved.

The base model consists of 4 components: Velocity, Direction, Sustainability and Quality.  I have added a fifth dimension of User/Customer Experience. 

• Velocity:  This is the rate of throughput for the agile team typically measured in points or some other measure of output.
• Direction: This relates to how well the backlog is managed, how well thought out the strategy is, and how the team manages instability (changing markets, customer needs, competitive pressures etc)
• Sustainability:  In an agile organization the goal is to increase velocity and maintain a sustainable pace.  Sustainability can relate to hours, mental overload etc.  (see related post on the creativity inflection point)

The last 2 have an external focus:

• Quality:  This relates to the quality of the product or service being produced by the team.  It can be measured by factors such as defects, service calls, process time etc.  Arguably anything that falls into the lean definition of ‘waste’ could fit into this category.
• User Experience:   Some may argue that quality vector includes user experience but I feel that they are best thought of as different dimensions.  Some metrics such as customer satisfaction (eg Net promoter score) will be influenced by both but they are not always correlated.  You can have a very high quality product that produces a very poor customer experience.  Having a specific gauge on user experience creates a better balance.

Measuring this over time can give you good view into where things are at, what is getting better and what is getting worse.  It can also help you measure against organization priorities.  For instance, the team may actually need to sacrifice some velocity to increase on the vector of user experience for some period of time. 

What do you think?

A startup is as much about mental preparation as it is about the idea.  If you have never done one you can do a lot of wheel spinning all the while burning precious capital and time.  Software can be especially daunting especially if you have either never done it before or you have come from a traditional large company.  If you have an idea for a software application - a web app or possibly a mobile app here are 5 resources that will put you in the right mental frame of mind:

1. Getting Real - The smarter faster easier way to build successful web applications

• A bible for the software startup, written in 2006 by 37 Signals.  You can read it for free online or purchase PDF or paperback..

2. The Entrepreneurs Guide to Customer Development

• Forget traditional product development methods.  They assume you have a market.  The goal of a startup is to find a market.  This e-book is a quick start to understanding new thinking on customer development.  Once you have digested this, you can then migrate up to the original authority on the topic: The 4 Steps to the Ephiphany.

3. The UX Driven Startup

• I was just recently made aware of this presentation but find that it provides a great summary perspective on an often missing link in many software startups - how to think about the user experience, and design.  For consumer apps, the design and user experience is more important that the technical design - especially early on.

The last two are not strictly related to software development - more of what I would refer to as 'business philosophy' books that will complete you mental preparation.

4. Rework

• Another resource from 37 Signals.  A collection of amazing and quick-to-read essays in one consise book.

5. Linchpin

• An amazing book from Seth Godin on making yourself indispensible (which is required if you want your startup to be successful)

Here are the slides from a presentation I gave last night to an MBA class at George Fox University.  I presented what I feel are the 3 imperatives for managing a modern business:

One of the tenants of Agile is the use of simple tools' such as white boards and index cards.  This is sound advice when you are starting down the Agile path.  If you start off using software it is very easy to get wrapped around the axel with too much focus on the tool and not enough on learning and improving your development process.  However once you mature, extend the use of agile beyond a single team, or perhaps have distributed teams software tools often become a necessity manage your agile processes.    The issue with simple tools is that they do not scale extremely well and can create a team impediment to increasing the overall velocity.  Even though we have our team centralized and keep it small, we reached this point last year and made the switch to using software (Atlassian/Jira), which allows us to put a lot less time into managing the entire product development process ( both product management and engineering).  We now could do a lot more work at lower stress levels with the same staffing.  

That being said - the process of finding the right tool for your organizational needs is challenging as this is still a relatively young market.  The good news is that is now changing with the release of a Forester report on Agile development Tools (Q2 2010) - The bad news is that if you are not a member, the report is listed at $1749.  However Rally, who received top marks (Congratulations guys!) blogged today with a link to the report.  Who knows if it will stay up for long but go take a look - it is worth a read.  In addition to the scoring, it also provides some valuable insights as to the state of the agile development market.    One note - this list is not exhaustive and focus's mostly on the enterprise market.  For those just starting into Agile but possibly with a distributed team check out Pivotal Tracker.  It is an excellent, light-weight and free Agile mgmt tool.

We have practiced agile in my current startup for 3.5 years we have gotten very good at executing quickly and under conditions of extreme change and uncertainty.  Our product development team is considered an organizational success story of consistency and execution excellence... but is it to a fault? While we have done a great job of shifting with the needs of the market, while still maintaining consistent output and consistent improvement, I can't help but feel that a focus on execution (ie - releasing code) which is deeply ingrained in our culture is often detrimental to an objective of product market fit.

Yes - We talk to potential customers, actual customers, we carry out usability testing, and pre-testing of new features before then go into development when possible, but what got me thinking about this was a comment made last week:  'as we grow with more clients, we need to be more careful about how we iterate into new features to ensure they meet a minimum standard of feature readiness for usability'. This comment essentially implied that iterative development and usability is an either-or choice!   But why?  And then I thought about our culture of execution.  For example - how we measure progress of product development in terms of points/features released.  Could this be closing our minds to other mechanisms of 'release' and clouding the real goal of finding a way to validate a hypothesis with a customer?   What we need is a cultural shift in thinking from a focus on execution to a focus on learning. 

Take for instance the Agile scrum board with its focus on execution.  In scrum, stories (features etc) don't get counted as done until they pass acceptance tests and the code is ready for release. Once the code is released the team is then on to the next batch hoping that this iteration is taking us down the right path and waiting for feedback while we move on to execute on other things. 

Maybe there is a better way... recently I have heard discussions in the lean startup community on how the scrum kanban board could be modified to create a learning focus vs execution focus.  It's the idea of adding another column to the kanban for customer validation with specific limits set on how many items can be sitting in that column.  Working code is no longer the measure of success, but validated learnings about a change are.  This intrigues me.  Limits would not allow the team to take on new work until other items can be validated and cleared from the queue.  It even has the potential to help ensure that certain things don't even get started until there is a valid mechanism on how it could be validated?

Yes - when something like this is proposed in a culture of execution the response will most likely be 'That will slow us down'?  This type of comment is the root of the problem in an execution based culture.  If the focus was on learning one would see that this will likely make you go faster. 

At the Startup Lessons Learned Conference on April 23 Kent Beck presented the 'Build' Keynote on Beyond Agile Programming.  In addition to using a great analogy between startups and goats, he presented a compelling enhancment to the agile manifesto as applied to startups. 

(In each set of bullets the first bullet is pre Agile, the second is the statement from the Agile manifesto, and the third bullet is beyond Agile for startups) 

• Processes and Tools
• Individuals and Interactions
• Team Vision and Disipline

A startup needs optimize for the team over the individual

• Comprehensive Documentation
• Working Software
• Validated Learning

A startup needs to begin with the need and work backwards towards the software

• Contract Negotiations
• Customer Collaboration
• Customer Discovery

A startup needs to discover/find who your customers are before you can collaborate with them

• Follow the Plan
• Responding to Change
• Initiate Change

 A startup doesn't have change, so before you can respond to change you need to initiate change

Subtle but important.