I’m about to embark on another project next week, an intranet portal, where I have self volunteered to be the ScrumMaster. A few fears about this:
- This is a big project, typical high-profile deal. On top of that it wandered seriously off course, so in a way I’m being asked to get it back on course.
- I have at least 2 other projects underway so I’ll be paying less attention to them. I put a lot of trust in my staff so I’m not actually that worried about this effect.
- I have other priorities which are going to conflict to some extent from finally launching weekly one-on-one sessions to attending architecture meetings about our SOA plans.
- I’m the sheepdog for the team, but I’m also the functional manager for many of them, so when I make suggestions am really letting the team self-organize?
- Many on the team including the product owner have never truly experienced anything like Scrum.
- No one on the team has done much with Websphere Portal, and like any enterprise software it appears to have a lot of gotchas.
- I’m taking away some creative editing for our companies content authors and giving them more defined authoring templates. Today they have full control of static HTML pages they can author in FrontPage. It’s right think to do, but never much fun to deliver the news.
- By default being a functional manager, this is a sub-optimal situation because I’m not 100% focused on this project.
Given all these fears I’m still pretty confident everything will turn out OK on this one, for pretty much one simple reason. I really trust the team I have on this. They are talented, dedicated, tenacious at solving configuration problems, and they really want to deliver. In the end I always trust the people on a project as the best predictor of success. (People over Process)
We just can’t get any of our Scrum teams to agree to a small penalty for arriving late to daily standups. Three official projects now and all of them have turned down the idea of having a cup with $1 donations if you show up late, aka a container of charity.
I plan on trying to get it agreed to on my next unofficial Scrum project, but it may not be part of our culture. We definitely have the late meetings complex that plagues just about anyplace.
I’d argue that Martin Fowler’s Patterns of Enterprise Application Architecture could apply to both though it doesn’t have Ruby example code for any of the patterns.
Brian Marrick looks back on 5 years since the Agile Manifesto:
I think it no coincidence that so many of the Agile Manifesto authors had past experience with Smalltalk (or, in my case, Lisp). That kind of background makes it easier to think of software as something you could readily change. I don’t think Agile would have taken off without semi-flexible languages like Java and the fast machines to run them.
Moreoever, each new tool—JUnit, Cruise Control, refactoring IDEs, FIT—makes it easier for more people to go the Agile route. Without them, Agile would be a niche approach available only to the ridiculously determined.
I’ve heard this idea before that Agile methodologies wouldn’t really work that well until we had IDEs that could easily allow refactoring and languages like Java, Ruby, C#, and Python. I find the idea has a lot of merit. Part of the appeal of Agile is the tools make refactoring a whole lot easier than it used to be.
The one thing about tools that still makes me twinge is when someone explains how you can just click, drag, drop a snippet here, step through the wizard, and bang you generate all your code. This is where the tool is supposedly doing all your work for you. Since this often makes TDD just about impossible these sorts of tools feel really flakey. They often generate just really awful code as well. The final nail in the coffin is you can only ever look at the code effectively or change it by firing up the tool. Those sorts of tools seem really anti-Agile, much like Microsoft Project or the Rational Suite.
Ran my second class on TDD with JUnit today. Now the bulk of our developers have been exposed to TDD directly, but I think there’s still a lot of work to do to nail down real adoption. One of the issues is quite a few people in the class don’t actually get to code in Java all that often so their actual skills are pretty rusty. That made it a lot harder to get through the labs.
I was pleased that two of the QA staff made it to the training and actually got some hands on with the labs. I think QA and development in our organization are starting to work a lot more closely together. Focusing developers on testing can only help.
I was also really pleased that the group helped each other out with a lot of pairing. Even with the three labs I didn’t get tons of requests for help. Of course I might have missed something and they were just content to struggle alone, but I don’t think so.
And I did learn some presentation training lessons some for the second or third time:
- Always be fully prepared. I changed the Keynote presentation up til the Friday afternoon before so I couldn’t get the slides printed until Monday morning and I spent 2 hours doing it. If I had finished them and sent them to the internal print shop–bang an hour later, bound PDF copies.
- When bringing snacks for the afternoon to keep people awake, don’t just get things like peanut M&Ms since some people may be allergic.
- Always setup the machines ahead of time fully. (I was saved here by the fact that it was a pretty technical group and they helped each other out, including putting the labs on a shared drive and not a CD, duh.)
I left the group with the idea that as soon as possible they should go ahead and really try out TDD for about two weeks so they could get a much better feel for it. If most of them try that out this class will have been a wild success. In the meantime I’ll be trying to do a lot more pairing with my own developers. I’m hoping to have a few test infected converts eventually.