A brief note today as I celebrate a small anniversary and victory marking my first year back as an independent consultant.  At this time last year I embarked on my first project after leaving the world of Microsoft Consulting Services (MCS) Canada with a little ditty helping a local customer get started with SharePoint 2010 Forms Based Authentication customizations.  One thing led to another, and before I knew it I had a profitable first year.

Over this time, I began to help my customer (and eventually their customers) introduce discipline and rigor to their software delivery practices by applying a process that I’d been studying and applying for almost ten years:  Scrum.  As I had seen many times before, the benefits were tangible and almost immediate with improved team morale and productivity:  Where once confusion reigned, there was now a regular rhythm that helped focus and align the business and development practices.

As a result of these experiences, I began to see my priorities changing – I thought I’d be doing a lot more SharePoint work, but I definitely was getting a higher calling.

Opening Soon:  A Practice Dedicated to Better Practices

In September, I fulfilled a long-time ambition to attend a Scrum Master training course delivered by its most famous (infamous?) co-creator, Ken Schwaber at his new training offices in Burlington, Mass.  I came away stuffed with experiences, ideas and clarity about where I wanted to next focus my energies and talents:  Helping software teams and their organizations become great software teams and organizations by applying better practices like Scrum.

It’s a good time to do this as now, finally, after so long “agile” software development is now ascending into the mainstream (even if a little late here in Canada).  There are a lot of good teams who are languishing under bad practices that make it nearly impossible for them to achieve success:  The deck is stacked against them with prevailing practices and failure always looms large, requiring all kinds of unsustainable effort to stave off.  The business climate is demanding that they do more with less and produce real results that justify the investment.

Exactly the job that Scrum and its kin were designed to do.  By the end of the year, I was beginning to inspect and adapt my own processes and it was suggesting that a change in direction was required. 

In the next few weeks I will be re-launching my consulting practice with service offerings directed at helping software teams and organizations take their game from zero to hero:  This includes an array of on-site training programs, coaching and development best practices guidance directed not only at preparing the “boots on the ground”, but also managers and the larger business for the cultural shifts in thinking that just-in-time processes require. 

More information will be forthcoming, so stay tuned:  Season 2 is promising to be a blockbuster…!

In the previous installment of this series (Part I), I introduced the first seven observations and notes that I had compiled over the course of a recent project where I was engaged to help a new team and product owner shepherd a small SharePoint 2010 portal into existence using Scrum.

Here are the next seven observations that in contrast to those in Part I, go a little deeper into the meat of organizational and implementation challenges that new Scrum teams encounter.

1.  Build a Release Plan. Revisit and revise it often.

• It’s difficult to know if you are reaching the “promised land” without knowing what it looks like.  A release plan sets out goals for each iteration along with expected features.
  
• Go through the activity of building the plan to first determine if the project is feasible within stated parameters like cost and budget.  Return to the release plan as a preface to each Sprint Planning session and Sprint Review.

2.  You can only go as fast as your team.

• Your project can only progress as fast as your team can deliver features according to their abilities and your definiton of “done”.  Don’t goad them into taking more on to satisfy your ambitions:  It will only lead to an increased probability that they won’t fully deliver a functional, potentially-shippable product increment.
  
• Do not fall into the trap of believing that overtime solves all problems: In reality, quality often suffers as a result.

3.  Set an explicit definition of “done” and stick to it.

• When you set a goal for a Sprint or Release, be explicit with a shared understanding of what it means when a feature is considered “done”.  Often, this defaults to the old trinity of coded/tested/documented, however even this needs clarity: 
• Coded: Usually means writing the code, ensuring it compiles without breaking and is checked-in;
• Tested: Is wide-open to interpretation: Developer unit tests? Acceptance tests?  Automated?
• Documented: This can mean comments in the code, along with capturing pertinent design details in a central repository like a wiki.  On this project, it was deemed satisfactory if a feature could be traced from requirement to implementation and back again.  Fortunately, TFS with the Microsoft Visual Studio 1.0 Scrum template along with associating checked in code to a work item made this a snap.
  
• Without a definition of done that is set and agreed-to by the Product Owner, the team is left to their own devices to determine this, which can and does lead to unpredictable results.

• On the flipside of each user story card, you should capture some simple criteria to prove that feature has been implemented according to spec.  If you run out of room, you may need to break the feature up as you’re likely discovering new usability scenarios.
  
• This tripped up my team on several occasions, and often left QA wondering what they were testing.  This takes practice to be diligent about capturing and remedying.

5.  Involve QA as part of the team from the start.  Give them automated test tools.

