Ouch–Visual Studio Copy and Paste Headache

Hopefully this will save someone else a bunch of time that I just wasted.  I have a large complex form and all of a sudden, I couldn’t add a hidden field.  I kept getting the “CS0103: The name ‘[hidden field name]‘ does not exist in the current context”.  Long story; short.  I had accidentally copied JUST the aspx page in my solution.  I had the following:

• Form1.aspx
  • Form1.aspx.cs
• Form1 – Copy.aspx

It was that darn “Form1 – Copy.aspx” that was causing all of  my grief.  I’m not sure how this happened, but I had a couple of instances with VS 2012 crashed on me and I suspect it had something to do with that.  Deleted the copy and BINGO; all better now.

Hope this saves you a few hours that I lost.

Continuous Delivery

If you’re not looking at continuous delivery, you should. We’ve all been there at 2am trying to figure out why a release blew up. Some DB change was skipped; some library wasn’t packaged properly or heaven help you if it is a firewall or network switch issue.

Official Book   Full disclosure; I haven’t read this yet

Also, start reading up on DevOps; there’s a lot to learn.  At the end of the day, much of this boils down to automating the mundane.  If your deployments aren’t mundane, then you should rethink how you are doing them.

New Job

After 13 years at H&R Block I’m moving to Ascend Learning.  I’m not leaving HRB as much as excitement for new opportunities.  Stay tuned for more as I not sure what the future brings.  Who knows, I may be blogging about Ruby, scorn, Boston or things that I can’t imagine.

SCRUM / Agile–What’s Next

In our sophomore year of agile, we’re tackling a handful of big ticket items.  First, we’re working closely with the business to ensure we’re aligned and that agile doesn’t become a negative.  This is all internal stuff that I’m not comfortable sharing.  If this is important to you, drop me a note or give me a call and we can discuss.

There’s more to agile than SCRUM

While SCRUM excels as a process, there’s a lot more to building world class software than process.  Spend any time in the agile space and you’d run across a LOT of terms: TDD, BDD, CI, etc., etc.  I’m not going to go into all of this; feel free to use Google or Bing and spend endless hours reading.  However, I did run across this maturity model for building & releasing software from ThoughtWorks and thought it was good.  It forgoes all of the buzzword jargon and focuses on how to rate your level of maturity and not which tools you use.  My teams reviewed this model and we’re shooting for “Level 1 – Consistent: Automated processes applied across whole application lifecycle”.  What level would you target?

Reference Maturity Model:  http://www.thoughtworks-studios.com/resources/agile-maturity-model-applied-building-and-releasing-software

SCRUM–What’s the best part?

The other day, someone asked me what the best part about the transformation to SCRUM/Agile has been.  It took a while for me to answer, because there’s been SOOOOOOOO much change.  Awesome products delivered; happy users; less paperwork more delivery; eliminating manual processes…

Answer: Providing new opportunities for coworkers that they really enjoy.

Alright, stop with the groans; this is the God’s honest truth.  I’ve seen people who were down in the dumps day after day with waterfail dramatically change to enjoying their work and smiling a lot.  The scrum teams work their butts off, but they also laugh a lot too.  If you’re not happy about what you’re doing, figure out how to make other people’s lives better and you’ll find a lot of happiness yourself.

Getting our SCRUM on #4

The Year In Review

We’re finishing our first year with SCRUM and I thought I’d recap the highs and lows that I’ve observed.  For me, this is the most enjoyable thing I’ve done in my 20+ year career in IT.

Highs

•   The teams have delivered more than anyone thought was possible.  Compared to the old methods where there were endless hours in meetings arguing over this word or that word, the teams got down to business and cranked code.
•   Quality is very good for the teams that implemented automation.  Simple things like automating builds, writing automated unit testing and implementing automated QA scripts has proven a huge win.  Utilizing automation emboldens the teams to make changes that they normally would be afraid to implement.
•   Our business partners are engaged and enjoy being part of the process.  They love being able to adjust features every few weeks and not being told “NO” constantly.  At times, they haven’t liked having to make tough decisions about one feature or another, but in the end, they’d never want to go back to waterfail.
•   If you follow the process, there really is transparency concerning progress and issues.  For the teams that have done burn-up charts (trend towards release scope), they have been spot on.  Velocity provides a good measure of just how much a team can accomplish sprint by sprint and the burn downs let you know whether you’re on track or if you’ve bit off more than you can chew.
•   Presenting the working product at the end of every sprint has given team members visibility to executives that they’d never experienced before.  The executives have really enjoyed getting to meet the unsung heroes who build their systems.  There’s a real sense of pride on the teams when “C” level execs take time out of their schedules to talk to them.

Lows

•   Teams can get lost in the sprint-by-sprint nature of delivery.  We’ve witnessed teams struggling when they have to integrate with other teams, because they got too focused on their timeline and forgot about the other teams.  I’m implementing a weekly “scrum-of-scrums” with my SCRUM teams, architecture, load & performance testing & infrastructure to ensure we’re engaging them appropriately.
•   Some people just can’t handle the teamwork and pace of scrum teams.  Everyone wants to believe they’re a “top dog”, but unfortunately, not everyone can handle it.  You have to spend time developing a personality profile so you know what types of individuals work on your teams.
•   Agile doesn’t prevent “death march” projects.  Even with full transparency, there are forces that drive projects into delivering more features than they should.  Quality suffers, people burn out and moral drops.  However, even on these projects, agile works better, because there’s always an end in sight in a few weeks.

So that’s my take after one year of really doing agile.  In the next 12 months, our plans are to gain more consistency across teams (artifacts & ceremonies) and just get better at it.  Organizationally, we’re still newbies, but there’s a real commitment from the top, which makes all the difference.

New Challenges

As I head into the new year, I’m starting a new role as a Director of App Dev for agile projects. If you’ve been following along, you should know that I’ve developed a passion for agile, scrum & xp practices. Moving out of architecture was a tough decision, but I couldn’t push the engineering teams toward xp & tdd from outside the org.

So, to my friends, peers & mentors, what advice do you have for me? What land mines should I watch out for?

If you wonder why I’m posting to a blog instead of Facebook, I’m keeping work & social networks separate. LinkedIn, which connects to my blog, is for work & Facebook/Google+ is for friends. I think mixing work associates into my friend network isn’t a good idea.

Have a Merry Christmas! Hope you can enjoy time with friends & family.