Is this your first time going to Agile2015? You’re not alone – it’s my first time too – but from what I understand this isn’t your mother’s tech conference.
So I asked Agile consultant and author Linda Rising, who’s speaking at the conference and is a veteran, for some advice for first-timers.
Don’t overthink it
If you’ve never been to an Agile conference, her best piece of advice is to just throw a dart (metaphorically of course) and go where it leads. Too much studying the schedule and planning out your time is kind of anti the whole Agile mindset, she said. “There is intense competition to speak here and all of the panels have been heavily vetted,” she explained. “You really can’t make a bad choice.”
Expand your horizons
Even if you’re a tester, don’t go to panels just about testing, she suggested. “Just go to one and then count on serendipity to get you where you need to be,” she said. The whole point of this conference of 2000 people is to have the “chance encounter” where you’ll learn something unexpected and meaningful.
Expect the unexpected
Because this is an Agile conference, it can seem a bit like a free for all to the uninitiated, she warned. But that’s kind of the point. “It’s in a big open space with people coming and going, someone’s coaching over there, someone’s joining a session late, someone’s leaving a session early,” she explained. “This is not a normal conference. Anybody can do anything and that’s kind of the idea.”
Get your game on
Games are a big part of the whole Agile experience so expect that in almost any session you attend there will be a period when a game is proposed. Part of the reason for that is to keep people engaged, Rising explained, and part of it is to tap in to our “right-brain creativity.” I’m not sure I have much/any right-brain creativity, but I guess I’ll find out soon enough.
You’ll want to download the app
Or, maybe you really shouldn’t download the conference app (here’s the link for the iphone version), Rising said. “All of that planning and scheduling – and an app – that just doesn’t seem very Agile to me. You should be agile and not over think this.”
Personally, I’m downloading the app (!) because I am paid to over think this. As for the rest of you newbies, I’d go with Linda’s advice.
Let me know if you’d like to meet up for an Agile chat – and I’d particularly like to meet other first timers.
Have you heard about the brand new hotel in Japan that is staffed exclusively by robots? If you’re lucky (and English-speaking), you’ll be welcomed at the front desk by a robotic dinosaur. Japanese speakers only get a humanoid robot, which is clearly their loss.
In this case, the move to automation may be a bit out there, but there’s a good business case to be made. Automation makes this hotel a bargain — guest rooms start at a mere $60, and top out at less than $160. And those robotic luggage handlers don’t need to be tipped.
So maybe it’s not so surprising to hear that enterprises, too, are pushing hard for automation, particularly in the testing arena.
But should they be? TechTarget contributors and testing consultants from Excelon Development — Matt Heusser and Justin Rohrman — met with me recently and this subject was on their minds. Apparently they’re getting a lot of calls from enterprises wanting to “automate the process.”
This isn’t a sign that enterprises are taking testing more seriously, Heusser said. It’s a sign they are in denial. “If you automate bad work, you’re going to end up with bad work done fast,” he said. “Automation is the meme of our age right now.”
The problem with the “let’s automate” bandwagon is that companies are treating the symptoms (testing is too slow) and not the underlying (and much more annoying) problems like the entire design process.
“In order to automate you have to look at what and how you are doing manually, first,” Heusser said. “You want to use automation to complement the human design efforts that work, not to replace them. The companies that have the most success with this think the entire process through and automate only where it makes sense.”
Think automation is the answer to your company’s problems? Or do you agree that the jump to automate might just make things more complicated? Or do you really just want to go to Japan?
I’m the new editor of SearchSoftwareQuality at TechTarget and I’d really like to hear what you think. I’m a veteran journalist who’s written about all kinds of technologies for more years than I’m comfortable admitting to and now I’m embracing software quality.
Email me and let me know what you think. Or what we should write about. Or your favorite thing about Japan.
The Boston Software Craftsmanship Meetup group met recently to play a couple of programming games. They were gracious enough to let me sit in as one of their own. The games were to demonstrate the value of pair programming and test-driven development (TDD). I already liked the idea of these techniques and after seeing them up close, I’m a big fan.
We started the night with a game of Pair Programming Musical Chairs. We split into pairs and got started on a simple problem using TDD. Then, at regular intervals a timer would go off and we would switch partners. One partner would stay with the code and the other partner would start in with a new partner on new code. Continued »
Red Hat Summit / Dev Nation 2015 fell pretty well in line with the theme everything old is new again. The three main themes repeated again and again were containers, DevOps and microservices. I think each of these three important trends is building on a well-established base of solid practice and technology. Continued »
For a journalist, an all-night hackathon can be a pretty intimidating undertaking. I was sure I’d be way over my head sitting with professional programmers as we built and programmed as Raspberry Pi at the Hack ‘Til Tomorrow: Hands-On IoT Hacknight event as part of Red Hat’s DevNation conference last night. I wasn’t completely wrong, but it was much easier to muddle through than I thought it would be. I learned a lot, gained a fair deal of confidence and even made new friends. Continued »
The folks behind Alpha Anywhere, including Alpha Software CTO Dan Bricklin, gathered a bunch of their users to focus on mobile application development and specifically on tablet applications yesterday. Many of the applications their users are building are clipboard replacement applications. That is, they are applications whose function would be done with paper forms on clipboards if tablets weren’t a better option.
If tablet applications are to be successful, “they can’t be worse in certain ways,” Bricklin pointed out, “They can’t slow the user down. They have to have some advantages, like making it easier to scan in new information, add photographs, etc.”
Frequently these apps are used to tie the data collection agents out in the field with enterprise databases on a central server. They’re about as utilitarian as a tablet app is likely to get. And yet much of the meeting was spent talking about design issues that at first mention you might think of as relatively minor. Continued »
The Yellow Pages Group (YPG) in Canada grew out of traditional print publishing. Now, they’re a major player in internet directory services across Canada. The transition wasn’t easy. It took a little luck, a lot of hard work, and the right outlook on IT.
Alain Gaeremynck is the senior enterprise architect at YPG. He said when he first started, nearly 4 years ago, the software development process showed a lot of similarities to their old print roots. The company struggled to keep up with customer demands for new search features and rich user experience. IT was seen as a cost of doing business rather than an investment or a competitive advantage. But that was soon to change. Continued »
There’s one big question at the heart of everything that good software project managers do. How do we develop software better? How do we improve the ways and means through which we develop software? In its time, the Agile Manifesto was a revelation to many developers. It formalized a school of thought about developing software in a fundamentally different and better way. Today, continuous software development seems to be building on Agile principles and pushing them forward. Quicker feedback, tighter cycles, go, go, go! Continued »
One of the main tenets of Agile development is to empower the development team to make its own choices. This is really important because it helps the developers identify with their projects in a very personal way. It gives them a motivator stronger than any benefits package. It gives them pride in their work. However, letting a dozen different teams take a dozen different approaches to development infrastructure probably isn’t the best strategy. It’s important to orchestrate efforts between teams without robbing individual teams of their autonomy.
It seems like there is a definite inverse relationship there. Program directors have to pick a point on a spectrum between letting each individual team make all their own decisions at one extreme and micromanaging every decision at the other. But this may be a false dichotomy. There may be a central infrastructure strategy that can orchestrate efforts across teams and still let individual teams of making their own choices. Let’s look at one particular organization that’s walking the tightrope between empowering teams to make their own choices and orchestrating large team efforts.
One year ago this Sunday, I predicted that the word for 2014 would be continuous – as in continuous development. I know it might be a self-fulfilling prophecy, but the word ‘continuous’ did seem to come up an awful lot in the world of software quality. I think about half of the content we put out on SearchSoftwareQuality.com in December had to do with continuous delivery and/or continuous deployment in one way or another. Keep reading for a peek at some of my favorites. Continued »