• When QA is integrated into the Scrum Team, they are able to understand and discern features and create effective test plans by actively engaging the developers.  This has to happen on a daily basis.  It’s too late to leave it even for a few days.
  
• QA will fail if they are expected to run tests manually; they will fall behind and never catch-up.  Get them an automated UAT suite so that they can compile their test cases and run them automatically at the push of a button.  I recommend Telerik’s Web UI Test Studio.

6.  Don’t design in absence of the team.  Iterate.

• Wireframes and PhotoShop mock-ups are great for “seeing” a design and gettings a feel for it.  However, when they are developed in exclusion of physical implementation by the team, you really have a simulated sense of reality.
  
• This simulated reality often comes at a high cost the longer you wait to implement it;  it can and does create gaps where the mock-ups “hide” how certain features are designed to work, which leads to significant re-work later on, and always takes a lot of work to implement.
  
• Integrate design into planning for each iteration so that the team can translate them into working software.  The goal of every dollar spent in a project should be directed toward creating a functional, potentially-shippable product increment every two weeks.  Period.  Full-stop.
  
• Give your design time to breathe; leverage the opportunities that Sprint Review provides to check your assumptions against reality.  Adjust and improve every iteration.

7.  Trust the team.

• Don’t obsess over whether the team knows what tasks to take on and that you or a Project Manager knows better.  They can and will organize themselves around the work to be done in the most efficient manner because it is always less painful to do so.
  
• Have a question about the product under development?  Ask the team.
  
• Have a question about a new feature you’d like to see in the next Sprint?  Ask the team.
  
• The team will always have a deeper understanding of your product and the challenges faced to make it real:  Always be transparent.  Always take any issue or question to the team.

Well, this is disappointing:  Due to a lack of sufficient sales, Paul and I made the difficult decision earlier this morning to cancel the Toronto stop for his SharePoint Governance and Information Architecture Master Class. 

We thought and schemed about ways we could keep pushing this inevitable decision off, but in the end time played a factor and not having certainty that we’d have enough people to make the event worthwhile was going to play havoc with his itinerary and ability to secure reasonable travel and accommodation arrangements.

Boo.

What Went Wrong?

I’d love to know myself.  Paul and I worked our networks to drive traffic to register.  We tweeted, blogged, cajoled colleagues, pitched the local user group and talked to customers.  No dice.

According to my EventBrite site stats we garnered over 300 page views, and while a bit lower than I’d like even that number wasn’t a wide enough catchment to get interested parties to sign up.  And as I wrote yesterday, that really surprises me because I know how important the topic is:  Governance is *huge* for the enterprise as they are just *now* coming to grips with the reality of hundreds of failed SharePoint implementations.  Ditto for small and medium sized organizations.

They all know that they want to be in some happy future state where SharePoint enables them to be more productive collaborators and information hunter/gatherers but haven’t the foggiest how to achieve it.  Paul’s course provides this guidance – and while it does take some hard work, it’s not that difficult and can be a lot of fun.   It’s our loss to have missed out on the opportunity to have him come to Toronto.

Not All Bad News

Those that have registered for the event will have received a refund notice from the EventBrite site and you can contact me regarding any questions you may have.  Now, it’s not all entirely gloom & doom:  There is an outside chance that Paul may still want to make a trip up to do a guest appearance at a local SharePoint user group.  This is still in the envisioning/planning phase (HA!) – if it comes together, you’ll hear about it here and on Twitter.

Paul has said that it’s unlikely he’ll be back this way (Toronto) any time soon – but there is always an opportunity for the future.  I’ll be working with him over the coming months to see what we can do differently to try and get his Master Class here and in front of an audience of the willing!

Those who have been following my tweets and blog posts (1, 2) recently know that I’ve been helping SharePoint governance impresario Paul Culmsee of CleverWorkarounds fame to bring his Master Class to Toronto this May 12–13.  It could be the time of year and May seeming like a long way off with visions of the cottage dancing in folks’ heads, but it’s been a slow burn to build interest. 

And it makes no sense because I know this class addresses an important issue for a lot of consultants, analysts, project managers and customers  here in the Greater Toronto Area.

Long story short:  We’re on the cusp of making a go/no-go decision this week.  Paul’s got a heavy agenda that’s taking him across the USA and they are gung-ho to have him deliver his practical, deep-dive curriculum.  To lose out here in Canada would be a real shame as he’s not likely to make a trip back this way for a while.  And it’s a horrible way to show our world-famous hospitality, to boot!

So:

This is an exceptional value for two days’ deep-dive into Information Architecture.  You’ll be getting an EXCEPTIONAL value for $1650 CDN!  How exceptional?  When I was with MCS, I’d have to come to you for a minimum of three days at $250/h to give you a mere shadow of the great guidance you’ll get from Paul through a pre-packaged offering that would not address some of the most important issues for your governance planning.  That’s a savings of over $4000!  And you’ll come away with a governance plan that people will actually use!

So:

You’ll be glad you did.  If we can get at least ten folks interested, Paul will seriously consider keeping this afloat and come to Toronto.  Let’s meet this challenge!

UPDATE: Want a sample of what Paul has to offer?  See this sampler vid from one of his recent presentations on SharePoint governance (click to launch):

Recently, I concluded an engagement where I was coaching a new Scrum Team and Product Owner who wanted to build a SharePoint 2010 web-facing content management system with extranet access.  This proved a challenging endeavour on multiple fronts, from lack of proper training and preparation (no time) and experience with the technologies and problem domain to an inconsistent level of engagement for planning each Sprint and defining “done”. 

Over the course of the project, I compiled a diary of observations and notes about what worked and did not work for the Scrum Team and Product Owner as they moved through their project.  Below are the first seven lessons learned I noted: While certainly not new or unknown in agile circles, I present them to edify others who may be taking on a Scrum project for the first time and need some support in making the right choices to avoid problems they might encounter in their implementation.

1. Get training before you start the project.  For everyone.
• While some teams can learn-as-they-go, to be really effective you need to do some dry runs before beginning.  Learn the roles and their responsibilities.  Write some user stories, build and prioritize a Product Backlog.  Decompose it into a Sprint Backlog.  Have a Sprint Review.

• Effective training will give you 40% theory and 60% practical application - you need to do this so that you can begin your Scrum project with less learning curve friction.  You should be able to plan a two week Sprint from start to finish in four hours or less.

2. Scrum is not magic.  It's easy to begin, difficult to master.
• When I instruct teams on Scrum, I make a point of repeating the phrase: "This isn't magic;  it's a framework with rules of engagement that help you get things done."  Too often I find that organizations understand the brochure but not the manual when it comes to Scrum, and this disconnect leads to some shock and awe when the full scope of responsibilities is understood.
   
• Scrum isn't a means to get more done faster - in fact, for new teams they will feel a little slowed down - this is normal because they're building the discipline it takes to be a world-class delivery team.

3. The rules of Scrum are there for a reason:  Don't work around them.
• The first questions I'm often asked by a Product Owner and team is how they can abandon or work around the handful of rules that Scrum requires.  They are there for a reason:  To keep you and your team productive while promoting ROI. 
   
• They have been "play tested" by thousands of teams over two decades - they work because they are simple and effective, but it is hard work to stick to them.  This is why you need a strong Scrum Master / Coach - to keep you motivated as you build your competency.

4. Choose your Scrum Team according to your project.
• It's common sense:  To work effectively, your team needs to have, as an aggregate, the skills required to take on your project.  If they do not, they will move more slowly as they acquire these skills, which can be OK if you've got the budget to accommodate it.

• Having access to a Subject Matter Expert can help a team remove obstacles more quickly, but they are not necessarily an accelerator:  At the end of the day, the team still needs to do the research, whether with the SME or Google, and implement a solution.

5. It takes at least three iterations to get a team together.
• Learning Scrum is easy;  applying it consistently is the challenge.   I often relate the analogy of training to run your first 10k or half-marathon when you have no experience running at all:  You need to understand that newbies will take time to adapt to the pace and practices, and will sometimes falter in their training.
   
• Your new team will likely follow a curve where they are "failing" for the first three iterations as they learn and internalize how to work together as a unit.  Be patient;  expect them to hit their stride in the 4th - 6th iterations. 

6. If you're going to be the Product Owner, be sure you can meet the demands of the role.
• This is a tough and challenging role that has no real analog or precedent:  You are the active guardian of ROI:  You set the goals for each release and iteration and you steer the project based on the inspect/adapt planning and feedback points that bracket every Sprint timebox.  This means keeping your Product Backlog groomed and prioritized with good user stories and working closely with the Scrum Master and Team.

• If you feel that you've got too much on your plate to do this role well, you have two choices:  Delegate your plate to someone else so that you can devote enough attention to the project or delegate the role to someone who can.

7. Celebrate the achievement of every Sprint.
• I make it a point to celebrate the end of every Sprint with each team I coach by taking them out to a pub for a round on me - including the Product Owner.  By the end of a Sprint, a team is often exhausted and exhilarated:  They've hit highs and lows on the road to Sprint Review and they may or may not have made their goal.

• By taking the time to recognize their achievement through a small reward like getting together for a beverage, you validate each team member as a human being and not just a resource.  It gives them a relaxed forum to swap war stories, talk shop or what's up for the weekend while building team morale and loyalty.